[03:01] <kenvandine> any archive admins around that can look at some packages in binNEW that are holding up builds?
[03:18] <AbsintheSyringe> cjwatson, about recent talks about "slashdot" releasing false claims that ubuntu was moving to rolling releases, this is what I had in my mind when I supported this idea of being future for all linux platforms not just ubuntu http://theravingrick.blogspot.com/2010/11/ubuntu-is-not-moving-to-rolling-release.html
[03:18] <AbsintheSyringe> google picked it up
[07:03] <didrocks> good morning
[07:04] <axp2> Hi didrocks
[07:04] <didrocks> hey axp2
[07:04] <axp2> Or good afternoon
[07:45] <dholbach> good morning!
[08:00] <didrocks> hey dholbach!
[08:01] <dholbach> salut didrocks
[08:01] <cdbs> Hi dholbach !
[08:02] <dholbach> heya cdbs
[08:05] <dholbach> pitti, james_w: could it be that the workitems tracker is a bit broken right now?
[08:05] <dholbach> it tells me that we have all kinds of unknown milestones
[08:17] <cdbs> Can someone please look at bug #688002 and its attached patch? Currently the hplip package is uninstallable and broken. This patch fixes it. Thanks!
[08:20] <cdbs> s/uninstallable/non installable/
[08:24] <cdbs> its a debdiff
[08:42] <tumbleweed> tkamppeter: cdbs's fix isn't right
[08:44] <pitti> good morning
[08:45] <pitti> ScottK: kdegraphics> built now
[09:01] <micahg> pitti: could you please take a look at bug 685421
[09:09] <pitti> micahg: ah, thanks; will respond in the bug report
[09:11] <micahg> pitti: thanks
[09:14] <pitti> micahg: I'll get to it today
[09:14] <pitti> dholbach: yes, over night I got tons of cron mail from it; I'll have a look later on
[09:15] <micahg> pitti: great, thanks, let me know if there need to be any rebuilds because of it, I'll be happy to help
[09:15] <dholbach> super
[09:15] <pitti> micahg: I'll care about hedgewars; if you see another one being affected, feel free to upload a rebuild once the fixed mangler is in natty
[09:16] <micahg> pitti: ok, I was just wondering if there's any way to tell if something would've been affected
[09:16] <pitti> micahg: not without actually trying to run the game, I think
[09:16] <micahg> I'll keep an eye out for bugs though
[09:17] <pitti> but I guess we should hear about the games people care about
[09:29] <ev> @pilot out
[09:55] <pitti> ogra: I can't help it, but kiko's mugshot on https://launchpad.net/~kiko just looks like you
[09:58] <cdbs> @pilot in
[09:58] <cdbs> :)
[09:58] <dholbach> cdbs, woohoo!
[09:58]  * dholbach hugs cdbs
[09:58] <dholbach> hey sabdfl
[09:59]  * cdbs hugs dholbach 
[09:59] <sabdfl> good morning, /hugs back :-)
[09:59]  * cdbs hugs sabdfl 
[09:59] <sabdfl> prescience
[09:59] <dholbach> cdbs, thanks for patch piloting
[10:00]  * dholbach hugs sabdfl too
[10:00] <sabdfl> i love visiting here, /hugs dholbach
[10:00] <dholbach> :-)
[10:00] <cdbs> dholbach: yup, but there's barely anything in the sponsor queue for universe packages
[10:00] <cdbs> :)
[10:00] <dholbach> http://reqorts.qa.ubuntu.com/reports/sponsoring-stats/ looks GOOD if you ask me :)
[10:01] <cdbs> Its like the stock market during the recession :D
[10:01] <tumbleweed> cdbs: you can also help pilot things that you don't have upload rights for
[10:01] <cdbs> tumbleweed: which is what I am doing ATM
[10:01] <dholbach> the sponsoring queue is getting emptier, but we still have LOADS of patches sitting in launchpad
[10:01] <dholbach> and branches for that matter :)
[10:02] <cdbs> yup, UDD merges need attention
[10:02] <dholbach> I hope that harvest can help with that in the future: http://harvest.ubuntu.com/opportunities
[10:02] <dholbach> and people will pick up opportunities when doing an upload anyway
[10:05]  * dholbach releases a new harvest
[10:11] <pitti> james_w: what was the rationale of this "extra-projects" branch? if there are blueprints which aren't against the ubuntu project for linaro, why not just track them in a separate linaro.cfg and output?
[10:11] <pitti> james_w: otherwise we'll have to either ignore one set of milestones, or merge them, which is also confusing (and would break the auto-reset, etc.)
[10:39] <Riddell> cdbs: aren't I ment to be the patch pilot today?
[10:39] <dholbach> Riddell, there can be more than one :)
[10:39] <cdbs> Riddell: I think many people can patch pilot at once
[10:40] <Riddell> @pilot in
[10:40] <dholbach> woohoo!
[10:40]  * dholbach hugs Riddell
[10:40]  * cdbs hugs Riddell 
[10:40] <cdbs> though this channel topic just hit its maximum char limit
[10:41] <cdbs> Riddel is written, not Riddell
[10:41] <cdbs> I think it would be good to remove the Natty GDM login broken thing
[10:41] <seb128> you can drop the natty gdm login issue
[10:52] <cdbs> tkamppeter: Thanks for those uploads :)
[11:00] <cjwatson> hallyn_: I switched to quilt for later versions of grub2, but if you're looking at lucid then yes it's cdbs-edit-patch
[11:01] <cjwatson> kenvandine: it helps if you give specific package names when asking that sort of thing
[11:01] <cjwatson> no idea what to prioritise here
[11:03] <seb128> cjwatson, what did kenvandine ask to do?
[11:08] <cjwatson> 03:01 <kenvandine> any archive admins around that can look at some packages in binNEW that are holding up builds?
[11:08] <seb128> cjwatson, ok, pîtti sorted it since
[11:08] <seb128> it was libdbusmenu I think
[11:09] <cjwatson> ok
[11:11] <ogra> pitti, you mean like http://www.grawert.net/230405_030.jpg ?
[11:11] <ogra> (sorry, missed to scale it down)
[11:13] <pitti> ogra: 'zactly :)
[11:14] <ogra> *g*
[11:17] <cdbs> g2g, did some patch-piloting on -motu
[11:18] <cdbs> and elsewhere
[11:18] <cdbs> @pilot out
[11:34] <Q-FUNK> is anybody taking care of doing a rebuild upload for eog and gedit?  they seem to be the last two bits of gnome that use python2.6 here.
[11:34] <Q-FUNK> I can only upload to main for one package, so I cannot act upon these myself.
[11:36] <Laney> seb128: ^^^
[11:38] <seb128> Laney, thanks
[11:52] <kenvandine> cjwatson, doko_ did it fo me last night
[11:52] <kenvandine> s/fo/for
[11:54] <mbiebl> superm1: hi
[11:54] <mbiebl> superm1: you wrote the upstart job for mysql?
[11:58] <mbiebl> looks like there is a race condition on shutdown
[11:58] <mbiebl> mysql.conf has stop on runlevel [016]
[11:59] <mbiebl> I have /var/lib/mysql on a separate partition
[12:01] <mbiebl> and the rc.conf job is basically run at the same time on shutdown as the mysql.conf job
[12:01] <mbiebl> as shutting down mysql takes quite a bit of time here, the umount scripts try to unmount /var/lib/mysql before mysqld is down
[12:01] <mbiebl> that leads to a correupted fs on every boot
[12:02] <mbiebl> superm1: want a bug report for that?
[12:04] <mbiebl> seems other jobs have the very same problem (dbus, rsyslog) but probably nobody noticed because stopping those jobs should be rather quick
[12:14] <mbiebl> So I'd say it is a general problem of using "stop on runlevel [016]" because it is not race-free
[12:54] <sladen> rickspencer3:
[13:09] <didrocks> jdstrand: hey, can you binary new unity-common please?
[13:10] <doko> james_w: how do I make sure that I get the unmodified upstream tarball for merge requests? e.g. #685180
[13:17] <jdstrand> didrocks: hey, sure
[13:17] <didrocks> jdstrand: thanks :)
[13:24] <jdstrand> didrocks: done
[13:24] <jdstrand> didrocks: fyi, only i386 was needed, the other three were already accepted
[13:25] <pitti> jdstrand: (it's presumably an arch-all package, and thus only gets built on i386)
[13:25] <didrocks> jdstrand: it's arch:all, hence only i386 :)
[13:25] <jdstrand> oh duh
[13:25] <jdstrand> that is precisely it
[13:25] <didrocks> :)
[13:25]  * pitti ^5s didrocks
[13:26]  * didrocks ^5s pitti back
[13:26] <pitti> jdstrand: thanks
[13:26] <didrocks> jdstrand: thanks a bunch ;) you will make a lot of user happy with intellihide available now :)
[13:26] <jdstrand> nice!
[13:28] <fbond> c
[13:29] <pitti> didrocks: no more fiddling in ccsm to get rid of it? indeed!
[13:30] <didrocks> pitti: it's not the default yet, will be next week normally. You still have to enable autohide :)
[13:31] <didrocks> (autohide is now "intellihide" even if the name of the option is the same)
[13:31] <pitti> didrocks: a day, a week, doesn't matter; I'm just happy to see the feature
[13:31] <didrocks> :)
[13:31] <didrocks> I recommend particularly the new effect on minimize now, with the launcher visible
[13:32] <pitti> didrocks: in classic gnome my screen "overhead" is just the top panel right now; with that, we're getting back to that state
[13:32] <didrocks> pitti: exactly
[13:36] <udienz> hello ubuntu-devel
[13:36] <udienz> i have merge proposed
[13:37] <udienz> https://code.launchpad.net/~udienz/ubuntu-docs/natty-ubuntu-docs.fix677998/+merge/42857
[13:37] <udienz> fixing #42857
[13:37] <udienz> bug 42857
[13:39] <udienz> and here https://code.launchpad.net/~udienz/ubuntu/natty/aspell-en/aspell-en.fix687483/+merge/43124
[13:39] <udienz> my pleasure if you want to reviewing it
[13:41] <Daviey> doko: I don't suppose you have thoughts on bug #688522?  It's pretty urgent, that one :/
[13:41] <Daviey> doko: I wondered if we need something similar to http://icedtea.classpath.org/hg/release/icedtea6-1.8/file/eab926d1eb04/patches/openjdk/6650759-missing_inference.patch
[13:53] <G__81> is there a separate channel for unity where in i could submit patches etc to unity ?
[13:54] <beuno> G__81, try #ayatana
[13:54] <G__81> ok
[13:58] <cjwatson> Riddell: why did you merge the patch in bug 686607?  I already followed up to the merge review asking for it to be sent upstream instead, and wanted to wait for a response there.
[13:58] <cjwatson> not happy about that, really
[13:59] <cjwatson> it's a low-priority bug, we don't need to rush on it
[14:01] <Riddell> cjwatson: oh sorry, I saw that it had been submitted upstream and thought that would satisfy your request
[14:02] <cjwatson> as I said in the merge request, I'm generally trying to reduce the number of distribution-specific patches we carry.  openssh upstream often doesn't accept patches anything like verbatim
[14:03] <cjwatson> and if they don't accept it I have the choice between carrying the patch forever, or regressing, either of which is worse than not applying the patch to start with
[14:06] <cjwatson> doko: taking bug 687488
[14:08] <james_w> pitti, because linaro has blueprints spread over multiple projects, and we would like to track them together
[14:08] <pitti> james_w: I updated the merge proposal with some details
[14:08] <james_w> thanks
[14:10] <james_w> pitti, which merge proposal? I don't see your comments on either of mine
[14:12] <james_w> oh, found it
[14:12] <pitti> james_w:
[14:12] <pitti> https://code.launchpad.net/~james-w/launchpad-work-items-tracker/multi-project/+merge/43221
[14:15] <doko> cjwatson: thanks
[14:20] <james_w> doko, if you do a "bzr builddeb -S" in that branch, you can compare the checksum in the .dsc with the upstream one
[14:23] <doko> lamont, cjwatson: we need an update of the chroots. every build still has python2.6-minimal installed, which lets builds fail ...
[14:23] <doko> james_w: thanks
[14:24] <lamont> doko: awesome
[14:24] <lamont> doko: so I assume you'd like that "now"?
[14:24] <doko> :-) well, it's just failing builds
[14:25] <doko> lamont: does python2.6-minimal need the priority changed for that (still required)?
[14:27] <lamont> I'll tell you in a few min
[14:29] <lamont> doko: shure looks like debootstrap grabs required and base..., and it defintitely grabbed python2.6-minimal
[14:29] <lamont> so... fix that and poke me when it's clear?
[14:29] <doko> ok
[14:30] <cjwatson> also python2.6 -> standard
[14:30] <cjwatson> and python2.7-minimal -> required, python2.7 -> important
[14:30]  * lamont wanders off for a few
[14:30] <doko> standard? not optional?
[14:30] <cjwatson> http://people.canonical.com/~ubuntu-archive/priority-mismatches.txt
[14:30] <cjwatson> except that much of that should be ignored due to the temporary python2.6-dev dependency
[14:31] <cjwatson> I assume something in standard still wants python2.6.  it'll drop out once the rebuilds complete, probably
[14:34] <lamont> The following packages will be REMOVED:
[14:34] <lamont>   python2.6-minimal
[14:34] <lamont> 0 upgraded, 0 newly installed, 1 to remove and 0 not upgraded.
[14:34] <lamont> cjwatson: ^^
[14:34] <cjwatson> ack
[14:34] <chrisccoulson> does anyone have any idea why this link fails: http://paste.ubuntu.com/541643/
[14:34] <chrisccoulson> i've tried pretty much everything i can think of now, and still can't get it to work :/
[15:07] <cr3> cjwatson: to follow up on yesterday, might you have a bug number for the mac_address feature request to d-i?
[15:07] <jcastro> mdz: do you have a method of updating the brainstorm ideas to point people to the answers?
[15:08] <jcastro> and also resolving the ideas when they've been reviewed?
[15:09] <cjwatson> cr3: bug 56679
[15:09] <mdz> jcastro: I don't; is that something you could help coordinate?
[15:10] <jcastro> I can do them all now.
[15:10] <mdz> jcastro: awesome, thanks
[15:11] <jcastro> mdz: I just update the status and add a link in the developer response area so I can just take that recurring WI
[15:17] <mdz> jcastro: cool, I'll mention that to the TB for future editions
[15:23] <ogra> pitti, i'm getting WI tracker spam like " [WARNING] milestone "natty-alpha-2" is unknown/invalid" same for ubuntu-11.04-beta and ubuntu-11.04 milestoned specs ... any idea why ?
[15:23] <pitti> ogra: please ignore, I fixed this this moring
[15:23] <ogra> ah, thanks
[15:31] <pitti> erm, bzr, where are thou? "ImportError: No module named bzrlib"
[15:31] <pitti> doesn't work with python2.6 either
[15:32] <pitti> but the package ships it for both versions, hmm
[15:36] <jdstrand> I've got a bit of an emergency security update I need to work on and my archive admin duties will be likely postponed (I typically focus on NEW). if anyone really needs something deNEWed today, feel free to ping me
[15:47] <cjwatson> doko: what's happening with bug 605042?  last comment from you was moving it to maverick-updates
[15:48] <cjwatson> mvo: what more is needed to close bug 671016?  just getting the new page written?
[15:49] <doko> cjwatson: I think this is still blocked on the kernel side. I don't know what I can do more than backing out this upstream change
[15:51] <cjwatson> bjf: could you please look at bug 605042?  see above
[15:57] <mvo> cjwatson: yes, the page is missing, a bit more testing and then it should be done.
[15:58] <bjf> cjwatson, afraid i've not done arm for a couple cycles now and have no HW
[15:59] <dvanstone> how do I add a disk that was solo to current boot options
[15:59] <cjwatson> bjf: who should be responsible for that bug?  it's assigned to canonical-kernel-team but nobody has taken responsibility
[15:59] <cjwatson> bjf: and it's blocking something that the foundations team is being asked about every release meeting
[16:00] <bjf> cjwatson, well, we lost our ARM devs to linaro, i'll send some email and see if I can get it on someones radar (will cc you)
[16:00] <cjwatson> thanks
[16:01] <cjwatson> given that this is the hardware that runs our buildds on the LTS release, we have to be able to support those kernels somehow
[16:06] <cjwatson> lamont: are the chroots updated now?
[16:07] <lamont> cjwatson: was in a meeting.  kicking things now
[16:14] <lamont> cjwatson: debootstrap --variant=buildd still gives python2.6-minimal in the resulting chroot
[16:15] <cjwatson> doko changed that I believe, maybe it hasn't finished publishing yet
[16:15] <cjwatson> that would be odd though
[16:15] <cjwatson> I've given it a kick
[16:15] <cjwatson> should be available in <1.5 hours
[16:16] <doko> was just published with the last publisher run. amd64, i386, powerpc, but not yet armel
[16:16] <cjwatson> /home/lp_archive/ubuntu/indices/override.natty.main:python2.6-minimal   required        python
[16:16] <cjwatson> disagrees
[16:16] <doko> cjwatson: does the overwrites file need patching?
[16:17] <cjwatson> I ran change-override.py
[16:17] <cjwatson> did you try to upload to fix that?
[16:17] <doko> http://launchpadlibrarian.net/60435630/buildlog_ubuntu-natty-i386.python2.6_2.6.6-6ubuntu4_BUILDING.txt.gz says optional:
[16:18] <cjwatson> uploading to change Priority has zero effect
[16:18] <cjwatson> Priority and Section are set in overrides
[16:18] <doko> no, didn't change anything there
[16:19] <lamont> bzr branch lp:~lamont/launchpad-buildd/chroot-scripts; sudo chroot-scripts/make-chroot.sh -d natty --lp  <-- should you care to duplicate
[16:20] <cjwatson> ok, well I've fixed it in the archive now
[16:20] <lamont> cjwatson: I assume we need a publisher run?
[16:21] <smoser> i thought htat i had seen a way to transparently cat a file that was compressed or uncompressed.
[16:22] <cjwatson> lamont: yes
[16:22] <smoser> ie, something like an option to zcat or something.
[16:22] <cjwatson> zcat will cat uncompressed files
[16:22] <smoser> $ zcat foo
[16:22] <smoser> gzip: foo: not in gzip format
[16:23] <cjwatson> hm, my mistake
[16:23] <smoser> ah. --force will do it
[16:23] <cjwatson> zcat -f, yes
[16:41] <tgardner> is there a known way to work around the python2.7-minimal install problem?
[16:48] <cjwatson> tgardner: what's the error message?
[16:48] <cjwatson> installed fine for me
[16:49] <cjwatson> bug 687524 I suppose
[16:49] <tgardner> cjwatson, I got caught by the archive being unbuildable earlier this week (I missed the memo). Now I consistently get:
[16:49] <tgardner> dpkg: error processing python2.7-minimal (--configure):
[16:49] <tgardner>  subprocess installed post-installation script returned error exit status 3
[16:49] <tgardner> No apport report written because the error message indicates its a followup error from a previous failure.
[16:49] <tgardner>  dpkg: dependency problems prevent configuration of python2.7:
[16:49] <tgardner>  python2.7 depends on python2.7-minimal (= 2.7.1-1); however:
[16:49] <cjwatson> (and bug 687658)
[16:49] <tgardner>   Package python2.7-minimal is not configured yet.
[16:49] <tgardner> dpkg: error processing python2.7 (--configure):
[16:50] <tgardner>  dependency problems - leaving unconfigured
[16:50] <cjwatson> the operative line from the bug reports is actually "E: pycompile:240: Requested versions are not installed", which is before the output you showed
[16:50] <cjwatson> but anyway
[16:50] <cjwatson> doko: ^- could you have a look at that please?
[16:51] <tgardner> cjwatson, yep 'E: pycompile:240: Requested versions are not installed'
[16:51] <doko> looking ...
[16:51] <cjwatson> in general anything from "dpkg: error processing ..." onwards is just like "make: error 1" - follow-on errors
[16:51] <tgardner> cjwatson, ack
[16:52] <doko> tgardner: which versions of python and python-minimal are installed?
[16:53] <tgardner> python-minimal                  2.6.6-2ubuntu1
[16:53] <tgardner> python2.6                       2.6.6-6ubuntu3
[16:54] <tgardner> python2.6-minimal               2.6.6-6ubuntu3
[16:55] <doko> tgardner: could you unpack python and python-minimal (2.7.1-*) and try again?
[16:55] <tgardner> doko, what do you mean 'unpack' ? apt-get install ?
[16:56] <doko> aptitude download python python-minimal, then dpkg --unpack these
[16:57] <doko> then dpkg --configure --pending
[16:57] <doko> looks like http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=605356
[16:58] <lamont> cjwatson: guesses on eta to publisher being done?
[16:58] <doko> I should fix that in maverick-proposed
[17:00] <Riddell> @pilot out
[17:00] <cjwatson> lamont: 16:15 <cjwatson> should be available in <1.5 hours
[17:01] <cjwatson> lamont: it'll be the publisher run that's about to start
[17:03] <doko> tgardner: did that work?
[17:05] <tgardner> doko, no, but I might just be caught in some intermediate state. I can just reinstall this server...
[17:15] <cjwatson> soren: do you have an example case for bug 687584 to hand?
[17:29] <lamont> cjwatson: afk for a few hours, and then I'll get the chroots updated, will advise :(
[17:32] <cjwatson> ok, thanks
[17:35] <pitti> slangasek: ah, thanks for the clarification in bug 395281
[17:42] <pitti> sconklin: should I reject the linux-lts-backport-maverick upload sitting in the lucid-proposed queue? this was already copied from the PPA
[17:43] <pitti> sconklin: in fact, it's older (23.40, where 23.41 is in -proposed); rejecting, FYI
[17:44] <bdmurray> barry: is bug 688655 python2.7 related?
[17:50] <barry> bdmurray: it could be some dependent package is broken or different in 2.7.  doesn't strike me as immediately caused by 2.7, but i'll add the tag and take a look
[17:51] <doko> janimo: ping
[17:52] <janimo> doko: pong
[18:09] <smoser> ok. so i'm writing a utility that stuffs a MBR in front of a partition image.  failing 'splice' from the kernel, i basically have to write the MBR, then append the data from the source to the destination.
[18:09] <smoser> it appears dd with 'conv=sparse' never happened http://www.mail-archive.com/bug-coreutils@gnu.org/msg11804.html
[18:10] <smoser> can anyone think of a way that i can keep the destination file sparse using utilities in ubuntu (ideally main)
[18:10] <smoser> basically i need something to open a file for append and copy sparsely from another.
[18:16] <slangasek> pitti: n/p - not sure what the explanation is for the currently reported behavior, though
[18:19] <sladen> smoser: suggestions are that cp /dev/fd/0 /dev/fd/1  or something
[18:20] <sladen> smoser: but I do really wish that they would accept the desire for conv=sparse
[18:20] <ebroder> sladen: You'd need some way to talk cp into opening /dev/fd/1 with O_APPEND
[18:21] <sladen> ebroder: I ended up writing a tool
[18:22] <sladen> ebroder: turned into this  http://blog.alex.org.uk/2010/12/02/copying-sparse-files/
[18:24] <smoser> sladen, i didn't realize you were involved in that.
[18:24] <smoser> i had talked to alex and he pointed me at it.
[18:27] <sladen> smoser: perhaps we should get that into the distribution now it's been released separately
[18:27] <sladen> smoser: it should already be packaged ;-)
[18:27] <smoser> sladen, right. thats definitely an option.
[18:47] <alexbligh> smoser: ok I was quietly betting you'd get no replies on alternatives, but did not anticipated sladen would point you back at the same thing :-)
[18:47] <smoser> entrapment!
[19:00] <cjwatson> smoser: is conv=notrunc not sufficient?  I wouldn't have thought that would have changed anything after the endpoint of the write?
[19:04] <smoser> cjwatson, conv=notrunc works, but if it reads 1G worth of zeros , it will (i assumed) write 1G worth of zeros
[19:04] <smoser> rather than seeking.
[19:07] <cjwatson> oh, I read your problem the wrong way round
[19:07] <cjwatson> thought you were overwriting data at the start, not inserting
[19:08] <cjwatson> is inserting really the right way to go about it?  perhaps reframe your design
[19:08] <cjwatson> after all the distance between the boot sector and the partition will not always be the same, probably
[19:09] <smoser> cjwatson, i'm probably messing this up badly. but http://paste.ubuntu.com/541997/ is what i have.
[19:09] <ScottK> cjwatson: Would you please rescore the gtkglextmm build (only affects powerpc) - I think that's the blocker on getting python-visual built.
[19:10] <smoser> i've got process in place that builds partition images, i want to be able to produce disk images from those, and have those disk images boot in a full virt env
[19:10] <ScottK> (which in turn blocks boosts1.40 removal)
[19:12] <ebroder> smoser: Does this need to work as not-root? If it can be root-only, will cp work if the destination is a block device? You could use kpartx to create a device-mapper object for the partition, and cp --sparse=always onto that
[19:13] <smoser> i just really dont want to be root.
[19:14] <ebroder> smoser: btw, you know about blockdev(8) for probing for things like the size of block devices?
[19:15] <smoser> ebroder, i'd seen it, but didn't worry to much at this point about block devicesa
[19:31] <cdbs> IS python-webkit working properly with python 2.7 ?
[19:32] <barry> cdbs: working, or building?
[19:32] <cdbs> barry: working
[19:32] <cdbs> I don't know about its build status
[19:32] <kirkland> cjwatson: hi...  i just did two preseeded installations of natty;  one on ext3 and the other on ext4
[19:33] <kirkland> cjwatson: the ext3 one took <6 minutes, the ext4 one took 12 minutes
[19:33] <cdbs> Since I am getting ImportError: AttributeError: 'module' object has no attribute 'WebView'
[19:33] <kirkland> cjwatson: what ever happened with that dpkg issue?
[19:33] <cdbs> barry: ^
[19:33] <kirkland> cjwatson: did we get that fixed?  or decided not to?
[19:34] <barry> cdbs: it's possible.  i haven't looked at it yet.  can you file a bug and tag it with python27?
[19:34] <barry> i can at least look
[19:34] <cdbs> barry: okay then
[19:35] <barry> cdbs: thanks
[19:35] <cjwatson> ScottK: done
[19:36] <cjwatson> kirkland: it's in progress.  dpkg has a --force-unsafe-io option now, and there are other changes in progress.  I'll adjust the installer before natty to use that
[19:36] <cjwatson> (or something similar)
[19:36] <cjwatson> kirkland: Debian is thoroughly on top of the issue at this point.
[19:37] <kirkland> cjwatson: okay thanks;  i'll set my preseeds to use ext3 for speed for now, and test ext4 once you get a fix committed
[19:38] <ScottK> Thanks for the rescore on gtkglextmm.
[19:39] <cdbs> barry: will file tomorror, thanks!
[19:41] <cjwatson> kirkland: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=605009 in particular - finally got some proper attention from tytso, including a specific suggestion to use sync_file_range which will be implemented in the next dpkg release
[19:41] <cjwatson> kirkland: so I'm holding off doing anything with --force-unsafe-io in the installer until I see whether that makes a difference
[19:42] <kirkland> cjwatson: okay, thanks;  i'm now subscribe to that debian report
[19:42] <kirkland> cjwatson: i'll monitor it there;  please poke my if and when you specifically want my testing feedback
[19:49] <cjwatson> ok
[19:49] <cjwatson> kirkland: no need to tell me when it gets closed though, I'll get e-mailed
[19:49] <kirkland> cjwatson: ack
[19:50] <kirkland> cjwatson: somewhat related to that ...
 cjwatson: so i have a preseed with "d-i partman-lvm/confirm boolean true"
 cjwatson: but I'm being held at that question anyway
 cjwatson: any hints?
 cjwatson: full preseed at http://pastebin.com/ME2CDpnx
[19:52] <cjwatson> kirkland: I can help if and only if I see a DEBCONF_DEBUG=developer syslog
[19:53] <kirkland> cjwatson: okay, i'll get you one
[19:54] <kirkland> cjwatson: the only thing odd i see is that the root disk where the installation is taking place is registered as sdb (instead of sda) in the installer
[19:54] <kirkland> cjwatson: post install, it's sda in runtime
[19:54] <kirkland> cjwatson: and the installation proceeds just fine as sdb
[19:54] <cjwatson> anything that that breaks is a bug in its own right
[19:54] <kirkland> cjwatson: okay
[19:54] <kirkland> cjwatson: i can't find anything else odd going on there
[19:55] <kirkland> cjwatson: i'm working around this for now with:
[19:55] <kirkland> -       preseed_file.write("d-i partman-auto/method string lvm\n")
[19:55] <kirkland> +       preseed_file.write("d-i partman-auto/method string regular\n")
[19:55] <cjwatson> it's not worth speculating.  it's about a hundred times quicker to look at a debug log
[19:55] <kirkland> cjwatson: okay, i'll send another install through with that cmdline option
[20:01] <jono> hey all
[20:02] <jono> I have a USB keyring running natty, but persistence is not working, can anyone recommend how I fix it
[20:02] <jono> ?
[20:09] <kirkland> cjwatson: well darn;  not reproducing it today :-/  happened several times yesterday
[20:09] <kirkland> cjwatson: i'll keep the cmdline debug parameter on there though, and grab the syslog if it shows up again
[20:10] <d-kessel> barry: considering python 2.7/natty - what do you guess when it will be safe to upgrade packages?
[20:26] <barry> d-kessel: you can upgrade packages now.  which one in particular are you thinking about?
[20:29] <d-kessel> thanks. well all ~170 update manager tells me to
[20:33] <d-kessel> barry: thanks. well all ~170 update manager tells me to
[20:36] <barry> d-kessel: i've been updating my vms today and it seems okay to me
[20:37] <micahg> hi robbiew, do you have time for a PM?
[20:37] <robbiew> micahg: sure
[20:39] <d-kessel> barry: thx, I'll see what it does to my "real" netbook installation
[20:42] <ebroder> jono: Honestly, if you have a spare USB key, running usb-creator on one key, then using that to do an actual install onto another key is going to be a truer testing environment. It will also get testing for things like the text-free boot changes
[20:42] <ebroder> I think I saw some discussion about expanding testdrive to install onto a USB key, which would remove the need for the spare
[20:46] <ebroder> jono: In the mean time, can you start by pastebining the syslinux/syslinux.cfg file on the USB drive?
[20:46] <jono> ebroder, I just talked with ev about this
[20:46] <jono> I am not entirely sure what the issue is
[20:46] <jono> and I have just wiped the stick to install it another way
[20:47] <ebroder> jono: Ah, ok
[20:47] <jono> ev would you mind filing a bug for this?
[20:47] <jono> as you have the outputs I pasted
[20:47] <ev> jono: those all just show that it isn't a problem in usb-creator
[20:47] <jono> gotcha
[20:47] <ev> what we need is something with the issue to post a bug against casper with their /var/log/casper.log attached
[20:48] <ev> preferably with debug set on the kernel command line
[20:54] <d-kessel> barry: upgrading failed, it is running dpkg --configure -a now
[20:55] <barry> d-kessel: dang
[21:12] <Keybuk> The next time Lennart sarcastically suggests it only took him a year to write systemd, I'm going to reply that it only took me *two hours* to add socket activation to Upstart
[21:13] <ebroder> Oooh, looks like fun
[21:14] <Keybuk> https://code.launchpad.net/~scott/upstart/bridges
[21:14] <Keybuk> adds an upstart-socket-bridge binary
[21:15] <ebroder> Keybuk: Yeah, I was skimming that and the session-support branches
[21:15] <Keybuk> if you stick "start on socket PROTO=inet PORT=1234" in your job, the bridge makes a listening socket on port 1234 for you, and when it gets a connection, sends the event with the socket
[21:19] <ebroder> Keybuk: Uh, don't you need to deal with SOCK_DGRAM vs. SOCK_STREAM?
[21:19] <Keybuk> ebroder: sure, at some point :p
[21:19] <Keybuk> that'd be just adding an int type to the Socket structure
[21:20] <Keybuk> defaulting to SOCK_STREAM
[21:20] <Keybuk> then adding
[21:20] <ebroder> socket(2) talks about AF_INET being a "domain", not a protocol
[21:20] <Keybuk> SOCK=STreaM
[21:20] <Keybuk> SOCK=DGRAM
[21:20] <Keybuk> etc.
[21:20] <Keybuk> yeah, I think I picked up "proto" from inetd
[21:20] <ebroder> Sure, I agree it's easy, I'm just nitpicking your terminology before anybody commits to it
[21:20] <Keybuk> noted, shall check I'm using the right thing there
[21:23] <ebroder> Keybuk: What's the plan for dealing with "start on socket PROTO=unix PATH=/var/run/dbus/system_bus_socket" having an implicit dependency on /var/run being mounted? Do you force the developer to make that explicit by adding an " and local-filesystems" or whatever?
[21:23] <Keybuk> hmm
[21:23] <Keybuk> that'd need to be a depedency on the socket bridge for now
[21:23] <Keybuk> I think the best thing is just to have the socket bridge started on virtual-filesystems
[21:23] <Keybuk> so /var/run is always available for it
[21:24] <Keybuk> 0.10 handles this stuff rather better
[21:24] <Keybuk> but we wanted to have it in 0.6 for fun
[21:25] <ebroder> I'm not familiar with the changes for 0.10. I'm guessing it rolls mountall into upstart and gives upstart stronger filesystem awareness?
[21:25] <Keybuk> nah
[21:25] <Keybuk> but it does actually roll the socket listening into upstart itself
[21:25] <Keybuk> where this is using a bridge
[21:26] <ebroder> How does that help?
[21:26] <Keybuk> because then upstart knows when it should be listening on the socket and when it shouldn't
[21:26] <Keybuk> e.g.
[21:26] <Keybuk> while apache
[21:26] <Keybuk> listen inet 80
[21:26] <Keybuk> exec ...
[21:26] <Keybuk> says to only listen while apache is running
[21:26] <Keybuk> and to only exec on connection
[21:26] <ebroder> Oh, interesting
[21:26] <Keybuk> it's the whole "while" thing that helps
[21:27]  * ebroder nods
[22:06] <kirkland> jjohansen: hey, would you mind joining #ecryptfs on OFTC?
[22:13] <lamont> cjwatson: doko: building tarballs now
[22:40] <lamont> cjwatson / doko: new python2.6-minimal-free tarballs uploaded
[22:40] <lamont> have a nice day
[22:41] <doko> lamont: available for builds *now* ?
[22:49] <doko> lamont: yes, and hurray! seeing now different build failures ;p
[22:50] <lamont> doko: uploaded == what LP will serve to the buildds the next time they ask