[02:02] <BenC> Can anyone give ghc a priority bump on the ppc buildd please?
[02:08] <StevenK> BenC: Link the build to me?
[02:08] <BenC> StevenK: https://launchpad.net/ubuntu/+source/ghc/7.4.1-4ubuntu1/+build/3646882
[02:08] <StevenK> BenC: Rescored.
[02:09] <BenC> StevenK: thanks!
[02:09] <StevenK> It dropped from 60 minutes to 26.
[02:15] <BenC> StevenK: quicker than expected, it started already
[02:27] <BenC> StevenK: if all goes well, this should clear out a huge chunk of FTBFS and dep-waits on ppc
[02:27] <StevenK> \o/
[02:28] <BenC> StevenK: any chance of an easy way to kick off rebuilds of all FTBFS on ppc matching .*haskell.* (once this is done)?
[02:29] <StevenK> A lot of clicking on LP? :-)
[02:29]  * BenC prepares his rebuild-clicker thingy
[02:35] <lifeless> api scripts should be able to, no?
[02:41] <hupahuper> Hello all! I had a quick question, I received an email back from submitting an app to the app showdown, and it said he made some changes and then "
[02:41] <hupahuper> I'll submit it for vote for inclusion in Ubuntu Extras."
[02:42] <hupahuper> I would assume this means I should take no action? However, the email also said, as part of the standard template, that I should make the changes and resubmit the application.
[02:43] <hupahuper> also, my status on myapps is Needs information. He said he posted the revised edition on a ppa which he linked, so should I resubmit and point to that ppa? Or merge, then resubmit with new ppa?
[02:45] <RAOF> hupahuper: I'm not familiar with the myapps process, and I suspect that most of the people in this channel aren't, either. As /topic says, I think you'll be better off in #ubuntu-app-devel
[02:45] <hupahuper> ah, sorry. Thanks!
[02:46] <RAOF> No problem!
[03:52] <pitti> Good morning
[04:07] <thinkndev> good evening
[04:08] <BenC> Good morning pitti
[04:27] <BenC> StevenK: Do builds automatically get accepted or is there some handling occurring on that end?
[04:33] <StevenK> BenC: It may be in NEW
[04:34] <BenC> StevenK: shouldn't be, nothing new in the package and it's accepted on i386 and amd64, but powerpc seems to be slow on the uptake
[04:34] <BenC> s/accepted/processed/
[04:35] <BenC> It's accepted for powerpc, just not published
[04:42] <StevenK> BenC: Ah, the publisher is blocked by generate-contents-files
[04:42] <BenC> Ah, thanks
[05:22] <Debolaz> Is wayland really going into 12.10?
[05:24] <Debolaz> Or was that just some wild rumor being passed around by the ignorant masses? :)
[05:24]  * Debolaz gets excited every time wayland is mentioned.
[05:25] <ScottK> Debolaz: The last two releases have had wayland.
[05:25]  * ScottK is sure the next one won't be any different.
[05:25] <Debolaz> ScottK: Let me rephrase it: Actually used in 12.10.
[05:25] <ScottK> By default, no.
[05:27] <RAOF> Actually, TBD.
[05:27] <RAOF> Still aiming for it, yes.
[05:28] <RAOF> Debolaz: See https://blueprints.launchpad.net/ubuntu/+spec/desktop-q-system-compositor
[05:28] <RAOF> That's not user- or developer-visible wayland, of course.
[06:49] <dholbach> good morning
[07:43] <Laney> http://paste.ubuntu.com/1085796/
[07:43] <Laney> should apt/dpkg be able to recover from this, or do I need to --reinstall?
[08:13] <jamespage> cjwatson, around? my seed change broken the tomcat server task - not sure I understand why based on our conversation on Monday
[08:35] <tvoss> doko, ping
[08:49] <pitti> hallyn: FYI, I reverted your libtiff5-dev cups change; that's not the right way; if we want to switch to libtiff5 by default, the "Provides: libtiff-dev" needs to be moved from 4 to 5 instead
[09:02] <cjwatson> jamespage: broke how?
[09:02] <jamespage> cjwatson, so I can see that germinate picked up the seed change OK
[09:03] <jamespage> but the ISO image build can't locate the tomcat7 packages
[09:03] <cjwatson> jamespage: oh, it's still in component-mismatches
[09:03] <jamespage> cjwatson, so the packages have to be in main before the ISO build will pick them up?
[09:03] <cjwatson> now, I don't particularly think it needs an MIR since it's just a new version; but you filed one and it is as yet unapproved
[09:03] <cjwatson> yes
[09:04] <jamespage> cjwatson, right - I misunderstood then
[09:04] <cjwatson> I'm a bit confused by your comment in the bug
[09:04] <cjwatson> "Jamie - When do you think you will be able to complete this review?"
[09:04] <cjwatson> but Jamie acked tomcat7 once tomcat6 is demoted
[09:05] <jamespage> cjwatson, jdstrand did give an initial approval for tomcat7 on the MIR - but I added an extra dependency to enable the test suites which has not been acked
[09:05] <cjwatson> ah
[09:05] <cjwatson> so, I can act on the movements to main as soon as the MIR bits are ready, but I can't process the MIR for you
[09:06] <jamespage> cjwatson, OK - I'll see what jdstrand says when he gets online but I expect the QA team will want this fixed
[09:07] <jamespage> so I will probably back out my seed change later today
[09:09] <xclaesse> hello,
[09:09] <xclaesse> does ubuntu installer support partitions on encrypted LVM nowadays? or should I still use the text-based installer?
[09:11] <xclaesse> also, will it do the partition alignment for SSD disks?
[09:15] <cjwatson> xclaesse: encrypted LVM> not yet; it's on the roadmap for 12.10, hopefully
[09:15] <cjwatson> xclaesse: SSD alignment should work in 12.04, except for GPT (known bug, fixed in 12.10, will hopefully be fixed in 12.04.1 or failing that 12.04.2)
[09:16] <xclaesse> cjwatson, and if I use the alternate installer to have encrypted LVM, will it align as well?
[09:17] <cjwatson> I think so, though there are a lot of layers in that case :-)
[09:20] <xclaesse> yeah luks, lvm, ext4 :)
[09:20] <xclaesse> googling, and it seems it's possible to do with ubuntu
[09:20] <xclaesse> thanks :)
[09:28] <seb128> cjwatson, hey, is there any progress on the ubiquity,daily iso test issues?
[09:34] <cjwatson> seb128: no, I tried reproducing them again yesterday and failed to reproduce even once
[09:34] <seb128> :-(
[09:35] <seb128> cjwatson, so what would help at this point? having the test setup to run ubiquity under --debug or something?
[09:35] <cjwatson> a way to improve the probability of reproducing it locally
[09:35] <cjwatson> I need further modifications beyond --debug
[09:36] <cjwatson> I mean I can keep randomly trying but it's not a very efficient use of time :-P
[09:36] <seb128> right
[09:37] <seb128> but we need to figure out something before rick kill us all :p
[09:37] <cjwatson> I'll have another go, but I don't really know what to say
[09:39] <cjwatson> when it's this hard to reproduce manually it seems like the priority ought to be adjusted down from OMGDROPEVERYTHING a bit
[09:42] <seb128> cjwatson, right, I agree with that, I just think rick or jason are going to come back at some point asking where we stand and what's the plan to get the issues resolved so I'm trying to figure what the answers to those questions are...
[09:42] <seb128> cjwatson, do we have any idea that is a real issue for users out of the test setup?
[09:42] <seb128> or we just don't have enough tracking,feedback to know that?
[09:42] <cjwatson> not really aside from errors.ubuntu.com and such
[09:46] <jasoncwarner_> hey cjwatson and seb128 , just catching up. can we at least revert the change(s) that are causing it until we have a way to reproduce it ?
[09:46] <cjwatson> jasoncwarner_: no
[09:46] <cjwatson> jasoncwarner_: there is no change I can identify as causing it
[09:47] <jasoncwarner_> cjwatson: ok....hmmm...when you say "hard to reproduce manually", are you saying you can't reproduce, or that it is a challenge to reproduce it?
[09:47] <cjwatson> none of the recent installer changes have been AFAICS remotely related, and most of them fixed other bugs that also showed up in QA so reversion would not be an improvment
[09:47] <cjwatson> *improvement
[09:47] <cjwatson> jasoncwarner_: I have been able to reproduce maybe twice out of about a dozen attempts
[09:47] <cjwatson> jasoncwarner_: unfortunately neither of those were with sufficient debugging enabled
[09:47] <cjwatson> so, I mean, if the answer is that I just sit here mindlessly retrying I can do that
[09:48] <cjwatson> but based on experience so far I won't be able to give a timeline with any degree of confidence
[09:49] <jasoncwarner_> cjwatson: or perhaps we can bring in some reinforcements? get more eyes on it?
[09:49] <cjwatson> well, feel free, although I'm not sure who else would be able to help
[09:50] <cjwatson> what I'm trying to do is to get logs with 'set -x' inserted just before the bit in /bin/hw-detect that asks the hw-detect/select_modules question
[09:50] <cjwatson> since that appears to be what's mysteriously bailing out
[09:51] <jasoncwarner_> cjwatson: would it be quick to document the steps so someone else could give it a go? seb128 would you be able to take a look if that were the case? and perhaps we can grab ev and maybe pitti if they can spare a few minutes?
[09:51] <cjwatson> I just documented the steps above :-)
[09:51] <cjwatson> oh, and run with 'ubiquity -d' as well
[09:51] <jasoncwarner_> cjwatson: always one step ahead ;)
[09:52] <cjwatson> I think it's kind of misdirected effort TBH, but well
[09:52] <seb128> cjwatson, it seems like the easiest way would be to get a package hacked to get whatever info we need and got it on an iso for the jenksys setup to run?
[09:53] <jasoncwarner_> cjwatson: why so? I'm generally uneasy about something that you can only sometimes reproduce.
[09:54] <cjwatson> it's not a failure that's showing up on errors.u.c, or one I can find any other reports of from actual people
[09:54] <cjwatson> so, sure, it's a bug and we should definitely fix it to clear our automatic reports, but I feel OMG-fix-now importance for it is overinflated
[09:55] <cjwatson> and I definitely feel any more than two people on it is distracting attention from more important things that are actually affecting humans
[09:55] <cjwatson> 
[09:55] <cjwatson> (grr)
[09:55] <jasoncwarner_> cjwatson: though, it is breaking out builds right now as well, which is bad for the daily quality stuff, though, I do agree that if we put too many people on it, that takes away from other things (the careful balance ;) )
[09:55] <cjwatson> it's not breaking our builds, it's breaking our jenkins tests, surely
[09:56] <cjwatson> not really the same
[09:56] <jasoncwarner_> cjwatson: ack on the mispeak
[09:56] <jasoncwarner_> cjwatson: do you suspect it might be tooling (aka the jenkins tests? )
[09:56] <cjwatson> it can't be solely that because I did manage to reproduce it albeit rarely
[09:56] <jasoncwarner_> (asking b/c you mention it isn't on errors etc)
[09:57] <jasoncwarner_> cjwatson: hmmm...what is the issue exactly anyway (probably should have asked that earlier ;) )
[09:57] <cjwatson> https://jenkins.qa.ubuntu.com/view/Quantal/view/ISO%20Testing%20Dashboard/job/quantal-desktop-amd64_default/79/
[09:58] <cjwatson> bug 1023036
[09:59] <cjwatson> ah, well, I can find one other report of it from a linux mint install in 2010 with a bunch of other errors before it
[09:59] <cjwatson> unlikely to be the same thing ...
[10:04] <jamespage> doko, I've raised MP's for both icedtea-web and openjdk-7 to delete/recreate the alternatives with a higher priority that openjdk-6; and to switch the Dependencies for icedtea-web to openjdk-7 where appropriate.
[10:04] <jamespage> would appreciate your review before I upload
[10:05] <jasoncwarner_> cjwatson: I guess its puzzling (or troubling might be a better word for it) that only 2/8 manual tests have produced it, but it seems the auto tests can reproduce it quite regularly?
[10:05] <cjwatson> somewhat regularly; it's not consistent even in autotests
[10:05] <cjwatson> would only be a small change in the probability of some race or other to produce such a result, I gues
[10:05] <cjwatson> s
[10:06] <jasoncwarner_> cjwatson: ok, so aside from adding more people looking at it, is there anything we can do for you at the moment?
[10:06] <jasoncwarner_> would you like one minion or so to try and reproduce with you?  ;)
[10:07] <cjwatson> I don't have any suggestions at the moment
[10:07] <cjwatson> I wish I did
[10:08] <seb128> cjwatson, what about what I said? if we get a package of an hacked ubiquity with logs details that could be useful and get it on an iso to throw to the jenkis?
[10:08] <cjwatson> seb128: that's a fair bit of work in itself, and it's not entirely clear to me that it will be useful because I don't know whether the logging I can think of so far will be sufficient
[10:09] <cjwatson> it's certainly a fallback measure, but I would prefer to continue manual reproduction attempts first
[10:09] <cjwatson> if we were going to do that I'd probably just upload extra debugging to quantal rather than bothering with building a separate iso :)
[10:09] <seb128> cjwatson, ok, is there anything special to do during the install, like is that specific to some options selected?
[10:09] <cjwatson> 10:50 <cjwatson> what I'm trying to do is to get logs with 'set -x' inserted just before the bit in /bin/hw-detect that asks the hw-detect/select_modules question
[10:09] <cjwatson> 10:51 <cjwatson> oh, and run with 'ubiquity -d' as well
[10:10] <cjwatson> the two times I reproduced it it was with all default options
[10:10] <seb128> cjwatson, right, I read that, I was just wondering if doing a standard full disk install with autologin is good
[10:10] <seb128> ok
[10:10] <seb128> I will try to fire a few vm installs and see if I can get it
[10:10] <cjwatson> ta, won't hurt
[10:11] <cjwatson> (that's what I've been doing since we started this conversation, too)
[10:42] <cjwatson> seb128,jasoncwarner_: well, I've uploaded a ubiquity version to quantal-proposed that adds a tiny bit more debugging, which will hopefully help
[10:42] <cjwatson> maybe
[10:42] <seb128> cjwatson, ok, I'm just done syncing isos, I will get that one in my vm and start test installs
[10:42] <seb128> cjwatson, thanks
[10:43] <cjwatson> I'll push through an updated CD build once that's all built and copied to quantal and published
[10:44] <cjwatson> IIRC jenkins automatically notices new image builds
[10:44] <seb128> it seems to do yes
[10:44] <seb128> it picked up the .1 isos yesterday
[11:07] <tvoss> doko, ping
[11:21] <tvoss> seb128, ping
[11:21] <seb128> tvoss, hey
[11:26] <seb128> tvoss, it's about bug #1006860? do you know if that patch got forwarded upstream?
[11:27] <seb128> cjwatson, there is something weird with that ubiquity update, it doesn't start for me (I downloaded ubiquity ubiquity-ubuntu-artwork ubiquity-frontend-gtk and did dpkg -i those)
[11:28] <cjwatson> seb128: ENOTENOUGHDATA
[11:28] <tvoss> seb128, no, I do not know. There was a comment on the bug saying that the ubuntu-reviewers team has been subscribed
[11:28] <cjwatson> seb128: Anyway I wasn't suggesting that you install those; it would be much quicker to edit /bin/hw-detect by hand ...
[11:28] <seb128> cjwatson, right, well I wanted to try those, will do that now
[11:28] <seb128> $ ubiquity -d
[11:28] <seb128> < 3 seconds wait>
[11:28] <seb128> $
[11:29] <cjwatson> /var/log/syslog /var/log/installer/debug
[11:29] <seb128> not sure what datas would be useful
[11:30] <seb128> cjwatson, http://pastebin.ubuntu.com/1086028/ syslog
[11:30] <seb128> cjwatson, http://pastebin.ubuntu.com/1086029/ debug
[11:31] <cjwatson> No sign of an attempt to start ubiquity 2.11.11 there
[11:31] <seb128> hum
[11:32] <cjwatson> I think the debconf db is in some kind of broken state.  Try from a fresh boot
[11:32] <cjwatson> In general running ubiquity multiple times without rebooting is not particularly well supported
[11:32] <cjwatson> Don't try it unless you're attempting to fix that :)
[11:32] <seb128> cjwatson, well sudo apt-get install ubiquity/quantal ... etc for the 3 binaries and it works again
[11:33] <seb128> but anyway I will downgrade and just hack the file by hand for the set -x
[11:33] <cjwatson> I'll worry about it if it happens to a fresh ISO built with that version
[11:33] <seb128> ok, fair enough, I prefered to mention it in case
[11:33] <cjwatson> Sure
[11:38] <seb128> tvoss, right, usually patches should be sent upstream as well if possible
[11:40] <tvoss> seb128, okay. So I reach out to the gdb guys, referencing the bug report and proposing the patch, right?
[11:40] <seb128> tvoss, correct
[11:40] <seb128> tvoss, thanks
[11:40] <tvoss> seb128, np
[11:46] <tvoss> seb128, hmmm, gdb points people back to the distribution
[11:46] <seb128> tvoss, why? our version is patched?
[11:46] <tvoss> seb128, that's the argument, right
[11:47] <seb128> tvoss, ok, thanks, I was just trying to be good upstream citizen, I will check out with doko when he's online or sponsor the patch later if he doesn't reply (not sure how much he's around or if he's a debconf this week)
[11:48] <tvoss> seb128, awesome, thanks. I will announce the patch together with a link to the bug report on gdb-patches, though
[11:48] <seb128> tvoss, thanks
[12:01] <mdeslaur> @pilot in
[12:43] <larsduesing> Ohm...
[12:45] <larsduesing> is in SRU queue, but doesn't show up in http://people.canonical.com/~ubuntu-archive/pending-sru.html
[12:45] <larsduesing> https://bugs.launchpad.net/ubuntu/precise/+source/aiccu/+bug/1007408
[12:45] <seb128> larsduesing, https://launchpad.net/ubuntu/precise/+queue?queue_state=1
[12:45] <seb128> larsduesing, the sru page only shows accepted SRUs
[12:46] <larsduesing> oh, ok..
[12:46] <seb128> larsduesing, the one you mention is waiting for review to be accepted
[12:49] <larsduesing> yes... I see...
[12:50] <larsduesing> thanks...
[12:55] <hallyn> pitti: mterry did ask cjwatson why libtiff-dev was on 4 instead of 5, I forget what the answer was
[12:56] <hallyn> pitti: are you saying all of the changes we've been making for libtiff4-dev->libtiff5-dev are wrong, or cups is special?
[12:58] <cjwatson> If I got that question I didn't understand it
[12:58] <cjwatson> If we're switching to libtiff5-dev I tend to think we probably ought to switch the Provides
[13:00] <hallyn> cjwatson: two days ago you added 'Provides: libtiff-dev' to tiff3 right?  perhaps i misunderstood
[13:00] <apw> do we not expect update-manager -d to allow upgrades yet ?
[13:01] <hallyn> pitti: oh, i see.  the ones which were 'libtiff-dev' should not be changed.
[13:03] <Laney> Well, they will be changed if you switch the provides.
[13:05] <cjwatson> hallyn: I didn't do anything
[13:05] <cjwatson> hallyn: All I did was sync both tiff and tiff3 directly from Debian; I made no Ubuntu-specific changes whatsoever
[13:06] <cjwatson> hallyn: tiff3 previously didn't exist; syncing it took over the libtiff4-dev binary package (and others) from what was previously built by the tiff source package
[13:06] <cjwatson> hallyn: So as far as the Provides goes, it was status quo
[13:06] <cjwatson> Changing libtiff-dev to libtiff5-dev, if anyone's been doing that, is certainly incorrect
[13:06] <hallyn> cjwatson: i see.  thanks
[13:07] <cjwatson> Changing libtiff4-dev to libtiff5-dev is merely arguable; it's probably better to make that libtiff-dev and switch the default
[13:07] <hallyn> cjwatson: i guess the nbs reports (which have since been removed) made me think that switching to libtiff5-dev was more urgent
[13:08] <hallyn> makes sense then, thanks
[13:08] <cjwatson> Those were only ever temporary; I'm sorry I didn't warn you, but I didn't expect the timing to be such that they'd show up on NBS at all
[13:10] <mvo> apw: generally yes
[13:10] <apw> mvo, didn't work for me, had to do it by hand
[13:15] <pitti> hallyn: "no change for libtiff-dev"> right
[13:18] <seb128> cjwatson, ubiquity refuses to bug for me as well, 5 installs, no error :-(
[13:18] <jdstrand> jamespage: bug #1009579 ACK'd
[13:18] <jdstrand> jamespage: do not my comments int he bug though :)
[13:19] <jdstrand> err
[13:19] <jdstrand> jamespage: do note my comments in the bug though
[13:20] <jamespage> jdstrand, thanks for the ack; I will feed back the delta to Debian (I'm the maintainer of that package anyway)
[13:20]  * jdstrand nods
[13:21] <jamespage> cjwatson, please can you dig me out of my tomcat-server seed change hole ^^
[13:21] <jdstrand> I can do that
[13:22] <jamespage> jdstrand, yes please
[13:22] <jdstrand> jamespage: you need an AA to promote jakarata-taglibs-standard?
[13:22] <cjwatson> And tomcat7
[13:22] <jamespage> jdstrand, both packages I think
[13:22] <mvo> apw: oohhh, the default is to do only lts -> lts at this point, need to look how to fix that via -d
[13:24] <jdstrand> cjwatson: I'm on it
[13:24] <apw> mvo, ahh that'd expalin a few things ...
[13:30] <jdstrand> jamespage: so, does this mean I can demote tomcat6?
[13:30] <jamespage> jdstrand, almost - I just need to complete the transition for packages which use libservlet2.5-java to libservlet3.0-java which should free it up
[13:30] <herton> @pilot in
[13:30] <jamespage> its packaging only so should not take to long
[13:31] <jamespage> (i.e. I will have it done this week)
[13:31] <jdstrand> jamespage: is there a bug filed on it?
[13:31] <jamespage> jdstrand, not yet
[13:31]  * jamespage add its to the list for this week
[13:31] <jdstrand> I'll file one real quick
[13:31] <jamespage> ah - thanks
[13:32] <ScottK> Is the apport retracer running?  https://bugs.launchpad.net/ubuntu/+bugs?field.tag=need-i386-retrace&orderby=-id&start=0 has shown the same 16 bugs for at least the last 12 hours.
[13:34] <dobey> for multiarch packages, does the -dev need to Pre-Depends on multiarch-support as well as the lib package?
[13:34] <seb128> ScottK, shrug, log is "2012-07-03 08:18 i386.txt"
[13:34] <seb128> ScottK, so I guess it's down for a week
[13:34] <seb128> pitti, ^ should I just remove the lock and see how it goes? there is no obvious error in the log
[13:34] <jdstrand> jamespage: fyi, bug #1023405. I assigned it to you but didn't milestone it or anything
[13:34] <seb128> ScottK, thanks for pointing it
[13:34] <jamespage> jdstrand, thanks
[13:35] <pitti> seb128: uh, sure; I thought I restarted it yesterday or so
[13:35] <pitti> seb128: if it's something permanent, it'll just fail again and then we can investigate
[13:35] <seb128> pitti, hum, that log is from 2012-07-03, i.e over a week untouched
[13:35] <seb128> pitti, if you restarted it yesterday do I overlook something?
[13:36] <pitti> seb128: apparently I just misremember then
[13:36] <seb128> pitti, ok, let me try to rm it
[13:36] <pitti> seb128: it looks like it just hung in the middle of retracing
[13:36] <mterry> Is there a part of dh_python3 or dh_python2 that mangles the shebang line at the top of scripts dropped in /usr/bin?
[13:36] <pitti> seb128: ah, the process is still running
[13:36] <pitti> seb128: I'll kill it
[13:36] <seb128> pitti, doh, I rm-ed the log by error
[13:36] <seb128> pitti, well it was only a log
[13:36] <seb128> pitti, thanks
[13:37] <pitti> seb128: ah, now I know -- I looked yesterday, saw the lock, checked ps, and saw that it was running
[13:37] <pitti> but I didn't look at the date
[13:38] <seb128> pitti, ev: does it affect errors.ubuntu.com stats in any way where a retracer is down for a week like that?
[13:38] <seb128> pitti, ev: if it does we should probably make sure we notice earlier when a retracer is stucked
[13:38] <pitti> seb128: no, errors.u.c. has its own set of retracers
[13:38] <seb128> ok, good
[13:38] <seb128> I hope they don't have similar issues ;-)
[13:38] <dobey> mterry: python3 setup.py install should change #!/usr/bin/python to be #!/usr/bin/python3 i think
[13:39] <dobey> mterry: but if you have "#!/usr/bin/env python" that breaks
[13:39] <mterry> dobey, I have env python3
[13:39] <ScottK> mterry: For dh_python3 in quantal as of yesterday.  I don't think anyone's merged python-defaults, so not yet.
[13:40] <mterry> And setup.py seems to be called with python3
[13:40] <mterry> ScottK, sorry, I don't follow
[13:41] <ScottK> If "#!/usr/bin/env python" is pointing to a python3 version, that's not right.
[13:41] <ScottK> The shebang rewriting is a new feature in dh_python2/3.
[13:41] <seb128> mterry, see changelog in http://packages.qa.debian.org/p/python-defaults/news/20120630T185419Z.html
[13:41] <ScottK> I sync'ed python3-defaults ~yesterday, so that's in quantal.
[13:41] <seb128> "- rewrite shebangs by default (disable via --no-shebang-rewrite),
[13:41] <seb128>        examples:
[13:41] <seb128>         + "/usr/bin/env python*" → "/usr/bin/python*""
[13:41] <ScottK> No one merged python-defaults yet (AFAIK), so I don't think dh_python2 does that.
[13:42] <seb128> ScottK, makes sense, mterry's case is a python3 one
[13:42] <ScottK> barry should do that merge though.
[13:42] <mterry> seb128, ScottK: I'm looking at update-manager, which during a build got translated from python3 to python, thus breaking it
[13:42] <seb128> ScottK, mterry: revelant upload is https://launchpad.net/ubuntu/+source/python3-defaults/3.2.3-1 for python3 then?
[13:43] <ScottK> seb128: Yes.
[13:43] <jdstrand> ScottK: just to be clear-- /usr/bin/python shouldn't ever be python3 (unless maybe all of the world is changed). Is that accurate?
[13:43] <ScottK> jdstrand: Something like that.
[13:43] <jdstrand> ok, that is what I thought
[13:44] <ScottK> Or you're Arch, but they're just crazy.
[13:44] <ScottK> mterry: Build log?
[13:44] <jdstrand> heh, it is a good thing I ported ufw then ;)
[13:45] <mterry> ScottK, https://launchpadlibrarian.net/109741274/buildlog_ubuntu-quantal-i386.update-manager_1%3A0.166_BUILDING.txt.gz
[13:46] <dobey> anyone have an answer to my multiarch question?
[13:46] <ScottK> dobey: No, it doesn't.
[13:47] <ScottK> mterry: And the problem is that there's a shebang re-written to /usr/bin/python?  Where?
[13:47] <mterry> ScottK, in /usr/bin/update-manager
[13:47] <dobey> thanks
[13:47] <mterry> ScottK, in the source, it is "#!/usr/bin/python3"
[13:48] <mterry> but becomes "#! /usr/bin/python"
[13:48] <ScottK> I agree that's unfortunate.
[13:48] <mterry> I'm testing with  --no-shebang-rewrite now
[13:49] <mterry> It looks like it's using python3 throughout, calling setup.py with python3 and all that
[13:51] <ScottK> Agreed.
[13:53] <mterry> ScottK, even with --no-shebang-rewrite, I still get the bug.  Do you know which code is responsible for the build log line "copying and adjusting update-manager -> build/scripts-3.2" ?
[13:53] <ScottK> I'm looking into it now.
[13:59] <cjwatson> gema: how long should it take jenkins to pick up the Ubuntu desktop 20120711.2 image build I did?
[14:01] <gema> cjwatson: not much, let me check
[14:01] <gema> cjwatson: are we talking quantal?
[14:01] <cjwatson> Yeah
[14:01]  * gema goes check
[14:01] <cjwatson> I figured I'd ask after an hour
[14:02] <gema> cjwatson: I am going to run the jobs manually, they don't seem to have started automatically
[14:03] <cjwatson> Right, thanks
[14:03] <gema> np, will keep you posted
[14:03] <ScottK> mterry: If you can try a build locally with a modified dh_python3, what happens if you change python to python3 in the SHEBANG_RE ... line (32) of debpython/tools.py?
[14:04] <mterry> ScottK, ok
[14:04] <ScottK> That RE is unchanged between dh_python2 and dh_python3, so I'm suspicious.
[14:07] <ScottK> Also there's a log message in the relevant function (fix_shebang), so using verbose might be helpful.
[14:09] <mterry> ScottK, that changed the shebang line to "#!/usr/bin/python" (still python but now no space after the shebang?)
[14:10] <ScottK> OK.  I'm still looking at it.
[14:10] <ScottK> Did you build with --verbose and did that yield anymore clues?
[14:11] <mterry> not yet, about to now
[14:14] <mterry> ScottK, http://pastebin.ubuntu.com/1086226/
[14:15] <mterry> ScottK, that is *without* the RE change
[14:15] <ScottK> OK
[14:15] <mterry> I'll make one with
[14:16] <apw> are we aware of a collision between ifupdown and netbase on /etc/init.d/networking ?
[14:16] <apw> (this is an upgrade P -> Q)
[14:18] <mterry> ScottK, http://pastebin.ubuntu.com/1086239/ is *with* the RE change, if it illuminates anything
[14:20] <mterry> Don't see the "replacing shebang" log line in either
[14:20] <ev> seb128: we don't have great failure notification on the errors.ubuntu.com retracers just yet, but webops tends to notice them going away.
[14:20] <ev> at some point soon I'll get them wired up to nagios
[14:21] <Laney> bah, just got hit by bug #1019999 again
[14:21] <Laney> remove errno? it seems subsumed.
[14:22] <ScottK> mterry: I'm not sure now what's doing it.
[14:22] <seb128> mterry, did you try to downgrade python3-defaults to see if that's coming from it?
[14:23] <mterry> ScottK, it seems python3 and dh_python3 both have shebang mangling code?
[14:23] <mterry> seb128, no, let me try that
[14:24] <ScottK> dh_python3 is part of python3.
[14:24] <apw> stgraber, hey .. i seem to have some fallout from the netbase/ifupdown breaks: stuff you did, seems to not be working right on upgrade ...
[14:25] <ScottK> mterry: I have a minimal test case.  fix_shebang in tools.py is definitely wrong.
[14:25] <mterry> ScottK, right.  But there seem to be two bits.  one in build_scripts.py and one in dh_python3
[14:25] <mterry> ScottK, ok, well that's good then
[14:26] <ScottK> But let's make sure we got the right thing.
[14:26] <stgraber> apw: ah? test upgrades worked fine here, though I had one bug report of someone with a bad mirror (missing one of the two packages)
[14:27] <apw> stgraber, i get this on upgrade direct from P to Q(today)
[14:27] <apw> dpkg: error processing /var/cache/apt/archives/ifupdown_0.7.1ubuntu1_i386.deb (--unpack):
[14:27] <apw>  trying to overwrite '/etc/init.d/networking', which is also in package netbase 5.0ubuntu1
[14:28] <seb128> cjwatson, did you read the discussion between ScottK and mterry?
[14:28] <seb128> --- 10/usr/lib/ubiquity/bin/ubiquity    2012-07-09 20:06:45.000000000 +0200
[14:28] <seb128> +++ 11/usr/lib/ubiquity/bin/ubiquity    2012-07-11 12:54:45.000000000 +0200
[14:28] <seb128> @@ -1,4 +1,4 @@
[14:28] <seb128> -#!/usr/bin/python3
[14:28] <seb128> +#! /usr/bin/python
[14:28] <udevbot> Error: "@" is not a valid command.
[14:29] <seb128> cjwatson, that's ubiquity 2.11.10 -> 2.11.11
[14:29] <seb128> cjwatson, I'm pretty sure that's why the update was busted for me
[14:29] <stgraber> apw: hmm, I guess ifupdown could use a Breaks statement... I just followed what Debian did (changing the version numbers to match), but just having Replaces: netbase (<< 4.00) seems wrong indeed
[14:29] <seb128> ScottK, mterry: ^ btw
[14:29] <mterry> hm
[14:29] <stgraber> apw: can you file a bug against ifupdown?
[14:31] <apw> stgraber, ack
[14:31] <apw> stgraber, so does that mean i should be upgrading netcore first, or removing it
[14:32] <stgraber> apw: you should be upgrading netbase first indeed, that'll make /etc/init.d/networking go away, then ifupdown can unpack and take that file over
[14:33] <mterry> seb128, ScottK: Downgrading python-defaults to 3.2.3-0ubuntu1 didn't help
[14:33] <cjwatson> seb128: oh, hah, thanks
[14:34] <seb128> cjwatson, yw
[14:34] <cjwatson> gema: ^- so that jenkins test will not be very useful - sigh
[14:34] <apw> stgraber, bug #1023437
[14:35] <gema> cjwatson: sorry!
[14:35] <stgraber> apw: netbase :) but thanks for the report, will look at it once I'm dong fighting with iscsi and meetings :)
[14:35] <cjwatson> gema: not your fault :)
[14:35] <ScottK> mterry: OK.  Then it's not the new rewriting feature.
[14:35] <gema> cjwatson: let me know whenever you want another run, the one ongoing will finish anyway
[14:36] <ScottK> I suspect it's the python3 distutils one.
[14:36] <apw> stgraber, fixed :)  if i try and install netbase it says it cant cause of the breaks
[14:36] <cjwatson> I assume there's no point in me debugging this from the ubiquity point of view?
[14:36] <ScottK> mterry: clearly debhelper thinks this is a python package and I think it's running the wrong distutils.  Something needs overriding.
[14:36] <mterry> ScottK, is there a known change in that code recently, that I can downgrade?
[14:37] <ScottK> that was the only one I knew of.
[14:37] <stgraber> apw: fun ;) can you try "apt-get install netbase ifupdown"? not sure if that'd be enough to give a hint to apt about the required ordering.
[14:37] <seb128> cjwatson, mterry ran into it with update-manager
[14:37] <seb128> cjwatson, I just though of ubiquity after, so no, I doubt ubiquity debugging is needed
[14:37] <mterry> seb128, well, technically cjwatson ran into it with update-manager.  He uploaded that one too.  ;)
[14:37] <seb128> cjwatson, it's likely to affect any package using python3
[14:38] <mterry> seb128, maybe if we downgrade cjwatson?
[14:38] <seb128> mterry, downgrade what source,binary?
[14:38] <stgraber> apw: I'm also quite surprised that this didn't show up in any of the automated upgrade tests or in my own upgrade tests, always fun to have bug depend on apt ordering (though this one at least is pretty obvious)
[14:38] <mterry> :)
[14:38] <apw> stgraber, nope the same.  if i am reading the errors right here, ifupdown _has_ to be upgraded first cause the new netcore breaks it, but ifupdown can't install cause netcore won't upgrade
[14:39] <apw> stgraber, ie it tries to update ifupdown first on its own and that fails
[14:39] <stgraber> apw: should be the other way around, ifupdown is now shipping a file that used to be in netbase, so netbase should unpack without configuring, then ifupdown should install, then netbase should configure
[14:39] <apw> stgraber, i guess i need to remove one or other, upgrade the other and reinstall it
[14:40] <cjwatson> mterry: update-manager?  Bah, I missed that
[14:40] <cjwatson> Has anyone looked at whether we'll need to scan the archive for this bug
[14:40] <mterry> cjwatson, it only is visible if you install the built binaries
[14:40] <cjwatson> ?
[14:40] <stgraber> apw: can't you downgrade to the precise versions of them? hopefully this bug will be fixed in a few hours
[14:40] <apw> stgraber, hmm, if netbase breaks ifupdown < 0.7 then it has to update ifupdown to >= 0.7 before it can install netbase ... right ?
[14:41] <cjwatson> apw: Before it can configure netbase
[14:41] <seb128> cjwatson, not yet, still trying to figure what update created the issue
[14:41] <cjwatson> Breaks allows unpacking the new netbase first, but not configuring it
[14:41] <seb128> cjwatson, I guess once we have it we need to figure what python3 packages got rebuilt
[14:41] <apw> stgraber, i can happily leave the machine as it is until its sorted
[14:42] <stgraber> apw: I can probably upload you a new ifupdown in a PPA based on what "should" be the fix, so if you can then test that, it'd save me some time trying to replicate the failure and testing the fix
[14:42] <apw> stgraber, sure the machine is bust as it is :)
[14:42] <ScottK> mterry: What happens if you override override_dh_buildsystems: to an empty value?
[14:42] <apw> stgraber, poke me when you get it done, no huge rush
[14:45] <mterry> ScottK, no help
[14:45] <ScottK> mterry: What's the log look like for that?
[14:45] <ScottK> (verbose)
[14:46] <stgraber> apw: uploaded to ppa:stgraber/foundation-build, add that PPA and test the upgrade again once it's done building. If that works I'll push to the archive.
[14:46] <apw> stgraber, ack
[14:46] <mterry> ScottK, http://pastebin.ubuntu.com/1086279/
[14:47] <mterry> ScottK, it should be easy enough to reproduce yourself.  apt-get source update-manager, then a debuild
[14:47] <mterry> ScottK, (I'm still looking, I'm just saying, for faster feedback)
[14:47] <ScottK> Sure.
[14:47] <ScottK> I'm trying to get some $WORK done here too though.
[14:48] <ScottK> BTW, that did make the log a lot better.  It's no longer trying to use python-support, for example.
[14:48] <ScottK> So that's a good change, regardless.
[14:48] <ScottK> Oh, nevermind.
[14:48] <ScottK> I can't read.
[14:51] <apw> stgraber, that version you uploaded is older than the archive it seems
[14:52] <mterry> In the logs, I see "py3versions: Command not found"
[14:52] <mterry> And then it installs files in 2.7 locations....
[14:53] <stgraber> apw: indeed...
[14:54] <ScottK> mterry: I had it a bit wrong.  It's override_dh_buildsystem:
[14:54] <ScottK> That yields some interesting errors.
[14:54] <mterry> ScottK, ah ok
[14:55] <stgraber> apw: it'd help if I used the quantal source instead of the precise source :)
[14:55] <Laney> dh_buildsystem is a thing?
[14:55] <cjwatson> It's new to me ...
[14:55] <Laney> I thought it was dh $@ --buildsystem=…
[14:55] <cjwatson> AOL
[14:56] <ScottK> Laney: That works too.
[14:56] <ScottK> I just wasn't sure if that'd work to unset it.
[14:57] <ScottK> Debhepler is picking python distutils (not python3 distutils) with it's buildsystem selection.
[14:58] <ScottK> auto_build, auto_clean, and auto_install are too.
[14:58] <ScottK> However, fixing all that, doesn't fix the shebang problem.
[14:59] <BenC> Today is the day powerpc becomes top dog on the ftbfs list…fear powerpc
[14:59] <Laney> I don't see a python3 thing in /usr/share/perl5/Debian/Debhelper/Buildsystem/
[14:59] <Laney> BenC: !!!
[15:00] <Laney> I saw your ghc fix. Can it be?
[15:00] <Laney> (did Erik confirm it?)
[15:01] <BenC> Laney: erikd says it didn't work on his G5, but I have a feeling he is hitting another bug…all my tests worked (and the G5 buildd's seem to like it)
[15:01] <tsdgeos> didrocks: can i make more noise about my libopenjpeg MIR?
[15:02] <didrocks> tsdgeos: talk to doko or jdstrand about it? I'm not involved at all into that MIR and don't really have the time to deal with it, sorry
[15:03] <didrocks> look at who is "assigned to"
[15:03] <tsdgeos> didrocks: oh, i thought you were, sorry
[15:04] <ScottK> mterry: It's the python3.2 distutils/command/build_scripts.py  that's triggering.  No idea why now.
[15:06] <tsdgeos> jdstrand: ping, can i make more noise about the openjepg MIR?
[15:06] <mterry> ScottK, hmm, doing this locally is picking up my python2 installation, so I'm getting a different log than on the buildd, where only python3 is installed
[15:06]  * mterry goes into a chroot
[15:07] <ScottK> mterry: "copying and adjusting update-manager" is where this shows up in the log.
[15:07] <mterry> yup
[15:07] <mterry> locally, that's being run by python2.7 build_scripts.py.  but on the buildd, it's python3.2's  (which still gets it wrong)
[15:08] <ScottK> mterry: You'll need to comment out the calls to dh_auto_build/install (not needed anyway, AFAICT) and add this:
[15:08] <ScottK> copying and adjusting update-manager
[15:08] <ScottK> Oops
[15:08] <ScottK> override_dh_auto_clean:
[15:08] <ScottK>         python3 setup.py clean -a
[15:09] <ScottK> Then you'll get a complete python3 build (that's in addition to the buildsystem change)
[15:09] <ScottK> It'll stil be busted though.
[15:09] <mterry> oh  :)
[15:15] <ScottK> It at least builds all the way through with only python3 though.
[15:16] <ScottK> My suspicions are shifting back to dh_python3 though.
[15:17] <ScottK> The update-manager in build/scripts-3.2 has the right shebang.
[15:18] <stgraber> apw: wow, looks like I was looking at an old debian/control all along, looking at what's actually in quantal, I'm not completely sure what's wrong. (ifupdown properly breaks/replaces the old netbase)
[15:18] <mterry> ScottK, ah good
[15:18] <apw> stgraber, anything else i can get you from the machine, or access to it or something
[15:19] <mterry> I see that too.  And working in a chroot, I get only python3 as well
[15:21] <ScottK> And, in fact, right before dh_python3 runs, it's still python3.
[15:22] <ScottK> And right after it runs, it's not.
[15:23] <stgraber> apw: reproduced here
[15:24] <apw> stgraber, this is an oddy as the error says "which is also in package netbase 5.0ubuntu1" but if i look at the .deb for that its not actually in there ...
[15:25] <stgraber> apw: yeah, conffiles are weird like that
[15:25] <seb128> ScottK, mterry: do you have a bug for the issue? some users are abusing bug #1013276 for the problems with the recent update-manager rebuild
[15:26] <ScottK> I don't.
[15:26] <mterry> seb128, no not yet.  didn't know which component to file it against yet  :)
[15:28] <stgraber> apw: I found an old e-mail from cjwatson to debian-devel covering what had to be done for ssh (similar moving conffiles around between packages). Though as we're moving to an upstart job, it's really quite unlikely that there's anything for the user to keep in there, so I might just end up checking the md5sum in netbase's new preinst, if it matches remove it, if it doesn't, move it to .dpkg-old
[15:29] <cjwatson> stgraber: the stuff in ssh was a workaround for a dpkg bug long since fixed
[15:29] <cjwatson> nowadays Replaces is supposed to be enough
[15:29] <cjwatson> if it's not I think we should be questioning whether something in dpkg has regressed
[15:31] <mterry> OK, it is fix_shebang
[15:31] <mterry> as you suspected
[15:31] <stgraber> cjwatson: right, just noticed that it's supposed to be fixed in dpkg...
[15:32] <stgraber> cjwatson: I'm not crazy in thinking that versioned (<< new-version-without-the-conffile) Breaks + Replaces should take care of it fine?
[15:32] <stgraber> cjwatson: (anyway, can talk post-meeting)
[15:33] <cjwatson> stgraber: I think that should; it's been a while since I attempted a conffile move
[15:33] <cjwatson> stgraber: I vaguely recall noticing some other problem recently which suggested something was wonky in this area in dpkg, but unfortunately I don't remember the details
[15:33] <stgraber> cjwatson: one trick is that the conffile is getting replaced by a symlink to /lib/init/upstart-job, not sure if that'd confuse dpkg somehow
[15:34] <cjwatson> Certainly possible
[15:35] <ScottK> mterry: Fixing the RE solves it.
[15:35] <ScottK> I think it was a mix of using python/python3 in the build and this error.
[15:35] <mterry> ScottK, yup, just reached that same conclusion
[15:35] <ScottK> I'll fix python3-defaults
[15:36] <ScottK> seb128 or mterry: Is there a bug number?
[15:36] <mterry> ScottK, awesome.  Uh, not yet.  I can file one real quick
[15:37] <mterry> ScottK, simple bug here: 1023474
[15:37] <mterry> bug 1023474
[15:38] <mterry> seb128, ^
[15:38] <seb128> mterry, ScottK: bug #1022994
[15:38] <mterry> guh ok
[15:38] <mterry> seb128, I thought you said that was the wrong bug
[15:38] <ScottK> mterry: Should be python3-defaults anyway.
[15:38]  * ScottK will use mterry's bug.
[15:38] <seb128> mterry, no, that one has been opened yesterday
[15:38] <seb128> mterry, the one I pointed was an older one
[15:38] <seb128> *pointed earlier
[15:39] <mterry> seb128, ok.  Well, if ScottK is using my bug, we can mark those as dups
[15:39] <ScottK> Both update-manager and python3-defaults need fixing.
[15:39] <seb128> mterry, right
[15:39] <mterry> ScottK, true, u-m and ubiquity need re-builds
[15:39] <ScottK> I suspect you'll find it's more than rebuilds.
[15:40] <ScottK> You need to make sure debhelper isn't helping you use python instead of python3.
[15:40] <seb128> ScottK, hum, what other sources need those special checks?
[15:40] <cjwatson> Pretty sure those two will just be rebuilds.  I was fairly careful.
[15:40] <mterry> ScottK, well, for update-manager at least, when it builds, it only has python3 installed
[15:41] <ScottK> OK.
[15:42] <ScottK> cjwatson: It may just be an artifact of not totally miminal chroots.
[15:42] <ScottK> uploaded in any case.
[15:44] <seb128> ScottK, what do you mean "artifact of not totally miminal chroots", building on a non minimal chroot shouldn't result in a buggy package for sure?
[15:45] <ScottK> If the debhelper auto buildsystem thing detects python distutils it'll use it.
[15:45] <ScottK> (not phython3)
[15:45] <ScottK> So if you don't override buildsystem, it'll build differently in python is installed.
[15:47] <seb128> hum
[15:48] <stgraber> cjwatson: one side effect of /etc/init.d/networking being a symlink is that it's not listed as a conffile in ifupdown...
[15:48] <seb128> that doesn't seem something reliable
[15:49] <ScottK> Agreed.
[15:50] <ScottK> Unfortunately no one has fixed the autobuild system thing to know about python3.
[15:50] <ScottK> There's a GSoC project to deal with building for all the python versions, but it's not done yet.
[15:50] <ScottK> (I think it's GSoC)
[15:50] <jdstrand> tsdgeos: it is on my todo list, I've replied in the bug
[15:51] <tsdgeos> jdstrand: not sure if your comment is "good" or "bad"
[15:52] <jdstrand> it is a statement of fact. there is a security history. a full review is pending, but likely not to happen super soon
[15:54] <tsdgeos> ok
[15:54] <mterry> ScottK, hah, funny that I got python-defaults vs python3-defaults wrong for this bug
[15:54] <tsdgeos> i understnad that''s a different way of saying no :d
[15:54] <ScottK> I fixed it.
[15:55] <mterry> yar
[15:55] <jdstrand> tsdgeos: it is not a NAK. as for the review, like I said, it is on my todo, just not at the top
[15:55] <tsdgeos> jdstrand: sure, i understand
[15:56]  * jdstrand nods
[16:00] <ScottK> FWIW, fixed in Debian too.
[16:14] <ScottK> mterry: My upload made the last publisher run, so you should be good to upload in ~20 minutes.
[16:14] <mterry> ScottK, awesome.  thanks for helping with this!
[16:21] <mdeslaur> @pilot out
[16:36] <dobey> does multiarch not work with cmake? i'm trying to set up a package for multiarch that uses cmake, but the libs still just go to /usr/lib in debian/tmp/
[16:37] <ScottK> dobey: phonon has been multiarched.  I think it uses cmake.  You might see what was done there.
[16:38] <dobey> ScottK: ok, thanks. i'll check it out
[16:41] <Laney> you'll probably have to prod some variables
[16:42] <dobey> yeah, looks like it adds -DLIB_SUFFIX=/$(DEB_HOST_MULTIARCH) to the cmake command
[16:43] <Laney> I don't think it's standard though, so you'll have to check out the cmake files in your project
[16:54] <dobey> ah, indeed. :-/
[16:54] <bdmurray> mterry: could you have a look at bug 1019650?
[17:07] <ScottK> Retracer is doing stuff now.  Thanks seb128 and pitti.
[17:07] <seb128> ScottK, thanks for pointing the issue, it was hanging for a week but nothing check for hanging processes, we just get emails when it hits an error
[17:08] <ScottK> Sounds suboptimal.
[17:08] <seb128> yes
[17:20] <mterry> bdmurray, I believe that is already fixed.  let me comment in bug
[17:51] <bdmurray> mterry: I ran into that bug with the lastest version of update-manager 0.166
[17:53] <mterry> bdmurray, ...  OK...  But that code doesn't even exist anymore
[17:53] <mterry> :(
[17:55] <mterry> bdmurray, actually, I'm suspicious.  Since 0.166 doesn't even run
[18:40] <bdmurray> mterry: okay it looks to me like it was an issue with update-manager being updated and the version number not matching what had been running
[18:40] <bdmurray> mterry: there is an apport bug about that
[19:24] <stgraber> cjwatson: apparently hardcoding /etc/init.d/networking in ifupdown.conffiles makes dpkg DTRT. Upgrading from precise to quantal with a clean /etc/init.d/networking leads to it being a symlink to /lib/init/upstart-job. Doing the same with an updated file triggers the conffile prompt, if the user chooses to keep their changes, then /etc/init.d/networking is kept as a regular file.
[19:25] <stgraber> cjwatson: I was a bit worried dpkg would somehow mangle /lib/init/upstart-job in that case but apparently it doesn't. Can you see anything else that could go wrong with this approach?
[19:29] <primepie> I installed gnu lib readline  ... and I noticed it got installed in /usr/lib/x86_64-linux-gnu  .. I wrote a simple program that calls using_history() and tried to compile it with -lreadline -lhistory but it still says undefined reference to `using_history'
[19:30] <jtaylor> primepie: likely an ordering issue, libraries must be after objects needing them
[19:31] <jtaylor> primepie: e.g. gcc object.c -lreadline, not gcc -lreadline object.c
[19:31] <primepie> jtaylor: didn't make a different
[19:31] <primepie> difference
[19:32] <primepie> jtaylor: http://pastebin.com/LFKqkFQM this is the program
[19:32] <primepie> it compiles on ubuntu 10 but not on 12
[19:32] <jtaylor> then its an ordering issue
[19:32] <jtaylor> whats the commandline your are using to compile?
[19:33] <primepie> gcc test.c -lreadline -o test
[19:33] <jtaylor> I can'T reproduce it
[19:33] <primepie> jtaylor: nm .. it is.. the Makefile in the 2 machines are different
[19:33] <primepie> my fault
[19:35] <mterry> pitti, did you mean to overwrite the tiff5 change in cups, or shall I put that back?
[19:36] <mterry> (assuming you were the one that sync'd it)
[19:36] <Laney> 11/07 09:49:48 <pitti> hallyn: FYI, I reverted your libtiff5-dev cups change; that's not the right way; if we want to switch to libtiff5 by  default, the "Provides: libtiff-dev" needs to be moved from 4 to 5 instead
[19:37] <mterry> guh, hmm
[19:38] <Laney> It does seem like that's what you're trying to achieve (changing the default)
[19:38] <Laney> so you should probably just do that
[19:39] <mterry> yeah, but I figured the set of changes was small enough to just do it manually, since a lot of them specifically mentioned tiff4 anyway
[19:39] <mterry> we were only targetting main
[19:39] <mterry> that way we could avoid a delta on the tiff packages (albeit adopting a delta on some others0
[19:40] <Laney> Pretty sure Debian will switch after wheezy anyway
[19:40] <mterry> they will
[19:41] <mterry> guh, so close, only a few packages left to do.  but I'll defer to pitti here
[19:42]  * mterry looks into moving the Provides
[19:44] <hallyn> mterry: (mind you the revert was demotivating but) for the sake of what we're doing, is it worth moving the provides ourselves?
[19:44] <hallyn> or are we mainly just wanting to make sure that anything explicitly depending on libtiff4-dev gets fixed?
[19:45] <hallyn> i suppose changing it now will help catch any potential errors that would otherwise happen whenever tiff3 was removed
[19:45] <mterry> hallyn, my goal was to be able to move to only having the stable version of tiff in main
[19:46] <Laney> I just pushed a transition tracker file
[19:46] <mterry> hallyn, so if pitti is requesting that we not patch libtiff-dev -> libtiff5-dev, we can move the Provides and still fix the ones that specifically mention libtiff4-dev (probably to just libtiff-dev now, instead of libtiff5-dev)
[19:46] <hallyn> mterry: i see
[19:46] <Laney> you should get to see how a proper transition would look next time it generates
[19:47] <hallyn> mterry: yup
[19:47]  * hallyn doesn't now what a transition tracker file is
[19:47] <mterry> Laney, thanks.  I still don't know the magic behind those transition reports
[19:47] <hallyn> is it like a little robot-bug that gets inserted through your stomach?
[19:47] <Laney> https://bazaar.launchpad.net/~ubuntu-transition-trackers/+junk/transition-tracker/view/head:/ubuntu/monitor/tiff.ben
[19:49] <hallyn> cool
[19:56] <scientes> how do i restart udev?
[19:57] <scientes> after i trashed my /dev
[20:20] <cjwatson> stgraber: cool, that sounds plausible enough then ...
[20:35] <mterry> Laney, can you add http://pastebin.ubuntu.com/1086827/ to the transition tracker for me?
[20:36] <Laney> oui
[20:36] <mterry> danke!
[20:37] <Laney> did you mean to miss armhf out?
[20:39] <mterry> Laney, oh hah, no.  I still forget about armhf
[20:39] <Laney> tsk tsk
[20:43] <Laney> mterry: there you go, should be there next run
[20:43] <mterry> Laney, thanks!
[21:02] <herton> @pilot out
[21:12] <stgraber> apw: uploaded a new ifupdown to the archive, it looks like it's working fine here but I'm not particularly happy with the hack. Let me know if it works/doesn't for you.
[21:12] <apw> stgraber, thanks will do
[21:17] <apw> stgraber, appreciate your efforts fixing it
[21:19] <stgraber> apw: np. it's the kind of thing I prefer to fix now than see show up on some QA report a week before release ;)
[21:19] <apw> stgraber, now there is that for sure
[21:28] <stgraber> stokachu: could you link the merge proposal with bug 977947? it's not trivial to find it from that bug :)
[21:45] <infinity> stgraber: Oh, I didn't even stop to think that it's a symlink in Ubuntu.
[21:46] <infinity> stgraber: That kinda explains the bug entirely.
[21:47] <stgraber> infinity: yeah, apparently that confuses dpkg a bit ;)
[21:48] <infinity> stgraber: That *might* be a dpkg bug.  Maybe.
[21:48] <infinity> stgraber: But it's a pretty odd corner case.
[21:49] <stgraber> I'm just wondering there won't be a weird side effect of my fix I didn't think of, was kind of scared of a side effect like dpkg writing to /lib/init/upstart-job, putting the old networking script content in there or something (though testing showed that it seems safe)
[21:49] <stgraber> s/wondering/hoping/
[21:49] <infinity> There could be weird side effects, but not that level of weird.
[21:52] <stgraber> infinity: opened a task against dpkg so we don't loose track of it
[21:54] <infinity> stgraber: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=421344
[21:54] <infinity> stgraber: You may trip on this.
[21:55] <infinity> stgraber: And if THAT bug has been accidentally fixed along the way, some mention of that would be nice. ;)
[21:57] <infinity> stgraber: Though, I suspect that if your hack is working for you, the only reason is because it's also part of a Replaces file migration, which then skips some of the normal conffile handling.
[21:57] <infinity> stgraber: *hand wavy too lazy to trace the code right now response*
[21:58] <stgraber> infinity: sounds like http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=421346 is about implementing my "hack" automatically in debhelper (considering symlinks in /etc as being conffiles)
[21:59] <infinity> stgraber: Yes, but it's blocked by the dpkg bug.
[22:00] <stgraber> but yeah, sounds like dpkg doesn't handle them terribly well at the moment, though I suppose I'm fine as long as we don't move /etc/init.d/networking to another symlink pointing somewhere else (which I'm certainly not planning to do :))
[22:22] <apw> stgraber, hey, the new ubuntu2 version seems to let me continue the upgrade
[22:22] <stgraber> apw: cool
[22:44] <BenC> StevenK: Can you bump this for me, please: https://launchpad.net/ubuntu/+source/ghc/7.4.1-4ubuntu2/+build/3649402
[22:45] <BenC> It's gone from 40 minutes to an hour
[22:45] <BenC> err, 2 hours
[22:45] <StevenK> BenC: Haha, needs more fixing? Now 6 minutes.
[22:46] <BenC> The last fix worked partially, needed one more to make it perfect
[22:47] <BenC> StevenK: thanks
[22:47]  * BenC wishes for Build score powers
[23:08] <unixpro1970> Where is linux-vdso-so located?
[23:09] <RAOF> unixpro1970: It's not; it's a virtual shared object (which is what the ‘v’ stands for).
[23:10] <unixpro1970> Then how can I generate it?
[23:10] <RAOF> It's provided by the kernel
[23:10] <unixpro1970> Or use it?
[23:11] <unixpro1970> Thanks ROAF, must I use a command line parameter when compiling to make it work.
[23:11] <RAOF> AFAIK it's an entirely transparent optimisation. If it *isn't* entirely transparent, it's only used in libc.
[23:11] <unixpro1970> So is the solution include libc?
[23:11] <geofft> http://www.trilithium.com/johan/2005/08/linux-gate/
[23:11] <unixpro1970> to include
[23:34] <unixpro1970> okay,thanks guys.