[00:20] gn [03:29] Good morning [03:37] heya pitti! [03:37] hey kees, how are you? [03:37] good, you? [03:38] quite fine, thanks! [03:38] I'm excited to see everyone next week :) [03:38] kees: ah, you'll be on UDS? great! [03:38] Oo, you're coming? [03:38] yup! quick hop down the coast :) [03:38] kees-sponsored beer BoF? [03:39] I need to present my new "survive my USB stick" challenge :P [03:39] Sounds dirty. [03:39] dunno about _sponsored_, but drinking BoF I'll attend. [03:39] "survive inserting this USB stick and I won't laugh at you" ? not a good ring to it. [03:40] anyway, should be fun [03:40] I'm not sure I want to take part in this challenge. [03:40] Sounds sketchy. [03:40] I didn't weaponize it too much! [03:40] That's not comforting. ;) [03:40] hehe [03:41] yeah, it's really disappointing [03:41] how about "tell me what this USB stick is?" [03:42] and slangasek can't help! [03:42] heh [03:42] that's fine, I'm too busy screaming at startpar anyway [03:42] haha [03:43] I'm still trying to right myself after spinning in circles to make some changes to klibc actually build [03:43] my upstart startpar changes were never tested with a job that starts and immediately stops again on boot [03:43] so of course the first package I look at trying to submit upstart patches to Debian for does exactly that (anacron) [03:44] argh [03:44] now to figure out which part of the startpar code the race is in [03:44] "I'll start with 'a'!" urf [03:44] it was actually one that was on my TIL merge list :) [03:45] in other news, some additional hardening updates from Debian are trickling into quantal now. fun to watch! http://outflux.net/ubuntu/hardening/ [03:47] 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] kees: What issues were you having making klibc build? [03:50] infinity: just trying to figure out how to correctly refer to a library in a different directory. [03:50] infinity: I ended up realizing there was another place I could copy the logic from. [03:51] 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] sick burn! [03:52] Okay, so maybe it'll be an Adam-sponsored beer BoF after I took that cheap shot. ;) [03:52] hehe [04:17] oh, that startpar bug was much simpler than I thought [04:17] just needs listen() to have a backlog so we don't miss incoming upstart connections :P [05:40] how am i suppose to version something that hasn't been released and is coming from git? [05:40] i can do `git rev-parse --short HEAD` to get a g [05:40] but howabout the date? [05:41] and do i need to do all this wierism to generate a orig.tar.gz? [05:41] or can it just work natively with git and branches somehow? [05:42] nice question scient.es I'd like to read the answer too [05:43] I'm tempted to just make it a native debian package [05:43] but that doesn't seem like the right thing to do [05:43] * micahg thanks infinity for the devscripts update [05:49] scientes: Generally one does $LAST_RELEASE+git20120504.$SHA or $NEXT_RELEASE~git20120504.$SHA (with 8-char shas) [05:49] RAOF, and if no releases, 0.0.1 ? [05:49] 0.0.0 [05:49] and that date is the packaging date, not the last commit date? [05:50] tahts what I've done in the past. [05:50] Either. [05:50] so 0.0.0+git20120504 for example. [05:50] 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] You can also just to “0+git”, because 0.$POSITIVE > 0+git [05:51] git show --format=format:"" didn't seem to have anything useful [05:51] git log will give you the commit date. [05:51] and do i use git archive to make an orig.tar.gz? [05:52] But if you want to automate the whole shebang... you can see xserver-xorg-video-nouveau's get-orig-source target. [05:52] RAOF, finially there is an answer [05:54] RAOF, where? http://anonscm.debian.org/gitweb/?p=pkg-xorg/driver/xserver-xorg-video-nouveau.git;a=tree [05:54] oh i see it [05:54] 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] debian/rules, get-orig-source: [05:54] sudo build-me-a-tarball [05:55] sudo make me a sandwich :_ [05:55] :) [05:56] just as long as it's not little bobby tables :) [05:58] Eh. We all do proper input sanitisation, right? :) [06:02] RAOF, why do you clone fresh every time? why not --reference=. ? [06:02] 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] ahh, that why not git archive [06:03] to export [06:03] 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 === doko_ is now known as doko [06:10] SpamapS, http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=667198 [06:10] Debian bug 667198 in handlersocket "handlersocket: ftbfs with GCC-4.7" [Important,Open] [06:16] kirkland`: Will you or any other @canonical.com's me at FTF in San Antonio next month? [06:16] *be [06:21] BenC: kirkland's not a Canonical employee anymore. [06:22] infinity: Ah, lots happens in a year.. [06:22] infinity: Who's in charge of the server team now? [06:23] or would otherwise care about my question :) [06:24] BenC: Daviey, though I suspect he's not planning to be in San Antonio. He may know if someone else is. :P [06:24] BenC: Or SpamapS may know. [06:26] infinity: ok, thanks [06:42] good morning [06:57] E: changelog for this version is not (yet) available; try https://launchpad.net/ubuntu/+source/cyrus-sasl2/+changelog [06:57] but they are available ... [06:57] dupondje: yes, but are they on changelogs.ubuntu.com? [06:59] ah nope :) [06:59] tought it was looking @ the launchpad page, but its an alternative :) [06:59] should parse the launchpad page ^^:) === lfaraone_ is now known as lfaroane === lfaroane is now known as lfaraone [07:10] how about computer janitor clearing /var/cache/apt? === smb` is now known as smb === dendrobates is now known as dendro-afk === dendro-afk is now known as dendrobates [09:24] dholbach: python-levenshtein shouldn't have been sync'd, can you readd the dh_python2 diff please? [09:24] hum [09:25] - use python-support instead of python-central; Closes: #617011 [09:26] will do - I clearly didn't look closely enough [09:26] thanks [09:36] 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] Launchpad bug 909292 in python3.2 (Debian) "Crashes when C calls Python callback with Python3 due to local ctypes module build configuration" [Unknown,Confirmed] https://launchpad.net/bugs/909292 [09:36] fortunately I hadn't spent too much time on it yet [09:36] cjwatson: indeed, I'm getting all sorts of bug reports on that [09:36] merely stared at the screen in a baffled kind of way [09:36] it seems 90% of the incoming reports with py3 are due to that [09:37] that bug took me some 15 hours to track down.. [09:37] cjwatson: so does it work with the -proposed version now? [09:38] I'm just updating to that now to se [09:38] e [09:41] cjwatson: you are porting ubiquity to py3? [09:47] pitti: yep [09:48] pitti: I have a decent number of the tests passing, but still lots more to do [09:48] I'm about 95% done with apport now [09:48] I still need python3-xdg and python3-launchpadlib, but most code can deal without these [09:49] it's so much fun untangling bytearrays and strings.. [09:49] I need python3-pyicu, but I've sent a patch for that to Debian [09:49] (well, which I need to correct it seems, but) [09:50] also usb-creator, I think it's rather easier [09:50] python3-launchpadlib is ultimately blocked on oauth [09:50] barry's spreadsheet (IIRC) suggests switching to oauth2 [09:50] ah; it seems wadllib and many lazr modules are already available [09:51] Yeah, I did part of that last cycle before running out of time and blocking on oauth [09:51] I think we're close to a tipping point for a lot of Ubuntu-specific things - just a few more libraries [09:52] 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] yeah, I noticed the same in apport [09:53] 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] instead of waiting on the crash reports to come in [09:53] code that needs to handle both is a pain ... [09:53] micahg, done [09:53] thanks [09:54] 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] most of our archive tools should be ready once python3-debian and python3-launchpadlib are available [09:54] porting Launchpad will be interesting ;-) [09:55] pitti: isinstance(foo, six.string_types) [09:55] 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] if you're willing to depend on python{,3}-six [09:55] I'll need to get the distribute ready for 3.3 ... [09:55] instead of a simple "a♥b' [09:55] pitti: from __future__ import unicode_literals [09:56] (changes semantics of all literal strings in the file, but that's often OK for tests) [09:56] cjwatson: ah, that makes "a" what used to be u"a"? [09:56] indeed [09:56] ah, good [09:56] works with >= 2.6 [09:56] cjwatson: yes, that's fine, as the code needs to work with both 2 and 3 anyway for a fair while [09:57] cjwatson: thanks for the hint [09:57] but most of the time I must say it's workable [09:57] barry reckons most Python files should start with 'from __future__ import absolute_import, print_function, unicode_literals', I gather [09:57] I just found one thing for which there is absolutely no compatiblity between the two [09:58] personally I think unicode_literals can be difficult outside tests, at least if there's an API to preserve [09:58] pitti: oh? [09:59] http://bazaar.launchpad.net/~apport-hackers/apport/trunk/view/head:/apport/REThread.py#L64 [09:59] pitti: six.reraise [09:59] the syntax for re-raising an exception object changed, and neither version accepts the syntax of the other [09:59] cjwatson: yeah, external dependency again [09:59] which indeed uses the same exec hack, but at least it makes it somebody else's problem :) [10:00] I've got quite a few "if sys.version ..." comparisions anyway, at least they are greppable [10:00] 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] ("grepable"?) [10:00] greppable, I think :) [10:01] and I ended up using six in my python-debian port as well, because it was far too much trouble not to [10:01] cjwatson: http://www.googlefight.com/index.php?lang=en_GB&word1=grepable&word2=greppable disagrees :) [10:01] pitti: bah [10:01] so far in update-manager I've managed to get away without [10:02] I seem to be working on the stuff that starts with 'u' :-P [10:02] 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] yeah, apport is perhaps a special case [10:03] update-manager has to be a bit careful as well due to the dist-upgrader tarball [10:03] cjwatson: U> don't we all? :-) [10:04] 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] (cleaned up a local ~/bin/ script which was also installed in /usr/bin/; didn't notice madison.cgi was using it) [10:08] pitti: confirmed that this python3.2 fixes my segfaults [10:08] \o/ [10:08] one bug to rule them all [10:09] 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] (nothing to do with ctypes, I think) [10:10] hum, somehow my python-levenshtein upload didn't make it to LP? [10:10] cjwatson, it was the libffi_pic.a library linked to the python3 executable [10:11] ah no, there it is [10:11] *phew* [10:11] doko: I meant my TypeError in ubiquity was nothing to do with ctypes :-) [10:11] but previously I had the segfault you just fixed [10:26] 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] dholbach: it's no worse than before at this point [10:27] ok [10:27] 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] eagles0513875: I thought I already mentioned it's in debian experimental [10:28] 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] eagles0513875: right now testing, TBD at UDS, merges/syncs from other repos as needed [10:30] micahg: i understand as well that its in experimental just want to backup my push for 3.82 with the bug report [10:32] micahg: here is the bug report to backup why i want to get us bumped up to 3.82 [10:32] \o/ apport test suite now fully works for both python 2 and 3 [10:34] micahg: :D seems like the fix made it into the upstream package :) === amitk is now known as vinguamit === vinguamit is now known as amitk === Ursinha__ is now known as Ursula === Ursula is now known as Ursinha === Ursinha is now known as Guest69236 === Ursula is now known as Ursinha === _salem is now known as salem_ [12:48] 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] I'd forgotten about that, should stick it in -updates/quantal [12:51] 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] don't pass any of the *-ubiquity boot args [12:51] i know i can just remove --purge ubiquity, but this will also remove it copletely and kill the desktop icon [12:51] cjwatson, well, i dont think an upload to quantal makes sense, debian will benefit from it too [12:52] cjwatson: so i remove only-ubiquity from isolinux/txt.cfg ? [12:52] its not that we are late in the release yet :) [12:52] ogra_: it's in -proposed, it should go somewhere [12:52] oh, indeed, -updates for sure [12:52] and -updates should <= quantal [12:52] yeah [12:52] it's easy to sync later [12:52] k [12:52] zaytsev: sounds right [12:53] zaytsev: well [12:53] zaytsev: maybe also drop hidden-timeout=whateveritis from /isolinux/gfxboot.cfg [12:54] 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] should work with the same configuration [12:55] 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] cjwatson: awesome thanks a lot man [12:56] no problem [12:58] audacious-plugins looks plausible in -proposed, promoting now [13:01] great [13:04] ogra_: done: http://anonscm.debian.org/gitweb/?p=pkg-multimedia/audacious-plugins.git;a=commitdiff;h=fed6c9546ebd5b94eab42d1f70f8c011ec80c772 [13:06] bdrung: ta [13:06] sorry I didn't forward that, it was in the middle of release crunch [13:06] cjwatson: no problem and no need any more :) [13:07] awesome ! [13:07] ogra_: that was an easy and quick task :) [13:33] sabdfl: Rev 24 of the revised CoC resolves the concern I expressed in yesterday's CC meeting. Thanks. [13:34] cjwatson, pitti everything work out okay? :) [13:34] so far [13:35] great! [13:36] ScottK,sabdfl: yep, me too === JanC_ is now known as JanC === Zic__ is now known as Zic [13:50] xnox: if you want to help with the nagios-nrpe sru validation, they're all in now === kirkland` is now known as kirkland [13:51] stgraber: ok. [14:24] hi, any idea what's the licence for the circle of friend logo? [14:31] bigon: the files themselves should be CC-BY-SA. How you use it depends on trademarks [14:31] bigon: what are you trying/wanting to do? [14:34] sladen: gnome-boxes is including the circle of friend [14:34] and I'm trying to figure out if it could be included into debian [14:34] sladen: ^ [14:37] bigon: http://launchpad.net/ubuntu-branding/+filebug?field.title=gnome-boxes+licence+of+CoF+for+Debian [14:38] bigon: and I'll try and sort you out one under whatever licence needed (thought content should be CC-BY-SA anyway) [14:38] sladen: If the license is Debian specific, it's not DFSG free. [14:39] So, to avoid questions, make it license and not license for Debian. [14:39] A license for Debian doesn't help. [14:39] doko: ACK, I'll get on it. There's a new upstream to package as well. [14:40] CC-BY-SA is DFSG [14:42] 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] Trying, perhaps not very well. [14:43] bigon: however regardlessly, it would be good to have a place to track this [14:43] bigon: with longer-longevity than IRC scollback [14:45] https://bugzilla.gnome.org/show_bug.cgi?id=671251 [14:45] Gnome bug 671251 in general "do not include non-free content" [Blocker,Unconfirmed] [14:45] there is already an upstream bug open for that [14:47] 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] yeah sorry [14:52] so for my part what should I do? ask gnome-boxes upstream to get a licences for the project? [14:53] (or I didn't understand?) [14:55] 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] (yeah I was thinking about firefox/iceweasel thing) [14:56] I'm opening a bug on the LP [14:56] Though then again, the debian swirl would likely fail that test as well :) I've heard there's onging work there though... [14:56] bigon: I've added https://bugzilla.gnome.org/show_bug.cgi?id=671251#c10 [14:56] Gnome bug 671251 in general "do not include non-free content" [Blocker,Unconfirmed] [14:57] bigon: is that sufficient? [14:57] How to do a local [s|de|pde]build *with* pkg mangler and/or debug symbol generator? [14:57] bigon: Zack's current intention/wish I believe is to move all restrictions over to being trademark based [14:58] xnox: mk-sbuild will install pkgbinarymangler [14:58] but basically, you just install it in the chroot [14:58] tumbleweed: awesome =) thanks. [15:01] sladen: let's hope :) thx [15:01] arand: well there is 2 logo for debian one official and one non official http://www.debian.org/logos/ [15:08] bigon: slightly more complicated than that. There are four (main) variations. swirl; swirl + text; wine bottle; wine bottle with text [15:08] bigon: those with text are covered by trademarks. Those with the wine bottle may only be used by DDs [15:09] yeah I was to fast to read [15:15] pitti: Is there a useful equivalent of python-gi-dev for Python 3? [15:15] pitti: Or do I just keep on using python-gi-dev? It's a bit confusing that it Depends: python-gi [15:29] 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] 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] You didn't remove hidden-timeout [15:30] Like I said [15:30] 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] You can still have a timeout [15:31] Do you actually want the splash screen? [15:32] 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] It's possible you'll need to rebuild the gfxboot theme, then [15:32] cjwatson: i grepped isolinux for maybe and it seems to be in bootlogo [15:32] It's in the gfxboot-theme-ubuntu source package; the patch I expect you want is http://paste.ubuntu.com/967136/ [15:33] cjwatson: is it checksommed? maybe i'll just hack it with the hex editor? [15:33] No, that's almost certainly seventeen orders of magnitude more pain than doing it properly [15:33] Apply that patch, build binary package, fish out bootlogo from binary package, replace [15:34] cjwatson: ok thanks for the patch, i'll do both at the same time and see what finished first :-) [15:34] If you're building a derived distribution, I rather hope you're comfortable with building packages :) [15:55] 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] More precisely I'm looking for ChunkedOutputStream.java [15:58] alexbligh1: If you want the exact source, you want 'apt-get source openjdk-headless' [15:59] (Though, I assume you mean openjre-headless) [16:00] Or, openjdk-6-jre-headless, even. :P [16:01] And ignore the bzr branch it tells you to get, if it's wrong. [16:01] Or not useful. [16:02] 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] Yep. [16:04] yofel: Did anyone ever verify that last-minute software-properties upload to precise-proposed? [16:05] It'd be nice to get that synced up in precise-updates/quantal. [16:07] cjwatson: I did, just forgot it wasn't yet out to precise [16:07] infinity, that's what I would have thought, but that doesn't seem to be the case [16:07] thanks for the reminder [16:07] alexbligh1: How do you mean? [16:07] There's no other way binaries get into the archive. [16:07] 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] And though rt.lib is (somehow) built by that file, it does not contain the class [16:08] 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] I just don't understand how the java stuff is built [16:09] jar tf on rt.lib shows that class file was (somehow) used to build the rt.lib in it. [16:09] After getting the openjdk-6-jre-headless source package, cd to the directory it gives you and run 'debian/rules patch'. [16:09] Then you'll find that file in build/openjdk/jdk/src/share/classes/sun/net/httpserver/ChunkedOutputStream.java . [16:10] (That debian/rules target is run as part of dpkg-buildpackage, pre-build) [16:11] (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] cjwatson, thanks. I am missing some build-depends but will sort that out. [16:11] cjwatson, me neither :-) [16:15] 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/ === deryck is now known as deryck[lunch] === funkyHat_ is now known as funkyHat [16:26] 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] alexbligh1: We'd SRU for things like that, sure. File a bug with a pointer to the patch. [16:29] l [16:32] @pilot in === udevbot changed the topic of #ubuntu-devel to: Archive open | Ubuntu 12.04 (Precise Pangolin) is released! | Dev' of Ubuntu (not support or app devel) | build failures -> http://bit.ly/HaWdtw | #ubuntu for support and general discussion for hardy -> precise | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: infinity [16:36] infinity, thanks, will do [16:38] * dholbach hugs infinity [16:43] * xnox winks at infinity [16:43] Is it getting hot in here, or is it just me? [16:43] haha [16:45] 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:45] Launchpad bug 994208 in clang (Ubuntu) "Needs to know about quantal" [Undecided,In progress] [16:46] infinity, man, I was just about to head out [16:46] and use emacs? [16:47] what else? [16:47] dholbach: *snicker* [16:47] I don't think I've had emacs installed for over a decade. [16:47] Going on two, actually... Last time I used it extensively was university. [16:47] PS: I'm old. [16:49] * xnox starts emacs with init [16:49] Heathen. [16:49] I bet your terminals have white backgrounds too. [16:49] I heard once you can actually chsh /usr/bin/emacs [16:50] (or whatever the exact path is) [16:50] * dholbach starts to panic and looks for exit signs [16:50] haha lol vim fan here :) [16:51] but... *off-topic* :P [16:52] infinity: http://ethanschoonover.com/solarized [16:55] This dude takes his colours rather seriously... === Ursinha is now known as Guest78578 [17:05] smo/win 6 [17:10] 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] mvo: 993190> this discussion again? :-) [17:13] mvo: we already don't show any debconf prompt on a stock desktop system [17:13] mvo: it's only when users have extra services installed that the prompt shows up [17:19] mvo: There's "auto-expand-termimal" code? I've never actually seen that happen. :P [17:20] 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] It's a startup check. [17:20] So it's no use for Perl transitions. [17:22] 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] as you like :-) [17:25] 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] infinity: well, there should be :/ [17:26] there was another bug where I had a go at analysing this too [17:27] bug 979661 [17:27] Launchpad bug 979661 in update-manager (Ubuntu) "oneiric to precise: debconf: unable to initialize frontend: Gnome and falls back to Dialog" [High,Confirmed] https://launchpad.net/bugs/979661 [17:27] 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] I'm very reluctant to restart arbitrary services out from under the user that we know very little about [17:28] you'd have to do some pretty cool things with vte to make it dynamically auto-expand [17:28] though I suppose that's why we have vte in there [17:29] slangasek: certainly, this is a bug in itself if that does not work that needs fixing [17:30] mvo: do we have an environment variable that tells us if we're in a release-upgrade or not? [17:30] today I found three damaged hard disks when upgrading my build machines ... just one is running now. not a good day :-/ [17:30] if we could key on that, I'd reluctantly accept auto-restarting [17:30] because during a release upgrade users should expect restarting [17:30] 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] cjwatson: woah, very nice! [17:30] 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] mvo: it's just in trunk, feel free to review :) [17:31] it won't quite run yet [17:33] 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] infinity: desktop users don't install servers and already don't have this problem [17:34] so the affected users are doing strange things with their desktops and I don't think we can safely extrapolate [17:35] slangasek: True, it's a curious cross-section of people. [17:36] 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] cjwatson: out of curiosity, why trunk and not a seperate branch if its not quite running yet? [17:37] (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] 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] 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] it will always catch some people by surprise [17:39] Yup. [17:40] beware-of-leopard, etc [17:40] So will having stale libraries loaded when you thought you were current on security updates. [17:40] well, that's why the upgrade doesn't let you silently fail to restart services === deryck[lunch] is now known as deryck === Ursinha- is now known as Ursinha === Ursinha is now known as Guest84854 === Guest84854 is now known as Ursula === Ursula is now known as Ursinha [18:02] mvo: I don't believe I broke Python 2, so I didn't think it mattered [18:05] 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] anyway, I don't think it'll take much longer to complete the app side of this port [18:06] cjwatson: aha, thanks, I missed the bit that it continues to run just fine in py2 [18:07] fwiw lp:~ubuntu-core-dev/update-manager/precise should have a fix for the timeout handling [18:08] 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] cjwatson: yeah, exactly, at least the dist-upgrade part will have to, so this approach makes perfect sense [18:10]