[05:11] Good morning [08:00] stgraber: you have plans to release a new pastebinit for precise === jussio1 is now known as jussi [08:38] good morning [08:46] hey dholbach, how are you? [08:48] morning folks [08:55] hey pitti - doing great - how about you? [08:55] dholbach: I'm quite fine, hoping that the jetlag won't be too bad [08:57] yeah, same here :) [09:41] 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] 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] 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] htorque_: put them into /etc/udev/rules.d/, to avoid overwriting them [10:47] pitti: and the keymap file? [10:47] 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] 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] htorque_: formally it's OT here, but I don't mind; you can ask in #udev [10:49] ok, thanks again! :-) [10:51] pitti: your work on the new apport interface looks nice :) [10:51] ev: we should talk [10:52] lifeless: sure thing [10:52] when works for you [10:52] ev: not now, ETIRED, but soon. About crash db stuff. [10:52] lifeless: sure, I figured as much. [10:52] just pop something in the calendar and I'll find the time :) [10:52] ev: I have shiny new library and open sourced analysis console, all in the right space. [10:52] oooh yay [10:52] ev: okies [10:53] wonderful [10:53] ev: lp:python-oops-tools is the analysis console - a fairly stock django app at the moment [10:53] 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] lifeless: great stuff! Digging in now [11:01] some scaling work probably needed to hit 'bigdata' scales, but... [11:01] we have 27M oopses in there today and its ok [11:01] the disk store can be directly mapreduced if we put it on an hdfs volume [11:01] so its actually a reasonable starting point [11:33] jelmer: are you on top of this bzr/armel build failure? [11:35] cjwatson: I wasn't, looking into it now. Thanks for pointing it out. [11:41] jelmer: ta [11:56] ScottK: ping === MacSlow is now known as MacSlow|lunch === dpm is now known as dpm-lunch === MacSlow|lunch is now known as MacSlow [13:00] hi [13:01] is it the good place to ask question about pbuilder issues ? [13:01] I can't create a pbuilder for Ubuntu > Jaunty [13:01] (for ARM) [13:01] I tried to use the ubuntu-ports repository, but the chroot fails [13:02] http://paste.davromaniak.eu/?show=21 <== here is the log of the pbuilder creation [13:02] http://paste.davromaniak.eu/?show=23 <== and here is the strace for the chroot command that fails [13:03] http://paste.davromaniak.eu/?show=24 <== I tried to chroot only /bin/bash [13:12] 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] davromaniak: er, but your pbuilder log says natty. please explain [13:13] davromaniak: I suspect that you are trying to build this on an architecture which does not support executing ARM binaries? [13:15] cjwatson: so I tried to compile packages for Ubuntu ARM [13:15] it only works when trying to create a pbuilder for Ubuntu Jaunty (with the old-releases repo) [13:15] but when I try to create a pbuilder for a newer version than Jaunty (Natty for example), it's not working [13:16] davromaniak: what is the host architecture? [13:16] and the worst, is the machine which runs the pbuilder is an armel machine [13:17] davromaniak: does /var/cache/pbuilder/build/3518/debootstrap/debootstrap.log exist? [13:17] by the way, it's not an Ubuntu machine, because I only have 1 armel server, which runs under Debian Squeeze [13:17] yes, this file exists [13:17] please pastebin it [13:17] PS if you're on an armel host then why are you explicitly saying --arch armel? [13:17] oh - is it ARMv7 capable? [13:18] Ubuntu armel will not run on pre-ARMv7 systems [13:18] jaunty and karmic supported ARMv5t/ARMv6, but that support was dropped in lucid, sorry [13:19] http://paste.davromaniak.eu/index.php?show=25 <== here is the log [13:19] https://wiki.ubuntu.com/Mobile/ARMv7AndThumb [13:19] Linux arthur 2.6.32-5-kirkwood #1 Wed Jan 12 15:27:07 UTC 2011 armv5tel GNU/Linux [13:19] so the version for the arm arch which is not supported [13:19] yep, sorry, not supported by Ubuntu any more [13:20] ok [13:20] so I will try to use qemu and rootstock to create a virtual machine for my builds [13:56] kirkland, awake? [14:02] Laibsch: no plans, though it probably would be a good idea [14:02] smoser: yo [14:02] smoser: here now [14:02] kirkland, when you do get in, look at http://paste.ubuntu.com/730977/ [14:04] smoser: so your small dir isn't getting used? [14:04] thats what it appears to me, yeah. [14:04] i would have expected most of that upgrade to be < 40M debs [14:06] smoser: agreed [14:06] smoser: i was suspect of lifeless's instructions to stack those up, more than one [14:07] "stack those up, more than one" ? [14:07] smoser: two different cachedir lines [14:07] smoser: in the squid.conf [14:07] smoser: i wonder if it would make a difference to swap their order [14:07] smoser: put "big" first [14:09] i can try that, real quick. [14:22] cyphermox: are you intending to deal with the usb-modeswitch merge today? It's causing ISO build failures across the board === d1b is now known as db === db is now known as Guest74077 === Guest74077 is now known as d1b === yofel_ is now known as yofel === blaze` is now known as blaze [15:13] 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? === dpm-lunch is now known as dpm === dholbach_ is now known as dholbach === Quintasan_ is now known as Quintasan [15:48] kirkland, ok. so back from the above. [15:49] i restarted with order reversed and it seems to have no affect. [15:49] my "big" grows even for small dowwnloads. [15:50] http://paste.ubuntu.com/731053/ [15:50] lifeless, around ? maybe you can shed light. [16:34] mok0: pong [16:37] pitti, Hi :) [16:47] seb128, what version of gtk+ will we ship in 12.04? [16:49] seb128, in case you missed my question, do you know which version of gtk+ will ship in 12.04? [16:50] cnd_, hey, depends of you [16:50] hmm/ [16:50] ? [16:51] cnd_, we were planning to go for 3.4 but that got blocked on getting the gesture story sorted [16:51] ahh [16:51] cnd_, so 3.2 or 3.4, depending of how much conflict we will get [16:52] ok [16:53] kirkland, or lifeless if you see this, i opened bug 887186 against orchestra with details on squid issue. [16:53] Launchpad bug 887186 in orchestra (Ubuntu) "squid proxy big and small buckets not functioning correctly" [Undecided,New] https://launchpad.net/bugs/887186 [16:54] 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] 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] 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] bug 618399 [16:58] Launchpad bug 618399 in Launchpad itself "DistroSeries:+nominations timeouts" [Critical,Triaged] https://launchpad.net/bugs/618399 === bregma is now known as bregma|lunch [17:04] 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] 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] 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] smoser: it is showing up on my merge list and I don't want to step on the server team's toes [17:10] pitti: howdy!! are you free by any chance? [17:11] 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] cjwatson, nnnng, could they have made it more confusing [17:11] lool,geser: oh, I had a fuse merge in progress already [17:11] I'll get round to it this week [17:12] lool: (also, I'm TIL on merges.ubuntu.com) [17:12] 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] jdstrand, my toes will not be hurt if you did it. [17:12] heh [17:13] so we just need to sync to debian. [17:13] i can do that. i only did it before as it was somethign that was really behind debian. [17:13] jdstrand, bug # ? [17:13] 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] s/been managing/last touched/ [17:14] smoser: no bug number. was looking at https://merges.ubuntu.com/main.html [17:14] but thats fine. [17:14] oh, i thought there was a security bug that made you look [17:14] 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] pitti: could you please reject redhat-cluster from oneiric's -proposed? [17:15] so my teeny change to the oneiric packaging is no longer needed in future merges [17:16] 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] slangasek, yeah i got "reeducated" :) [17:16] ok :) [17:18] 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] :) [17:19] I'll take your word for it; at the very least I suppose it was in the Cygnus build system before it became autoconf === bregma|lunch is now known as bregma [17:38] cjwatson: TIL? [17:38] 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] cjwatson: Ah right, I should have pinged you too, I pinged the last merger because there were a lot of Ubuntu changes [17:40] cjwatson: Oh actually you did, I searched for merge instead of ubuntu in the changelog, and hit geser instead of you [17:41] we need a single consistent rule (hence "last Ubuntu uploader"), otherwise you get duplicate work [17:41] obviously the last uploader is entitled to pass it on if they want [17:45] cjwatson: Makes sense [17:48] Which was the first version of Ubuntu to introduce the @+@home subvolume layout for btrfs? (Info for wiki section) [17:48] mewerner_arand: 11.04 [17:49] lool: btw, you're listed as TIL on mawk and ca-certificates ;) https://merges.ubuntu.com/main.html [17:49] Ok, good, I'm doing a section detailing this layout, and why one should avoid set-default in ubuntu, amongst other things.. [17:49] lool: if you don't want them, let us know :) [17:52] stgraber: if you make a new upstream release, please do so early enough that it can go into Debian first. [17:54] mterry, are you around ? [17:54] smoser, heyo [17:55] 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] debian/control: Depend on adduser [17:56] http://bazaar.launchpad.net/~ubuntu-branches/ubuntu/precise/rsyslog/precise/view/head:/debian/control#L17 [17:56] it doesn't look to me that that came from debian [17:56] and i'm just trying to figure out if it is necessary [17:56] 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] smoser, looking. I believe ucf is used to handle merging debian conf files? [17:58] well, sort of. http://bazaar.launchpad.net/~ubuntu-branches/ubuntu/precise/rsyslog/precise/revision/17#debian/control [17:58] i suspect that you just inadvertantly copied another depends line from debian in the merge [17:58] (you're human, thats ok, i just wanted to see if you did it on purpose and knew why) [17:59] smoser, no, I remember the ucf bit was intentional [17:59] smoser, trying to remember why (I mean, ucf is clearly used in the package, just not sure why the depends was separate) [18:02] mterry, well, a grep shows it only used in rsyslog-mysql and rsyslog-postgresql pre and post. [18:02] 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] though, we no longer support any Ubuntu that has such an ancient ucf [18:03] ok. so i think we can drop it. [18:03] smoser, I just did an apt-get and I have it in rsyslog.postinst, postrm [18:03] smoser, on precise. What version of the source are you looking at? [18:03] hm.. [18:05] mterry, i was grepping in debian sourc.e [18:05] thank sfor your input. i'll poke aroudn a bit more. [18:07] smoser, ok! thanks for looking at rsyslog, it's kind of a bear [18:07] Hello, when was the last sync from Debian testing to precise ? [18:07] cjwatson: ok, I pushed my yelp update to the desktop branch [18:07] 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] lool: ah, cool :) [18:08] 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] 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] jbicha: thanks, I'll sort mine out this evening or tomorrow then [18:14] AnAnt: this moring [18:15] *morning [18:15] is there a reason that xcb-util-renderutil is not sync'ed from Debian testing ? [18:16] AnAnt: seems probable that no one got to it during UDS [18:16] oh, no, cjwatson says otherwise :) [18:17] AnAnt: new sources are handled differently [18:18] ok [18:18] mterry, yeah, it should be there. thanks. [18:22] cjwatson: so with libfl-dev in, pam can now be cross-built sensibly, yay :) [18:23] www.openprinting.org is back up again, so printer driver auto-download is available again now (tested with Oneiric). [18:30] I have another question regarding swt-gtk & xcb-util/xcb-util-renderutil) [18:32] 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] 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] does being a MOTU include the priv to accept nominations for relase (driver-priv)? [18:33] nominations for packages in universe, of course [18:33] 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] or just wait until Ubuntu decides sync xcb-util-renderutil (and wether it will add it to main or not) ? [18:36] Laibsch: yes, you can nominate all packages that you are allowed to upload [18:37] debfx: OK. Thx [18:37] you can accept nominations when you're an uploader, you can nominate if you're in bug control [18:45] 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] lool: "merged upstream" - inaccurate [18:45] I don't recognize Thomas Dickey's work as upstream of us [18:46] because I'm unwilling to work with an upstream who throws tarballs over the wall as a development methodology [18:46] especially tarballs that are built using his personal version of autoconf [18:49] lool: so as the "upstream" status of mawk is still in limbo, I'm currently not actively merging patches :/ === dendro-afk is now known as dendrobates [19:05] slangasek: hooray [19:07] 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] 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] cjwatson: but will it be in main ? [19:08] I was still typing :) [19:08] ah, ok [19:09] * AnAnt waits ... [19:09] !regression-alert facter Bug #732953 [19:09] 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] Launchpad bug 732953 in facter (Ubuntu Precise) "can_connect function inside ec2.rb always return false" [High,Fix released] https://launchpad.net/bugs/732953 [19:09] adam_g: I am only a bot, please don't think I'm intelligent :) [19:09] !regression-alert [19:09] cjwatson, jdong, pitti, skaet, ScottK, kees, Daviey, pgraner: reporting regression in a stable release update; investigate severity, start an incident report, perhaps have the package blacklisted from the archive [19:09] adam_g: yep, saw that this morning - are you working on a fix? [19:09] ^ i've pushed 3 branches to to fix this, but need sponsorship [19:09] cjwatson: well, syncing swt-gtk would revert that sync [19:09] cjwatson: well, syncing swt-gtk would revert that delta [19:10] cjwatson: there are 3 branches (lucid, maverick, natty) tagged "732953_fixregress" that fixes the issue. should i file a [19:10] MP? [19:10] that's fine; it will dep-wait until xcb-util-renderutil binaries are published [19:10] adam_g: yes [19:11] can somebody who's in their working hours deal with adam_g's sponsorship request? as a stable regression it's urgent [19:11] SpamapS: ping? ^ [19:11] cjwatson: so you'll sync swt-gtk ? [19:13] AnAnt: can't you do it yourself? [19:14] cjwatson: swt-gtk is in main [19:14] cjwatson: I can file a syncrequest if needed [19:14] 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] ok [19:15] AnAnt: I assume you're checking with the last uploaders to avoid duplicate work, when looking at merges in main? [19:16] 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] smoser: is your small full ? [19:16] lool: he considers RCS state-of-the-art [19:17] :) [19:17] slangasek: state-of-the-art,v please [19:17] hah! [19:17] cjwatson: autodeb/autopkgtest -- cool; so these should be kept I guess [19:17] cjwatson: I don't understand your question [19:17] slangasek: ^ mind merging them in Debian? essentially you can take the whole Ubuntu diff now [19:17] (just uploaded mawk to Ubuntu now) [19:18] lifeless, no. [19:18] $ sudo sh -c 'du -ks /var/spool/squid/small'; grep cache_dir /etc/squid/*.conf [19:18] 16456 /var/spool/squid/small [19:18] cache_dir aufs /var/spool/squid/big 40000 16 256 [19:18] cache_dir aufs /var/spool/squid/small 40000 16 256 max-size=40M [19:18] 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] lool: a bug report and split-out patch would help, fwiw :) [19:18] 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] lool: otherwise it goes into my overflowing bucket of things-to-merge-from-Ubuntu-when-I-get-to-it [19:19] 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] AnAnt: it's fine to deal with other people's merges, you just have to ask them first [19:19] (usually fine, anyway) [19:19] cjwatson: I didn't know about that rule, but I did talk to doko [19:20] 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] 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] AnAnt: it's been on the top of every merges.ubuntu.com index for six years [19:20] (at least) [19:21] AnAnt: ok, you know now :-) [19:21] cjwatson: I never go to merges.ubuntu.com [19:21] it's also on https://wiki.ubuntu.com/UbuntuDevelopment/PackageArchive#Syncing_and_Merging (although less forcefully), and probably elsewhere [19:21] cjwatson: I just check the Ubuntu status of packages that I maintain (or care for) on Debian [19:22] the rule is there because often multiple people care about something [19:22] cjwatson: http://irclogs.ubuntu.com/2011/10/18/%23ubuntu-java.html [19:22] and it's good to have a single rule that's easy to interpret [19:23] 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] bzr has an option to do it [19:24] I occasionally forget to use that option :/ [19:24] slangasek: Hmm the Debian bug actually mentions a commit to a collab-maint git repo [19:24] http://anonscm.debian.org/gitweb/?p=collab-maint/mawk.git;a=commitdiff;h=e2e6d7ad [19:24] with a different fix from the one in Ubuntu [19:25] lool: yep, set up without the consent of the maintainer [19:25] micahg: what's that for ? [19:25] AnAnt: getting the Debian changelogs since the last merge in the .changes file so they show up on the -changes ML [19:25] micahg: I thought that bzr-builddeb was meant to set -v back to the last tagged version? [19:25] -v followed by the last Ubuntu version [19:25] slangasek: I'm confused, there's both a collab-maint git repo and a bzr branch you just added? [19:26] 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] ajmitch: if that's the case, that would explain why it's broke with UDD merges :) [19:26] micahg: does syncpackage do that ? [19:27] lool: the good news is, I can delete the collab-maint git repo to eliminate the confusion [19:27] micahg: better to check with someone who knows for sure :) [19:27] slangasek: did you save the patches in there that weren't uploaded? [19:27] lool: no? [19:27] slangasek: the automated testing patches are already forwarded in Debian #351820 [19:27] Debian bug 351820 in mawk "automated testing - patch to wire in upstream test suite" [Wishlist,Open] http://bugs.debian.org/351820 [19:27] the collab-maint repo is not mine [19:27] lool: ah, ok [19:28] micahg: running into something like bug 876888 ? [19:28] Launchpad bug 876888 in bzr-builddeb "bzr bd -S --package-merge on e2fsprogs 1.42~WIP-2011-10-09-1ubuntu1 generates a .changes file recording the birth of the universe" [Undecided,Fix committed] https://launchpad.net/bugs/876888 [19:28] 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:28] Debian bug 391051 in mawk "mawk: buffer overflow in collect_RE from overlong regexp" [Normal,Open] http://bugs.debian.org/391051 [19:29] lool: ok then :) [19:29] ajmitch: not me, I usually don't use UDD, but have seen plenty of merges from Debian w/out it [19:31] 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] 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] micahg: I use --no-lp usually [19:40] AnAnt: why? [19:40] --no-lp is deprecated and is only for cases where nothing else works [19:40] please don't use it frivolously [19:40] micahg: I sync a package that has just been accepted into Debian [19:41] micahg: when I sync a package that has just been accepted into Debian [19:41] AnAnt: ideally, this cycle, that should wait until it hits testing [19:41] it's rare that there's that much of a rush [19:41] by which time syncpackage will work fine with LP [19:42] micahg: ah, that's right for precise, but I was generally speaking [19:42] 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] 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] and I save the Debian upload ack in my mailbox until I've synced it into Ubuntu [19:43] this works well for me [19:43] right, also if it's rejected by the ftpmasters for one reason or another, there will be problem with bzr [19:43] you can end up with the same version of the package having different contents [19:49] 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] lool: I have no intention of using the collab-maint git repo for anything [19:49] or of merging the "new upstream" at all until Thomas becomes a responsible upstream, which he currently isn't [19:50] 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] @pilot in === udevbot_ changed the topic of #ubuntu-devel to: Precise open for uploads | Ubuntu 11.10 Released! | Development of Ubuntu (not support, not app development) | build failures -> http://bit.ly/or6CHJ | #ubuntu for support and general discussion for hardy -> oneiric | #ubuntu-app-devel for application development on Ubuntu | http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: none, bryceh === dendrobates is now known as dendro-afk === micahg changed the topic of #ubuntu-devel to: Precise open for uploads | Ubuntu 11.10 Released! | Development of Ubuntu (not support, not app development) | build failures -> http://bit.ly/or6CHJ | #ubuntu for support and general discussion for hardy -> oneiric | #ubuntu-app-devel for application development on Ubuntu | http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: bryceh [19:54] 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] having an upstream would be fine, but not one who's going to work like this === ppetraki_ is now known as ppetraki [20:02] slangasek: Ok; thanks for sharing the history [20:02] or story rather [20:05] what does "over-the-wall" mean in this context? [20:09] bjsnider: no public VCS, only monolithic tarball drops that intermix a large number of changes [20:10] he's committing all of the changes himself? [20:10] certainly, as he's the only one who has access to his personal directory where he maintains it :) [20:11] but the issue is not "who commits", the issue is reviewability (and auditability) [20:12] slangasek: /c [20:12] Ups [20:12] slangasek: forwarded email to you [20:12] ok === Amaranth_ is now known as Amaranth [20:13] /c pronounced in Finnish sounds like the word for arse (“perse”). [20:13] adam_g: do you still need somebody to look at your SRU? [20:13] doesn't sound very FOSS to me [20:15] it's not non-free to have a private repository; it's just not good modern practice [20:16] SpamapS: yes please [20:17] certainly gives one pause to keep something like that in main and depended on by lsb-core :-P [20:17] fortunately, 'diff' [20:18] SpamapS: what, mawk? the mawk in main isn't maintained that way at all, that's the point ;) [20:20] adam_g: whats the status of the bug in Oneiric? [20:20] slangasek: oh cool :) [20:21] adam_g: seems like the regression itself should be reported and tracked as a new bug [20:21] SpamapS: it does not affect oneiric. [20:21] SpamapS: i can certainly do that. [20:21] SpamapS: I thought that's what the bug linked to earlier was [20:22] oh, it's not what adam_g linked to. Try bug 885998 [20:22] Launchpad bug 885998 in facter (Ubuntu) "facter upgrade crashes puppet" [Critical,Confirmed] https://launchpad.net/bugs/885998 [20:22] oh I missed that one === allison_ is now known as wendar [20:23] adam_g: so, first point of feedback would probably be to change the bug reference to 885998 [20:23] SpamapS: doing that now [20:27] adam_g: let me know when you've pushed, will pull and sponsor w/ the updated bug reference. [20:28] SpamapS: done [20:28] kirkland: wants (top left corner thing) [20:28] kirkland: wants wants wants! === Amaranth_ is now known as Amaranth [20:55] adam_g: ok, sponsoring now [20:57] SpamapS: thank you [21:08] hrm, we really need to fix sponsor-patch to work with UDD+SRU [21:09] SpamapS: that's not really sponsor-patch's problem, is it? [21:11] tumbleweed: no, UDD should probably redirect lp:ubuntu/lucid/$package to the right place.. [21:11] tumbleweed: but since that seems to be eluding the UDD masters.. I wonder if sponsor-patch couldn't "figure it out" [21:12] SpamapS: most of the time lucid-proposed/$package doesn't exist [21:12] SpamapS: right place is relative [21:13] micahg: indeed, that is the problem in a nut shell. [21:26] lifeless: okay, i found it [21:26] lifeless: it only works with u3d though, not u2d which i'm running for aforementioned battery reasons [21:28] kirkland: ah :( [21:34] lifeless: if you're on 3d, it's easy though === dendro-afk is now known as dendrobates [22:26] 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] (the conflicts are rather broad, unfortunately) [22:32] kirkland: cool... how [22:32] lifeless: ccsm [22:32] lifeless: search for 'unity' [22:32] lifeless: top option, "reveal mode" [22:32] lifeless: set to 'top left' [22:37] 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] yeah, that last one is the bit that gives the nasty merge [22:39] 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] hmm [22:39] 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] yeah, especially considering the file had a different name when this was originally applied, I'm struggling with bzr [22:43] in extremis I guess I could take the conflicted file plus {BASE,THIS,OTHER} and try to progress it [22:43] although collaborative merge resolution is ... hard [22:44] I think I'm starting to understand how it fits together [22:44] I might ask for review when done :) [22:45] * cjwatson nods [22:46] 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] hmm, that's an excellent question [22:48] I fear I screwed up the merge in r355 slightly [22:49] cjwatson: so the bits from 217 should be put back? [22:49] ... so how did keyboard detection work last time I observed it working then? [22:49] (the capb stuff) [22:49] oh, hah [22:49] $ detect_keyboard= [22:49]