[05:11] <pitti> Good morning
[08:00] <Laibsch> stgraber: you have plans to release a new pastebinit for precise
[08:38] <dholbach> good morning
[08:46] <pitti> hey dholbach, how are you?
[08:48] <jml> morning folks
[08:55] <dholbach> hey pitti - doing great - how about you?
[08:55] <pitti> dholbach: I'm quite fine, hoping that the jetlag won't be too bad
[08:57] <dholbach> yeah, same here :)
[09:41] <Laibsch> I'm requesting a mentor for a simple package that I intend to create (upstream and in Debian).  The purpose is to carve out some volatile data that is currently hard-coded in a bunch of packages and thus necessitates a bunch of SRU (which don't always happen).
[09:42] <Laibsch> I have packaging experience, but I'm not really a programmer.  I could use somebody to help me with some design decisions.  Overall the package is VERY simple, a small collection of flat-file databases.
[10:45] <htorque_> pitti: hello! i don't know where to ask, but i know that you know the answer: where should we place custom udev rules and keymap files? is there a special place for those or is it okay to just put them in /lib/udev/..?
[10:46] <pitti> htorque_: put them into /etc/udev/rules.d/, to avoid overwriting them
[10:47] <htorque_> pitti: and the keymap file?
[10:47] <pitti> htorque_: I recently added a patch to udev to support /etc/udev/keymaps/, but that might not be in oneiric yet; but for a new keymap file you can just use /lib/udev/keymaps/
[10:49] <htorque_> pitti: ok, thanks a bunch! btw. was it ok to ask that question here? it feels wrong, but you don't get support on things like this in #ubuntu(+1).
[10:49] <pitti> htorque_: formally it's OT here, but I don't mind; you can ask in #udev
[10:49] <htorque_> ok, thanks again! :-)
[10:51] <Chipzz> pitti: your work on the new apport interface looks nice :)
[10:51] <lifeless> ev: we should talk
[10:52] <ev> lifeless: sure thing
[10:52] <ev> when works for you
[10:52] <lifeless> ev: not now, ETIRED, but soon. About crash db stuff.
[10:52] <ev> lifeless: sure, I figured as much.
[10:52] <ev> just pop something in the calendar and I'll find the time :)
[10:52] <lifeless> ev: I have shiny new library and open sourced analysis console, all in the right space.
[10:52] <ev> oooh yay
[10:52] <lifeless> ev: okies
[10:53] <ev> wonderful
[10:53] <lifeless> ev: lp:python-oops-tools is the analysis console - a fairly stock django app at the moment
[10:53] <lifeless> ev: you can probably follow your nose from there to find the rest of the treasure (including e.g. amqp transmission of error reports - so doing a job queue is simples)
[10:58] <ev> lifeless: great stuff! Digging in now
[11:01] <lifeless> some scaling work probably needed to hit 'bigdata' scales, but...
[11:01] <lifeless> we have 27M oopses in there today and its ok
[11:01] <lifeless> the disk store can be directly mapreduced if we put it on an hdfs volume
[11:01] <lifeless> so its actually a reasonable starting point
[11:33] <cjwatson> jelmer: are you on top of this bzr/armel build failure?
[11:35] <jelmer> cjwatson: I wasn't, looking into it now. Thanks for pointing it out.
[11:41] <cjwatson> jelmer: ta
[11:56] <mok0> ScottK: ping
[13:00] <davromaniak> hi
[13:01] <davromaniak> is it the good place to ask question about pbuilder issues ?
[13:01] <davromaniak> I can't create a pbuilder for Ubuntu > Jaunty
[13:01] <davromaniak> (for ARM)
[13:01] <davromaniak> I tried to use the ubuntu-ports repository, but the chroot fails
[13:02] <davromaniak> http://paste.davromaniak.eu/?show=21 <== here is the log of the pbuilder creation
[13:02] <davromaniak> http://paste.davromaniak.eu/?show=23 <== and here is the strace for the chroot command that fails
[13:03] <davromaniak> http://paste.davromaniak.eu/?show=24 <== I tried to chroot only /bin/bash
[13:12] <cjwatson> davromaniak: you'll have to use old-releases.ubuntu.com; jaunty reached its end-of-life some time ago and we no longer support it
[13:12] <cjwatson> davromaniak: er, but your pbuilder log says natty.  please explain
[13:13] <cjwatson> davromaniak: I suspect that you are trying to build this on an architecture which does not support executing ARM binaries?
[13:15] <davromaniak> cjwatson: so I tried to compile packages for Ubuntu ARM
[13:15] <davromaniak> it only works when trying to create a pbuilder for Ubuntu Jaunty (with the old-releases repo)
[13:15] <davromaniak> but when I try to create a pbuilder for a newer version than Jaunty (Natty for example), it's not working
[13:16] <cjwatson> davromaniak: what is the host architecture?
[13:16] <davromaniak> and the worst, is the machine which runs the pbuilder is an armel machine
[13:17] <cjwatson> davromaniak: does /var/cache/pbuilder/build/3518/debootstrap/debootstrap.log exist?
[13:17] <davromaniak> by the way, it's not an Ubuntu machine, because I only have 1 armel server, which runs under Debian Squeeze
[13:17] <davromaniak> yes, this file exists
[13:17] <cjwatson> please pastebin it
[13:17] <cjwatson> PS if you're on an armel host then why are you explicitly saying --arch armel?
[13:17] <cjwatson> oh - is it ARMv7 capable?
[13:18] <cjwatson> Ubuntu armel will not run on pre-ARMv7 systems
[13:18] <cjwatson> jaunty and karmic supported ARMv5t/ARMv6, but that support was dropped in lucid, sorry
[13:19] <davromaniak> http://paste.davromaniak.eu/index.php?show=25 <== here is the log
[13:19] <cjwatson> https://wiki.ubuntu.com/Mobile/ARMv7AndThumb
[13:19] <davromaniak> Linux arthur 2.6.32-5-kirkwood #1 Wed Jan 12 15:27:07 UTC 2011 armv5tel GNU/Linux
[13:19] <davromaniak> so the version for the arm arch which is not supported
[13:19] <cjwatson> yep, sorry, not supported by Ubuntu any more
[13:20] <davromaniak> ok
[13:20] <davromaniak> so I will try to use qemu and rootstock to create a virtual machine for my builds
[13:56] <smoser> kirkland, awake?
[14:02] <stgraber> Laibsch: no plans, though it probably would be a good idea
[14:02] <kirkland> smoser: yo
[14:02] <kirkland> smoser: here now
[14:02] <smoser> kirkland, when you do get in, look at http://paste.ubuntu.com/730977/
[14:04] <kirkland> smoser: so your small dir isn't getting used?
[14:04] <smoser> thats what it appears to me, yeah.
[14:04] <smoser> i would have expected most of that upgrade to be < 40M debs
[14:06] <kirkland> smoser: agreed
[14:06] <kirkland> smoser: i was suspect of lifeless's instructions to stack those up, more than one
[14:07] <smoser> "stack those up, more than one" ?
[14:07] <kirkland> smoser: two different cachedir lines
[14:07] <kirkland> smoser: in the squid.conf
[14:07] <kirkland> smoser: i wonder if it would make a difference to swap their order
[14:07] <kirkland> smoser: put "big" first
[14:09] <smoser> i can try that, real quick.
[14:22] <cjwatson> cyphermox: are you intending to deal with the usb-modeswitch merge today?  It's causing ISO build failures across the board
[15:13] <Laibsch> tumbleweed: Is there visibility of classical SRU bugs (ubuntu+1 task closed as fixed, nomination pending for stable release) for Ubuntu Drivers?  Particularly those with patches attached?
[15:48] <smoser> kirkland, ok. so back from the above.
[15:49] <smoser> i restarted with order reversed and it seems to have no affect.
[15:49] <smoser> my "big" grows even for small dowwnloads.
[15:50] <smoser> http://paste.ubuntu.com/731053/
[15:50] <smoser> lifeless, around ? maybe you can shed light.
[16:34] <ScottK> mok0: pong
[16:37] <PaoloRotolo> pitti, Hi :)
[16:47] <cnd_> seb128, what version of gtk+ will we ship in 12.04?
[16:49] <cnd_> seb128, in case you missed my question, do you know which version of gtk+ will ship in 12.04?
[16:50] <seb128> cnd_, hey, depends of you
[16:50] <cnd_> hmm/
[16:50] <cnd_> ?
[16:51] <seb128> cnd_, we were planning to go for 3.4 but that got blocked on getting the gesture story sorted
[16:51] <cnd_> ahh
[16:51] <seb128> cnd_, so 3.2 or 3.4, depending of how much conflict we will get
[16:52] <cnd_> ok
[16:53] <smoser> kirkland, or lifeless if you see this, i opened bug 887186 against orchestra with details on squid issue.
[16:54] <tumbleweed> Laibsch: I'm not on the SRU team. I know there's a page for reviewing those nominations, but I don't know if anyone reviews them regularly. Generally it's best to ping on IRC.
[16:57] <Laibsch> tumbleweed: the problem is that those pages currently (and for quite a while actually) oops in launchpad.  So, many of those patches fall through the cracks and are ignored.  Same problem as in the bad days :-(
[16:57] <Laibsch> I have a lot of personal experience of that.  Having to ping may or may not work for me (I have a lot of experience of it NOT working) but should not be the default process.
[16:58] <Laibsch> bug 618399
[17:04] <lool> geser: Would you be tempted to merge latest fuse?  python-fuse in precise now Depends on fuse instead of fuse-utils, which is what the Debian package now provides (there's a fuse-utils compatibility package in the Debian source as well)
[17:08] <apw> slangasek, in the conversions for the kernel packaging you did for multiarch, you use DEB_HOST_MULTIARCH as part of build destination addresses, that seems wrong given there is also a _BUILD_MULTIARCH thing ?
[17:08] <jdstrand> smoser: hey, so istr you being involved in an rsyslog transition of some sort. was that 4 -> 5.8 or 5.8.1 -> 5.8.6?
[17:09] <jdstrand> smoser: it is showing up on my merge list and I don't want to step on the server team's toes
[17:10] <roaksoax> pitti: howdy!! are you free by any chance?
[17:11] <cjwatson> apw: build/host naming is confusing (inherited from autoconf terminology) - build is the arch you're building on, host is the arch you're building for, so destination paths normally want host
[17:11] <apw> cjwatson, nnnng, could they have made it more confusing
[17:11] <cjwatson> lool,geser: oh, I had a fuse merge in progress already
[17:11] <cjwatson> I'll get round to it this week
[17:12] <cjwatson> lool: (also, I'm TIL on merges.ubuntu.com)
[17:12] <jdstrand> smoser: actually, looking at it, I think I'd prefer your team to handle it. the CVE I fixed is fixed in the version in Debian now, so you can drop that
[17:12] <smoser> jdstrand, my toes will not be hurt if you did it.
[17:12] <jdstrand> heh
[17:13] <smoser> so we just need to sync to debian.
[17:13] <smoser> i can do that. i only did it before as it was somethign that was really behind debian.
[17:13] <smoser> jdstrand, bug # ?
[17:13] <jdstrand> smoser: well, there is a bit of delta that I didn't want to make the call on, since your team has been managing it
[17:13] <smoser> s/been managing/last touched/
[17:14] <jdstrand> smoser: no bug number. was looking at https://merges.ubuntu.com/main.html
[17:14] <smoser> but thats fine.
[17:14] <smoser> oh, i thought there was a security bug that made you look
[17:14] <jdstrand> smoser: no. I fixed the security bug (I last touched it actually) in oneiric. Debian took a newer upstream that has the fix
[17:15] <roaksoax> pitti: could you please reject redhat-cluster from oneiric's -proposed?
[17:15] <jdstrand> so my teeny change to the oneiric packaging is no longer needed in future merges
[17:16] <slangasek> apw: HOST in C speak is "the architecture this code will be hosted on"; rather than BUILD which is "the architecture this code will be built on" - so HOST is almost always correct
[17:16] <apw> slangasek, yeah i got "reeducated" :)
[17:16] <slangasek> ok :)
[17:18] <slangasek> cjwatson: though I'd be hard pressed to put my finger on it in a spec, I'm reasonably certain we can't blame autoconf for the host/build confusion, I think they inherited it from elsewhere ):
[17:18] <slangasek> :)
[17:19] <cjwatson> I'll take your word for it; at the very least I suppose it was in the Cygnus build system before it became autoconf
[17:38] <lool> cjwatson: TIL?
[17:38] <cjwatson> lool: touched it last - the rule that you should ask the person who last uploaded the package about a merge, to avoid duplicate work
[17:39] <lool> cjwatson: Ah right, I should have pinged you too, I pinged the last merger because there were a lot of Ubuntu changes
[17:40] <lool> cjwatson: Oh actually you did, I searched for merge instead of ubuntu in the changelog, and hit geser instead of you
[17:41] <cjwatson> we need a single consistent rule (hence "last Ubuntu uploader"), otherwise you get duplicate work
[17:41] <cjwatson> obviously the last uploader is entitled to pass it on if they want
[17:45] <lool> cjwatson: Makes sense
[17:48] <mewerner_arand> Which was the first version of Ubuntu to introduce the @+@home subvolume layout for btrfs? (Info for wiki section)
[17:48] <cjwatson> mewerner_arand: 11.04
[17:49] <slangasek> lool: btw, you're listed as TIL on mawk and ca-certificates ;) https://merges.ubuntu.com/main.html
[17:49] <mewerner_arand> Ok, good, I'm doing a section detailing this layout, and why one should avoid set-default in ubuntu, amongst other things..
[17:49] <slangasek> lool: if you don't want them, let us know :)
[17:52] <Laibsch> stgraber: if you make a new upstream release, please do so early enough that it can go into Debian first.
[17:54] <smoser> mterry, are you around ?
[17:54] <mterry> smoser, heyo
[17:55] <smoser> i'm looking at rsyslog, and the rsyslog binary package has 'ucf' dependency , which i can only seem to attribute to you, and a comment that says
[17:55] <smoser>   debian/control: Depend on adduser
[17:56] <smoser> http://bazaar.launchpad.net/~ubuntu-branches/ubuntu/precise/rsyslog/precise/view/head:/debian/control#L17
[17:56] <smoser> it doesn't look to me that that came from debian
[17:56] <smoser> and i'm just trying to figure out if it is necessary
[17:56] <cjwatson> jbicha: the ubuntu-desktop yelp branch is out of date (even before my most recent upload, which I just realised needs to go into that branch)
[17:57] <mterry> smoser, looking.  I believe ucf is used to handle merging debian conf files?
[17:58] <smoser> well, sort of. http://bazaar.launchpad.net/~ubuntu-branches/ubuntu/precise/rsyslog/precise/revision/17#debian/control
[17:58] <smoser> i suspect that you just inadvertantly copied another depends line from debian in the merge
[17:58] <smoser> (you're human, thats ok, i just wanted to see if you did it on purpose and knew why)
[17:59] <mterry> smoser, no, I remember the ucf bit was intentional
[17:59] <mterry> smoser, trying to remember why (I mean, ucf is clearly used in the package, just not sure why the depends was separate)
[18:02] <smoser> mterry, well, a grep shows it only used in rsyslog-mysql and rsyslog-postgresql pre and post.
[18:02] <mterry> smoser, yeah, that same revision adds a call to ucf in debian/rsyslog.postinst that uses --three-way (hence the >= 0.8 versioning since that argument was added in that version of ucf)
[18:02] <mterry> though, we no longer support any Ubuntu that has such an ancient ucf
[18:03] <smoser> ok. so i think we can drop it.
[18:03] <mterry> smoser, I just did an apt-get and I have it in rsyslog.postinst, postrm
[18:03] <mterry> smoser, on precise.  What version of the source are you looking at?
[18:03] <smoser> hm..
[18:05] <smoser> mterry, i was grepping in debian sourc.e
[18:05] <smoser> thank sfor your input. i'll poke aroudn a bit more.
[18:07] <mterry> smoser, ok!  thanks for looking at rsyslog, it's kind of a bear
[18:07] <AnAnt> Hello, when was the last sync from Debian testing to precise ?
[18:07] <jbicha> cjwatson: ok, I pushed my yelp update to the desktop branch
[18:07] <lool> slangasek: Yes, I actually did mawk earlier today and just want to reboot with the new binaries (in my PPA) to test them; didn't check ca-certificates yet
[18:07] <slangasek> lool: ah, cool :)
[18:08] <lool> slangasek: I am probably better placed to do ca-certificates, but I don't have time to fix the root causes in the Debian source to address the regressions we faced some time ago
[18:09] <slangasek> lool: would be happy to have mawk back in sync, btw, but haven't gone fishing in the Ubuntu package to see what's needed; looks like there are a pair of changes that would still apply, one of which I'm pretty sure has not been forwarded to Debian at all
[18:14] <cjwatson> jbicha: thanks, I'll sort mine out this evening or tomorrow then
[18:14] <cjwatson> AnAnt: this moring
[18:15] <cjwatson> *morning
[18:15] <AnAnt> is there a reason that xcb-util-renderutil is not sync'ed from Debian testing ?
[18:16] <slangasek> AnAnt: seems probable that no one got to it during UDS
[18:16] <slangasek> oh, no, cjwatson says otherwise :)
[18:17] <slangasek> AnAnt: new sources are handled differently
[18:18] <AnAnt> ok
[18:18] <smoser> mterry, yeah, it should be there. thanks.
[18:22] <slangasek> cjwatson: so with libfl-dev in, pam can now be cross-built sensibly, yay :)
[18:23] <tkamppeter> www.openprinting.org is back up again, so printer driver auto-download is available again now (tested with Oneiric).
[18:30] <AnAnt> I have another question regarding swt-gtk & xcb-util/xcb-util-renderutil)
[18:32] <AnAnt> during oneiric cycle, xcb-util source packages was split into two source packages xcb-util & xcb-util-renderutil, where libxcb-render-util0-dev was provided by xcb-util-renderutil
[18:33] <AnAnt> Hence in oneiric a delta was added to swt-gtk changing Build-Dep from libxcb-render-util0-dev to libxcb-util0-dev (which is provided by xcb-util)
[18:33] <Laibsch> does being a MOTU include the priv to accept nominations for relase (driver-priv)?
[18:33] <Laibsch> nominations for packages in universe, of course
[18:33] <AnAnt> the question is, that I don't know the difference between libxcb-render-util0-dev & libxcb-util0-dev, hence I am not able to decide wether to sync this change back into Debian or not
[18:35] <AnAnt> or just wait until Ubuntu decides  sync xcb-util-renderutil (and wether it will add it to main or not) ?
[18:36] <debfx> Laibsch: yes, you can nominate all packages that you are allowed to upload
[18:37] <Laibsch> debfx: OK.  Thx
[18:37] <micahg> you can accept nominations when you're an uploader, you can nominate if you're in bug control
[18:45] <lool> slangasek: mawk has two pieces remaining, one is the autopkg/autodebtest stuff which seems a bit useless because it's not actually run during build (AFAIU) and the other is a patch for long regexps which has been forwarded to Debian and merged upstream, but not uploaded in Debian yet; if you could take it that'd be nice, you could decide either way for the autopkgtest/autodebtest bits
[18:45]  * lool goes rebooting
[18:45] <slangasek> lool: "merged upstream" - inaccurate
[18:45] <slangasek> I don't recognize Thomas Dickey's work as upstream of us
[18:46] <slangasek> because I'm unwilling to work with an upstream who throws tarballs over the wall as a development methodology
[18:46] <slangasek> especially tarballs that are built using his personal version of autoconf
[18:49] <slangasek> lool: so as the "upstream" status of mawk is still in limbo, I'm currently not actively merging patches :/
[19:05] <cjwatson> slangasek: hooray
[19:07] <cjwatson> lool: we're planning/hoping to start running autopkgtest tests automatically this cycle, I believe (not during build, but that's not the point)
[19:08] <cjwatson> AnAnt: I've synced xcb-util-renderutil into Ubuntu now; I think it was an oversight that it wasn't done in oneiric
[19:08] <AnAnt> cjwatson: but will it be in main ?
[19:08] <cjwatson> I was still typing :)
[19:08] <AnAnt> ah, ok
[19:09]  * AnAnt waits ...
[19:09] <adam_g> !regression-alert facter Bug #732953
[19:09] <cjwatson> AnAnt: I've put the source package in main initially, although it will only stay there if something starts (build-)depending on it, so please go ahead and revert that delta in swt-gtk
[19:09] <adam_g> !regression-alert
[19:09] <cjwatson> adam_g: yep, saw that this morning - are you working on a fix?
[19:09] <adam_g> ^ i've pushed 3 branches to to fix this, but need sponsorship
[19:09] <AnAnt> cjwatson: well, syncing swt-gtk would revert that sync
[19:09] <AnAnt> cjwatson: well, syncing swt-gtk would revert that delta
[19:10] <adam_g> cjwatson: there are 3 branches (lucid, maverick, natty) tagged "732953_fixregress" that fixes the issue. should i file a
[19:10] <adam_g> MP?
[19:10] <cjwatson> that's fine; it will dep-wait until xcb-util-renderutil binaries are published
[19:10] <cjwatson> adam_g: yes
[19:11] <cjwatson> can somebody who's in their working hours deal with adam_g's sponsorship request?  as a stable regression it's urgent
[19:11] <adam_g> SpamapS: ping? ^
[19:11] <AnAnt> cjwatson: so you'll sync swt-gtk ?
[19:13] <cjwatson> AnAnt: can't you do it yourself?
[19:14] <AnAnt> cjwatson: swt-gtk is in main
[19:14] <AnAnt> cjwatson: I can file a syncrequest if needed
[19:14] <cjwatson> AnAnt: oh; please use requestsync then, I don't deal with sync requests over IRC because the audit trail is hard to follow then
[19:14] <AnAnt> ok
[19:15] <cjwatson> AnAnt: I assume you're checking with the last uploaders to avoid duplicate work, when looking at merges in main?
[19:16] <lool> slangasek: I didn't check the actual upstream status, but the Debian bug had been tagged fixed-upstream; I didn't know his maintenance style was problematic   :-/
[19:16] <lifeless> smoser: is your small full ?
[19:16] <slangasek> lool: he considers RCS state-of-the-art
[19:17] <slangasek> :)
[19:17] <cjwatson> slangasek: state-of-the-art,v please
[19:17] <slangasek> hah!
[19:17] <lool> cjwatson: autodeb/autopkgtest -- cool; so these should be kept I guess
[19:17] <AnAnt> cjwatson: I don't understand your question
[19:17] <lool> slangasek: ^ mind merging them in Debian?  essentially you can take the whole Ubuntu diff now
[19:17] <lool> (just uploaded mawk to Ubuntu now)
[19:18] <smoser> lifeless, no.
[19:18] <smoser> $ sudo sh -c 'du -ks /var/spool/squid/small'; grep cache_dir /etc/squid/*.conf
[19:18] <smoser> 16456   /var/spool/squid/small
[19:18] <smoser> cache_dir aufs /var/spool/squid/big 40000 16 256
[19:18] <smoser> cache_dir aufs /var/spool/squid/small 40000 16 256 max-size=40M
[19:18] <cjwatson> AnAnt: are you aware that the standard rule for merges is that you must check with whoever uploaded the package last, to avoid duplicate work?
[19:18]  * lool had fan issues on reboot, probably should call Lenovo tomorrow
[19:18] <slangasek> lool: a bug report and split-out patch would help, fwiw :)
[19:18] <cjwatson> https://merges.ubuntu.com/main.html "If you are not the previous uploader, ask the previous uploader before doing the merge. This prevents two people from doing the same work."
[19:18] <slangasek> lool: otherwise it goes into my overflowing bucket of things-to-merge-from-Ubuntu-when-I-get-to-it
[19:19] <lool> slangasek: there's one for the actual patch, I'll update it with the quilt version now, and report the autodeb/autopkg tests as a separate bug; I thought you had access to some Vcs or something since you had done a Debian upload
[19:19] <cjwatson> AnAnt: it's fine to deal with other people's merges, you just have to ask them first
[19:19] <cjwatson> (usually fine, anyway)
[19:19] <AnAnt> cjwatson: I didn't know about that rule, but I did talk to doko
[19:20] <slangasek> lool: sure, it's in a bzr branch that shares history with the UDD branch, but so do lots of other things that I haven't had time to review myself and merge
[19:20] <slangasek> the value of a bug report is that someone else gets to write the rationale and do the analysis :-)
[19:20]  * AnAnt checking logs
[19:20] <cjwatson> AnAnt: it's been on the top of every merges.ubuntu.com index for six years
[19:20] <cjwatson> (at least)
[19:21] <cjwatson> AnAnt: ok, you know now :-)
[19:21] <AnAnt> cjwatson: I never go to merges.ubuntu.com
[19:21] <cjwatson> it's also on https://wiki.ubuntu.com/UbuntuDevelopment/PackageArchive#Syncing_and_Merging (although less forcefully), and probably elsewhere
[19:21] <AnAnt> cjwatson: I just check the Ubuntu status of packages that I maintain (or care for) on Debian
[19:22] <cjwatson> the rule is there because often multiple people care about something
[19:22] <AnAnt> cjwatson: http://irclogs.ubuntu.com/2011/10/18/%23ubuntu-java.html
[19:22] <cjwatson> and it's good to have a single rule that's easy to interpret
[19:23] <cjwatson> anyway, in this case it should be fine
[19:23]  * micahg wonders what we can do about people not passing -v to dpkg-buildpackage (or bzr not doing it)
[19:24] <slangasek> bzr has an option to do it
[19:24] <slangasek> I occasionally forget to use that option :/
[19:24] <lool> slangasek: Hmm the Debian bug actually mentions a commit to a collab-maint git repo
[19:24] <lool> http://anonscm.debian.org/gitweb/?p=collab-maint/mawk.git;a=commitdiff;h=e2e6d7ad
[19:24] <lool> with a different fix from the one in Ubuntu
[19:25] <slangasek> lool: yep, set up without the consent of the maintainer
[19:25] <AnAnt> micahg: what's that for ?
[19:25] <micahg> AnAnt: getting the Debian changelogs since the last merge in the .changes file so they show up on the -changes ML
[19:25] <ajmitch> micahg: I thought that bzr-builddeb was meant to set -v back to the last tagged version?
[19:25] <micahg> -v followed by the last Ubuntu version
[19:25] <lool> slangasek: I'm confused, there's both a collab-maint git repo and a bzr branch you just added?
[19:26] <m4n1sh> anyone from core-dev can review my merge request? https://code.launchpad.net/~manishsinha/software-properties/fix-887249-handle-404-error/+merge/81488
[19:26] <micahg> ajmitch: if that's the case, that would explain why it's broke with UDD merges :)
[19:26] <AnAnt> micahg: does syncpackage do that ?
[19:27] <slangasek> lool: the good news is, I can delete the collab-maint git repo to eliminate the confusion
[19:27] <ajmitch> micahg: better to check with someone who knows for sure :)
[19:27] <lool> slangasek: did you save the patches in there that weren't uploaded?
[19:27] <slangasek> lool: no?
[19:27] <lool> slangasek: the automated testing patches are already forwarded in Debian #351820
[19:27] <slangasek> the collab-maint repo is not mine
[19:27] <slangasek> lool: ah, ok
[19:28] <ajmitch> micahg: running into something like bug 876888 ?
[19:28] <lool> slangasek: The only Ubuntu patch has been forwarded in Debian #391051 but fixed differently in upstream and in the collab-maint repo; I will use the collab-maint fix because it seems cleaner, and forward that to the bug (which already has a link to the patch in collab-maint)
[19:29] <slangasek> lool: ok then :)
[19:29] <micahg> ajmitch: not me, I usually don't use UDD, but have seen plenty of merges from Debian w/out it
[19:31] <barry> ajmitch: i stopped using --package-merge while that bug was outstanding.  from the bug tasks it looks like it's been sru'd into oneiric, so i'll try it on my next merge.
[19:38] <micahg> AnAnt: syncpackage uses LP to sync a package from Debian to Ubuntu similar to what we used to request from an archive admin w/requestsync (this only works if you have upload rights for the package in question)
[19:39] <AnAnt> micahg: I use --no-lp usually
[19:40] <micahg> AnAnt: why?
[19:40] <cjwatson> --no-lp is deprecated and is only for cases where nothing else works
[19:40] <cjwatson> please don't use it frivolously
[19:40] <AnAnt> micahg: I sync a package that has just been accepted into Debian
[19:41] <AnAnt> micahg: when I sync a package that has just been accepted into Debian
[19:41] <micahg> AnAnt: ideally, this cycle, that should wait until it hits testing
[19:41] <cjwatson> it's rare that there's that much of a rush
[19:41] <micahg> by which time syncpackage will work fine with LP
[19:42] <AnAnt> micahg: ah, that's right for precise, but I was generally speaking
[19:42] <AnAnt> cjwatson: well, usually I am the debian maintainer of that package, so I just do so to avoid forgetting that I need to sync
[19:42] <cjwatson> for my own packages, I generally wait until I've seen that it's built cleanly everywhere in Debian, which is usually enough time for LP to have picked it up
[19:43] <cjwatson> and I save the Debian upload ack in my mailbox until I've synced it into Ubuntu
[19:43] <cjwatson> this works well for me
[19:43] <micahg> right, also if it's rejected by the ftpmasters for one reason or another, there will be problem with bzr
[19:43] <micahg> you can end up with the same version of the package having different contents
[19:49] <lool> slangasek: uploaded + sent to Debian; you'll have good pain merging the new upstream into bzr as there were at least 3 tarballs from upstream merged into the git branch, some of which renaming #defines over the place or changing indentation wholesale
[19:49] <slangasek> lool: I have no intention of using the collab-maint git repo for anything
[19:49] <slangasek> or of merging the "new upstream" at all until Thomas becomes a responsible upstream, which he currently isn't
[19:50] <slangasek> it's on my todo list to raise this issue with him again, and either convince him to do it right or else cut my losses and just maintain the Debian package directly
[19:52] <bryceh> @pilot in
[19:54] <slangasek> lool: if this wasn't clear, Thomas is not the upstream author; when I first adopted mawk, the package was abandonware upstream, which is not ideal but is workable.  Thomas came along and unilaterally declared himself the upstream and started doing over-the-wall tarball releases, which is not ok
[19:54] <slangasek> having an upstream would be fine, but not one who's going to work like this
[20:02] <lool> slangasek: Ok; thanks for sharing the history
[20:02] <lool> or story rather
[20:05] <bjsnider> what does "over-the-wall" mean in this context?
[20:09] <slangasek> bjsnider: no public VCS, only monolithic tarball drops that intermix a large number of changes
[20:10] <bjsnider> he's committing all of the changes himself?
[20:10] <slangasek> certainly, as he's the only one who has access to his personal directory where he maintains it :)
[20:11] <slangasek> but the issue is not "who commits", the issue is reviewability (and auditability)
[20:12] <lool> slangasek: /c
[20:12] <lool> Ups
[20:12] <lool> slangasek: forwarded email to you
[20:12] <slangasek> ok
[20:13] <ion> /c pronounced in Finnish sounds like the word for arse (“perse”).
[20:13] <SpamapS> adam_g: do you still need somebody to look at your SRU?
[20:13] <bjsnider> doesn't sound very FOSS to me
[20:15] <cjwatson> it's not non-free to have a private repository; it's just not good modern practice
[20:16] <adam_g> SpamapS: yes please
[20:17] <SpamapS> certainly gives one pause to keep something like that in main and depended on by lsb-core :-P
[20:17] <lifeless> fortunately, 'diff'
[20:18] <slangasek> SpamapS: what, mawk?  the mawk in main isn't maintained that way at all, that's the point ;)
[20:20] <SpamapS> adam_g: whats the status of the bug in Oneiric?
[20:20] <SpamapS> slangasek: oh cool :)
[20:21] <SpamapS> adam_g: seems like the regression itself should be reported and tracked as a new bug
[20:21] <adam_g> SpamapS: it does not affect oneiric.
[20:21] <adam_g> SpamapS: i can certainly do that.
[20:21] <cjwatson> SpamapS: I thought that's what the bug linked to earlier was
[20:22] <cjwatson> oh, it's not what adam_g linked to.  Try bug 885998
[20:22] <SpamapS> oh I missed that one
[20:23] <SpamapS> adam_g: so, first point of feedback would probably be to change the bug reference to 885998
[20:23] <adam_g> SpamapS: doing that now
[20:27] <SpamapS> adam_g: let me know when you've pushed, will pull and sponsor w/ the updated bug reference.
[20:28] <adam_g> SpamapS: done
[20:28] <lifeless> kirkland: wants (top left corner thing)
[20:28] <lifeless> kirkland: wants wants wants!
[20:55] <SpamapS> adam_g: ok, sponsoring now
[20:57] <adam_g> SpamapS: thank you
[21:08] <SpamapS> hrm, we really need to fix sponsor-patch to work with UDD+SRU
[21:09] <tumbleweed> SpamapS: that's not really sponsor-patch's problem, is it?
[21:11] <SpamapS> tumbleweed: no, UDD should probably redirect lp:ubuntu/lucid/$package to the right place..
[21:11] <SpamapS> tumbleweed: but since that seems to be eluding the UDD masters.. I wonder if sponsor-patch couldn't "figure it out"
[21:12] <tumbleweed> SpamapS: most of the time lucid-proposed/$package doesn't exist
[21:12] <micahg> SpamapS: right place is relative
[21:13] <SpamapS> micahg: indeed, that is the problem in a nut shell.
[21:26] <kirkland> lifeless: okay, i found it
[21:26] <kirkland> lifeless: it only works with u3d though, not u2d which i'm running for aforementioned battery reasons
[21:28] <lifeless> kirkland: ah :(
[21:34] <kirkland> lifeless: if you're on 3d, it's easy though
[22:26] <slangasek> cjwatson: can you offer any guidance regarding the merge of debian/keyboard-configuration.config in console-setup?  I'm walking the history now to understand it, but maybe there are specific pitfalls I should be watching out for?
[22:27] <slangasek> (the conflicts are rather broad, unfortunately)
[22:32] <lifeless> kirkland: cool... how
[22:32] <kirkland> lifeless: ccsm
[22:32] <kirkland> lifeless: search for 'unity'
[22:32] <kirkland> lifeless: top option, "reveal mode"
[22:32] <kirkland> lifeless: set to 'top left'
[22:37] <cjwatson> slangasek: it basically amounts to (1) ubiquity integration (2) improved upgrade handling of various degrees of horribleness (3) handling of some more layout/variant combinations and defaults (4) cdebconf-keystep integration (just make sure to keep the state machine numbers right)
[22:38] <slangasek> yeah, that last one is the bit that gives the nasty merge
[22:39] <cjwatson> I would be inclined to reapply that by hand one case-option at a time, and adjust the following states on the way
[22:39] <slangasek> hmm
[22:39] <cjwatson> it's not desperately hard to keep track of if you do it that way, but bzr is not likely to be able to do a good job
[22:40] <slangasek> yeah, especially considering the file had a different name when this was originally applied, I'm struggling with bzr
[22:43] <cjwatson> in extremis I guess I could take the conflicted file plus {BASE,THIS,OTHER} and try to progress it
[22:43] <cjwatson> although collaborative merge resolution is ... hard
[22:44] <slangasek> I think I'm starting to understand how it fits together
[22:44] <slangasek> I might ask for review when done :)
[22:45]  * cjwatson nods
[22:46] <slangasek> cjwatson: where is $detect_keyboard even supposed to come from?  Way back in rev 217 of debian/config.proto, I see it being set; but the current file doesn't have this
[22:47] <cjwatson> hmm, that's an excellent question
[22:48] <cjwatson> I fear I screwed up the merge in r355 slightly
[22:49] <slangasek> cjwatson: so the bits from 217 should be put back?
[22:49] <cjwatson> ... so how did keyboard detection work last time I observed it working then?
[22:49] <slangasek> (the capb stuff)
[22:49] <cjwatson> oh, hah
[22:49] <cjwatson> $ detect_keyboard=
[22:49] <cjwatson> $ if $detect_keyboard && true; then echo yes; fi
[22:49] <cjwatson> yes
[22:49] <cjwatson> shell semantics can still surprise me after all these years
[22:49]  * slangasek snickers
[22:50] <cjwatson> it's probably broken in the gtk frontend
[22:50] <cjwatson> so yes, those bits should be put back
[22:50] <cjwatson> well spotted
[22:51] <cjwatson> (I know it works in oneiric, at least in d-i, I test it from time to time)
[22:58] <broder> what do i do to get listed on the "People" page on the workitems tracker?
[22:59] <bryceh> broder, would think you should be there automatically; pitti can fix, so chat with him?
[22:59] <broder> ok. i'll try to catch him tonight
[23:00] <broder> i know i never showed up last cycle, and i thought i had work items assigned to me
[23:00]  * cjwatson blinks
[23:00] <cjwatson> $ dpkg-architecture -qDEB_BUILD_ARCH; dpkg-query -W gcc-4.6; gcc ---_this_is_not_a_flag_ -o /dev/null -xc -c /dev/null
[23:00] <cjwatson> armel
[23:00] <cjwatson> gcc-4.6 4.6.2-2ubuntu1
[23:00] <cjwatson> $ dpkg-architecture -qDEB_BUILD_ARCH; dpkg-query -W gcc-4.6; gcc ---_this_is_not_a_flag_ -o /dev/null -xc -c /dev/null
[23:00] <cjwatson> i386
[23:00] <cjwatson> gcc-4.6 4.6.2-2ubuntu1
[23:00] <cjwatson> gcc-4.6.real: error: unrecognized option ‘---_this_is_not_a_flag_’
[23:00] <cjwatson> (yes, gcc on $PATH points to /usr/bin/gcc-4.6 in both cases)
[23:01] <slangasek> gcc-4.6.real?
[23:01] <slangasek> ccache or something?
[23:01] <cjwatson> hardening-wrapper
[23:01] <slangasek> ah
[23:01] <slangasek> in both cases?
[23:02] <cjwatson> no, just i386, and same behaviour after removing it
[23:02] <cjwatson> which is good for i386; it's the armel behaviour I don't understand
[23:02] <cjwatson> oneiric/armel behaves properly; precise/armel is busted
[23:02]  * slangasek nods
[23:05] <cjwatson> these xz binary upload failures are getting irritating; shame there's not much to be done about them except whack-a-mole and wait six months
[23:08] <cjwatson> the Debian perl team has started transitioning at rather a rate of knots
[23:10] <slangasek> phooey
[23:24] <debfx> couldn't pkgbinarymangler add the missing Pre-Depends if xz is used?
[23:24] <cjwatson> I guess that might be a possibility