[00:11] ScottK: Use deborphan, and tell it to keep ubuntu-standard, perhaps? === cpg is now known as cpg|away === james is now known as Guest15651 === mdeslaur_ is now known as mdeslaur === cpg|away is now known as cpg === plars_ is now known as plars === cpg is now known as cpg|away [04:53] any sru-team members around? === cpg|away is now known as cpg [07:25] good morning === mcclurmc_away is now known as mcclurmc === yofel_ is now known as yofel === zya-afk is now known as zyga [11:09] infinity: gstreamer1.0 should build fine now (just uploaded -2) === cpg is now known as cpg|away === mdeslaur_ is now known as mdeslaur [11:36] slomo: Thanks! === larsu_ is now known as larsu === mcclurmc is now known as mcclurmc_away [12:10] 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] seb128: for bug 1034558 and bug 1034560 we need to prepare an LO upload soon. [12:15] Launchpad bug 1034558 in pentaho-reporting-flow-engine (Ubuntu) "[MIR] libbase-java, libsac-java, libxml-java, libflute-java, libpentaho-reporting-flow-engine-java, liblayout-java" [Undecided,New] https://launchpad.net/bugs/1034558 [12:15] Launchpad bug 1034560 in libserializer (Ubuntu) "[MIR] libloader-java, libformula-java, librepository-java, libfonts-java, libserializer-java " [Undecided,New] https://launchpad.net/bugs/1034560 [12:18] Sweetshark, don't you plan to upload 3.6 soon anyway? :-) === _salem is now known as salem_ [12:22] 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] Sweetshark, how come we won those depends between rc3 and stable? === mcclurmc_away is now known as mcclurmc === zyga is now known as zyga-afk [12:56] seb128: bug 992232 [12:56] Launchpad bug 992232 in libreoffice (Ubuntu) "no libreoffice-report-builder in precise" [Undecided,Fix released] https://launchpad.net/bugs/992232 [12:57] Sweetshark, seems like we could do longer without it and should not block 3.6 on that? [12:58] seb128: you mean no reportbuilder in quantal main? [12:58] Sweetshark, was it in precise main? [13:00] seb128: no but they bitched me in doing an extra ppa rebuilding full LibreOffice only for this small extension [13:00] Sweetshark, well, it's not a regression then, I would recommend you keep it off until the MIRs are resolved [13:01] or check with the MIR team if they can review,approve that stack soon [13:02] IIRC there was at least on of those packages needlessly using crappy maven ... [13:03] Sweetshark, so please keep that off [13:05] seb128: k [13:06] seb128: I dropped a note in the bug. [13:07] Sweetshark, thanks === zyga-afk is now known as zyga === james is now known as Guest53826 === Quintasan_ is now known as Quintasan === dendro-afk is now known as dendrobates [14:11] 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] micahg: http://people.canonical.com/~ubuntu-archive/transitions/sqlite.html [14:14] micahg: 37 packages should drop build-deps? 245 are still to fix? [14:19] stokachu: can you paste me that URL again? [14:19] sure [14:20] stgraber: https://code.launchpad.net/~adam-stokes/ubuntu/quantal/gnome-vfs/lp977940-multiarch/+merge/114258 [14:27] 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. === dholbach_ is now known as dholbach === doko__ is now known as doko [14:45] hi [14:46] why in the world if i install ffmpeg i get ffmpeg from libav that is deprecated? [14:46] ogra_: ping [14:46] my software are all messed up [14:46] rbasak, on the phone atm ... [14:47] ogra_: ok, np [14:47] ogra_: for when you're done... I think your recent flash-kernel changes might have caused a regression [14:47] Peace-: Since when is libav deprecated...? [14:47] infinity: [14:47] ffmpeg version 0.8.3-4:0.8.3-0ubuntu3, Copyright (c) 2000-2012 the Libav developers [14:47] built on Jul 30 2012 22:10:17 with gcc 4.7.1 [14:47] *** THIS PROGRAM IS DEPRECATED *** [14:47] This program is only provided for compatibility and will be removed in a future release. Please use avconv instead. [14:48] Peace-: Yes... And? [14:48] infinity: and it doesnt work at all [14:48] Peace-: ffmpeg is deprecated, not libav. [14:48] infinity: really ? i can compile ffmpeg [14:48] why i have to be forced to use avconv? [14:49] ogra_: I've filed bug 1035269 - please could you take a look when you can? [14:49] Launchpad bug 1035269 in flash-kernel (Ubuntu) "highbank quantal installer regression" [Undecided,New] https://launchpad.net/bugs/1035269 [14:51] 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] then when yoi install ffmpeg [14:51] you get that is not ffmpeg [14:52] Peace-: Take it up with libav/ffmpeg upstream. And please keep the anger and profanity to a minimum. [14:52] infinity: ffmpeg is developed [14:52] so it's not a ffmpeg issue [14:52] but a distro issue [14:52] and there is no way to get the real ffmpeg on ubuntu right now [14:52] you have to git clone and compile it [14:53] Isn't that decision made by debian and not ubuntu? [14:54] debian is ubuntu ? [14:54] at least someone should provide a ffmpeg version on ubuntu [14:54] ubuntu is derived from debian. [14:55] so it's not debian [14:55] i use ubuntu , so i ask in the ubuntu channel [14:55] really i use kubuntu but this is a shell program btw [14:56] 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] Peace-: When I suggested you ask here, I was anticipating you'd do it more politely and productively. [14:56] Since any difference needs to be supported and maintained. [14:56] ScottK: i have lost hours to do my software [14:57] 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] and now i find out that there is no way for users to get the ffmpeg [14:57] and here they are saying to ask to debian ? [14:57] bah [14:57] Peace-: I understand frustration, but incivility is not productive. It doesn't help solve your problem. [14:57] 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] 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] ScottK: incivility is to say it's not an ubuntu issue [14:59] or if i have a problem i should ask to debian devel [14:59] It's not an area we're likely to diverge from Debian on. [14:59] 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] (and unlikely) [14:59] you have not to diverge , there is ffmpeg => install ffmpeg , you wann avconv install avconv [15:00] but here if you install ffmpeg you get avconv 0_0 [15:00] It's not that simple, with the switch to libav as a backend provider. [15:01] 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] Peace-: from the looks of it you get a malfunctioning ffmpeg, but you don't get avconv? [15:01] 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] 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] 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] rbasak: i don't think i can get any support in debian btw [15:03] Chipzz: it works but doesn't recognize some options [15:03] it's a complete mess [15:03] Chipzz: no, it does not. === dendrobates is now known as dendro-afk [15:03] 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] Chipzz: it simply did not receive any updates. this was done to ensure that *existing*, packaged programs break [15:04] siretart: wait, am I reading this right? you want to ENSURE breakage? [15:04] Are there any *easy* "C oriented" bugs that one can help in Ubuntu? [15:04] 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] sorry [15:05] siretart: Chipzz [mpeg2video @ 0x8558e60] Unable to parse option value "mv0" [15:05] Chipzz: it simply did not receive any updates. this was done to ensure that *existing*, packaged programs *do not* break [15:05] and that string worked before [15:05] ah, ensuring breakage would be quite baffling [15:05] anyway [15:05] Peace-: this is not the best place to discuss individual bugs. [15:06] Peace-: the ffmpeg maintainers were infamous for breaking stuff in the past. who's to say the problem isn't upstream? [15:06] Chipzz: the main stuff has always worked [15:07] 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] vibhav, 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] no the issue it's that i want ffmpeg instead i get another stuff [15:07] Peace-: not 100% sure I'm getting this right, but I don't think the warning causes the breakage [15:08] Peace-: no you didn't. you got a version of ffmpeg where a couple of options have been broken [15:08] you can joke as you want [15:09] mpt: let me see [15:09] I'm not joking. you however are misstating the facts [15:09] but the stuff it's this change in this section is a very mess [15:09] 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] mpt: yeah, I know that :) [15:09] ok :-) [15:09] 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] ogra_: thanks, shall I leave it with you? [15:10] ogra_: you can reproduce on highbank in our lab [15:11] ogra_: or me or mahmoh can test for you if you like [15:11] rbasak, err, wait, flash-kernel-installer actually removes the diversion before running [15:11] ogra_: the diversion ought to work with or without live-installer - that was certainly my intention when I suggested this approach [15:11] (and i see it doing that properly in your syslog [15:11] ) [15:11] I can't figure out why update-initramfs does nothing, or whether the kernel postinst ends up not calling it [15:11] cjwatson, yeah, i was mislead, its all fine on the flash-kernel side [15:11] Either way, it doesn't seem to end up running [15:12] 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] Aug 10 14:34:06 flash-kernel-installer: error: flash-kernel failed [15:12] rbasak: the intention is for it to do nothing until the installer is ready for it to do something [15:12] i would assume this is the reason [15:12] ogra_: the reason is far above that [15:12] rbasak: no [15:12] no? [15:12] At the stage that flash-kernel runs, the initrd doesn't exist [15:12] rbasak: the behaviour at the base system installation step is intentional [15:12] the initramfs is supposed to be generated later [15:13] cjwatson: ok, understood [15:13] at what point should it be generated? [15:13] i guess f-k-i should run update-initramfs before running flash-kernel here [15:13] right about the point that it's failing [15:13] (or not run f-k at all and just raly on the trigger) [15:13] *rely [15:13] ogra_: agreed, it should run update-initramfs I think [15:13] So it's still a bug in flash-kernel? [15:13] rbasak: yes [15:14] rbasak, right, just in a different place [15:14] ogra_: well, it may need to think a bit to work out which kernel to run u-i for [15:14] since I suspect -u won't work, as there's no initramfs yet [15:14] right, but there will only be one kernel [15:14] Yes - I tried -u manually after the install failed, IIRC. [15:14] and it has version detection code [15:14] ah, of course, I had seen [15:15] in-target update-initramfs -u || true [15:15] update-initramfs -c && flash-kernel i guess ... [15:15] and forgotten that that would now be insufficient [15:15] I think you should amend that line to check for the no-initramfs-yet case [15:15] (-c doesnt call the hook (upstream decision)) [15:15] I'm at the failure point now, I can easily test something [15:15] One question: can I get in-target to print output to the console? It redirects to syslog it seems right now [15:16] 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] ah, yeah [15:16] rbasak: for all the stuff here, you can just run chroot /target ... [15:16] (the above was from top of my head) [15:16] cjwatson: that's what I did but then it complains about /sys, so I had to bind mount that [15:16] I'll do that :) [15:16] rbasak: although you can use in-target --pass-stdout [15:16] which is the direct answer to your question [15:17] in-target --pass-stdout update-initramfs -u returns nothing [15:17] but doesn't create the initrd [15:17] I wouldn't expect it to [15:17] you need -c and the version [15:17] right [15:17] in-target --pass-stdout update-initramfs -c $(uname -r) [15:18] With -v, it would say "Nothing to do, exiting." [15:18] well, a link to the non-existent initrd is created [15:18] http://paste.ubuntu.com/1139416/ [15:18] 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] rbasak, try -c -v [15:19] ogra_: no joy: http://paste.ubuntu.com/1139424/ [15:20] think you need -k $(uname -r) [15:20] oh ... yeah [15:21] or -k all [15:21] in-target --pass-stdout update-initramfs -c -v -k $(uname -r) worked [15:21] -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] Agreed - but to test I'll want to redo the test from scratch [15:22] do that :) [15:22] I'm on it :) [15:23] though its really intresting that apparently -u behavior changed [15:23] in the past it just created one as if you had called -c [15:24] It was news to me that -u even existed, but I might be misremembering [15:24] -u is used since forever [15:24] IIRC I just ran update-initramfs and it updated it as per the name [15:24] update-initramfs -u has been there forever, and I'm not sure I agree with ogra_'s recollection :) [15:24] cjwatson, i know i could use it with just -u in lucid at least [15:24] it behaved like -c -k all [15:25] * rbasak clearly doesn't run update-initramfs very often [15:25] (that was always my workaround for upstream refusing to call triggers from -c) [15:25] just looking at the oldest version I can find and I don't see this [15:25] are you absolutely sure that in such cases an initramfs didn't exist already? [15:26] not absolutely, no [15:27] 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] cjwatson: quick ?: do you know of a way to force patman's last partition to a fixed size - avoid filling the disk? [15:29] 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] there is no way to do this natively in partman, I'm afraid [15:29] I mean, without such a hack [15:29] cjwatson, oh, i didnt say that, i said it created one if there wasnt one [15:29] ogra_: I looked at the version in lucid and don't see that :) [15:29] cjwatson: thx, just confirming the hack I guess :) :( [15:30] cjwatson, hmm, that one has set_initramfs() ? [15:30] ogra_: after the [ -z "${version}" ] [15:30] 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] cjwatson: what's a reliable way to remove a partition from the installer env? [15:35] parted /dev/sda rm 4? But it's not in the installer and I'm not sure sfdisk is either [15:35] yeah it is [15:35] anna-install parted-udeb [15:36] 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] cjwatson: thx [15:38] parse /target/etc/fstab, perhaps? [15:38] But a bit horrible to detect UUID= and LABEL= and I have no idea if /dev/disk/by-uuid will exist [15:38] You probably don't want the dummy partition to be in /target/etc/fstab [15:38] Since you wouldn't want to give it a mountpoint [15:39] I was going to look for another partition that is mounted on the same target disk [15:39] Ah, yeah, could do. /dev/disk/by-uuid/ will exist [15:39] Might be easier to just df /target or something [15:39] Good point [15:39] Or grep ' /target ' /proc/mounts [15:40] if by-label exists I can just use that [15:40] Whatever the syntax is [15:40] by-label exists [15:40] sweet [15:41] Er, I'm not sure partman lets you assign labels though? [15:41] it does [15:42] label{ DELETEME } [15:42] Ah yes [15:42] Hidden off in the per-fs code so I didn't notice it [15:43] Good news, everyone! http://paste.ubuntu.com/1139467/ - "in-target --pass-stdout update-initramfs -c -k all" works as expected. [15:45] Lose the --pass-stdout for production code of course [15:45] Is it intentional that there's no suffix on the initramfs there? [15:45] * cjwatson doesn't know the subarch configuration here [15:46] 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] Err, no it didn't create an initrd. I saw the vmlinuz-... and assumed [15:47] It does return exit status 0 though [15:47] 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] With -v, "Nothing to do, exiting." [15:48] So the only known way right now is with -k $(uname -r) [15:49] "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] arges: do you know about https://wiki.ubuntu.com/UbuntuBackports? [15:50] 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] looks like the code hasn't changed in a while, as all version from natty->quantal are the same [15:51] I think that's OK but I'm not sure [15:51] 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] stokachu: the diff applies cleanly on it, so I'm just going to merge it into that one for you [15:51] ogra_: ^^ === dendro-afk is now known as dendrobates [15:52] rbasak, hmpf, i just uploaded with -k all [15:52] ogra_: sorry [15:53] rbasak, did you start the install from scratch fixing f-k-i before you did hit the error ? [15:54] 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] 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] I did only in-target --pass-stdout update-initramfs -c -k all [15:54] Last time, it did work with -k $(uname -r) [15:55] 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] rbasak, if you could inject the fix before it errors, that would be good [15:56] ogra_: at what stage exactly? [15:56] i dont see a reason why all wouldnt work [15:56] We did just enable ssh so I can do that [15:56] any stage before f-k-i gets called [15:56] just to avoid it hitting the error [15:56] OK but after the kernel gets installed I presume [15:57] We have remote syslog working too so I should be able to manage that [15:57] indeed :) [15:57] 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] well, you will just edit f-k-i.postinst i guess [15:57] you shoudl be able to do that at any time once the f-k-i.udeb is in place [15:58] With -k all or -k $(uname -r)? [15:58] stokachu: uploaded to quantal [15:58] doesnt matter if teher is a kernel already ... as long as the fix and kernel are there if it gets executred :) [15:58] rbasak, -k all please [15:59] ogra_: any particular place in the postinst? [15:59] 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] stgraber: thanks [15:59] rbasak, http://paste.ubuntu.com/1139494/ [15:59] ogra_: right [16:00] rbasak, in the fs you will find it in /var/lib/dpkg/info/flash-kernel-installer.postinst [16:00] ogra_: thanks [16:00] (and you have to use nano, no vi in d-i) [16:00] aargh [16:00] That might be tricky [16:00] * rbasak will see what he can do :-) [16:01] haha, nano isnt that bad :) [16:01] (i agree its not fun either) [16:02] stgraber: https://bugs.launchpad.net/ubuntu/precise/+source/libart-lgpl/+bug/977964 i think this one is ready to go as well [16:02] Launchpad bug 977964 in libart-lgpl (Ubuntu Precise) "Please transition libart-lgpl to multi-arch" [Medium,In progress] [16:03] * rbasak considers submitting a vi udeb [16:05] stokachu: ok. I'll push gnome-vfs and that one to precise-proposed then [16:05] stokachu: gnome-vfs should be identical to the quantal upload I just did right? (except for the release and pocket) [16:05] stgraber: exactly [16:06] stokachu: ok, gnome-vfs uploaded to precise-proposed then [16:06] rbasak, i would be surprised if cjwatson didnt acutally have a vi.udeb given he is an extensive user ;) [16:06] stgraber: sweet :D [16:08] ogra_: you'd be surprised, then :) [16:08] 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] heh [16:09] 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] Change injected, now waiting for the install to finish [16:09] there is only one actual update-initramfs call in the script [16:09] (the second mentioning is a comment) [16:10] as long as the line you changed ends in || true ... all is fine [16:10] Yeah that what the grep was for - to check :) [16:10] http://paste.ubuntu.com/1139512/ [16:10] I occasionally use extremely obscure sed invocations instead of nano [16:10] * rbasak did consider that just now [16:11] I wonder if there's a patch to sed converter [16:12] stokachu: debdiff in the libart bug isn't up to date. Can you attach one with the bug reference? [16:13] stgraber: instead of the MP? [16:13] ill do whatever you prefer [16:14] stokachu: oh, I missed that it had a MP [16:14] stokachu: sorry, will use that then [16:14] stgraber: thats cool i just linked the related branch a min ago into the bug [16:14] 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] Launchpad bug 1030316 in postfix (Ubuntu) "evolution don't hadle IDN-Mail adresses" [Undecided,New] https://launchpad.net/bugs/1030316 [16:14] rbasak, heh so instead of changing the existing call you added an update-initramfs call [16:14] shouldnt do any harm though [16:15] ogra_: really? [16:15] ogra_: I don't see it [16:15] you seem to have edited around line 30 [16:15] stgraber: shit i didnt update my maintainer email for that changelog [16:15] lol [16:15] the actual call is around line 74 [16:15] stokachu: that's fine, I fixed it ;) [16:16] stokachu: you also forgot to run update-maintainer and the version should have been ubuntu0.1 [16:16] or your serial output simply messed it up or so [16:16] stgraber: or update-maintainer [16:16] stgraber: err yea you got it faster than me [16:16] I did it via ssh [16:16] http://paste.ubuntu.com/1139512/ [16:16] stokachu: resulting debdiff, let me know if that looks good: http://paste.ubuntu.com/1139518/ [16:16] stgraber: lol thanks i rushed it [16:17] stgraber: looks good [16:17] uploaded [16:17] you da man [16:17] stgraber: do these MP's automatically get flagged as uploaded [16:17] or is it still a manual process [16:18] ogra_: AFAICT the edit I intended is consistent with the grep output [16:18] Though I admit I have no idea what line number I edited since I presume ^G doesn't work in nano! [16:19] ^C [16:19] thanks [16:19] Line 74 then [16:19] oh [16:19] stokachu: hmm, nope. Let me mark it as merged [16:20] sorry, blind me i didnt get thats a grep [16:20] i cought that was a copy/paste from your nano session [16:20] Ah [16:20] 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] so it looked pretty weird how the functions were suddenly merged into one :P [16:20] 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] tell you what: [16:21] f5cbd5a8ff6202eca1a28187138d9e96 flash-kernel-installer.postinst [16:21] :) [16:21] heh [16:22] "Making the system bootable" [16:22] ogra@anubis:~/Devel/packages/flash-kernel-3.0~rc.4ubuntu18$ md5sum debian/flash-kernel-installer.postinst [16:22] f5cbd5a8ff6202eca1a28187138d9e96 debian/flash-kernel-installer.postinst [16:22] :) [16:22] 33% [16:22] !! ERROR: Installation step failed [16:22] rbasak: I am only a bot, please don't think I'm intelligent :) [16:22] :-( [16:23] rbasak, syslog please [16:23] on its way [16:24] thx [16:25] stgraber: ok cool [16:25] ogra_: http://paste.ubuntu.com/1139531/ [16:26] bzr: ERROR: These branches have diverged. See "bzr help diverged-branches" for more information. [16:26] No branches have diverged? [16:26] rbasak, i dont see it running at all [16:27] ogra_: line 3017? [16:27] thats the fallout [16:27] well with -k all, it doesn't produce any output [16:27] since it considers there to be nothing to do [16:28] which we see if we add -v. Is this what you mean? [16:28] hmpf, ok, i'll switch to $(uname -r) [16:28] ok [16:30] uploaded [16:30] ogra_: thanks! sorry for the extra upload [16:31] well, i still would like to have -k all working ... but thats for later :) [16:34] cjwatson: any feedback on latest comment on https://bugs.launchpad.net/ubuntu/+source/netcf/+bug/904014 [16:34] Launchpad bug 904014 in netcf (Ubuntu Quantal) "[MIR] netcf" [Medium,Fix released] [16:34] OK :) [16:34] EOD [16:37] stokachu: I've followed up [16:38] stokachu: make sense? [16:39] cjwatson: i think so :) [16:40] 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:40] Launchpad bug 520386 in libvirt (Ubuntu Quantal) "libvirt-bin hypervisor does not support virConnectNumOfInterfaces / unable to create domain with virt-manager using network bridge" [High,Fix released] [16:44] 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] stokachu: for the purpose of this bug I'm basically the archive robot [16:45] 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 === dendrobates is now known as dendro-afk [16:47]