infinity | ScottK: Use deborphan, and tell it to keep ubuntu-standard, perhaps? | 00:11 |
---|---|---|
=== 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 | ||
tjaalton | any sru-team members around? | 04:53 |
=== cpg|away is now known as cpg | ||
dholbach | good morning | 07:25 |
=== mcclurmc_away is now known as mcclurmc | ||
=== yofel_ is now known as yofel | ||
=== zya-afk is now known as zyga | ||
slomo | infinity: gstreamer1.0 should build fine now (just uploaded -2) | 11:09 |
=== cpg is now known as cpg|away | ||
=== mdeslaur_ is now known as mdeslaur | ||
infinity | slomo: Thanks! | 11:36 |
=== larsu_ is now known as larsu | ||
=== mcclurmc is now known as mcclurmc_away | ||
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:10 |
Sweetshark | seb128: for bug 1034558 and bug 1034560 we need to prepare an LO upload soon. | 12:15 |
ubottu | 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 |
ubottu | 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:15 |
seb128 | Sweetshark, don't you plan to upload 3.6 soon anyway? :-) | 12:18 |
=== _salem is now known as salem_ | ||
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:22 |
seb128 | Sweetshark, how come we won those depends between rc3 and stable? | 12:25 |
=== mcclurmc_away is now known as mcclurmc | ||
=== zyga is now known as zyga-afk | ||
Sweetshark | seb128: bug 992232 | 12:56 |
ubottu | Launchpad bug 992232 in libreoffice (Ubuntu) "no libreoffice-report-builder in precise" [Undecided,Fix released] https://launchpad.net/bugs/992232 | 12:56 |
seb128 | Sweetshark, seems like we could do longer without it and should not block 3.6 on that? | 12:57 |
Sweetshark | seb128: you mean no reportbuilder in quantal main? | 12:58 |
seb128 | Sweetshark, was it in precise main? | 12:58 |
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:00 |
seb128 | or check with the MIR team if they can review,approve that stack soon | 13:01 |
Sweetshark | IIRC there was at least on of those packages needlessly using crappy maven ... | 13:02 |
seb128 | Sweetshark, so please keep that off | 13:03 |
Sweetshark | seb128: k | 13:05 |
Sweetshark | seb128: I dropped a note in the bug. | 13:06 |
seb128 | Sweetshark, thanks | 13:07 |
=== 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 | ||
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:11 |
xnox | micahg: http://people.canonical.com/~ubuntu-archive/transitions/sqlite.html | 14:13 |
xnox | micahg: 37 packages should drop build-deps? 245 are still to fix? | 14:14 |
stgraber | stokachu: can you paste me that URL again? | 14:19 |
stokachu | sure | 14:19 |
stokachu | stgraber: https://code.launchpad.net/~adam-stokes/ubuntu/quantal/gnome-vfs/lp977940-multiarch/+merge/114258 | 14:20 |
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:27 |
=== dholbach_ is now known as dholbach | ||
=== doko__ is now known as doko | ||
Peace- | hi | 14:45 |
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:46 |
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:47 |
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:48 |
rbasak | ogra_: I've filed bug 1035269 - please could you take a look when you can? | 14:49 |
ubottu | Launchpad bug 1035269 in flash-kernel (Ubuntu) "highbank quantal installer regression" [Undecided,New] https://launchpad.net/bugs/1035269 | 14:49 |
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:51 |
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:52 |
rbasak | Isn't that decision made by debian and not ubuntu? | 14:53 |
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:54 |
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:55 |
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:56 |
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:57 |
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:58 |
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 | 14:59 |
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:00 |
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:01 |
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:02 |
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 |
=== dendrobates is now known as dendro-afk | ||
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:03 |
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:04 |
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:05 |
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:06 |
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:07 |
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:08 |
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:09 |
rbasak | ogra_: thanks, shall I leave it with you? | 15:10 |
rbasak | ogra_: you can reproduce on highbank in our lab | 15:10 |
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:11 |
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:12 |
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:13 |
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:14 |
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:15 |
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:16 |
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:17 |
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:18 |
rbasak | ogra_: no joy: http://paste.ubuntu.com/1139424/ | 15:19 |
cjwatson | think you need -k $(uname -r) | 15:20 |
ogra_ | oh ... yeah | 15:20 |
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:21 |
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:22 |
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:23 |
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:24 |
* 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:25 |
ogra_ | not absolutely, no | 15:26 |
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:27 |
mahmoh | cjwatson: quick ?: do you know of a way to force patman's last partition to a fixed size - avoid filling the disk? | 15:28 |
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:29 |
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:30 |
* ogra_ also remembers that he was wondering for years why -c exists | 15:31 | |
mahmoh | cjwatson: what's a reliable way to remove a partition from the installer env? | 15:34 |
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:35 |
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:36 |
mahmoh | cjwatson: thx | 15:37 |
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:38 |
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:39 |
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:40 |
cjwatson | Er, I'm not sure partman lets you assign labels though? | 15:41 |
mahmoh | it does | 15:41 |
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:42 |
rbasak | Good news, everyone! http://paste.ubuntu.com/1139467/ - "in-target --pass-stdout update-initramfs -c -k all" works as expected. | 15:43 |
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:45 | |
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:46 |
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:47 |
rbasak | With -v, "Nothing to do, exiting." | 15:48 |
rbasak | So the only known way right now is with -k $(uname -r) | 15:48 |
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:49 |
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:50 |
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:51 |
=== dendro-afk is now known as dendrobates | ||
ogra_ | rbasak, hmpf, i just uploaded with -k all | 15:52 |
rbasak | ogra_: sorry | 15:52 |
ogra_ | rbasak, did you start the install from scratch fixing f-k-i before you did hit the error ? | 15:53 |
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:54 |
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:55 |
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:56 |
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:57 |
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:58 |
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 | 15:59 |
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:00 | |
ogra_ | haha, nano isnt that bad :) | 16:01 |
ogra_ | (i agree its not fun either) | 16:01 |
stokachu | stgraber: https://bugs.launchpad.net/ubuntu/precise/+source/libart-lgpl/+bug/977964 i think this one is ready to go as well | 16:02 |
ubottu | Launchpad bug 977964 in libart-lgpl (Ubuntu Precise) "Please transition libart-lgpl to multi-arch" [Medium,In progress] | 16:02 |
* rbasak considers submitting a vi udeb | 16:03 | |
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:05 |
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:06 |
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:08 |
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:09 |
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:10 | |
rbasak | I wonder if there's a patch to sed converter | 16:11 |
stgraber | stokachu: debdiff in the libart bug isn't up to date. Can you attach one with the bug reference? | 16:12 |
stokachu | stgraber: instead of the MP? | 16:13 |
stokachu | ill do whatever you prefer | 16:13 |
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 |
ubottu | Launchpad bug 1030316 in postfix (Ubuntu) "evolution don't hadle IDN-Mail adresses" [Undecided,New] https://launchpad.net/bugs/1030316 | 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:14 |
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:15 |
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:16 |
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:17 |
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:18 |
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:19 |
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:20 |
rbasak | tell you what: | 16:21 |
rbasak | f5cbd5a8ff6202eca1a28187138d9e96 flash-kernel-installer.postinst | 16:21 |
rbasak | :) | 16:21 |
ogra_ | heh | 16:21 |
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 |
ubottu | rbasak: I am only a bot, please don't think I'm intelligent :) | 16:22 |
rbasak | :-( | 16:22 |
ogra_ | rbasak, syslog please | 16:23 |
rbasak | on its way | 16:23 |
ogra_ | thx | 16:24 |
stokachu | stgraber: ok cool | 16:25 |
rbasak | ogra_: http://paste.ubuntu.com/1139531/ | 16:25 |
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:26 |
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:27 |
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:28 |
ogra_ | uploaded | 16:30 |
rbasak | ogra_: thanks! sorry for the extra upload | 16:30 |
ogra_ | well, i still would like to have -k all working ... but thats for later :) | 16:31 |
stokachu | cjwatson: any feedback on latest comment on https://bugs.launchpad.net/ubuntu/+source/netcf/+bug/904014 | 16:34 |
ubottu | Launchpad bug 904014 in netcf (Ubuntu Quantal) "[MIR] netcf" [Medium,Fix released] | 16:34 |
rbasak | OK :) | 16:34 |
rbasak | EOD | 16:34 |
cjwatson | stokachu: I've followed up | 16:37 |
cjwatson | stokachu: make sense? | 16:38 |
stokachu | cjwatson: i think so :) | 16:39 |
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:40 |
ubottu | 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:40 |
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:44 |
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:45 |
=== dendrobates is now known as dendro-afk | ||
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:47 |
ScottK | The poster is one of the two main postfix devs. | 16:48 |
cyphermox | alright | 16:48 |
ScottK | Thanks. | 16:49 |
=== dendro-afk is now known as dendrobates | ||
cyphermox | ScottK: are you switching it back to evolution? | 16:50 |
ScottK | I will. | 16:50 |
ScottK | cyphermox: Done | 16:51 |
=== henrix_ is now known as henrix | ||
=== mcclurmc is now known as mcclurmc_away | ||
stokachu | cjwatson: ok will do, thanks for the tip | 17:02 |
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:22 |
arges | micahg, so do I need to apply that fix to precise, then backport to oneiric? | 17:23 |
micahg | arges: you can backport to precise and then oneiric, or SRU to precise if appropriate and backport that to oneiric | 17:24 |
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:27 |
micahg | arges: right, I remember that | 17:32 |
micahg | arges: so, the package currently in precise won't build if updated without this fix? | 17:33 |
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:34 |
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:35 |
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:36 |
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:37 |
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:38 |
arges | micahg, whois_5.0.18~precise1 is what it does | 17:41 |
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:42 |
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:58 |
=== cpg|away is now known as cpg | ||
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 | 17:59 |
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:00 | |
Sweetshark | cjwatson: what was that magic source again I needed for async binary package copies? | 18:22 |
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:39 |
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:40 |
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:41 |
shadeslayer | cjwatson: kudos to the guys who implemented async copy | 18:49 |
cjwatson | shadeslayer: does it work well for you then | 18:51 |
cjwatson | ? | 18:51 |
shadeslayer | cjwatson: yep | 18:51 |
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 |
ubottu | Launchpad bug 1031092 in Launchpad itself "OOPSing PPA async copy shows no failure reason in web UI" [Critical,In progress] https://launchpad.net/bugs/1031092 | 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:52 |
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:53 |
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:54 |
shadeslayer | it's in kubuntu-dev-tools | 18:55 |
shadeslayer | ah it's kopypackages | 18:55 |
shadeslayer | cjwatson: http://paste.kde.org/532178 | 18:55 |
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:56 |
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:57 |
=== cpg is now known as cpg|away | ||
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:58 |
shadeslayer | ( that usually happens for every KDE release that we test build and backport ) | 18:59 |
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:00 |
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 |
ubottu | Launchpad bug 575450 in Launchpad itself "Archive:+copy-packages nearly unusable due to timeouts" [Critical,In progress] https://launchpad.net/bugs/575450 | 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:01 |
ubottu | Launchpad bug 1009787 in Launchpad itself "timeout querying archives for recipes via API" [Critical,Triaged] https://launchpad.net/bugs/1009787 | 19:01 |
shadeslayer | yep, that's the one | 19:02 |
cjwatson | which is probably beyond my SQL ability | 19:02 |
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:14 |
cjwatson | sveinse: 'quilt shell' | 19:17 |
jtaylor | sveinse: use a proper vcs for that | 19:17 |
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:18 |
cjwatson | but quilt shell is the swiss army knife | 19:19 |
sveinse | and I can emacs in it I guess then :P | 19:19 |
cjwatson | if your perversions lie in that direction | 19:20 |
sveinse | lol, yeah | 19:21 |
sveinse | Are there any resources available to determine if a command name is available? Beyond apt-file which lists everything? | 19:42 |
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:46 |
infinity | roadmr: Trap SIGTERM and exit cleanly? | 19:49 |
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:51 | |
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:53 |
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:54 |
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. | 19:55 |
=== yofel_ is now known as yofel | ||
=== dendrobates is now known as dendro-afk | ||
=== dendro-afk is now known as dendrobates | ||
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:38 |
dobey | if your application is a gui app, you probably get a SIGPIPE when X goes away | 20:41 |
roadmr | dobey: ok, I'll try that | 20:44 |
slangasek | roadmr: nothing should be using SIGKILL here | 20:45 |
slangasek | ... except the shutdown scripts at the very end | 20:45 |
roadmr | slangasek: ok, good to know, that'd be a bit hard to handle :/ | 20:46 |
slangasek | SpamapS: heh, so systemd has its own version of bug #711635. http://lists.fedoraproject.org/pipermail/devel/2012-June/169365.html | 20:50 |
ubottu | Launchpad bug 711635 in mysql-5.1 (Ubuntu Oneiric) "init: post-start can cause respawn to hang" [High,Triaged] https://launchpad.net/bugs/711635 | 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 | 20:50 |
=== dendrobates is now known as dendro-afk | ||
SpamapS | slangasek: yeah looks identical really. I think the workaround we came up with is pretty decent considering. | 21:00 |
* slangasek nods | 21:01 | |
=== dendro-afk is now known as dendrobates | ||
=== JanC_ is now known as JanC | ||
=== dendrobates is now known as dendro-afk | ||
=== salem_ is now known as _salem | ||
xnox | micahg: thanks for fixing up the sqlite tracker | 22:32 |
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:33 |
micahg | ~ /sqlite/ matches anything with sqlite in it | 22:34 |
* micahg guesses his python-sqlite entry is redundant then :) | 22:34 | |
micahg | I'm glad to know negative lookaheads work :) | 22:35 |
* xnox 's head takes a few human seconds to parse lookaheads though | 22:36 | |
micahg | xnox: there's a performance penalty in general with them, but it seemed to make sense here | 22:38 |
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 |
=== cpg|away is now known as cpg | ||
xnox | micahg: but the package is affected. | 22:39 |
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:40 |
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:41 |
micahg | let me make it not show green... | 22:43 |
micahg | xnox: ok, the next refresh should get rid of the green | 22:47 |
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 :) | 22:48 |
cjwatson | Sweetshark: so did your libreoffice copies work out? I'm not seeing a record of them in the logs ... | 23:40 |
xnox | micahg: but now we have a split between green and unknown! more information =) | 23:46 |
micahg | xnox: hrm? looks fine to me | 23:47 |
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:48 |
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:49 |
* micahg -> off now until Sat night | 23:52 | |
jocarter | have a good weekend micahg | 23:54 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!