[01:55] <RoAkSoAx> hey guys vol_id has been dropped for karmic, correct?
[02:02] <dtchen> RoAkSoAx: correct. See the udev changelog entry for 141-2+git4a74214.
[06:40] <LucidFox> I'm rather shocked nobody seems to have packaged clang for Debian or Ubuntu yet
[06:41] <RAOF> Yeah, I was a bit surprised, too.
[06:42] <LucidFox> There's an ITP in Debian, though.
[07:30] <pitti> Good morning
[07:33] <micahg> morning pitti
[07:33] <micahg> thank you for sponsoring my patch :)
[07:35] <pitti> you're welcome
[07:59] <dholbach> good morning
[08:38] <ttx> pitti: hey -- I was wondering if you planned to add "by assignee" workitems report at some point
[08:39] <ttx> sometimes it's difficult to get a picture of where you stand, especially if you have work items assigned from several teams
[08:40] <pitti> ttx: like the ones that we have since yesterday?
[08:40] <pitti> ttx: http://piware.de/workitems/server/lucid/report.html, "Status by work item"
[08:41] <ttx> pitti: not exactly
[08:41] <pitti> ttx: it's per team right now indeed, there's no global by-assignee report yet
[08:41] <pitti> (it's a little trickier to do, since there are separate DBs for each team; not really hard, though)
[08:41] <ttx> pitti: I was thinking about "my own burndown chart" grouping items from all projects, whatever team they belong in
[08:42] <ttx> i.e. "am I late ?" rather than "is this project late ?"
[08:45] <seb128> hey
[08:46] <seb128> did yesterday's evening upload got accepted but silently dropped?
[08:46]  * seb128 uploaded some packages while launchpad was supposed to be in update and those got accepted for upload but dropped apparently
[08:46] <seb128> I wonder if I should upload again
[08:47] <pitti> seb128: reuploading worked for me
[08:47] <pitti> my gnome-menus upload last night was silently dropped, too
[08:47] <seb128> grrr
[08:47] <seb128> I'm not sure I kept sources for all the uploads I did
[08:47] <seb128> screw you launchpad
[08:47] <seb128> and I'm not sure which ones got dropped now
[08:48] <pitti> seb128: check the "accepted" mails?
[08:49] <seb128> pitti, didn't got those
[08:49] <pitti> then you can safely assume that all got dropped
[08:49] <seb128> launchpad just dropped the uplaods silently
[08:50] <seb128> well I managed to pass some before shutdown
[08:50] <seb128> but I'm not which rebuilds I did exactly for gir now
[08:51] <seb128> anyway, let me think about what I did ;-)
[08:51] <seb128> that will teach me to work after hours
[08:54] <LucidFox> seb128, I noticed that the recent upload of gnome-shell depwaited on the Debian version of gjs, so I merged it.
[08:55] <seb128> LucidFox, I did that yesterday but it got dropped cf log
[08:55] <LucidFox> Weird
[08:55] <seb128> LucidFox, I reuploaded my version now, yours was bugged
[08:55]  * LucidFox nods
[08:55] <seb128> LucidFox, thanks anyway
[08:56] <LucidFox> Out of interest, how was it bugged?
[08:56] <seb128> didn't use replaces or conflict
[08:56] <seb128> debian uses different name
[08:56] <seb128> it wouldn't install because it conflict with the ubuntu gsj-dev
[08:56] <seb128> gjs
[08:56] <LucidFox> ...Oh.
[08:56] <seb128> or rather install would break on file conflict
[09:03] <micahg> pitti: any idea when the my apport fix will go to proposed?
[09:04] <pitti> micahg: soon
[09:04] <micahg> pitti: ok :)
[09:04] <micahg> it's hard to triage crashes without apport :)
[09:15] <LucidFox> mc must have the weirdest build system I have seen.
[09:15] <LucidFox> Debian build system, not upstream. debian/rocks, "Colin's Build System"...
[09:25] <seb128> pitti, so our libx11 is too old
[09:25] <pitti> tjaalton: is there a newer libx11-dev available, or should we sync from Debian?
[09:25] <seb128> some things you synced don't build
[09:25] <seb128> that break gtk installability
[09:25] <seb128> and all desktopish builds
[09:26] <pitti> there are also quite some bits in NEW
[09:27] <pitti> (metacity, gir, etc.)
[09:27] <seb128> libxinerama failed to build too
[09:27] <seb128> which is part of the issue
[09:27] <seb128> https://edge.launchpad.net/ubuntu/+source/libxinerama/2:1.1-1/+build/1378080
[09:28] <seb128> I'm wondering if some build-depends are not tight enough
[09:28] <pitti> this looks more like a missing b-dep?
[09:29] <pitti> most syncs were requested by bryce and tjaalton, so they should have gotten the mail spam
[09:29] <seb128> ok, my mailbox got flooded during night
[09:29] <seb128> none of my uploads from this night built
[09:29] <seb128> I guess we just have to wait for tjaalton or bryce to be around now
[09:30] <pitti> I give back xinerama
[09:30] <seb128> thanks
[09:30] <seb128> we will need to sort the libx11 question though
[09:31] <tjaalton> pitti, seb128: once libxext is in the archive I'll file rebuilds
[09:31] <seb128> tjaalton, things depwait on a newer libx11 that the one we have too
[09:31] <tjaalton> pitti: I'm merging libx11, there's one change that apparently needs to be preserved
[09:31] <seb128> tjaalton, thanks
[09:31] <pitti> great, thanks
[09:31] <pitti> tjaalton: "file" -> just ping on IRC
[09:32] <pitti> with a list of packages to retry (no commas)
[09:32] <tjaalton> pitti: ok
[09:32] <pitti> tjaalton: or just use the ubuntu-dev-tools "buildd" script yourself
[09:32] <pitti> buildd package lucid retry
[09:32] <tjaalton> the reason for the failed builds was that we had a newer libxext than what the new x11proto-xext Breaks, so they weren't held in the queue
[09:33] <tjaalton> pitti:  oh cool
[09:33] <pitti> $ cat /home/martin/bin/giveback
[09:33] <pitti> #!/bin/sh
[09:33] <pitti> for i in $@; do
[09:33] <pitti> buildd $i lucid retry
[09:33] <pitti> done
[09:33] <pitti> ^ for even lazier people :)
[09:36] <tjaalton> pitti: hehe, I'll steal that one :)
[09:37] <tjaalton> hmm, libxext was built 2h ago but still not in the archive..
[09:56] <tjaalton> pitti: who is responsible for the publisher? there is certainly something wrong with it, since built packages are not being pushed to the archive
[09:58] <cjwatson> 2009-12-04 09:03:20 DEBUG   Publishing custom gnome-menus, gnome-menus_2.28.0.1-0ubuntu3_sparc_translations.tar.gz to ubuntu/lucid
[09:58] <cjwatson> 2009-12-04 09:03:20 ERROR   Failure processing queue_item 1460701
[09:58] <cjwatson>  -> http://launchpadlibrarian.net/36423030/bDF1qc8NVJ5FX6mGghGbd19C93f.txt (permission denied for relation translationgroup
[09:58] <cjwatson> )
[09:58] <cjwatson> I'll follow up with the Soyuz people
[09:58] <tjaalton> thanks :)
[10:09] <cjwatson> tjaalton: looking happier now ... (thank bigjools)
[10:10] <tjaalton> cjwatson: great
[10:12] <ttx> cjwatson: hey -- I had a couple questions for you about the SC announcement (that affect how I'll do the NC announcement)
[10:13] <ttx> cjwatson: If we are to follow spec we should publish when eucalyptus-sc in installed and sshd is running. Currently its run at eucalyptus-sc start.
[10:13] <ttx> cjwatson: Any plans to upstartify openssh-server ? :)
[10:15] <cjwatson> ttx: upstartifying openssh-server is dependent on upstart being able to function reasonably in a chroot
[10:16] <ttx> cjwatson: so we would fix the announcements later, when that support is added ?
[10:16] <cjwatson> Keybuk: ^- is that planned for lucid?
[10:17] <ttx> cjwatson: Question #2: It's better if SC announces "I'm an SC for cluster FOO", so adding a dest="CLUSTERNAME" thing in the TXT record.
[10:17] <ttx> cjwatson: Is that destination info currently propagated by the installer in one of the /etc/eucalyptus files ?
[10:17] <cjwatson> I suppose I could hackily ship both an upstart job *and* an init script somehow ...
[10:17] <cjwatson> ttx: yes, eucalyptus-cc.conf
[10:18] <cjwatson> ttx: see eucalyptus bzr
[10:18] <cjwatson> I've already done this :)
[10:18] <ttx> cjwatson: ok, I thought that file didn't get installed on the SC and the NC, will check
[10:18] <cjwatson> I actually added a eucalyptus-sc.conf with the same info
[10:18] <Keybuk> cjwatson: no
[10:19] <cjwatson> Keybuk: ok, any suggestions for how to best satisfy what the server team need for euca?
[10:19] <Keybuk> I don't know what the server team need
[10:19] <cjwatson> it's encapsulated quite accurately in the last couple of dozen lines of scrollback
[10:19] <ttx> Keybuk: we want to write an upstart job that is started "when sshd is running"
[10:19] <Keybuk> cjwatson: why not make an upstart ssh job?
[10:20] <cjwatson> because sshd is very commonly run in chroots
[10:20] <cjwatson> and I will not break that
[10:20] <Keybuk> fair enough
[10:20] <cjwatson> so if there's a way to upstartify it without breaking chroot operation as well, that would be OK; e.g. shipping the init script as well
[10:20] <Keybuk> no idea
[10:20] <Keybuk> don't really care
[10:27] <ttx> cjwatson: I guess the publication upstart script could loop/test for sshd existence before publishing.
[10:28] <cjwatson> ttx: let me see if I can get openssh to DTRT somehow
[10:28] <ttx> cjwatson: ok :)
[10:29] <ttx> cjwatson: I looked at eucalyptus-sc.conf... Would eucalyptus/cluster-name also be available to the NC installer ? i.e. can I add a eucalyptus-nc.postinst to put the destination cluster-name in a eucalyptus-nc.conf file ?
[10:31] <ttx> cjwatson: the intended behavior being, existing cluster is detected, select NodeController install, end up with the detected cluster name in a file on the NC.
[10:33] <ttx> ... so that I can pick it up when announcing "I'm an NC for cluster foo"
[10:34] <cjwatson> ttx: it won't actually quite work yet for the SC anyway :) we'll need to arrange for it to be preseeded, so we can do the same thing for the NC
[10:34] <ttx> cjwatson: right. I'll do a placeholder announcement, sufficient to test the autoregistration, and we'll refine later
[10:37] <cjwatson> ttx: fixed it to preseed eucalyptus/cluster-name now
[10:37] <cjwatson> ttx: so you can just copy the same bit from eucalyptus-sc.{postinst,templates}
[10:37] <perecastanyersar> hi all only one question:
[10:37] <perecastanyersar> If I need to download a package from ubuntu hardy partner..where I must go?
[10:37] <ttx> cjwatson: cool thx
[10:37] <cjwatson> perecastanyersar: 'deb http://archive.canonical.com/ubuntu hardy partner' in /etc/apt/sources.list
[10:39] <perecastanyersar> how I can download the package from apt? it's the -d option? apt don't listen to me
[10:39] <cjwatson> perecastanyersar: 'aptitude download' is the most straightforward
[10:39] <perecastanyersar> ah thanks i'll try
[10:40] <cjwatson> perecastanyersar: 'apt-get -d install <package>' will do it too but will leave the package in /var/cache/apt/archives/ rather than in the current directory
[10:42] <perecastanyersar> I'm trying to install the IDS from partner ubuntu sources: sudo apt-get install informix-ids-demo (for amd64)
[10:42] <perecastanyersar> and apt-says that need a dependency from informix-ids...that is a package that is missing in the repository
[10:46] <perecastanyersar> any ideas how I can install informix from partner sources?
[10:49] <cjwatson> perecastanyersar: looks like it's only available for i386. You should file a bug
[10:52] <tjaalton> pitti: buildd says "Unable to find source package 'libxinerama' in the Lucid-release pocket." and the same for every package I try
[10:53] <tjaalton> oh well, lunch ->
[11:07] <cjwatson> Keybuk,slangasek: is it just me or is /usr/share/debhelper/autoscripts/postinst-upstart-restart wrong? it starts with 'if [ -x "/etc/init.d/#JOB#" ]; then' ...
[11:08] <cjwatson> and indeed it doesn't seem to be adjusted for upstart at all
[11:08] <cjwatson> is it relying on the upstart-job stuff or something?
[11:10] <Keybuk> might be
[11:10] <Keybuk> dunno
[11:24] <ogra> hmm, could someone promote libicu42 and friends ?
[11:24] <ogra> seems webkit FTBFS on armel because of it missing in main
[11:25] <cjwatson> ogra: done
[11:25] <cjwatson> (architecture mismatch)
[11:25] <ogra> thanks
[11:26]  * ogra waits for the publisher until giving back webkit ...
[11:32] <seb128> tjaalton, how are things going with libx11?
[11:32] <tjaalton> seb128: I could upload it now, since libxext is in the archive
[11:32] <seb128> do it then! ;-)
[11:32] <tjaalton> surely :)
[11:32] <seb128> thanks
[11:33] <pitti> tjaalton: hm, weird; works for me here
[11:33] <cjwatson> pitti: can you reset the foundations db please? modulo one or two glitches (esp. the upstart server review) we're done with work items
[11:34] <pitti> cjwatson: just ditch the db, so that it starts back from 0?
[11:34] <pitti> tjaalton: hm, works here; given back
[11:34] <cjwatson> well, whatever you normally do when teams are finished preparing WIs
[11:34] <cjwatson> if you want to just restart the graph position, that's fine too
[11:34] <pitti> easier to delete the db; done, and regenerating now
[11:37] <pitti> cjwatson: done
[11:37] <tjaalton> pitti: it seems to work on my lucid laptop, but not on jaunty desktop
[11:37] <cjwatson> thanks
[12:00] <ogra> hmm, whats up with gstreamer ?
[12:01] <seb128> what do you mean?
[12:01] <fagan> ogra: whats wrong with it?
[12:01] <ogra> gstreamer and gst-plugins-bade are all dep wait
[12:01] <ogra> http://qa.ubuntuwire.org/ftbfs/
[12:01] <seb128> gstreamer is not depwait
[12:01] <seb128> your webpage is buggy or outdated
[12:01] <ogra> https://launchpad.net/ubuntu/+source/gst-plugins-base0.10/0.10.25-5 didnt build
[12:02] <seb128> yes
[12:02] <seb128> xorg breakage
[12:02] <seb128> tjaalton just uploaded libx11
[12:02] <ogra> ah, k
[12:02] <seb128> that should make gtk installable again...
[12:02]  * ogra will just wait then
[12:02] <seb128> then we can retry desktop things
[12:02] <ogra> yep, understood
[12:02] <ogra> thanks 1
[12:03] <ogra> !
[12:03] <seb128> you're welcome
[12:06] <cjwatson> Keybuk: I think I've confused upstart somehow. 'sudo start ssh' hangs; 'initctl log-priority debug' shows "init: ssh goal changed from stop to start" in syslog but that's about it
[12:07] <cjwatson> Keybuk: http://paste.ubuntu.com/334466/ is the configuration file
[12:07] <Keybuk> bug 406397 probably
[12:07] <Keybuk> for a start
[12:08] <Keybuk> your "script" calls grep
[12:08] <Keybuk> so Upstart will follow that fork, and get the pid of grep
[12:08] <cjwatson> ah, could be. in my previous version of the job, I forgot the 'exec'
[12:08] <cjwatson> oh, even with 'expect daemon'?
[12:08] <Keybuk> why are you mucking with OOM_ADJ like that ?!
[12:08] <cjwatson> because I forgot that upstart supported it :)
[12:08] <Keybuk> :D
[12:09] <Keybuk> oom -17
[12:09] <Keybuk> should just dtrt
[12:09] <cjwatson> is there a way to deconfuse upstart without rebooting at this point?
[12:09] <cjwatson> yeah
[12:09] <Keybuk> "oom never" actually I think you mean
[12:09] <Keybuk> no
[12:09] <Keybuk> you have to reboot at this point
[12:09] <cjwatson> ok, thanks
[12:10] <shankhs> what is a template for packaging? Please.
[12:10] <shankhs> i know dh-make is used to create template
[12:11] <shankhs> i am a noob
[12:11] <Keybuk> shankhs: -> #ubuntu-motu
[12:12] <shankhs> Keybuk: thanx
[12:20] <pitti> Keybuk: does bug 491162 ring a bell for you?
[12:21] <Keybuk> pitti: the bug description is wrong
[12:21] <Keybuk> there are lots of problems with the gdm start on line
[13:37] <dpm> pitti, I'm looking at http://piware.de/workitems/community/lucid/report.html and I can't get some of the other community blueprints to show up there. For example, https://blueprints.launchpad.net/ubuntu/+spec/community-lucid-community-participation-in-coordinating-translations is there anything else needed to do to get blueprints picked up?
[13:38] <pitti> dpm: right, that's only "proposed" for lucid, not accepted
[13:38] <pitti> done now
[13:38] <dpm> pitti, ah, I see, thanks, I'll get jono to accept the rest.
[14:03] <daanemanz> hi all, does anyone know where I can find the source code for php5-uuid?
[14:03] <daanemanz> installing using pecl doesn't work
[14:23] <ogra> pitti, report.html should have a link somewhere on the page to https://wiki.ubuntu.com/WorkItemsHowto
[14:55] <mdz> kane_, hi
[15:11] <doko_> seb128: do you know why the cairo/gtk/xtst -dev packages are not installable?
[15:11] <seb128> doko_, because of the zillion xorg lib synced yesterday didn't build it
[15:12] <seb128> the new libxi conflicted with other updates
[15:12] <seb128> and depended on the new libx11 that tjaalton uploaded some hours ago
[15:12] <seb128> should be sorting itself now
[15:27] <pitti> new libx11 is published, anyway
[15:28] <pitti> just getting it through dist-upgrade
[15:43] <seb128> pitti, gtk installability fixed now indeed
[15:44] <ogra> seb128, anything i need to give back on arm ?
[15:44] <seb128> ogra, not that I know, I'm giving back things on all archs
[15:44] <ogra> k, thanks ...
[15:45] <ogra> feel free to dump such stuff on me for armel at least if you dont find the time in the future ...
[15:45] <seb128> ok
[15:59] <Keybuk> pitti: so what's actually wrong with the whole floppy thing?
[15:59] <pitti> Keybuk: if only I knew -- I asked for ssh access on a machine with a floppy
[15:59] <Keybuk> I have a machine with a floppy drive
[15:59] <pitti> I haven't had a working one in 5 years
[15:59] <Keybuk> no floppy disks though ;)
[16:00] <Keybuk> but if I select Floppy from the Places menu, the little light comes on and it goes KER-CHUNK-THUNK for a second
[16:00] <pitti> I see the reason why it can't work in a stock karmic -- blkid is never called
[16:00] <pitti> but I don't see why it still doesn't work even with that extra testing rule
[16:00] <Keybuk> why does blkid need to be called?
[16:01] <pitti> to tell dk-disks that there's an useful fs on it, and gvfs that there's a volume available
[16:02] <Keybuk> why does it need to  know that?
[16:02] <Keybuk> mount -t auto ? :p
[16:03] <Keybuk> if I see any floppy disks for sale, I'll pick one up and put it in the drive, then you can ssh in and play
[16:03] <pitti> sale? haha
[16:03] <ogra> lol
[16:03] <pitti> well, I might still have some deeply buried in my cellar
[16:03] <pitti> but no drive to put them into
[16:03] <Keybuk> yeah I have the drive but no disks :p
[16:04] <pitti> I still have a zip drive, though :) (not used in years either)
[16:04]  * ogra has a box behind him on the shelf ... no drive either 
[16:04] <ogra> though i have a usb drive but it registers as /dev/sdX
[16:04]  * pitti -> meeting
[16:04] <Keybuk> I don't think I have _ever_ used the drive
[16:05] <mjr> just about any hd-lookalike will register as sdX these days
[16:05] <pitti> given my salary rate, it'd probably be ten times cheaper to just ship that poor guy an usb key instead of spending half a day fixing floppies :)
[16:05] <pitti> "there, fits 40.000 floppies"
[16:06] <Keybuk> ROFL
[16:06] <Keybuk> "Economics, with pitti"
[16:07] <ogra> mjr, well, its a floppy drive :)
[16:07] <mjr> oh *blink*
[16:07] <mjr> makes sense though
[16:07] <gorgapor>  how would I find out where the gnome-terminal color schemes are located, like tango, rxvt, xterm, linux console, etc? I'm sure they are some xml file somewhere, but I can't find them
[16:54] <sebner> pitti: poor you! devicekit-* gets renamed. surely a bad transition for everyone :\
[16:54] <pitti> sebner: I heard; I proposed the name :)
[16:54] <sebner> pitti: ahahaha!!!!!!!!
[16:54] <pitti> sebner: it's actually not too bad, only two or so rdepends
[16:54] <pitti> sebner: well, I didn't decide _that_ to rename it :)
[16:54] <sebner> pitti: oh fine than but for upstream projects ...
[16:55] <pitti> I just avoided having it called "disks"
[16:55] <pitti> yeah, it's a bit hairy for those; OTOH, gdu'sagvfs' API didn't change at all, which is what most apps really want to use
[16:55] <sebner> heh
[16:56] <pitti> argh, what did I write
[16:56] <pitti> "gdu's and gvfs'"
[16:56] <maco> renamed to...?
[16:57] <pitti> udisks
[16:58] <sebner> pitti: fine thenm, and with plymouth we are on the edge again :D (kernel guys decided to be funstoppers though :P)
[17:00] <Keybuk> pitti: wow
[17:00] <Keybuk> you're quite right
[17:00] <Keybuk> we should have totally named udisks in Klingon instead!
[17:01] <pitti> you found a translation for it? :-)
[17:01] <maco> Keybuk: then we'd be red hat
[17:02] <maco> (since someone in here, i think you, was recently complaining about opaque red hat naming)
[17:02] <pitti> oh, gdu'sagvfs'
[17:02] <ogra> when did redhat step back from all the kit names ?
[17:02] <ogra> shouldnt it be udiskit ?
[17:02] <pitti> isn't that "mount my disk now or I'll slice your throat"?
[17:02] <pitti> ogra: David wants to get away from that
[17:02] <ogra> haha
[17:02] <Keybuk> DaHmeyjaj!
[17:02] <ogra> i guess he gets tired of all the jokes
[17:03] <Keybuk> (lit. many good arrays :p)
[17:03] <Keybuk> ogra: s/redhat/David/
[17:03] <ogra> indeed
[17:03] <Keybuk> RH's preferred naming scheme of the week is "towns in MA"
[17:04] <ogra> as long as they dont start using animals :)
[17:04] <pitti> Keybuk: hm, "jaj" is "day", isn't it?
[17:05] <Keybuk> I thought -jaj was the good suffic
[17:05] <Keybuk> though google says it means "May"
[17:06]  * pitti looks for his muhaQwi
[17:09] <ion> keybuk, pitti: http://www.youtube.com/watch?v=LBtj4WoC6XA
[17:10] <pitti> lol
[17:15] <mdz> cjwatson, the fix for bug 364649 was not evident in my server test install
[17:15] <mdz> there's no /var/log/installer/media-info
[17:15] <Keybuk> ion: heard that before ;)
[17:16] <Keybuk> ion: he does a fun Metal version of the Klingon Anthem (Qoy qeylIs puqloD)
[17:16] <mdz> cjwatson, should I file a new bug or reopen that one?
[17:17] <cjwatson> mdz: please reopen it; I see the problem (it tries to copy /cdrom/.disk/info after /cdrom is unmounted)
[17:19] <mdz> cjwatson, so it will not have worked in 9.10 either?
[17:20] <cjwatson> correct :-/
[17:20] <cjwatson> ubiquity should still have been fine
[17:21] <Keybuk> huh
[17:21] <Keybuk> that's odd
[17:21] <Keybuk> I definitely see a /var/log/installer/media-info from u6y
[17:21] <Keybuk> in fact, I rely on it :p
[17:21] <cjwatson> "ubiquity should still have been fine"
[17:21] <cjwatson> it's d-i that's broken
[17:22] <Keybuk> ah, I was misunderstanding your use of "should"
[17:22] <cjwatson> mdz: actually, if you haven't reopened it already, the simplest fix is in cdrom-detect, if you could give me a new task there
[17:22] <Keybuk> and affirming that u6y *does* work fine :p
[17:22] <mdz> cjwatson, can do
[17:31] <cjwatson> mdz: fixed, sorry about that
[17:31] <mdz> cjwatson, no worries. did the ubiquity part take?
[17:31] <cjwatson> mdz: yes, as Keybuk confirmed above
[17:31] <mdz> ah, missed that,
[17:32] <mdz> and as you said as well
[17:32]  * mdz curses multitasking
[17:46] <tripzero> any idea when ubuntu will be getting a 2.6.31.{5,6} backport?
[17:46] <tripzero> ubuntu 9.10*
[18:05] <kees> asac: around?
[18:28] <seb128> is merges.ubuntu.com supposed to be regularly updated?
[19:03] <vimpulse> hi all.  I think that when Xorg is running, Control+Alt+Delete should pop up the Linux task manager.  That's what users migrating from Windows will expect.  What do you think?
[19:03] <maco> i think ctrl alt del means reboot in the *nix world
[19:04] <vimpulse> maco:  I think not in Xorg
[19:04] <vimpulse> maco:  also, Ctrl+Alt+Delete used to mean reboot in the Microsoft world, then MSFT changed it.  You can change it too.  :)
[19:04] <maco> wouldnt it be confusing if in X it gave you a task list but in a shell, instead of top it rebooted you?
[19:04] <maco> seems like a good way to lose your data
[19:04] <vimpulse> maco:  true.  I didn't think of that.
[19:22] <vimpulse> maco:  is there a way to prevent mode errors like the one you described?  Maybe the init maintainer could change init to listen for a different reboot key combo other than Control+Alt+Del?
[19:23] <maco> dunno about that
[19:23] <vimpulse> anyone?
[19:36] <Smwn> VAGINA!
[19:38] <vimpulse> cjwatson:  thanks.  :)
[19:39] <ikonia> cjwatson: thank you
[19:41] <slangasek> cjwatson: postinst-upstart-restart> - this is deliberate, see the 7.3.15ubuntu3 changelog entry for debhelper
[19:42] <cjwatson> slangasek: ah. thanks
[20:57] <smoser> slangasek, around?
[21:03] <slangasek> smoser: hi
[21:05] <smoser> you have thoughts ... i have to make a -desktop version for uec
[21:05] <smoser> for where i put it, i think /srv/ec2-images/uec-desktop/{karmic,hardy,lucid}/YYYYMMDD
[21:06] <smoser> rather than intermingling output with the -server stuff , which is in
[21:06] <smoser>  /srv/ec2-images/{karmic,hardy,lucid}/YYYYMMDD
[21:06] <smoser> does that sound right to you?
[21:08] <vimpulse> maco:  here's an idea.  Ctrl+Alt+Delete should not start up the task manager, since that would lead to mode errors.  But it should make an xmessage pop up telling users how they *can* start the task manager.
[21:09] <vimpulse> maco:  also, if it doesn't already, then Ctrl+Shift+Esc should cause the task manager to pop up.
[21:12] <smoser> slangasek, ^
[21:13] <slangasek> smoser: that seems reasonable
[21:14] <smoser> ok. thanks. and since i've got you here, could you read over the command at https://wiki.ubuntu.com/UEC/Images/Publishing "for-project ubuntu publish-release" ...
[21:14] <smoser> to make sure it is sane
[21:19] <vimpulse> maco:  gtg.  you can email me at jspiro at jspiro dot com
[21:20] <slangasek> smoser: mm, will be a bit before I can get to it; heading out to lunch shortly
[21:21] <superm1> can we sync v3 source packages now with the new launchpad?
[21:21] <smoser> no problem. thanks slangasek
[21:21] <cjwatson> superm1: sadly apparently that slipped to the *next* lp release
[21:22] <superm1> boo :(
[21:22] <superm1> and i don't suppose there's any chance for an out of band update for it then
[21:25] <crypt-0> hi
[21:25] <crypt-0> if i select a diffrent device other than the primary hard rive for /boot will grub and the MBR be installed to that device?
[21:28] <cjwatson> sort of. it isn't reliable right now. I have plans to fix that for lucid
[21:28] <Flannel> Did ubiquity (or any installer) get some fancy "I'm going to install -pae even though its not on the CD because you have 4GB of RAM" feature?
[21:28] <cjwatson> yes
[21:29] <Flannel> cjwatson: How does one disable it?
[21:29] <crypt-0> cjwatson, is there a way to manually install it ?
[21:29] <cjwatson> Flannel: not sure you can right now short of installing without a network attached, sorry
[21:30] <cjwatson> crypt-0: sure, grub-install ...
[21:30] <Flannel> Right, that's what I just suggested he do.
[21:30] <Flannel> cjwatson: Please fix that!
[21:30] <crypt-0> i want it to be reliable, because i want to be able to boot my primary HD from a usb stick
[21:30] <cjwatson> Flannel: why?
[21:30] <cjwatson> I mean, what active problem is it causing?
[21:30] <Flannel> cjwatson: Because -pae kernel panics for him
[21:30] <cjwatson> then surely to goodness that should be fixed in the -pae kernel
[21:30] <Flannel> True, but having a system is important in the meantime.
[21:30] <cjwatson> well, I can't fix it for karmic now anyway
[21:30] <crypt-0> cjwatson, the alternate installer will me choose where to install correct?
[21:31] <cjwatson> crypt-0: in expert mode, yes; as does ubiquity, in the Advanced dialog
[21:31] <crypt-0> also, since i will be installing to encrypted device, ...
[21:31] <crypt-0> ah ok
[21:31] <Flannel> cjwatson: It also should *say* that its doing so, since otherwise its magic handwaving that no one knows about
[21:31] <cjwatson> Flannel: it was a last-minute hack for karmic because we were getting lots of requests for it at a high level. please file bugs about problems
[21:31] <crypt-0> [ubiquity] is that the Desktop Cd with the GUI?
[21:31] <cjwatson> the installer is entirely entitled to do magic handwaving, though :)
[21:31] <cjwatson> crypt-0: yes
[21:32] <Flannel> cjwatson: Not without -pae being on the CD it isn't.
[21:32] <cjwatson> and I actually don't think it's appropriate for the desktop installer to tell you details like which kernel it's using
[21:32] <cjwatson> if the kernel doesn't work, that's what needs to be fixed
[21:32] <crypt-0> cjwatson, https://help.ubuntu.com/community/FeistyLUKSTwoFormFactor
[21:32] <crypt-0> i will be improving this guide
[21:33] <cjwatson> Flannel: it absolutely is; the kernel is not the only thing it installs from the network
[21:33] <crypt-0> im going to use TFA, so i will make a guide for 9.10
[21:33] <cjwatson> crypt-0: er, ok, I'm not going through that on a Friday night :)
[21:33] <crypt-0> if i want to improve that quite dated guide where could i do it?
[21:33] <Flannel> cjwatson: That's news to me.  Is this documented anywhere?
[21:33] <cjwatson> Flannel: no
[21:33] <cjwatson> it installs language packs from the network because they won't fit on the CD, in general
[21:34] <cjwatson> all points where it tries to download anything have (or at any rate should have) a Skip button
[21:34] <crypt-0> cjwatson, in short it is two-factor-authentication for LUKS, but it is for Feisty
[21:35] <crypt-0> i want to modify it and bump it up (update) some of the things for 9.10
[21:35] <cjwatson> Flannel: I'd like to fix the problem here, but I just want to do so by starting from the problem rather than by starting from a proposed solution :)
[21:35] <cjwatson> I usually find the former approach produces better results
[21:36] <Flannel> cjwatson: Bug report is being filed.  But again: doing magic handwavey things that potentially cause problems (and won't let you disable) is a pretty straight forward fix-- let you disable them.
[21:36] <crypt-0> and possibly have someone review it :) two factor authentication would be nice to document. Furthermore, it would be nice if i could code a script to do it with the automated crypto installer for the next release of Ubuntu.
[21:36] <cjwatson> Flannel: I agree that in this case it ought to be preseedable somehow
[21:36] <Flannel> I agree that problems are better than proposed solutions, but I juts don't think there's much debate in the matter.
[21:37] <cjwatson> one man's magic is another man's Doing The Right Thing
[21:37] <cjwatson> (oops: sorry, unintentional sexist language)
[21:37] <crypt-0> Basically, i want to get more involved in the Ubuntu development. Cryptography is my strong point, Two factor auth with your MRB and boot partition on a thumbdrive counter a lot of the new attacks on encryption.
[21:37] <cjwatson> Flannel: the thing to remember is that that isn't a fix, it's a workaround.
[21:38] <cjwatson> quite possibly a valuable one, but nevertheless a workaround
[21:38] <cjwatson> the installer does in general support lots of preseedable tweaks to its behaviour, we were just too rushed in this case
[21:39] <crypt-0> This would be very nice for people working with laptops that have to keep cooperate files secret.
[21:39] <Flannel> cjwatson:  https://launchpad.net/bugs/477050 is the PAE panic
[21:39] <cjwatson> I think I'd want to refactor the rather grotty hack in the process of making it more controllable
[21:40] <crypt-0> cjwatson, do a lot of the issues with 9.10 have to do with the new kernel being so much different than the old one?
[21:40] <cjwatson> crypt-0: I'm sorry, that's too vague a question for me to even contemplate answering
[21:40] <cjwatson> the kernel changes very substantially from release to release; and any operating system of the size of Ubuntu has lots of problems
[21:41] <crypt-0> I noticed the new version of g++ and c++ complicate the compiling of some programs (older versions do it fine)
[21:41] <cjwatson> g++ gets stricter with most releases
[21:41] <cjwatson> it is still fundamentally the fault of the program for not complying with the standards
[21:41] <crypt-0> for example turning a "warning" that the developer knows about into a fatal build error?
[21:41] <cjwatson> g++ used to be very permissive, and people got used to it; but I rather suspect it caused wider problems because lots of people wrote code to g++ that worked nowhere else
[21:42] <crypt-0> cjwatson, i agree.
[21:42] <cjwatson> if you have an issue with what g++ is doing, I suggest taking it to the g++ developers
[21:42] <cjwatson> it won't get noticed here
[21:42] <cjwatson> but I suspect they will simply tell you to either (a) fix your code or (b) use an older version of g++ until you can
[21:42] <crypt-0> well the forums are very helpful.
[21:42] <crypt-0> [older version] i do
[21:43] <crypt-0> i downgraded
[21:43] <cjwatson> there you go. it's not as if it expires. :)
[21:43] <crypt-0> right :D
[21:43] <cjwatson> it is not viable for Ubuntu to remain on older versions of the compiler suite forever.
[21:43] <mneptok> crypt-0: the Ubuntu forums are not the proper venue for filing bugs or feature requests against compilers
[21:44] <crypt-0> mneptok, im well aware of that. However some of the problems i have encountered with the new compiler were fixable with help from the forums.
[21:44] <mneptok> crypt-0: as cjwatson says, g++ does not throw errors for no reason. if you want to ignore them and have code that is out of language spec, use an old version. but the real solution is a code cleanup.
[21:45] <crypt-0> correct.
[21:46] <crypt-0> I compile a *lot* of code, i noticed the problems mostly with poorly maintained code or code that has not been updated for ages.
[21:46] <mneptok> so we're agreed it's not an issue with Ubuntu development, but rather an issue with a more strict compiler, and crufty code? if so, it's probably better to raise these issues with g++ maintainers, or seek c++ gurus to help clean up the cruft. :)
[21:46] <crypt-0> Yes.
[21:47] <crypt-0> I was just stating the problem.
[21:47] <mneptok> no worries.
[21:47] <mneptok> i say that not to be dismissive, but rather to point you at resources more likely to help solve your issues.
[21:48] <crypt-0> Im also looking for a "proper" way to package sun java so i can build packages for it.
[21:48] <crypt-0> I can make my own packages to update myself, but i want to help the community in general.
[21:48] <mneptok> !info sun-java6-jre
[21:49] <crypt-0> there are some complaints about the version being old, and i know it is "discontinued" and community maintained.
[21:52] <cjwatson> one would package it by updating the packaging already in the archive
[21:52] <cjwatson> I wouldn't recommend trying to create new packaging from scratch
[21:52] <crypt-0> Again, im not saying this is your fault: Im saying you have much bigger issues to deal with that building a java package. It is no problem for me to manually update, but i would like to be able to package java and build it so it can get included in updates. In case you are not aware it is still at 1.6.16 and 1.6.17 has been out for a while. Hardy already updated to 1.6.17 is there an easy way to grab the packages from the heady update repositories and
[21:52] <crypt-0>  port them to 9.10?
[21:53] <cjwatson> sure, grab the source package and debuild
[21:53] <crypt-0> cjwatson, in other words  apply a patch or a diff and upload the old pacage along with the patch and or diff?
[21:54] <cjwatson> debuild is a program name
[21:54] <cjwatson> it's odd that it's newer in hardy than in newer releases, I'm sure that could be fixed (in lucid at the very least)
[21:55] <crypt-0> i have tried to crawl through the mirror via a web browser to find the package. I do not want to enable hardy repos on my machine.
[21:55] <crypt-0> is there a way i can request the package from the hardy updates repo with wget?
[21:56] <cjwatson> sure, use packages.ubuntu.com
[21:56] <crypt-0> i tried i think the version was still at 1.6.6 :S
[21:56]  * crypt-0 tries again
[21:56] <cjwatson> http://packages.ubuntu.com/hardy-updates/sun-java6-bin
[21:57] <cjwatson> panel at the right has source download links
[21:57] <crypt-0> 6-17-0ubuntu1.8.04: amd64
[21:57] <crypt-0> cool
[21:58] <cjwatson> the source isn't architecture-specific, of course
[21:58] <crypt-0> last i checked the package was out of date on that
[21:58] <crypt-0> right.
[21:58] <cjwatson> I'm referring to the links under "Download Source Package sun-java6"
[21:58] <crypt-0> and the hardy package will *probably* install fine on 9,10
[21:58] <cjwatson> http://packages.ubuntu.com/source/hardy-updates/sun-java6 is probably clearer
[22:00] <crypt-0> cjwatson, do you have 2e6035430545cc59c3fd6f68f7b00708 as the md5sum for sun-java6_6-17.orig.tar.gz?
[22:00] <crypt-0> at the link you just pointed at.
[22:01] <cjwatson> crypt-0: I'm not going to answer that question because it's silly to compare md5sums over IRC. :)
[22:01] <crypt-0> true :)
[22:01] <crypt-0> unless this was a SSL network.
[22:01] <cjwatson> SSL is not a substitute for trust
[22:02] <crypt-0> any encryption is meaningless if the other end is compromised.
[22:02] <cjwatson> it's entirely possible to add deb-src lines to /etc/apt/sources.list and then use apt-get source sun-java6/hardy-updates (or something like that)
[22:02] <crypt-0> or in the case of an irc server, the other end or the server.
[22:03] <cjwatson> you can always remove it afterwards - and then you'll get signature checking
[22:03] <crypt-0> oh ok, so it will check the gpg sig for it?
[22:03] <crypt-0> ok :)
[22:03] <cjwatson> encryption/compromised> you're missing the point. the problem here is not the software, it's the people. I could be anybody.
[22:03] <cjwatson> yes, it will check the signature chain from Release.gpg through Release and Sources to the source files. you can do this by hand but it's tedious.
[22:04] <crypt-0> right, but chances are if someone was doing an attack on the ubuntu packages...they would not be hanging out here ready to give out evil MD5 sums...but they may.
[22:05] <crypt-0> GPG signing is much more secure, agreed.
[22:21] <crypt-0> $ gpg --verify MD5SUMS.gpg
[22:21] <crypt-0> gpg: no signed data
[22:21] <crypt-0> gpg: can't hash datafile: file open error
[22:22] <crypt-0> ah nevermind
[22:24] <crypt-0> gpg --verify MD5SUMS.gpg MD5SUMS :)
[22:28] <crypt-0> "While security flaws in the MD5 algorithm have been uncovered, MD5 hashes are still useful when you trust the organization that produces them. Moving to more secure hashes like SHA-256 and Whirlpool is under discussion. "
[22:29] <crypt-0> gpg-signed MD5 hashes are still secure.
[22:29] <crypt-0> Someone can also just make a SHA256 sum of the evil .iso file if the wanted.
[22:31] <crypt-0> I suppose suing SHA2 or Whirlpool could help. But a gpg signed MD5 i believe is as secure as GPG itself.
[22:31] <cjwatson> crypt-0: you know that we also have SHA256SUMS files on our CD image mirrors, right? ...
[22:31] <cjwatson> so this is moot
[22:32] <crypt-0> Yes.
[22:32] <cjwatson> the reason we still ship MD5SUMS has not a lot to do with its security, and a lot to do with the fact that md5sum.exe tools are more widespread on Windows than sha256sum.exe tools or equivalent
[22:32] <cjwatson> and for CD images this does matter
[22:33] <crypt-0> What i am saying is that regardless of how strong the hash is, someone can still hash their evil iso with it.
[22:34] <crypt-0> So no need for a stronger hash, when you give the gpg signed hashes already, assuming you can trust the integrity of the GPG key.
[22:35] <crypt-0> Dont get me wrong, this is not really a complaint, just my two cents.
[22:35] <cjwatson> the need for the strength of the hash is second-preimage resistance
[22:35] <jmarsden> crypt-0: Well, if the has were so weak one could deliberately create evil ISOs with the same hash as the non-evil one, there would be a problem... but I'm not sure #ubutnu-devel is the right place to be learning about cryptography
[22:35] <cjwatson> in other words, the ease of creating a second message with a known hash
[22:36] <cjwatson> MD5 is not at the stage yet when that is trivial, although I think you are a little blase in saying flatly that it's still secure. That's probably the case right now but it will probably not be the case in a few years, which is why we're migrating away from MD5.
[22:37] <jdstrand> cjwatson: it is my understanding that LP still can't do source format 3.0 (quilt). is that correct?
[22:37] <jdstrand> cjwatson: hi btw
[22:37] <cjwatson> jdstrand: that is unfortunately still the case - pushed back to the next LP release
[22:37] <jdstrand> k
[22:37] <crypt-0> Im saying it is secure if you trust the GPG key that signed the hashes.
[22:38] <jdstrand> cjwatson: are we doing anything special wrt to Debian packages using 3.0?
[22:38] <jdstrand> (with syncing)
[22:38] <cjwatson> crypt-0: you are mistaken.
[22:38] <cjwatson> jdstrand: putting them on hold
[22:38] <jdstrand> cjwatson: ok
[22:39] <jdstrand> cjwatson: thanks
[22:39] <cjwatson> jdstrand: I think in the odd case people have reverted to 1.0 and fakesynced
[22:40]  * crypt-0 has more reading to do :)
[22:41] <crypt-0> I usually check both the MD5, SHA1 and SHA256 sums, and their gpg signatures anyway.
[22:41] <cjwatson> crypt-0: the GPG signature is on the *hash*, and a hash can always (by the pigeonhole principle) be valid for more than one message. If you can discover another message with the same hash that's also a valid ISO image (and I have some reason to suspect that this might not be as hard as people tend to think; published manually-constructed MD5 collisions often seem to differ in quite a small number of bits), then the trust ...
[22:41] <cjwatson> ... assigned to the GPG key that signed it matters not one whit
[22:41] <cjwatson> crypt-0: it's a waste of time to check the weaker hashes
[22:41] <cjwatson> crypt-0: I haven't done the maths for SHA256, but checking both MD5 and SHA1 adds an upper bound of only six bits of security over checking SHA1 alone
[22:42] <crypt-0> Not to mention, SHA1 was broken in 2005.
[22:42] <cjwatson> that's slightly dodgy collision resistance. don't confuse it with second-preimage resistance
[22:43] <cjwatson> (source for my claim regarding only six bits of additional security from checking both hashes: http://cm.bell-labs.com/who/akl/hash.pdf)
[22:43] <cjwatson> argh, that link has died
[22:44] <crypt-0> confirmed.
[22:45] <cjwatson> at any rate the lay summary is that MD5 and SHA-1 (and similarly SHA-256) are not fundamentally sufficiently different algorithms in a strong enough sense for multiple checks to provide much extra security
[22:45] <crypt-0> would be nice to add it to my stack of white papers though.
[22:47] <cjwatson> the reference is Antoine Joux' multicollisions paper from CRYPTO 2004, if you can find an online copy.
[22:48] <cjwatson> there's a slightly stronger result in http://eprint.iacr.org/2004/304.pdf, but I haven't finished reading that.
[22:49] <wgrant> jdstrand, cjwatson: Note that the next LP release is supposedly a little under two weeks away, so it's not toooo long.
[22:50] <jdstrand> wgrant: appreciated, I'm just putting a comment in the sync bugs for now