[00:57] <ohsix> cjwatson: thanks
[01:09] <ohsix> cjwatson: does zsync work well with those images? (<10% transferred between versions)
[01:11] <charlie-tca> ohsix: yes, it does. I use it everyday to keep my copies updated
[01:11] <cjwatson> I don't have measurements myself, but I don't see why it wouldn't, certainly
[01:12] <ohsix> neat
[01:12] <cjwatson> one of the reasons we use squashfs is that it's rsync-friendly, which should hold for zsync too
[01:12] <ohsix> do the aufs update options in update-manager actually work?
[01:13] <maco> aufs still exists?
[01:13] <ohsix> well i never tried it, but i've seen it there; and it'd be cool if it did
[01:13] <cjwatson> aufs still exists
[01:13] <maco> i remember that it did....i remember talk of it on the mailing list
[01:13] <maco> but i thought the upstream kernel rejected it?
[01:14] <maco> cjwatson: is it sauce? or did upstream change minds?
[01:14] <cjwatson> there's no other option for our live CDs right now
[01:14] <cjwatson> I don't know what the state of the update-manager work is; mvo had it working at one point but I don't know if that's current or what the provisos were
[01:14] <cjwatson> we're looking at a similar facility using btrfs
[01:15] <ohsix> man an fs that can do snapshots and jump back to them would be great :D
[01:16] <ohsix> afaik you can do it with lvm but it's convoluted and expensive
[01:16] <cjwatson> unfortunately the alpha-2 installer wasn't quite up to the required installation bits, but alpha-3 should be; I don't know how far mvo's got with the u-m side
[01:16] <maco> ohsix: https://lists.ubuntu.com/archives/ubuntu-devel/2009-March/027747.html
[01:18] <ohsix> maco: thanks
[01:20] <maco> cjwatson: this is what i was thinking of https://lists.ubuntu.com/archives/ubuntu-devel/2010-June/030952.html
[01:23] <cjwatson> yes, there have been problems with aufs maintenance
[01:23] <cjwatson> but union-mounts are perpetually almost-there-but-not-quite
[01:23] <cjwatson> we would love to use them eventually ...
[01:23] <maco> and given valerie having left red hat, i don't expect them to reach "quite" any quicker
[01:38] <JordiGH> So my package shows a bug in Ubuntu that it doesn't show in Debian. It hasn't been modified; looks like it's just a problem with how some libraries get pulled in as dependencies during build time in Ubuntu and Debian. How should I fix it/
[01:38] <JordiGH> ?
[01:38] <JordiGH> This bug, to be precise: https://bugs.launchpad.net/ubuntu/+source/octave3.2/+bug/546671
[01:40] <JordiGH> If there is no Ubuntu maintainer for a Debian package, is there a way to automatically request bugs for an Ubuntu package be forwarded to Debian?
[01:41] <micahg> JordiGH: there's a link in the PTS to Ubuntu bugs
[01:41] <JordiGH> Yeah, can I just get them forwarded to my email?
[01:41] <micahg> JordiGH: you can subscribe to the package in launchpad if you like
[01:42] <JordiGH> What's the point of reporting bugs to an Ubuntu package that has no Ubuntu maintainer? :-/
[01:42] <micahg> JordiGH: Ubuntu doesn't have maintainers
[01:42] <JordiGH> What are they called, Software Artists?
[01:43] <cjwatson> it just means that packages do not necessarily have dedicated maintainers in the same way that they do in Debian
[01:44] <micahg> JordiGH: unfortunately, we don't have enough people to get to all the bugs
[01:44] <cjwatson> it doesn't mean that nobody will ever look at it
[01:44] <JordiGH> Okay, I guess I'll subscribe to all of "my" Ubuntu packages... and figure out how to fix this bug that doesn't exist in Debian.
[01:45] <maco> can start out just requesting a no-change rebuild in case it just needs to be rebuilt to go with current libraries i guess
[01:46] <cjwatson> maco: best not to spend buildd resources on that until after confirming that it would fix the problem
[01:46] <JordiGH> I don't that's the problem, I gotta figure out why it's not pulling in the right library at build time.
[01:46]  * cjwatson peers at the build-dependencies
[01:46] <JordiGH> I don't know that's
[01:46] <micahg> maco: it's been rebuilt since it was reported with no succes
[01:46] <maco> micahg: oh
[01:47] <cjwatson> comparing the Debian and Ubuntu build logs would be a good plan
[01:47] <micahg> JordiGH: I would suggest finding which package has that symbol and make sure that it was pulled in with the build-deps in Ubuntu, it could be something that the toolchain changes for natty/wheezy are trying to avoid
[01:47] <cjwatson> the bug was reported long before those toolchain changes.
[01:48] <JordiGH> So, how do I tell Launchpad to send me bug reports regarding these packakges?
[01:48] <cjwatson> subscribe to the package, as micahg told you
[01:48] <micahg> cjwatson: right, I'm saying the toolchain change might be meant to fix similar issues
[01:48] <JordiGH> I know, where's the damn link?
[01:48] <micahg> s/fix/expose/
[01:48] <cjwatson> stop swearing and I'll tell you?
[01:48] <JordiGH> Where's the beautiful link?
[01:48] <cjwatson> heh
[01:48] <cjwatson> https://launchpad.net/ubuntu/+source/octave3.2
[01:48] <micahg> https://bugs.launchpad.net/ubuntu/+source/octave3.2/+subscribe
[01:48] <cjwatson> top right, "Subscribe to bug mail"
[01:49] <JordiGH> Alright, thanks.
[01:49] <JordiGH> And now, I gotta do the same for the 30+ other packages, joy.
[01:49] <cjwatson> the usual culprit for this kind of bug is alternatives in the build-dependency chain
[01:49] <JordiGH> I gotta login?
[01:49]  * JordiGH taps foot impatiently.
[01:49] <cjwatson> you could use launchpadlib for that
[01:49]  * cjwatson looks up the API
[01:50] <maco> well you still have to login to use the api
[01:50] <cjwatson> sure
[01:50] <maco> in order to authorise your script to run
[01:50] <cjwatson> but it saves clicking through 30+ links
[01:51] <JordiGH> Look, guys, I don't want to get involved with Ubuntu; I just don't want my package making us look bad because nobody is looking at it in Ubuntu. I want to subscribe pkg-devel-octave@lists.alioth.debian.org to all of these packages, not my personal email.
[01:51] <JordiGH> I guess I can use pkg-octave-devel@lists.alioth.debian.org as the subscription email address?
[01:51] <micahg> JordiGH: well, you still have to log in, but then, create a team, set that e-mail as the team contact, subscribe the team
[01:52] <cjwatson> you'll need an account whose preferred e-mail address is pkg-octave-devel
[01:52] <broder> JordiGH: isn't this what the derivatives feature in Debian BTS is for?
[01:52] <cjwatson> s/BTS/PTS/
[01:52] <broder> or maybe it's PTS. i can't remember
[01:52] <JordiGH> broder: What feature is that?
[01:52] <broder> :)
[01:52]  * micahg already suggested the link in the PTS to Ubuntu bugs (shows a count as well)
[01:52] <cjwatson> it's in the developer's reference
[01:53] <broder> http://www.debian.org/doc/manuals/developers-reference/resources.html#pkg-tracking-system
[01:53] <broder> you want to subscribe to the derivatives-bugs keyword
[01:54] <JordiGH> broder: I see... thanks.
[01:55] <broder> np
[01:55] <cjwatson> hmm, no differences in the octave3.2 dependencies between Debian and Ubuntu that I can see
[01:55] <cjwatson> (not meaningful ones anyway)
[01:56] <cjwatson> I wonder if this is really a problem in octave itself, or a transitive problem somewhere else
[01:56] <JordiGH> Where's the Ubuntu build log?
[01:57] <cjwatson> https://launchpad.net/ubuntu/+source/octave3.2 links to all the versions
[01:57] <cjwatson> (I have a browser keyword for https://launchpad.net/ubuntu/+source/%s, since that's nearly always my starting point)
[01:57] <cjwatson> http://launchpadlibrarian.net/58223997/buildlog_ubuntu-natty-i386.octave3.2_3.2.4-8_BUILDING.txt.gz is the latest one on i386
[01:58]  * cjwatson tries to install it here to look but it depends on the world so will take a while
[01:59] <JordiGH> Well, I see it is pulling libfltk1.1-dev
[01:59] <cjwatson> that seems to match Debian
[02:02] <JordiGH> Wait, duh, fltk is not the problem, it's the opengl stuff.
[02:02] <cjwatson> indeed.  it's pulling in the same libgl* packages too, though
[02:02] <cjwatson> this is sort of why I wondered if it was a problem further down the stack
[02:02]  * JordiGH wonders if it's a problem with C++ symbol mangliing.
[02:03] <JordiGH> That could happen if there are several versions of g++ involved...
[02:03] <JordiGH> Let's see, where is that Ubuntu libgl package...
[02:03] <cjwatson> it's a while since that ABI changed
[02:03] <cjwatson> octave3.2:1> backend("fltk")
[02:03] <cjwatson> octave3.2:2>
[02:03] <cjwatson> seems fine here
[02:04] <JordiGH> Huh.
[02:04] <JordiGH> Can you plot something?
[02:04] <JordiGH> Type "sombrero".
[02:04] <JordiGH> Without quotes.
[02:05] <cjwatson> looks like a sombrero to me
[02:05] <cjwatson> blue brim, red tip
[02:05] <JordiGH> What version?
[02:05] <cjwatson> 3.2.4-8, in natty
[02:05] <cjwatson> so perhaps something between maverick and natty has fixed thig
[02:05] <cjwatson> *this
[02:05] <JordiGH> Oh, good.
[02:06] <cjwatson> or perhaps it is architecture-specific
[02:06] <maco> oh the if-statements
[02:06] <cjwatson> I'm on i386; the only mention of an architecture anywhere in the bug report (most of the users don't say) is amd64
[02:06] <cjwatson> I can't easily confirm that
[02:07] <JordiGH> I dooooubt this is architecture specific.
[02:08] <cjwatson> well, it's your package, but if it were mine I wouldn't like to rule it out until it's been confirmed, especially as we still don't know the cause :)
[02:09] <JordiGH> Well, libftgl2 doesn't have that symbol for some reason.
[02:10] <cjwatson> should it?
[02:11] <JordiGH> Good question, ld seems to think so, at least when it created Octave.
[02:11] <cjwatson> Google suggests opengl_renderer is part of the Octave API?
[02:11] <cjwatson> e.g. http://octave.sourceforge.net/doxygen/html/classopengl__renderer.html
[02:11] <JordiGH> Yes.
[02:11] <JordiGH> That's our bare-bones Doxygen.
[02:12] <cjwatson> so why should the vtable for opengl_renderer be supplied by some other library?
[02:13] <JordiGH> Wait, I see, that is an Octave symbol...
[02:16] <JordiGH> Hmmmm....
[02:19] <cjwatson> it should be in liboctinterp; in the lucid amd64 package, at least, it isn't
[02:19] <JordiGH> Okay, I'm feeling like a n00b... why does objdump tell me that liboctave has no symbols? Does that just mean it's been stripped? But don't you need symbols in order to link to it?
[02:19]  * cjwatson unpacks a few more for comparison
[02:19] <cjwatson> probably wrong options, I'm using 'nm -D' here
[02:19] <cjwatson> there are different types of symbols and you may be asking for the wrong type
[02:20] <JordiGH> Huh, I don't want to disassemble it.
[02:20] <cjwatson> nm -D isn't a disassembler.
[02:20] <cjwatson> so maverick amd64 is broken, natty amd64 works
[02:20] <cjwatson> or at least has the right symbols
[02:22] <cjwatson> same with i386 - lucid/maverick broken, natty fixed
[02:22] <JordiGH> Huh.
[02:22] <JordiGH> How very odd.
[02:22] <cjwatson> so you're right that it's not arch-specific
[02:23]  * cjwatson diffs the maverick and natty build logs
[02:23] <JordiGH> Oh, cute, nm can demangle C++ symbols.
[02:23] <JordiGH> That's pretty damn interesting.
[02:24] <cjwatson> -checking for glEnable in -lGL... no
[02:24] <cjwatson> +checking for glEnable in -lGL... yes
[02:24] <cjwatson> looks like the first difference of note
[02:25] <JordiGH> You diffed the build logs...
[02:25] <cjwatson> yes
[02:25] <cjwatson> GL/gl.h was present in both though
[02:29] <cjwatson> and in fact GL/gl.h is identical in maverick and natty's mesa-common-dev
[02:29] <cjwatson> curiouser and curiouser
[02:30] <JordiGH> and it's the same Octave version, down to the Debian revision, isn't it?
[02:30] <cjwatson> no
[02:30] <cjwatson>  octave3.2 |    3.2.4-6 | maverick/universe | source, amd64, armel, i386, powerpc
[02:31] <cjwatson>  octave3.2 |    3.2.4-8 | natty/universe | source, amd64, armel, i386, powerpc
[02:31] <JordiGH> Well, well, well...
[02:31] <cjwatson> I wonder if the removal of libgl1-mesa-swx11-dev and libglu1-mesa-dev from the build-deps was significant
[02:32] <cjwatson> not a whole lot else changed
[02:32] <JordiGH> http://bugs.debian.org/591333
[02:32] <RAOF> Wait - libgl1-mesa-swx11-dev was in the build-deps?
[02:32] <JordiGH> RAOF: Yes.
[02:33] <JordiGH> So that could make the configure script fail.
[02:35] <cjwatson> aha, I misread the maverick build log too - libgl1-mesa-dev *wasn't* installed then, of course
[02:35] <cjwatson> (due to the Conflicts from libgl1-mesa-swx11-dev
[02:35] <cjwatson> )
[02:36] <JordiGH> Okay, mystery solved.
[02:36] <JordiGH> cjwatson: Aren't you a DD?
[02:37] <JordiGH> I've seen your name in Debianthings.
[02:37] <cjwatson> I still don't entirely get it though; GL/gl.h is provided by mesa-common-dev, which is depended upon by libgl1-mesa-dev and libgl1-mesa-swx11-dev both
[02:37] <cjwatson> so what's making the configure test fail?
[02:37] <cjwatson> JordiGH: yes
[02:37] <RAOF> It's quite possible that libgl1-mesa-swx11 is broken; I can't imagine many people use it, so we wouldn't notice.
[02:37] <cjwatson> damn, I missed taking note of my ten-year anniversary in Debian :-)
[02:38]  * maco sets cake in front of cjwatson
[02:38] <cjwatson> Subject: New Debian maintainer Colin Watson
[02:38] <cjwatson> Date: Mon, 05 Feb 2001 20:36:19 +0000
[02:38] <cjwatson> anyway
[02:39] <JordiGH> Happy decennial.
[02:39] <cjwatson> thanks :)
[02:39] <cjwatson> ah, octave3.2 is doing AC_TRY_LINK
[02:39] <charlie-tca> cjwatson: Congratulations on 10 years in Debian! that is quite an accomplishment
[02:39] <cjwatson> sorry, AC_CHECK_LIB
[02:41] <JordiGH> cjwatson: Sorry, I've managed to get this far in life without understanding autotools. What's significant about those two macros?
[02:42] <cjwatson> just that the output of configure would depend on the shared libraries providing those symbols as well as on the headers
[02:43] <cjwatson> I suspect that if we really wanted to nail this down it would require seeing config.log, which hasn't been preserved here
[02:43] <cjwatson> but it does seem as though those two build-deps are the culprit
[02:44] <cjwatson> is it safe to remove those in both 3.2.3-1 and 3.2.4-6?
[02:44] <JordiGH> Huh, can you backport fixes to older Ubuntu releases?
[02:45] <JordiGH> I thought they only did security fixes.
[02:45] <cjwatson> we can
[02:45] <cjwatson> https://wiki.ubuntu.com/StableReleaseUpdates
[02:45] <cjwatson> this is broken functionality, I think it's reasonable to fix
[02:46] <JordiGH> Well, we only use opengl for that particular function, so you can try backporting Thomas's fix to those two Ubuntu releases, and if you get the sombrero, then it works.
[02:48] <cjwatson> I can take care of that
[02:48] <cjwatson> thanks for the debugging
[02:48] <JordiGH> And thanks to you too.
[07:35] <didrocks> good morning
[07:54] <Daviey> oops
[07:54] <Daviey> @pilot out
[07:56] <nigelb> Daviey: patch piloting over night? ;)
[07:57] <pitti> Good morning
[07:57] <cdbs> Good morning Martin sir!
[07:57] <hdon> the cgdb in ubu10.04 does not properly ioctl() with TIOCSWINSZ
[07:57] <hdon> the latest release from their website works, though
[07:58] <hdon> err
[07:58] <hdon> actually know, i just built from their bleeding edge
[07:58] <hdon> but anyhow
[07:58] <hdon> it's a simple fix. you guys should put it in
[07:58] <hdon> d'oh
[07:58] <hdon> nevermind, it still doesn't. i forgot i put in a work-around.
[07:59]  * hdon fixes
[07:59] <hdon> $ cgdb cgdb # YES!
[08:00] <broder> hdon: best thing to do is file a bug, prepare a debdiff or a merge proposal (https://wiki.ubuntu.com/PackagingGuide/Recipes/Debdiff), and ask for sponsorship (https://wiki.ubuntu.com/SponsorshipProcess)
[08:00] <hdon> broder, sorry for the wrong information. the bug hasn't been fixed in any version of cgdb. i am fixing it now
[08:00] <broder> well, once you do...
[08:01] <dholbach> good morning
[08:01] <hdon> i will have to send the fix to the cgdb maintainer
[08:01] <hdon> someone else can get it into ubu
[08:17] <dholbach> if you have a new project you want to introduce at UDW (5 minutes) and attract new people to help out, please consider signing up at the bottom of https://wiki.ubuntu.com/UbuntuDeveloperWeek/Sessions
[08:28] <nigelb> dholbach: does this look good? http://justanothertriager.wordpress.com/2011/02/09/have-an-interesting-project-you-want-to-talk-about/
[08:28] <nigelb> arg, sorrywrong channel
[08:40] <dholbach> @pilot in
[08:41] <cdbs> dholbach: yay!
[08:43]  * pitti hugs dholbach
[09:48] <hdon> broder, the bug is not in cgdb, it is in gdb. a warning occurs, though. you can see the bug in action here: http://codebad.com/~donny/gdb-tty-bug.png
[09:48] <dholbach> hey seb128 - who maintains gnome-session upstream? can we ping them about https://bugzilla.gnome.org/show_bug.cgi?id=637449 ? :)
[09:48] <seb128> dholbach, vuntz
[09:48] <seb128> dholbach, he's on #ubuntu-desktop, you can ping him there if you want
[09:49] <dholbach> I'm pinging him - thanks :)
[09:49] <seb128> yw
[10:40] <pitti> james_w: hm, do you still remember why I reverted the WI tracker blueprints branch back then?
[10:41] <pitti> james_w: was it just because lillypilly was still running hardy?
[10:41] <sabdfl> pitti: i know the feeling. the past recedes rapidly, doesn't it :-)
[10:42] <sabdfl> like my hairline
[10:42] <pitti> or "maverick"
[10:43] <cdbs> :o sa-bdfl :)
[10:43] <broder> ha! i think the sponsorship form is counting html entities as multiple characters
[10:43] <broder> at least, that's my best explanation for why it thought my write-up was 11 characters longer than i did
[10:44] <maxb> *blink*
[10:44] <maxb> lillypilly?
[10:44] <pitti> maxb: aka "people.canonical.com"
[10:44] <maxb> Just when I thought canonical machine names couldn't get weirder....
[10:45] <pitti> YK, http://lillypilly.canonical.com/ confirms that it works :)
[10:45] <pitti> maxb: you think lillypilly is weird? have you looked at https://launchpad.net/builders recently, especially the armel ones?
[10:45] <cody-somerville> Wow. I just realized I've been reading 'lillypilly' as 'lillypad' this entire time.
[10:46]  * pitti hasn't attempted trying to pronounce actinidiaceae or #canonical anacardiaceae yet
[10:46] <pitti> (eh, where did this "#canonical" come from)
[10:46] <cdbs> Wow!
[10:46] <cdbs> internal canonical discussions on #ubuntu-devel
[10:47] <pitti> I guess IS ran out of Penguin names, fruits and Antarctica stations at some point
[10:47] <pitti> and apparently the periodic table of elements as well :)
[10:47] <cody-somerville> and berries
[10:47] <broder> that's a lot of things to run out of
[10:49] <Nafallo> pitti: you missed elements, but apparently we're still using the fruits scheme.
[10:49] <pitti> Nafallo: "I missed elements"?
[10:50] <pitti> Nafallo: oh, if you mean that buildds don't exhaust element names, we have more servers than just buildds :)
[10:50] <Nafallo> pitti: we went through the periodic table between antarctica stations and fruits ;-)
[10:50] <cdbs> I kinda like the names of the buildds
[10:50] <cdbs> makes me feel hungary
[10:50] <pitti> Nafallo: I mentioned that above :)
[10:50] <cdbs> *hungry
[10:50] <Nafallo> ah.
[10:51] <jpds> cdbs: Some people feel anger.
[10:51] <pitti> Nafallo: will you guys ever move to Comic characters?
[10:51] <Nafallo> pitti: not my decision
[10:51] <cdbs> Or Toy Story characters, like Debian does
[10:52] <pitti> nah, NIH
[10:52] <pitti> and too confusing :)
[10:52] <directhex> debian already ran out of toy story characters
[10:52] <directhex> hence using a toy story 2 character for 7.0
[10:53] <broder> wheezy was the singing squeaky-toy penguin, right?
[10:53] <directhex> yep. from TS2, which has absolutely no historical ties to debian, other than being the sequel to TS1
[10:55] <Laney> what is the historical tie with TS1?
[10:56] <directhex> Laney, bruce perens, bruce@pixar.com
[10:56] <Laney> ah yes
[10:57] <directhex> and related, e.g debian-bugs@pixar.com
[10:58]  * amitk thinks IS should dedicating machine names to the top ubuntu contributors
[11:02] <pitti> . o { Hey Nafallo, can you please poke sabdfl? it crashed again }
[11:02] <pitti> amitk: I don't think that'll come across very well..
[11:03] <amitk> pitti: you mean there will be friction against the Ubuntu Hall of Fame?
[11:04] <amitk> pitti: or you think people don't want machines named after them :)
[11:04] <pitti> rather, talking about people names when you speak about machines :)
[11:04] <pitti> that, too
[11:04]  * Laney fscks amitk 
[11:05]  * amitk goes back to hacking on the kernel and leaves community sensitivity to others... :-p
[11:05] <pitti> I have named my machines after Duck Tales characters
[11:06] <Nafallo> pitti: lolnovetoed
[11:06] <cjwatson> directhex: Debian hadn't quite run through everything in TS1 - scanning down wikipedia, there's at least RC, Mr. Spell, Rocky, Snake, Robot, Shark, Mike
[11:06] <cjwatson> I assume the RMs just preferred Wheezy
[11:07] <cjwatson> ("RC" would be more than a little confusing ...)
[11:07] <directhex> cjwatson, i was under the impression RC was on the excluded list
[11:07]  * cody-somerville names his machines after the dictionary.com word of the day.
[11:07] <cjwatson> still leaves at least six though
[11:07] <directhex> the machines at home are named delerium, death, desire & dream. cake to the person who guesses the scheme
[11:08] <cody-somerville> directhex, The Endless?
[11:10] <directhex> cake!
[11:10]  * cody-somerville suspects the cake is a lie.
[11:13] <tjaalton> what is the correct way to configure the console keymap? 'cached.kmap.gz' is a 20 byte file here
[11:13] <tjaalton> tried reconfiguring console-setup
[11:18] <mr_pouit> cjwatson: hi, what's the "correct" way of getting rid of the aubergine bg in grub-pc (the xubuntu plymouth theme is black, so it's a bit weird currently)? I tried to drop a 06_xubuntu_theme in /etc/grub.d to override the bg: http://paste.ubuntu.com/564912/. It works, but I guess it's not that nice, as it makes grub set the aubergine bg, and right after set a black one...
[11:40] <pitti> james_w: ah, nevermind, https://code.launchpad.net/~james-w/launchpad-work-items-tracker/blueprints-api/+merge/43240 has the reason (overly long file names)
[12:06] <dholbach> does anybody have a moderately educated opinion about bug 714838 (syncing newest gnutls26) - the sync generally looks good and we're still before FF - but it looks loads and loads changed (2.8→2.10)
[12:07] <cjwatson> tjaalton: reconfigure console-setup or edit /etc/default/keyboard - it may be that it currently requires a manual 'sudo setupcon' due to some bug
[12:07] <cjwatson> mr_pouit: there's no correct way to do it in add-on packages right now - it'll need changes in grub2
[12:08] <cjwatson> dholbach: I think it should be the reporter's responsibility to analyse reverse dependencies and prepare a transition if one is needed
[12:08]  * dholbach nods
[12:08] <cjwatson> and that he should be asked to do that
[12:09] <cjwatson> mind you is it actually a transition?
[12:09] <tjaalton> cjwatson: it looks fine though, just that the console keymap on my desktop is wrong, laptop has the same settings and it's fine there (though no umlauts with the vga font it seems)
[12:09] <cjwatson> apparently not, it's still gnutls26
[12:09] <Laney> no
[12:09] <dholbach> cjwatson, yes, no transition - just a huge version jump
[12:09] <cjwatson> then I have no educated opinion :)
[12:09] <cjwatson> tjaalton: does 'sudo setupcon' fix it?
[12:10] <tjaalton> cjwatson: no, it creates the 20byte cache file, if I've removed it before
[12:11] <cjwatson> forget about the cache file, I mean does it fix the currently-in-use keymap?
[12:11] <tjaalton> no
[12:12] <cjwatson> then I need more details - what's the current behaviour compared to desired behaviour?
[12:12] <tjaalton> cjwatson: it's the us layout
[12:12] <tjaalton> on X it has been fine
[12:13] <tjaalton> maybe it was broken before upgrading lucid->maverick->natty yesterday, can't remember..
[12:15] <cjwatson> tjaalton: "it's the us layout" is that current state or desired state?
[12:16] <cjwatson> show me /etc/default/keyboard and /etc/default/console-setup
[12:16] <tjaalton> cjwatson: current, I want fi :)
[12:17] <tjaalton> cjwatson: http://paste.ubuntu.com/564947/ http://paste.ubuntu.com/564948/
[12:19] <cjwatson> tjaalton: now the output of 'sh -x /bin/setupcon' (run at the console)
[12:24] <tjaalton> cjwatson: sigh, how do I get the output somewhere? script, screen, redirecting stderr all fail
[12:24] <tjaalton> it just says "not on the linux console..."
[12:25] <cjwatson> hmm
[12:27] <cjwatson> tjaalton: use --force
[12:31] <tjaalton> naturally :)
[12:32] <tjaalton> cjwatson: http://paste.ubuntu.com/564951/
[12:34] <cjwatson> tjaalton: could you remove /etc/console-setup/cached.kmap.gz and do the same again?
[12:35] <cjwatson> (20-byte file sounds like the result of gzipping nothing)
[12:36] <tjaalton> ok, got it. the error from ckbcomp is "Unknown name $sun_t6_custom"
[12:37] <cjwatson> what version of keyboard-configuration and console-setup?
[12:38] <tjaalton> uh, 1.57ubuntu5
[12:38] <tjaalton> both
[12:38] <tjaalton> I see there are newer ones available
[12:38] <cjwatson> console-setup (1.57ubuntu6) natty; urgency=low
[12:38] <cjwatson>   * Allow underscores in rules variables ($sun_t6_custom).
[12:38] <cjwatson>  -- Evan Dandrea <ev@ubuntu.com>  Mon, 07 Feb 2011 15:14:44 +0000
[12:39] <tjaalton> :)
[12:40] <tjaalton> wonder why it wasn't installed yesterday during the upgrade
[12:42] <tjaalton> main archive and all.. but
[12:45] <cjwatson> tjaalton: ubuntu6 failed to build; ubuntu7 succeeded (yesterday)
[12:46] <tjaalton> cjwatson: ok, that explains it. and the layout is good now
[12:46] <cjwatson> good good
[12:46] <tjaalton> :)
[12:59] <barry> dholbach: ping, re: bug 686257 merge proposal (python-keyring)
[13:03] <ogra> dholbach, hmm, you already acked all sync requests ari-tczew asked me for
[13:04]  * ogra didnt know he had asked you too
[13:05] <seb128> ogra, he probably didn't
[13:05] <seb128> ogra, dholbach just do clean the sponsoring queue daily
[13:05] <seb128> ogra, without need pings to do it
[13:05] <seb128> needing
[13:06] <ogra> ah
[13:06] <seb128> ogra, seems he's patch pilot as well today ;-)
[13:06] <ogra> oh, i missed that bit
[13:06] <ogra> who reads topics anyway :P
[13:46] <ari-tczew> DktrKranz: ping
[13:49]  * hallyn just finally read the loom howto, figures he'll have to give those a shot
[13:49] <hallyn> for his udd sanity
[13:50] <ari-tczew> is there anyone with concerns about upgrade gnutls26 to 2.10*? bug 714838
[13:51] <hallyn> jdstrand: I"ve uploaded the debdiff and source package for libvirt 0.8.7 to people.canonical.com/~serge/libvirt_0.8.7-0ubuntu1.src.tgz, if you wanted to take a look.
[13:55] <DktrKranz> ari-tczew: pong
[13:55] <jdstrand> hallyn: ack, but I won't be able to look at it for a bit
[13:55] <jdstrand> hallyn: thanks for doing it :)
[13:56] <ari-tczew> DktrKranz: IIRC at the natty start we have discussed about something related to gnutls... could you give a feedback for my question asked 5 minutes ago here?
[13:57] <dholbach> barry, pong
[13:58] <barry> dholbach: hi.  comment updated on https://code.launchpad.net/~barry/ubuntu/natty/python-keyring/bug-686257/+merge/48967
[13:58] <hallyn> jdstrand: thanks - no hurry, i'm gonna need sometime before i can get to testing it the way i want
[13:58] <DktrKranz> ari-tczew: I think it was about gnustep
[13:58] <dholbach> barry, will check in a bit
[13:58] <barry> dholbach: thanks
[14:00] <hallyn> (unfortunately I can't try loom right now bc I can't install packages - this is not good :)
[14:00] <ari-tczew> DktrKranz: yea probably, have you got any concerns about upgrade gnutls to 2.10.4?
[14:01] <DktrKranz> ari-tczew: non that I know of
[14:01] <ari-tczew> dholbach: ^^
[14:01] <dholbach> barry, I never saw tests packaged, but I haven't looked closely for a while - so I don't know - it just looked weird to me
[14:02] <dholbach> ari-tczew, then get somebody else to ACK it - I just wasn't sure myself
[14:02] <barry> dholbach: looking in my build log keyring/tests subpackage is included in the .deb afaict
[14:03] <dholbach> barry, yes, that's what I noticed too and why I wrote the comment
[14:04] <dholbach> I personally don't see the need (if people want code examples, they can grab the source - also users should be able to trust the package maintainers that the test suite was run) - but I'm very happy to be overruled - as I said: I don't know what "the standard" is there :)
[14:04] <barry> dholbach: i get it now (the tests weren't included before but now they are)
[14:04] <barry> dholbach: i'm not sure there *is* a standard ;)
[14:05] <barry> dholbach: it was debated to no consensus in upstream mlists.  you know now which side i came down on :)
[14:05] <dholbach> yep
[14:05] <barry> dholbach: do you feel strongly that they should not be included?
[14:06] <dholbach> no, as I said: I'm happy to be overruled
[14:06] <pitti> FWIW, I think it's by and large a waste to include them in binary pacakges
[14:07] <barry> pitti: please see my comment in the above mentioned merge proposal
[14:11] <pitti> barry: I do agree to the argument that these make it easy to check the correctness of the installed package
[14:12] <barry> pitti: i also like the simpler packaging when the tests are a subpackage (nothing to rm)
[14:16] <barry> dholbach, pitti: in the absence of consensus, can we keep the tests in this case?
[14:18] <dholbach> barry, I'm happy whatever
[14:18] <pitti> yeah, I don't think it's a policy matter
[14:18] <pitti> shoudl be the discretion of the maintainer
[14:18] <pitti> I don't have a strong opinion against it
[14:19] <barry> cool. thanks.
[14:26] <dholbach> barry, I removed the "ppa0"
[14:26] <dholbach> @pilot out
[14:26] <barry> dholbach: thanks.  that was an artifact of a test build.
[14:33] <dholbach> ari-tczew, what do you want to know about Harvest?
[14:33] <hallyn> hm, a freshly created package using 'dh_make' is calling '/usr/bin/make -C .', but a 'CFLAGS += XYZ" in the top-level Makefile is being ignored.  Is that expected?
[14:33] <ari-tczew> dholbach: what kind of bugs are reported on harvest?
[14:34] <dholbach> ari-tczew, you can see the list of "kinds of opportunities" on the left hand side and hover over them with the mouse
[14:34] <dholbach> (outstanding merges, rc bugs in Debian, etc.)
[14:34] <ari-tczew> dholbach: I'm clicking on kinds and nothing happened
[14:35] <dholbach> hover
[14:35] <dholbach> don't blick
[14:35] <dholbach> click
[14:35] <ari-tczew> ?
[14:35] <hallyn> do i have maybe cdbs was overkill for this package
[14:35] <dholbach> move the mouse of "bitesize" for example and don't move for a second
[14:36] <dholbach> it will give you some information what "bitesize" is about
[14:38] <ari-tczew> dholbach: ok I guess how it works
[14:38] <dholbach> you can select package sets and opportunity types you're interested in
[14:39] <ari-tczew> dholbach: I've received some informations that natty has got a lot of uninstallable packages. does harvest support this kind of bugs?
[14:40] <dholbach> no, I don't think there's a list for it
[14:43] <ari-tczew> dholbach: what do you think about expand harvest with department for uninstallable packages?
[14:43] <dholbach> ari-tczew, the only thing you need to do is write a script that spits out data according to: http://daniel.holba.ch/blog/?p=838
[14:43] <dholbach> I can then add it to Harvest easily
[14:44] <dholbach> Harvest is decentral: you write a script that writes a simple enough list, I add it to Harvest
[14:44] <dholbach> check out http://harvest.ubuntu.com for more information
[14:44] <ari-tczew> dholbach: I'm not a code developer.
[14:45] <dholbach> and I won't have the time in the next few weeks, but I agree that it's a good idea
[14:45] <geser> smoser: Hi, are you perhaps working on the ec2-api-tools FTBFS? I've gave it a try but only run into a new issue once I fixed one (I've already run into 2)
[14:46] <smoser> geser, i did not know it was ftbfs. i will make sure it does not. bug ?
[14:46] <geser> smoser: no bug yet but http://launchpadlibrarian.net/58997063/buildlog_ubuntu-natty-i386.ec2-api-tools_1.3.57419-0ubuntu2_FAILEDTOBUILD.txt.gz
[14:47] <ari-tczew> dholbach: No matching opportunities in 238 selected packages
[14:47] <smoser> first issue is java depends ?
[14:47] <ari-tczew> dholbach: why only 238 packages are supported?
[14:47] <geser> smoser: I can file a bug and attach those fixes that I already have if it helps you
[14:47] <dholbach> ari-tczew, which package set is currently selected?
[14:47] <ari-tczew> dholbach: nothing
[14:47] <dholbach> ari-tczew, there are much much more packages supported - it just shows you what you selected and what it has data available for
[14:48] <dholbach> ari-tczew, please send me a screenshot
[14:48] <smoser> geser, sure. it can't hurt.
[14:48] <smoser> thank you.
[14:53] <ari-tczew> dholbach: http://img204.imageshack.us/i/harvestx.png/
[14:55] <geser> smoser: bug 715818
[14:59] <dholbach> ari-tczew, ok - can you file a bug about it? http://launchpad.net/harvest/+filebug
[14:59] <dholbach> I don't know what's going on right now - maybe Dylan will know
[15:13] <pitti> barry: btw, the computer-janitor pygi branch should work well now with current natty's pygobject
[15:14] <cdbs> smoser: euca2ools is no longer shipping the EUCALYPTUS_CERT for EC2. why?
[15:16] <smoser> cdbs, that not be intended
[15:17] <cdbs> smoser: really? in your blog post it appears its very much needed for AWS
[15:17] <smoser> *not shipping it* would be not intended :)
[15:17] <smoser> it is packaged in /usr/share/euca2ools/cert-ec2.pem
[15:18] <cdbs> :o
[15:18]  * cdbs missed that in dpkg -L
[15:21] <smoser> cdbs, if this is broken, let me know, but it does not appear to me that it should be.
[15:23] <barry> pitti: cool, i'll take a look, thanks
[16:39] <jam> barry: just seeing if you're actually online right now, had some questions for you
[16:39] <barry> jam: i'm here, though just finishing up a meeting
[16:39] <jam> barry: k, just ping me when you're done, nothing urgent, but some udd questions
[16:42] <barry> jam: all freed up
[16:42] <jam> barry: I was thinking about the package-import stuff. And I thought it might be nice to prototype some stuff, and work with someone who is actually doing udd, and see what feedback we get
[16:42] <jam> I can write code, but I really don't know a ton about packaging.
[16:43] <jam> So I was thinking it might be nice to do some prototype conversions of packages you actually maintain, so that you can give feedback about what you like/don't like
[16:43] <barry> jam: i'd be happy to be your guinea pig :)
[16:43] <jam> rather than hypothetical "wouldn't it be good if the importer did X"
[16:44] <barry> jam: unfortunately, i will not be at today's udd meeting
[16:45] <lool> cjwatson: Oy!  We're lacking some modules in initramfs for btrfs and probably others on some architecture/kernels; if btrfs-tools is installed, the initramfs has the right modules though; I see partman-btrfs arranges for this to be installed, but I was wondering whether we wanted to seed this somewhere so that Ubuntu initramfses have support for btrfs?
[16:46] <cjwatson> lool: perhaps standard along with the other filesystems there, but I'm not entirely convinced - most of the filesystems there are ones you might have on USB sticks or whatever, and btrfs isn't really in that category
[16:47] <cjwatson> lool: the initramfs only needs it if / is btrfs, and surely the installer should take care of that
[16:47] <lool> cjwatson: correct, d-i and ubiquity take care of that
[16:47] <lool> via partman-btrfs
[16:47] <cjwatson> indeed
[16:47] <lool> cjwatson: btrfs is "special" in that its deps are broken in the kernel modules
[16:47] <lool> just like ubifs
[16:47] <cjwatson> "its deps are broken"?
[16:48] <lool> cjwatson: The module dependencies are insufficient to pull the right stuff
[16:48] <lool> long story, but basically multiple providers of the feature prevents the module from having a sensible dep
[16:48] <cjwatson> oh, you mean the way btrfs-tools/debian/local/btrfs.modules lists libcrc32c crc32c zlib_deflate btrfs
[16:49] <lool> Yes
[16:49] <cjwatson> is btrfs.ko itself in the initramfses you care about, just not its dependencies?
[16:49] <lool> correct
[16:49] <cjwatson> btrfs is probably there because 'auto_add_modules base' in initramfs-tools adds it
[16:49] <cjwatson> so in that case I'd recommend adding those extra modules in 'auto_add_modules base' too
[16:50] <cjwatson> that seems better than seeding btrfs-tools
[16:50] <cjwatson> and it should be upstreamable to Debian if their kernel is the same way
[16:50] <lool> cjwatson: Thanks a lot; I wanted to do this too, pinged maks on #debian-devel, but I dind't specifically know where to fix this in initramfs-tools
[16:51] <lool> cjwatson: wheredo you usually upstream hte initramfs-tools bugfixes?
[16:51] <cjwatson> just grep for btrfs in the source, there's only one non-changelog match
[16:51] <cjwatson> bugs.debian.org
[16:52] <lool> cjwatson: thanks a lot
[16:52] <jam> barry: so can you give a couple of packages that you would like me to play around with?
[16:53] <lool> cjwatson: There is one btrfs utility which gets copied into the initramfs too; I don't know whether that'd be relevant enough to warrant seeding
[16:53] <barry> jam: sure.  do you want ones with or without quilt3 patches?
[16:53] <lool> I don't use btrfs at this point
[16:53] <jam> barry: I want ones that you use :), but both is probably good
[16:54] <cjwatson> lool: it's useful for control and I think for subvolume bits and pieces but I don't think it's vital
[16:54] <barry> jam: okay :)  i'm going to grab some lunch and look at my set of branches.  will let you know
[16:54] <jam> barry: grabbing lunch myself, thanks. You can just email me if you want
[16:54] <lool> cjwatson: Ok; I will defer the seed part then, thanks
[16:54] <barry> jam +1
[16:56] <lool> cjwatson: while we're at it, I've noticed ubifs has a similar issue and an uglier workaround (if / is ubifs and MODULES=dep, add these modules); do you think it should be listed in base too, or is it just a weird filesystem?
[16:57] <lool> cjwatson: Actually I'm just realizing that the base fix will only work for MODULES=most, probably not =dep
[16:59] <cjwatson> lool: ubifs seems a bit too special-purpose for base
[17:00] <lool> cjwatson: Ok; I think I will use the same approach for btrfs + MODULES=dep than for ubifs
[17:00] <ari-tczew> cjwatson: you're admin with knowledge, maybe you have an opinion for bug 714838
[17:01] <cjwatson> lool: this does seem like it ought to be a set of manual hints to the dependency resolver, yes
[17:02] <cjwatson> ari-tczew: I disclaimed having an opinion earlier when dholbach asked.  I think the basic questions should be: what's the reason for the sync, and are you prepared to take responsibility for any problems it causes?
[17:03] <cjwatson> it seems like there should be more of a reason than just it being available
[17:07] <ari-tczew> Found a total of 93 reverse build-depend(s) for libgnutls-dev.
[17:07] <ari-tczew> not good
[17:07] <cjwatson> I think that's why it made dholbach nervous; it's fairly core, and it's hard to roll back libraries
[17:08] <cjwatson> so there'd have to be a substantial benefit to justify the risk
[17:13] <ari-tczew> cjwatson: I think he was easy as usually.
[17:15] <ari-tczew> cjwatson: I'll ask kees during his today piloting. If he won't be convinced, I'll delay sync to next devel cycle.
[17:16] <lool> cjwatson: Turns out there's a nicer fix in tip initramfs-tools as maks pointed out; I guess it means I need to mergeit  :-)
[17:19] <cjwatson> lool: I've got most of that merge in bzr, I'll do it if you like
[17:19] <cjwatson> I just forgot to commit
[17:27] <lool> cjwatson: Awesome
[17:27] <lool> cjwatson: Well I'd love if you were to upload that, thanks a lot!
[17:27] <cjwatson> I'm sure I can manage that :)
[17:27] <cjwatson> I'd been meaning to anyway
[17:30] <kees> activate super pursuit mode!
[17:30] <kees> wait, that's not it.
[17:30] <kees> @pilot in
[17:37] <kees> ari-tczew: reading back-scroll doesn't help. what's the question?
[17:41] <cjwatson> lool: done
[17:42] <ari-tczew> kees: we are considering useful of sync bug 714838
[17:46]  * lool hugs cjwatson 
[17:48] <kees> ari-tczew: the only reason gnutls26 appeared in unstable is because debian opened for development again. I don't think we should sync it this cycle without a more pressing reason.
[17:49] <ari-tczew> kees: I'll delay it for next devel cycle then.
[17:50] <kees> okay, thanks
[17:50] <ari-tczew> kees: I'm counting on exim4. ;-)
[17:50] <kees> ari-tczew: which bug# is that one?
[17:50] <ari-tczew> kees: bug 713855
[18:01] <kees> ari-tczew: for exim4, can you change 71_exiq_grep_error_on_messages_without_size.patch to use the upstream fix (from that report), drop the "From" (this should have been Author: with Daniel van Eeden) and add an Origin: line, and finally mention the debian bug # in the changelog?
[18:02] <ari-tczew> kees: FYI, I know about new way created by upstream, but I submitted debdiff before upstream patch.
[18:02] <kees> ari-tczew: no worries. best we get the "real" fix in, though.
[18:08] <hv> I read about a serious java bug on slashdot.  I cannot find a corresponding bug number on bugs.debian.org, or bugs.launchpad.org.  The bug is this: Double.parseDouble("2.2250738585072012e-308") produces an infinite loop.
[18:08] <hv> Is this well known?
[18:08] <ari-tczew> kees: I wanted get it by merging next upstream release, but that's right, we can get it right now and drop with merging next upstream release.
[18:08] <ari-tczew> hv: #launchpad
[18:09] <micahg> ari-tczew: no, he's asking about java
[18:09] <ari-tczew> ah
[18:10] <mtaylor> pitti: hi! is there a way to silence WARNING: the following files are not recognized by DistUtilsExtra.auto:
[18:10] <kees> ari-tczew: right
[18:11] <ari-tczew> kees: what's the deadline of your piloting today?
[18:11] <ari-tczew> since I have to do some other stuff right now, I'll finish exim4 later
[18:11] <kees> ari-tczew: I'm done in about 3.5 hours
[18:11] <ari-tczew> ok
[18:11] <kees> ari-tczew: no worries; it's an easy fix now that I've read through the rest of it.
[18:11] <micahg> kees: can you sponsor my pidgin merge?
[18:12] <kees> micahg: bug #?
[18:12] <micahg> kees: I just a merge proposal, no bug: https://code.launchpad.net/~micahg/ubuntu/natty/pidgin/2.7.9-2/+merge/48721
[18:12]  * micahg figured it would be picked up the next morning :)
[18:13] <cjwatson> hv: best to file a bug if you find it in our Java implementation.  We don't normally trawl Slashdot looking for bug reports there. :-)
[18:14] <hv> cjwatson: I don't expect bug reports in slashdot, either.  Last one I remember was the debian openssh fiasco ;)
[18:15] <cjwatson> s/openssh/openssl/
[18:15] <hv> apparently openjdk does not use launchpad for bug reports (or that is what launchpad says)
[18:15] <kees> micahg: looking at it now
[18:15] <cjwatson> you should file bug reports on Ubuntu packages in the package namespace, not the upstream project namespace
[18:15] <micahg> kees: thanks
[18:15] <cjwatson> https://bugs.launchpad.net/ubuntu/+source/openjdk-6
[18:15] <cjwatson> (or, better, 'ubuntu-bug openjdk-6')
[18:16] <kees> hv: sbeattie may already be looking into that issue.
[18:18] <kees> micahg: I find this merge confusing. :) /me isn't used to bzr merges for packaging yet.
[18:19] <hv> cjwatson: thanks. /me is embarrassed.  kees: thanks.
[18:20] <micahg> kees: ok, I guess leave it for someone else, or I can walk you through it
[18:21] <kees> micahg: no, no, I got it; it's just I need to pull a lot of packages to actually review it. it's much easier to review debian-to-ubuntu deltas rather than ubuntu-to-ubuntu deltas across a debian change
[18:21] <micahg> kees: ah, ok
[18:22] <micahg> kees: yeah, I actually found a change I made was actually made by Debian, so I dropped it from the changelog
[18:22]  * kees nods
[18:23] <micahg> kees: BTW, the debian branches are on LP, so you can diff against them as well
[18:23] <kees> micahg: true, but I only trust source packages. :)
[18:24] <micahg> kees: no, I meant the Debian source package import
[18:25] <kees> wow, there are _extensive_ changes between debian and ubuntu. seb128: shouldn't you enumerate the changes when doing a merge of pidgin? besides just control and rules, there are _8_ added patches.
[18:26] <seb128> kees, they were enumerated like 2 changelog entries bellow
[18:26] <micahg> kees: I'm wondering how I missed those
[18:26]  * micahg only saw one change
[18:26] <kees> seb128: yeah, I see that now.
[18:26] <seb128> kees, I did just fetch the new debian revision, apply that and added a "sync on debian" entry
[18:26] <kees> micahg: this is why I don't trust bzr. :)
[18:26] <seb128> either that rebasing
[18:26] <seb128> easier
[18:26] <micahg> kees: maybe I should redo that then
[18:27] <kees> well, my opinion is to always enumerate the delta, but if that's not how seb128 does it, then I guess it's less of an issue here.
[18:27] <kees> let me still look at what actually changed, one sec...
[18:27]  * micahg guesses he shouldn't trust bzr either
[18:28] <seb128> kees, that's how I do it usually but I feeled lazy and just wanted to backport one revision from debian without redoing the merge
[18:28] <kees> seb128: see, there are changes between the last full resync list and current.
[18:28]  * kees nods
[18:28] <kees> last full changelog list was 1:2.7.3-1ubuntu1
[18:28]  * micahg can do a full list :)
[18:29] <kees> micahg: yeah, I'd prefer that. I'll keep review the actual delta here, but I'd like to see a full delta report in the changelog.
[18:29] <kees> *reviewing
[18:30] <seb128> kees, well I could have copied the summary in the current entry
[18:30] <seb128> it's basically a merge with a new revision grabbed after and a changelog entry added for upload
[18:32] <kees> seb128: right. but between 1:2.7.3-1ubuntu1 and current there were 7 real changes, and 3 resyncs without enumeration. it can be confusing to someone new to the package. *shrug*
[18:33] <seb128> indeed, sorrya bout théat
[18:34] <seb128> doh, "sorry about that" rather
[18:35] <micahg> I just found some stuff never made it into our package :(, minor things like Vcs-Svn changed to Vcs-Git
[18:36] <RoAkSoAx> is there anyone expert in distutils extra that might be ableto help me with an issue of updating a .desktop file?
[18:37]  * micahg needs to file a bug against bzr for not showing this stuff
[18:45] <bcurtiswx> i downgraded a package from the gnome3 PPA to natty (nautilus), but it still links to libgtk-3.0.so.0 => /usr/lib/libgtk-3.0.so.0 (0x00007fd03e47b000)
[18:45] <bcurtiswx> how can I change that to be -2.0 ?
[18:48] <kees> micahg: the actual contents of the merge look fine. once you're ready with a new changelog, I'm happy to upload.
[18:49] <bcurtiswx> as far as packaging is concerned, a merge you would bzr merge-upstream, what do you do for a sync ?
[18:52] <lifeless> mdz: ping
[18:52] <micahg> kees: it seems we missed a lot of changes in our version, i'm going to try to pull in some of the changes that Debian made to the packaging, I'll check the changelog to make sure it's not something specific that we changed
[18:55] <kees> micahg: cool, thanks
[18:57] <mdz> lifeless, hi
[18:57] <lifeless> mdz: I'm wondering what my next step should be with the discussion about package name substring matching in bug search
[18:58] <lifeless> mdz: I'm presuming you saw my thread on u-d, and blog post on blog.l.n
[18:58] <mdz> lifeless, I had seen your blog post but not the u-d thread
[18:58] <mdz> and I didn't see the comments on your blog post
[18:59] <mdz> so I know what you proposed but not what the response was
[18:59] <lifeless> there was little response
[18:59] <lifeless> one strongly in favour of the current behaviour
[18:59] <lifeless> some technical 'how can we help make what you do now fast'
[18:59] <lifeless> and a few 'make it faster -please'
[19:00] <lifeless> the u-d thread - https://lists.ubuntu.com/archives/ubuntu-devel/2011-February/032381.html
[19:02] <lifeless> mdz: based on the feedback I've had, I don't think there would be an outcry at us changing this, but I want to make sure that I haven't missed a community depending on it
[19:02] <mdz> lifeless, in that case, I think all you can do if you want to be more cautious is to wait a while longer and publicize the question more widely
[19:03] <lifeless> mdz: can you suggest a good forum for wider publication ?
[19:03] <mdz> lifeless, you've already hit ubuntu-devel and planet, so I'd say identi.ca and twitter if you haven't already
[19:03] <mdz> lifeless, but frankly, I think it would be reasonable to throw the switch and see what happens, so long as it's easy to back out
[19:03] <lifeless> I'll send something out on those channels today
[19:04] <mdz> AIUI you're doing more runtime feature switches these days to facilitate that sort of thing
[19:04] <lifeless> yes, we can phase it in conservatively with the ability to toggle it off in a second
[19:04] <lifeless> if we're not sure about a change
[19:24] <kees> slangasek: hi, do you have a moment to look at https://code.launchpad.net/~mathieu-tl/ubuntu/natty/plymouth/lsb-release-version/+merge/45095 ? I think it's ready, but since you had reviewed it before, it might make sense for you to double-check it now?
[19:24] <slangasek> kees: <cough> reload the page ;)
[19:26] <kees> slangasek: /me sees no difference....
[19:26] <slangasek> kees: Status: Merged
[19:26] <slangasek> kees: I merged it not 5 minutes ago :)
[19:26] <kees> oh! hah.
[19:27] <kees> okay, I was looking for comments or your review status to change. ;)
[19:27] <kees> excellent timing!
[19:53] <jam> barry: are you still around?
[19:53] <jam> some Q's about pychecker
[19:59] <barry> jam: yep
[20:00] <jam> barry: so, it looks like it was fairly recently converted to v3 format, and before that there *weren't* any debian/patches files
[20:00] <jam> (as of Lucid at least, since 'apt-get source' gave me something without any debian/patches)
[20:00] <barry> interesting
[20:01] <barry> jam: does that make it harder or worse to use as an example?
[20:01] <jam> barry: I'm trying to figure out how things are supposed to be done
[20:02] <jam> I thought I sort of understood debian/patches, but getting something that doesn't have it is both good and bad
[20:02] <jam> good to know that things like this exist
[20:02] <jam> bad because we have to plan for how to handle them
[20:03] <barry> jam: right.  it's considered bad form to add a patch system when there isn't one already, unless you're the debian maintainer
[20:04] <barry> jam: in those cases, we edit the source directly, and the change gets included in a diff.gz file against the original tarball
[20:04] <jam> barry: I always thought it was bad form to edit the source directly :)
[20:05] <barry> jam: as did i, until i chastised for doing it the other way :)
[20:06] <jam> barry: so why don't I see your name in the pychecker history?
[20:06] <jam> ):
[20:06] <jam> :)
[20:06] <jam> silly async hands
[20:08] <jam> barry: so my goal with this is to put together a (possibly fully manual) import of a package, that you could poke around in, and see what you think of
[20:08] <jam> I'd like something that you actively use, if possible
[20:09] <barry> jam: okay, let me find a better example
[20:13] <barry> jam: i guess part of the problem is that the packages i maintain i usually am also the upstream, so i don't tend to use quilt much in them.  where i've interacted b/w quilt and bzr is in projects i've fixed bugs in, i.e. adding patches
[20:23] <jam> barry: I personally don't care about quilt as much as how should the import look
[20:23] <jam> however, I assume you also tend to just fix upstream?
[20:23] <jam> or do you actually do fixes in patches?
[20:23] <jam> cjwatson: are you around ? i realize the timezone is probably pretty bad for you right now
[20:24] <ari-tczew> kees: I tried to encourage Debian maintainer to enable hardening in exim4 but he seems to be not interested :(
[20:25] <SpamapS> kees: thanks for uploading that upstart fix. :)
[20:27] <barry> jam: when i submit branches that fix bugs in ubuntu, i adapt to the package's existing patch system.  if it uses quilt, that's what i use, but it could be one of several different patch systems - or none at all.  i know that probably doesn't help much ;).  the biggest impedance mismatch is where i'm developing a fix in a branch that has a patchsys and i need to submit a new debian/patches file for review.
[20:27] <barry> jam: quilt is a good enough example of that, and this page shows the pain:
[20:27] <barry> https://wiki.ubuntu.com/DistributedDevelopment/Documentation/PatchSystem
[20:28] <kees> SpamapS: you bet; glad to have that all sorted out.
[20:28] <barry> jam: so i think any package that has a set of quilt packages would be decent to start with because it would give a sense of how we *want* to deal with it
[20:28] <kees> ari-tczew: that's too bad :(
[20:30] <jam> barry: I'll read through that.
[20:30] <jam> There are, in fact, several co-mingled issues
[20:31] <jam> one is how to handle 'I want the current tip in a fashion I can easily hack on it'
[20:31] <jam> another is "how do we want to represent the history"
[20:31] <barry> indeed. ;)
[20:32] <barry> jam: if there's a conflict between those two goals, the first is (i think) more important.  a source package's history is largely determined by debian/changelog rather than 'bzr log' if that makes sense
[20:32] <barry> jam: i'm leaving early today, so let's talk again tomorrow
[20:32] <lifeless> barry: the history has an impact on 'merge two branches
[20:33] <jam> barry: what is the "quilt import...; quilt push; quilt pop" ? (Just trying to understand why the multiple steps)
[20:33] <jam> that seem to conflict
[20:34] <barry> lifeless: ah, not something the user cares much about, but the machinery cares a lot about
[20:34] <lifeless> barry: they user cares a lot when merging from debian, or linaro from ubuntu. or linaro from debian
[20:34] <kees> SpamapS: https://code.launchpad.net/~clint-fewbar/ubuntu/natty/mountall/fix-mounted-tmp/+merge/48681
[20:34] <kees> SpamapS: doesn't "env MOUNTPOINT=/tmp" mean the /usr logic will never fire?
[20:35] <barry> jam: 'man quilt' will answer a lot of questions there, but basically think of quilt as a version control system.  it manages a stack of patches.  that's important because sometimes a patch is applied upstream and you can get rid of it in debian/patches
[20:35] <jam> barry: right, but you just imported a patch, and then push and pop it, which seems pretty strange, I guess you talk about it
[20:35] <barry> lifeless: i guess ime, a diff is useful, but debian/changelog tells me more about the history than bzr log does
[20:35] <barry> jam: right.  it *is* strange. :)
[20:36] <jam> barry: also, isn't that to remove the change from the working tree, which isn't what you are supposed to still do?
[20:36] <barry> jam: and i don't know if it's the best way to do it, but it's the only way i found that didn't result in huge gobs of unresolveable conflicts
[20:37] <barry> jam: someone (james_w perhaps?) did recommend that the changes could live in both the source tree and in debian/patches, but i found that confusing
[20:37] <jam> barry: I thought that was the point of v3 quilt
[20:38] <lifeless> barry: by representing history, I think you and jam may mean different things
[20:38] <jam> that it would be in a patch system, but also in the WT, so that you actually build/test against the final code
[20:38] <SpamapS> kees: no that only sets a default value
[20:38] <lifeless> barry: things like 'should patches be a patch file or a changed revision
[20:38] <lifeless> barry: and those changes radically alter the sorts of merge conflicts you get
[20:38] <lifeless> barry: I'm not talking about /bzr log/ output *t all*
[20:38] <barry> jam: right, but most packagers *only* use quilt.  iow, it's there vcs for changing the package.  we essentially have two competing vcses on the same source tree
[20:38] <jam> lifeless: right. and everyone I've talked about seems to have internalized things differently :)
[20:38] <SpamapS> kees: that is so that if somebody runs 'start mounted-tmp' the don't torch all files in / .. might be worth nothing how important it is.
[20:39] <SpamapS> s/nothing/noting/
[20:39]  * SpamapS really should get a new keyboard the typos are getting worse.. :p
[20:39] <kees> SpamapS: heh, okay, cool
[20:40] <barry> jam, lifeless i *really* have to go now, so we'll pick this up again tomorrow.  one thing that may be helpful is to think about not what we have to do today, but what we eventually want it to look like.  in that regard, i don't ever want to deal with the quilt until i have to generate something for external consumption, and then for folks who aren't using udd (read: the debian maintainer)
[20:41] <jam> barry: in my head, it is a "bzr export-loom-to-debian-patches" or something along those lines
[20:41] <kees> SpamapS: should the "cd "${MOUNTPOINT}" gain a "|| exit 0" ?
[20:43] <SpamapS> kees: I don't think so. The logic of the if's will exit 0 on the chance that /usr is mounted before /tmp (there won't be a /tmp/.delayed_mounted_tmp_clean) and this way we flag problems where /tmp isn't accessible.
[20:45] <kees> SpamapS: what about the totally insane case of: system comes up with no /tmp directory, /usr gets mount, entire filesystem is wiped.
[20:46] <SpamapS> kees: upstart scripts are guaranteed to run with set -e .. but I agree.. hggdh brought up that it is a bit scary that set -e is our only guard.. so maybe even || exit 1 is better.
[20:46] <kees> cool
[20:47] <SpamapS> want me to a) add a comment to the env statement, and b) add the || exit 1 and re-push ? Or do you just want to do that and upload?
[20:47] <kees> SpamapS: I'll just add it and push/upload. easy fixes.
[20:48] <SpamapS> kees: once again, thanks for the reviews and uploads.
[20:48]  * SpamapS thinks there must be a UTF-8 character for "gratitude"
[20:48] <kees> SpamapS: you bet! :) thanks for the fixes :)
[20:50] <ari-tczew> kees: exim4 updated
[20:50] <ari-tczew> guess your browse remember bug number ;-)
[20:50] <ari-tczew> s/browse/web browser
[20:52] <kees> ari-tczew: yup, thanks, I'll go re-check.
[20:54] <ari-tczew> kees: when you have done exim4, would be nice to get this one https://code.launchpad.net/~bkbox/ubuntu/maverick/munin/fix-for-699967/+merge/48984
[21:40] <amitk> bryceh: hey bryce, around?
[21:42] <amitk> bryceh: I'm running latest natty with an nvidia GeForce 8400. Nouveau was giving several problems, so I decided to try the binary driver (nvidia-current). Now X doesn't start any more and uninstall the binary driver doesn't help either. Any suggestions?
[21:43] <RAOF> amitk: Uuurgh.
[21:44] <amitk> RAOF: i know, bad idea :-/
[21:44] <RAOF> amitk: Installing the binary driver has probably uninstalled X.  nvidia-current doesn't support the X server we have in natty at the moment (and the dependencies are a little messed up), so the xserver declares a Breaks: on nvidia-current.
[21:45] <amitk> RAOF: really?!!! /me checks
[21:45] <RAOF> (Or, technically, on xserver-xorg-video-8, which nvidia-current Provides:)
[21:46] <amitk> RAOF: you're right, apt-get install xorg is installing a lot of stuff
[21:49] <amitk> RAOF: thanks, X is back :)
[21:49] <RAOF> :)
[21:50] <kees> coming out of hyperdrive now...
[21:51] <kees> @pilot out
[21:51] <amitk> RAOF: how well are the discrete ATI cards supported? I need something other than nouveau
[21:51] <RAOF> amitk: If you've got something less new than a Radeon X6800 it should be fully supported.
[21:52] <RAOF> (By the open drivers.  Again, no proprietary fglrx for Xserver 1.10 yet)
[21:52] <ari-tczew> kees: FYI, it could be ubuntu3 for SRU
[21:52] <ari-tczew> because natty is 3ubuntu2
[21:52] <kees> ari-tczew: it _can_ be, but it should not be.
[21:53] <ari-tczew> kees: strange
[21:53] <kees> best to just stick to the common convention to avoid needing to consider collisions.
[21:53] <ari-tczew> but no problem for me
[21:53] <kees> for example, I can give you a case where this caused a problem:
[21:54] <kees> maverick release, natty opened for development
[21:54] <kees> some SRUs went through into maverick and were distro-copied to natty
[21:54] <kees> so maverick and natty had the same versions
[21:54] <kees> they were, say ubuntu2 then ubuntu3. then natty gets a "real" bump to ubuntu4.
[21:55] <kees> on the next SRU to maverick, following the package convention, it also tried to do ubuntu4, but that collides with natty
[21:55] <ari-tczew> kees: nope. maverick - 1ubuntu2, natty -3ubuntu2
[21:55] <kees> ari-tczew: right, in this case it's not a problem. I'm saying that when reviewing patches and doing sponsorship, it's best to set a good example and follow the expected conventions on package versioning.
[21:56] <ari-tczew> kees: ok understand.
[21:56] <ari-tczew> ;]
[21:56] <kees> :)
[22:01] <achiang> kees: i've a question re: chromium-browser... v8 is in maverick-security (i think), but i don't see a .orig.tar.gz here --- http://ports.ubuntu.com/pool/universe/c/chromium-browser/
[22:03] <kees> achiang: hm, looking
[22:04] <kees> achiang: I think the orig would just be in the regular archive.
[22:04] <achiang> kees: ah, interesting. thanks
[22:04] <kees> achiang: should be findable on LP though: https://launchpad.net/ubuntu/+source/chromium-browser
[22:05] <achiang> kees: actually, i don't see it here either -- http://archive.ubuntu.com/ubuntu/pool/universe/c/chromium-browser/
[22:05] <achiang> kees: i guess we don't actually want v8 anywhere
[22:06] <achiang> because it doesn't appear in LP either
[22:06] <kees> achiang: yeah, looks to just be v9
[22:06] <achiang> kees: thanks!
[22:07] <kees> achiang: you should still be able to dig it out of https://launchpad.net/ubuntu/+source/chromium-browser/+publishinghistory
[22:07] <achiang> kees: nope, the latest is what i want, so v9 is perfect
[22:07] <kees> achiang: e.g. https://launchpad.net/ubuntu/maverick/+source/chromium-browser/8.0.552.237~r70801-0ubuntu0.10.10.1
[22:07] <kees> achiang: okay, cool
[22:08] <achiang> thanks again
[22:20] <szymon_g> hi
[22:20] <szymon_g> could anyone tell me what are default cflags for ubuntu 32bit 10.10/11.04 :?
[22:21] <szymon_g> is it, despite its name (-386) still runable on that architecture /apart from performance issues etc/- thats theorotical question
[22:22] <micahg> szymon_g: minimum arch for x86 is 686 in Ubuntu now
[22:23] <szymon_g> micahg, is it the same for the current one and the next one, or was it changed somehow? have you got a link to documentation etc about that /i discuss that on one of forums, i need a 'hard proof'/ :?
[22:23] <szymon_g> ah, thanx for answer btw (my manner :/)
[22:24]  * micahg looks for the pertinent mail on ubuntu-devel
[22:25] <micahg> szymon_g: https://lists.ubuntu.com/archives/ubuntu-devel/2010-July/031020.html
[22:26] <szymon_g> oh, great thanx micahg!
[22:26] <micahg> szymon_g: you're welcome
[22:26] <szymon_g> btw, if may i ask: why the name is still 386? if can be (well.. it is) a bit confusing...
[22:27] <micahg> szymon_g: legacy, Debian's default is 486, but we just call the platform i386
[22:27]  * szymon_g still doesn't understand why not to call it simply i686 ;)
[22:29] <broder> szymon_g: it's mostly because the string "i386" is baked into a lot of places, and changing it would be a huge ordeal
[22:33] <hallyn> is there a 'dh_installxyz' command to install /etc/default files?  I know debian/package.default will get handled, but the package ships with a /etc/default/xyz file in its base directory, I'm wondering how to best get that installed
[22:33] <broder> hallyn: i think dh_installinit handles default files
[22:34] <broder> but what's wrong with just using dh_install for that?
[22:34] <hallyn> broder: just that the file ships in the package's base dir.  should i just copy it into debian/ in a pre-build step?
[22:34] <broder> dh_install can pull from the root of the package
[22:34] <hallyn> i don't want to copy it myself and riskit getting otu of sync
[22:35] <hallyn> broder: that's what i was hoping.  so you say dh_installinit?  lemme go re-read that one
[22:35] <broder> no, dh_install
[22:35] <broder> there's no reason to treat the file specially. it's in one place, you want it in another place, that's what dh_install does
[22:36] <hallyn> broder: ok.  i was afraid there might in fact be a reason to treat is specially
[22:36] <hallyn> (namely, perms/ownership)
[22:36] <hallyn> broder: i'll do that then, thanks!
[22:37] <broder> perms and ownership are all handled by dh_fixperms anyway
[22:37] <broder> dh_installinit doesn't do anything special to the default file it copies over
[22:37] <highvoltage>  /win 26
[22:38] <hallyn> and so the first place dh_install looks for the file is the package topdir?