[00:00] <SpamapS> hallyn: lp:~clint-fewbar/debigem/trunk
[00:00] <SpamapS> hallyn: that one is native
[00:00] <SpamapS> builds perfectly with bzr-buildpackage --native
[00:01] <SpamapS> hallyn: do you have "3.0 (native)" in debian/source/format ?
[00:01] <SpamapS> hallyn: if not, try that :)
[00:08] <hallyn> SpamapS: oh, no i do not
[00:52] <SpamapS> hallyn: did that help?
[00:58] <hallyn> SpamapS: yes, it does, and it's a lot faster than using export-upstream :)
[00:58] <hallyn> thx
[00:59] <SpamapS> sweet
[01:43] <james_w> SpamapS: please file a bug on the missing but there thing
[01:43] <james_w> hallyn: please file a bug on the --native not working for you first time if possible
[01:44] <james_w> hallyn: just the log from your attempts would probably help me diagnose.
[02:02] <SpamapS> james_w: will do
[02:07] <hallyn> james_w: well, i didn't have debian/source/format set.  is that then still a bug, or user error?
[02:12] <james_w> hallyn: still a bug
[02:13] <james_w> any confusion is worth examining to see if it can be alleviated
[02:14] <hallyn> james_w: ok, will do, thanks
[02:54] <ebroder> I'm trying to figure out how cryptsetup and mountall interact. I have a swap LV that's not configured as a potential resume partition (the key is regenerated at boot) and therefore isn't decrypted from the initrd. It *seems* like the cryptdisks-enable and mountall jobs will race, right?
[02:54] <ebroder> Err, rather, they seem to be racing
[02:55] <ebroder> Regardless of whether I set nobootwait or not, the boot seems to succeed without interference and the swap is enabled by the time boot completes
[02:55] <ebroder> But I can't find any setting that will kill mountall's "unable to find device" plymouth message
[03:03] <cwillu_at_work> ebroder, do not concern yourself with the secrets of scary people
[03:06] <cwillu_at_work> ebroder, what does nobootwait do again?
[03:06] <cwillu_at_work> I think I understand the process, but I want to hear your interpretation before I explain what happens
[03:06] <cwillu_at_work> i.e., if I'm wrong, I'd like to find out before I start saying stuff :p
[03:08] <ebroder> cwillu_at_work: Actually, I'm still trying to work it out. It looks like mountall has some sort of udev trigger or something? So when cryptdisks-enable runs, it'll trigger mountall to try mounting stuff again
[03:08] <ebroder> Which I guess explains why the boot doesn't completely fail when I *don't* have nobootwait sent
[03:09] <cwillu_at_work> ebroder, cryptdisks-enable isn't the relevant job here I don't believe
[03:09] <cwillu_at_work> cryptdisks-udev is the magic
[03:10] <ebroder> Eh. They're basically the same thing, right? One does initialization, and one responds to events after initialization?
[03:10] <cwillu_at_work> it also handles mounting the contained devices
[03:10] <ebroder> Wait, really?
[03:10] <cwillu_at_work> i.e., it does a "mount /dev/unlocked_device"
[03:10] <cwillu_at_work> which will only do anything if it's listed in fstab
[03:10] <cwillu_at_work> yep, read /lib/cryptsetup/cryptdisks.functions
[03:11] <cwillu_at_work> crypttab_start_one_disk calls mount_fs
[03:11] <cwillu_at_work> and mount_fs does: mount "$point"
[03:12] <ebroder> Huh. Will mount do a swapon?
[03:12]  * cwillu_at_work giggles
[03:13] <cwillu_at_work> hmm
[03:13] <ebroder> cwillu_at_work: No, it won't. It'll complain about the mountpoint not existing
[03:13] <cwillu_at_work> ebroder, oddly, there's nothing that does a swapon in my /etc/init*/*
[03:13] <ebroder> cwillu_at_work: Yes there is - mountall
[03:13] <cwillu_at_work> mountall emits all-swaps
[03:14] <cwillu_at_work> it doesn't swapon
[03:14] <ebroder> The init job doesn't, but the mountall daemon does
[03:15] <cwillu_at_work> that's unfortunate: /
[03:15] <cwillu_at_work> have you looked at its source yet?
[03:15]  * cwillu_at_work dives in
[03:16] <ebroder> I've tried to, but I haven't managed to grok Keybuk's style yet
[03:16] <cwillu_at_work> heh
[03:16] <cwillu_at_work> I love the nih_ prefix :p
[03:20] <cwillu_at_work> ebroder, you're _only_ asking about swap devices?
[03:20] <cwillu_at_work> or are you concerned about normal mounts too?
[03:20] <ebroder> Nope, just swap
[03:20] <cwillu_at_work> it doesn't ever wait on swap
[03:20] <cwillu_at_work> at least, if I'm reading it right
[03:23] <ebroder> Maybe I need to spend some more time figuring out what exactly the failure I'm seeing is
[03:24] <cwillu_at_work> among other things:  (no)bootwait has no effect on swaps:  it checks whether something is swap in the same if tree as it later checks for that tag
[03:25] <cwillu_at_work> in mount_policy, swaps never have anything added to their dependencies
[03:27] <cwillu_at_work> ugh, I hate dpatch
[03:29]  * cwillu_at_work threatens to sue if dpkg-buildpackage doesn't work from inside dpatch-editpatch's hackjob
[03:30] <cwillu_at_work> ebroder, are you an ubuntu dev, or just another poser like me? :D
[03:41] <cwillu_at_work> does anyone know if our bash has readline statically compiled in?
[03:42] <cwillu_at_work> I'm trying to fix some broken history behaviour, but bash doesn't seem to be using any readline libs, let alone my modified ones
[03:42]  * cwillu_at_work blinks, as he finally notices bash-static is installed
[03:42] <cwillu_at_work> but... that's not what I'm running anyway
[04:02] <cwillu_at_work> and yes, our bash has readline compiled in
[04:02] <cwillu_at_work> drat
[07:30] <dholbach> good morning
[07:33] <pitti> Good morning
[07:33] <dholbach> hi pitti :)
[07:34] <pitti> hey dholbach, how are you?
[07:34] <dholbach> great - how are you?
[07:37] <pitti> I'm great, thanks!
[08:35] <iulian> Morning dholbach.
[11:16] <dholbach> thekorn, Happy Birthday! :)
[11:24] <pitti> thekorn: ooh, alles Gute zum Geburtstag!
[11:25] <thekorn> dholbach: pitti vielen Dank
[11:25] <dholbach> :-)
[11:44] <hyperair> ScottK: did you get around to checking out libgpod?
[11:46] <Laney> he's away
[11:47] <Laney> hyperair: you should just get it sponsored to the proposed queue and it will be reviewed there
[11:47] <tkamppeter> pitti, I have a fix for bug 653814.
[11:47] <Laney> (assuming that's what you mean)
[11:49] <tkamppeter> pitti, the bug was caused by changes done to make PPDs for Ricoh printers correctly selected depending on whether an optional PostScript module is installed or not, but for HP PostScript printers PCL PPDs got selected instead of PostScript PPDs.
[11:50] <tkamppeter> pitti, as HP lasers are rather common I think this is very important for Maverick. should I upload the two packages containing the fix?
[11:52] <hyperair> Laney: yeah, i asked him to sponsor it for me
[11:52] <Laney> hyperair: didrocks might fancy it ;)
[12:36] <shadeslayer> ion: i still have that archive signing bug
[12:36] <shadeslayer> everything is updated and ubuntu-extras-keyring is installed
[12:37] <shadeslayer> and when i tried to remove and reinstall that package i got gpg: key "3E5C1192" not found: eof
[12:39] <fta> mvo, hi, any idea about bug 654782? corrupted deb file or bug in apt/dpkg?
[12:40] <shadeslayer> ion: ok fixed with sudo apt-get --reinstall install ubuntu-extras-keyring
[12:53] <pitti> tkamppeter: if they have an unintrusive and precise patch, please go ahead
[12:55] <tkamppeter> pitti, OK.
[12:59] <tkamppeter> pitti, done.
[12:59] <hyperair> didrocks: hey do you have upload access to main?
[13:01] <didrocks> hyperair: yes
[13:01] <didrocks> hyperair: need sponsoring?
[13:01] <hyperair> didrocks: would you mind uploading libgpod to -proposed?
[13:01] <hyperair> didrocks: yeah.
[13:02] <hyperair> https://bugs.launchpad.net/ubuntu/+source/libgpod/+bug/652855
[13:02] <hyperair> needs a fakesync
[13:02] <didrocks> hyperair: ah, the libpod change :-) sure, as we discussed it with the desktop team :)
[13:02]  * hyperair nods =)
[13:02] <bdrung> doko: i did a quick look, but i have not enough time to work on them
[13:02] <hyperair> you were there during the discussion?
[13:02] <Laney> haha @ the last comment there
[13:03]  * hyperair only recalls talking to seb128 about it
[13:03] <doko> bdrung: looks like we have to disable these ...
[13:03] <didrocks> hyperair: yeah, I read it :-)
[13:03] <hyperair> aah
[13:04] <didrocks> hyperair: I was around, I just don't speak when I don't have any valuable input from my point of view (at least, I try :p)
[13:04] <bdrung> doko: yes
[13:05] <doko> bdrung: let me know if you can help with the removal
[13:05] <hyperair> didrocks: try, eh? =p
[13:05] <bdrung> doko: this week probably not
[13:52] <zul> pitting: ping the landscape-client SRUs have been verified as fixed can we move them into updates?
[14:02] <seb128> tkamppeter, hey
[14:03] <seb128> tkamppeter, do you know if somebody is working on porting system-config-printer to gtkbuilder?
[14:05] <tkamppeter> seb128, no.
[14:05] <tkamppeter> seb128, what is gtkbuilder
[14:06] <soren> It's just like glade, only different.
[14:06] <seb128> tkamppeter, https://bugs.edge.launchpad.net/ubuntu/+source/system-config-printer/+bug/403540
[14:06] <tkamppeter> soren, seb128, is glade about to be deprecated in favor of gtkbuilder?
[14:07] <soren> zul: pitting? pitti - next generation?
[14:07] <seb128> tkamppeter, it's not 'about to', it has been a year ago
[14:07] <pitti> zul: can do
[14:07] <seb128> tkamppeter, but we want to drop libglade from the default installation next cycle
[14:07] <seb128> tkamppeter, system-config-printer is one of the few software which has not been ported yet
[14:07] <geser> soren: better than the current one? :)
[14:07] <soren> geser: Impossible :)
[14:08] <zul> pitti: thanks
[14:08] <zul> soren: not enough caffine :)
[14:08] <pitti> zul: ah, just 7 days today, so right on time
[14:08] <zul> pitti: excelent
[14:09] <tkamppeter> seb128, this would depend on Tim Waugh, the principal maintainer of system-config-printer.
[14:10] <seb128> tkamppeter, could you ask him if he has any plan to work on that?
[14:10] <seb128> I guess fedora will want that as well since they are porting everything to be GNOME3 compliant as well
[14:14] <tkamppeter> seb128, I asked him in the bug report now.
[14:14] <soren> seb128, tkamppeter: http://cyberelk.net/tim/2010/03/17/system-config-printer-1-2-0/ says it's already using GtkBuilder?
[14:14] <seb128> tkamppeter, thank you
[14:14] <seb128> soren, oh, nice
[14:15] <seb128> we have 1.1. though
[14:15] <soren> system-config-printer | 1.2.3+20100723-0ubuntu7 |      maverick | source
[14:15] <soren> ?
[14:15] <seb128> soren, hum, my mistake
[14:15] <seb128> so maybe just somebody who forgot to clean the control depends?
[14:15] <seb128> checking...
[14:16] <soren> It's gui.py certainly uses GtkBuilder.
[14:16] <soren> s/It's/Its/ darn it.
[14:17] <seb128> ok, I got confused
[14:17] <soren> The only mention of glade is a comment and the name of the xml file.
[14:17] <seb128> they didn't rename their .glade to .ui and the depends didn't get updated
[14:17] <soren> ...and debian/control, clearly.
[14:17] <seb128> soren, thanks ;-)
[14:18] <seb128> tkamppeter, ^ their ported the code, you need to drop the depends on python-glade2 in the next upload
[14:18] <soren> seb128: Oh, thank *you*. I was desperately looking for an excuse to do something else for a few minutes. :)
[14:18] <seb128> lol
[14:19] <tkamppeter> seb128, I have done an upload to Maverick some minutes ago, to fix bug 653814, should I replace it to drop this dependency in Maverick or should I wait until Natty with that?
[14:19] <seb128> tkamppeter, you can wait until next cycle
[14:20] <seb128> tkamppeter, we still have some other packages in the default installation depending on it
[14:20] <seb128> so it will not make a difference to drop it now
[14:20] <tkamppeter> OK, so first Natty upload should drop this dependency to magically free ups some megs on the CD.
[14:21] <seb128> tkamppeter, thanks
[14:21] <seb128> it's probably some megs, the library is small, but it's less cruft in any case ;-)
[14:38] <micahg> Riddell: do you have time to process 2 removals from the archive?
[14:44] <Riddell> micahg: if they're reported as bugs and subscribed to ubuntu-archive I'm going to process them shortly
[14:50] <micahg> Riddell: awesome, thank you
[14:55] <jibel> pitti, I think that you can publish debian-installer 20081029ubuntu102.4 to lucid-updates, the kernel in updates is already 2.6.32-25 and dove is 2.6.32-209.25, there is no bug report attached.
[14:56] <pitti> jibel: already done
[14:56] <pitti> jibel: thanks
[14:56] <jibel> pitti, thank you
[15:00] <cjwatson> pitti: please note https://wiki.ubuntu.com/ArchiveAdministration#Special%20case:%20debian-installer%20updates
[15:00] <cjwatson> I'm going to apply that now
[15:01] <cjwatson> (done)
[15:07] <pitti> ah, thanks
[16:28] <philsf> pitti, about bug #642792, what about reverting the kernel patch? Could this be done in time for release?
[16:29] <pitti> philsf: no, the kernel is solidly frozen; there's not enough time to prepare, test, upload, build, and publish a new kernel until the release
[16:29] <pitti> that's why I mentioned "needs to become an SRU now"
[16:29] <philsf> pitti, I figured. thanks for the clarification
[17:21] <tkamppeter> pitti, hi
[18:02] <fta> pitti, hi, when there's a problem while unpacking a deb, does apport trigger the corresponding package hooks?
[18:02] <fta> pitti, wrt bug 654782
[18:02] <pitti> fta: it sohuld, yes
[18:03] <fta> pitti, so i guess i should tweak my hooks to prevent that error, right?
[18:03] <seb128> fta, there quite some bugs similar to this one
[18:04] <fta> seb128, oh, really? i should dupe this one then
[18:04] <pitti> fta: looks like the apport hooks did run, why?
[18:04] <pitti> fta: but yes, this seems like a common problem, not specific to chromium
[18:04] <seb128> fta, could be due to disk running out of space
[18:05] <seb128> bug #108837
[18:05] <fta> pitti, i meant, i should not try to export stuff from the user chromium profile in that case
[18:05] <pitti> ah, right
[18:06] <fta> seb128, it's not a disk full: http://launchpadlibrarian.net/57097434/Df.txt  (unless it's short of inodes)
[18:12] <penguin42> fta: That's a buffer read error not write, so isn't that where it's coming from?
[18:12] <cjwatson> usually means i/o error reading from disk or something like that
[18:13] <cjwatson> (reading the .deb, specifically)
[18:36] <didrocks> pitti: just back on bug #642792, the drawback is that now my SysReq key (which is Fn + printscreen) on my laptop is no longer working. I was asking myself when I had to use it why I cDouldn't…
[18:58] <wathek> jello all
[18:59] <wathek> hello all
[18:59] <wathek> is it possible to make xorg work with my multitouch table using TUIO ? like in this http://www.tuio.org/images/diagram.png ?
[19:05] <vish> cjwatson: hi, could you have a look at Bug #653259 ?  it causes problems in a few apps, is there a reason ubiquity does not append the .utf8 ?
[19:07] <cjwatson> $ grep en_IN /usr/share/i18n/SUPPORTED
[19:07] <cjwatson> en_IN UTF-8
[19:07] <cjwatson> ubiquity is correct, the apps are wrong
[19:07] <cjwatson> compare:
[19:07] <cjwatson> $ grep en_GB /usr/share/i18n/SUPPORTED
[19:07] <cjwatson> en_GB.UTF-8 UTF-8
[19:09] <vish> cjwatson: i'm not sure which is right.. but it was causing problems in gwibber which was fixed.. but likely there maybe other apps not factoring this
[19:10] <cjwatson> the apps are wrong and need to be fixed.  there are interfaces available for this
[19:10] <cjwatson> sorry, it's that simple I'm afraid
[19:11] <vish> cjwatson: nah, np. if it is intended then could you close the bug with a comment?
[19:11] <cjwatson> already done
[19:11] <vish> thx.
[19:14] <cjwatson> vish: BTW, I have experience implementing this on the application side and am happy to advise anyone who is confused about it
[19:16] <vish> cjwatson: cool! will direct any /confused/ folks to you, if i notice similar bugs.
[19:17] <cjwatson> the background is that .UTF-8 was added to locale names purely in order to distinguish them from legacy non-Unicode locales
[19:17] <cjwatson> the POSIX specification is absolutely clear that locale names are opaque and applications aren't allowed to try to interpret them
[19:17]  * vish nods..
[19:18] <cjwatson> now, in some cases you actually have to - OS installers certainly need to know a certain amount about the OS, sometimes you need to try to work out the language as well rather than leaving it to gettext, etc.
[19:18] <cjwatson> but if you're doing anything like that then you're skating along the edges of what's allowed and you need to make sure that it works with all valid locales
[19:20] <vish> k
[19:26] <kenvandine> cjwatson, makes sense, i wasn't sure where the bug really was and the code in gwibber that it caused a problem for was actually useless :)
[19:27] <cjwatson> sometimes the way :)
[19:27] <kenvandine> cjwatson, the thing that really complained was python, locale.setlocale wouldn't set the locale back to what it was previously set at
[19:28] <kenvandine> error was the encoding was wrong
[19:28] <kenvandine> that useless code hitting the exception in setlocale, was preventing messages from getting parsed... nasty bug
[19:28] <cjwatson> that sounds like a different bug.  locale.setlocale works fine with en_IN
[19:28] <kenvandine> it does, sort of
[19:29] <kenvandine> if you do loc = locale.getlocale(locale.LC_TIME)
[19:29] <kenvandine> and then locale.setlocale(locale.LC_TIME, loc)
[19:29] <kenvandine> it blows up
[19:29] <kenvandine> something like that, typing from memory
[19:29] <cjwatson> oh wow, that's totally a python bug
[19:29] <cjwatson> >>> loc
[19:29] <cjwatson> ('en_IN', 'ISO8859-1')
[19:30] <kenvandine> i think the exception was that the encoding wasn't valid for the locale
[19:30] <kenvandine> something along those lines
[19:30]  * kenvandine doesn't know enough about locales
[19:30] <cjwatson> the locale module is just wrong
[19:31]  * kenvandine moves the bug there
[19:31] <kenvandine> if i choose en_IN from gdm, it works fine
[19:31] <cjwatson> the odd bit is that it actually does use nl_langinfo
[19:31] <kenvandine> but it sets the encoding to UTF-8
[19:31] <cjwatson> just not in the right place
[19:31] <cjwatson> (it uses it in getpreferredencoding)
[19:33] <cjwatson> still buggy in python3
[19:34] <kenvandine> cjwatson, since you clearly know WAY more about this than I, care to comment on the bug?
[19:34] <cjwatson> subscribe me to whichever bug it is and I'll have a look tomorrow
[19:35] <kenvandine> thx
[19:36] <maxb> james_w: Could you requeue_package deja-dup? It just unexpectedly succeeded locally
[19:43] <YokoZar> Someone approve my ia32-libs upload so I can do a ritualistic dance
[19:48] <ari-tczew> SpamapS: ping
[19:51] <SpamapS> ari-tczew: pong? wassup
[19:52] <ari-tczew> SpamapS: I've commented your patch for drupal (@bzr). What do you think about apply patch to older releases?
[19:59] <SpamapS> ari-tczew: I think it would be worthy of a Lucid SRU.. maybe Hardy.
[20:00] <ari-tczew> SpamapS: why just that?
[20:08] <SpamapS> ari-tczew: Oh, it could probably be SRU'd to all the others, true. ;)
[20:09] <ari-tczew> SpamapS: cool! do you planning prepare patches for SRUs?
[20:41] <SpamapS> ari-tczew: I usually wait until the fix makes it into the current dev release before nominating for SRU's
[20:50] <ari-tczew> SpamapS: good point, true. :)
[21:00] <kees> slangasek: my /etc/pam.d/sudo lists pam_limits.so as "required", but doesn't seem to work. i.e. when I sudo, I lose all the settings from limits.conf. have you run into anything like that?
[21:59] <slangasek> kees: sudo'ing to root?  '*' limits don't apply to root
[22:01] <kees> oh. heh
[22:01] <kees> dur
[22:34] <ogra_ac> crimsun, you around ?
[22:36] <ogra_ac> crimsun, i'm looking for info where and how /usr/share/alsa/init/00main is used in the initalization process, it appears that only alsactl init seems to actually use it (see LP: #637947)
[22:45] <myrkraverk> pitti% Are you there by any chance?
[22:51] <\sh> myrkraverk: hopefully is went to bed ;)
[22:51] <\sh> s/is/he/
[22:51] <myrkraverk> \sh% Ah.
[22:52] <ajmitch> \sh: aren't you in the same timezone? :)
[22:53] <\sh> ajmitch: yes...but I just finished with an SSL update rollout during the evening hours
[22:54]  * ajmitch hopes it went well
[22:56] <\sh> ajmitch: yes..and it went fast..it took only 20 minutes for 50 servers ;)
[22:57] <\sh> 5 mins for the linux machines with puppet + terminator , and 15 mins for the windows crap
[23:46] <SpamapS> wow.. this maintainer script is doing all these crazy things with conffiles and has one comment "Prepare to move a conffile without triggering a dpkg question"