=== cpg is now known as cpg|away
[00:58] <ScottK> I'd appreciate it if someone who understands how to troubleshoot multi-arch stuff would look at Bug 1079836.
[00:58] <ubottu> Launchpad bug 1079836 in python2.7 (Ubuntu) "Python 2.7 fails to install after upgrade from 12.04 to 12.10" [Undecided,New] https://launchpad.net/bugs/1079836
=== cpg|away is now known as cpg
[01:27] <infinity> ScottK: I'm having a hard time not blaming that on his local from-source installation having been not entirely cleaned up...
[01:30] <infinity> ScottK: Responded to the bug, however.
=== cpg is now known as cpg|away
=== jamesh_ is now known as jamesh
[02:45] <ScottK> infinity: Thanks.  You're probably right.
=== fenris is now known as Guest70212
=== Guest70212 is now known as ejat
[03:20] <jimi_c> is it normal that the desktop iso only has a handful of .deb files on it, whereas the server iso has many more?
[03:22] <jimi_c> i run the cobbler project, and just tried to import the 12.10 desktop distro and noticed the issue, since cobbler is looking for the linux-headers deb file
[03:23] <StevenK> The server uses the alternate installer, the desktop iso uses Ubiquity and a squashfs.
[03:23] <jimi_c> will the desktop version work with a normal preseed?
=== fenris is now known as Guest50405
=== cpg|away is now known as cpg
[04:57] <pitti> Good morning
=== Tonio_ is now known as Tonio_aw
[07:58] <dholbach> good morning
=== tkamppeter_ is now known as tkamppeter
[08:36] <ion> hai
=== smb` is now known as smb
=== Tonio_aw is now known as Tonio_
[09:09] <jibel> pitti, auto package tests are broken today. There is a bug in cloud images. The default user is not added to sudoers and cannot execute anything as root. I'll find a workaround until it get  fixed.
[09:10] <pitti> jibel: thanks for letting me know
[09:10] <pitti> jibel: can we use yesterday's?
[09:15] <jibel> pitti, no it was already broken. Creation of the image runs fine because it runs as root, only the tests fail afterwards when then run through sudo.
[09:49] <pitti> jibel, cjwatson: do you have time to talk about britney/autopkgtest now or in 10 mins?
[09:50] <jibel> pitti, I do
[09:51] <pitti> jibel, cjwatson: I'm hanging out in Platform QA -> Meeting room
[09:51] <cjwatson> Yeah, 10 mins
[09:54] <OdyX> tkamppeter: Q regarding foomatic-db-compressed-ppds: all cups interfaces I could check here (:631, system-config-printer-kde), show duplicated driver entries for foomatic-db-compressed-ppds (e.g. OKI B6300): what is at fault? compressed-ppds that has both "DRV" and "MFG" entries or interfaces that don't filter ?
=== Tonio_ is now known as Tonio_aw
=== Tonio_aw is now known as Tonio_
[10:13] <jibel> cjwatson, https://code.launchpad.net/auto-package-testing/
[10:13] <jibel> cjwatson, http://bazaar.launchpad.net/~auto-package-testing-dev/auto-package-testing/trunk/view/head:/jenkins/trigger-adt-test
=== Tonio_ is now known as Tonio_aw
=== Sweetsha1k is now known as Sweetsharl
=== Sweetsharl is now known as Sweetshark
[10:57] <tkamppeter> OdyX, system-config-printer filters duplicate entries, I do not know why system-config-printer-kde filters them, too. The best would be to add filtering of duplicate entries to pyppd.
=== _salem is now known as salem_
[11:04] <OdyX> tkamppeter: /usr/lib/cups/driver/foomatic-db-compressed-ppds list | grep B6300-Postscript
[11:05] <OdyX> tkamppeter: ^ does the output of that make sense ?
[11:06] <OdyX> tkamppeter: that looks like a line-split wrongly placed aftter TP; and before MFG, no ?
=== doko_ is now known as doko
[11:21] <hrw> doko: can you check one thing for me? "apt-get source gcc-4.7;cd gcc-4.7-*;echo aarch64 >debian/target;debian/rules patch"
[11:23] <hrw> Applying patch svn-doc-updates.diff
[11:23] <hrw> patch: **** Only garbage was found in the patch input.
[11:23] <hrw> Patch svn-doc-updates.diff does not apply (enforce with -f)
=== cpg is now known as cpg|away
[11:28] <cjwatson> pitti: oh, OK, I got rid of all but one of the python-apt stderr failures :)
[11:29] <pitti> cjwatson: oh wow, that was quick!
[11:29] <cjwatson> no, I mean last week or before
[11:29] <cjwatson> pitti: I suspect some of the remainder is fallout from gnupg being stricter about long IDs
[11:30] <jibel> pitti, I worked around the bug in VMs used for adt and re-ran apport.
[11:31] <pitti> jibel: cheers! I didn't even see that fail, I guess it wasn't mirrored to the public instance
[11:33] <jibel> pitti, interesting, publication stopped 2 days ago :(
[11:33] <doko> hrw, sure, just disable it for now
[11:33] <pitti> jibel: FSVO "interesting" :(
[11:34] <jibel> Thread state
[11:34] <jibel> Dead(!)
[11:34] <jibel> java.lang.NullPointerException
[11:34] <jibel> jenkins' publisher strikes again
[11:37] <hrw> doko: did that already
[12:12] <mlankhorst> infinity: ping?
[12:23] <tkamppeter> OdyX, yes, this looks really like a bug in pyppd.
[12:32] <OdyX> tkamppeter: pyppd source says "    One ppd_file might result in more than one PPD. The rules are: return an
[12:32] <OdyX>     PPD for each "1284DeviceID" entry, and one for each "Product" line, if it
[12:32] <OdyX>     creates an unique (Manufacturer, Product) DeviceID.
[12:32] <OdyX> "
[12:33] <OdyX> I can't trace back to where it originates, but it sounds weird.
[12:42] <OdyX> tkamppeter: 3a96ceb9526f9505b2a07a614a6c7d2d53dd1d7d in pyppd.git, from 2010-08-09, reasoning unclear to me.
[12:49] <OdyX> tkamppeter: filed that as https://github.com/vitorbaptista/pyppd/issues/1
=== Tonio_aw is now known as Tonio_
=== attente_zzz is now known as attente
=== Tonio_ is now known as Tonio_aw
=== Tonio_aw is now known as Tonio_
[14:21] <mitya57> hi barry, we have just been missing you at #ubuntu-meeting :)
[14:23] <barry> mitya57: yeah, i was having some system problems this morning :/
[14:23] <mitya57> thanks for coming anyway :)
=== Tonio_ is now known as Tonio_aw
[14:57] <wookey> infinity: I failed my core-dev entrance exam due to SRU cluelessness
[14:57] <wookey> 'Don't know - I'd ask someone on IRC' was not deemed good enough
[14:58] <wookey> they are quite strict :-)
=== Tonio_aw is now known as Tonio_
[15:03] <tumbleweed> wookey: when I'm unsure, I re-read the descriptions here https://wiki.ubuntu.com/UbuntuDevelopers#Ubuntu_Core_Developers
[15:05] <wookey> yeah. I'd probably have failed me too. Thing is short of actually swotting up and treating it like an exam just filing bugs and letting other deal with stuff, I'm not actually going to get much more knowledgable about that stuff.
[15:05] <tumbleweed> find a bug in a stable release, and SRU it :)
[15:06] <stgraber> wookey: I'd recommend reading the SRU process wiki page and the release schedule for the current LTS and the current development release. That should help you understand the interactions between those two and have a clearer idea of how things work.
[15:07] <wookey> I've already done that. The question wasn;t about 'did you know there was an SRU process' or 'have you used SRU process', it was 'for which transitiopns between suites is it appropriate'
[15:08] <stgraber> wookey: FWIW, what I was expecting you to tell me was that a change that just landed in experimental would have to be synced or merged into raring, then can be SRUed to precise but as you need to keep an upgrade path, the change also needs to be SRUed to quantal
[15:09] <stgraber> wookey: then you'd have had extra bonus points for noticing that the date I gave you was during the 12.04.2 freeze and so you could have told me that the precise part of that process would have to wait until the 31st (but as I said, that'd have been extra points ;))
[15:09] <wookey> Right. Well I definately didn't know that
[15:10] <wookey> But I can;t imagine why I'd ever want to get somethig into precise-updates
[15:10] <wookey> so it's not very useful knowledge
[15:11] <wookey> But I agree, I have quite a vague understyanding of the sync/merge paths and processes
[15:13] <wookey> I have learned enough to know that I shouldn't presume anything from the way Debian does stuff. Which is why I default to asking someone clueful.
[15:13] <wookey> If it's not obvious
[15:31] <smoser> slangasek, at some point i think i'm going to need your help with what seems to me to be a race condition in networking coming up that is showing in raring images.
[15:31] <smoser> https://bugs.launchpad.net/ubuntu/+bug/1078926
[15:31] <ubottu> Launchpad bug 1078926 in Ubuntu "raring instance failed to find EC2 datasource" [High,Confirmed]
[15:34] <smoser> it appears from /var/log/syslog that dhclient for an 'auto' interface was blocked, and couldn't finish until 'failsafe' finished. (note, also, that cloud-init-nonet probably had very similar timeouts, so it could have been it that was blocking)
[15:47] <doko> kees, ping
[16:06] <ritz_> barry ping, wrt https://bugs.launchpad.net/udd/+bug/848064 and https://bugs.launchpad.net/ubuntu/+source/bzr/+bug/1078395
[16:06] <ubottu> Launchpad bug 888615 in Bazaar "duplicate for #848064 UDD branch freshness checker breaks on incomplete history" [High,Confirmed]
[16:06] <ubottu> Launchpad bug 1078395 in bzr (Ubuntu) "bzr: ERROR: Revision * not present in *" [Medium,New]
[16:07] <doko> mterry, the boost stuff was promoted on Friday
[16:07] <mterry> doko, yeah thanks.  The nux branch enabling tests landed
[16:07] <mterry> doko, so whenever nux makes a new release, they will start being used
[16:07] <ritz_> barry how do I fix this bug ?
[16:08] <doko> unless pitti demotes it before ... that's why I don't like pre-promotions
[16:08] <ritz_> is this bzr, or the lp import ?
[16:08] <pitti> FYI, I don't do archive admin stuff these days unless someone asks me
[16:09] <bdmurray> mpt: do you have an opinion on bug 1033226?
[16:09] <ubottu> Launchpad bug 1033226 in update-manager (Ubuntu) "No close option, only restart" [Medium,Triaged] https://launchpad.net/bugs/1033226
[16:11] <mpt> bdmurray, yes. I'd like to add a "Restart Later", I just haven't figured out what it should do yet, i.e. when and how it should remind you again.
[16:11] <mterry> mvo, the update-manager test_update_origin.py test is failing.  Seems like the fake cache installs it sets up aren't working.  Could you look at it real quick and see if you know what it is?
[16:11] <mterry> mvo, (not as in real soon, but as in don't spend a lot of time if you don't know what's wrong)
[16:13] <barry> ritz_: are you looking to fix the bug itself, or to fix an import affected by that bug?
[16:15] <mvo> mterry: test for libcupscgi1 fails?
[16:16] <mterry> mvo, the name changes each time because of internal set sorting, but yeah
[16:16] <mterry> mvo, the lines above the test go through a set of package names and "fake install" them into the apt cache used for the test
[16:16] <mterry> mvo, but as soon as it tries to see if any of that worked, it fails
[16:17] <mterry> mvo, this doesn't seem to have been caused by an update-manager checkin
[16:20] <mvo> mterry: looking
[16:20] <mvo> mterry: should be fixed in trunk now
[16:20] <mterry> mvo, that was easy  :)
[16:21] <mterry> mvo, ah interesting
[16:21] <mvo> mterry: yeah :) took me a bit of head scratching, but then I figured what was wrong
[16:21] <mterry> mvo, python-apt got stricter in the multi-arch world?
[16:23] <mvo> mterry: apt itself got stricter, it used to assume missing architecture means native, but that is no longer the case for raring. fortunately that is exceedingly rare, except of re.g. testsuites and really old installs
[16:23] <mterry> mvo, makes sense.  thanks!
[16:23] <mvo> yw
[16:26] <ritz_> barry either one
=== Tonio_ is now known as Tonio_aw
=== Tonio_aw is now known as Tonio_
[16:29] <barry> ritz_: i think you'll have more luck asking on the #udd channel
[16:29] <ritz_> thank you :)
[16:33] <ritz_> barry , hmm, where do I find #udd ?
[16:34] <barry> ritz_: hmm, i guess #bzr is better
[16:34] <ritz_> barry thanks you :)
[16:35] <barry> ritz_: good luck!
[16:44] <slangasek> smoser: I'm on vacation all week; you might want to talk to stgraber about networking races instead
[16:45] <smoser> slangasek, thanks.
[16:48] <cjwatson> pitti: I fixed all the python-apt autopkgtest errors I could, but I'm left with the ones you see in the current output; I can't reproduce that locally, even if I start up a process listening on the relevant port to deliberately confuse matters (which the test suite should now guard against)
[16:49] <cjwatson> pitti: Any help gratefully welcomed, if you have time ...
[16:55] <slangasek> smartboyhw: also, you're going to want to reproduce it with --verbose so we can get the ordering output from upstart.
[16:55] <slangasek> er
[16:55] <slangasek> smoser: also, you're going to want to reproduce it with --verbose so we can get the ordering output from upstart.
[16:55] <smoser> slangasek, well... that'd be nice...
[16:56] <smoser> yeah, i knew that'd be what you'd ask for.
[16:56] <smoser> its non-trivial to produce since it doesn't happen all the time.
=== francisco is now known as Guest78941
=== mcclurmc is now known as mcclurmc_away
=== fisted is now known as Guest13876
[17:27] <toabctl> is there some documentation about adt-run ?
[17:30] <infinity> mlankhorst: ?
=== Quintasan_ is now known as Quintasan
[17:30] <infinity> wookey: Don't worry, I don't know anything about SRUs either.
[17:34] <bdmurray> bryce: does the xorg apport package hook need to run for package install failures?
[17:34] <bdmurray> bryce: for example bug 1077509
[17:34] <ubottu> Launchpad bug 1077509 in libdrm (Ubuntu) "Ubuntu will not update on my laptop" [Undecided,New] https://launchpad.net/bugs/1077509
[17:38] <ChogyDan> RAOF: your analysis of bug 1068341 is incorrect.  Dpkg doesn't pull in the linux-headers dependency at all, which is why folks are having trouble
[17:38] <ubottu> Launchpad bug 1068341 in software-properties (Ubuntu) "No way to specify correct dependencies for dkms packages (nvidia driver install fails to get matching header)" [High,Triaged] https://launchpad.net/bugs/1068341
[17:38] <xnox> toabctl: not much really apart from the manpages.
[17:39] <xnox> toabctl: use the wrapper script in lp:auto-package-testing
[17:39] <toabctl> xnox, I got http://developer.ubuntu.com/packaging/html/auto-pkg-test.html and dholbach told me about https://wiki.ubuntu.com/TestCaseCompetition
[17:39] <xnox> toabctl: it uses a cloud image to spin up a VM and execute adt-run for you based on a packaging bazaar branch pushed on launchpad.
[17:39] <xnox> toabctl: since that's how the jobs are run in real jenkins
[17:40] <xnox> toabctl: while that should work, it's also dangerous as it can destroy your machine.
[17:40] <xnox> toabctl: for example a rm -rf gone astray can wipe everything.
[17:40] <dholbach> xnox, maybe we should update http://developer.ubuntu.com/packaging/html/auto-pkg-test.html?
[17:41] <xnox> dholbach: toabctl: yes, please use "prepare-testbed & run-adt-test" scripts from the lp:auto-package-testing. As that's the only way that we actually currently support results =)
[17:42] <doko> kees, jdstrand: see gcc-4.8 in the ubuntu-toolchain-r/test ppa. had to disable gcc-default-format-security.diff, breaks the bootstrap. any idea why?
[17:42] <xnox> if it doesn't pass with run-adt-test it will not pass in jenkins either.
[17:42] <mlankhorst> bryce: see email btw, I want to get the backport stack into precise-proposed asap
[17:42] <dholbach> xnox, https://bugs.launchpad.net/ubuntu-packaging-guide/+bug/1080805 - I'll have a chat with pitti tomorrow (if nobody goes and fixes it in the meantime :))
[17:43] <ubottu> Launchpad bug 1080805 in Ubuntu Packaging Guide "Update autopkgtest guide with current tool information" [Undecided,New]
[17:43] <xnox> dholbach: lol =))))
[17:44] <xnox> dholbach: to be honest those two scripts should be merged into ubuntu-dev-tools
[17:45] <dholbach> xnox, sounds good to me - maybe you can file a bug about that ;-)
[17:46] <xnox> dholbach: sure.
[17:51] <jdstrand> sbeattie/sarnold: could you guys coordinate what might be going on with doko's question re gcc-default-format-security.diff (perhaps with kees)? ^
[17:54] <kees> doko: it applies, but breaks the build? weird.
[18:16] <mterry> mpt, am looking at an update-manager bug about what happens when an update error occurs.  So if an update error occurs, but there are still updates available (either from a previous check or a partial current check), do you have a preference for the wording on the "updates available" page
[18:17] <mterry> ?
[18:17] <mterry> Something similar to the stop-update message I imagine
=== yofel_ is now known as yofel
[18:42] <bryce> bdmurray, if you're 100% certain it's a package install failure and not, e.g. dkms build issues or similar, then much that's collected currently could be omitted.
[18:42] <bryce> bdmurray, you thinking you'd like to optimize the hooks a bit?
[18:42] <bryce> mlankhorst, ok looking
[18:46] <robru> y
[18:46] <robru> lol
[18:53] <bryce> mlankhorst, is it the whole stack you're ready to upload or just the x11proto and apt updates referenced in your email?
[18:54] <mlankhorst> I can upload the rest after x11proto and apt
[18:54] <mlankhorst> that's why I want those in quickly, but since x11proto is a new version that's not a dot release I probably need more paperwork :/
[18:54] <bryce> mlankhorst, ah, yes
[18:55] <infinity> We need a new apt for the new X11 stack? *raise brow*
[18:55] <bryce> infinity, patched, I expect, to handle smoother uploads
[18:56] <mlankhorst> infinity: multiarch bug that makes switching impossible
[18:56] <mlankhorst> it fails halfway through and only dpkg -r *-lts-quantal solves it
[18:56] <infinity> mlankhorst: Oh, that bugfix is already in the queue.  Kay.
[18:56] <infinity> mlankhorst: I thought it was something scary. :P
[18:56] <bryce> mlankhorst, so in both cases you are going to be following the regular SRU process.  So start by for each filing a bug report stating the problem and solution clearly.  Follow the usual SRU syntax (Impact, Test Case, Regression Risk, etc.)
[18:57] <infinity> mlankhorst: I'll review and accept that right now.
[18:57] <mlankhorst> infinity: nah I don't dare to touch apt for that
[18:58] <bryce> mlankhorst, in the case of x11proto, how many changes are in the changeset compared with the version in precise already?
[18:58] <mlankhorst> bryce: it's just a header change
[18:59] <bryce> mlankhorst, ok so < 8 changes in the git log?  that should be straightforward
[18:59] <mlankhorst> is 1 bug for all 3 good enough?
[18:59] <bryce> mlankhorst, in that case I think you can do it as just a regular SRU too.
[18:59] <bryce> all 3 what?
[18:59] <mlankhorst> x11proto packages
[19:00] <bryce> x11proto binary packages?  yeah sru's usually target the source package
[19:00] <mlankhorst> no it's separate, each proto has its own package :)
[19:01] <bryce> ah, duh, right.
[19:01]  * infinity frowns at mvo's apt SRU and all the vomit from using different autotools.
[19:02] <bryce> that's probably more down to personal preference.  I'd do separate SRU's for each package, since they're likely to get processed separately.  But I think it should be ok to do them all together.
[19:02] <infinity> Grr, and he also regressed the translations.
[19:02] <bryce> mlankhorst, if the changes are related in some fashion it makes sense to do one sru, since then you just have to write a single description
[19:03] <mlankhorst> yeah it would just be a copy paste 3x
[19:03] <bryce> mlankhorst, if each is going to need a separate test case, then maybe separate
[19:03] <mlankhorst> nah they're all used for the same
[19:03] <bryce> mlankhorst, yep so just one bug with tasks for each of the source packages affected
[19:05] <mlankhorst> yeah I'll do it tomorrow, eod for a while now :P
[19:05] <bryce> no prob
[19:06] <bryce> mlankhorst, hey, wanted to check in about how those synchronization rework patches are going?
[19:06] <infinity> mlankhorst: I'm going to have to re-do this apt SRU and un-regress the translations, but I'll get it up today for you, since mvo's not around for me to bug him. :P
[19:06] <mlankhorst> thanks!
[19:07] <bryce> mlankhorst, also on bug 1010794 wanted to see if you'd already done uploads for the nouveau fix for quantal-proposed and precise-proposed, and if not do you plan to do it?  (If not, I'll take care of it when I get a chance.)
[19:07] <ubottu> Launchpad bug 1010794 in xserver-xorg-video-nouveau (Ubuntu Quantal) "Graphics/text corruptions in some applications with nouveau drivers" [High,Triaged] https://launchpad.net/bugs/1010794
[19:08] <mlankhorst> bryce: I think it was rejected because xxv-nouveau 1.0.3 had a regression in one of its fixes
[19:09] <mlankhorst> it was fixed with 20995bb5920021668b8b607f886201c643ee0e9a
[19:10] <mlankhorst> bryce: the synchronization changes are going slow btw, but I'm trying to get things upstreamed now, it makes the rest easier at least..
[19:11] <bryce> mlankhorst, ok
[19:11] <bryce> mlankhorst, hmm bug 1010794 says fixed in sync of 1.0.4; does that already include that commit?
[19:11] <ubottu> Launchpad bug 1010794 in xserver-xorg-video-nouveau (Ubuntu Quantal) "Graphics/text corruptions in some applications with nouveau drivers" [High,Triaged] https://launchpad.net/bugs/1010794
[19:12] <mlankhorst> raring has it fixed
[19:13] <bryce> mlankhorst, ok.  and for precise and quantal, 20995bb5920021668b8b607f886201c643ee0e9a is the commit to be backported?
[19:14] <mlankhorst> not sure if it counts for precise, it's probably unaffected
[19:14] <mlankhorst> the corruption bug is only in xserver
[19:15] <mlankhorst> was only more noticeable on nouveau since it did more fallbacks
=== Tonio__ is now known as Tonio_aw
[20:21] <infinity> mlankhorst: apt for quantal reviewed and accepted, precise fixed and re-uploaded, just waiting on LP to spit out a diff for me to verify I didn't somehow break it while fixing mvo's upload. :P
[20:22] <mlankhorst> thanks, will verify tomorrow :-)
[20:22] <infinity> Shiny.
=== sraue_ is now known as sraue
=== robbiew is now known as robbiew-afk
=== salem_ is now known as _salem
=== mcclurmc_away is now known as mcclurmc
=== mcclurmc_away is now known as mcclurmc
=== cpg|away is now known as cpg
=== cpg is now known as cpg|away
[22:58] <doko> kees: exactly
[23:29] <doko> barry, what does the new distribute fix?
[23:30] <barry> doko: i am hunting down problems with virtualenv and python3.3.  i think this will fix it, though i also think the python-virtualenv package needs to be updated (which i'm working on, but upstream 1.8.2 is still broken)
[23:30] <doko> ahh, ok
[23:30] <barry> doko: and i need to get virtualenv working w/3.3 so tox will work, and i need tox to work so i can get piston_mini_client to work.  it's been a yak shaving day ;)