[00:02] <psusi> cjwatson, per my discussion with smoser at UDS about the cloud images needing to online extend the root fs while booting without an initrd, I have some patches to parted and the kernel to do this.  Any chance of getting parted 3.0 merged for precise?
[00:09] <slangasek> patching the kernel for it? eew? :)
[00:13] <cjwatson> psusi: I think it's unlikely given the amount of installer work that has to be done first
[00:14] <cjwatson> psusi: specifically removal of everything that relies on libparted's filesystem code, which is going to involve writing a wrapper that knows how to transform various tools' progress output into debconf progress; I made a start on this a while back but there's quite a bit to do
[00:23] <psusi> cjwatson, ohh.. I thought the installer hadn't been relying on the parted filesystem code for a long time, seeing as how it has been basically broken for ages
[00:24] <psusi> slangasek, needed to add the missing BLKPG ioctl command to change the length of an in use partition... online expand and shrink of a btrfs partition is a beautiful thing ;)
[00:24] <broder> ...how can that ever be remotely safe?
[00:24]  * slangasek does not get warm fuzzies
[00:24] <slangasek> :)
[00:25] <psusi> broder, lvm has been doing it for years
[00:26] <psusi> ext4 can only grow online, but btrfs can shrink too
[00:27] <cjwatson> psusi: it still does in some places where it hasn't been broken
[00:27] <cjwatson> psusi: yes, it needs to move away from that anyway; but there are places where the practical effect of that would be a regression for users in terms of what progress bars we manage to provide, and I want to avoid that
[00:28] <psusi> cjwatson, so it relies on libparted to handle resize of fat filesystems and provide feedback?  anything else?
[00:29] <cjwatson> I forget, sorry, you'll have to hunt through partman
[00:29] <cjwatson> pretty certain it's a good deal more than that though
[00:29] <psusi> k.. just afaik, fat and bare bones ext2 were the only filesystems it could actually deal with
[00:29] <cjwatson> RTFS :-)
[00:31] <cjwatson> start with parted_server, look for use of removed ped_* functions, then look for use of the corresponding parted_server commands in the rest of partman
[00:32] <psusi> parted_server is a custom front end to libparted right?
[00:32] <cjwatson> yes
[00:32] <cjwatson> it's in the partman-base source package
[00:32] <psusi> kk
[00:32] <cjwatson> it's probably most concisely described as shell bindings for libparted
[00:32] <cjwatson> ish
[00:33] <psusi> right
[00:33] <psusi> and the rest of partman is written in shell right?
[00:33] <cjwatson> yes
[00:33] <cjwatson> apart from a couple of tiny C helpers
[00:59] <fetova> Here, bothering again.
[00:59] <fetova> I've done again the push of the bug 886680, this time taking the code of lp:~ubuntu-core-dev/app-install-data-ubuntu/ubuntu and i get a really big diff...
[00:59] <fetova> What i've done wrong? :(
[00:59] <fetova> The merge proposal: https://code.launchpad.net/~fetova/ubuntu/precise/app-install-data-ubuntu/fix-for-886680/+merge/84347
[01:09] <cjwatson> fetova: again, you need to propose it for merging into the same branch that you branched from
[01:10] <cjwatson> fetova: you should call your branch lp:~fetova/app-install-data-ubuntu/fix-for-886680 (tedious namespace differences that I won't go into) and propose it for merging into lp:~ubuntu-core-dev/app-install-data-ubuntu/ubuntu
[01:13] <psusi> can you not search the source package list with apt-cache?
[01:14] <cjwatson> I doubt it
[01:14] <psusi> trying to find all the bloody assorted partman packages ;)
[01:14] <cjwatson> apt has a fairly weak internal representation of source packages
[01:14] <fetova> ok... i want to get this fully, so, another question:
[01:14] <fetova> Why should I name my branch lp:~fetova/app-install-data-ubuntu/fix-for-886680  instead of lp:~fetova/app-install-data-ubuntu/ubuntu/fix-for-886680 ?
[01:15] <cjwatson> fetova: drat, now I have to go into the grotty details :)
[01:15] <cjwatson> branches of the form lp:~OWNER/PROJECT/BRANCHNAME are upstream branches; branches of the form lp:~OWNER/DISTRO/SERIES/PACKAGE/BRANCHNAME are source package branches
[01:16] <cjwatson> source package branches are a newer invention, and a fair number of relatively old packages still use the upstream form, although we'd like to get everything over to source package branches eventually
[01:17] <cjwatson> in general if you find two branches of the same thing in the two different namespaces you can't assume that it's possible to freely merge between them; you need to figure out which one the developer of the package is using and match that
[01:18] <cjwatson> so, this package declares which it's using in the Vcs-Bzr field in debian/control (also shown by 'apt-cache showsrc' etc.)
[01:18] <cjwatson> that tells you where you should branch from
[01:18] <cjwatson> and you should ALWAYS propose a merge into the same branch that you branched from
[01:18] <cjwatson> (unless you know exactly what you're doing and know better, in which case you don't need my advice)
[01:19] <fetova> true :P
[01:20] <fetova> ok, so i need to explain the debugging i've made so far, to ask for advice for what i exactly should do in this case
[01:20] <cjwatson> the final piece is that it's normally best to use the same namespace as the branch you branched from, to reduce confusion in the Launchpad UI
[01:20] <cjwatson> so if it's three-level, use a three-level name; if it's five-level, use a five-level name
[01:21] <cjwatson> (it's unfortunate that quite this much complexity is on the surface)
[01:21] <fetova> yeah... a bit...
[01:22] <psusi> it's not bad once you understand it... just needs written down somewhere for people to read ;)
[01:23] <fetova> well, as i investigate on the sources, there is a script (update-menu-data.sh) that get from http://rookery.canonical.com/~mvo/gnome-app-install/ the .desktop
[01:23] <fetova> accordly by the date "today"
[01:23] <fetova> the last taken on the launchpad code has the bug
[01:23] <fetova> the most recent on that url, not
[01:24] <fetova> http://rookery.canonical.com/~mvo/gnome-app-install/menu-data-20110802.tar.gz
[01:24] <fetova> so... the bug is fixed on that code just getting this last .tar.gz
[01:25] <smoser> psusi, still around ?
[01:25] <psusi> smoser, yo
[01:26] <smoser> so forgive me for beign gravely ignorant.
[01:26] <psusi> bless you my son ;)
[01:26] <smoser> but given a kernel patch, we basically will just have to rewite the partition table (which I do already using sfdisk) and then amke a IOCTL , right ?
[01:27] <smoser> assuming you can get the stuff into kernel, the rest seems easy for me. i dont see the need for parted.
[01:27] <smoser> again, i'm sure i'm making an idiot of myself and missing something obvious :)
[01:27] <psusi> smoser, yea... and I have parted doing that nicely now... problem seems to be that ubuntu is still using an old parted because d-i still depends on some of the crappy filesystem code that has since been removed from parted ;)
[01:27] <psusi> well, if you want to patch sfdisk to do it, go for it
[01:28] <smoser> but its not even necessary to patch sfdisk.
[01:28] <fetova> so... i'm not sure how i should get the bug fixed, if geting this .tar and doing all the import stuff it on the lp:~ubuntu-core-dev/app-install-data-ubuntu/ubuntu code... or on the source package branch
[01:28] <smoser> i can just rewrite the partition table with sfdisk and tell it either not to call BLKKRRPART, or call it, it wont do anything.
[01:28] <psusi> well... it really should be done in the partition table writing tool... this isn't just a "hey, read the partition table", it is an "move the end of this partition to sector x"
[01:28] <smoser> and then i have a little program that makes the right call.
[01:28] <fetova> what do you think, cjwatson? :)
[01:29] <smoser> psusi, fair enough, but even then, that isn't *too* bad. i can have sfdisk tell me what that new sector is.
[01:29] <psusi> you *could* write a quick and dirty tool to do it and pass the sector and partition number from your script, but that feels a little kludgy to me
[01:30] <smoser> i agree, that better for sfdisk to do it. or parted, but if that is goign to require installer chagnes and possibly regressions... i'd do without.
[01:30] <smoser> if it saves me 2 seconds or something every boot in a cloud image, thats a big win.
[01:31] <psusi> sounds reasonable
[01:31] <smoser> and i don't really see the possible fallout.
[01:33]  * psusi needs to take HDIO_GETGEO out back and bury it behind the tool shed
[01:36] <cjwatson> psusi: surely it's easily enough backportable in parted anyway.
[01:37] <cjwatson> fetova: don't know, sorry, I've never attempted to do a full update of a-i-d-u from a new data dump; you want mvo
[01:37] <psusi> cjwatson, I'm not sure... because old parted has a resize command that also resizes the filesystem.. that was removed, and I have replaced it with one that just resizes the partition
[01:38] <fetova> I see, i'm mailing him
[01:38] <fetova> Thanks a lot for the guiding!, cjwatson :D
[01:40] <cjwatson> psusi: I meant the underlying libparted bit
[01:40] <cjwatson> psusi: as far as the parted command-line program goes, repurposing an old command is bad style, even if it was removed.  Give it a new name instead
[01:40] <psusi> cjwatson, sure, that's easy.. but you need a user interface for it ;)
[01:41] <cjwatson> psusi: people with scripts that use 'resize' should get an error message with parted 3.0, not have the script do some random other thing instead
[01:42] <psusi> cjwatson, they will get an error as the arguments are different.... old one took start pos, new one does not... only moves the end
[01:46] <cjwatson> psusi: that's a pretty fragile way to do it; a new command would be easier to understand
[01:46] <cjwatson> what if somebody adds another optional argument in future, say
[01:47] <cjwatson> design for people coming along and modifying your code later without full context :)
[01:47] <cjwatson> and that will make the backport trivial, so it should be a no-brainer to do it that way?
[01:47] <psusi> well, what should you call it?  this one should be called resize, and the original one should have been named resizefs, but it was't...
[01:47] <cjwatson> resizepart?
[01:48] <psusi> that's the reverse naming convention of all of the other commands
[01:48]  * cjwatson shrugs
[01:48] <psusi> hrm...
[01:48] <cjwatson> or use a different verb
[01:48] <cjwatson> I can't do naming after local midnight
[01:49] <infinity> alternatelysize
[01:49] <infinity> makebiggerorsmaller
[01:49] <infinity> SO MANY OPTIONS.
[01:50] <psusi> I guess resizepart could work... I just hate introducing things that make people go "why the hell was it given THAT name? oh, because there was an older broken misnamed command that was removed, but had the logical name for this one"
[01:53] <infinity> You could just name it britney.
[01:53] <psusi> lol... actually, if I did name if resizepart, because you can use short prefixes and the old resize command is gone, "resize" would still be recognized as resizepart
[01:54] <infinity> D'oh.
[01:54] <infinity> rpart?  rsizepart?
[01:55] <cjwatson> changesize, changeextents
[01:56] <cjwatson> extents
[01:56] <cjwatson> why was it given that name> sometimes compatibility is painful but that doesn't make it less valuable ...
[01:57]  * infinity grumbles about people using dh_autoreconf in their clean targets..
[01:58] <cjwatson> infinity: debuild -S -nc  IYF
[01:59] <cjwatson> (with care)
[01:59] <psusi> hrm...
[01:59] <infinity> cjwatson: IYF?
[01:59] <cjwatson> is your friend
[01:59] <psusi> maybe I could name it changesize, and require that name to be used in batch mode for clarity, but going forward, alias resize for interactive users...
[02:00] <infinity> Huh.  dpkg-buildpackage was supported -nc forever.  No idea how I missed that.
[02:01] <cjwatson> it's only been allowed with -S since dpkg 1.15.1 (May 2009)
[02:01] <cjwatson> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=304404
[02:02] <psusi> then drop the requirement and accept either in batch mode in say, 2-3 years
[02:02] <psusi> yea... I like that...
[02:02] <infinity> cjwatson: Ahh, could be why I never used it.  Maybe I once tried and failed. ;)
[02:40] <broder> did clutter-gst just get promoted? (trying to figure out if my lintian lab is on crack or just out of date)
[02:41] <broder> (i see it's in main now - trying to figure out if it was just moved recently)
[02:42] <broder> hmm..no, looks like it was a few days ago
[04:34] <broder> since the sponsorship queue isn't picking it up, could i get some kind soul to sponsor bug #897383 for me?
[05:09] <hallyn> If there is any MOTU or coredev around in the mood to upload a (well 3) one-line change to ii, bug 899494 is here to spice up your friday night...
[05:10] <broder> hallyn: i can take a look as long as it's quick
[05:11] <broder> wow. this is a special package
[05:13] <hallyn> broder: that'd be great, thanks!
[05:13] <hallyn> yes, it is :)
[05:16] <hallyn> ugh, just opened my (precise-changes-subscribed) mbox :)
[05:18] <infinity> hallyn: *cough*
[05:18] <infinity> hallyn: Sorry. :P
[05:18] <hallyn> :)  np, delete is quick :)
[05:21] <infinity> micahg: You still around?
[05:23] <broder> hallyn: test building now, but a few points of feedback
[05:24] <broder> (which i'm just cleaning up in my build)
[05:24] <broder> (a) ii in lucid is a source format 1.0 package, which means that it doesn't apply quilt packages by default
[05:24] <hallyn> jinkeys
[05:25] <hallyn> (sbuild did apply it, though)
[05:25] <broder> no, your debdiff has the patch applied
[05:25] <hallyn> oh.  i see. that explains why .pc was in the debdiff
[05:25] <hallyn> right
[05:25] <broder> we don't usually add a patch system to a package in an SRU
[05:25] <broder> or as an ubuntu diff in general
[05:25] <hallyn> i should've paid more attention to that, thanks
[05:25] <broder> so for packages that aren't already either using quilt or source format 3.0 (quilt), the general convention is to just patch the source directly
[05:25] <infinity> Oh, how I'm glad that best practice reversed on that.
[05:26] <hallyn> oh?
[05:26] <infinity> I used to tear my hair out merging packages where some helpful Ubuntu dev had added a patch system that wasn't there upstream.
[05:26] <broder> hmm...in fairness, this may be an ubuntu-motu-land best practice and not a general ubuntu one
[05:26] <broder> but i'm doing the review so you get to play by my rules :-P
[05:26] <hallyn> broder: not even using dpatch?
[05:26] <infinity> broder: No, it was MOTU that used to be guilty of the above insanity.
[05:26] <infinity> broder: And I smacked many for it.
[05:26] <infinity> broder: It seems that things went my way. ;)
[05:27] <infinity> hallyn: Adding a patch system just plain shouldn't be done for an SRU or for a Debian->Ubuntu merge.
[05:27] <hallyn> broder: put another way - in oneiric it uses quilt, does that change anything?
[05:27] <infinity> hallyn: Just view an SRU as an Ubuntu->Ubuntu merge.  Adding extra code just makes it confusing.
[05:27] <broder> hallyn: yeah, you'd use their quilt hooks
[05:27] <broder> use the patch system that's there, but don't add a new one
[05:27] <infinity> (And yeah, if it already has a patch system, use it)
[05:27] <hallyn> right, but not in lucid, even though oneiric has it?
[05:28] <infinity> Yeah, not in lucid.
[05:28] <hallyn> ok (oneiric already has the fix :)
[05:28] <infinity> Your delta is from lucid->lucid, not from oneiric.
[05:28] <hallyn> i'll post a new debdiff, but you had more?
[05:28] <broder> actually, i think my point 1 managed to expand to cover everything :-P
[05:28] <broder> don't worry about a new debdiff, though
[05:28] <broder> i've already got it taken care of
[05:29] <hallyn> broder: thanks!
[05:29] <infinity> rm -rf .pc debian/patches && done? :)
[05:29] <broder> infinity: pretty much
[05:29] <broder> and tweak the changelog to not mention a file in debian/patches that's not there :)
[05:29] <infinity> Heh.
[05:29] <hallyn> (this bug was driving me nuts, very mysterious :)
[05:30] <broder> i can't believe you use this thing
[05:30] <broder> ok, uploaded
[05:30] <broder> and -> battery dead
[05:30] <broder> i'll be back later if there's any fallout :)
[05:30] <hallyn> good night - thanks again
[05:31] <infinity> It sounds handy for event-driven shell<>IRC scripting.
[05:31] <infinity> Also, knowing anyone uses such a gateway, I'm not inclined to try injecting code into it.
[05:31] <infinity> s/not/now/
[05:32] <hallyn> infinity: it makes interacton with xmpp (i.e. google chat) trivial
[05:33] <hallyn> and, it becomes very usable with pcw or multitail+vim
[05:33] <infinity> I'll concede the first point.  The rest just sounds perverse.
[05:34] <hallyn> :)
[05:34] <infinity> But hey, I haven't really changed my UI over nearly two decades of irc->ircII->BitchX->irssi, so who am I to talk?
[05:35] <infinity> If IRC doesn't have a blue bar at the bottom, I don't know it's IRC....
[05:35] <hallyn> haha, the right byobu theme could do that for you i'm sure :)
[05:35] <infinity> *shudder*
[16:14] <quadrispro> hi all
[16:21] <apw> infinity, i've uploaded those hf fixes ... fingers crossed
[16:21] <ogra_> \o/
[16:23] <apw> ogra_, its on a buildd, so i guess 3-4 hours till we know, but i hacked (literally) one of cross build chroots to test it properly, so its as good as i can make it without building it in the real chroot
[16:24] <apw> so there seemed no point to hold it off any longer
[16:24] <ogra_> yeah, lets see
[16:24] <ogra_> right, its not like we are short on buildd power :P
[16:24] <ogra_> if it fails it fails
[16:24] <apw> for arm thats a nice position to be in
[16:25] <ogra_> heh
[16:25] <ogra_> well, currely hf owns most of them i think
[16:25] <ogra_> el is indeed a bit short
[18:59] <bdrung> tumbleweed: http://paste.debian.net/147955/
[19:00] <bdrung> tumbleweed: shouln't we do another upload
[19:00] <bdrung> ?
[19:02] <bdrung> besides that: some "Missing docstring"
[19:02] <bdrung> tumbleweed: man pages are missing
[19:03] <bdrung> tumbleweed: test cases are missung
[19:03] <bdrung> s/missung/missing
[19:03] <bdrung> can we get rid of "E: 80:main: Class 'PersonTeam' has no 'me' member"
[19:03] <bdrung> ?
[19:04] <bdrung> besides that both branches seems to be fine
[19:19] <tumbleweed> bdrung: yes, due for one soon, but (as you can see) I have some new things I've been playing with that need a little polish, first :)
[19:19] <bdrung> k
[19:20] <bdrung> tumbleweed: RL keeps me busy. therefore i have only little time to review (no time for developing new things)
[19:20]  * tumbleweed probably shouldn't be writing new things either :)
[19:21] <bdrung> tumbleweed: but now you have to finish them! :p
[19:21] <tumbleweed> yeah :/
[20:27] <bdrung> tumbleweed: let me know if i should review something
[20:28] <tumbleweed> bdrung: you can tell me how useful those tools in braches attached to bug 876554 are (and give UI review)
[20:29] <bdrung> tumbleweed: they are useful
[20:30] <tumbleweed> great, must clean them up then :/
[21:30] <apw_> infinity: ogra_ ..armhf is pending binary new ... :)
[21:37] <tumbleweed> bdrung: there, first branch is reviewable
[21:37] <bdrung> tumbleweed: which?
[21:38] <tumbleweed> who-can-upload-876554
[21:42] <bdrung> tumbleweed: "R: 25:main: Too many statements (54/50)"
[21:43] <bdrung> tumbleweed: split it into more functions
[21:44] <bdrung> tumbleweed: maybe split command line parsing
[21:44] <tumbleweed> yup, the only logical split
[21:45] <bdrung> tumbleweed: main has no comment
[21:46] <bdrung> tumbleweed: can we get rid of E: 93:main: Class 'PersonTeam' has no 'me' member
[21:46] <tumbleweed> bdrung: no, pylint doesn't unterstand metaclasses
[21:46] <tumbleweed> our pylint configuration file already whitelists PersonTeam
[21:51] <tumbleweed> bdrung: pushed r1252
[21:54] <bdrung> tumbleweed: ./upload-permission audacity  -r lucid-proposed
[21:55] <bdrung> tumbleweed: i can't upload to lucid :( and lucid-proposed is unknown
[21:55] <tumbleweed> permissions are the same across pockets
[21:55] <bdrung> tumbleweed: "You can not upload this package, yourself." -> name the package
[21:56] <bdrung> You can upload this package. -> name it
[21:56] <bdrung> tumbleweed: then why $ ./upload-permission audacity -r lucid
[21:56] <bdrung> You can not upload this package, yourself.
[21:57] <tumbleweed> ah, the bit that answers that does check the pocket
[22:14] <bdrung> tumbleweed: "You can upload audacity." -> "You can upload audacity to oneiric." maybe?
[22:16] <bdrung> tumbleweed: http://paste.debian.net/147975/ -> shouldn't line 5 and 6 removed?
[22:20] <tumbleweed> bdrung: yeah, fixed
[22:21] <bdrung> tumbleweed: You can upload audacity to None.
[22:22] <bdrung> tumbleweed: i would kill the last line too: http://paste.debian.net/147976/
[22:24] <bdrung> tumbleweed: http://paste.debian.net/147977/ -> packagesets VS component?
[22:27] <tumbleweed> got all that
[22:28] <tumbleweed> actually, no
[22:31] <tumbleweed> right
[22:31] <bdrung> tumbleweed: it looks good now. last point: the name of the script
[22:32] <bdrung> tumbleweed: is it precise enough?
[22:32] <bdrung> tumbleweed: maybe ubuntu-upload-permission?
[22:32] <tumbleweed> s/^/ubuntu-/ ?
[22:33] <bdrung> then it's not short, but the tab-completion will help
[22:35] <tumbleweed> renamed
[22:39] <bdrung> tumbleweed: debian/control -> sort it
[22:40] <bdrung> tumbleweed: ups, no. update-maintainer is twice there
[22:41] <tumbleweed> ah, I thought it was missing
[22:43] <bdrung> tumbleweed: backportpackage is missing there
[22:45] <bdrung> tumbleweed: you can merge your branch now
[22:45] <psusi> yay!  online partition resize patches successfully backported to precise
[22:46] <tumbleweed> bdrung: next branch
[22:46] <bdrung> tumbleweed: i will go to bed in the near future
[22:53] <bdrung> tumbleweed: will you merge the approved branch first?
[22:54] <tumbleweed> bdrung: done. (took a while, suffering temporary network problems 50% packetloss somewhere between ZA and UK) :/
[22:55] <tumbleweed> cjwatson: this is something I did this morning, as a result of a conversation we had a while back about a tool to show if a package is "seeded" inimages. I'm rsyncing the manifests & lists from cdimage and building an index of packages
[22:57] <tumbleweed> if we find this useful, it'd probably be preferable if I didn't have to generate the index separately, and we could do it somewhere in the publication pipleines (it's tiny, so fast to do)
[23:02] <bdrung> tumbleweed: good night
[23:02] <tumbleweed> night, thanks for dusting out all the corners :)
[23:03] <bdrung> you're welcome