[09:40] <kees> pitti: I've added you to the recipient list of the kernel abi checking tool (it runs hourly now)
[09:42] <pitti> kees: oh, that's even better; thanks!
[09:43] <kees> np :)
[09:43] <kees> pitti: oh, btw, I have a demo of bug 726814 for you, if you need. it's very exciting. I was hoping you might have some insight into it.
[10:14] <pitti> cjwatson: for the defaults builder, would /usr/share/pkgname/locale.txt with a single default locale be enough to derive a sensible default keyboard layout, or do we always need to specify that explicitly?
[10:18] <barry> cr3: daily nag: checkbox :)
[10:40] <Laney> pitti or cjwatson: please moderate my t-b@ mail :-)
[10:40]  * Laney seeks guidance from the elders
[10:40] <pitti> Laney: done
[10:40] <Laney> ty
[11:07] <cjwatson> pitti: I think it would be better to have people who are preparing defaults packages specify the keyboard layout they want
[11:08] <cjwatson> pitti: since there certainly isn't a universally correct mapping from locale to keyboard layout
[11:08] <pitti> cjwatson: right, they should be able to, but do they need to?
[11:08] <pitti> ISTR that if I select a language in gfxboot, it automatically selects a reasonable layout, too
[11:12] <sidd_mak> how to integrate a media player in gnome sound panel...??
[11:12] <cjwatson> pitti: reasonable for you :-)
[11:12] <cjwatson> pitti: but I guarantee you that somebody's going to be unhappy with some entry in that giant mapping table
[11:12] <cjwatson> pitti: German is a pretty uncontroversial case, but not all locales are so easy
[11:12] <pitti> cjwatson: oh, absolutely
[11:13] <pitti> cjwatson: I was just asking whether it should require specifying a layout if you specify a locale
[11:13] <cjwatson> we could use a default as long as there's some way to override it
[11:13] <pitti> and my gut feeling is that we shouldn't
[11:13] <cjwatson> ok
[11:32] <lifeless> bryceh: ping
[13:08] <kirkland> lamont: ping
[13:09] <lamont> ?
[13:09] <lamont> don't ping, ask
[13:10] <nigelb> woah, internet went off in dublin?
[13:10] <StevenK> It did?
[13:11] <nigelb> Almost everyone with a conference host seems to have disconnected
[13:11] <StevenK> That's because it's lunch time!
[13:11] <nigelb> Ah, that explains that :)
[14:05] <slangasek> lamont: kirkland is pinging about util-linux regression in handling /sys in /etc/mtab
[14:06] <slangasek> lamont: have you seen the bug, by chance?
[14:25] <pitti> cjwatson: oh, I've been meaning to ask you: what would be a pallatable form of specifying the keyboard layout in a defaults package? the four XKB* variables that /etc/default/keyboard
[14:26] <pitti> ... sets?
[14:26] <pitti> or only a single value which maps to gfxboot?
[14:28] <cjwatson> pitti: I'd go for the format that our loadkeys command accepts: e.g. "de" or "de:dvorak"
[14:28] <cjwatson> layout or layout:variant
[14:28]  * cjwatson checks what gfxboot likes
[14:28] <cjwatson> oh, hm, one moment
[14:29] <cjwatson> actually, I think layout or layout_variant would be easiest to process
[14:30] <StevenK> cjwatson: O hai -- are you attached to Dapper or Karmic, or can we obsolete them?
[14:38] <cjwatson> skaet: ^- StevenK above
[14:39] <skaet> StevenK, Dapper is ok to obsolete,  we have to give an overlap on Karmic.
[14:39] <pitti> cjwatson: ok, layout{,_variant} it is then; is there a list of all available ones somewhere, which the documentation could refer to?
[14:39] <StevenK> skaet: Hasn't Karmic been EOL'd for months, though?
[14:40] <pitti> cjwatson: oh, nevermind; sohuld be in loadkeys, I'll have a look
[14:40] <skaet> SteveK,  OEM wants a 6 month buffer
[14:40] <StevenK> skaet: Right, so when does that get reached?
[14:40] <cjwatson> pitti: xkb-data
[14:41] <cjwatson> pitti: loadkeys just uses that (indirectly)
[14:41] <cjwatson> pitti: don't, whatever you do, refer to any of the old Linux-console-only keyboard maps you might find lying around :)
[14:41] <highvoltage> imo there should really be a revisiting of the ubuntu release/support cycle at some point
[14:42] <skaet> SteveK,  Karmic EOL'd on 4/30,  10/30 we can move off.
[14:43] <pitti> cjwatson: so /usr/share/X11/xkb/rules/xorg.lst looks very close already; at least it's easy enough to parse to be able to check if the user specified a valid one
[14:43] <skaet> StevenK, ^^
[14:43] <pitti> cjwatson: thanks!
[14:43] <StevenK> skaet: Ah, thank you.
[14:44] <StevenK> skaet: I'm working on obsoleting Dapper.
[14:44] <skaet> StevenK, thank you.  :)
[14:48] <cjwatson> pitti: yes; there's also xorg.xml if that's easier
[14:49] <davidboy> ohai.  I know this isn't quite the right place, but can someone please tell me what I'm doing wrong with this code?  http://pastie.org/2134172
[14:50] <davidboy> I've sat in ayatana all day last week and noone knew anything
[15:18] <davidboy> Dammit.  This is such a tiny problem ... should be easy, but I can't figure out anything I'm doing wrong
[15:27] <RoAkSoAx> cjwatson: ping
[15:28] <cjwatson> RoAkSoAx: content please
[15:28] <RoAkSoAx> cjwatson: I seek your advice with something. koan, a tool that comes with cobbler has a feature "--replace-self" where basically downloads a kernel/initrd to replace the installation of the local machien
[15:29] <RoAkSoAx> cjwatson: it uses grubby at the moment, but that's only working for grub1 obviosly
[15:29] <RoAkSoAx> cjwatson: so I'm working on getting grub2 supported. So I was wondering what's the best approach to do this
[15:29] <RoAkSoAx> cjwatson: I'm doing something similar to doign this: http://pastebin.ubuntu.com/634324/ (in Python, just hardcoding stuff atm)
[15:30] <RoAkSoAx> cjwatson: once creating the file, running update-grub to add the entry to grub, so on next reboot, I can select that and get Ubuntu reinstalled...
[15:31] <RoAkSoAx> cjwatson: is that a good approach to handle things with grub, in this case? (Just creating a file for the entry everytime I want to replace the current installation?)
[16:14] <TheMuso> diwic: Is that jack detection meeting still going ahead? if so I'll be down in 15 minutes or so for it.
[16:16] <diwic> TheMuso, it should start in 15 min. Currently there is another meeting in this room and I'm not sure it'll finish in time.
[16:50] <tkamppeter> pitti, hi
[16:55] <pitti> tkamppeter: hello Till
[16:55] <tkamppeter> pitt, can you pass the Natty SRU of CUPS to -updates
[16:56] <tkamppeter> pitti, and upload CUPS with my last cups-avahi.dpatch update to Oneiric, so that people can test on the sprint? Thanks.
[16:56] <pitti> tkamppeter: natty SRU is only 3 days old, needs 7 days
[16:56] <pitti> doing oneiric now
[16:57] <pitti> see #u-desktop, cups only moved to testing today, and I was waiting for that
[16:57] <tkamppeter> pitti, the SRU is already verified.
[16:58] <pitti> yes, but it needs to mature in proposed for 7 days to catch regressions
[16:58] <pitti> see https://wiki.ubuntu.com/StableReleaseUpdates
[16:59] <tkamppeter> pitti, OK, so do it on your first SRU day of next week, for the Sprint the Oneiric upload is more important. People hhave Oneiric there.
[16:59] <pitti> you could send a call for testing to ubuntu-devel@
[16:59] <pitti> with instructions how to test it
[16:59] <tkamppeter> pitti, is there a printer on the Sprint?
[17:00] <pitti> tkamppeter: just asked; there is one broken one which we can borrow
[17:01] <tkamppeter> pitti, I have already sent one to ubuntu-devel-discuss@ last week. should I simply repeat it on ubuntu-devel@?
[17:01] <pitti> tkamppeter: we need to connect it to an oneiric box, and then try to print something from an iphone?
[17:02] <pitti> (FWIW, most folks have android here, but we ought to find an iphone here)
[17:02] <tkamppeter> pitti, if it is good enough for testing (one can set up a queue and recognize the input file on the paper) then it is OK.
[17:02] <tkamppeter> pitti, that's it.
[17:03] <tkamppeter> pitti, what about the call for testing? Should I repeat it on ubuntu-devel@?
[17:03] <pitti> tkamppeter: you can try
[17:03] <tkamppeter> pitti, will do.
[17:04]  * TheMuso has an iphone.
[17:19] <tkamppeter> pitti, done.
[17:39] <apw> pitti: hi, i am looking at lp:ubuntu/oneiric/udev and it seems to be majorly out of date compared to the archive
[17:41] <cjwatson> apw: try lp:~ubuntu-core-dev/ubuntu/oneiric/udev/ubuntu, which is where the work's actually done
[17:41]  * cjwatson goes to update the Vcs-Bzr field
[17:41] <apw> cjwatson: i am confused how the importer branches can be out of date tho.
[17:41] <cjwatson> bug
[17:42] <cjwatson> (bugs.launchpad.net/udd)
[17:43] <cjwatson> maxb has been nuking vast numbers of importer failures recently; I assume he hasn't got round to this one yet ...
[17:43] <maxb> Hello
[17:44] <cjwatson> RoAkSoAx: I'm failing to understand, and will come round.  Are you in the server room?
[17:44] <maxb> Ah, that's one of the NoFinalPath ones
[17:44] <maxb> I had a quick look at those, and decided I need to get some support for someone knowing bzrlib internals better than I for that.
[17:45] <maxb> apw: Because the importer threw an exception whilst importing
[17:45] <maxb> Although annoyingly, it only broke in the bit where it tries to generate a preview merge diff, which I'm not sure really get used much
[17:50] <slangasek> jelmer: ^^ maxb is asking for you to help put him to work :-)
[17:50] <maxb> hah
[17:50]  * jelmer ducks
[17:51] <jelmer> maxb: hi
[17:51] <slangasek> lamont: ribbit
[17:54] <RoAkSoAx> cjwatson: I'm doing this (maybe my code explains itself better :) ): http://paste.ubuntu.com/634419/
[17:55] <cjwatson> RoAkSoAx: it would be easier to see the (grub legacy) original
[17:55] <cjwatson> I don't really understand what this is trying to do, right now
[17:56] <RoAkSoAx> cjwatson: this looks better: http://paste.ubuntu.com/634428/
[17:58] <cjwatson> RoAkSoAx: please just tell me where I can see the original?
[17:58] <cjwatson> I don't want to read a diff right now, I want to study the original code to understand what it's doing
[17:58] <RoAkSoAx> cjwatson: bzr branch lp:ubuntu/cobbler , file is under koan/app.py
[17:58] <cjwatson> thanks, I'll look at that
[17:59] <RoAkSoAx> cjwatson: function starting in line line 937
[18:17] <pitti> apw: right, please don't use the udd branch for udev
[18:17]  * pitti waves good night
[18:23] <RobOakes> Howdy, is this a good place to ask package questions or is there a more appropriate channel for that?
[18:49] <maxb> RobOakes: It's a good place for questions about packages in Ubuntu itself, especially packages in main. For universe packages, #ubuntu-motu perhaps, though I don't think people will mind asking here. For non-Ubuntu packaging, e.g. PPAs, #ubuntu-packaging.
[18:53] <RobOakes> Okay, thanks.
[19:06] <RobOakes> I'm a complete noob to packaging, but am trying to configure a daily build. Does anyone know what is meant by "source field" in respect to a debian package build?
[19:07] <m4n1sh> RobOakes: where did you encounter that? Please tell the exact place
[19:09] <RobOakes> During a build of a daily LyX package I'm trying to create (using a recipe).  My build fails because of this error error: "first block lacks a source build."
[19:09] <RobOakes> Here is the build log: https://launchpadlibrarian.net/74251271/buildlog.txt.gz
[19:11] <RobOakes> Ugh. Nevermind. I misspelled the first line "Source"
[19:22] <lamont> slangasek: sorry - what was the question?
[19:40] <lamont> slangasek: util-linux /sys thing - no, I haven't looked at that bug yet
[19:40] <lamont> slangasek: otoh, I'm also pretty sure I didn't do the merge for oneiric
[20:26] <broder> hmm...have sync runs not happened recently, or do i need to start harassing the AAs to run backport-helper when they run sync-helper?
[20:40] <micahg> broder: first one in about a week I think was today
[21:24] <cjwatson> broder: I got a bit put off by the size of the backports queue today, but I will do it today/tomorrow
[21:24] <broder> cjwatson: no worries - just wanted to make sure it hadn't been forgotten about
[22:09] <slangasek> lamont: no, I did the merge for oneiric... there was no mention of this bug in the BTS, and we were trying to work out if it's even an intended behavior change
[22:10] <lamont> oh.  nfc
[22:10] <lamont> what specifically is the behavior?
[22:10] <slangasek> lamont: it seems that for some reason, /sys is no longer written to mtab
[22:13] <slangasek> lamont: generalizing, it seems to be any filesystem with 'none' as a mount source
[22:19] <broder> that...seems like a terrible idea
[22:20] <lamont> that is likely intended behavior
[22:21] <lamont> might be related to the push to ln -sf /proc/mounts /etc/mtab
[22:21] <lamont> dunno
[22:21] <lamont> so after I accidentally manage to get uxterm into anthy input mode, how the *&%)*&%)* do I turn that off?
[22:40] <hallyn> cjwatson: if you're around, can you take a look at bug 803159 (and tell me if there is a reason the fix shouldn't be SRUd)?
[22:54] <hallyn> how many times am i going to hose a vm by forgetting to set bridge_ports on the bridge
[22:57] <cjwatson> hallyn: dup of bug 802985; I explained the problem there
[22:57] <hallyn> cjwatson: ok, thanks - i looked through the buglist but couldn't find that one...
[22:57] <cjwatson> I agree it's a serious problem but the fix is ... not as trivial as it looks
[22:57] <cjwatson> it was the most recent bug filed on eglibc
[22:58]  * cjwatson fiddles bug status
[22:58] <hallyn> cjwatson: I see
[22:59] <hallyn> (just read your explanation of why sru isn't particularly helpful :)
[22:59] <cjwatson> necessary but not sufficient
[22:59] <hallyn> any suggestion for best workaround?
[22:59] <cjwatson> uname LD_PRELOAD
[23:00] <cjwatson> lie about utsname.release and pretend it's 3.0.0 rather than 3.0
[23:00] <cjwatson> not a one-liner but shouldn't be too hard
[23:00] <hallyn> cjwatson: assuming it's mostly scripts, would it be easier to just have debootstrap, early on, bind
[23:00] <hallyn> ok,
[23:01] <cjwatson> debootstrap ought to be fixed, but it will be fairly involved
[23:01] <hallyn> to do LD_PRELOAD we'll have to ship and build the .so though right?
[23:02] <slangasek> wouldn't a dpkg-divert of /bin/uname be simpler yet (wrapping it with a shell script)?
[23:03] <cjwatson> hallyn: no, I mean just set that environment variable when running debootstrap
[23:03] <cjwatson> oh, but it will probably interact messily with chrooting
[23:03] <hallyn> slangasek: that sounds good...
[23:03] <cjwatson> slangasek: inserting such a dpkg-divert into debootstrap would be fiddly too
[23:03] <cjwatson> there really isn't a good straightforward workaround for this
[23:03] <slangasek> yes, but doesn't require writing a custom .so
[23:03] <cjwatson> sure
[23:04] <hallyn> cjwatson: but you can't LD_PRELOAD a script, so it's arch-dependent, that's where I"m not sure how we woudl handle it
[23:04] <cjwatson> hallyn: I'm absolutely not suggesting shipping such a workaround
[23:04] <hallyn> writing th e.so, probably easy, but
[23:04] <hallyn> oh
[23:04] <cjwatson> we shouldn't ship something that isn't a fix, for this
[23:04] <hallyn> haha, ok.  that's just to get us limping along in the meantime.  makes sense
[23:07] <cjwatson> it's strictly more difficult than multiple components (which we've done in debootstrap) because you have to deal with the same package being in both lucid and lucid-updates at different versions, and only using the newer one
[23:07] <cjwatson> in shell
[23:08] <hallyn> but someone's working on it?
[23:08] <cjwatson> well, if it's in the pkgdetails interface then it's in perl (normally) or C (in d-i)
[23:08] <cjwatson> hallyn: not yet
[23:08] <cjwatson> but I probably will