[00:20] <melodie> gn
[03:29] <pitti> Good morning
[03:37] <kees> heya pitti!
[03:37] <pitti> hey kees, how are you?
[03:37] <kees> good, you?
[03:38] <pitti> quite fine, thanks!
[03:38] <kees> I'm excited to see everyone next week :)
[03:38] <pitti> kees: ah, you'll be on UDS? great!
[03:38] <infinity> Oo, you're coming?
[03:38] <kees> yup! quick hop down the coast :)
[03:38] <infinity> kees-sponsored beer BoF?
[03:39] <kees> I need to present my new "survive my USB stick" challenge :P
[03:39] <infinity> Sounds dirty.
[03:39] <kees> dunno about _sponsored_, but drinking BoF I'll attend.
[03:39] <kees> "survive inserting this USB stick and I won't laugh at you" ?  not a good ring to it.
[03:40] <kees> anyway, should be fun
[03:40] <infinity> I'm not sure I want to take part in this challenge.
[03:40] <infinity> Sounds sketchy.
[03:40] <kees> I didn't weaponize it too much!
[03:40] <infinity> That's not comforting. ;)
[03:40] <kees> hehe
[03:41] <slangasek> yeah, it's really disappointing
[03:41] <kees> how about "tell me what this USB stick is?"
[03:42] <kees> and slangasek can't help!
[03:42] <slangasek> heh
[03:42] <slangasek> that's fine, I'm too busy screaming at startpar anyway
[03:42] <kees> haha
[03:43] <kees> I'm still trying to right myself after spinning in circles to make some changes to klibc actually build
[03:43] <slangasek> my upstart startpar changes were never tested with a job that starts and immediately stops again on boot
[03:43] <slangasek> so of course the first package I look at trying to submit upstart patches to Debian for does exactly that (anacron)
[03:44] <kees> argh
[03:44] <slangasek> now to figure out which part of the startpar code the race is in
[03:44] <kees> "I'll start with 'a'!" urf
[03:44] <slangasek> it was actually one that was on my TIL merge list :)
[03:45] <kees> in other news, some additional hardening updates from Debian are trickling into quantal now. fun to watch! http://outflux.net/ubuntu/hardening/
[03:47] <kees> and at current rates, debian will catch up with ubuntu on the package build hardening front some time in early 2014 http://outflux.net/debian/hardening/
[03:50] <infinity> kees: What issues were you having making klibc build?
[03:50] <kees> infinity: just trying to figure out how to correctly refer to a library in a different directory.
[03:50] <kees> infinity: I ended up realizing there was another place I could copy the logic from.
[03:51] <kees> but I get dizzy any time I watch klibc build :)
[03:51]  * infinity notes that the SWE bar appears to have been lowered.
[03:51]  * infinity ducks.
[03:51] <kees> sick burn!
[03:52] <infinity> Okay, so maybe it'll be an Adam-sponsored beer BoF after I took that cheap shot. ;)
[03:52] <kees> hehe
[04:17] <slangasek> oh, that startpar bug was much simpler than I thought
[04:17] <slangasek> just needs listen() to have a backlog so we don't miss incoming upstart connections :P
[05:40] <scientes> how am i suppose to version something that hasn't been released and is coming from git?
[05:40] <scientes> i can do `git rev-parse --short HEAD` to get a g<sha1>
[05:40] <scientes> but howabout the date?
[05:41] <scientes> and do i need to do all this wierism to generate a orig.tar.gz?
[05:41] <scientes> or can it just work natively with git and branches somehow?
[05:42] <chilicuil> nice question scient.es I'd like to read the answer too
[05:43] <scientes> I'm tempted to just make it a native debian package
[05:43] <scientes> but that doesn't seem like the right thing to do
[05:43]  * micahg thanks infinity for the devscripts update
[05:49] <RAOF> scientes: Generally one does $LAST_RELEASE+git20120504.$SHA or $NEXT_RELEASE~git20120504.$SHA (with 8-char shas)
[05:49] <scientes> RAOF, and if no releases, 0.0.1 ?
[05:49] <TheMuso> 0.0.0
[05:49] <scientes> and that date is the packaging date, not the last commit date?
[05:50] <TheMuso> tahts what I've done in the past.
[05:50] <RAOF> Either.
[05:50] <TheMuso> so 0.0.0+git20120504 for example.
[05:50] <scientes> ok, so back to the original question, its east to use rev-parse to get the sha1 of of a refspec, but how about the date of that refspec?
[05:50] <RAOF> You can also just to “0+git”, because 0.$POSITIVE > 0+git
[05:51] <scientes> git show --format=format:"" didn't seem to have anything useful
[05:51] <RAOF> git log will give you the commit date.
[05:51] <scientes> and do i use git archive to make an orig.tar.gz?
[05:52] <RAOF> But if you want to automate the whole shebang... you can see xserver-xorg-video-nouveau's get-orig-source target.
[05:52] <scientes> RAOF, finially there is an answer
[05:54] <scientes> RAOF, where? http://anonscm.debian.org/gitweb/?p=pkg-xorg/driver/xserver-xorg-video-nouveau.git;a=tree
[05:54] <scientes> oh i see it
[05:54] <scientes> http://anonscm.debian.org/gitweb/?p=pkg-xorg/driver/xserver-xorg-video-nouveau.git;a=blob;f=debian/rules;h=de4cc9c4a2ffa2c437eb3a2eb614f5845b9e50dd;hb=HEAD
[05:54] <RAOF> debian/rules, get-orig-source:
[05:54] <RAOF> sudo build-me-a-tarball
[05:55] <scientes> sudo make me a sandwich :_
[05:55] <scientes> :)
[05:56] <micahg> just as long as it's not little bobby tables :)
[05:58] <RAOF> Eh.  We all do proper input sanitisation, right? :)
[06:02] <scientes> RAOF, why do you clone fresh every time? why not --reference=. ?
[06:02] <RAOF> scientes: Because that target is meant to ensure that an arbitrary person can get a tarball; it can't rely on anything outside of the package.
[06:03] <scientes> ahh, that why not git archive
[06:03] <scientes> to export
[06:03] <RAOF> Probably because at the time I wrote that I was sick of wrangling git to do what I wanted. :)
[06:04]  * scientes loves git
[06:04]  * scientes doesn't like seeing all the deduplication features of git go to waste
[06:10] <doko> SpamapS, http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=667198
[06:16] <BenC> kirkland`: Will you or any other @canonical.com's me at FTF in San Antonio next month?
[06:16] <BenC> *be
[06:21] <infinity> BenC: kirkland's not a Canonical employee anymore.
[06:22] <BenC> infinity: Ah, lots happens in a year..
[06:22] <BenC> infinity: Who's in charge of the server team now?
[06:23] <BenC> or would otherwise care about my question :)
[06:24] <infinity> BenC: Daviey, though I suspect he's not planning to be in San Antonio.  He may know if someone else is. :P
[06:24] <infinity> BenC: Or SpamapS may know.
[06:26] <BenC> infinity: ok, thanks
[06:42] <dholbach> good morning
[06:57] <dupondje> E: changelog for this version is not (yet) available; try https://launchpad.net/ubuntu/+source/cyrus-sasl2/+changelog
[06:57] <dupondje> but they are available ...
[06:57] <micahg> dupondje: yes, but are they on changelogs.ubuntu.com?
[06:59] <dupondje> ah nope :)
[06:59] <dupondje> tought it was looking @ the launchpad page, but its an alternative :)
[06:59] <dupondje> should parse the launchpad page ^^:)
[07:10] <erle-> how about computer janitor clearing /var/cache/apt?
[09:24] <micahg> dholbach: python-levenshtein shouldn't have been sync'd, can you readd the dh_python2 diff please?
[09:24] <dholbach> hum
[09:25] <micahg>  - use python-support instead of python-central; Closes: #617011
[09:26] <dholbach> will do - I clearly didn't look closely enough
[09:26] <micahg> thanks
[09:36] <cjwatson> pitti: aha!  thank you for tracking down bug 909292, as I'm pretty sure that's what was giving me grief in ubiquity
[09:36] <cjwatson> fortunately I hadn't spent too much time on it yet
[09:36] <pitti> cjwatson: indeed, I'm getting all sorts of bug reports on that
[09:36] <cjwatson> merely stared at the screen in a baffled kind of way
[09:36] <pitti> it seems 90% of the incoming reports with py3 are due to that
[09:37] <pitti> that <censored> bug took me some 15 hours to track down..
[09:37] <pitti> cjwatson: so does it work with the -proposed version now?
[09:38] <cjwatson> I'm just updating to that now to se
[09:38] <cjwatson> e
[09:41] <pitti> cjwatson: you are porting ubiquity to py3?
[09:47] <cjwatson> pitti: yep
[09:48] <cjwatson> pitti: I have a decent number of the tests passing, but still lots more to do
[09:48] <pitti> I'm about 95% done with apport now
[09:48] <pitti> I still need python3-xdg and python3-launchpadlib, but most code can deal without these
[09:49] <pitti> it's so much fun untangling bytearrays and strings..
[09:49] <cjwatson> I need python3-pyicu, but I've sent a patch for that to Debian
[09:49] <cjwatson> (well, which I need to correct it seems, but)
[09:50] <cjwatson> also usb-creator, I think it's rather easier
[09:50] <cjwatson> python3-launchpadlib is ultimately blocked on oauth
[09:50] <cjwatson> barry's spreadsheet (IIRC) suggests switching to oauth2
[09:50] <pitti> ah; it seems wadllib and many lazr modules are already available
[09:51] <cjwatson> Yeah, I did part of that last cycle before running out of time and blocking on oauth
[09:51] <cjwatson> I think we're close to a tipping point for a lot of Ubuntu-specific things - just a few more libraries
[09:52] <cjwatson> I'm *very* keen to port ubiquity because we've had so many undetected Unicode errors in the past, and Python 3 will force those front and centre
[09:52] <pitti> yeah, I noticed the same in apport
[09:53] <pitti> it essentially needs to handle both kinds, so adding a few more test cases was enough to trigger a gazillion errors from running it
[09:53] <pitti> instead of waiting on the crash reports to come in
[09:53] <cjwatson> code that needs to handle both is a pain ...
[09:53] <dholbach> micahg, done
[09:53] <micahg> thanks
[09:54] <pitti> what annoys me is that there is no simple way of checking whether an object is a "string", you need separate py2/py3 cases there
[09:54] <cjwatson> most of our archive tools should be ready once python3-debian and python3-launchpadlib are available
[09:54] <cjwatson> porting Launchpad will be interesting ;-)
[09:55] <cjwatson> pitti: isinstance(foo, six.string_types)
[09:55] <pitti> and I'm using gems like b'a\xe2\x99\xa5b'.encode('UTF-8') to get a constant unicode string in the tests
[09:55] <cjwatson> if you're willing to depend on python{,3}-six
[09:55] <doko> I'll need to get the distribute ready for 3.3 ...
[09:55] <pitti> instead of a simple "a♥b'
[09:55] <cjwatson> pitti: from __future__ import unicode_literals
[09:56] <cjwatson> (changes semantics of all literal strings in the file, but that's often OK for tests)
[09:56] <pitti> cjwatson: ah, that makes "a" what used to be u"a"?
[09:56] <cjwatson> indeed
[09:56] <pitti> ah, good
[09:56] <cjwatson> works with >= 2.6
[09:56] <pitti> cjwatson: yes, that's fine, as the code needs to work with both 2 and 3 anyway for a fair while
[09:57] <pitti> cjwatson: thanks for the hint
[09:57] <pitti> but most of the time I must say it's workable
[09:57] <cjwatson> barry reckons most Python files should start with 'from __future__ import absolute_import, print_function, unicode_literals', I gather
[09:57] <pitti> I just found one thing for which there is absolutely no compatiblity between the two
[09:58] <cjwatson> personally I think unicode_literals can be difficult outside tests, at least if there's an API to preserve
[09:58] <cjwatson> pitti: oh?
[09:59] <pitti> http://bazaar.launchpad.net/~apport-hackers/apport/trunk/view/head:/apport/REThread.py#L64
[09:59] <cjwatson> pitti: six.reraise
[09:59] <pitti> the syntax for re-raising an exception object changed, and neither version accepts the syntax of the other
[09:59] <pitti> cjwatson: yeah, external dependency again
[09:59] <cjwatson> which indeed uses the same exec hack, but at least it makes it somebody else's problem :)
[10:00] <pitti> I've got quite a few "if sys.version ..." comparisions anyway, at least they are greppable
[10:00] <cjwatson> I'm using six in ubiquity, on the grounds that once we're comfortable with ditching py2 compat there it'll be easy to drop
[10:00] <pitti> ("grepable"?)
[10:00] <cjwatson> greppable, I think :)
[10:01] <cjwatson> and I ended up using six in my python-debian port as well, because it was far too much trouble not to
[10:01] <pitti> cjwatson: http://www.googlefight.com/index.php?lang=en_GB&word1=grepable&word2=greppable disagrees :)
[10:01] <cjwatson> pitti: bah
[10:01] <cjwatson> so far in update-manager I've managed to get away without
[10:02] <cjwatson> I seem to be working on the stuff that starts with 'u' :-P
[10:02] <pitti> I'm just a bit wary of introducing more dependencies, as this stuff needs to run in chroots, the data center, stable releases, etc.; asking for -six might not be too much trouble, but I could avoid it
[10:02] <cjwatson> yeah, apport is perhaps a special case
[10:03] <cjwatson> update-manager has to be a bit careful as well due to the dist-upgrader tarball
[10:03] <pitti> cjwatson: U> don't we all? :-)
[10:04] <cjwatson> in retrospect, I'm very glad that lucid had python 2.6 and python-apt (pre-)0.8
[10:05]  * cjwatson unbreaks rmadison, sorry about that
[10:05] <cjwatson> (cleaned up a local ~/bin/ script which was also installed in /usr/bin/; didn't notice madison.cgi was using it)
[10:08] <cjwatson> pitti: confirmed that this python3.2 fixes my segfaults
[10:08] <pitti> \o/
[10:08] <pitti> one bug to rule them all
[10:09] <cjwatson> usb-creator-gtk actually manages to show its UI now; ubiquity gives me a TypeError, but that's just next in the list ...
[10:09] <cjwatson> (nothing to do with ctypes, I think)
[10:10] <dholbach> hum, somehow my python-levenshtein upload didn't make it to LP?
[10:10] <doko> cjwatson, it was the libffi_pic.a library linked to the python3 executable
[10:11] <dholbach> ah no, there it is
[10:11] <dholbach> *phew*
[10:11] <cjwatson> doko: I meant my TypeError in ubiquity was nothing to do with ctypes :-)
[10:11] <cjwatson> but previously I had the segfault you just fixed
[10:26] <micahg> dholbach: you might want to have a look at this: http://wiki.debian.org/Python/PythonSupportToDHPython2, meh, not your fault, last diff was wrong as well :)
[10:27] <micahg> dholbach: it's no worse than before at this point
[10:27] <dholbach> ok
[10:27] <eagles0513875> hey Sweetshark do you happen to have a link to the launchpad bug or upstream make bug in regards to the parallell issue in make 3.81 cuz i would really like to push a bump up to 3.82 for this release cycle if possible
[10:28] <micahg> eagles0513875: I thought I already mentioned it's in debian experimental
[10:28] <eagles0513875> micahg: thats what im confused on now is in regards to what repos are being pulled from according to this link https://lists.ubuntu.com/archives/ubuntu-devel/2012-April/035155.html
[10:29] <micahg> eagles0513875: right now testing, TBD at UDS, merges/syncs from other repos as needed
[10:30] <eagles0513875> micahg: i understand as well that its in experimental just want to backup my push for 3.82 with the bug report
[10:32] <eagles0513875> micahg: here is the bug report to backup why i want to get us bumped up to 3.82
[10:32] <pitti> \o/ apport test suite now fully works for both python 2 and 3
[10:34] <eagles0513875> micahg: :D seems like the fix made it into the upstream package :)
[12:48] <ogra_> bdrung, seeing you are in debian-multimedia and that you have done the last audacious-plugins upload, would you mind pulling cjwatson's b-dep fix from precisce-proposed into the debian package ?
[12:48]  * ogra_ had some arm users asking about it in precise and just noticed the fix in -proposed
[12:50] <cjwatson> I'd forgotten about that, should stick it in -updates/quantal
[12:51] <zaytsev> hi folks... i'm remastering the livecd which is later intent to transform into a live usb. what's the correct way to prevent ubiquity from starting on boot?
[12:51] <cjwatson> don't pass any of the *-ubiquity boot args
[12:51] <zaytsev> i know i can just remove --purge ubiquity, but this will also remove it copletely and kill the desktop icon
[12:51] <ogra_> cjwatson, well, i dont think an upload to quantal makes sense, debian will benefit from it too
[12:52] <zaytsev> cjwatson: so i remove only-ubiquity from isolinux/txt.cfg ?
[12:52] <ogra_> its not that we are late in the release yet :)
[12:52] <cjwatson> ogra_: it's in -proposed, it should go somewhere
[12:52] <ogra_> oh, indeed, -updates for sure
[12:52] <cjwatson> and -updates should <= quantal
[12:52] <ogra_> yeah
[12:52] <cjwatson> it's easy to sync later
[12:52] <ogra_> k
[12:52] <cjwatson> zaytsev: sounds right
[12:53] <cjwatson> zaytsev: well
[12:53] <cjwatson> zaytsev: maybe also drop hidden-timeout=whateveritis from /isolinux/gfxboot.cfg
[12:54] <zaytsev> cjwatson: ok, thanks, but when i will make an usb out of it, will i also have to modify syslinux somehow, or this will work too?
[12:54] <cjwatson> should work with the same configuration
[12:55] <zaytsev> cjwatson: ah thanks for the gfxboot tip, it seems that i should just make it chose live instead of live-install and this will also keep the original functionaity
[12:55] <zaytsev> cjwatson: awesome thanks a lot man
[12:56] <cjwatson> no problem
[12:58] <cjwatson> audacious-plugins looks plausible in -proposed, promoting now
[13:01] <ogra_> great
[13:04] <bdrung> ogra_: done: http://anonscm.debian.org/gitweb/?p=pkg-multimedia/audacious-plugins.git;a=commitdiff;h=fed6c9546ebd5b94eab42d1f70f8c011ec80c772
[13:06] <cjwatson> bdrung: ta
[13:06] <cjwatson> sorry I didn't forward that, it was in the middle of release crunch
[13:06] <bdrung> cjwatson: no problem and no need any more :)
[13:07] <ogra_> awesome !
[13:07] <bdrung> ogra_: that was an easy and quick task :)
[13:33] <ScottK> sabdfl: Rev 24 of the revised CoC resolves the concern I expressed in yesterday's CC meeting.  Thanks.
[13:34] <barry> cjwatson, pitti everything work out okay? :)
[13:34] <cjwatson> so far
[13:35] <barry> great!
[13:36] <cjwatson> ScottK,sabdfl: yep, me too
[13:50] <stgraber> xnox: if you want to help with the nagios-nrpe sru validation, they're all in now
[13:51] <xnox> stgraber: ok.
[14:24] <bigon> hi, any idea what's the licence for the circle of friend logo?
[14:31] <sladen> bigon: the files themselves should be CC-BY-SA.  How you use it depends on trademarks
[14:31] <sladen> bigon: what are you trying/wanting to do?
[14:34] <bigon> sladen: gnome-boxes is including the circle of friend
[14:34] <bigon> and I'm trying to figure out if it could be included into debian
[14:34] <bigon> sladen: ^
[14:37] <sladen> bigon: http://launchpad.net/ubuntu-branding/+filebug?field.title=gnome-boxes+licence+of+CoF+for+Debian
[14:38] <sladen> bigon: and I'll try and sort you out one under whatever licence needed (thought content should be CC-BY-SA anyway)
[14:38] <ScottK> sladen: If the license is Debian specific, it's not DFSG free.
[14:39] <ScottK> So, to avoid questions, make it license and not license for Debian.
[14:39] <ScottK> A license for Debian doesn't help.
[14:39] <SpamapS> doko: ACK, I'll get on it. There's a new upstream to package as well.
[14:40] <bigon> CC-BY-SA is DFSG
[14:42] <sladen> I believe what ScottK was kindly attempting to point out is that "a Licence for one organisation" would fail DFSG #5, however what we would do is to ensure that the upstream version of gnome-boxes had licensing that was clear enough for everyone.  If it isn't then that's where the failure is and where we need to get it fixed
[14:42] <ScottK> Trying, perhaps not very well.
[14:43] <sladen> bigon: however regardlessly, it would be good to have a place to track this
[14:43] <sladen> bigon: with longer-longevity than IRC scollback
[14:45] <bigon> https://bugzilla.gnome.org/show_bug.cgi?id=671251
[14:45] <bigon> there is already an upstream bug open for that
[14:47] <sladen> bigon: even better, ta.  (BTW, if it's often useful to mention/paste the upstream URL first as it helps everyone get up to speed with better context)
[14:47] <bigon> yeah sorry
[14:52] <bigon> so for my part what should I do? ask gnome-boxes upstream to get a licences for the project?
[14:53] <bigon> (or I didn't understand?)
[14:55] <arand> bigon: I think a restrictive trademark policy might be able to fail the DFSG as well, http://www.ubuntu.com/aboutus/trademarkpolicy is probably what would have to be scrutinized, if anything.
[14:55] <bigon> (yeah I was thinking about firefox/iceweasel thing)
[14:56] <bigon> I'm opening a bug on the LP
[14:56] <arand> Though then again, the debian swirl would likely fail that test as well :) I've heard there's onging work there though...
[14:56] <sladen> bigon: I've added  https://bugzilla.gnome.org/show_bug.cgi?id=671251#c10
[14:57] <sladen> bigon: is that sufficient?
[14:57] <xnox> How to do a local [s|de|pde]build *with* pkg mangler and/or debug symbol generator?
[14:57] <sladen> bigon: Zack's current intention/wish I believe is to move all restrictions over to being trademark based
[14:58] <tumbleweed> xnox: mk-sbuild will install pkgbinarymangler
[14:58] <tumbleweed> but basically, you just install it in the chroot
[14:58] <xnox> tumbleweed: awesome =) thanks.
[15:01] <bigon> sladen: let's hope :) thx
[15:01] <bigon> arand: well there is 2 logo for debian one official and one non official http://www.debian.org/logos/
[15:08] <sladen> bigon: slightly more complicated than that.  There are four (main) variations.  swirl;  swirl + text;  wine bottle;  wine bottle with text
[15:08] <sladen> bigon: those with text are covered by trademarks.  Those with the wine bottle may only be used by DDs
[15:09] <bigon> yeah I was to fast to read
[15:15] <cjwatson> pitti: Is there a useful equivalent of python-gi-dev for Python 3?
[15:15] <cjwatson> pitti: Or do I just keep on using python-gi-dev?  It's a bit confusing that it Depends: python-gi
[15:29] <zaytsev> cjwatson: i'm still confused with isolinux. so it says default live, which is the "try ubuntu" entry and doesn't have only-ubiquity (unlike "install ubuntu"), however, when i boot maybe-ubiquity gets added to the parameters and it shows up
[15:30] <zaytsev> cjwatson: but what confuses me particularly is that when i press some key and select the menu with enter, it doesn't get added and everything works
[15:30] <cjwatson> You didn't remove hidden-timeout
[15:30] <cjwatson> Like I said
[15:30] <zaytsev> cjwatson: right, but if i remove it then i will have to select an item by hand, right? this is not what i want
[15:31] <cjwatson> You can still have a timeout
[15:31] <cjwatson> Do you actually want the splash screen?
[15:32] <zaytsev> cjwatson: well yes, this would be nice, i want it to work exactly as it works now, but wihtout ubiquity showng up. except that something evil adds maybe-ubiquity to the parameters if i don't select the item by hand and so it gets triggered
[15:32] <cjwatson> It's possible you'll need to rebuild the gfxboot theme, then
[15:32] <zaytsev> cjwatson: i grepped isolinux for maybe and it seems to be in bootlogo
[15:32] <cjwatson> It's in the gfxboot-theme-ubuntu source package; the patch I expect you want is http://paste.ubuntu.com/967136/
[15:33] <zaytsev> cjwatson: is it checksommed? maybe i'll just hack it with the hex editor?
[15:33] <cjwatson> No, that's almost certainly seventeen orders of magnitude more pain than doing it properly
[15:33] <cjwatson> Apply that patch, build binary package, fish out bootlogo from binary package, replace
[15:34] <zaytsev> cjwatson: ok thanks for the patch, i'll do both at the same time and see what finished first :-)
[15:34] <cjwatson> If you're building a derived distribution, I rather hope you're comfortable with building packages :)
[15:55] <alexbligh1> openjdk-headless on lucid contains the library /usr/lib/jvm/java-6-openjdk/jre/lib/rt.jar. I want to get the EXACT source this was built from. apt-get source says 'http://bazaar.launchpad.net/~openjdk/openjdk/openjdk6'. On executing the bzr get indicated, it retrieves a directory with no versioning and no .java files. How does one retrieve this?
[15:58] <alexbligh1> More precisely I'm looking for ChunkedOutputStream.java
[15:58] <infinity> alexbligh1: If you want the exact source, you want 'apt-get source openjdk-headless'
[15:59] <infinity> (Though, I assume you mean openjre-headless)
[16:00] <infinity> Or, openjdk-6-jre-headless, even. :P
[16:01] <cjwatson> And ignore the bzr branch it tells you to get, if it's wrong.
[16:01] <cjwatson> Or not useful.
[16:02] <infinity> I'm all for ignoring it, full stop, if the goal is seeing the "exact source used to build the binaries", since that's always the source package.
[16:03] <cjwatson> Yep.
[16:04] <cjwatson> yofel: Did anyone ever verify that last-minute software-properties upload to precise-proposed?
[16:05] <cjwatson> It'd be nice to get that synced up in precise-updates/quantal.
[16:07] <yofel> cjwatson: I did, just forgot it wasn't yet out to precise
[16:07] <alexbligh1> infinity, that's what I would have thought, but that doesn't seem to be the case
[16:07] <yofel> thanks for the reminder
[16:07] <cjwatson> alexbligh1: How do you mean?
[16:07] <cjwatson> There's no other way binaries get into the archive.
[16:07] <alexbligh1> infinity, I am looking for the file 'sun/net/httpserver/ChunkedOutputStream.java' which is used to build rt.lib, which is provided by openjdk-headless
[16:08] <alexbligh1> And though rt.lib is (somehow) built by that file, it does not contain the class
[16:08] <alexbligh1> openjdk-6-source (which is not a source package) has a zip file in, which has that file in, which has a bug in.
[16:09] <alexbligh1> I just don't understand how the java stuff is built
[16:09] <alexbligh1> jar tf on rt.lib shows that class file was (somehow) used to build the rt.lib in it.
[16:09] <cjwatson> After getting the openjdk-6-jre-headless source package, cd to the directory it gives you and run 'debian/rules patch'.
[16:09] <cjwatson> Then you'll find that file in build/openjdk/jdk/src/share/classes/sun/net/httpserver/ChunkedOutputStream.java .
[16:10] <cjwatson> (That debian/rules target is run as part of dpkg-buildpackage, pre-build)
[16:11] <cjwatson> (I don't actually know anything about OpenJDK as such, just wrangling the build targets, so don't ask me for OpenJDK-specific advice ...)
[16:11] <alexbligh1> cjwatson, thanks. I am missing some build-depends but will sort that out.
[16:11] <alexbligh1> cjwatson, me neither :-)
[16:15] <alexbligh1> I am very much hoping the answer is 'but you can just install the precise openjdk on lucid' but I think I may be in library hell/
[16:26] <alexbligh1> cjwatson, thanks. Does Lucid take bugfixes to thing like Java? Specifically this one: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6744329 which claims to be released in 6u18(b03) but is mysteriously absent in the Ubuntu .20 point release.
[16:28] <infinity> alexbligh1: We'd SRU for things like that, sure.  File a bug with a pointer to the patch.
[16:29] <alexbligh> l
[16:32] <infinity> @pilot in
[16:36] <alexbligh1> infinity, thanks, will do
[16:38]  * dholbach hugs infinity
[16:43]  * xnox winks at infinity
[16:43] <infinity> Is it getting hot in here, or is it just me?
[16:43] <dholbach> haha
[16:45] <infinity> dholbach: Hey, in exchange for piloting goodness, you can totally install all the precise-proposed packages from http://pad.lv/994208 and leave verification feedback on the bug, right?  Thanks. ;)
[16:46] <dholbach> infinity, man, I was just about to head out
[16:46] <dholbach> and use emacs?
[16:47] <dholbach> what else?
[16:47] <infinity> dholbach: *snicker*
[16:47] <infinity> I don't think I've had emacs installed for over a decade.
[16:47] <infinity> Going on two, actually... Last time I used it extensively was university.
[16:47] <infinity> PS: I'm old.
[16:49]  * xnox starts emacs with init
[16:49] <infinity> Heathen.
[16:49] <infinity> I bet your terminals have white backgrounds too.
[16:49] <Chipzz> I heard once you can actually chsh /usr/bin/emacs
[16:50] <Chipzz> (or whatever the exact path is)
[16:50]  * dholbach starts to panic and looks for exit signs
[16:50] <Chipzz> haha lol vim fan here :)
[16:51] <Chipzz> but... *off-topic* :P
[16:52] <xnox> infinity: http://ethanschoonover.com/solarized
[16:55] <infinity> This dude takes his colours rather seriously...
[17:05] <roaksoax> smo/win 6
[17:10] <csgeek> is there a live stream of UDS ? I can't make it out there 'till Friday.  I was hoping I could catch some of what's going on
[17:13] <slangasek> mvo: 993190> this discussion again? :-)
[17:13] <slangasek> mvo: we already don't show any debconf prompt on a stock desktop system
[17:13] <slangasek> mvo: it's only when users have extra services installed that the prompt shows up
[17:19] <infinity> mvo: There's "auto-expand-termimal" code?  I've never actually seen that happen. :P
[17:20] <cjwatson> It only happens if libgtk2-perl (or similar) is missing when update-manager starts, not when it's deconfigured or worse at the point when debconf actually needs to ask a question.
[17:20] <cjwatson> It's a startup check.
[17:20] <cjwatson> So it's no use for Perl transitions.
[17:22] <zaytsev> cjwatson: sorry, was distracted; patching bootlogo with a hex editor took 2 sec and works as a charm, i would go the hard way, but it's all your canonical people fault: i've got so used to launchpad that i don't even have pbuilder set up locally ;-)
[17:24] <cjwatson> as you like :-)
[17:25] <mvo> slangasek: right, in this case it was a user that had rsync installed by their admins (for rdiff-backup I think). I don't mind being overriden here, but I'm concerned about the breakage that can happen if the upgrade stops this early :/
[17:25] <mvo> infinity: well, there should be :/
[17:26] <cjwatson> there was another bug where I had a go at analysing this too
[17:27] <cjwatson> bug 979661
[17:27] <slangasek> mvo: right, I don't think I've ever seen the auto-expander code, as infinity mentions... any chance we could fix *that*?
[17:28] <slangasek> I'm very reluctant to restart arbitrary services out from under the user that we know very little about
[17:28] <cjwatson> you'd have to do some pretty cool things with vte to make it dynamically auto-expand
[17:28] <cjwatson> though I suppose that's why we have vte in there
[17:29] <mvo> slangasek: certainly, this is a bug in itself if that does not work that needs fixing
[17:30] <slangasek> mvo: do we have an environment variable that tells us if we're in a release-upgrade or not?
[17:30] <doko> today I found three damaged hard disks when upgrading my build machines ... just one is running now. not a good day :-/
[17:30] <slangasek> if we could key on that, I'd reluctantly accept auto-restarting
[17:30] <slangasek> because during a release upgrade users should expect restarting
[17:30] <cjwatson> mvo: oh, I got a bit carried away with some Python 3 preparation in update-manager and ended up doing the bulk of the port, pending a few libraries and bug-fixes
[17:30] <mvo> cjwatson: woah, very nice!
[17:30] <slangasek> what I don't want is for this question to silently cause restarts on a library upgrade alone, when the user may not be expecting it
[17:31] <cjwatson> mvo: it's just in trunk, feel free to review :)
[17:31] <cjwatson> it won't quite run yet
[17:33] <infinity> slangasek: I'd almost say that I wouldn't mind restarting if the frontend was a GUI one, but that's my own elitist "servers don't have GUIs, and desktop users want stuff to Just Work" belief, and probably not widely-held. :P
[17:34] <slangasek> infinity: desktop users don't install servers and already don't have this problem
[17:34] <slangasek> so the affected users are doing strange things with their desktops and I don't think we can safely extrapolate
[17:35] <infinity> slangasek: True, it's a curious cross-section of people.
[17:36] <infinity> slangasek: That said, if we have no issues with daemons auto-restarting on their own upgrades (and, indeed, we don't), why are we so anal about the same happening during a library upgrade?
[17:37] <mvo> cjwatson: out of curiosity, why trunk and not a seperate branch if its not quite running yet?
[17:37] <infinity> (For a long time, I've been wondering if there'd be a sane way to auto-restart daemons any time a dependency was upgraded, to make sure security updates took, etc)
[17:38] <slangasek> infinity: because users don't look at "oh, there's a libpam update" and automatically think "my database server is going to be offline, I should prepare for that"
[17:38]  * mvo looks at the auto-expand problem now
[17:39] <infinity> slangasek: No, they don't, and that's not something we should change in a stable release, but I'm wondering if maybe socialising that expectation might not be a bad idea.
[17:39]  * infinity shrugs.
[17:39] <slangasek> it will always catch some people by surprise
[17:39] <infinity> Yup.
[17:40] <slangasek> beware-of-leopard, etc
[17:40] <infinity> So will having stale libraries loaded when you thought you were current on security updates.
[17:40] <slangasek> well, that's why the upgrade doesn't let you silently fail to restart services
[18:02] <cjwatson> mvo: I don't believe I broke Python 2, so I didn't think it mattered
[18:05] <cjwatson> mvo: my preferred porting approach involves gradually translating things into the common subset of both languages, with the odd sys.version conditional where there's no alternative; this tends to be pretty trunk-friendly - but also the changes tend to be very extensive and touch lots of files in small ways, so I didn't want to have to maintain a long-lived branch that would be hard to merge
[18:05] <cjwatson> anyway, I don't think it'll take much longer to complete the app side of this port
[18:06] <mvo> cjwatson: aha, thanks, I missed the bit that it continues to run just fine in py2
[18:07] <mvo> fwiw lp:~ubuntu-core-dev/update-manager/precise should have a fix for the timeout handling
[18:08] <cjwatson> at some point we can drop py2 compatibility, but I'd rather wait until after the py3 port is well-established, and in the case of u-m it might need to keep working with py2 until after T
[18:09] <mvo> cjwatson: yeah, exactly, at least the dist-upgrade part will have to, so this approach makes perfect sense
[18:10] <cjwatson> slangasek: there's an env var you can check - look at debconf, it uses it
[18:17] <slangasek> cjwatson: mm, not finding any obviously-named vars when grepping the debconf source
[18:37] <slangasek> mvo: hmm, how does that update-manager change fix things?  I only see a change to the timeout length...?
[18:39] <mvo> slangasek: sorry, http://bazaar.launchpad.net/~ubuntu-core-dev/update-manager/precise/revision/2392 is the relevant change
[18:39] <mvo> slangasek: its a bit confusing I guess I should reorder that
[18:40] <slangasek> ah :)
[18:41] <slangasek> mvo: cool - do you plan to upload today?
[18:42] <mvo> I will try to get to it, my test looks good
[18:42] <slangasek> sweet, thanks
[18:42] <mvo> yw
[18:48] <cjwatson> slangasek: apparently I was thinking of libssl1.0.0.postinst
[18:48] <cjwatson> [ "$RELEASE_UPGRADE_MODE" = desktop ]
[18:49] <slangasek> cjwatson: right - I think we're already checking that var, but I wasn't sure if it was specific to release upgrades... I should double-check
[18:50] <cjwatson> pretty sure it is
[18:57] <slangasek> cjwatson: yep, seems to be... so I guess we can reasonably restart without warning after all
[18:59]  * Laney sees infinity's updates come down the tubes
[20:09] <slangasek> cjwatson: keep an eye on the terminal> yes, mvo has committed a fix to do that now
[20:12]  * infinity lunches.
[20:13] <slangasek> apw: bug #989793 is looking interesting; could we have a race between plymouth-splash, and nouveaufb replacing efifb, in the case of an EFI boot?
[20:16] <cjwatson> slangasek: well, ish - as I mentioned in the bug, it's a five-minute timeout
[20:16] <slangasek> right
[20:16] <slangasek> sorry, saw that mail after :)
[21:20] <adam_g> when seeking sponsorship for SRu, how can i file a merge proposal of a branch into precise-proposed/$foo if $foo doesn't have a precise-proposed branch yet?
[21:21] <tumbleweed> you can't. so just use precise/$foo
[21:21] <tumbleweed> and it will have t obe marked as merged manually
[21:23] <infinity> adam_g: Or just provide a diff in the bug.
[21:24] <adam_g> thanks
[21:25] <adam_g> https://bugs.launchpad.net/bugs/990742  has a debdiff attached, just need to initiate a no change upload to -proposed
[21:50] <Daviey> cjwatson: hey, happen to be around?
[21:52] <cjwatson> Daviey: packing, what's up?
[21:52] <Daviey> cjwatson: Happen to be able to spend a few minutes pointing to d-i support for casper/squashfs?
[21:53] <Daviey> cjwatson: I can see how to boot INTO a live enviroment.. but not unpack to disk via d-i, skipping packages unpack/configure etc.
[21:57] <cjwatson> Daviey: look at the live-installer source package, please
[21:57] <cjwatson> Daviey: and compare with the Debian Live images, which install this way
[21:57] <cjwatson> I pointed smoser at the same things the other day - did a message get lost somewhere?
[21:58] <Daviey> cjwatson: Probably, i'll dig in.. Trying to tie it together.. Thanks.
[21:59] <cjwatson> debian/live-installer.postinst is the entry point
[21:59] <cjwatson> in support/squashfs you can see that it already has support for casper's squashfs path
[21:59] <Daviey> yeah, just saw that
[22:00] <cjwatson> this just replaces the bootstrap-base step (i.e. debootstrap), although obviously might install more packages than debootstrap does depending on what's in the squashfs
[22:00] <cjwatson> you would probably separately need to tell pkgsel not to do anything
[22:00] <cjwatson> but that's fairly easy, I bet you can just iterate until it DTRT
[22:05] <Daviey> cjwatson: thanks!
[22:05] <cjwatson> np