[00:09] <YokoZar> If I remove a binary package with a new source upload, does that require some archive admin tomfoolery?
[00:10] <YokoZar> (wine1.3 waiting in queue removes ttf-symbol-replacement-wine1.3)
[00:11] <broder> yes. "NBS" is the magic term you're looking for
[00:31] <YokoZar> slangasek: What do you think of architecture-dependent header files in /usr/include?
[00:32]  * YokoZar has now twice encountered -dev packages that have different, incompatible header files on 32/64 bit
[00:41] <slangasek> YokoZar: well, they're certainly incompatible with multiarch.  http://lists.debian.org/debian-policy/2011/03/msg00151.html
[00:43] <YokoZar> slangasek: welp, it turns out gstreamer-plugins-base0.10-dev is one such package
[03:03] <ScottK> sladen: I don't.
[03:03]  * ScottK would prefer it were just fixed and would stay fixed.
[03:05] <sladen> ScottK: wuhhh?
[03:06] <ScottK> sladen: That's a periodic problem that's intermittent.  They fix something, it doesn't time out, they change something else, it happens again.  That's why so many OOP's because it morphs over time.
[03:09] <sladen> ScottK: ah, gotcha, the dup-notdup-dup-notdup-OOPen
[05:36] <didrocks> good morning
=== mdke_ is now known as mdke
[07:00] <dholbach> good morning
[07:01]  * bryceh waves to dholbach
[07:01] <dholbach> hey bryceh
[07:01]  * nigelb waves to bryceh 
[07:09] <zma> hi, I would like to use apt-get build-dep so that it only loads appropriate header files from debÂ-src repositories. How to do it? I can't use build-dep normally because of faulty dependencies in those packages I work with.
=== chrisccoulson_ is now known as chrisccoulson
=== dendro-afk is now known as dendrobates
[08:14] <jamespage> bdrung: 4/29 r-b-d's of asm3 FTBFS with 3.3  - looking now
[08:18] <jamespage> bdrung: tracking under bug 851659
[08:18] <ubottu> Launchpad bug 851659 in asm3 (Ubuntu) "[FFE] Sync asm3 3.3.1-1 (universe) from Debian unstable (main)" [Wishlist,New] https://launchpad.net/bugs/851659
[08:59] <raphink> has nobody blogged in 3 days or is planet ubuntu broken?
[09:15] <jussi> raphink: I think its broken - saw someone say that they had reported it and "it would take a couple of days to fix"
[09:16] <jussi> [10:05:12] <pleia2> ejat: btw, filed a ticket re: planet, it's still broken :\
[09:16] <jussi> [10:05:51] <pleia2> they said they'd look at it "within the next few days"
[09:16] <Laney> :(
[09:18] <bdrung> jamespage: thanks for tracking them.
[09:24] <YokoZar> ScottK: Thanks for the early ack, I was gonna get around to making that bug the FFE tonight :)
[09:36] <jamespage> bdrung: not looking to bad - then I saw eucalyptus-java-common
[09:37] <jamespage> I don't currently have two spare bits of kit to test euca on with a new version of asm3
[09:49] <apw> pitti, the current source for work-items stuff references the milestones.project field which is not in our oneiric.db, any idea of the history ?
[09:55] <apw> pitti, seems to have come in via "merge James Westby's and Chris Johnston's redesign" which has completely changed the interface milestone_list losing its ordering, plus this reliance on a field we do not have
[09:56] <apw> james_w, ^^
[10:42] <jdstrand> cjwatson: gparted 0.8.0-1 added a Depends and 0.8.0-2 reduced that to Recommends on gpart (universe) for 'Add attempt data rescue for lost partitions'. Should this be moved to Suggests or should gpart get a MIR?
[10:42] <cjwatson> I don't know
[10:42] <cjwatson> at this stage I guess reduce to suggests
[10:43] <jdstrand> ok, I'll do it real quick
[10:43] <jdstrand> cjwatson: well, unless you are poking at gparted atm
[10:43] <cjwatson> I'm not
[10:43] <cjwatson> I haven't looked at the code to see how badly it fails without it; presumably not very since it's not Depends
[10:44] <jdstrand> the comment in -2 is 'gpart is not available on all achitectures'
[10:44] <jdstrand> which at least hints that fails gracefully
[10:54] <jdstrand> cjwatson: Device/Attempt Data Rescue...
[10:55] <jdstrand> cjwatson: 'Command gpart was not found
[10:55] <jdstrand> cjwatson: This feature uses gpart. Please install gpart and try again.'
[10:55] <jdstrand> yep, graceful
[11:17] <cjwatson> jdstrand: ok, good
=== dendrobates is now known as dendro-afk
=== Ursinha-afk is now known as Ursinha
=== MacSlow is now known as MacSlow|lunch
[12:22] <hallyn> smoser: slangasek: SpamapS: that bug with networking being considered up before dhcp is done, did that get resolved?
=== doko_ is now known as doko
[12:27] <james_w> apw, yep, it's part of the new schema
[12:28] <apw> james_w, well it seems our DBs are not of the new schema?  is there a migration path
[12:28] <apw> james_w, also though it changes the semanatic of that routine which was intended to return them in due_date order, which returning a {} does not do any more
[12:29] <james_w> apw, where are you getting oneiric.db from?
[12:29] <apw> from ~platform
[12:29] <james_w> running collect will update the schema as always
[12:30] <james_w> right, the up to date databases live on status.ubuntu.com now
[12:54] <slangasek> hallyn: yes
[12:56] <elleuca> pitti, query?
[13:04] <hallyn> slangasek: which package was the bug filed against?  I believe bug 850309 in natty is due to that
[13:05] <ubottu> Launchpad bug 850309 in libvirt (Ubuntu) "libvirt fails to autostart VM attached to a bridged port" [Medium,New] https://launchpad.net/bugs/850309
[13:05] <slangasek> hallyn: ifupdown
[13:05] <hallyn> thanks
[13:05] <apw> slangasek, the fix for the headers ftbs is out on our list for review
[13:07] <slangasek> apw: cheers :)
[13:24] <roadmr> hello!
[13:24] <hallyn> slangasek: something seems to have gone weird with that 0.7~alpha5.1ubuntu4 ifupdown merge.  The 0.7~alpha5.1ubuntu5 one (which wasn't done through a merge request) failed to import, and when I manually try import-dsc, it gives me
[13:24] <hallyn> bzr: ERROR: Unable to find the tag for the previous upstream version, 0.7~alpha5.1ubuntu4, in the branch: upstream-0.7~alpha5.1ubuntu4. Consider importing it via import-dsc or import-upstream.
[13:25] <hallyn> smoser: ^ do you have a debdiff for bug 850226 by chance?
[13:25] <ubottu> Launchpad bug 850226 in ifupdown (Ubuntu) "static-network-up event waits for 'auto' devs without a config stanza" [Medium,Fix released] https://launchpad.net/bugs/850226
[13:26] <Daviey> hallyn: http://launchpadlibrarian.net/79907784/ifupdown_0.7~alpha5.1ubuntu4_0.7~alpha5.1ubuntu5.diff.gz ?
[13:27] <hallyn> Daviey: yeah i can reconstruct from that
[13:27] <hallyn> but not sure how to fix the udd tree :)
[13:28] <hallyn> Daviey: interestingly, when I did pull-lp-source, it didnt download that diff
[13:30] <hallyn> Daviey: so where the heck did you find that?
[13:30] <Daviey> hallyn: on the LP page.
[13:31] <Daviey> hallyn: https://launchpad.net/ubuntu/+source/ifupdown/0.7~alpha5.1ubuntu5 'Avaliable diffs'
[13:31] <hallyn> Daviey: thanks!
[13:32] <Daviey> ofc, LP can spell. i cannot.
[13:34] <slangasek> hallyn: import-dsc may not work on account of this being a native package; there is no "upstream version"
[13:40] <hallyn> slangasek: drat :)  thanks
[13:48] <mterry> dpm, heyo.  I can't seem to log into wp-admin on developer.ubuntu.com now?
[13:49] <dpm> mterry, hey! hm, perhaps something to do with the fix IS did recently regarding the certificate?
[13:50] <dpm> mterry, have you tried http://developer.ubuntu.com? (without https)
[13:51] <mterry> dpm, that tricked it, though the SSO page gave me a warning that the site wasn't recognized by Ubuntu SSO
[13:52] <dpm> mterry, oh, weird, let me add a comment to the RT regarding that
[13:52] <jamespage> bdrung: I think I've done as much testing as I can with libasm3-java 3.3.2;
[13:52] <dpm> but glad you could log in
[14:01] <cjwatson> slangasek: looking at xdeb, I found your change to disregard multiarch-foreign packages.  However nothing seems to actually take care of installing foreign-arch packages when that's required.  Do you know if anyone has a branch that does that?  In the meantime xdeb is sort of broken
[14:01] <cjwatson> because if you try to build say any X library package, it ignores the x11proto-*-dev packages because they're multi-arch: foreign, but doesn't install the host-arch versions either
[14:01] <bdrung> jamespage: thanks
[14:05] <slangasek> cjwatson: hrrmm, I don't think I ran into that issue
[14:05] <slangasek> x11proto-*-dev are arch: all as well
[14:07] <Laney> doko: do you know of a graph showing stats for ftbfs/fixes resulting from your rebuild?
[14:07] <cjwatson> slangasek: huh
[14:08] <cjwatson> slangasek: in that case perhaps I have a different problem; trying to cross-build libx*, it was refusing to notice header files in /usr/include/X11/
[14:08] <doko> Laney, no. rsalveti has one, but only counts the one seen on the production buildds
[14:08] <Laney> yeah I know of a similar one too
[14:08] <Laney> never mind
[14:14] <cr3> skaet: ping, beta freeze question for you: I just noticed that the most recent checkbox package is missing the execute bit on some scripts, is that small enough a change to be acceptable or could it wait until after the freeze?
[14:21] <skaet> cr3,  thanks for flagging.  Let me check on a few things and get back to you.
[14:32] <sconklin> @pilot in
=== udevbot changed the topic of #ubuntu-devel to: Beta 2 Freeze | Archive: Feature/UI Freeze | 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: sconklin
=== dholbach_ is now known as dholbach
=== MacSlow|lunch is now known as MacSlow
[14:47] <cjwatson> mvo_: can you give me an update on bug 742935 / bug 781874?
[14:47] <ubottu> Launchpad bug 742935 in aptdaemon (Ubuntu Natty) "aptd crashed with OSError in release(): [Errno 9] Bad file descriptor" [Undecided,Triaged] https://launchpad.net/bugs/742935
[14:47] <ubottu> Launchpad bug 781874 in aptdaemon (Ubuntu Natty) "<type 'exceptions.TypeError'>: __init__() takes exactly 2 arguments (1 given)" [High,Triaged] https://launchpad.net/bugs/781874
[14:48] <cjwatson> in fact there are a few aptdaemon bugs on https://wiki.ubuntu.com/ReleaseTeam/Meeting/2011-09-16#Foundations
[14:52] <smoser> stgraber, around ?
[14:53] <stgraber> smoser: yep
[14:53] <smoser> we're seeing build break of the ubuntu arm cloud images as a result of your change to friendly-recovery
[14:53] <stgraber> smoser: fixed yesterday
[14:53] <smoser> oh?
[14:53] <stgraber> smoser: if that's the update-grub call failing
[14:54] <smoser> utlemming, stgraber says fixed yesterday
[14:54] <smoser> was our build failure with 0.2.15  ?
[14:54] <jamespage> bdrung: please could you review bug 851900 and ack if you are OK with what I have covered
[14:54] <ubottu> Launchpad bug 851900 in eucalyptus (Ubuntu) "Eucalyptus slow to startup with broken connections to :8443/register" [Undecided,New] https://launchpad.net/bugs/851900
[14:54] <jamespage> no - not that one
[14:54] <utlemming> smoser: correct
[14:54] <stgraber> utlemming: you had it failing with 0.2.15? weird, 0.2.14 was supposed to be the buggy one
[14:55] <stgraber> utlemming: do you have a build log?
[14:55] <jamespage> bdrung: sorry - bug 851659
[14:55] <ubottu> Launchpad bug 851659 in asm3 (Ubuntu) "[FFE] Sync asm3 3.3.2-1 (universe) from Debian unstable (main)" [Wishlist,New] https://launchpad.net/bugs/851659
[14:55] <utlemming> stgraber: yup http://uec-images.ubuntu.com/oneiric/20110916/log.stdout.stderr
[14:55] <stgraber> utlemming: that's 0.2.14
[14:55] <smoser> looking at https://launchpadlibrarian.net/80046327/friendly-recovery_0.2.14_0.2.15.diff.gz
[14:55] <utlemming> stgraber: its at the very bottom, but only for ARMEL images
[14:55] <stgraber> utlemming: Get:64 http://archive.ubuntu.com/ubuntu/ oneiric/main friendly-recovery all 0.2.14 [7242 B]
[14:55] <smoser> i'm wondering why we'd hit that codee
[14:55] <stgraber> fixed in 0.2.15
[14:56] <smoser> yeah, utlemming that log shows 0.2.14
[14:56] <utlemming> stgraber, smoser: you're right
[14:56] <stgraber> smoser: that's the post-inst of friendly-recovery that calls update-grub if it's installed. In your case grub-common is installed but grub isn't. The fix now checks for both /boot/grub/grub.cfg and update-grub, that's how memtest86 does it so that should work for friendly-recovery too
[14:57] <smoser> stgraber, fwiw, your [ -x $(which update-grub) ] is redundant
[14:57]  * utlemming kicks another build of the armel images
[14:57] <smoser> which is not going to show you something htat is not executable
[14:57] <ahasenack> hi guys, can someone please take a look, and hopefully approve, the smart package sitting in the lucid upload queue? https://launchpad.net/ubuntu/lucid/+queue?queue_state=1
[14:58] <smoser> and, also, you can do 'which' with 'command -v 2>/dev/null' to be posix sh internal
[14:58] <smoser> anyway.
[14:58] <smoser> thanks for fixing stgraber
[14:58] <ahasenack> hmm, I don't see it in the maverick or natty upload queues
[15:00] <ahasenack> zul: hi, did you upload smart (#244453) to maverick and natty too?
[15:00] <zul> ahasenack: no i got delayed with other things ill do it right now
[15:00] <ahasenack> zul: ah, ok, thanks
[15:11] <mvo_> cjwatson: I check the release one next, #819328 should be fixed now and 812023 no lnger cause a error (but there reamins some more work to make it really nice and clean)
[15:14] <cjwatson> mvo_: thanks!
[15:16] <bdmurray> didrocks: did you test that bug pattern?  it didn't work for me
[15:18] <didrocks> bdmurray: it's my first addition to the bug pattern, so I maybe screwed something, I looked at the wiki page though
[15:19] <bdmurray> didrocks: there is a script in the bugpatterns branch for testing the pattern called test-local and that'll run the bug pattern against a specific bug
[15:19] <bdmurray> didrocks: e.g. ./test-local 851169
[15:19] <bdmurray> didrocks: I've pushed a fix.  Which wiki page was that by the way?
[15:20] <didrocks> bdmurray: oh? I didn't know about the fix, the wiki page is at: https://wiki.ubuntu.com/Apport/DeveloperHowTo#Bug_patterns
[15:20] <didrocks> bdmurray: thanks for the fix!
[15:21] <bdmurray> didrocks: no problem, I'll update that wiki page with info about testing them then
[15:21] <didrocks> bdmurray: yeah, that would be handful! thanks :)
[15:25] <zul> ahasenack: done
[15:25] <ahasenack> zul: thanks, so now someone else needs to approve it?
[15:26] <zul> ahasenack: yep
[15:26] <bdrung> jamespage: ack, we have to wait for the release team to review it
[15:27] <bdrung> jamespage: http://bazaar.launchpad.net/~james-page/ubuntu/oneiric/jenkins/ftbfs-asm3.3/revision/4 -> why do you change the "Forma of this file is" line?
[15:27] <jamespage> bdrung: because I can't use vim by the looks of things - that is a mistake
[15:31] <jamespage> lemme just fix that
=== dendro-afk is now known as dendrobates
=== yofel_ is now known as yofel
=== deryck is now known as deryck[lunch]
[16:31] <micahg> multiarch broke?
[16:31] <infinity> Archive skew, I assume.
[16:33] <infinity>    libgcc1 | 1:4.6.1-9ubuntu2 |       oneiric | armel, i386, powerpc
[16:33] <infinity>    libgcc1 | 1:4.6.1-9ubuntu3 |       oneiric | amd64
[16:33] <infinity> micahg: ^--- When that shakes out, life will be good again.
[16:33] <micahg> infinity: ok, figured as much, thanks
[16:41]  * micahg wonders why some symlinks in ia32-libs adds 17.8MB to the binary size
[16:42] <infinity> *raise brow*
[16:43] <micahg> err, add 4.9MB to the binary, 17.8 to the installed size
[16:44] <infinity> Without looking at the change, I'd be inclined to go with the general Internet wisdom of "ur doin it wrong".
[16:47]  * micahg is just an observer in this case...
[16:47] <micahg> YokoZar: ^^
[16:48] <infinity> micahg: Did you miss the "- Also add libllvm2.9" part?
[16:49] <micahg> infinity: yeah, that must be it :(
[16:49] <micahg> YokoZar: nevermind
[16:52] <infinity> micahg: Yeah, that's definitely it.  llvm is huge.
[16:53] <infinity> It's also multiarched, so I'm not sure why it's in ia32-libs...
[16:55] <infinity> YokoZar: What was the rationale for adding llvm to ia32-libs?
[17:00] <slangasek> infinity: dependency of some of the mesa backends.
[17:00] <slangasek> I was content to leave them broken, YokoZar seemingly less so
[17:01] <infinity> slangasek: Irksome.  So not really fixable until mesa is also multiarched, I guess.
[17:01] <infinity> Except... It is.
[17:03] <infinity> But I suppose we still need lib32 insanity there for hysterical raisins.
[17:07] <slangasek> infinity: it's all needed because of other libraries farther up the chain that aren't multiarched; the handful of packages that still have to be installed with ia32-libs should be dependency-complete on amd64, since we can't make ia32-libs Depends: libgl1-mesa:i386
[17:07] <slangasek> but then, "fixing" libGL in the latest upload has regressed some binary-only software that was happier when it couldn't find it ;) (bug #851947)
[17:07] <ubottu> Launchpad bug 851947 in ia32-libs (Ubuntu) "/usr/lib32/libGL.so.1 prevents Doom 3 from starting" [Undecided,New] https://launchpad.net/bugs/851947
[17:14] <infinity> slangasek: Fun bug.  I assume that's a bad interaction with a binary driver or some such.  They used to dpkg-divert those paths.
[17:16] <infinity> Maybe it's time to install the non-free nvidia driver and try to play Doom.
[17:22] <Chipzz> infinity: with the added bonus of loosing some frustration. or was that the whole point to begin with? ;)
[17:24] <infinity> Chipzz: I can play video games with nouveau these days (we've come a long way!), so the frustration vector with the non-free driver is entirely in the wrong direction.
[17:29] <slangasek> infinity: well, we don't use dpkg-divert anymore, but update-alternatives :)
[17:29] <slangasek> so if ia32-libs is now installing libGL to /usr/lib32, that could well be the problem, because the alternatives are meant to operate on ld.so.conf.d
[17:30] <infinity> slangasek: Yeah, that's almost certainly the problem, if none of that's been looked at since dpkg-divert was given the boot from the binary drivers.
[17:31] <slangasek> mvo_: still around?  Would you be willing to also install cryptsetup to test that case on bug #849954?
[17:31] <ubottu> Launchpad bug 849954 in plymouth (Ubuntu Oneiric) "FFe: enable flicker-free boot with lightdm" [Medium,Incomplete] https://launchpad.net/bugs/849954
[17:31] <slangasek> mvo_: you don't need to use cryptsetup, just have it installed
[17:35] <Daviey> RoAkSoAx: How does testdrive know about the current candidate?
[17:35] <Daviey> Does it use, http://iso.qa.ubuntu.com/qatracker/dllist ?
=== deryck[lunch] is now known as deryck
[18:20] <i0n> is there anywhere I can find out what ./configure options the apache2 maintainer used when packaging httpd?
=== chuck_ is now known as zul
[18:23] <slangasek> i0n: download the source package and look at it?
[18:24] <slangasek> apw: do you know if there's a reason why udev's udev-fallback-graphics job and plymouth-splash/lightdm/gdm have duplicate checks for graphics-device-added and drm-device-added events?  It seems to me that they should really only be checked in one place or the other
[18:24] <i0n> slangasek: i did, ive busted it open and looking at it im not finding how it assigns the install directories.. In src/debian there are some files like apache2.2-bin.dirs which look right, but im having a hard time seeing where they are called.
[18:24] <slangasek> i.e., either udev-fallback-graphics should be emitted only when we *don't* get one of the other events, or we should check for that event exclusively rather than checking for it as well as the -device-added events
[18:25] <slangasek> i0n: debian/rules is the makefile that controls package building.  You could also look at the build log in launchpad, which would show all the command output
[18:25] <i0n> slangasek: thanks, im new to packaging on this level.
[18:30] <i0n> slangasek: is there a dpkg command way to grab the source?
[18:30] <slangasek> i0n: 'apt-get source <package>'
[18:32] <i0n> hmm i copied the debian/ directory into the new apache source
[18:36] <zul> barry: for the dh_python2 transition does it matter if the python version is 2.6.6-3
[18:36] <barry> zul: 2.6.6-3~ specifically
[18:37] <zul> barry: how come?
[18:37] <Daviey> That is why dh_python2 support was added, wasn't it?
[18:37] <Daviey> s/why/when
[18:38] <mtaylor> sorry - just joined - can someone paste me the bit of this that I missed?
[18:38] <barry> zul: python-defaults (2.6.6-3) unstable; urgency=low
[18:38] <barry>  
[18:38] <barry>   * Upload to unstable
[18:38] <barry>   * dh_python2: egg renaming fixed
[18:38] <barry>  
[18:38] <barry>  -- Piotr Ożarowski <piotr@debian.org>  Wed, 22 Sep 2010 23:03:15 +0200
[18:38] <barry>  
[18:38] <zul> barry: ah ok
[18:39] <barry> zul: np!
[18:40] <Daviey> Does anyone have thoughts on http://paste.ubuntu.com/691015/ (line 442), having difernet behaviour based on lsb_release output seems fugly to me..
[18:40]  * mtaylor agrees with Daviey - would love a better solution - but would prefer fugly to no solution
[18:41] <mtaylor> Daviey: I suppose I _could_ test for the existence of dh_python2...
[18:42] <Daviey> mtaylor: I'm not convinced debian/rules should handle backports in the main stamp, at least.
[18:42] <Daviey> Is it really unreasonable to run an extra script?
[18:42] <mtaylor> Daviey: I understand
[18:42] <mtaylor> I would HIGHLY prefer not to
[18:42] <slangasek> IMHO this is why we have VCSes that let us cheaply manage different branches for each release, but YMMV :)
[18:42] <infinity> Daviey: Different behaviour based on lsb_release is pretty common.
[18:43] <slangasek> infinity: yes, but generally only for Ubuntu vs. Debian, not lucid/maverick vs. natty+
[18:43] <Daviey> infinity: example?
[18:43] <Daviey> Ahh, yes - seen that for upstart vs init.d
[18:43] <micahg> slangasek: not true, we do it in the Mozilla products
[18:43] <mtaylor> Daviey: how about this insteaD:
[18:43] <mtaylor> WITH_PYTHON2 = $(shell test -f /usr/bin/dh_python2 && echo "--with python2")
[18:43] <infinity> slangasek: Looked at the GCC makefiles lately?
[18:44] <micahg> slangasek: I take that back, Mozilla is an exception to everything :)
[18:44] <slangasek> mtaylor, Daviey: we are meant to be backporting dh_python2 for use with lucid and maverick via -updates or -backports yet this cycle; would it perhaps be sufficient to assume dh_python2 availability?
[18:45] <mtaylor> slangasek: that's been part of the assumption ... but we're trying to release openstack diablo
[18:45] <slangasek> infinity: yes, and gcc is the exception that proves the rule... :)
[18:45] <infinity> slangasek: Perhaps. :P
[18:45] <mtaylor> slangasek: and I currently cannot build packages for lucid
[18:45] <slangasek> mtaylor: right
[18:45] <ScottK> That's because no one finished the backport yet.
[18:45] <ScottK> Someone should do that.
[18:45] <Daviey> mtaylor: whey not wrap your package building with, [ -a debian/backports/$(lsb_release -c | awk '{ print $2 }') ] debian/backports/$(lsb_release -c | awk '{ print $2 }')
[18:45] <Daviey> so run a backport script if it exists?
[18:45] <mtaylor> slangasek: also - I'm not personally convinced about asking someone who adds ppa:nova-core/ppa to also add backports
[18:45] <infinity> I see no particular issues with debian/rules being backport-friendly...
[18:46] <ScottK> mtaylor: The intent is to put it in -updates.
[18:46] <mtaylor> Daviey: why is that better/more desirable? that requires wrapper scripts
[18:46] <slangasek> doko: ^^ barry mentioned that you have a tentative dh_python2 backport branch; is it in a state worth sharing with mtaylor?
[18:46] <mtaylor> slangasek: yeah - if that was something I could pop into my ppa, that would make me very happy
[18:46] <Daviey> mtaylor: i assumed you already had a script?
[18:47] <mtaylor> Daviey: there is currently a script, but every line that exists in it is a bug imo
[18:48] <barry> i'm also happy to take over doko's branch if it would help
[18:48] <mtaylor> Daviey: you will find that I come from the "defaults should do sensible things" camp and find wrapper scripts to be hacks that indicate underlying system bugs
[18:48]  * mtaylor would also be more than happy to help on doko's branch ... certainly not opposed to pitching in here :)
[18:49] <Daviey> mtaylor: and WITH_PYTHON2 = $(shell lsb_release -c | perl -nle '/lucid|maverick/ && print "--with python2"') , isn't a hack!?
[18:49] <doko> no branch. I'll try to push this out this weekend
[18:49] <dobey> does a release team member still need to approve freeze exception on bug #850142 ? it has +1 from docs and translations
[18:49] <ubottu> Launchpad bug 850142 in Ubuntu One Control Panel "UI Freeze exception: Remove the Bookmarks section from the Services tab" [High,In progress] https://launchpad.net/bugs/850142
[18:49] <SpamapS> If the goal of the branch is to build on lucid -> current .. then it should just handle this in debian/rules by choosing whichever is available. How is that not working already with just 'dh' ?
[18:49] <mtaylor> in any case - I expect someone to be able to pull a packaging branch and build a package using standard toolchains and not have to know about additional scripts that must be run in order to enable that
[18:50] <dobey> SpamapS: dh doesn't default to python2 in anything yet. it defaults to python-support
[18:50] <SpamapS> Is there some reason we can't just let it build with python-support ?
[18:51] <cr3> skaet: any updates on the flag I raised earlier about checkbox and file permissions?
[18:51] <dobey> SpamapS: too simple? ;)
[18:51] <skaet> cr3,  yes, sorry.  its fine.  go ahead.
[18:51] <SpamapS> its still in main
[18:51] <infinity> Daviey: It's not much worse than old debian/rules files that use to do "test -x /usr/bin/dh_foo && dh_foo", which was a very common practice.
[18:51] <SpamapS> this doesn't go on any CDs
[18:51] <dobey> SpamapS: the fun part is if you are shipping a twisted plugin or something
[18:51] <infinity> Daviey: Again, I don't see why you're annoyed with a backport-friendly rules file.
[18:51] <SpamapS> I would be pretty surprised if nova/glance/swift had twisted plugins embedded. :)
[18:52] <barry> doko: awesome, thanks!
[18:52] <dobey> SpamapS: well anything similar to that. twisted is an example i saw problems with, because it uses python-central on lucid, but not on maverick+
[18:52] <Daviey> infinity: I'm not annoyed, it just seems messy to support X releases with one rules file.
[18:53] <barry> the main reason to backport dh_python2 is so that people can also back port oneiric/debian versions of converted packages more easily
[18:53] <SpamapS> Daviey: what is the reasoning behind forcing dh_python2?
[18:53] <infinity> Daviey: Honestly, I prefer it.
[18:53] <mtaylor> Daviey: depends on from which perspective... NOT supporting X releases with one rules file is messy from an upstream perspective
[18:54] <dobey> Daviey: i'd rather have 1 rules file, even if i have to do funky stuff to generate control from control.in and such, rather than N rules/control files, from the perspective of maintaining daily builds on N releases
[18:54] <mtaylor> ++
[18:55] <Daviey> mtaylor: I dunno, having a backport script seems to be cleaner to me.. easier to maintain, and a tidier rules file.  I guess that is preference.
[18:55] <micahg> openjdk also uses one rules file for multiple releases
[18:55] <Daviey> I've seen the script to mangle the package in a few areas.
[18:55] <Daviey> It also allows you to mangle to control file etc.
[18:55] <SpamapS> Whats tidier than a dh7 rules file with no arguments? :)
[18:55] <mtaylor> now that's the tidiest!
[18:56] <dobey> SpamapS: an empty rules files ;)
[18:56]  * SpamapS got told
[18:56] <mtaylor> dobey: ++
[18:56] <SpamapS> ;)
[18:56]  * infinity fears we've now abstracted so far that people find a 3-line rules file ugly, when a 1-line one would have sufficed if there wasn't that "icky 2-line hack".
[18:56] <barry> yeah, unfortunately, even with dhpy2, you still can't quite get to a 3-liner
[18:56] <SpamapS> infinity: ROFL
[18:57]  * mtaylor has many packages that had 3 line dh rules files and worked just fine... turns out if upstream behaves itself ... :)
[18:57] <dobey> if people would just stop writing new code, it would be easy
[18:57] <mvo_> slangasek: re 849954 - sure I can do that
[18:58] <slangasek> mvo_: thankee :)
[18:58] <barry> mtaylor: yep.  more goo comes in when you want to run the test suite for multiple versions, have rest docs to build, etc.
[18:58] <mtaylor> barry: TOTALLY
[18:59] <barry> mtaylor: well, now that i passed pox's muster on my own packages, i'm going to look into fixing those problems.  eg. debbug 641314
[18:59] <Daviey> mtaylor: note, that using the mangling method would have removed all the pain you have been experiencing trying to get one debian/ for all releases
[18:59]  * YokoZar thought he removed the wine1.0 package last cycle...
[19:00] <mtaylor> Daviey: there are many things that would have removed all of the pain I'm experiencing. I'm guessing we probably don't want to explore them all right now :)
=== kklimonda_ is now known as kklimonda
[19:02] <dobey> slangasek: can one of you give release team ok on bug #850142 ? it has OKs from docs/i18n
[19:02] <ubottu> Launchpad bug 850142 in Ubuntu One Control Panel "UI Freeze exception: Remove the Bookmarks section from the Services tab" [High,In progress] https://launchpad.net/bugs/850142
[19:02] <YokoZar> Say I'm removing wine1.0, can I: 1) Straight up have archive delete it, 2) Convert it into a dummy package depending on wine1.2, or 3) Delete it and ask update-manager to transition users?
[19:02] <mvo_> YokoZar: I think (2) is best
[19:02] <Daviey> mtaylor: Well if you think it helps the discussion..
[19:02] <mvo_> YokoZar: hello btw
[19:02] <infinity> YokoZar: Having update-managet do it is something we do when you fail to do (2) correctly.  It shouldn't be the default option. :P
[19:03] <mtaylor> Daviey: nah. I doubt it would be useful in any way right now
[19:03] <YokoZar> mvo_: Hey there :)
[19:03] <YokoZar> infinity: Yes, the downside is this means it takes 2 LTS cycles to completely remove a package since you need the first to transition users and the second to breaks/replaces it
[19:03] <infinity> YokoZar: However, you should probably produce the transitional metapackages from the 1.2 or 1.3 source, and just delete the 1.0 source completely.
[19:03] <YokoZar> infinity: yes, of course
[19:04] <Daviey> mtaylor: well best not say it then :)
[19:04] <mtaylor> done!
[19:04] <YokoZar> mvo_: Does software center still display dummy packages?
[19:04] <infinity> YokoZar: Eh?  You can break/replace right now, it should just be versioned.
[19:05] <mvo_> yes, but that is probably something we should fix (that it displays dummy packages)
[19:05] <infinity> YokoZar: And then after the next LTS, you just silently drop the transitional package.
[19:05] <infinity> mvo_: Filtering out "transitional" in descriptions would probably catch most of them.
[19:05] <infinity> mvo_: Curious if there are any false positives in that list, though.
[19:07] <RoAkSoAx> Daviey: nope not at the moment
[19:08] <RoAkSoAx> Daviey: when I did that the dllist stuff wasn't yet being generated, but thanks for reminding me about that
[19:08] <mvo_> infinity: yeah, I will check that out
[19:08] <Daviey> RoAkSoAx: how are you doing it atm?
[19:09] <RoAkSoAx> Daviey: (status, output) = commands.getstatusoutput("wget -q -O- http://iso.qa.ubuntu.com/qatracker | egrep 'iso.qa.ubuntu.com/qatracker/test'")
[19:11] <Daviey> RoAkSoAx: awesome :)
[19:18] <RoAkSoAx> Daviey: ;)
[19:19] <SpamapS> damnit.. just figured out my Canon printer has been DoS'ing my wifi for the last day with mDNS.. no wonder network has been crap.
[19:21] <YokoZar> infinity: I meant breaks/replace a non-versioned one and have no binary dummy in the archive.  Takes two LTS for that :(
[19:21] <YokoZar> Not that I should be particularly concerned about binary dummys...
[19:22] <infinity> Nope, still just the one.
[19:24] <infinity> YokoZar: The trick, if your foo1.0 package is produced from foo1.2 sources is to have your Breaks/Replaces on << Source-Version, and then when you drop the transitional package (in the release after the LTS), you just change that Breaks to a Conflicts, and poof it goes away.
[19:24] <YokoZar> Err ok 2 releases not 2 LTS releases
[19:24] <YokoZar> (one of which is an LTS though)
[19:24] <nigelb> SpamapS: In honor of the awesomeness http://c0016417.cdn2.cloudfiles.rackspacecloud.com/353omj.jpg
[19:24] <infinity> YokoZar: I don't see a problem with that. :P
[19:25] <micahg> infinity: YokoZar don't forget about removing the version when converting to conflicts :)
[19:25] <infinity> micahg: Actually, the versioning still works in that case.  But sure, it's also correct to remove it. :P
[19:26] <micahg> infinity: I've been told versioned conflicts does bad things to apt
[19:26] <slangasek> correct
[19:27] <slangasek> you should use versioned breaks+replaces, or unversioned conflicts+replaces, per Policy
[19:27] <infinity> I suspect that depends on what it's trying to resolve.
[19:27] <slangasek> other combinations are Nearly Always Wrong
[19:28] <infinity> slangasek: Well, yes.  That policy is sane because it accidentally describes what Breaks and Conflicts are semantically meant to do.
[19:28] <infinity> But from a "will it break" perspective, a versioned Conflict+Replace won't behave any worse than a versioned Break+Replace, it's just not quite correct.
[19:28] <infinity> (But when the version spec ends up matching "every version ever", it's ultimately the same as unversioned)
[19:29] <slangasek> no, a versioned Conflicts+Replaces *does* behave worse than a versioned Breaks+Replace
[19:30] <slangasek> Breaks --> deconfigure before continuing, Conflicts --> remove or upgrade before continuing
[19:30] <slangasek> very different impact on the resolver
[19:30] <infinity> slangasek: In the above case?  Unless someone broke something in apt, I fail to see how it could.
[19:30] <infinity> But yes, in many cases, fair enough.
[19:32] <dobey> SpamapS: i don't even have my printer plugged in to ac power unless i need to use it for something
[19:52] <SpamapS> nigelb: :-D
[19:52] <nigelb> :)
[20:00] <micahg> can we recommend from multiverse to partner since if partner isn't enabled, it should just ignore it?
[20:01] <dobey> hrmm
[20:01] <ScottK> micahg: You can.
[20:01] <ScottK> The only requirement for multiverse is that it be legally distributable.
[20:01] <micahg> ScottK: ok, thanks
[20:01] <ScottK> It doesn't even have to be installable.
=== dendrobates is now known as dendro-afk
[20:58] <cr3> skaet: regarding the flag I raised earlier, roadmr reported bug #852138 with the corresponding merge request
[20:58] <ubottu> Launchpad bug 852138 in checkbox (Ubuntu) "Some files under scripts/ lack executable permission" [Undecided,New] https://launchpad.net/bugs/852138
[21:11] <m4n1sh> doko: ping
[22:12] <mtaylor> kirkland: ping
[22:12] <kirkland> mtaylor: yo
=== dendro-afk is now known as dendrobates
=== dendrobates is now known as dendro-afk
[23:08] <sconklin> @pilot out
=== udevbot changed the topic of #ubuntu-devel to: Beta 2 Freeze | Archive: Feature/UI Freeze | 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: