[00:11] <infinity> ScottK: Use deborphan, and tell it to keep ubuntu-standard, perhaps?
[04:53] <tjaalton> any sru-team members around?
[07:25] <dholbach> good morning
[11:09] <slomo> infinity: gstreamer1.0 should build fine now (just uploaded -2)
[11:36] <infinity> slomo: Thanks!
[12:10] <rbasak> How does one switch a package conffile from conffile to manually managed in maintainer scripts? Just doing it makes dpkg think that the file is obsolete after upgrade. dpkg-maintscript-helper seems relevant and mentions this case, but it doesn't seem to fit "removing a conffile" nor "moving a conffile" which seem to be the only two cases documented.
[12:15] <Sweetshark> seb128: for bug 1034558 and bug 1034560 we need to prepare an LO upload soon.
[12:18] <seb128> Sweetshark, don't you plan to upload 3.6 soon anyway? :-)
[12:22] <Sweetshark> seb128: yes, I have that one ready. Should I just give you one for uploading? the components mismatch will go crazy, but better now than two days before ff, right?
[12:25] <seb128> Sweetshark, how come we won those depends between rc3 and stable?
[12:56] <Sweetshark> seb128: bug 992232
[12:57] <seb128> Sweetshark, seems like we could do longer without it and should not block 3.6 on that?
[12:58] <Sweetshark> seb128: you mean no reportbuilder in quantal main?
[12:58] <seb128> Sweetshark, was it in precise main?
[13:00] <Sweetshark> seb128: no but they bitched me in doing an extra ppa rebuilding full LibreOffice only for this small extension
[13:00] <seb128> Sweetshark, well, it's not a regression then, I would recommend you keep it off until the MIRs are resolved
[13:01] <seb128> or check with the MIR team if they can review,approve that stack soon
[13:02] <Sweetshark> IIRC there was at least on of those packages needlessly using crappy maven ...
[13:03] <seb128> Sweetshark, so please keep that off
[13:05] <Sweetshark> seb128: k
[13:06] <Sweetshark> seb128: I dropped a note in the bug.
[13:07] <seb128> Sweetshark, thanks
[14:11] <stokachu> stgraber: i got that mp updated with changelog and posted rdeps testing to bug, if you get a chance today could you give it a lookover?
[14:13] <xnox> micahg: http://people.canonical.com/~ubuntu-archive/transitions/sqlite.html
[14:14] <xnox> micahg: 37 packages should drop build-deps? 245 are still to fix?
[14:19] <stgraber> stokachu: can you paste me that URL again?
[14:19] <stokachu> sure
[14:20] <stokachu> stgraber: https://code.launchpad.net/~adam-stokes/ubuntu/quantal/gnome-vfs/lp977940-multiarch/+merge/114258
[14:27] <rbasak> How does one switch a package conffile from conffile to manually managed in maintainer scripts? Just doing it makes dpkg think that the file is obsolete after upgrade. dpkg-maintscript-helper seems relevant and mentions this case, but it doesn't seem to fit "removing a conffile" nor "moving a conffile" which seem to be the only two cases documented.
[14:45] <Peace-> hi
[14:46] <Peace-> why in the world if i install ffmpeg i get ffmpeg from libav that is deprecated?
[14:46] <rbasak> ogra_: ping
[14:46] <Peace-> my software are all messed up
[14:46] <ogra_> rbasak, on the phone atm ...
[14:47] <rbasak> ogra_: ok, np
[14:47] <rbasak> ogra_: for when you're done... I think your recent flash-kernel changes might have caused a regression
[14:47] <infinity> Peace-: Since when is libav deprecated...?
[14:47] <Peace-> infinity:
[14:47] <Peace-> ffmpeg version 0.8.3-4:0.8.3-0ubuntu3, Copyright (c) 2000-2012 the Libav developers
[14:47] <Peace->   built on Jul 30 2012 22:10:17 with gcc 4.7.1
[14:47] <Peace-> *** THIS PROGRAM IS DEPRECATED ***
[14:47] <Peace-> This program is only provided for compatibility and will be removed in a future release. Please use avconv instead.
[14:48] <infinity> Peace-: Yes... And?
[14:48] <Peace-> infinity: and it doesnt work at all
[14:48] <infinity> Peace-: ffmpeg is deprecated, not libav.
[14:48] <Peace-> infinity: really ? i can compile ffmpeg
[14:48] <Peace-> why i have to be forced to use avconv?
[14:49] <rbasak> ogra_: I've filed bug 1035269 - please could you take a look when you can?
[14:51] <Peace-> i think the guys i have made this shit is very stupid , if you like use avconv but you should not force people to use it instead of ffmpeg that is currently developed
[14:51] <Peace-> then when yoi install ffmpeg
[14:51] <Peace-> you get that is not ffmpeg
[14:52] <infinity> Peace-: Take it up with libav/ffmpeg upstream.  And please keep the anger and profanity to a minimum.
[14:52] <Peace-> infinity: ffmpeg is developed
[14:52] <Peace-> so it's not a ffmpeg issue
[14:52] <Peace-> but a distro issue
[14:52] <Peace-> and there is no way to get the real ffmpeg on ubuntu right now
[14:52] <Peace-> you have to git clone and compile it
[14:53] <rbasak> Isn't that decision made by debian and not ubuntu?
[14:54] <Peace-> debian is ubuntu  ?
[14:54] <Peace-> at least someone should provide a ffmpeg version on ubuntu
[14:54] <rbasak> ubuntu is derived from debian.
[14:55] <Peace-> so it's not debian
[14:55] <Peace-> i use ubuntu , so i ask in the ubuntu channel
[14:55] <Peace-> really i use kubuntu but this is a shell program btw
[14:56] <rbasak> Your request to do something different in Ubuntu than Debian is valid, but I'm not sure it's worth maintaining such a big difference from Debian over this.
[14:56] <ScottK> Peace-: When I suggested you ask here, I was anticipating you'd do it more politely and productively.
[14:56] <rbasak> Since any difference needs to be supported and maintained.
[14:56] <Peace-> ScottK: i have lost hours to do my software
[14:57] <ScottK> And since the people who do the maintenance work on both distros are the same people, it'd be really odd for them to change.
[14:57] <Peace-> and now i find out that there is no way for users to get the ffmpeg
[14:57] <Peace-> and here they are saying to ask to debian ?
[14:57] <Peace-> bah
[14:57] <ScottK> Peace-: I understand frustration, but incivility is not productive.  It doesn't help solve your problem.
[14:57] <rbasak> You'd need to achieve consensus about this kind of change before it'll happen. The people with the biggest voices are the people who actually do the maintenance work.
[14:58] <ScottK> Peace-: I think what you ought to do is figure out how to support both libav and ffmpeg.  The reason I suggested talking to siretart is he might have a suggestion on how to go about that.
[14:58] <Peace-> ScottK: incivility is to say it's not an ubuntu issue
[14:59] <Peace-> or if i have a problem i should ask to debian devel
[14:59] <ScottK> It's not an area we're likely to diverge from Debian on.
[14:59] <rbasak> I did not say that it's not an Ubuntu issue. I said that the primary decision is made on Debian, and for Ubuntu to diverge is exceptional.
[14:59] <rbasak> (and unlikely)
[14:59] <Peace-> you have not to diverge , there is ffmpeg => install ffmpeg , you wann avconv install avconv
[15:00] <Peace-> but here if you install ffmpeg you get avconv 0_0
[15:00] <infinity> It's not that simple, with the switch to libav as a backend provider.
[15:01] <infinity> Though, I'm sure there are ways to make ffmpeg and libav coexist in peaceful harmony, no one's put that work in, that I know of.
[15:01] <Chipzz> Peace-: from the looks of it you get a malfunctioning ffmpeg, but you don't get avconv?
[15:01] <rbasak> I understand your frustration, but the primary place to fix it on Debian, since most changes on Debian propogate to Ubuntu (and I think this would), and we try to stay as close to what Debian do as possible.
[15:01] <siretart> Peace-: the 'ffmpeg' package in ubuntu exists only for transitional to help programs that are already in ubuntu. it will go away in the near future
[15:02] <Chipzz> siretart: was there a transitional period were ffmpeg simply emitted a warning instead of not working? or is that what it currently does?
[15:02] <Peace-> rbasak: i don't think i can get any support in debian btw
[15:03] <Peace-> Chipzz: it works but doesn't recognize some options
[15:03] <Peace-> it's a complete mess
[15:03] <siretart> Chipzz: no, it does not.
[15:03] <Chipzz> Peace-: I don't know how it was lately, but ffmpeg has never been known for their stable API. maybe this is a problem with upstream instead of with ubuntu?
[15:04] <siretart> Chipzz: it simply did not receive any updates. this was done to ensure that *existing*, packaged programs break
[15:04] <Chipzz> siretart: wait, am I reading this right? you want to ENSURE breakage?
[15:04] <vibhav> Are there any *easy* "C oriented" bugs that one can help in Ubuntu?
[15:04] <siretart> Chipzz: the ffmpeg program nowadays received a number of command line updates that requires changes to existing programs that we package. it's all about compatibility
[15:05] <siretart> sorry
[15:05] <Peace-> siretart:  Chipzz [mpeg2video @ 0x8558e60] Unable to parse option value "mv0"
[15:05] <siretart> Chipzz: it simply did not receive any updates. this was done to ensure that *existing*, packaged programs *do not* break
[15:05] <Peace-> and that string worked before
[15:05] <Chipzz> ah, ensuring breakage would be quite baffling
[15:05] <Peace-> anyway
[15:05] <siretart> Peace-: this is not the best place to discuss individual bugs.
[15:06] <Chipzz> Peace-: the ffmpeg maintainers were infamous for breaking stuff in the past. who's to say the problem isn't upstream?
[15:06] <Peace-> Chipzz: the main stuff has always worked
[15:07] <Chipzz> Peace-: from what I understand of this discussion, there's 2 issues: a) ffmpeg breaking some command line options and b) ffmpeg being deprecated and ubuntu *WARNING* about that
[15:07] <mpt> vibhav, <https://bugs.launchpad.net/ubuntu/+bugs?field.tag=bitesize> is a list of bugs that have been marked as easy. I don't know of any simple way of telling which packages are written in C and which aren't.
[15:07] <Peace-> no the issue it's that i want ffmpeg instead i get another stuff
[15:07] <Chipzz> Peace-: not 100% sure I'm getting this right, but I don't think the warning causes the breakage
[15:08] <Chipzz> Peace-: no you didn't. you got a version of ffmpeg where a couple of options have been broken
[15:08] <Peace-> you can joke as you want
[15:09] <vibhav> mpt: let me see
[15:09] <Chipzz> I'm not joking. you however are misstating the facts
[15:09] <Peace-> but the stuff it's this change in this section is a very mess
[15:09] <mpt> vibhav, but once you have bzr installed, "bzr branch lp:ubuntu/name-of-package" will get you a copy of the package to look for yourself.
[15:09] <vibhav> mpt: yeah, I know that :)
[15:09] <mpt> ok :-)
[15:09] <ogra_> rbasak, hrm, you dont use normal server images i guess ... good catch, the diversion should actually only show up when live installer is used ... seems it doesnt
[15:10] <rbasak> ogra_: thanks, shall I leave it with you?
[15:10] <rbasak> ogra_: you can reproduce on highbank in our lab
[15:11] <rbasak> ogra_: or me or mahmoh can test for you if you like
[15:11] <ogra_> rbasak, err, wait, flash-kernel-installer actually removes the diversion before running
[15:11] <cjwatson> ogra_: the diversion ought to work with or without live-installer - that was certainly my intention when I suggested this approach
[15:11] <ogra_> (and i see it doing that properly in your syslog
[15:11] <ogra_> )
[15:11] <rbasak> I can't figure out why update-initramfs does nothing, or whether the kernel postinst ends up not calling it
[15:11] <ogra_> cjwatson, yeah, i was mislead, its all fine on the flash-kernel side
[15:11] <rbasak> Either way, it doesn't seem to end up running
[15:12] <ogra_> Aug 10 14:34:06 in-target: Can't find /boot/vmlinuz-3.5.0-9-highbank or /boot/initrd.img-3.5.0-9-highbank
[15:12] <ogra_> Aug 10 14:34:06 flash-kernel-installer: error: flash-kernel failed
[15:12] <cjwatson> rbasak: the intention is for it to do nothing until the installer is ready for it to do something
[15:12] <ogra_> i would assume this is the reason
[15:12] <rbasak> ogra_: the reason is far above that
[15:12] <cjwatson> rbasak: no
[15:12] <rbasak> no?
[15:12] <rbasak> At the stage that flash-kernel runs, the initrd doesn't exist
[15:12] <cjwatson> rbasak: the behaviour at the base system installation step is intentional
[15:12] <cjwatson> the initramfs is supposed to be generated later
[15:13] <rbasak> cjwatson: ok, understood
[15:13] <rbasak> at what point should it be generated?
[15:13] <ogra_> i guess f-k-i should run update-initramfs before running flash-kernel here
[15:13] <cjwatson> right about the point that it's failing
[15:13] <ogra_> (or not run f-k at all and just raly on the trigger)
[15:13] <ogra_> *rely
[15:13] <cjwatson> ogra_: agreed, it should run update-initramfs I think
[15:13] <rbasak> So it's still a bug in flash-kernel?
[15:13] <cjwatson> rbasak: yes
[15:14] <ogra_> rbasak, right, just in a different place
[15:14] <cjwatson> ogra_: well, it may need to think a bit to work out which kernel to run u-i for
[15:14] <cjwatson> since I suspect -u won't work, as there's no initramfs yet
[15:14] <ogra_> right, but there will only be one kernel
[15:14] <rbasak> Yes - I tried -u manually after the install failed, IIRC.
[15:14] <ogra_> and it has version detection code
[15:14] <cjwatson> ah, of course, I had seen
[15:15] <cjwatson>                 in-target update-initramfs -u || true
[15:15] <ogra_> update-initramfs -c && flash-kernel i guess ...
[15:15] <cjwatson> and forgotten that that would now be insufficient
[15:15] <cjwatson> I think you should amend that line to check for the no-initramfs-yet case
[15:15] <ogra_> (-c doesnt call the hook (upstream decision))
[15:15] <rbasak> I'm at the failure point now, I can easily test something
[15:15] <rbasak> One question: can I get in-target to print output to the console? It redirects to syslog it seems right now
[15:16] <cjwatson> flash-kernel-installer.postinst already takes care of running flash-kernel later, so I don't think you need to worry about whether the hook is called or not
[15:16] <ogra_> ah, yeah
[15:16] <cjwatson> rbasak: for all the stuff here, you can just run chroot /target ...
[15:16] <ogra_> (the above was from top of my head)
[15:16] <rbasak> cjwatson: that's what I did but then it complains about /sys, so I had to bind mount that
[15:16] <rbasak> I'll do that :)
[15:16] <cjwatson> rbasak: although you can use in-target --pass-stdout
[15:16] <cjwatson> which is the direct answer to your question
[15:17] <rbasak> in-target --pass-stdout update-initramfs -u returns nothing
[15:17] <rbasak> but doesn't create the initrd
[15:17] <cjwatson> I wouldn't expect it to
[15:17] <ogra_> you need -c and the version
[15:17] <rbasak> right
[15:17] <ogra_> in-target --pass-stdout update-initramfs -c $(uname -r)
[15:18] <cjwatson> With -v, it would say "Nothing to do, exiting."
[15:18] <mahmoh> well, a link to the non-existent initrd is created
[15:18] <rbasak> http://paste.ubuntu.com/1139416/
[15:18] <arges> micahg, hello. I think I have a backport bug properly formatted, was wondering if you could take a look at pad.lv/943502 to see if this can be put into the queue. thanks
[15:18] <ogra_> rbasak, try -c -v
[15:19] <rbasak> ogra_: no joy: http://paste.ubuntu.com/1139424/
[15:20] <cjwatson> think you need -k $(uname -r)
[15:20] <ogra_> oh ... yeah
[15:21] <ogra_> or -k all
[15:21] <rbasak> in-target --pass-stdout update-initramfs -c -v -k $(uname -r) worked
[15:21] <ogra_> -k all should actually be fine so we dont need to rely on versions in that call and leave it to u-i
[15:22] <rbasak> Agreed - but to test I'll want to redo the test from scratch
[15:22] <ogra_> do that :)
[15:22] <rbasak> I'm on it :)
[15:23] <ogra_> though its really intresting that apparently -u behavior changed
[15:23] <ogra_> in the past it just created one as if you had called -c
[15:24] <rbasak> It was news to me that -u even existed, but I might be misremembering
[15:24] <ogra_> -u is used since forever
[15:24] <rbasak> IIRC I just ran update-initramfs and it updated it as per the name
[15:24] <cjwatson> update-initramfs -u has been there forever, and I'm not sure I agree with ogra_'s recollection :)
[15:24] <ogra_> cjwatson, i know i could use it with just -u in lucid at least
[15:24] <ogra_> it behaved like -c -k all
[15:25]  * rbasak clearly doesn't run update-initramfs very often
[15:25] <ogra_> (that was always my workaround for upstream refusing to call triggers from -c)
[15:25] <cjwatson> just looking at the oldest version I can find and I don't see this
[15:25] <cjwatson> are you absolutely sure that in such cases an initramfs didn't exist already?
[15:26] <ogra_> not absolutely, no
[15:27] <cjwatson> update-initramfs -u has always picked one of the currently-existing initramfses to update if not told explicitly (exactly which one it picks has changed), but I don't see that it ever updated all of them
[15:28] <mahmoh> cjwatson: quick ?: do you know of a way to force patman's last partition to a fixed size - avoid filling the disk?
[15:29] <cjwatson> mahmoh: you must create a dummy partition at the end, and then remove it in a manner of your choice at the end of install (preseed/late_command or whatever)
[15:29] <cjwatson> there is no way to do this natively in partman, I'm afraid
[15:29] <cjwatson> I mean, without such a hack
[15:29] <ogra_> cjwatson, oh, i didnt say that, i said it created one if there wasnt one
[15:29] <cjwatson> ogra_: I looked at the version in lucid and don't see that :)
[15:29] <mahmoh> cjwatson: thx, just confirming the hack I guess :) :(
[15:30] <ogra_> cjwatson, hmm, that one has set_initramfs() ?
[15:30] <cjwatson> ogra_: after the [ -z "${version}" ]
[15:30] <ogra_> it might have been a bug that it did create them but i'm pretty sure i used -u to create one for ac100
[15:31]  * ogra_ also remembers that he was wondering for years why -c exists 
[15:34] <mahmoh> cjwatson: what's a reliable way to remove a partition from the installer env?
[15:35] <rbasak> parted /dev/sda rm 4? But it's not in the installer and I'm not sure sfdisk is either
[15:35] <cjwatson> yeah it is
[15:35] <cjwatson> anna-install parted-udeb
[15:36] <cjwatson> and then, yes, you probably want to use parted for this; it will involve accurately predicting the disk name and partition number I'm afraid
[15:37] <mahmoh> cjwatson: thx
[15:38] <rbasak> parse /target/etc/fstab, perhaps?
[15:38] <rbasak> But a bit horrible to detect UUID= and LABEL= and I have no idea if /dev/disk/by-uuid will exist
[15:38] <cjwatson> You probably don't want the dummy partition to be in /target/etc/fstab
[15:38] <cjwatson> Since you wouldn't want to give it a mountpoint
[15:39] <rbasak> I was going to look for another partition that is mounted on the same target disk
[15:39] <cjwatson> Ah, yeah, could do.  /dev/disk/by-uuid/ will exist
[15:39] <cjwatson> Might be easier to just df /target or something
[15:39] <rbasak> Good point
[15:39] <cjwatson> Or grep ' /target ' /proc/mounts
[15:40] <mahmoh> if by-label exists I can just use that
[15:40] <cjwatson> Whatever the syntax is
[15:40] <cjwatson> by-label exists
[15:40] <mahmoh> sweet
[15:41] <cjwatson> Er, I'm not sure partman lets you assign labels though?
[15:41] <mahmoh> it does
[15:42] <mahmoh> label{ DELETEME }
[15:42] <cjwatson> Ah yes
[15:42] <cjwatson> Hidden off in the per-fs code so I didn't notice it
[15:43] <rbasak> Good news, everyone! http://paste.ubuntu.com/1139467/ - "in-target --pass-stdout update-initramfs -c -k all" works as expected.
[15:45] <cjwatson> Lose the --pass-stdout for production code of course
[15:45] <cjwatson> Is it intentional that there's no suffix on the initramfs there?
[15:45]  * cjwatson doesn't know the subarch configuration here
[15:46] <rbasak> I'm not sure what you mean. But something didn't work. I see an initrd in /target/boot, but the installer still fails, which it didn't do last time
[15:47] <rbasak> Err, no it didn't create an initrd. I saw the vmlinuz-... and assumed
[15:47] <rbasak> It does return exit status 0 though
[15:47] <arges> hello. whats the process to get a new package added? looking to get a version of libhugetlbfs in lucid. i see its in natty onwards (and it cleanly can be built with backportpackage)
[15:48] <rbasak> With -v, "Nothing to do, exiting."
[15:48] <rbasak> So the only known way right now is with -k $(uname -r)
[15:49] <rbasak> "The use of "all" for the version string specifies update-initramfs to execute the  chosen  action  for all kernel versions, that are already known to update-initramfs.". I suppose update-initramfs doesn't yet know about this kernel, so we do need to use -k $(uname -r)?
[15:50] <rbasak> arges: do you know about https://wiki.ubuntu.com/UbuntuBackports?
[15:50] <arges> rbasak, yea I was going to do a backport... but the package doesn't exist in lucid at all... wasn't sure of the right path
[15:51] <arges> looks like the code hasn't changed in a while, as all version from natty->quantal are the same
[15:51] <rbasak> I think that's OK but I'm not sure
[15:51] <stgraber> stokachu: your branch is based on the wrong bzr branch. As that's a desktop package, the base is lp:~ubuntu-desktop/gnome-vfs/ubuntu
[15:51] <stgraber> stokachu: the diff applies cleanly on it, so I'm just going to merge it into that one for you
[15:51] <rbasak> ogra_: ^^
[15:52] <ogra_> rbasak, hmpf, i just uploaded with -k all
[15:52] <rbasak> ogra_: sorry
[15:53] <ogra_> rbasak, did you start the install from scratch fixing f-k-i before you did hit the error ?
[15:54] <ogra_> i know sometimes there are bindmounts of dev sys and proc in /target after an error occured that can make the installer fall over
[15:54] <rbasak> ogra_: I reinstalled from scratch, hit the error, and then -k all doesn't create the initrd even though I said it did earlier because I didn't look carefully (sorry).
[15:54] <rbasak> I did only in-target --pass-stdout update-initramfs -c -k all
[15:54] <rbasak> Last time, it did work with -k $(uname -r)
[15:55] <rbasak> I can reinstall from scratch again if you like to verify and make certain? It's all scripted so isn't any trouble, just takes half an hour
[15:55] <ogra_> rbasak, if you could inject the fix before it errors, that would be good
[15:56] <rbasak> ogra_: at what stage exactly?
[15:56] <ogra_> i dont see a reason why all wouldnt work
[15:56] <rbasak> We did just enable ssh so I can do that
[15:56] <ogra_> any stage before f-k-i gets called
[15:56] <ogra_> just to avoid it hitting the error
[15:56] <rbasak> OK but after the kernel gets installed I presume
[15:57] <rbasak> We have remote syslog working too so I should be able to manage that
[15:57] <ogra_> indeed :)
[15:57] <rbasak> Just to be sure, you mean to ssh and try "in-target update-initramfs -c -k all" after kernel install and before f-k-i?
[15:57] <ogra_> well, you will just edit f-k-i.postinst i guess
[15:57] <ogra_> you shoudl be able to do that at any time once the f-k-i.udeb is in place
[15:58] <rbasak> With -k all or -k $(uname -r)?
[15:58] <stgraber> stokachu: uploaded to quantal
[15:58] <ogra_> doesnt matter if teher is a kernel already ... as long as the fix and kernel are there if it gets executred :)
[15:58] <ogra_> rbasak, -k all please
[15:59] <rbasak> ogra_: any particular place in the postinst?
[15:59] <ogra_> we know that $(uname -r) works, but update-initramfs has its own version detection logic i would like to use instead of hardcoding for the boot kernel d-i uses
[15:59] <stokachu> stgraber: thanks
[15:59] <ogra_> rbasak, http://paste.ubuntu.com/1139494/
[15:59] <rbasak> ogra_: right
[16:00] <ogra_> rbasak, in the fs you will find it in /var/lib/dpkg/info/flash-kernel-installer.postinst
[16:00] <rbasak> ogra_: thanks
[16:00] <ogra_> (and you have to use nano, no vi in d-i)
[16:00] <rbasak> aargh
[16:00] <rbasak> That might be tricky
[16:00]  * rbasak will see what he can do :-)
[16:01] <ogra_> haha, nano isnt that bad :)
[16:01] <ogra_> (i agree its not fun either)
[16:02] <stokachu> stgraber: https://bugs.launchpad.net/ubuntu/precise/+source/libart-lgpl/+bug/977964 i think this one is ready to go as well
[16:03]  * rbasak considers submitting a vi udeb
[16:05] <stgraber> stokachu: ok. I'll push gnome-vfs and that one to precise-proposed then
[16:05] <stgraber> stokachu: gnome-vfs should be identical to the quantal upload I just did right? (except for the release and pocket)
[16:05] <stokachu> stgraber: exactly
[16:06] <stgraber> stokachu: ok, gnome-vfs uploaded to precise-proposed then
[16:06] <ogra_> rbasak, i would be surprised if cjwatson didnt acutally have a vi.udeb given he is an extensive user ;)
[16:06] <stokachu> stgraber: sweet :D
[16:08] <cjwatson> ogra_: you'd be surprised, then :)
[16:08] <cjwatson> I do use vi extensively but I have to cope with minimal environments often enough that I've learned to (barely) tolerate nano
[16:09] <ogra_> heh
[16:09] <rbasak> So my first nano problem isi that I didn't know how to jump to line 71, so I hope I've applied ogra's patch in the right place :)
[16:09]  * rbasak grepped the file afterwards to make sure
[16:09] <rbasak> Change injected, now waiting for the install to finish
[16:09] <ogra_> there is only one actual update-initramfs call in the script
[16:09] <ogra_> (the second mentioning is a comment)
[16:10] <ogra_> as long as the line you changed ends in || true ... all is fine
[16:10] <rbasak> Yeah that what the grep was for - to check :)
[16:10] <rbasak> http://paste.ubuntu.com/1139512/
[16:10] <cjwatson> I occasionally use extremely obscure sed invocations instead of nano
[16:10]  * rbasak did consider that just now
[16:11] <rbasak> I wonder if there's a patch to sed converter
[16:12] <stgraber> stokachu: debdiff in the libart bug isn't up to date. Can you attach one with the bug reference?
[16:13] <stokachu> stgraber: instead of the MP?
[16:13] <stokachu> ill do whatever you prefer
[16:14] <stgraber> stokachu: oh, I missed that it had a MP
[16:14] <stgraber> stokachu: sorry, will use that then
[16:14] <stokachu> stgraber: thats cool i just linked the related branch a min ago into the bug
[16:14] <ScottK> cyphermox: re Bug #1030316 - Postfix upstream has already decided it's the client's responsibility to convert the domain to punycode, so if it stays a postfix but, I'll have to mark it wontfix.  I think it should stay with evolution, but didn't want to just revert your change without discussing.
[16:14] <ogra_> rbasak, heh so instead of changing the existing call you added an update-initramfs call
[16:14] <ogra_> shouldnt do any harm though
[16:15] <rbasak> ogra_: really?
[16:15] <rbasak> ogra_: I don't see it
[16:15] <ogra_> you seem to have edited around line 30
[16:15] <stokachu> stgraber: shit i didnt update my maintainer email for that changelog
[16:15] <stokachu> lol
[16:15] <ogra_> the actual call is around line 74
[16:15] <stgraber> stokachu: that's fine, I fixed it ;)
[16:16] <stgraber> stokachu: you also forgot to run update-maintainer and the version should have been ubuntu0.1
[16:16] <ogra_> or your serial output simply messed it up or so
[16:16] <stokachu> stgraber: or update-maintainer
[16:16] <stokachu> stgraber: err yea you got it faster than me
[16:16] <rbasak> I did it via ssh
[16:16] <rbasak> http://paste.ubuntu.com/1139512/
[16:16] <stgraber> stokachu: resulting debdiff, let me know if that looks good: http://paste.ubuntu.com/1139518/
[16:16] <stokachu> stgraber: lol thanks i rushed it
[16:17] <stokachu> stgraber: looks good
[16:17] <stgraber> uploaded
[16:17] <stokachu> you da man
[16:17] <stokachu> stgraber: do these MP's automatically get flagged as uploaded
[16:17] <stokachu> or is it still a manual process
[16:18] <rbasak> ogra_: AFAICT the edit I intended is consistent with the grep output
[16:18] <rbasak> Though I admit I have no idea what line number I edited since I presume ^G doesn't work in nano!
[16:19] <cjwatson> ^C
[16:19] <rbasak> thanks
[16:19] <rbasak> Line 74 then
[16:19] <ogra_> oh
[16:19] <stgraber> stokachu: hmm, nope. Let me mark it as merged
[16:20] <ogra_> sorry, blind me i didnt get thats a grep
[16:20] <ogra_> i cought that was a copy/paste from your nano session
[16:20] <rbasak> Ah
[16:20] <stgraber> stokachu: they get marked as merged automatically when they are actually merged. Which isn't the case for these ubuntu-desktop branches or for SRUs
[16:20] <ogra_> so it looked pretty weird how the functions were suddenly merged into one :P
[16:20] <rbasak> No - I just did the grep to make sure there weren't any other similar occurrences because I didn't know what line number I was on
[16:21] <rbasak> tell you what:
[16:21] <rbasak> f5cbd5a8ff6202eca1a28187138d9e96  flash-kernel-installer.postinst
[16:21] <rbasak> :)
[16:21] <ogra_> heh
[16:22] <rbasak> "Making the system bootable"
[16:22] <ogra_> ogra@anubis:~/Devel/packages/flash-kernel-3.0~rc.4ubuntu18$ md5sum debian/flash-kernel-installer.postinst
[16:22] <ogra_> f5cbd5a8ff6202eca1a28187138d9e96  debian/flash-kernel-installer.postinst
[16:22] <ogra_> :)
[16:22] <rbasak> 33%
[16:22] <rbasak> !! ERROR: Installation step failed
[16:22] <rbasak> :-(
[16:23] <ogra_> rbasak, syslog please
[16:23] <rbasak> on its way
[16:24] <ogra_> thx
[16:25] <stokachu> stgraber: ok cool
[16:25] <rbasak> ogra_: http://paste.ubuntu.com/1139531/
[16:26] <bkerensa> bzr: ERROR: These branches have diverged.  See "bzr help diverged-branches" for more information.
[16:26] <bkerensa> No branches have diverged?
[16:26] <ogra_> rbasak, i dont see it running at all
[16:27] <rbasak> ogra_: line 3017?
[16:27] <ogra_> thats the fallout
[16:27] <rbasak> well with -k all, it doesn't produce any output
[16:27] <rbasak> since it considers there to be nothing to do
[16:28] <rbasak> which we see if we add -v. Is this what you mean?
[16:28] <ogra_> hmpf, ok, i'll switch to $(uname -r)
[16:28] <rbasak> ok
[16:30] <ogra_> uploaded
[16:30] <rbasak> ogra_: thanks! sorry for the extra upload
[16:31] <ogra_> well, i still would like to have -k all working ... but thats for later :)
[16:34] <stokachu> cjwatson: any feedback on latest comment on https://bugs.launchpad.net/ubuntu/+source/netcf/+bug/904014
[16:34] <rbasak> OK :)
[16:34] <rbasak> EOD
[16:37] <cjwatson> stokachu: I've followed up
[16:38] <cjwatson> stokachu: make sense?
[16:39] <stokachu> cjwatson: i think so :)
[16:40] <stokachu> cjwatson: i think there is a huge user base that would benefit from having precise updated , at least by this bug https://bugs.launchpad.net/ubuntu/+source/libvirt/+bug/520386
[16:44] <cjwatson> stokachu: although I'm on ubuntu-sru, I don't do a whole lot of SRU processing in practice, so in this case I'm probably not the one you need to convince
[16:44] <cjwatson> stokachu: for the purpose of this bug I'm basically the archive robot
[16:45] <cjwatson> stokachu: have a look through https://wiki.ubuntu.com/StableReleaseUpdates and see if you can come up with a justification that matches the "When" section there
[16:47] <cyphermox> ScottK: np.
[16:47] <ScottK> cyphermox: I'll switch it back then.
[16:47] <cyphermox> I'll ship that upstream
[16:47] <ScottK> Upstream evolution, right?
[16:47] <cyphermox> yeah
[16:47] <ScottK> cyphermox: Here's a reference: http://tech.groups.yahoo.com/group/postfix-users/message/266018
[16:48] <ScottK> The poster is one of the two main postfix devs.
[16:48] <cyphermox> alright
[16:49] <ScottK> Thanks.
[16:50] <cyphermox> ScottK: are you switching it back to evolution?
[16:50] <ScottK> I will.
[16:51] <ScottK> cyphermox: Done
[17:02] <stokachu> cjwatson: ok will do, thanks for the tip
[17:22] <micahg> arges: you can't backport from quantal straight to oneiric, you can to backport through precise
[17:22] <micahg> arges: requestbackport in ubuntu-dev-tools will tell you what you need to do if you pass it the proper options
[17:22] <arges> micahg, ok with this particular package i had to fix something with the debian/rules file upstream. that was fixed and put into quantal
[17:23] <arges> micahg, so do I need to apply that fix to precise, then backport to oneiric?
[17:24] <micahg> arges: you can backport to precise and then oneiric, or SRU to precise if appropriate and backport that to oneiric
[17:27] <arges> micahg, the change, btw, is to debian/rules because this package likes to check the version string and fail if it doesn't match. so I 'm guessing this is an SRU to precise to fix debain/rules rather than a backport
[17:32] <micahg> arges: right, I remember that
[17:33] <micahg> arges: so, the package currently in precise won't build if updated without this fix?
[17:34] <arges> micahg, we can only backport from quantal because that version has the proper debian/rules version regexp
[17:34] <micahg> arges: right, but for oneiric, you can only backport from a pocket in precise, so, you have to get it there one way or another
[17:35] <arges> micahg, ok so if i backport from quantal to precise. then i can backport the backport? : )
[17:35] <micahg> right :)
[17:35] <arges> okey dokey
[17:36] <micahg> arges: well, it ends up a no change backport from quantal, but you have to keep the upgrade path, that's the concept
[17:36] <arges> should i make a new bug for this? or just use the existing one?
[17:36] <micahg> arges: 'requestbackport -d oneiric -s quantal whois'  might make it clearer what work needs to be done
[17:37] <arges> micahg, also. the version string is 'whois_5.0.17' in quantal. the backportpackage appends ~series1  but shouldn't it append -ubuntu1~series1 ?
[17:37] <micahg> arges: it'll now be ~ubuntuXX.XX
[17:38] <arges> micahg, ok i'll get that going then. thanks
[17:38] <micahg> arges: you can use backportpackage to test what the version will be
[17:38] <micahg> arges: actually, quantal has 5.0.18
[17:41] <arges> micahg,  whois_5.0.18~precise1 is what it does
[17:42] <micahg> arges: you have an old version :)
[17:42] <arges> micahg, i'm on my precise desktop... will move to quantal laptop
[17:42] <micahg> arges: I use the u-d-t PPA
[17:42]  * micahg is still on precise
[17:42] <arges> micahg, cool adding ppa now thanks
[17:58] <arges> micahg, so there is a new naming convention for backports? the version regex i changed assumed the form -ubuntuX~series1  vs ~ubuntu12.04.1 ... so should I ask upstream guy to change the version string again (or ask that it be removed)? or is there a way I can patch debian/rules for  ubuntu?
[17:59] <cjwatson> the new naming convention is ~ubuntu12.04.1 tc.
[17:59] <cjwatson> *etc.
[17:59] <micahg> arges: I thought we discussed making it more generic...
[17:59] <cjwatson> use quantal's requestbackport
[17:59] <cjwatson> or backportpackage or whatever it is
[17:59] <micahg> arges: if it's that fragile, it's still broke IMHO
[17:59] <arges> cjwatson, yes normally it would work, but for this particular package it has a regex that checks for the version string
[18:00] <arges> micahg, yea I agree
[18:00] <arges> time to submit a patch
[18:00] <cjwatson> what I mean is that if it's assuming the form ~ubuntu12.04.1 then it's correct (modulo fragility)
[18:00] <cjwatson> it's not clear which side of your "versus" is which :)
[18:00]  * cjwatson -> dinner
[18:22] <Sweetshark> cjwatson: what was that magic source again I needed for async binary package copies?
[18:39] <cjwatson> Sweetshark: join the ~launchpad-beta-testers team and you can do it in the web UI
[18:39] <cjwatson> Sweetshark: https://blog.launchpad.net/general/beta-test-asynchronous-ppa-package-copies
[18:39] <Sweetshark> cjwatson: done, thanks!
[18:40] <cjwatson> just another couple of bugs to fix (which shouldn't affect you) and I think we can roll that out to everyone
[18:40] <Sweetshark> cjwatson: /me mumbles the inofficial libreoffice motto: "LibreOffice -- based on code breaking your toolchain since 1985"
[18:41] <Sweetshark> cjwatson: lets see what injuries we can do to launchpad with this ultimate testcase.
[18:41] <cjwatson> the bugs I know about only happen if the copies fail for some other reason :)
[18:49] <shadeslayer> cjwatson: kudos to the guys who implemented async copy
[18:51] <cjwatson> shadeslayer: does it work well for you then
[18:51] <cjwatson> ?
[18:51] <shadeslayer> cjwatson: yep
[18:52] <shadeslayer> I need to try copying the entire kde binaries though ...
[18:52] <cjwatson> oh good.  now if only I could reproduce the last bit of bug 1031092 in the test suite
[18:52] <cjwatson> I can make it happen in production, but ...
[18:52] <shadeslayer> cjwatson: before async copying, the kubuntu team wrote scripts to copy entire releases from one ppa to another
[18:53] <shadeslayer> just because lp went, "No, you're doing that wrong, it's 5 packages at a time"
[18:53] <cjwatson> yeah
[18:53] <cjwatson> you can still use copy-package in lp:ubuntu-archive-tools if you prefer scripting to the web
[18:53] <cjwatson> or indeed the Archive.copyPackage API call directly
[18:54] <shadeslayer> uh ok, I don't think anyone of us knew about copy-package ....
[18:54]  * shadeslayer looks
[18:54] <cjwatson> it's relatively new
[18:54] <shadeslayer> probably why
[18:54] <cjwatson> in fact part of the work in exposing this was to make Archive.copyPackage / copy-package work when the target archive is a PPA - that was previously disabled
[18:54] <shadeslayer> we've had kcopypackage for about a year now I think
[18:54] <shadeslayer> ah
[18:54] <cjwatson> does it use Archive.syncSource then?
[18:54] <shadeslayer> don't know, I'll have to look
[18:54] <cjwatson> no google hits for kcopypackage
[18:55] <shadeslayer> it's in kubuntu-dev-tools
[18:55] <shadeslayer> ah it's kopypackages
[18:55] <shadeslayer> cjwatson: http://paste.kde.org/532178
[18:56] <cjwatson> Right, syncSource.  That used to be the only option
[18:56] <shadeslayer>  target.syncSource, yeah, syncSource it is
[18:56] <cjwatson> That's the old synchronous interface
[18:57] <shadeslayer> ah
[18:57] <shadeslayer> I guess we should just use copy-packages now
[18:57] <cjwatson> You can basically s/syncSource/copyPackage/ to get the async version of the API, though if you're happy with the web UI / other tools then you may not want to bother maintaining that script
[18:58] <cjwatson> syncSource is vulnerable to timeouts on large packages, which you've probably noticed
[18:58] <cjwatson> or possibly uploads that close lots of bugs, I forget
[18:58] <lifeless> the latter
[18:58] <shadeslayer> cjwatson: the problem with the web ui is that it's not viable when you want to copy an entire PPA
[18:58] <shadeslayer> so if the webui has a "Copy everything from this ppa to target ppa"
[18:58] <shadeslayer> that would be awesome
[18:59] <shadeslayer> ( that usually happens for every KDE release that we test build and backport )
[19:00] <cjwatson> yeah, it would; I suggest filing a bug, as my work on this has largely been because it was getting in my way for other work :)
[19:00] <cjwatson> in the meantime, that's totally scriptable
[19:00] <shadeslayer> we just scripted it because we didn't expect it to be fixed soon enough
[19:00] <shadeslayer> for that matter, querying lp for recipes times out as well
[19:00] <cjwatson> I don't think anyone's filed this bug, so it's not on anyone's to-do list afai
[19:00] <cjwatson> k
[19:01] <shadeslayer> ( and a bug was filed for that as well )
[19:01] <cjwatson> perhaps because the mere notion of copying an entire PPA was utterly blocked on bug 575450
[19:01] <shadeslayer> hmm .. will do tomorrow, too tired to do right now :)
[19:01] <shadeslayer> :D
[19:01] <shadeslayer> "This bug affects you and 13 other people "
[19:01] <shadeslayer> xD
[19:01] <cjwatson> the recipes timeout is presumably bug 1009787
[19:02] <shadeslayer> yep, that's the one
[19:02] <cjwatson> which is probably beyond my SQL ability
[19:14] <sveinse> When preparing a new patch with quilt, do I always have to pre-declare (quilt add) which files I am about to change? It just feels so... cumbersome. I'd rather make quilt discover what I've done. (I'm a complete quilt noob)
[19:17] <cjwatson> sveinse: 'quilt shell'
[19:17] <jtaylor> sveinse: use a proper vcs for that
[19:18] <jtaylor> or that
[19:18] <jtaylor> I always forget quilt has that command
[19:18] <cjwatson> quilt fold is handy too if you're integrating a patch from elsewhere
[19:18] <sveinse> jtaylor: yeah, I'm preparing a patch for an existing package, so vcs isn't really an option here
[19:19] <cjwatson> but quilt shell is the swiss army knife
[19:19] <sveinse> and I can emacs in it I guess then :P
[19:20] <cjwatson> if your perversions lie in that direction
[19:21] <sveinse> lol, yeah
[19:42] <sveinse> Are there any resources available to determine if a command name is available? Beyond apt-file which lists everything?
[19:46] <roadmr> Hello! I need my application to somehow get notified when the user logs out, so it can clean up appropriately. What's the recommended way to do this?
[19:49] <infinity> roadmr: Trap SIGTERM and exit cleanly?
[19:51] <roadmr> infinity: oh so I *do* get SIGTERM on logout? that's what I was expecting but a quick experiment (trap the signal, write a file) didn't turn out anything. I must be doing it wrong...
[19:51]  * roadmr goes back to the drawing board
[19:53] <infinity> roadmr: Well, I don't know a ton about session management in the wonderful GUI world, but I assume all your children get a TERM, I can't see any other sensible way to do it.
[19:53] <slangasek> it depends
[19:53] <slangasek> you might get TERM, you might get HUP
[19:53] <slangasek> you certainly get a signal
[19:53] <infinity> slangasek: Randomly? :P
[19:53] <slangasek> *however*, if it's a shutdown, you might not get the opportunity to fully *process* that signal before the system cuts out from under you
[19:54] <infinity> There's that, yes.
[19:54] <infinity> Depending on how many milisecond you need to sort out your business.
[19:54] <slangasek> (I'm not sure how good the handling here is in e.g., lightdm)
[19:54] <roadmr> slangasek: I'm less concerned about shutdowns (the app dies anyway) than about logout/login by the same user (app doesn't shut down, then complains it's already running, confused user)
[19:54] <roadmr> slangasek: btw thanks for the SIGHUP clue, I guess I should have looked at other signals before asking :/
[19:55] <slangasek> infinity: "randomly" - depends on whether you're a child process of a shell for testing? :)
[19:55] <infinity> slangasek: If I am, my mother's been lying to me.
[20:38] <roadmr> ok so I registered a handler for all signals, then closed the session, and the handler seemingly didn't get called :/ so I wonder if maybe the applications get KILLed altogether :/
[20:41] <dobey> if your application is a gui app, you probably get a SIGPIPE when X goes away
[20:44] <roadmr> dobey: ok, I'll try that
[20:45] <slangasek> roadmr: nothing should be using SIGKILL here
[20:45] <slangasek> ... except the shutdown scripts at the very end
[20:46] <roadmr> slangasek: ok, good to know, that'd be a bit hard to handle :/
[20:50] <slangasek> SpamapS: heh, so systemd has its own version of bug #711635.  http://lists.fedoraproject.org/pipermail/devel/2012-June/169365.html
[20:50] <roadmr> slangasek, dobey: oh, I'm an idiot, my signal handler was wrong. The application got SIGHUP when I closed the session. Sorry :/ now I know what i need to handle
[21:00] <SpamapS> slangasek: yeah looks identical really. I think the workaround we came up with is pretty decent considering.
[21:01]  * slangasek nods
[22:32] <xnox> micahg: thanks for fixing up the sqlite tracker
[22:33] <micahg> xnox: no problem, that list scared me :)
[22:33] <xnox> micahg: yeah it was scary to me as well. So did the regexp catch sqlite3 as well as sqlite, before you changed it?
[22:33] <micahg> xnox: yes
[22:33] <xnox> micahg: nice to know....
[22:34] <micahg> ~ /sqlite/   matches anything with sqlite in it
[22:34]  * micahg guesses his python-sqlite entry is redundant then :)
[22:35] <micahg> I'm glad to know negative lookaheads work :)
[22:36]  * xnox 's head takes a few human seconds to parse lookaheads though
[22:38] <micahg> xnox: there's a performance penalty in general with them, but it seemed to make sense here
[22:39] <xnox> micahg: it's only a tracker =) but the green ones - means that it's spurious dependencies that can/should/must be dropped
[22:39] <xnox> ?
[22:39] <xnox> (which verb do you choose?)
[22:39] <micahg> xnox: green is because good == true
[22:39] <xnox> micahg: but the package is affected.
[22:40] <xnox> micahg: so why is it still listing sqlite2 build-deps
[22:40] <micahg> no, most likely if it's green, it means it's an alternate build dependency or not built on that arch
[22:40] <xnox> ok
[22:40] <micahg> xnox: hrm?  not understanding the question...
[22:41] <xnox> it needs checking, in case if it's not an alternate build-dep, and we want to remove sqlite2 from the archive
[22:41] <xnox> it will need fixing.
[22:43] <micahg> let me make it not show green...
[22:47] <micahg> xnox: ok, the next refresh should get rid of the green
[22:48] <xnox> micahg: great it will be unknown instead, perfect =)
[22:48] <micahg> grr...silly redundancy, we
[22:48] <micahg> *we'll just call it clarity :)
[23:40] <cjwatson> Sweetshark: so did your libreoffice copies work out?  I'm not seeing a record of them in the logs ...
[23:46] <xnox> micahg: but now we have a split between green and unknown! more information =)
[23:47] <micahg> xnox: hrm? looks fine to me
[23:48] <micahg> xnox: unknown stuff means no binary bad stuff, but possible build-depends bad
[23:48] <xnox> micahg: well gentle has alternative build deps and ends up build against sqlite3
[23:48] <xnox> micahg: the rest, yes as you said
[23:48] <micahg> xnox: which is why it's good :)
[23:48] <xnox> previously we had 6 green =) now we have 1 green and 5 investigations ;-)
[23:49] <xnox> hence the comment "more information!" =)
[23:49] <micahg> which probably just means that --as-needed is doing its job and the build dependencies need to be updated
[23:52]  * micahg -> off now until Sat night
[23:54] <jocarter> have a good weekend micahg