[02:43] <lotuspsychje> good morning
[21:43] <Bashing-om> UWN: Issue765 now available to our reading public: https://wiki.ubuntu.com/UbuntuWeeklyNewsletter/Issue765 :D
[21:44] <sarnold> woot


[01:41] <MegaTrousers> Greetings. I seem to be able to find the Ubuntu Packaging Guidelines for Edgy, but I can't seem to find its wiki for Karmic. Anyone have any ideas?
[03:35] <MegaTrousers> Greetings. I seem to be able to find the Ubuntu Packaging Guidelines for Edgy, but I can't seem to find its wiki for Karmic. Anyone have any ideas?


[07:37] <bryce> tjaalton: ok cool
[07:38] <bryce> tjaalton: maybe I can do up a script to automate all those requests
[23:13] <tjaalton> tseliot: btw, you need to bump the abiver to 2.9 from the nvidia packages
[23:16] <tjaalton> or drop the Provides..
[23:23] <tjaalton> or add xserver-xorg-dev build-dep and get the abiver on build time


[02:33] <nigelb> I still can't figure out why I started hacking on LP before I read about Zope 3.
[02:33] <nigelb> Finally I'm reading Zope 3 intros :P
[04:53]  * StevenK purges 3GiB of postgres logs so that /var actually has some free space.
[04:57]  * nigelb twitches at GiB
[05:00] <StevenK> nigelb: You don't like {K,M,G,T}iB?
[05:00] <StevenK> Can't remember what comes after T. E?
[05:21] <lifeless> Eca
[05:21] <lifeless> bah
[05:21] <lifeless> Exa
[05:22] <StevenK> Right, so it is E
[05:22] <lifeless> or is it P
[05:22] <StevenK> Then, P, then Z, and then OMGBBQWTFBIG
[05:22] <lifeless> it might be P E
[05:22] <lifeless> ah E P
[05:24] <lifeless> wgrant: we don't build-in a structure of partitioned namespaces (partly because teams have no project affiliation etc
[05:24] <lifeless> wgrant: so folk need to remember
[05:32] <lifeless> wgrant: however, this one has me confused too ;P
[06:20] <nigelb> StevenK: My dislike is for the 'i'
[06:21] <lifeless> nigelb: you're a no i kinda guy ?
[06:22] <nigelb> lifeless: Bwahaha. No.
[06:26] <nigelb> So, I noticed something weird today.
[06:26] <nigelb> Potentialy a mintor security thing.
[06:27] <nigelb> When I go to https://launchpad.net/~canonical-sysadmins, I see a <hidden> under "Subteam of"
[06:27] <nigelb> Isn't our policy to to show "its not even there" when something isn't supposed to be seen?
[06:28] <nigelb> s/show/do'g
[06:28] <nigelb> s/show/do/g
[06:35] <lifeless> thats an adapter kicking in and preventing disclosure
[06:35] <lifeless> yes, it shouldn't show at all, but its a cosmetic, not a security, concern
[06:35] <lifeless> please do file a bug
[06:36] <nigelb> cool, will do
[06:49] <wgrant> lifeless: It is actually a security concern, slightly.
[06:49] <wgrant> I filed it a couple of years ago.
[06:49] <wgrant> It's in alphabetical order.
[06:49] <wgrant> So you can determine the display name.
[06:50] <nigelb> wgrant: there's already a bug?
[06:50] <wgrant> I think so. Trying to find it...
[06:51] <lifeless> wgrant: you can guess at possible display names ;)
[06:51] <wgrant> lifeless: Then you can create teams on staging to do a search.
[06:51] <nigelb> wgrant: bug 329132
[06:51] <nigelb> ?
[06:51] <_mup_> Bug #329132: Strange string under "Subteam of" in LOSAs' team page <confusing-ui> <lp-registry> <registry-people> <Launchpad itself:Fix Released by bac> < https://launchpad.net/bugs/329132 >
[06:52] <wgrant> Hah
[06:52] <wgrant> What a fix.
[06:52] <wgrant> I thought I filed a similar one, though...
[06:53]  * nigelb stabs Zope 3
[06:54] <nigelb> Trying to get it to work. Refuses to work.
[06:54] <wgrant> What are you doing to the poor creature?
[06:54] <nigelb> Using Benji's quick start guide
[06:54] <wgrant> nigelb: I guess you should file a new one rather than reopen the old one.
[06:55] <nigelb> wgrant: Filing now
[06:55] <wgrant> nigelb: You may have some issues with using that.
[06:55] <nigelb> Oh.
[06:55] <wgrant> nigelb: Since Zope 3 doesn't exist any more.
[06:55] <nigelb> wtf.
[06:55] <wgrant> It's... complicated.
[06:55] <wgrant> Most of the underlying libraries now make up what is known as the Zope Toolkit, or ZTK.
[06:56] <wgrant> The UI (ZMI and other stuff that's mentioned there) is not part of the ZTK, and was abandoned for a time.
[06:56] <wgrant> But then was made into its own project atop the ZTK, BlueBream.
[06:56] <nigelb> All I wanted was to get a hands on feel for zope minus the complications of Launchpad so I can figure out Launchpad faster.
[06:56] <wgrant> Not sure if that is still active.
[06:56] <wgrant> http://bluebream.zope.org/screencasts.html may be helpful.
[06:57] <wgrant> http://bluebream.zope.org/doc/1.0/index.html too
[06:57] <wgrant> Looks like the docs don't make me want to die any more. Which is a good start.
[06:57] <nigelb> Oh, cool!
[06:57] <nigelb> Thank you
[06:57] <nigelb> Is that closer to what LP is using?
[06:58] <wgrant> LP doesn't use BlueBream, but it uses many components of the ZTK.
[06:58] <wgrant> Not all the latest versions, but mostly within the last 18 months.
[06:58] <wgrant> It also uses some stuff that BlueBream uses but that is outside the ZTK.
[06:58] <nigelb> Ok, so it should give me a good basic idea.
[06:58] <wgrant> Yup.
[06:59] <nigelb> Right now, I'm coding on LP with extensing grepping and asking here.
[06:59] <nigelb> And grepping my logs of asking here.
[06:59] <wgrant> Previously I would have suggested that you obtain, by some means, a copy of Web Component Development with Zope 3. But it was already obsolete when I started, and it's going to not be practically usable now.
[07:00] <wgrant> Good in-depth teaching of the concepts, though.
[07:00] <wgrant> Most LP engineers do what you do, I think :)
[07:00] <wgrant> They learn Zope 3 by drowning in LP.
[07:00] <nigelb> Hah
[07:01] <wgrant> "It is recommended to use a custom-built Python for working with BlueBream."
[07:01] <wgrant> Gaaaaah stupid Python people.
[07:01] <nigelb> heh
[07:02] <wgrant> (if following the bluebream getting started guide, I would use virtualenv to install bluebream without polluting your system)
[07:03] <nigelb> I always use virtualenv for this kinda stuff
[07:03] <lifeless> wgrant: ah, nifty
[07:03] <wgrant> From Wikipedia: "BlueBream is in active development and is now considered a stable framework, used on production projects worldwide, most notably Launchpad."
[07:04] <nigelb> WHAT?
[07:04] <wgrant> But we don't use the whole thing :(
[07:04] <wgrant> Maybe they've altered the scope of BlueBream to be everything that was in Zope 3 that is not in the ZTK.
[07:04] <wgrant> Last I heard it was primarily the ZMI.
[07:04] <lifeless> nigelb: my preferred solution for 'LP is hard to understand' is to clean things up
[07:05] <lifeless> nigelb: e.g. by deleting lots o fcode
[07:05] <nigelb> lifeless: My problem is my web development experience is in Django. I'm trying to figure out how is the sort of right way to to do things in zope.
[07:05] <lifeless> nigelb: ah
[07:05] <nigelb> Its probably a day or two of reading up
[07:05] <lifeless> nigelb: so do you want the good news or the bad nes ?
[07:05]  * StevenK deleted something like 2,800 lines of code yesterday
[07:05] <nigelb> I figured its time I invested that
[07:05] <nigelb> lifeless: I'll take the bad news first
[07:05] <lifeless> nigelb: the right way of doing things is the wrong way for LP
[07:06] <nigelb> Expected.
[07:06] <nigelb> Yay!
[07:06] <lifeless> sorry, that was mistyped. But hilarious.
[07:06] <lifeless> nigelb: the right way of doing things in zope is the wrong way for LP
[07:06] <nigelb> StevenK: When I meet at some point, I'll buy you a drink for that.
[07:06] <lifeless> is what I meant to say.
[07:06] <nigelb> Small difference :)
[07:06] <nigelb> StevenK: *meet you
[07:07] <lifeless> two words, but significant impact :>
[07:07] <wgrant> lifeless: Well, everything except persistence is not too bad.
[07:07] <lifeless> wgrant: except that *everything* is driven by persistence.
[07:07] <lifeless> wgrant: also you forgot configuration.
[07:07] <nigelb> Well, so I'm probably looking at bare basic concepts. Like tal thingy or zcml.
[07:08] <nigelb> Both of these I still don't really understand, but I can read and guess
[07:08] <wgrant> lifeless: Except ZCA and views and TAL and ZCML and the general architecture.
[07:08] <lifeless> wgrant: tal and views are impacted by persistence; zcml is because of the model:interfaces interactions.
[07:09] <wgrant> Only slightly.
[07:09] <wgrant> lifeless: Also, do we want to roll back that spaces in URLs thing?
[07:09] <lifeless> wgrant: zca also interacts with persistence in the same way, fwiw
[07:09] <lifeless> wgrant: yes, we do.
[07:10] <wgrant> Shouldn't have to roll back production, since we're almost deployable.
[07:10] <wgrant> Also there's also an additional 1000 Loggerhead OOPSes that we might care about.
[07:10] <lifeless> wgrant: are you still on leave ?
[07:10] <wgrant> Yes.
[07:10] <lifeless> heh
[07:10] <lifeless> wgrant: I was going to ask if you felt like doing the rollback
[07:10] <nigelb> If wgrant is *this* productive when he's on leave...
[07:10] <wgrant> qemu-kvm's broken gdbstub is broken enough that I will look at work, but not do it :)
[07:11] <nigelb> lifeless: I saw the wiki LEP. Has it gone stale or is it still alive?
[07:11] <lifeless> nigelb: its confused
[07:11] <nigelb> Because I'd like to propose extracting stuff from readthedocs and bring it into LP.
[07:11] <StevenK> lifeless: Oh, the loggerhead rollback?
[07:11] <lifeless> StevenK: not loggerhead, url ascii rules
[07:12] <wgrant> loggerhead's broken too, but I think that might be two rollouts ago.
[07:12] <wgrant> Not quite sure.
[07:12] <lifeless> 993 RuntimeError: dictionary changed size during iteration ?
[07:12] <lifeless> probably bzrlib
[07:13] <wgrant> We didn't upgrade bzrlib, did we?
[07:13] <wgrant> Still 2.3.3
[07:13] <wgrant> We did upgrade loggerhead.
[07:15] <lifeless> we need a bug at the least
[07:15] <lifeless> and probably a rollback of loggerhead too
[07:18]  * wgrant curses lifeless a bit.
[07:18] <lifeless> wgrant: ?
[07:18] <wgrant> The only thing left writing to BugTask's target key attributes directly is the bugsummary tests.
[07:19] <wgrant> removeSecurityProxy ftw.
[07:19] <lifeless> wgrant: hah. I didn't write those :P
[07:19] <wgrant> GUILTY
[07:20] <wgrant> We might be able to put NULL Project to sleep on Monday...
[07:21] <StevenK> Oh, nice
[07:21] <StevenK> wgrant: Can I land populate-bprc now?
[07:22] <lifeless> StevenK: why wouldn't you ?
[07:22] <wgrant> Well, it almost has a veto.
[07:22] <wgrant> (not from me!)
[07:22] <StevenK> lifeless: From a certain GSA who won't be named saying it sounded like an epicly bad idea
[07:23] <lifeless> how so ?
[07:23] <lifeless> what was the concern ?
[07:23] <lifeless> https://bugs.launchpad.net/loggerhead/+bug/826136
[07:23] <_mup_> Bug #826136: dictionary changed size during iteration <oops> <loggerhead:Triaged> < https://launchpad.net/bugs/826136 >
[07:24] <StevenK> lifeless: That the data does not and should not go into the main DB
[07:24] <lifeless> StevenK: thats not a concern
[07:24] <lifeless> StevenK: thats a conclusion
[07:24] <lifeless> :)
[07:25] <StevenK> lifeless: After wgrant and I talked about it, we decided to wait for a bit, since if we kick off the migration, it's quite difficult to migrate the data back out again
[07:25] <lifeless> StevenK: I don't follow.
[07:25] <wgrant> It's slightly awkward.
[07:25] <wgrant> Not quite difficult :)
[07:27] <StevenK> lifeless: It's a large amount of data that will land into launchpad_main -- it will sit like a red wine stain. Once it's there, it will require persistance to move
[07:28] <lifeless> StevenK: so the concern is size?
[07:29] <lifeless> StevenK: why isn't deleting it as simple as a loop doing delete LIMIT 50 ?
[07:29] <StevenK> lifeless: No. My small concern is migration pain
[07:29] <StevenK> My other concern is I'm not clever enough to implement step 3 and 4 of the grand plan
[07:30] <lifeless> they being?
[07:30] <StevenK> 3. Hook into the publisher to create and delete rows in BPRC and BPP when it publishes or superseded a BPR.
[07:31] <StevenK> 4. Hook into the publisher to generate contents file, and turn off the current contents generation script.
[07:31] <lifeless> 3 seems bogus
[07:31] <wgrant> Both are.
[07:31] <StevenK> Eh?
[07:31] <wgrant> Neither should be in the publisher, I don't think.
[07:32] <wgrant> BPRC lifetime is the same as file lifetime.
[07:32] <lifeless> 4 could be in the publisher, or separate
[07:32] <wgrant> So they should certainly not be removed by the publisher.
[07:32] <wgrant> 4 is possibly OK, but not required, and there's already enough in the publisher IMO :)
[07:32] <lifeless> 3 is bogus because there can be N published entries, and trying to add just-in-time or delete just-after-use will be massively racy.
[07:34] <StevenK> The garbo job should certainly keep up with new BPRs, but I'm concerned about bloat in BPRC/BPP
[07:34] <wgrant> The BPF expiry script will remove them.
[07:34] <StevenK> wgrant: Ah, that reminds me.
[07:35] <StevenK> wgrant: The populate-bprc garbo job returns BPRs that do not have any BPFs. Do not want.
[07:35] <wgrant> Indeed, although in production there shouldn't be any.
[07:36] <StevenK> wgrant: Hah, maybe.
[07:36] <lifeless> StevenK: so here is a question folk might like to answer
[07:36] <StevenK> lifeless, wgrant: So, land the garbo population job and then think about the next step while it populates?
[07:36] <lifeless> 'when was /usr/bin/foo introducted to the archive'
[07:37] <lifeless> StevenK: we might want to gc things for space considerations
[07:37] <lifeless> but having enough data to ssatisfy the use case is the first step
[07:37] <StevenK> We certainly do want to GC things
[07:37] <lifeless> StevenK: what was the gsa's concern ?
[07:37] <StevenK> lifeless: That it doesn't belong in the main DB
[07:37] <lifeless> StevenK: You can fit *every* file in *every* arch in *every* published deb, ever, in < 5GB
[07:38] <lifeless> [excluding PPAs, but they are (for now) still minimal)
[07:38] <StevenK> lifeless: Modulo bugs :-(
[07:42] <lifeless> StevenK: yes, but having extra rows would be fairly obvious
[07:42] <lifeless> StevenK: I don't think gc is a given.
[07:44]  * StevenK fixes the conflicts the branch has with devel
[08:17] <lifeless> rev 13687 is the rollback
[08:18] <StevenK> lifeless: We don't have much QA to do, wallyworld_, bigjools, 2 * danilo
[08:18] <StevenK> We might be able to deploy on Monday afternoon UK time
[08:26] <lifeless> not morning ?
[08:30] <StevenK> lifeless: Depends on how quick the QA is done -- I was being pessimistic.
[15:00] <nigelb> gah, qastaging is timing out, known?
[15:12] <jelmer> nigelb, hey
[15:12] <jelmer> nigelb, I don't think it is - perhaps it's just updating?
[16:05] <nigelb> jelmer: hm, maybe.
[16:05] <nigelb> I'll just try a while later :)
[20:08] <lifeless> nigelb: timing out on all pages or just one ?
[20:08] <lifeless> nigelb: some timeouts are (unfortunately) 'normal' for [qa]staging
[23:30] <lifeless> aieeeee
[23:30] <lifeless> IUnloggedException. Sob.


[16:42] -queuebot:#lubuntu-devel- New binary: lubuntu-meta [amd64] (artful-proposed/universe) [0.76] (lubuntu)
 You miss one little bot :-)
 Can you tell us about that, @julienlavergne? :D
[16:43] -queuebot:#lubuntu-devel- New binary: lubuntu-meta [armhf] (artful-proposed/universe) [0.76] (lubuntu)
[16:43] -queuebot:#lubuntu-devel- New binary: lubuntu-meta [i386] (artful-proposed/universe) [0.76] (lubuntu)
[16:44] -queuebot:#lubuntu-devel- New binary: lubuntu-artwork [amd64] (artful-proposed/universe) [0.67] (no packageset)
 Ah, the artwork is here too :-)
 Just made the seed changes we discuss last time
 \o/
 I also added more qt metapakges, it should be easier for people to install our qt stuff
 Yayyyy :D
 @julienlavergne: Could you send a quick email to the lubuntu-devel list explaining this, please?
 Even if it's just updating us on the fact that things have been uploaded, it would be great to have it there ;)
 I have to finish a few things before
 OK, that's totally fine. :)
[17:59] -queuebot:#lubuntu-devel- New: accepted lubuntu-artwork [amd64] (artful-proposed) [0.67]
[17:59] -queuebot:#lubuntu-devel- New: accepted lubuntu-meta [armhf] (artful-proposed) [0.76]
[17:59] -queuebot:#lubuntu-devel- New: accepted lubuntu-meta [amd64] (artful-proposed) [0.76]
[17:59] -queuebot:#lubuntu-devel- New: accepted lubuntu-meta [i386] (artful-proposed) [0.76]
 ping lubuntu devels
[18:05] <teward> probably better to state your actual question/statement :P
[18:05] <teward> devs don't reply well to random pings without reasons :P
[18:06] <acheronuk> I have taken the sddm 0.14 packages tsimonq2 staged in his ppa, and applied a couple of changes clivejo made and which Simon was going to do anyway
[18:06] <acheronuk> have put sddm 0.14 for artful in ppa:kubuntu-ppa/staging-misc and ppa:rikmills/sddm-0.14
 Ack
 I'll review later
[18:07] <acheronuk> tsimonq2: you will keep the changlog on that if uploaded ;)
 @acheronuk, :)
[18:08] <acheronuk> thx :)
[18:08] <acheronuk> teward: yep. I got slightly delayed copying in my next line :P
[18:09] <teward> :P
 PENIS!!!
 .__.
[18:31] <acheronuk> wrong chat I hope
 not really :|
[18:32]  * acheronuk shrugs
 @VikingRedwolf haha. deleted on telegram, but logged on IRC for ever
 wait, the word PENIS is logged forever? 😆
 I know, I know, public channel, and that stuff...
 :|
 lol
 WALTER!
[18:49] <redwolf> ha! you're right, @acheronuk, I'm seeing the PENIS word LOL :|
[18:50] <redwolf> wxl, ping me when you're ready
[19:14] <wxl> what @redwolf ?
 Walter, I sent you a private message, so Simon can't see it :|
 @VikingRedwolf, Why?
 😬


[06:40] <poolie> hi riddell
[06:51] <vila> hey poolie and others !
[06:53] <poolie> hi there
[06:53] <poolie> i'm giving udd config options to talk to staging lp to make it easier to debug/test stuff
[06:53] <vila> poolie: great !
[06:54] <vila> poolie: don't worry too much about using the stacked-based configs, I intend to upgrade udd when 2.4.x is deployed on jubany anyway
[07:46] <poolie> vila, so how about https://code.launchpad.net/~mbp/udd/configure/+merge/71822
[07:46] <poolie> oh also, while i'm here, can you see if you can get into the blog?
[07:46]  * vila looking
[07:47] <vila> poolie: this won't work until 2.4x is deployed I think
[07:49] <vila> poolie: meh, I'm out-of-date about iconfig
[07:50] <vila> gee, I didn't remember introducing a forward-compatible layer there...
[07:50] <poolie> ah, are you saying iconfig's present but can't be used?
[07:51] <vila> no no no, you're doing fine, my bad
[07:53] <poolie> thanks for thinking of it though
[07:54] <Riddell> hola
[07:55] <poolie> hi thar
[07:56] <jam> morning all
[07:56] <poolie> hi jam
[08:02] <vila> poolie: reviewed
[08:02] <vila> poolie: BB:tweak
[08:13] <poolie> thankss
[08:31] <poolie> i'll roll that out then
[08:38] <poolie> actually i might try to actually fix the httperrors first
[08:54] <jimis> I did a bzr switch, and an unexpected conflict happened
[08:54] <jimis> Can I undo and go back to previous branch to commit?
[08:55] <poolie> hi jimis
[08:56] <poolie> you can go back but i think that will carry back the conflicts
[08:56] <poolie> sorry
[08:56] <poolie> there ought to be a way to say 'i wish i never switched (or, merged, or whatever)' but there isn't yet
[08:58] <jimis> I was afraid of that :-(
[08:58] <jimis> anyway I understand that this workflow is not considered as mainstream for bzr
[08:58]  * jelmer waves
[08:58] <poolie> hi jelmer
[08:59] <jelmer> g'evening poolie
[08:59] <jimis> imho it should ask before switching, saying that a conflict has occured
[08:59] <vila> jimis: out of curiosity, what kind of unexpected conflict did you get ?
[09:00] <jimis> vila: I had changed a file but forgot to commit
[09:01] <jimis> so when I did "bzr switch other-branch" a conflict happened
[09:01] <jimis> and now I have to resolve it
[09:02] <vila> oh, so you wanted to commit it, not switch to the other branch carrying the change ?
[09:02] <jimis> wow, switching back created a double conflict :-o
[09:02] <vila> yeah, never a good idea to leave unresolved conflict
[09:02] <jimis> vila: no I wanted to switch, but I had forgotten to commit this particular file
[09:03] <vila> right, that what I meant, you wanted to commit *before* switching
[09:03] <jimis> that's what I should have done, yeah
[09:03] <vila> there are cases when you want to switch but still want to carry the change over
[09:03] <jimis> but bzr should have reminded me because I forgot
[09:04] <jimis> I intend to file a bug when I find some time, about missing functionality when working with checkouts
[09:04] <vila> yeah, kind of the --strict option on pull/push and... I forgot the other one send ?
[09:04] <jimis> I understand it is not a mainstream workflow, but it is the *only* possibility when working with branches sized as big as lp:gcc
[09:05] <jimis> multiple dirs is not an option then
[09:10] <Riddell> vila: where is baboun again?
[09:10] <jelmer> Riddell, under vila's desk :)
[09:10]  * Riddell books a trip on the eurostar to test his branch
[09:10] <jelmer> jam: did you have more comments on my transport-segments branch?
[09:10] <vila> Riddell: http://babune.ladeuil.net:24842
[09:10] <vila> jelmer: :)
[09:11] <jelmer> Riddell: :)
[09:11] <jam> jelmer: no, just the display thing, Riddell had already approved the branch
[09:14] <Riddell> vila: hmm, how do I build a branch again?
[09:14] <Riddell> oh, helps if I log in
[09:14] <vila> yeah, a lot ;)
[09:15] <jelmer> jam: thanks :)
[09:23] <jam> vila: do you have python-2.4 on babune?
[09:25] <Riddell> vila: I scheduled selftest-subset-natty but it says "pending - natty64.local is offline"
[09:25] <vila> Riddell: yup, the slave needs to be started, just wait a bit
[09:25] <vila> jam: probably, depends on the slave
[09:26] <jam> when did FF go to 6.0?
[09:26] <vila> jam: why would you care, we don't support anymore ?
[09:26] <jam> did they just decide to stop doing minor versions
[09:26] <jam> vila: I'm backporting something to bzr-2.1 for Lucide
[09:26] <jam> Lucid
[09:26] <jam> so we *do* care there
[09:26] <vila> then it should be available on the lucid slave
[09:27] <vila> jam: note that installing a local lucid chroot will probably be more convenient for you
[09:28] <vila> unless you just want a final test run that is
[09:30] <maxb>
[09:30] <jam> vila: yeah, pretty much
[09:30] <jam> I think everything is ok
[09:30] <jam> I just want to make sure before I submit it, and it goes boom when we release
[09:32] <vila> but.. doesn't python defaults to 2.5 on lucid already ?
[09:33] <vila>    python | 2.6.5-0ubuntu1 |         lucid | all
[09:33] <vila> yeah, 2.6 even
[09:33] <jam> vila: sure, but we are still backporting to a 2.1 series, which *is* 2.4 compatible
[09:33] <vila> I'm not even sure 2.4 is supported on lucid (imbw)
[09:34] <jam> even backporting to bzr-2.3 we should be verifying python-2.4 compatibility
[09:34] <vila> right, but I'm not sure you can use lucid to test 2.4 you may need to dig deeper
[09:34] <jam> I thought you had that set up on babune
[09:34] <jam> (since it at least are excuse for why it was ok to upgrade PQM)
[09:35] <poolie> ok this time for sure
[09:38] <jam> poolie: ? (this time you're gone for sure?)
[09:38] <poolie> this time i think i fixed bug 819910
[09:38] <jam> or this time httperror is fixed
[09:38] <poolie> it took kind of a silly long time
[09:38] <vila> poolie: \o/
[09:38] <poolie> we'll see
[09:38] <poolie> i have something a bit more realistic working locally though
[09:38] <poolie> which is a good step
[09:39] <poolie> not my best day ever
[09:39] <poolie> https://code.launchpad.net/~mbp/udd/819910-service-root/+merge/71832
[09:40] <poolie> quick review anyone?
[09:43] <jam> poolie: looking
[09:43] <vila> not at lot to look at ;) can't you add a test for that, even against a live lp ?
[09:43] <jam> poolie: str() is worrying for me, though it may be correct. And it certainly looks like something that Launchpadlib is likely to break
[09:44] <jam> since you're poking at private attributes
[09:44] <poolie> the object itself is a URI class
[09:44] <vila> and yeah, why the str() ?
[09:44] <poolie> and it defines a str as apparently the right way to get an actual string
[09:44] <jam> poolie: ok, that part works for me.
[09:44] <poolie> other launchpad client infrastructure won't accept the URI
[09:44] <poolie> as far as using the underscoe
[09:45] <poolie> there's no public equivalent
[09:45] <poolie> maybe i'll ask in #launchpad
[09:45] <jam> poolie: there's no way to ask for a branch's LP URL?
[09:45] <jam> or is it that you have to go via a round-trip that you are trying to avoid
[09:46] <jam> like lp.branches['~user/project/branch'].url seems like it should work
[09:46] <jam> but that is a round trip you might be trying to avoid
[09:46] <poolie> does that work?
[09:46] <poolie> it would be cleaner
[09:46] <poolie> i don't think this will be a performance problem
[09:46] <poolie> it's not hit all that much compared to the amount of other work this program does
[09:47] <jam> poolie: https://launchpad.net/+apidoc/beta.html#branches
[09:47] <jam> I'm thinking
[09:47] <vila> yeah, make it work, make it right, make it fast... and it doesn't work yet ;)
[09:48] <poolie> that doesn't work; it seems to expect an integer index
[09:48] <poolie> but there might bbe something similar
[09:48] <jam> poolie: so probably lp.branches.getByUniqueName(short_form).self_link
[09:48] <poolie> yep
[09:48] <poolie> or no
[09:48] <lifeless> jam: I wonder if you could have a look at https://code.launchpad.net/~lifeless/python-oops-wsgi/extraction/+merge/71839
[09:49] <lifeless> jam: its a replacement for the oops middleware we use in launchpadloggerhead
[09:49] <jam> lifeless: no diff yet, but I'll give it a minute
[09:49] <lifeless> yeah, no panic
[09:49] <lifeless> bedtime for me, 7am meeting tomorrow ;)
[09:49] <jam> lifeless: maybe you have a hint. Trying to get the LP API reference for a branch known by its short name
[09:49] <jam> (~user/project/branch)
[09:49] <poolie> yep, that's it
[09:49] <jam> trying to get something like api/1.0/...
[09:50] <poolie> thanks
[09:50] <jam> poolie: getByUniqueName is correct?
[09:50] <lifeless> jam: you want the devel api, not beta
[09:50] <jam> lifeless: this is for the udd package importer
[09:50] <lifeless> yes
[09:50] <jam> I think we found it, though.
[09:50] <lifeless> beta is -deprecated-
[09:50] <lifeless> dead dead dead
[09:51] <lifeless> for a live service under maintenance, I would definitely be using the devel version of the API
[09:51] <poolie> where is he using beta?
[09:51] <poolie> oh in the doc api
[09:52] <poolie> i don't think that's a problem unless we still have an lplib that defaults to beta
[09:52] <jam> poolie, lifeless: sure, it was just what firefox quick-linked for me when typing "apidoc"
[09:52] <poolie> oh actually if we're going to call we can just use getByUrls and simplify this a bit more
[09:53] <jam> poolie: or getByUrl, just depends what you actually have.
[09:53] <lifeless> poolie: its a problem to the extent that there is stuff in 'beta' that no longer exists, and conversely not stuff in beta that now exists.
[09:53] <lifeless> best to read the docs for the api being used.
[09:53] <poolie> i am looking at the 1.0 docs
[09:53] <poolie> i mean i don't think there's a practical problem for the importer
[09:54] <lifeless> sure
[09:54] <lifeless> I get that; I'm just trying to ensure you don't do what I've seen others do which is try a gone api and be confused when its not there but is on the web page.
[09:55] <poolie> oh it is actually gone?
[09:55] <lifeless> that particular one isn't.
[09:55] <poolie> perhaps the beta api doc pages should be removed
[09:55] <lifeless> but, in beta particularly, a great many have been deprecated and are now gone
[09:55] <lifeless> and there is a great deal in 1.0 that won't be listed on the beta page
[09:55] <lifeless> so you might miss out on just the right api for the job
[09:55] <lifeless> anyhow
[09:56] <lifeless> jam: that diff is up; I realise I haven't glued the url inclusion in the report in yet, I'll do that as a separate landing I think
[09:56] <poolie> so, jam needs to just update his bookmark or browser history
[09:57] <lifeless> more or less ;)
[09:57] <lifeless> gnight
[10:06] <poolie> jelmer: hooray
[10:07] <jelmer> poolie: glad that finally seems to be taking shape :)
[10:08] <jam> vila: so, do you have a test runner on babune that can run older versions of bzr against python-2.4?
[10:10] <vila> jam: not sure, do you know which ubuntu release supported 2.4 in the end ?
[10:11] <jam> hardy?
[10:11] <vila> hardy is 2.5 by default iirc
[10:11] <jam> vila: probably default, but still supported
[10:11] <jam> vs you can't even install python-2.4 on Lucid
[10:14] <vila> after a quick check, babune always use the default python so there is no existing job to test 2.4 explicitly, but you can probably create one pretty easily
[10:14] <vila> the hardy slave has python-2.4 installed
[10:17] <poolie> jam, ok, how about https://code.launchpad.net/~mbp/udd/819910-service-root/+merge/71832 then
[10:18] <jam> poolie: lp_call is really how you have to spell that? ugh
[10:18] <jam> but otherwise, approve
[10:18] <jam> poolie: you have a comment "Sripo of the scheme, and hostname" that should go
[10:19] <poolie> lp_call is a wrapper that handles retrying the operation etc
[10:19] <poolie> it really ought to be in lplib
[10:19] <poolie> also, for that matter, it would be nice if you could declare special forms in python for things like this
[10:20] <jam> sure
[10:21] <poolie> thanks
[10:22] <poolie> ok, i'll merge it and try it
[10:30] <jam> poolie: care to chat about my patch?
[10:30] <poolie> i'm just trying to roll this onto jubany and it seems to be breaking
[10:30] <poolie> after that sure
[10:31] <jam> sure
[10:33] <poolie> this is your get_parent_map patch?
[10:35] <jam> yes
[10:55] <poolie> jam, ok that _seems_ to be working
[10:55] <poolie> bit hard because of bug 827935
[11:00] <poolie> jam i might have some dinner now, i'll try to ping you later
[11:00] <jam> sure
[11:00] <jam> I should have lunch as well
[11:11] <jelmer> hmm, it's kindof worrying that PQM is now so slow that we can keep it busy overnight :-/
[11:21] <vila> jelmer: ... and still has a queue of 5 :-(
[11:32] <Riddell> so it this my fault or baboun's? http://babune.ladeuil.net:24842/view/debug/job/selftest-subset-natty/12/console
[11:33] <jam> Riddell: isn't everything your fault? You're the new guy, after all.
[11:33] <Riddell> it might be less my fault if I learnt to spell babune
[11:34] <vila> FATAL: Unable to delete script file /tmp/hudson2041655501694922969.sh
[11:34] <vila> shudder, long time not seen
[11:35] <vila> slave died for mysterious reason, try again, using a smaller subset may help
[11:36] <vila> making chroots real nodes and switching the old jobs to these new nodes will also address the issue but I'm not there yet...
[11:37] <vila> I've made some progress on upgrading the gentoo slave (which I couldn't do for.. months), currently rebuilding 12/258 packages...
[11:46] <vila> maxb: ping
[11:47] <vila> jam: are you planning to build th windows installers for 2.4.0 ?
[11:47] <jam> vila: at some point, though I was still dragging my feet based on what Jelmer has stated about bzr-svn (critical bug still remaining)
[11:48] <vila> huh ? Where ? When ? jelmer ?
[11:48] <vila> crap, just found the mail
[11:49] <vila> jelmer: is there a bug # for that ?
[11:51] <jam> vila: https://bugs.launchpad.net/bzr-svn/+bugs?search=Search&field.importance=Critical&field.status=New&field.status=Incomplete&field.status=Confirmed&field.status=Triaged&field.status=In+Progress&field.status=Fix+Committed ?
[11:51] <jam> 3 critical bugs
[11:52] <vila> hmpf
[11:52] <vila> madness
[11:54] <vila> jelmer: are all these bugs relevant for 2.4.0 or only for prior versions ?
[11:55] <vila> jelmer: also, are they regressions and do they affect the majority of users ?
[11:55] <jam> vila: I think you scared him away
[11:55] <vila> hehe
[11:56] <vila> *I* am the one who is scared, I know nothing scares jelmer ;)
[12:01] <jelmer> I'm lunchin' :)
[12:02] <jelmer> 826946 is the one that's worrying me
[12:02] <jelmer> 704716 is fixed so no longer an issue
[12:02] <jelmer> 485601 is fixed I think but doesn't have tests yet
[12:03] <vila> pfew, good to know (bon appétit by the way)
[12:05] <vila> jelmer: should bug #826946 block the 2.4.0 release (or even the 1.1.1 ? bzr-svn release) though ?
[12:06] <vila> HMPF (no space left on device, gentoo I hate you)
[12:06] <jelmer> vila: if it is as serious as it appears to be, it's a serious regression
[12:06] <vila> k
[12:06] <vila> jelmer: let me know how it goes
[12:15] <poolie> jam, are you back?
[12:15] <jam> poolie: yep
[12:15] <poolie> vila, is enospace connected or something else?
[12:16] <poolie> jam do you have an mp up already?
[12:16] <jam> poolie: yeah, I posted it while you were dining
[12:17] <vila> poolie: I went to /etc/fstab and found the comment I left ages ago when the same problem happened: don't use tmpfs for /var/tmp if more space is needed for emerge
[12:21] <jam> poolie: if you want to read through the merge proposal, I think I've captured everything I had to say about it. The only other bit that would-have-been-nice is to have you run some tests from Sydney
[12:21] <jam> but they take a while, and I didn't work up a script to automate all of it
[12:21] <poolie> i might do that tomorrow
[12:25] <poolie> vila, just add more swap
[12:26] <vila> poolie: or more memory or just comment out the fstab line which I did. After a reboot, the emerge is going on now
[12:27] <poolie> jam, i'm reading it
[12:27] <poolie> or tell emerge to use a different tmpfs
[12:34] <poolie> what a nice analysis
[12:34] <poolie> and what a long commit message :)
[12:43] <poolie> jam, hi
[12:43] <jam> hey
[12:43] <poolie> so the reasoning and the code make sense to me
[12:43] <poolie> i can't see any actual bugs (other than a couple of tweaks)
[12:44] <poolie> i'm not super confident that i would catch any bugs that actually were there though, cause it's moderately large
[12:44] <jam> yeah
[12:44] <poolie> so, perhaps i should just try it out a bit tomorrow
[12:44] <jam> I did manually test it against launchpad a fair amount
[12:44] <jam> Not that it exhaustively tests all possible edge cases.
[12:47] <poolie> i think landing into trunk first makes sense
[12:47] <poolie> it's really nice it doesn't need a server change
[12:48] <poolie> is there anything in particular we should talk about?
[12:54] <jam> poolie: I think I've worked through it. I mostly wanted to do the summary live-on-the-phone, but it has been done
[12:55] <poolie> weeee
[12:55] <poolie> the flood of mp mail indicates the lpapi connection is unjammed
[12:56] <poolie> i wonder if people will feel spammed
[12:56] <poolie> i guess it's a good chance to consider how much they are useful
[12:56] <jam> poolie: when don't people feel spammed by lp?
[12:56] <poolie> i don't know
[12:56] <poolie> i certainly do
[12:56] <poolie> i'd like to do built-in non-email notifications some time
[12:57] <poolie> https://bugs.launchpad.net/launchpad/+bug/827935/comments/1 might amuse
[12:57] <poolie> i should sleep
[12:59] <jam> poolie: real quick, what time would be reasonable to load the global config to check the value?
[13:00] <jam> poolie: OFFSET 313000 seems particularly telling
[13:01] <jam> (sort all 500,000 entries, and give me the middle 48)
[13:03] <poolie> yeah that offset looks to me like it's either loading them all (i'm not sure if that's what the oops means) or slicing a big collection
[13:03] <poolie> i haven't dug into it
[13:03] <poolie> how do you mean 'what time'?
[13:03] <poolie> as in, where in the code, or how long do i think it would take?
[13:03] <jam> poolie: where in the code
[13:04] <poolie> perhaps when the remotebranch or similar is constructed, make an instance and hold it?
[13:04] <jam> I don't think we want to check the config on every _get_parent_map_rpc call
[13:04] <poolie> that should make sure it's read just once
[13:04] <jam> this is in RemoteRepository
[13:04] <poolie> ok, remoterepository then
[13:04] <poolie> vila may have a more evolved idea, but putting it there should mean it's not loaded too many times in normal use, and we can move it later
[13:05] <jam> poolie: but you're thinking to cache the GlobalStack object, not just the config value
[13:05] <poolie> yes
[13:05] <jam> vila: ^^ thoughts?
[13:05] <poolie> is even reading out of that expensive?
[13:05] <poolie> it may be
[13:05] <jam> poolie: I don't think it is expensive as in, will show up in real-user-time branching all of history
[13:06] <jam> maybe in shorter term. But for all of bzr it only does 600 or so RPCs
[13:06] <jam> because of the preloading behavior
[13:06] <vila> jam,poolie: is there a global config on lp ?
[13:06] <poolie> ok, good night then
[13:07] <jam> vila: a config for all branches on lp? no
[13:07] <poolie> jam, if it's nontrivial to change i wouldn't block on it
[13:07] <jam> though you could do a locations.conf thing
[13:07] <poolie> we can always add it if it's wanted
[13:07] <vila> I suspect not (today)
[13:07] <poolie> another option would be to go off a debug flag which we know should be cheap
[13:08] <poolie> good night all
[13:09] <vila> jam: if you're talking about *local* config then the plan is that checking an option will be a bit more than checking an in-memory dict (or thrice) i.e. far lower than reading a file
[13:09] <vila> poolie: g'night
[13:10] <vila> jam: or doing an rpc call
[13:11] <jam> sure, but "plan" and what will "land in 2.4" is pretty different
[13:12] <jelmer> g'night poolie
[13:13] <vila> jam: well, stop worrying about a bug that has been there since the beginning then
[13:14] <vila> jam: *all* options requires reading one or several config files so far
[13:45] <jam> vila: which is why I've generally *avoided* having things in config files so far
[13:49] <vila> jam: then keep doing so until we get a better config or join the effort to get there ;)
[13:55]  * jelmer is generally also not too fond of adding configuration options
[13:56] <jelmer> it's often the easy answer, deferring to the user instead of thinking about what the right thing to do is
[13:56] <vila> yup, I know the trap
[13:56] <bigjools> as a KDE user, I say moar config!
[13:57] <vila> that doesn't mean nothing should be configurable
[13:58] <jelmer> bigjools: ((-:
[14:00] <vila> jelmer: the other extreme example is OSX (or more generally Apple) where you *can't* configure what you want because *they* know better
[14:04] <jelmer> vila: yeah
[14:11]  * jelmer takes a quick break
[15:11] <vila> jelmer: back ?
[15:17] <jelmer> vila: yep
[15:18] <vila> jelmer: you mentioned a fallout about my last patch around BZR_HOME, I can't find the thread anymore :-/
[15:20] <vila> jelmer: but from memory you mentioned bzr-svn tests failing because of it. I was wondering if these tests should be put into core instead
[15:20] <jelmer> vila: basically, if BZR_HOME is set then bzrlib.config.config_dir() returns unicode strings
[15:20] <vila> yeah, I remembered that
[15:20] <jelmer> vila: GMTA. lp:~jelmer/bzr/cachedir was an attempt to do just that :)
[15:23] <vila> oooh
[15:23] <vila> I don't clearly see the connection though :)
[15:24] <vila> or was it just a first step ?
[15:24] <jelmer> vila: bzr-svn falls back to storing its cache in ${config_dir()}/cache/svn if it can't find a cache directory
[15:26] <vila> ha, that's the connection, pfew, but... where does cache_dir calls config_dir ?
[15:31] <jam> jelmer: so it looks like PQM is still chewing through stuff you submitted yesterday. Not a good sign.
[15:31] <jam> http://webnumbr.com/bzr-pqm-queue-length.from%282011-08-01%29
[15:31] <jam> I do wish we had some stats on time-to-run-the-test-suite
[15:32] <jam> anyway, I'm off for now. Have a good night y'all
[15:34] <vila> g'night jam, the issues you mentioned have been briefly discussed here ;)
[15:36] <jelmer> jam: g'night
[15:36] <jelmer> jam: it does indeed look worrying :_/
[15:36] <jelmer> vila: it doesn't, but the bzr-svn equivalent of it does
[15:37] <vila> ....finally :)
[15:38] <vila> sooo, no need to search how to avoid return unicode right ?  Or are you already addressing jam's review ?
[15:43] <vila> jelmer: ^
[15:45] <jelmer> vila: Yeah, I'm addressing jam's concerns at the moment.
[15:46] <vila> k
[16:52] <jelmer> have a good evening
[17:19] <wilx> Hi, I am having problems installing/running bzr-fastimport: http://codepad.org/Uz43PkP4
[17:19] <wilx> This is the selfcheck fastimport as suggested by the README.txt output.
[17:20] <wilx> I run setup.py build and then I have copied the directory to ~/.bazaar/plugins/fastimport
[17:25] <fullermd> That's happening in bzr-git, not fastimport...
[17:38] <fullermd> Riddell: ping   (if'n you're around still)
[19:00] <wilx> fullermd: Oh, so it is not a problem with my installation steps of bzr-fastimport?
[19:00] <wilx> Shall I report it as a bug as suggested?
[19:18] <maxb> Perhaps, but not on fastimport, because the problem is an version incompatibility between bzr-git and dulwich
[19:21] <hexsprite> I _think_ i'm using a checkout, why do I get this? ERROR: Cannot switch a branch, only a checkout.
[19:22] <maxb> wilx: Actually the problem is simply: If you install dulwich 0.8.0, you must also install bzr git >= 0.6.2
[19:22] <maxb> hexsprite: Try "bzr info", see if it is as you expect. Pastebin it for more help.
[19:22] <lifeless> mgz: hi
[19:22] <hexsprite> Maybe that's not even the right command for what I want to do.  Which is to switch my working copy to be based on a new repository located in my homedir
[19:24] <mgz> hey lifeless
[19:24] <hexsprite> eg. i just merged all my changes from my feature checkout in ~/feature into ~/trunk repo. now i want to update ~/feature to be based on ~/trunk
[19:24] <lifeless> mgz: I can meet anytime, if now would be more convenient for you
[19:25] <lifeless> mgz: I just need 5 minutes to feed cats n stuff (I"ll be right back after that - let me know :P)
[19:25] <maxb> hexsprite: Please pastebin the output of "bzr info ~/feature" and "bzr info ~/trunk" - it will help explain the details of your situation
[19:28] <hexsprite> bzr info for both: http://pastebin.com/eMF1iiVD  -- note ~/main a checkout of trunk and 1079_dojo is where I'm actively working on new features
[19:28] <mgz> lifeless: I'm ready when you're back
[19:30] <hexsprite> to get 1079_dojo up to date so should i be doing: bzr switch ~/main
[19:36] <lifeless> mgz: kk
[19:36] <lifeless> mgz: do you have skype ?
[19:37] <mgz> I don't have a decent mic to connect to the computer unfortunately
[19:37] <lifeless> kk
[19:37] <lifeless> ringing in  a sec
[19:41] <jxself> http://doc.bazaar.canonical.com/latest/en/whats-new/whats-new-in-2.4.html
[19:41] <jxself> Says 2.4 was released August 8?
[19:41] <jxself> http://bazaar.canonical.com/en/ disagrees
[19:46] <meme> hi im trying to use bzr to push source code to a launchpad project but i have no idea what im doing i think im doing it right but i get bzr: ERROR: Not a branch: "/home/jadon/airscripts/.bzr/branch/": location is a repository.
[19:46] <meme>
[19:47] <meme> anyone able to help?
[19:50] <meme> anyone?
[19:50] <jxself> Relax. Be patient, young grasshopper. :)
[19:50] <beuno> meme, you're not in a branch, you're in a repostiry
[19:51] <meme> so i need to cd deeper tell im in a branch?
[19:55] <hexsprite> seems like bzr pull ~/main was what i needed
[19:57] <meme> well i did something that happend and now it does other stuff and it seems to work
[22:08] <Riddell> fullermd: pong
[22:10] <fullermd> Ohai.  Um.  Why was I pinging you?
[22:10]  * fullermd scratches his elbow.
[22:11] <fullermd> Oyah.  Are you doing much actively on qbzr?  I noticed you popping up in the commit logs somewhat lately...
[22:56] <wilx> maxb: Thanks, that's probably it. I have only bzr-git 0.6.1 installed.
[22:56] <controversial> hi
[22:57] <controversial> i've tried svn, git, and hg, and i'm using hg right now.  i'm curious about bzr though.  how does that compare against hg


[12:37] <Kopfgeldjaeger> Good night and bye
[01:37] <wasabi> Anybody around to discuss the initramfs lvm/md logic? I'm writing down how it "should" work, and would like input from somebody invested.
[01:39] <wasabi> This recent conversion to use udev... is interesting... but I wonder if it's self-defeating, and adds nothing of value.
[01:40] <ion_> I havent really read the code, either the earlier implementation or the udev implementation.
[01:40] <ion_> But using udev sounds right to me. :-)
[01:40] <wasabi> Sure, except udev is inherently disconnected from the actual init scripts that require wait conditions.
[01:41] <wasabi> Which makes it awkward to do what's expected. Wait 30 seconds for non-degraded vols, then start assembly degraded vols.
[01:41] <ion_> Well, yeah, we should migrate to Upstart. :-P
[01:42] <wasabi> I'm not sure if upstart makes this much better... and certainly not easier.
[01:42] <wasabi> The initramfs is by it's very nature sequential. You have to WAIT for the root device before moving on.
[01:46] <wasabi> Makes me wonder though if the process wouldn't be more robust if it was more straightforward... like root=md/md_device_uuid:lvm-vg/lvm_vg_uuid:lvm-lv/lvm_lv_uuid:fs/filesystem_uuid
[01:47] <wasabi> And just a simple dispatch to a set of scripts that are in charge of waiting for each component until a set timeout, and then mounting said component degraded.
[01:50] <wasabi> Hmm. maybe udev would be fine, as long as it never actually activated degraded volumes of any sort... but something else did after the timeout.
[08:27] <wolfe> :)
[08:28] <wolfe> nice, tracker is in C, unlike Beagle which is based on crap slow and buggy mono
[08:50] <Amaranth> wolfe: *cough*
[08:51] <wolfe> Amaranth: cover your mouth when you cough ;)
[08:52] <Amaranth> wolfe: mono is just fine
[08:52] <Amaranth> probably not appropriate for a long running daemon but...
[08:55] <wolfe> I haven't tried it in a year. I tried it 2 years ago, 1.5 years ago, and 1 year ago. The overall experience was terrible. Many APIs marked "completed" were incomplete(threw "Not Implemented," or were terible implemntations)
[08:55] <ion_> I dont find mono especially slow or buggy either. The language of choice probably isnt the most significant one of the things that make tracker better than beagle. :-)
[08:55] <wolfe> I didn't say language of choice, I said mono
[08:55] <wolfe> mono is just the VM
[08:56] <wolfe> now, oh boy, if you want to discuss all the flws in Mono's crapp C# implementation
[08:56] <ion_> There isnt much choice of the VM if your language of choice is C# and you want it to run on Linux.
[08:57] <wolfe> ion_: right, but for those of us who are cross platform programmers, Mono and Mono/C# is a hunk o junk
[08:57] <wolfe> which is why I use Python + wxWidgets
[08:58] <wolfe> ion_: Mono's purpose is to run windows apps on linux, pulling developers more towards linux. That isn't happening, the original purpose of mono is non existant
[08:58] <wolfe> they've complete .NET 1.1 support(supposedly, though it is probably non conforming like always), they're working on 2.0 support.. while WinFX(3.0) has been out for a really long time
[09:00] <wolfe> ion_: long as tracker is nice a fast.. and doesn't use 100+MB of memory running idle, I'm happy.
[09:01] <ion_> I dont even notice tracker, and this box isnt exactly high-end. (P3 500MHz, 384 MiB RAM)
[09:01] <wolfe> ion_: what about when it runs ;)
[09:01] <wolfe> people are complaining about when tracker does its thing, it is noticable.
[09:02] <wolfe> though when it is idle again, everything is fine.
[09:02] <ion_> Well, its extracting metadata from a video just now and i wouldnt have known it without taking a look at the process list.
[09:02] <wolfe> guess the people who complain have 500GB in porn ;)
[09:03] <ion_> (I do have indexing speed: 20 (slower) and minimize memory usage (slower indexing) set in Tracker preferences.)
[09:04] <wolfe> o
[09:04] <wolfe> well that would do it I guess :)
[09:04] <wolfe> ion_: say..
[09:04] <wolfe> ion_: do you notice any tools to join Ubuntu to a windows network?
[09:04] <wolfe> there was supposed to be a tool someone is working on.
[09:05] <wolfe> ubuntu specific, can't remember who it was.
[09:05] <ion_> This discussion is very offtopic, it probably should be continued on another channel. Its been years since i used samba.
[09:05] <wolfe> this discussion is devel related ;)
[09:05] <wolfe> the person said it was going to be included /maybe/ in this coming release.
[09:20] <Tonio_> hi
[09:45] <saispo> BenC: ping ? :)
[09:45] <saispo> hi seb128
[09:47] <seb128> lu saispo
[10:16] <seb128> ogra: new gnome-screensaver available
[10:18] <Hobbsee> good morning seb128
[10:18] <ogra> *yawn*
[10:18] <ogra> morning
[10:18] <ogra> seb128, thanks
[10:18] <seb128> hey Hobbsee
[10:19] <Hobbsee> hi ogra
[10:29] <tepsipakki> does someone know what's up with ubuntu.com-services (lp.net et al)?
[10:30] <elmo> tepsipakki: works for me - what's the problem you're seeing?
[10:30] <ogra> LP works fine here
[10:30] <tepsipakki> elmo: either they fail to open completely or partially
[10:30] <tepsipakki> connecting from hut.fi
[10:31] <tepsipakki> could be something here, too..
[10:31] <tepsipakki> rest of the world seems to work though :)
[10:31] <elmo> tepsipakki: try mtr-ing to launchpad.net and lithium.canonical.com, if you can still reproduce it
[10:31] <elmo> tepsipakki: if there's anything interesting in the first, pastebin both of them
[10:33] <tepsipakki> traceroute to l.c.c gets stuck after byrd.canonical.com
[10:36] <elmo> tepsipakki: k, that doesn't really matter
[10:37] <tepsipakki> now lp.net works again
[10:37] <tepsipakki> mtr/traceroute always got through
[10:38] <tepsipakki> maybe some db backend is busy?
[10:38] <maswan> elmo: we're getting errors to security.u.c (connection timed out)
[10:42] <Nicke> tepsipakki: I get connection timeouts now and then to LP too, fwiw
[10:43] <maswan> elmo: never mind, back again
[10:46] <elmo> seems like it might be telia
[10:46] <elmo> or telia vs. l3 anyway
[10:57] <maswan> elmo: telia might have had a power glitch in some parts, some machines we have in a telia hosting facility in denmark rebooted spontaneously. I guess if they have some routers/foo in there too, it might cause issues.
[10:57] <maswan> (wild guessing)
[10:58] <Nicke> (my traceroutes to lp seems to have problems with level 3 and Adapt Services.. not going through Telia at all)
[10:59] <maswan> well, we get transit from telia, so we'd be hit by that anyway. :)
[11:00] <Nicke> ah, true
[11:15] <maswan> elmo: hm. I'm getting issues to s.u.c/<IP_ADDRESS> again now
[12:03] <soren> How does it make sense to have a package listed as both Replaces and Recommends?
[12:03] <Hobbsee> uh....
[12:04] <elmo> soren: assuming the replaces is unversioned, it doesn't
[12:04] <elmo> maswan: yeah, I still can't see anything concrete unfortunately
[12:04] <soren> elmo: It is.
[12:04] <soren> elmo: Alright, just as I thought, then. Thanks.
[12:04] <elmo> err, well, that's not actually strictly true
[12:05] <elmo> soren: sorry, it's actually fine, I can replace *some* files in 'foo' (requires Replaces),  and still Recommend it
[12:06] <elmo> (s/strictly//, s/$/ at all/)
[12:06] <StevenK> s/strictly\( true\)$/\1 at all/ :-P
[12:13] <Kmos> bz-gtk 0.90 is out at debian =)
[12:13] <Kmos> ubuntu gutsy has 0.18.0
[12:13] <Kmos> lol
[12:14] <StevenK> And we are in UVF.
[12:14] <seb128> Kmos: what is funny?
[12:16] <Kmos> *bzr-gtk
[12:17] <Kmos> seb128: nothing.. just UVF is ending, i've some requests there and nothing was done yet, so I won't file another sync request for it
[12:18] <Hobbsee> uvf *isnt* ending for gutsy.  it will never end.  i told you this before, and you said you understood that.
[12:19] <Hobbsee> and your sync requests lately have been contradicting themselves, so in the interest of getting things done, they've been getting ignored.
[12:19] <Kmos> Hobbsee: but I won't file bug reports
[12:19] <Kmos> :)
[12:19] <Hobbsee> good.
[12:19] <Hobbsee> then i wont have to work out WTF to say.
[12:19] <Kmos> Hobbsee: only ddclient, and i've already explained.. and the others? =)
[12:19] <Hobbsee> you explained once, then contradicted yourself again.
[12:19] <Hobbsee> i gave up, at that point.
[12:20] <Kmos> ok, the problem is for ubuntu, isn't mine.. i published it at getdeb.net and people are downloading =)
[12:20] <Kmos> I'm credible for one things, but not for others
[12:20] <Kmos> that's the point.
[12:22] <Kmos> Hobbsee: that's your point of view =) I respect.
[12:22] <Hobbsee> i would have expected any repository maintainer to know what they were doing with their packages, before uploading them.
[12:23] <Hobbsee> if they prove that they dont, then clearly the quality of their packages is debatable.
[12:23] <seb128> Kmos: shipping non official packages is usually not a good idea
[12:23] <Hobbsee> seb128: ship?  who said anything about shipping?
[12:23] <RAOF> How exactly can you ship non-official packages anyway :)
[12:23] <Kmos> seb128: it's the only way I found to publish my ddclient package, that's i'm part of uptream
[12:23] <Hobbsee> seb128: this is about a sync/merge request of ddclient, whihc kmos contradicted himself in twice, so he turned to getdeb because it didnt get accepted.
[12:24] <Kmos> Hobbsee: I know the owner of getdeb, it's also from Portugal :)
[12:24] <Hobbsee> Kmos: if you're part of upstream, you should know WTF you're doing, including w.r.t syncs and merges, and not contradict yourself in bug reports about the package.
[12:24] <Kmos> Hobbsee: i've done an typo "is" - "isn't"
[12:25] <Hobbsee> yet you never corrected that in the bug report - or at least not when we read it.
[12:25] <Kmos> Hobbsee: I don't know what i'm doing.. you know =)
[12:25] <Hobbsee> which was a few days ago
[12:25] <Kmos> Hobbsee: check it again
[12:25] <seb128> Hobbsee: I probably didn't understand what getdeb.net is
[12:25] <Hobbsee> Kmos: i have better things to do with my time than read a sync or merge request which probably now contradicts itself a third time.
[12:26] <seb128> Hobbsee: I though somebody uploaded packages there
[12:26] <Hobbsee> seb128: ahhh
[12:26] <Kmos> bug 132694
[12:26] <ubotu> Launchpad bug 132694 in ddclient "Please merge ddclient (3.7.3-2) from Debian unstable" [Undecided,Incomplete]  https://launchpad.net/bugs/132694
[12:27] <Kmos> Hobbsee: i like to change comments and do typos and I can't :(
[12:27] <Kmos> *when
[12:28] <Kmos> I like to change comments when I do typos and I can't :(
[12:28] <seb128> Kmos: you should spend some time writting your bugs to include required informations
[12:29] <seb128> Kmos: that merge bug goes on pages and you still didn't describe what are the Ubuntu changes and why you think they can be dropped
[12:29] <Hobbsee> Kmos: what really worries me here is that you've had 2 blocks of contradictions in that bug report already, and you dont quickly change them to be right
[12:29] <seb128> "upstream don't apply it" is not a reason
[12:29] <Hobbsee> therefore, i've got absolutly NO confidence that the rest of your changes are right, as you clearly either a) dont have a clue WTF you're doing with the package or b) dont care enough to actually file a decent report with the required information, which you've been told about before.
[12:30] <Kmos> seb128: i've explained it.. upstream didn't apply it, because dyndns.com as talked to upstream to change it. only mention dyndns.com when we talk about the service, not about the core functions. like members.dyndns.org is the valid to update IP, and not dyndns.com
[12:30] <Kmos> this talk happen after my last ddclient package releases
[12:30] <Kmos> and before i enter to upstream as a member
[12:30] <Hobbsee> so, i cant, nor any in the MOTU-UVF team, in good conscience, approve that bug, because we know that it's likely wrong, and that we dont trust the filer to have gotten it right.
[12:30] <seb128> Kmos: well, your bug still doesn't list the changes with the rational, what you just explained is not clear
[12:30] <Kmos> so debian hadn't updated their package for long time
[12:31] <Hobbsee> it's as simple as that.
[12:31] <Kmos> Hobbsee: and you trust my other syncs? my last ddclient packages i've done
[12:31] <Kmos> that's contradiction
[12:31] <Kmos> lol
[12:31] <Kmos> so that's why I won't file bug syncs again
[12:31] <seb128> Kmos: what about "checked_ssl_load"?
[12:31] <Kmos> seb128: that's applied upstream
[12:32] <Kmos> and it's on v3.7.3
[12:32] <Kmos> everything is correct with the package, the only thing I need someone to check is the changelog, because that's merged
[12:32] <Kmos> I've also sent a lot of fixes to debian maintainer
[12:32] <Kmos> in hope he updates the package, that don't happened these weeks
[12:32] <seb128> Kmos: you should try to make a clear description directlu
[12:32] <seb128> directly
[12:33] <seb128> the issue with this bug is that the comments go on pages
[12:33] <Kmos> seb128: check last comment
[12:34] <Kmos> i took my debian/changelog
[12:35] <seb128> Kmos: so the package should be synced on debian or merged?
[12:36] <Kmos> merged from debian
[12:36] <Kmos> i've changed the title of the bug
[12:36] <Kmos> I think the debian maintainer has applied all of my changes, but not :(
[12:36] <Kmos> that's why I made it wrong first time
[12:37] <Kmos> but after changed to merge
[12:38] <Kmos> http://changelogs.ubuntu.com/changelogs/pool/universe/d/ddclient/ddclient_3.7.1-0ubuntu3/changelog
[12:38] <Kmos> as you can see here, I've done two packages of it
[12:39] <Kmos> * Added a patch to change dyndns.org to dyndns.com (LP: #106753)
[12:39] <Kmos> this was refused from dyndns.com service, we talked to them
[12:39] <Kmos>   * Re-add debian/patches/checked_ssl_load.diff which got dropped accidently in
[12:39] <Kmos>     last upload.
[12:39] <Kmos> this one is applied upstream
[12:39] <Kmos> like most of them
[12:40] <seb128> hum
[12:40] <seb128> merged = ubuntu changes need to applied
[12:40] <seb128> synced = use the debian version
[12:40] <Kmos> exactly
[12:40] <seb128> are we sure it needs to be merged?
[12:40] <seb128> which means you take the debian package
[12:40] <seb128> and what needs to be changed then?
[12:40] <Kmos> and applied the ubuntu changes
[12:40] <Kmos> * debian/rules: call dh_installinit with -u multiuser (Teardown spec)
[12:40] <Kmos> this one
[12:41] <Kmos> for example
[12:41] <Kmos> and ubuntu maintainer hadn't changed dyndns.com when talking about the service, inside debian/
[12:41] <Kmos> i've already mailed with, but with no answer until today
[12:41] <seb128> you should attach the debdiff of the merge to the bug then
[12:42] <Kmos> so I do the debdiff from debian unstable and my changed one
[12:43] <seb128> yes
[12:43] <Kmos> i'll do it now
[12:43] <Kmos> thanks
[12:44] <Kmos> seb128: it's attached to the bug
[01:13] <tuxcrafte1> how can i disable the new aiglx in gusty its causing errors on my system
[01:13] <thom> tuxcrafte1: #ubuntu for help
[01:14] <tuxcrafte1> thom: also for testing of gusty?
[01:15] <thom> #ubuntu+1 alternatively
[01:23] <Hobbsee> Kmos: lets put it this way - i gave you the benefit of the doubt in most cases, because i didnt know you were this bad at sync requests.  and i also checked the changes, to check that the ubuntu changes really were all gone.  however, now we're later in the cycle, and i've got other stuff i want to do.
[01:23] <Hobbsee> Kmos: so it either needs to be right, or not happen.
[01:24] <Hobbsee> seb128: if you could deal with that bug, that'd be appreciated.  i'd not want to put it up for the sponsorship review queue / motu-uvf queue again - we've already tried to figure it multiple times, adn given up.
[01:25] <seb128> Hobbsee: will do
[01:25] <Hobbsee> seb128: thanks
[01:27] <Kmos> Hobbsee: benefit of the doubt.. lol.. Ok
[01:27] <Hobbsee> Kmos: as in, trusting that the changes you listed that were also listed in debian were actually correct, that there werent any silently dropped, that werent in the original changelogs.
[01:27] <Kmos> Hobbsee: and the powertop sync I've request, you acked it.. it's the benefit of doubt
[01:28] <Kmos> and the others
[01:28] <Kmos> ok
[01:28] <Hobbsee> Kmos: yeah, but i have a clue about powertop.
[01:28] <Kmos> so what's wrong with it ?
[01:29] <Hobbsee> Kmos: but for stuff that i dont know a lot about, it's a different story, it's confusing, and i dont have the motivation, time, or possibly skill to go thru every fine-toothed change.
[01:29] <Hobbsee> also, i dont recall powertop having any ubuntu changes
[01:30] <Kmos> Hobbsee: exactly, so you can't say "i didnt know you were this bad at sync requests"
[01:30] <Hobbsee> sure i can.  i knew that some of them were right, but i didnt know that some of them were that badly, and that confusingly wrong.
[01:31] <Kmos> ok
[01:31] <Kmos> that's your opinion, but a lot of them are synced and working fine
[01:31] <Kmos> sabdfl: hi =)
[01:31] <Hobbsee> previously, i'd known that some of yours were right, and some were wrong - but i didnt know they were that badly wrong.
[01:31] <Hobbsee> greetings, sabdfl
[01:31] <sabdfl> hey Kmos
[01:31] <sabdfl> Hobbsee: :-)
[01:32] <Kmos> Hobbsee: so, you're good, i'm not.. lol
[01:32] <Kmos> that's ok =)
[01:32] <Hobbsee> Kmos: i never said quite that.
[01:33] <Kmos> Hobbsee: i need to work, conversation won't take us to any side.
[01:33] <Hobbsee> ok
[01:33] <Hobbsee> enjoy
[01:35] <cromo> hi. I have some problems with qc-usb-messenger kernel module compilation. For some reason it segfaults (gcc: Internal error: Segmentation fault (program cc1)). Using feisty here and I am wonderign what's wrong. I tried compiling this module on other machine (archlinux, gcc 4.2.1) and it worked just fine.
[01:35] <cromo> so I wonder if something is broken in feisty's gcc?
[01:36] <cromo> basically, it's enough to download http://home.mag.cx/messenger/source/qc-usb-messenger-1.6.tar.gz package, untar it and exec a typical 'make all' in the directory
[01:37] <cromo> anyone can please confirm that he gets the error?
[02:55] <_StefanS_> infinity: hey, can you please re-upload kdesdk for lpia ? It compiles without changes now.
[02:55] <Riddell> _StefanS_: it's called "give back" since nothing needs to be uploaded
[02:55] <_StefanS_> right gotcha.
[03:18] <asac> our fontconfig adds FC_ANY_METRICS to fontconfig.h (while debian doesn't) ... who might know about this patch?
[03:18] <asac> doko_: ^^^
[03:20] <doko_> asac: iwj did write that. we have to make sure that we don't use DejaVu as a substitute font for missing fonts for documents becuase it is not metrics compatible
[03:20] <asac> doko_: so debian never had it?
[03:20] <doko_> asac: no
[03:21] <asac> thats interesting because the patch for firefox i have has a debian bug ... let me see
[03:59] <Mirv> mjg59: do you happen to have any chance to put any input to bug #86666 ? in March, you said that "I'll see if I can determine a test case for this that will give us some more feedback", and there's now both manufacturer-supplied and copied from /sys/ BIOS ROM you asked for.
[03:59] <ubotu> Launchpad bug 86666 in usplash "Feisty crashes after grub, before boot process, if usplash is enabled (amd64)" [High,Triaged]  https://launchpad.net/bugs/86666
[04:00] <Mirv> not that I'd need the fix (vga=792 works just fine), but it seems to affect quite a lot Radeon X800 users (with an occasional mention about possible similar problems with some NVIDIAs)
[04:20] <mjg59> Mirv: I've added an update
[04:29] <\sh> jono, ping...very important matters arised
[04:30] <\sh> jono, please in private or jabber (jid<EMAIL_ADDRESS>[05:10] <bddebian> Heya
[05:24] <tkamppeter> Hi, I need some help
[05:24] <tkamppeter> I am packaging CUPS with an alternative USB backend, trying to surround kernel (or hardware) bugs
[05:25] <tkamppeter> The alternative backend includes /opt/lsb-buildenv-ia32/usr/include/linux/usb_ch9.h
[05:25] <tkamppeter> Sorry, i cannot grab other than the wrong thing, let me search
[05:25] <tkamppeter> It needs /usr/src/linux-headers-2.6.17-10/include/linux/usb_ch9.h
[05:25] <mjg59> That's weird. Where have my font and desktop effect preferences gone?
[05:26] <tkamppeter> On my Gutsy linux-headers-2.6.17-10 is installed, and simply requiring linux-headers pulls linux-headers-2.6.22-10 which does not contain mentioned file. What do I have to do?
[05:27] <mjg59> tkamppeter: If it needs to include anything from /usr/src, it's broken
[05:27] <mjg59> Try /usr/include/linux/usb/ch9.h
[05:28] <tkamppeter> In reality it only includes linux/usb_ch9.h, but on my system I have found this file only in /usr/src.
[05:28] <mjg59> Oh. Change it to linux/usb/ch_9.h
[05:29] <tkamppeter> Thank you, will try it.
[05:29] <mjg59> seb128: Any idea why gnome-control-center doesn't seem to be building the font preferences?
[05:29] <tkamppeter> File is in linux-libc-dev
[05:29] <mjg59> tkamppeter: Yes
[05:30] <seb128> mjg59: what do you mean? it's a tab in the appearance capplet now
[05:30] <mjg59> seb128: Ah!
[05:30] <mjg59> seb128: That's not especially obvious :)
[05:30] <seb128> right ;)
[05:31] <mjg59> seb128: It also seems to have lost the DPI setting
[05:31] <seb128> no, details
[05:31] <mjg59> Ah, yes, I'm blind
[05:32] <mjg59> Hm. We really need to fix X's DPI handling.
[05:34] <iwj> doko_: Would you be able to help me with some pointers in the glibc build system ?  I'm trying to wrap ldconfig with a script but my rules fragment isn't being executed.
[05:34] <lamont> seb128: please don't do like shared-mime-info 0.22-2 did and break ia64, mk?
[05:34] <iwj> doko_: I was hoping you would be able to tell me where it should go - since it takes about 4h to run the build system even with a fully primed ccache.
[05:46] <tkamppeter> jg59, thank you very much. Now I succeeded also to build it under pbuilder. The contributor of the code is probably not much experienced with packaging for distros.
[06:34] <iwj> Scary.  I've just taught autopkgtest how to file bugs in LP and turned it on.
[06:40] <mjg59> jamiemcc: Any joy with the tracker issue?
[06:40] <mjg59> I've just pulled a kernel source tree into an otherwise entirely empty home directory, and tracker is eating all my disk i/o
[06:40] <jamiemcc> mjg: yeah we are working on tuning it
[06:40] <calc> who processes MIRs right now?
[06:41] <calc> iwj: iirc i hear you were doing them?
[06:41] <mjg59> jamiemcc: It's really not in a releasable state right now :(
[06:41] <jamiemcc> mjg59: we will do index merging as updating a massive index is very painful
[06:41] <mjg59> jamiemcc: Ok, sounds promising
[06:41] <jamiemcc> mjg59: should be fixed for tribe 6
[06:41] <mjg59> Cool
[06:41] <jamiemcc> there may be corner cases but hopefully that will crop up in testing
[06:43] <jamiemcc> mjg59: we recommend setting source dirs to be crawled instead of watched
[06:43] <jamiemcc> that way it wont slow down check outs or compiling
[06:44] <mjg59> jamiemcc: Hm.
[06:44] <mjg59> jamiemcc: That's a pretty negative user experience.
[06:44] <jamiemcc> yeah but only for devs
[06:44] <jamiemcc> its why we adding the crawl directory setting to tracker
[06:44] <mjg59> Who are a major part of our userbase
[06:44] <jamiemcc> yeah I know
[06:44] <iwj> calc: Yep.
[06:45] <jamiemcc> mjg59: the best we can do is make it less slow in devs
[06:45] <jamiemcc> we cant make it as fast as
[06:45] <mjg59> jamiemcc: The alternative is to heuristically mark directories as source directories
[06:45] <iwj> calc: If you have packages you'd particularly like approved do feel free to mention them.
[06:45] <mjg59> Rather than asking people to do it manually
[06:45] <calc> iwj: have you had a chance to look at libvigraimpex and libsvg
[06:45] <iwj> I mean, to mention them now.
[06:45] <calc> iwj: ok
[06:46] <jamiemcc> mjg59: we will be using idle disk priority which will help a lot too
[06:46] <iwj> calc: They don't seem to be mentioned on https://wiki.ubuntu.com/UbuntuMainInclusionQueue
[06:46] <jamiemcc> idle mode waits for a grace period of no disk access before allowing tracker to use disk
[06:47] <iwj> calc: Ought they be ?  I can review them and add them if you like.
[06:47] <iwj> I see MainInclusionReportLibsvg and presumably a similar page for the other.
[06:47] <calc> iwj: doh, i forgot to add them there i guess :\ yea please do
[06:47] <jamiemcc> mjg59: you can set idle to trackerd using ionice to see if it makes a difference in your case?
[06:47] <iwj> calc: NP.
[06:48] <iwj> calc: When would you like a response by ?
[06:48] <calc> end of the week if possible, i want to do the next ooo build with them which i expect to probably do around that time
[06:48] <mjg59> jamiemcc: I'll give it a go next time I trigger it
[06:48] <calc> iwj: between approval and promotion doesn't take long does it?
[06:49] <mjg59> (I just killed it for the moment - I only have a few minutes to get this patch finished)
[06:49] <jamiemcc> mjg59: ok next version will try and set idle automatically
[06:49] <calc> iwj: assuming the packages are ok to be included i would like them to be in main (if possible) by the end of the week
[06:49] <iwj> calc: Not hugely but it depends on someone having an archive day.
[06:49] <calc> iwj: oh ok
[06:49] <iwj> OK.  I should look at them soon then./
[06:49] <iwj> Thanks.
[06:50] <calc> thank you 8)
[06:52] <alex-weej> asac: you got time for some VPN lovin'?
[07:02] <calc> iwj: did you put them under approved or did i somehow put them there by mistake? (on the wiki)
[07:03] <calc> iwj: i thought i added them to the area to be reviewed but it showed up under approved section, lol
[07:04] <zyga> anyone on gutsy around?
[07:04] <iwj> I haven't touched them yet ...
[07:04] <calc> iwj: ok i screwed up where i stuck it then, i just fixed it
[07:04] <zyga> could someone confirm that /usr/share/command-not-found/programs.d still exists?
[07:05] <zyga> (with up-to-date command-not-found and command-not-found-data packages)
[07:15] <infinity> calc, iwj: If any promotions are time sensitive, don't be afraid to ping me to have an "archive moment", rather than waiting for someone to take an archive day.
[07:21] <iwj> infinity: Noted.
[07:22] <asac> alex-weej: nope
[07:26] <alex-weej> asac: ok. can you consider making the bugs critical for gutsy release?
[07:27] <asac> alex-weej: yes give me bug id
[07:27] <alex-weej> asac: https://bugs.launchpad.net/bugs/134547
[07:27] <ubotu> Launchpad bug 134547 in network-manager-pptp "NetworkManager PPTP VPN does not work; bad pptp plugin" [Undecided,New]
[07:27] <alex-weej> asac: and, to a lesser extent, the bad DNS = crash one: https://bugs.launchpad.net/bugs/134544
[07:27] <ubotu> Launchpad bug 134544 in network-manager "NetworkManager aborts when attempting to connect to PPTP VPN server with bogus host name" [Undecided,New]
[07:28] <asac> alex-weej: bug 134544 must be a duplicate
[07:28] <alex-weej> asac: how so?
[07:28] <asac> ah sorry :)
[07:28] <asac> lost the context
[07:29] <alex-weej> (i split the old bug up into two new ones, the vpnc problem seemed to disappear)
[07:31] <asac> right
[07:46] <iwj> calc: Why does oo.o want a computer vision library ?
[07:50] <iwj> calc: Hmm.  Looks like it's just using it for image processing.
[07:56] <iwj> calc: Both approved.
[08:28] <calc> iwj: thanks :)
[08:38] <iwj> calc: NP.  Goodnight :-).
[08:49] <geser> Riddell: Hi, are you responsible for UVF exceptions for packages in main?
[08:52] <Riddell> geser: yes
[08:54] <geser> what's your opinion on bug #134684? the link list of fixed upstream problems looks interesting but on the other side boost has some rdepends which would need rebuilding.
[08:54] <ubotu> Launchpad bug 134684 in boost "Upgrade to Version 1.34.1" [Wishlist,New]  https://launchpad.net/bugs/134684
[08:56] <Riddell> geser: seems like a good idea if someone wants to test all the rdepends
[09:00] <geser> Riddell: ok, will test in my PPA if upgrading boost is possible
[10:12] <Riddell> geser: that's a good idea
[10:12] <soren> MikeDK: /win 10
[10:12] <soren> Whoops
[10:13] <Riddell> infinity: do you have any opinion on having opensync 0.30 packaged?
[10:15] <infinity> Riddell: None whatsoever...
[10:20] <Riddell> oh jings, why do I always mix you two up on irc
[10:20] <Riddell> lifeless: do you have any opinion on having opensync 0.30 packaged?
[10:27] <moquist> Any postgresql-savvy folks in here? I'm working on the Moodle package and could use some advice about best practices.
[10:33] <mathiaz> moquist: pitti is the man to talk to. But he's on vacation for two weeks.
[10:33] <lifeless> Riddell: yes
[10:34] <lifeless> Riddell: I think its a great idea; its on my todo list as upstream have apparently unbroken the soname issue.
[10:34] <lifeless> Riddell: if someone wants to throw a patch my way I'd be extremely happy.
[10:36] <Riddell> lifeless: what was the soname issue?
[10:37] <azeem> using scons
[10:37] <azeem> lifeless: though note that upstream discourages any use and packaging of opensync before 0.40 apparently
[10:37] <lifeless> IIRC - its a year back now - they broke the ABI comprehensively; didn't bump the soname, and plugins were hardcoded back. Or something. azeem was dealing directly with it.
[10:37] <azeem> it's really messed up there
[10:38] <lifeless> azeem: more and more I get the impression they don't want users.
[10:38] <azeem> apparently opensuse 10.3 (or whatever is next) won't ship it
[10:39] <azeem> or well, will ship 0.2x or something
[10:39] <azeem> but OTOH, maybe 0.32 is already heaps better than what is in the ubuntu/debian archive now
[10:39] <moquist> mathiaz: thx
[10:39] <bddebian> scons... Ugh
[10:40] <azeem> they switched to scons and had no clue that a library should have a soname - neither had scons
[10:40] <lifeless> I'm hearing that 0.3x is significantly better that 0.19
[10:41] <azeem> lifeless: I'm not sure they guarentee not breaking the file/archive format till 0.40 though
[10:41] <azeem> Riddell/lifeless: is this for gutsy, or just in general?
[10:41] <lifeless> gutsy IVF is tomorrow I think
[10:42] <lifeless> s/I/U/
[10:42] <lifeless> IVF would be rather different ;) ;)
[10:42] <Riddell> azeem: for gutsy
[10:42] <azeem> ok
[10:42] <lifeless> azeem: this is nuts; bzr has migrated file format several times, lossless upgrades. It's a solved problem.
[10:42] <Riddell> azeem: fancy packaging it?
[10:43] <Riddell> bddebian: it was
[10:43] <lifeless> bddebian: perhaps I'm thinking universe ?
[10:43] <bddebian> Us too
[10:43] <Riddell> new package deadline is thursday
[10:43] <bddebian> Aye
[10:43] <azeem> well, there's exceptions
[10:43] <azeem> no?
[10:43] <bddebian> Yes
[10:43] <lifeless> Riddell: meep; time for the UVF exception to roll out then -bzr 0.90 releases today
[10:44] <azeem> lifeless: alternatively, we could roll it out in debian experimental, get minimal testing, and then ask for UVFe sync
[10:44] <Riddell> lifeless: whoever is packaging it need to get me the changelog and convince me it's stable
[10:44] <Riddell> or more stable than what went before
[10:44] <azeem> 22:36 < azeem> lifeless: though note that upstream discourages any use and packaging of opensync before 0.40 apparently
[10:44] <azeem> Riddell: heh
[10:45] <lifeless> Riddell: of bzr, or of opensync ?
[10:45] <lifeless> Riddell: cause bzr is one of the most stable things I've ever seen.
[10:45] <Riddell> lifeless: both I guess.  bzr is a work of genius so I don't expect any problems
[10:46] <azeem> maybe we should check on the plugin state, last I checked about only the file-sync plugin was ported to 0.3x
[10:46] <azeem> s/state/status/
[10:48] <lifeless> http://svn.opensync.org/tags/plugins-0.32/
[10:48] <lifeless> looks promising; assuming its realistic
[10:49] <Riddell> danimo: any information on that?
[10:50] <danimo> Riddell: yes, it seems the enterprise branch guys changed the API without bumping the interface version
[10:50] <danimo> Riddell: till will look into it asap
[10:50] <azeem> lifeless: well, better than http://svn.opensync.org/tags/plugins-0.31/
[10:50] <danimo> Riddell: so it seems another repackaging (and relinking of all dependant packages) is due in one or two days
[10:50] <danimo> Riddell: sorry
[10:51] <Riddell> danimo: I was asking about opensync plugins
[10:51] <danimo> Riddell: oh, no, all I know is that 0.30 is not s/c
[10:51] <danimo> Riddell: tokoe knows mor
[10:51] <danimo> e
[10:51] <danimo> Riddell: suse already has new packages via OSBS
[10:55] <azeem> lifeless: 22:50 < abtronic> azeem: I don't think all of those are working yet
[10:55] <lifeless> I guess its a case of suck it up and see
[10:56] <azeem> btw, is there any indication how many users current opensync has on ubuntu?
[10:56] <lifeless> popcon
[10:56] <lifeless> http://popcon.ubuntu.com/
[10:56] <azeem> I have the feeling we're going annoy quite some of them if we'd ship 0.32 in gutsy
[10:57] <lifeless> http://popcon.ubuntu.com/by_vote
[10:57] <lifeless> meh sorry
[10:57] <lifeless> 270
[10:58] <lifeless> 75811 would seem to be the number of popcon users, or thereabouts
[10:58] <azeem> ok
[10:58] <lifeless> so we know there are millions of users
[10:59] <lifeless> millions / 100000 ~= some multiple of 10's expansion
[10:59] <lifeless> so say a few thousand opensync users.
[10:59] <lifeless> hows that for rough and ready stats
[11:01] <ion_> Im going to use opensync as soon as i get around to purchasing a data cable for my phone. :-)
[11:01] <lifeless> not if they never release a version with the plugins working again
[11:04] <azeem> get this: Apparently Sun put one of their engineers on the task of writing yet another gtk opensync frontend
[11:04] <lifeless> oh yay
[11:23] <ion_> iwj: Removing linux-ubuntu-modules-2.6.22-9-generic ..., update-initramfs: Generating /boot/initrd.img-2.6.22-9-generic, Purging configuration files for linux-ubuntu-modules-2.6.22-9-generic ..., update-initramfs: Generating /boot/initrd.img-2.6.22-9-generic
[11:23] <ion_> iwj: Could triggers be used to prevent this, too?
[11:25] <ion_> iwj: Perhaps make each linux-image-$REL package provide the trigger for initrd.img-$REL or something like that...
[12:08] <superm1_> Riddell, after the update cleared the buildds in -proposed yesterday, I received some info regarding a few reports of issues with the migration, and cherry picked a few patches from svn that take care of them.  Could you release the two updates (edgy and feisty -proposed) again?
[12:16] <superm1_> or infinity cjwatson mdz Keybuk ^