| infinity | apw: Your kernel build's been rescued and should be happy soon. | 00:19 |
|---|---|---|
| infinity | ScottK: Ditto with kdevelop. | 00:19 |
| bkerensa | https://bugs.launchpad.net/ubuntu/+source/bluez/+bug/952694 | 03:05 |
| ubottu | Launchpad bug 952694 in bluez (Ubuntu) "Toggling Bluetooth off also Disables Wifi Networking (Wifi Hardware Switched Off)" [Undecided,New] | 03:05 |
| ScottK | infinity: Thanks. | 03:33 |
| pitti | Good morning | 05:55 |
| jalcine | Heh, it's very early over here :) almost 2 AM. | 05:57 |
| pitti | dupondje: split needs an FFE bug, there we can review debdiffs etc. | 05:58 |
| pitti | dupondje: if the -bin package doesn't change the boot process (that's the point of it), and it has proper breaks:/replaces, it's safe | 05:58 |
| pitti | apw: do you know why these kernel modules on http://people.canonical.com/~ubuntu-archive/component-mismatches.txt want to go to universe? apparently they are not covered by linux-meta? | 06:03 |
| pitti | apw: it'd be a _lot_ easier to have all binaries in main | 06:04 |
| pitti | mixed main/universe is a real dealbreaker for our current kernel SRU process, as PPAs don't have components | 06:04 |
| pitti | geser: done | 06:06 |
| === jalcine is now known as webjadmin_ | ||
| vibhav | How Do I download a git patch? | 06:14 |
| vibhav | (https://github.com/openstack/nova/commit/74396d58810e9851a6d33aef3dc3b2185154abcb) | 06:14 |
| pitti | vibhav: github doesn't seem to support that directly; probably easiest to ctrl+mouse-mark the patch and paste it into an editor | 06:19 |
| vibhav | thanks pitti | 06:20 |
| vibhav | pitti: Is this fine then? http://paste.ubuntu.com/879972/ | 06:27 |
| pitti | vibhav: you need to remove the blank lines, but sure :) | 06:27 |
| vibhav | Do I need to remove the identation too? | 06:28 |
| pitti | yes | 06:28 |
| vibhav | Is this alright now? http://paste.ubuntu.com/879974/ | 06:30 |
| webjadmin_ | g'night | 06:31 |
| vibhav | webjadmin_: Good night | 06:31 |
| vibhav | pitti :Is this alright now? http://paste.ubuntu.com/879974/ | 06:34 |
| pitti | just try, patch will complain if it isn't :) | 06:35 |
| pitti | vibhav: sorry, actually the initial indentation was correct | 06:35 |
| vibhav | The earlier pastebin was right? | 06:36 |
| pitti | yes, except for the empty lines | 06:37 |
| pitti | vibhav: it needs to look like the web veiw | 06:37 |
| vibhav | alright | 06:38 |
| vibhav | patch: **** Only garbage was found in the patch input. | 06:40 |
| vibhav | It aint working | 06:47 |
| pitti | vibhav: probably easiest to just apply the changes manually; its' just a few changed lines after all | 06:48 |
| vibhav | pitti: I dont know how to do that :( | 06:50 |
| === jmp_ is now known as _jmp_ | ||
| dholbach | good morning | 07:54 |
| === smb` is now known as smb | ||
| apw | pitti, universe/main> erm, i presume they are threatening to move as they are LBM and not supported? what do you mean not coverered by linux-meta ? | 08:28 |
| pitti | apw: shouldn't there be some metapackage to depend on the ABI specific binaries? | 08:38 |
| apw | pitti, there cirtainly should be in all cases, though that report looks to be showing one | 08:39 |
| pitti | apw: oh, hang on -- there are the corresponding linux-meta binaries | 08:40 |
| pitti | apw: I suppose we should seed the linux-meta ones | 08:40 |
| apw | pitti, isn't the second line there all the meta packages for the ones demoting in the first | 08:40 |
| === bludude is now known as soaringsky | ||
| apw | pitti, ahh of course, the meta package has the release name in it | 08:40 |
| apw | pitti, so it'll need changing each release, i expect you have -oneiric- in oneiric | 08:41 |
| pitti | supported-kernel-common: * /^linux-(backports-modules-(headers|net)-oneiric-|headers-)?(386|cell|dove|ec2|generic|linaro-omap|linaro-vexpress|omap|omap4|armadaxp|powerpc|ps3|server|virtual).*/ | 08:41 |
| pitti | that's it | 08:41 |
| * pitti fixes | 08:41 | |
| pitti | it doesn't have -cw, but I'll add that as well | 08:42 |
| apw | pitti, thanks ... i'll poke leann to add 'get the seeds fixed' to the schedule when LBM comes alive in Q | 08:43 |
| pitti | apw: I think I got it, will check c-m in an hour | 08:45 |
| apw | pitti, thanks a lot | 08:45 |
| vibhav | shouldn't the FTBFS part in the topic be in #ubuntu-motu? | 08:49 |
| apw | is anyone else seeing delayes during boot; with a new plymouth message "waiting for network configuration" (approximatly) | 08:54 |
| pitti | apw: other than bug 949891? | 08:57 |
| ubottu | Launchpad bug 949891 in apparmor (Ubuntu Precise) "apparmor caching is not working which has severely regressed boot time" [High,Fix released] https://launchpad.net/bugs/949891 | 08:57 |
| dupondje | pitti: for cryptsetup, you prefer an extra package that just provides the bins (and conflicts cryptsetup) or a real splitted up package, where cryptsetup requires cryptsetup-bin ? :) | 08:58 |
| pitti | dupondje: the latter | 08:58 |
| pitti | cryptsetup-bin would then be in the default install | 08:58 |
| pitti | and cryptsetup would be installed by d-i if you configure encrypted disk | 08:58 |
| pitti | (just as right now) | 08:58 |
| dupondje | will check :) | 08:59 |
| pitti | a conflict is awkward and unnecessary | 08:59 |
| apw | pitti, i updated just 10m ago, so i'd expect to have that fix no? | 08:59 |
| pitti | apw: ah, then you should | 08:59 |
| pitti | apw: kernel gone from http://people.canonical.com/~ubuntu-archive/component-mismatches.txt | 08:59 |
| dupondje | most of ubuntu delta is also in debian now :) (became co-maintainer of it in debian) | 08:59 |
| pitti | ah, nice | 09:00 |
| apw | pitti, am seeing this on two machines, and was seeing it on sunday on one of them on a physically dysperate network | 09:00 |
| pitti | dupondje: I was just going to say, this should be coordinated with Debian, so that we don't carry the package split as a delta | 09:00 |
| apw | pitti, does anyone know what the message actually referes to, i've cirtainly never seen it on my network before | 09:00 |
| pitti | apw: not off-hand, no | 09:00 |
| apw | pitti, ok i'll update a test box and confirm it there (in this location) and file something | 09:01 |
| dupondje | pitti: http://artemis.dupie.be/dupondje/cryptsetup.patch what you think? :) | 09:06 |
| pitti | dupondje: needs a Breaks:/Replaces: cryptsetup (<< version_of_the_split) | 09:09 |
| pitti | dupondje: also, wrt. package description, I think it is "command line", not "commandline" | 09:10 |
| pitti | dupondje: I can't verify debian/rules just by looking, checking the binary debdiffs would be easier for taht | 09:10 |
| pitti | dupondje: but it looks fine | 09:11 |
| dupondje | was not final indeed :) will check to create a debdiff today | 09:11 |
| dupondje | also i'll add another patch that fixes a critical bug (and is only 1 line ^^) | 09:12 |
| dupondje | pitti: https://bugs.launchpad.net/ubuntu/+source/cryptsetup/+bug/343363 | 09:53 |
| ubottu | Launchpad bug 343363 in udisks (Ubuntu) "gnome functional depends on cryptsetup, but not in package management " [Low,Triaged] | 09:53 |
| dupondje | uploaded debdiff | 09:53 |
| pitti | dupondje: thanks! | 10:38 |
| pitti | dupondje: will you also push that to Debian? | 10:38 |
| kiko | hey there | 10:47 |
| kiko | anybody seeing weird font issues in the precise terminal? | 10:47 |
| ogra_ | kiko, only in my panel | 10:51 |
| ogra_ | terminals look fine here | 10:51 |
| pitti | kiko: WFM | 10:51 |
| pitti | kiko: be sure that anything that breaks gnome terminals will raise a rebellion here :) | 10:52 |
| pitti | like bug 948612 | 10:52 |
| ubottu | Launchpad bug 948612 in vte3 (Ubuntu Precise) "gnome-terminal does not scroll with mousewheel" [Medium,Fix released] https://launchpad.net/bugs/948612 | 10:52 |
| Claudinux | hi all, if a menu isn't shwon in the application menu but is visible only if i start a session in gnome-shell, the bug should be opened for unity or for the application? | 11:00 |
| geser | ogra_: like in bug #947059 or different issue? | 11:11 |
| ubottu | Launchpad bug 947059 in unity-2d (Ubuntu) "Panel fonts are green and blurry" [Undecided,Confirmed] https://launchpad.net/bugs/947059 | 11:11 |
| ogra_ | geser, same thing | 11:11 |
| ogra_ | and funny colored notifications | 11:11 |
| geser | are you using the light theme or the dark one? as I see this only with the light theme | 11:12 |
| ogra_ | light here | 11:15 |
| pitti | I'm using the bright theme (Radiance) and it's fine | 11:15 |
| ogra_ | havent cross checked with dark | 11:15 |
| geser | pitti: unity or unity-2d? | 11:16 |
| pitti | 3d | 11:18 |
| kiko | pitti, can you help me debug? this is kinda driving me crazy | 11:27 |
| kiko | pitti, what sort of settings or dotfiles might come into play? | 11:28 |
| pitti | kiko: probably better if the unity-2d guys have a look, I wouldn't know where to begin :( | 11:28 |
| kiko | pitti, for terminal? | 11:29 |
| geser | kiko: can you upload a screenshot of your terminal somewhere? | 11:30 |
| kiko | geser, pitti: http://www.async.com.br/~kiko/term.png | 11:30 |
| kiko | geser, that's a mutt threaded view | 11:30 |
| geser | and it worked before? | 11:31 |
| kiko | geser, definitely worked in natty | 11:31 |
| geser | looks interesting | 11:33 |
| kiko | geser, it happens with rxvt and xterm too | 11:34 |
| kiko | it doesn't happen with other apps that I can see: çáé | 11:34 |
| kiko | so it's something to do with fonts. but what? | 11:35 |
| kiko | lemme try and move .font* out of the way | 11:35 |
| geser | do other programs, that use line drawing /boxes work? | 11:35 |
| kiko | geser, in the terminal nothing works | 11:36 |
| kiko | even typing directly into the bash prompt | 11:36 |
| kiko | but say gvim works | 11:36 |
| kiko | it's really only to do with terminals | 11:37 |
| kiko | hmmm | 11:37 |
| kiko | what's special about rxvt, xterm and terminal | 11:38 |
| kiko | that makes it different from, say xditview or qtconfig-qt4 or chromium | 11:39 |
| geser | does it work in the real console (outside X)? | 11:40 |
| kiko | yes | 11:41 |
| * kiko installs terminator to test | 11:42 | |
| kiko | good news is that apart from this precise is killer! | 11:42 |
| kiko | fast | 11:42 |
| kiko | on my nfs-root setup | 11:42 |
| kiko | weirdly much faster in fact | 11:43 |
| kiko | geser, also busted in terminator | 11:44 |
| kiko | wtf | 11:44 |
| kiko | pitti, by looking at my screenshot anything you suggest I could investigate? | 11:44 |
| geser | it looks like mutt (and other apps emit utf-8 codes) but the terminal doesn't handle it | 11:46 |
| geser | but I don't have an idea how to verify it | 11:47 |
| dupondje | pitti: will be commited into debian, but maby there will be first a release with some bugfixes in debian, and then the split release. | 11:49 |
| dupondje | I take care we have no delta for Precise+1 :) | 11:51 |
| === MacSlow is now known as MacSlow|lunch | ||
| kiko | I think I know what's wrong | 12:10 |
| kiko | geser, locale lists everything as POSIX | 12:10 |
| kiko | found the issue | 12:12 |
| kiko | export LANG=en_US.UTF8 | 12:13 |
| kiko | how was this being set before I wonder | 12:13 |
| === _salem is now known as salem_ | ||
| ogra_ | kiko, /etc/default/locale | 12:15 |
| jalcine | kiko: perhaps via the environment? | 12:15 |
| jalcine | or in a .bashrc file? | 12:15 |
| kiko | yeah | 12:16 |
| pitti | kiko: err, a locale setting causes the screen corruption? | 12:33 |
| pitti | kiko: oh, the mutt one; yes, that's likely | 12:34 |
| pitti | dupondje: that sounds fine | 12:34 |
| dupondje | pitti: you'll sponsor it? I subscribed ubuntu-release. | 12:42 |
| pitti | dupondje: yes, can do | 12:42 |
| scott-work | cjwatson: good morning! i have added my casper.log file to bug# 923810 | 13:00 |
| scott-work | bug #923810 | 13:00 |
| ubottu | Launchpad bug 923810 in casper (Ubuntu) "preseeding passwd/user-default-groups is ineffective" [Medium,Fix released] https://launchpad.net/bugs/923810 | 13:00 |
| scott-work | i was also wondering if anyone can point me in a direction to look or talk about unreadable ubiquity installer text ala bug #952462? | 13:01 |
| ubottu | Launchpad bug 952462 in Ubuntu Studio "Ubuntustudio 12.04 installer has unreadable text" [Undecided,Confirmed] https://launchpad.net/bugs/952462 | 13:01 |
| scott-work | interestingly, this only affects the installer when choosen from the first menu, if the user lets the live FS come up and then chooses to install either from the applications menu or the "install" icon then the text appears normally | 13:02 |
| === MacSlow|lunch is now known as MacSlow | ||
| ScottK | kenvandine and/or pitti: Is someone working on getting the farsight/farstream mess worked out? | 13:07 |
| pitti | I assigned it to kenvandine | 13:08 |
| pitti | ah, he's online now | 13:08 |
| pitti | kenvandine: ^ RSVP | 13:08 |
| kenvandine | hey pitti | 13:08 |
| kenvandine | i was just reading that bug report | 13:08 |
| pitti | kenvandine: bug 952136 | 13:08 |
| ubottu | Launchpad bug 952136 in papyon (Ubuntu Precise) "libfarstream-0.1-0 not installable due to conflict with libgstfarsight0.10-0" [Critical,In progress] https://launchpad.net/bugs/952136 | 13:08 |
| pitti | kenvandine: not a good thing to upload library changes on a Friday evening :/ | 13:08 |
| pitti | kenvandine: I was wondering, is there a particular reason for the libraries to conflict? | 13:08 |
| pitti | kenvandine: even when switching papyon to farstream, it'll still cause apt to have a hard time during upgrades | 13:09 |
| kenvandine | because they both provide the same gstreamer plugins | 13:09 |
| pitti | ah | 13:09 |
| kenvandine | we should make papyon get removed i think | 13:09 |
| pitti | kenvandine: that ought to be a Breaks: then | 13:09 |
| kenvandine | telepathy-butterfly isn't really supported upstream | 13:09 |
| kenvandine | upstream switched to haze | 13:09 |
| kenvandine | i'll do that | 13:10 |
| pitti | kenvandine: i. e. add a Breaks: python-papyon somewhere? | 13:10 |
| pitti | plus removal bug plus seed fix? | 13:11 |
| kenvandine | is it seeded? | 13:11 |
| ScottK | Is there an alternative for MSN support? | 13:11 |
| ScottK | It's seeded in Kubuntu. | 13:11 |
| pitti | kenvandine: something pulls it into Kubuntu, so I guess yes | 13:11 |
| kenvandine | well actually we don't want to break papyon | 13:11 |
| ScottK | That's what broke the Kubuntu images over the weekend. | 13:11 |
| pitti | kenvandine: you need to Breaks: it if you want it removed in upgrades | 13:11 |
| pitti | and if we keep papyon, the libraries can't conflict | 13:12 |
| kenvandine | or make papyon depend on the new one | 13:12 |
| pitti | right | 13:12 |
| kenvandine | assuming it works | 13:12 |
| * kenvandine checks with upstream | 13:12 | |
| ScottK | papyon seems pretty widely used "Task: ubuntu-desktop, ubuntu-usb, kubuntu-desktop, kubuntu-full, kubuntu-active-desktop, kubuntu-active-full, kubuntu-active, edubuntu-desktop, edubuntu-usb, edubuntu-desktop-kde" | 13:13 |
| pitti | python-papyon is kubuntu and edubuntu-desktop-kde only | 13:13 |
| kenvandine | the only rdepends is telepathy-butterfly | 13:13 |
| ScottK | OK. | 13:13 |
| kenvandine | which telepathy will completely ignore now even if it is installed | 13:14 |
| pitti | right, and it seems ubuntu uses something else than butterfly for MSN | 13:14 |
| ScottK | Right. Stale cache. | 13:14 |
| kenvandine | it uses telepathy-haze now | 13:14 |
| pitti | kenvandine: then it seems we can just as well remove the package and breaks: it? | 13:14 |
| kenvandine | assuming the rdepends is accurate | 13:15 |
| kenvandine | i am surprised it was seeded directly | 13:15 |
| ScottK | pitti: Except then we lost msn support in the KDE telepathy stack (AIUI) | 13:15 |
| kenvandine | ScottK, telepathy-mission-control-5 switched to haze for MSN | 13:15 |
| kenvandine | and internally it migrates all the settings | 13:15 |
| pitti | ScottK: is libpurple too heavy for kubuntu? | 13:16 |
| kenvandine | they effectively blacklisted butterfly/papyon | 13:16 |
| ScottK | pitti: I don't know. | 13:16 |
| kenvandine | because it was breaking nearly weekly | 13:16 |
| pitti | ah no, libpurpose is alreayd on kubuntu | 13:16 |
| pitti | err, libpurple | 13:16 |
| kenvandine | hehe | 13:16 |
| pitti | so adding -haze shouldn't be a problem | 13:16 |
| ScottK | I really don't know the telepathy stuff at all. | 13:16 |
| jml | I just distupgraded and lost | 13:16 |
| jml | *ahem* | 13:16 |
| jml | I just dist-upgraded and lost unity. | 13:16 |
| ScottK | The only reason I'm caring at the moment is kenvandine's upload on Friday broke our image builds. | 13:17 |
| Riddell | pitti: oh really? I wonder what that's for | 13:17 |
| ScottK | Riddell: Do you understand how the telepathy stuff runs together well enough to figure the best path forward here? | 13:18 |
| pitti | Riddell: http://people.canonical.com/~ubuntu-archive/germinate-output/kubuntu.precise/desktop.depends | 13:18 |
| Riddell | oh it'll be telepathy-haze | 13:18 |
| pitti | Riddell: telepathy-haze is already on the kubuntu images | 13:18 |
| dupondje | msn worked fine this weekend :D | 13:18 |
| Riddell | ScottK: what's the issue? | 13:18 |
| pitti | so it seems we just need to drop -purpoe | 13:18 |
| kenvandine | the haze/buttefly depends stuff changed a couple weeks ago | 13:18 |
| pitti | err, t-butterfly | 13:18 |
| ScottK | Riddell: See backscroll here. | 13:18 |
| seb128 | jml, will teach you to dist-upgrade and ack without reading? ;-) | 13:18 |
| * pitti mutters "precise-proposed" | 13:18 | |
| Riddell | ScottK: I have, not worked out what the issue is yet :) | 13:18 |
| Riddell | farsight/farstream ? | 13:19 |
| jml | seb128: yeah, I guess. | 13:19 |
| ScottK | Riddell: Yes. | 13:19 |
| ironm | hello. May I ask one question, please? Why do I need an invitation for the #ubuntu-live channel? I have found some issues with live-builder on ubuntu 11.01 or 12.04 (server) but can't report them anywhere. I am looking for current documentation how to create live images on ubuntu. | 13:19 |
| ironm | thank you in advance for any hints | 13:19 |
| ScottK | Bug #952136 is why our builds broke over the weekend. | 13:19 |
| ubottu | Launchpad bug 952136 in papyon (Ubuntu Precise) "libfarstream-0.1-0 not installable due to conflict with libgstfarsight0.10-0" [Critical,In progress] https://launchpad.net/bugs/952136 | 13:19 |
| kenvandine | they really conflict, but the question is does kubuntu really need papyon | 13:19 |
| kenvandine | nothing rdepends on it | 13:19 |
| kenvandine | besides telepathy-butterfly, which won't work anymore anyway | 13:20 |
| Riddell | kenvandine: what's papyon ? | 13:20 |
| ScottK | Riddell: kenvandine and pitti are suggesting getting rid of papyon is the right answer, but I don't know what else would provide msn support then. | 13:20 |
| kenvandine | the msn library that telepathy-butterfly uses | 13:20 |
| pitti | kenvandine: I suppose not, but we still need something to breaks: it, to get it cleaned up on upgrades | 13:20 |
| jml | except there are only so many giant walls of text I can deal with in a given day, so I'll probably make the same mistake again | 13:20 |
| pitti | ScottK: telepathy-haze does, which is already in K | 13:20 |
| kenvandine | so it should be safe to drop it from the seed | 13:20 |
| ScottK | OK. So then the question is doe that work with telepathy KDE? | 13:20 |
| Riddell | ScottK: for kde-telepathy? I expect libpurple through telepathy-haze does but I can check | 13:21 |
| Riddell | and kopete uses libmsn | 13:21 |
| seb128 | jml, stop using command line tools and use update-manager? | 13:21 |
| ScottK | Riddell: Thanks. | 13:21 |
| pitti | jml: actually, see bug 930217 | 13:21 |
| ubottu | Launchpad bug 930217 in Launchpad itself "Make proposed pocket useful for staging uploads" [Low,Triaged] https://launchpad.net/bugs/930217 | 13:21 |
| pitti | jml: if we get that, we can avoid temporary breakage like that | 13:21 |
| ScottK | ironm: I suspect #ubuntu-installer is the channel you think you're looking for. | 13:21 |
| pitti | jml: so if you happen to know a LP manager who can bump this... :-D | 13:21 |
| jml | pitti: thanks. | 13:21 |
| ironm | thank you very much ScottK :) | 13:22 |
| Riddell | kenvandine, ScottK: upstream kde-telepathy say telepathy uses telepathy-haze which uses libpurple | 13:23 |
| kenvandine | ok, so it doesn't need to be seeded | 13:23 |
| Riddell | kenvandine: he says farsight has something to do with video/audio support which isn't yet in kde-telepathy so it's not an issue for us (might be for empathy I guess) | 13:25 |
| kenvandine | empathy already switched | 13:25 |
| kenvandine | so we're good | 13:26 |
| * kenvandine is figuring out the right package to add the breaks too | 13:26 | |
| kenvandine | it got removed from my box on dist-upgrade | 13:26 |
| kenvandine | i guess because of the farstream changed | 13:26 |
| pitti | kenvandine: if apt can figure it out, that's ok | 13:27 |
| pitti | kenvandine: but a single conflicts: in a library is usually relatively hard to get over | 13:27 |
| pitti | without a replaces:/provides or a breaks: on the app package layer | 13:28 |
| kenvandine | pitti, this is why we put it in the ubuntu-desktop ppa for a week first, to see if this caused any problems | 13:28 |
| kenvandine | i guess the best place would be in telepathy-mission-control-5 since it is effectly what removed butterfly support | 13:28 |
| pitti | kenvandine: yes, that sounds good | 13:29 |
| kenvandine | but technically farstream is what breaks papyon :) | 13:29 |
| ScottK | So can butterfly and papyon be removed entirely? | 13:45 |
| stgraber | @pilot in | 13:46 |
| === udevbot changed the topic of #ubuntu-devel to: Precise Beta-1 Released. Archive: open | Development of Ubuntu (not support, not app development) | build failures -> http://bit.ly/xmGdCW | #ubuntu for support and general discussion for hardy -> oneiric | #ubuntu-app-devel for app development on Ubuntu | http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: stgraber | ||
| henrix | pitti: ping | 13:47 |
| pitti | henrix: hello; please don't ping, just ask your question | 13:47 |
| henrix | pitti: i've been waiting for a while for the oneiric (and -lts) kernels to be promoted to -proposed | 13:48 |
| henrix | pitti: herton told me the right thing to do is to ping one of the arch admins... | 13:49 |
| pitti | hm, I thought I did them all on Friday | 13:49 |
| henrix | pitti: i guess not :) | 13:49 |
| pitti | right, hit after my EOD on Friday | 13:49 |
| pitti | ack, will do | 13:49 |
| henrix | ok, no prob. i was just wondering whether there was something wrong. | 13:49 |
| pitti | henrix: all done | 14:01 |
| henrix | pitti: thanks! | 14:01 |
| kenvandine | pitti, ScottK: i talked to the debian maintainer, he says he thinks the current farstream conflicts is enough | 14:03 |
| ScottK | OK. | 14:03 |
| kenvandine | nobody reported any upgrade problems while it was in the ppa | 14:03 |
| kenvandine | and i just did a dist-upgrade in a VM and it did the right thing | 14:04 |
| ScottK | Right, but how many Kubuntu users use the PPA? | 14:04 |
| kenvandine | so i think we are fine as is | 14:04 |
| ScottK | OK. | 14:04 |
| pitti | kenvandine: well, that's not an indication, as nobody using the PPA ran kubuntu apparently | 14:04 |
| kenvandine | true | 14:04 |
| kenvandine | but nothing in kubuntu actually depends on it | 14:04 |
| kenvandine | just the seed | 14:04 |
| pitti | our auto dist-upgrade testing has some kubuntu support, though | 14:04 |
| pitti | kenvandine: ok, so this just needs testing; if the dep gets dropped from k-desktop, it should work as well as in ubuntu | 14:05 |
| kenvandine | i think so | 14:05 |
| kenvandine | is someone fixing that? or should i look at kubuntu-desktop? | 14:06 |
| kenvandine | pitti, ^^ | 14:06 |
| pitti | kenvandine: the seeds? please do | 14:07 |
| kenvandine | ok, will do | 14:07 |
| pitti | thanks | 14:07 |
| ScottK | So it looks like the path to papyon for Kubuntu is kde-telepathy -> telepathy-butterfly -> python-papyon. | 14:08 |
| kenvandine | ScottK, and nothing should pull in telepathy-butterfly anymore, haze replaced it | 14:09 |
| ScottK | Right. I can fix that. | 14:09 |
| kenvandine | and it won't be installable | 14:09 |
| ScottK | Looking now. | 14:09 |
| Riddell | if telepathy-core drops telepathy-butterfly then it won't be on the kubuntu images any more | 14:10 |
| Riddell | or ubuntu desktop or anything else | 14:10 |
| Riddell | job done | 14:10 |
| kenvandine | it still needs to be removed from the kubuntu-desktop seed though | 14:10 |
| hallyn | the auto-quilt-pop-push in bzr merge is making for hard to review merges... | 14:12 |
| hallyn | is there something better than 'bzr diff' and 'bzr st' to show what actually changed? | 14:12 |
| hallyn | oh it didn't reapply them | 14:13 |
| Riddell | kenvandine: it's not in the kubuntu-desktop seed | 14:14 |
| kenvandine | ah, great~ | 14:14 |
| ScottK | Riddell: telepaty-butterfly provides Provides: telepathy-connection-manager | 14:14 |
| kenvandine | i thought pitti said it was | 14:14 |
| kenvandine | then i don't need to worry about it :) | 14:14 |
| ScottK | That's why it's getting pulled in. | 14:14 |
| Riddell | the only thing in the seed is kde-telepathy | 14:15 |
| ScottK | which depends on telepathy-connection-manager | 14:15 |
| Riddell | if that ends up with telepathy butterfly installed then indeed there is another problem somewhere | 14:15 |
| ScottK | What else provides that? | 14:15 |
| kenvandine | telepathy-gabble | 14:15 |
| kenvandine | haze | 14:15 |
| kenvandine | etc | 14:15 |
| kenvandine | should | 14:15 |
| Riddell | dunno, ask whoever maintaines telepathy | 14:16 |
| ScottK | Haze does | 14:16 |
| ScottK | We have that already. | 14:16 |
| ScottK | Riddell: I think I know how to fix it. | 14:16 |
| Riddell | so demote telepaty-butterfly and job done | 14:16 |
| kenvandine | that is a good idea | 14:16 |
| ScottK | kenvandine: Is there any reason not to just remove it? | 14:17 |
| kenvandine | nope | 14:17 |
| kenvandine | telepathy wouldn't use it even if it was installed | 14:17 |
| kenvandine | so yeah, we can do that too | 14:17 |
| ScottK | pitti: ^^^ Would you kill telepathy-butterfly, source and binary? | 14:18 |
| cr3 | pitti: I see you packaged postgresql, do you think that postgresql-plpython should have an actual meta package instead of a purely virtual one? the latter prevents me from specifying a dependency like postgresql-plpython (>= 8.4) | 14:18 |
| ScottK | kenvandine: telepathy-gabble and telepathy-haze both provide telepathy-connection-manager. Is one preferred? | 14:19 |
| kenvandine | no | 14:19 |
| kenvandine | different services | 14:19 |
| kenvandine | gabble is jabber (including gtalk and facebook) | 14:20 |
| ScottK | Riddell: It's also a package back in the meta-kde-telepathy package to only depend on a virtual package. It should depend on realpackage | virtualpackage to avoid these kinds of problems. | 14:20 |
| Riddell | aah | 14:20 |
| ScottK | back/bug | 14:21 |
| Riddell | ScottK: file a bug and ping me if you need packages removed | 14:21 |
| ScottK | OK. | 14:21 |
| Riddell | assuming it's a package I care about :) | 14:21 |
| ScottK | First I'll fix meta-kde-telepathy. | 14:21 |
| pitti | ScottK: removing | 14:22 |
| ScottK | Thanks. | 14:22 |
| pitti | and sync-blacklisted | 14:23 |
| pitti | cr3: as the server-side extensions are version specific, it usually doesn't make too much sense to depend on an arbitrary one | 14:23 |
| === JanC_ is now known as JanC | ||
| cr3 | pitti: how can I express something like this then: postgresql (>= 8.4), postgresql-plpython (>= 8.4) | 14:24 |
| cr3 | pitti: even though the extension are version specific, the package depending on it might not now the specific version :) | 14:24 |
| cr3 | s/now/know/ | 14:25 |
| cr3 | pitti: the only workaround I can think of would be to branch my project for each version of Ubuntu, which would seem unfortunate just because of postgresql-plpython :( | 14:26 |
| pitti | cr3: how about Depends: postgresql (>= 8.4), postgresql-plpython | 14:26 |
| cr3 | pitti: I'll give that a try, thanks! | 14:27 |
| === smb` is now known as smb | ||
| cr3 | pitti: worked like a charm, thanks! | 14:28 |
| pitti | cr3: to be _really_ correct, you'd also need to require that server and plpython are of the same version, but that's hard to express with dependencies | 14:29 |
| cr3 | pitti: yeah, I do that within my own packages, like (= ${binary:Version}), but I wouldn't know how for external packages | 14:30 |
| ScottK | pitti or Riddell: Bug #953061 | 14:32 |
| ubottu | Launchpad bug 953061 in papyon (Ubuntu) "Please remove papyon (source) and python-papyon (binaries) from precise" [Undecided,New] https://launchpad.net/bugs/953061 | 14:32 |
| pitti | doing | 14:33 |
| ScottK | Thanks. | 14:34 |
| lamont | http://paste.ubuntu.com/880433/ <-- d-r-u got lost on run 1, the second run I get this | 14:40 |
| infinity | lamont: You might need to manually install at least libc6*, libstdc++*, libgcc*, libapt*, and apt_* from /var/cache/apt/archives. :/ | 14:57 |
| infinity | lamont: Things getting wedged halfway through can end badly for apt, if it's at just the wrong time. | 14:57 |
| infinity | lamont: (And if any of those is actually unable to install/upgrade, bug reports plox!) | 14:58 |
| lamont | yeah - working thruogh it now | 14:58 |
| henrix | pitti: sorry to bother you again, but it looks like something went wrong during the upload | 14:59 |
| henrix | pitti: take a look at comment https://bugs.launchpad.net/ubuntu/+source/linux/+bug/949882/comments/2 | 15:00 |
| ubottu | Launchpad bug 949882 in Kernel SRU Workflow "linux: 3.0.0-17.30 -proposed tracker" [Undecided,In progress] | 15:00 |
| m_3 | mhall119: please ping me if you get a chance... I'd like help with summit production configuration | 15:00 |
| infinity | henrix: Will fix. | 15:01 |
| henrix | infinity: thanks for taking a look at it | 15:01 |
| mhall119 | m_3: ping | 15:01 |
| m_3 | mhall119: hey | 15:02 |
| m_3 | mhall119: so let me spin up a fresh stack of summit/postgresql/memcached | 15:03 |
| infinity | henrix: Hrm. Those meta packages appear to have always been in universe. | 15:04 |
| * infinity will look again in a sec. | 15:04 | |
| henrix | infinity: interesting... | 15:05 |
| pitti | henrix: I promoted all pacakges to main, are these comments a bit misleading? | 15:06 |
| pitti | henrix: I. e. do they actually say "the package is in main, but should be in universe"? | 15:06 |
| infinity | pitti: Did you? | 15:06 |
| pitti | henrix: that's known; we can't do PPA copies and fix the components at the same time | 15:07 |
| pitti | henrix: so I'm usually waiting for replies like this, and then fix them up individually | 15:07 |
| infinity | pitti: Unless you just did (like, since the last publisher run), all these packages from linux-meta are still in universe. | 15:07 |
| pitti | oh, I didn't override linux-meta | 15:07 |
| infinity | pitti: But, it also seems like they always have been. | 15:07 |
| pitti | since when does _that_ need overriding? | 15:07 |
| infinity | linux-backports-modules-cw-3.2-oneiric-generic | 3.0.0.16.19 | oneiric-security/universe | amd64, i386 | 15:07 |
| infinity | linux-backports-modules-cw-3.2-oneiric-generic | 3.0.0.16.19 | oneiric-updates/universe | amd64, i386 | 15:07 |
| infinity | linux-backports-modules-cw-3.2-oneiric-generic | 3.0.0.17.20 | oneiric-proposed/universe | amd64, i386 | 15:07 |
| infinity | ^-- For example. | 15:07 |
| infinity | pitti: It needs overriding when new backport packages are added. | 15:08 |
| infinity | pitti: New is new is new. :P | 15:08 |
| infinity | pitti: And it looks like the first time the -cw-3.2- stuff was added, it went to universe, and no one complained until now. I guess. | 15:08 |
| pitti | meh; pretty please let's stop mixing components for the kernel; it's a PITA | 15:08 |
| infinity | pitti: We don't. | 15:08 |
| pitti | they should all be in main really | 15:08 |
| infinity | pitti: It should all be in main. | 15:08 |
| infinity | pitti: But LP punts new packages to universe, and some AAs are lazy? :P | 15:09 |
| infinity | pitti: AFAIK, everything from linux, linux-backports-modules, and linux-meta is meant to be in main. | 15:09 |
| stgraber | can't we get regexp based component overrides? sounds like it'd help quite a bit with the kernel | 15:09 |
| pitti | ok, overriding | 15:09 |
| infinity | stgraber: There's a bug open to just change the automagic logic. | 15:10 |
| pitti | henrix: fixed the overrides, thanks | 15:10 |
| infinity | stgraber: It's my contention that new binaries should default to the same component as their source. | 15:10 |
| stgraber | infinity: that'd make sense indeed | 15:10 |
| pitti | +1 | 15:10 |
| infinity | stgraber: And others seem to agree. But no one's bothered to fix it. Was this you volunteering? ;) | 15:10 |
| * pitti needs to reboot urgently, brb | 15:10 | |
| henrix | pitti: great, thanks. i'm just looking at the irc backlog to understand what happen... | 15:11 |
| pitti | henrix: for hardy and lucid it's almost guaranteed that we'll get this kind of mail, and I'll fix it once we get it | 15:13 |
| pitti | henrix: (just so that you aren't scared in the future) | 15:13 |
| henrix | pitti: thanks :) | 15:14 |
| henrix | pitti: i *was* scared actually :) | 15:14 |
| geser | pitti, cr3: would it be even possible at all to specify a dependency on matching postgresql-plpython and server? given that several postgresql clusters can exists in different versions and it's possible that postgresql-plpython is only installed for one specific postgresql version and not the others | 15:16 |
| pitti | geser: it's a nice academic exercise | 15:16 |
| pitti | depends: (postgresql-8.4, postgresql-plpython-8.4) | (postgresql-9.1, postgresql-plpython-9.1) | 15:17 |
| pitti | and then do the usual boolean transformation to rewrite this in conjunctive normal form | 15:18 |
| herton | pitti, infinity, about component mismatches, we got on Lucid as well, because of the preempt packages (bug 947375). Well this one is the problem that on lucid not everything goes on main for this case | 15:19 |
| ubottu | Launchpad bug 947375 in Kernel SRU Workflow "linux: 2.6.32-40.87 -proposed tracker" [Undecided,In progress] https://launchpad.net/bugs/947375 | 15:19 |
| stgraber | infinity: not volunteering just yet but might end up having a look next time I get hit by it (usually when doing netinstalls) :) | 15:19 |
| pitti | herton: oh, this sets the task to "incomplete", fixing my canned search to include this | 15:20 |
| herton | pitti, I could change it back to confirmed, if you want | 15:20 |
| herton | pitti, I mean, change the bot to do it instead of using incomplete | 15:21 |
| pitti | herton: fixed my canned search, but thanks | 15:23 |
| henrix | pitti: i got the same comment again on LP... | 15:29 |
| pitti | henrix: it needs about half an hour up to an hour to get effective (needs a publisher run) | 15:29 |
| henrix | pitti: ah, right. since the promote-to-proposed had changed to fix release, i though it was solved already | 15:30 |
| henrix | pitti: but it went back to incomplete again. anyway, i'll wait :) | 15:30 |
| pitti | henrix: well, I close it as soon as I fix the overrides | 15:30 |
| pitti | I don't wait for a publisher | 15:30 |
| herton | pitti, I'll change the bot to delay the check, 1 hour of delay should ensure things to be published? | 15:30 |
| pitti | it's a hard enough process already :) | 15:31 |
| pitti | herton: yes, 1 hour is guaranteed to be enough | 15:31 |
| pitti | herton: publisher runs at :03 and :33 I believe | 15:31 |
| herton | ok cool | 15:31 |
| pitti | herton: cheers | 15:31 |
| pitti | mvo: I'd appreciate a look from you at bug 950676; it does look like an apt problem, but it might be possible to add some dependency "hints" to work around it? | 15:34 |
| ubottu | Launchpad bug 950676 in apt (Ubuntu Precise) "lucid->precise upgrade failure due to gir1.0->gir1.2 conflicts" [High,New] https://launchpad.net/bugs/950676 | 15:34 |
| mvo | pitti: will do, I'm curently on bug #940396 | 15:35 |
| ubottu | Launchpad bug 940396 in apt (Ubuntu Precise) "lucid -> precise main all failed to upgrade: dpkg: dependency problems prevent configuration of kde-runtime" [Critical,Confirmed] https://launchpad.net/bugs/940396 | 15:35 |
| pitti | mvo: ah, thanks; not that urgent, just if you could have a look in the next days | 15:36 |
| pitti | queue a tab in firefox or so | 15:36 |
| mvo | pitti: thanks, adding it now | 15:36 |
| dupondje | When dh_installinit is executed in debian/rules. and there is an upstart file, does it start on all runlevels? | 15:38 |
| pitti | henrix, herton: the checker seems to be wrong for omap4, see bug 950572 | 15:38 |
| ubottu | Launchpad bug 950572 in Kernel SRU Workflow "linux-ti-omap4: 3.0.0-1208.18 -proposed tracker" [Undecided,In progress] https://launchpad.net/bugs/950572 | 15:38 |
| pitti | dupondje: upstart doesn't have it's own concept of runlevels; it'll start as soon as the "start on" condition is true | 15:39 |
| pitti | dupondje: "start on" might say "on run levels 2 to 5" | 15:39 |
| herton | pitti, I think it should have gone to main originally, as all linux-ti-omap4 packages were on main previously (for natty and maverick) | 15:40 |
| pitti | herton: I agree; but that doesn't help us now, as oneiric release has it in universe | 15:40 |
| herton | pitti, so couldn't it be moved to main on updates/proposed? But ok, I can add an exception for it, it this can't be done | 15:42 |
| pitti | herton: it could, but in general we try to avoid changing components after release | 15:42 |
| pitti | herton: e. g. linux-tools-omap4 might have a dependency on another universe package | 15:43 |
| pitti | which wuold break if we promote it to main | 15:43 |
| pitti | herton: I had assumed your script compares it against the component in the release, but seems not; is that a hardcoded mapping in your script? | 15:43 |
| herton | pitti, depends, by default it checks the component on release, but for ti-omap4 it's a hardcoded enforce to be on main | 15:44 |
| cjohnston | m_3, mhall119; mhall119, m_3 :-) | 15:45 |
| m_3 | cjohnston: thanks!... we've been PMing | 15:46 |
| m_3 | cjohnston: how would you like to handle the linuxplumbers theming? | 15:46 |
| m_3 | we can branch ubuntu_website and modify the template there | 15:47 |
| cjohnston | m_3: thats probably what will heppen | 15:47 |
| cjohnston | happen | 15:47 |
| m_3 | do they want to go with the ubuntu theme? | 15:47 |
| m_3 | ah, ok | 15:47 |
| cjohnston | no.. we are going to use a plumbers theme... | 15:48 |
| cjohnston | they can have the ubuntu theme for now tho | 15:48 |
| cjohnston | i still havent gotten complete instructions | 15:49 |
| dupondje | What trigger should be used in upstart to run on shutdown (after disks are umounted) | 15:49 |
| m_3 | cjohnston: ok, well maybe I can just pass it as a config param for the charm... i.e., the theme/site branch | 15:49 |
| m_3 | defaults to ubuntu_website | 15:50 |
| cjohnston | ok | 15:50 |
| m_3 | currently set to http://bazaar.launchpad.net/~ubuntu-community-webthemes/ubuntu-community-webthemes/light-django-theme | 15:50 |
| herton | pitti, I see here that linux-ti-omap4 were released originally on main actually: http://pastebin.ubuntu.com/880527/ | 15:51 |
| infinity | herton: Yes, but not linux-tools-omap4, which is from -meta. | 15:53 |
| cjwatson | pitti: the publisher doesn't actually always quite manage to run every half-hour, as sometimes it overruns its slot; one hour is *usually* enough, I just wouldn't like to say "guarantee" | 15:53 |
| stgraber | seb128: I'm looking at https://code.launchpad.net/~nik90/ubuntu/precise/totem/add_quicklist/+merge/94170 just now, the submitter did the changes you requested and it looks good to me. I just wanted to check with you that it's indeed ok to upload this change at this point in the cycle as it's essentially adding new translatable strings | 15:54 |
| herton | infinity, oh right, nevermind | 15:55 |
| seb128 | stgraber, hey, it's ok, we will warn the translators soon about the ones which got added in a batched way | 15:57 |
| herton | pitti, infinity, I'll just fix the script to not enforce everything on main, the tools are on universe on maverick and natty as well | 15:58 |
| herton | *not enforce everything on main for ti-omap4 meta | 15:58 |
| pitti | cjwatson: ah, thanks; anyway, probably good enough for the checker scripts | 15:59 |
| stgraber | seb128: ok, I'll make the upload then, unless you have a totem upload coming up soon? | 15:59 |
| seb128 | nothing planned so feel free to upload | 15:59 |
| herton | pitti, infinity, fyi, this is the class which checks the components: ktl/check_component.py, used by stable/check-component and the bot (from git://kernel.ubuntu.com/ubuntu/kteam-tools.git) | 16:00 |
| m_3 | cjohnston: let's set up a walkthrough on managing the summit stack using the charms... I'm just waiting on info about which ec2 accounts to use, and then I'll be ready to go over it with you. | 16:07 |
| cjohnston | ok | 16:07 |
| stgraber | cjwatson: could you hardcode lxc in the ubuntu-server packageset? it tends to get out of it pretty often (as it's not actually seeded on any of the server seeds but it's definitely actively maintained by the server team) | 16:37 |
| stgraber | (I just added it again manually but I suspect it'll be dropped next time the script runs) | 16:38 |
| jamespage | micahg, around? can we discuss the native/non-native packages on the zentyal/ebox packages? | 16:38 |
| micahg | jamespage: sure, I"m heere | 16:39 |
| cjwatson | stgraber: yeah, please don't change the automatically-maintained package sets manually :) | 16:40 |
| jamespage | micahg, sweet - so I just read your comments on bug 928501 | 16:40 |
| ubottu | Launchpad bug 928501 in ebox (Ubuntu) "Precise will ship totally broken ebox packages" [High,Confirmed] https://launchpad.net/bugs/928501 | 16:40 |
| cjwatson | stgraber: I've added an exception for it now (which has caused it to drop out of edubuntu, incidentally) | 16:41 |
| micahg | stgraber: the source has dropped to universe for precise, is that intentional? | 16:41 |
| stgraber | cjwatson: thanks | 16:41 |
| jamespage | micahg: upstream don't ship tarballs; they release packages and only for ubuntu | 16:41 |
| stgraber | micahg: yes, nothing in main depends on it and it's not seeded by anything but edubuntu at the moment | 16:42 |
| jamespage | which was the thinking behind sticking with the native format - rather than switching to 3.0 (quilt) and adding in an extra step | 16:42 |
| micahg | stgraber: i.e. do they not want it "officially" supported | 16:42 |
| stgraber | micahg: it probably should be seeded by server though but that's a discussion for the server team to have :) | 16:42 |
| tumbleweed | jamespage: is the Ubuntu pcakaging going to be maintained in their VCS branches? | 16:42 |
| micahg | Daviey: ^^ | 16:42 |
| jamespage | tumbleweed, yes | 16:43 |
| stgraber | micahg: I think we want to officialy support it and we kind of do, I'm all for an MIR + adding to at least supported seed. I remember the security review being a problem last time it was attempted though | 16:43 |
| stgraber | micahg: hallyn would know more | 16:43 |
| micahg | jamespage: yes, but as it's not an Ubuntu specific thing in the sense that it's tied to our archive in some way, I'd think they should really release tarballs or use bzr snapshots, but there should be an upstream tarball as they're an upstream of Ubuntu | 16:43 |
| micahg | stgraber: ah, well, I don't want to increase security headaches ;) | 16:44 |
| Daviey | stgraber: why would we seed something like this? | 16:44 |
| micahg | jamespage: s/bzr/vcs/ | 16:44 |
| Daviey | jamespage: we don't want this in main do we? | 16:44 |
| jamespage | micahg, I'm not seeing how its NOT an Ubuntu specific thing? maybe I'm missing something | 16:44 |
| jamespage | Daviey, no | 16:45 |
| Daviey | ahh, two discussions happening concurrently | 16:45 |
| * Daviey switches on SMP. | 16:45 | |
| micahg | jamespage: it's Ubuntu specific in that they develop for Ubuntu not that it's inherently tied to Ubuntu | 16:45 |
| stgraber | Daviey: I'm talking about lxc, not ebox :) | 16:45 |
| infinity | I think lxc absolutely should go through the MIR dance and be supported. | 16:45 |
| infinity | If for no other reason than it's the only way to approximate "virtualisation" (and I use the term loosely) on ARM. | 16:46 |
| hallyn | stgraber: micahcg: sorry, i can't follow the above :) when the otehr issues are done being discussed, pls ping me and re-ask | 16:46 |
| Daviey | infinity: does qemu not work on arm? :) | 16:47 |
| infinity | Daviey: Full emulation, sure, no paravirt. | 16:47 |
| Daviey | infinity: Have you been tracking the work kvm and xen are doing to work on arm? | 16:47 |
| infinity | Daviey: So, if you want a bunch of VMs that run at the speed of a TI graphinc calculator, you're set. | 16:48 |
| m_3 | mhall119: dude... Daviey has a custom manage command that'll work http://pb.daviey.com/MTUs/ | 16:48 |
| m_3 | mhall119: can probably make that work for prepopulating menus too | 16:48 |
| infinity | Daviey: kvm and xen paravirt on ARM will only happen for A15 cores and beyond. The hardware support just ain't there in current hardware. | 16:48 |
| micahg | jamespage: for instance if Debian or Fedora wanted ebox, from what I've read in that bug, the upstream developers would welcome patches | 16:50 |
| jamespage | micahg: hmm | 16:50 |
| mhall119 | m_3: that would work for superuser | 16:50 |
| mhall119 | I think think it's better for us to make the code not crash when there isn't a menu (or summit) | 16:51 |
| m_3 | mhall119: well... ok :) | 16:52 |
| micahg | jamespage: again, this is only for the distro packaging, for their own packaging purposes, they're free to use 3.0 (natiive) | 16:52 |
| tumbleweed | jamespage: also, native packages make no separatino between packaging and upstream. Unless all developers who have upload rights for the packages have commit rights on their source branches (and exercise them), they're likely to get out of sync | 16:53 |
| micahg | jamespage: and with source format 3.0, the upstream debian dir is ignored IIRC, so they don't conflict either | 16:54 |
| jamespage | micahg, tumbleweed: so its really a) we fork the packaging and got with 3.0 (quilt) and have to merge each new upstream release in as we would do | 16:55 |
| micahg | jamespage: yep, same as any other upstream :) | 16:55 |
| jamespage | or b) we risk holding a delta over upstream by sticking with 3.0 (native) | 16:55 |
| tumbleweed | a hard to manage delta | 16:55 |
| micahg | I see b as wrong from the distro perspective which is why I mentioned it in the first place :) | 16:56 |
| jamespage | micahg, I guess the challenge here is that upstream are also the maintainer of the packages... | 16:57 |
| jamespage | hence adding in a step to switch the format of the packaging seems like extra work | 16:58 |
| micahg | jamespage: but they're not as they're not Ubuntu developers (and we don't have maintainers in Ubuntu :)) | 16:58 |
| micahg | they're the upstream developers who may in time get upload rights to their packages | 16:58 |
| tumbleweed | it's really not that big an extra step. It's trivial to add a tarball generating rule to debian/rules | 16:59 |
| Daviey | tumbleweed: Yes, you'd think we'd know that, right? :) | 17:00 |
| * tumbleweed has an (I beleive fairly rational) hatred of native packages :) | 17:00 | |
| Daviey | Seriously, this should not require so much consideration | 17:01 |
| tumbleweed | that too | 17:01 |
| infinity | It's easily handled with VCS branches. | 17:01 |
| infinity | I used to maintain telepathy-glib upstream, Debian, and Maemo, and it was all just git branches of the same thing, with different debian directories plopped on top. | 17:02 |
| infinity | The fact that "upstream" was also the maintainer in two distributions was handy, but not an argument for native packaging. | 17:03 |
| dholbach | one day we'll have a world without tarballs | 17:03 |
| === MacSlow is now known as MacSlow|dinner | ||
| infinity | (In fact, it maintained my sanity to have the debian-less upstream source be the "base") | 17:03 |
| Daviey | native packages are policy compliant, i see their limitations, but really, why create extra work? | 17:03 |
| infinity | dholbach: Meh, a tarball is no different from an upstream tag in a VCS. You still want a snapshot of a released state. | 17:04 |
| Daviey | it's upstream maintaining this, lets be flexible, but within policy | 17:04 |
| infinity | dholbach: (And, in fact, Nokia's internal build system for Maemo created orig.tar.gzs out of thin air from git tags) | 17:04 |
| infinity | Daviey: Oh, I don't care if people package natively. But a project that seems open to being used in places other than Ubuntu might want advice on how best to do that, and native maintenance isn't it. | 17:05 |
| infinity | Daviey: I imagine that's what micahg was driving at. I hope. | 17:05 |
| Daviey | right, and when that happens, let them switch the package to quilt | 17:05 |
| dholbach | infinity, the current tarball + patch system + vcs world is very far from my ideal world :) | 17:05 |
| infinity | dholbach: I don't mind it too much, except when people forget that the archive is authoritative because they live in a fantasy world where the VCS is. :P | 17:06 |
| micahg | Daviey: infinity: yes, but I believe it's disingenuous to use 3.0 (native) for something that's not developed specifically by Ubuntu developers for use in the Ubuntu archive | 17:07 |
| infinity | dholbach: (The Maemo "releases are tags" thing kinda fixed that for them) | 17:07 |
| Daviey | micahg: currently that is the case. | 17:07 |
| dholbach | infinity, if everything was all just branches, merging from each other would be a lot easier :) | 17:07 |
| Daviey | micahg: If you want to take on the work to switch it, please do. | 17:07 |
| infinity | micahg: native doesn't imply origin, it's an unfortunate name. | 17:07 |
| micahg | and also, another argument is that it makes them always think about the packaging vs upstream difference which is important for distro uploaders | 17:08 |
| micahg | infinity: it doesn't, but it makes sense from a distro perspective to use it that way | 17:08 |
| === JanC_ is now known as JanC | ||
| micahg | Daviey: and as has been pointed out lp:ubuntu/foo will be the authoratative packaging branch regardless, it would seem to make sense to enforce that at a packaging level by using 3.0 (quilt) | 17:09 |
| Daviey | micahg: great, please prepare the patches. | 17:10 |
| micahg | assuming it's up to date | 17:10 |
| infinity | micahg: The authoritative packaging branch is "apt-get source ebox". :P | 17:10 |
| infinity | micahg: Anything else is a delusion. | 17:10 |
| micahg | infinity: yes, well, that's why I said if it's up to date :P | 17:11 |
| Daviey | (for now) | 17:11 |
| infinity | (A delusion people are trying to make a reality, but until it all works right, I'm sticking with my statement) | 17:11 |
| micahg | Daviey: I've got a few other things I'm working on at the moment, but it should just be a matter of generating an upstream tarball and switching the debian/source/format content, I know there are links somewhere on how to generate an upstream tarball from a VCS | 17:13 |
| cjwatson | scott-work: nothing reconfigures jack at boot on ubuntustudio live systems - I guess we want that to happen? | 17:13 |
| cjwatson | (923810) | 17:13 |
| scott-work | cjwatson: yes please | 17:14 |
| Daviey | micahg: dude, we know that.. but if you feel that is how it should be done, please do it. | 17:15 |
| Daviey | (and liase with upstream) | 17:15 |
| jamespage | micahg, Daviey: I'm really concerned that we are putting in place a barrier between Ubuntu and this upstream project | 17:16 |
| jamespage | that we don't really need to have in place | 17:16 |
| Daviey | right | 17:16 |
| micahg | jamespage: Daviey: I don't think I should be obligated to fix something that's not even in the archive yet in order to have it follow sane packaging requirements | 17:16 |
| Daviey | micahg: requirements ? | 17:16 |
| Daviey | micahg: Are you suggeting ntive is anti-policy? | 17:16 |
| micahg | that barrier is that there's a difference between upstream and distro developement | 17:16 |
| micahg | Daviey: in this type of scenario, I think it is | 17:17 |
| infinity | micahg: There isn't right now. If they start accepting patches to work on other distros, there will be a difference between upstream and distro. | 17:17 |
| infinity | micahg: For now, native, while perhaps not entirely correct, isn't entirely incorrect either. | 17:18 |
| infinity | micahg: And it's trivial to change from native to non-native later. | 17:18 |
| micahg | infinity: there is as we might patch things at the distro level that "upstream" never needs to see including SRUs | 17:18 |
| infinity | micahg: I tend to agree with you on what I prefer to see, but it's not that meaningful in cases like this. | 17:18 |
| micahg | infinity: I think it matters when people are trying to patch things | 17:19 |
| infinity | micahg: Meh, we do SRUs of other native packages that often never need to go in the latest devel release. I don't see the difference. | 17:19 |
| jamespage | I also think we have an upstream project who will want to know about SRU updates | 17:19 |
| jamespage | their entire product is based on Ubuntu... | 17:20 |
| micahg | infinity: it's a pain to patch a native package especially when the last "patch" needs to be removed | 17:20 |
| infinity | micahg: It... Is? | 17:20 |
| * cjwatson patches native packages all the time; if it's hard you're doing it wrong | 17:20 | |
| infinity | micahg: Apply change, dpkg-buildpackage, done. | 17:20 |
| infinity | micahg: It's arguably easier to patch native packages, not harder. | 17:20 |
| cjwatson | (perhaps by mistakenly believing that patch systems are a good idea when applied to native packages) | 17:21 |
| micahg | infinity: cjwatson: well, you're both AAs and seasoned developers, am I wrong to be taking such a strong stance against this? | 17:22 |
| infinity | micahg: I think that, as long as they continue to target only Ubuntu (and it's a pretty specific set of tools), the point is kinda moot. | 17:23 |
| pitti | I haven't followed the whole discussion, but why would we consider ebox a native package? because there's no upstream any more? (zentyal now) | 17:23 |
| infinity | micahg: I agree with you that if/when they target other distros, they should perhaps branch packaging seperately from "upstream source", but I can't see how it matters one way or the other right now. | 17:24 |
| infinity | micahg: I, personally, would have an upstream/distro division if it was my project, and obviously you would too, but if they literally ONLY release to Ubuntu right now, that's the definition of "native". | 17:25 |
| pitti | i. e. they don't release at all, and don't have their own VCS, etc? | 17:25 |
| infinity | micahg: And it's asking them to do extra busy work to do upstream release tags/tarballs/whatever if they don't actually do "upstream releases". | 17:26 |
| micahg | infinity: to enforce the upstream/distro packaging difference? it's easy for the "upstream" branch to get out of sync | 17:26 |
| infinity | pitti: They have their own VCS, but AFAIUI, they only "release" to Ubuntu, not with "upstream releases". | 17:26 |
| pitti | so if they have their own VCS and development, it's not a native package | 17:26 |
| infinity | pitti: Err. | 17:26 |
| micahg | infinity: also, someone's going to have to get some type of tarball from them to upload, they're not Ubuntu devs, so what does it matter if that is an .orig.tar.gz or a .tar.gz? | 17:26 |
| tumbleweed | if they also plan to release to a PPA for older ubuntu releases, it' squite likely that there'll be times when the PPA packages will need to be different to current ubuntud dev release | 17:27 |
| infinity | pitti: There are any number of native packages (or have been in the past) in Debian that don't use {cvs,bzr,arch,git,svn}.debian.org | 17:27 |
| pitti | infinity: that's not what I meant | 17:27 |
| infinity | pitti: The location of one's VCS doesn't define your release style, it's where you release to (in their case, the Ubuntu archive, not upstream tarballs) | 17:27 |
| pitti | infinity: if they actually _use_ lp:ubuntu/ebox as their development trunk, it'd be native | 17:27 |
| micahg | infinity: and in fact from their perspective, the tarball won't make a difference regardless of that source format in the archive (unless packaging changes are needed) | 17:28 |
| pitti | if they have their own git or whatnot somewhere, then that his the trunk, and it can't conceptually be a native package | 17:28 |
| infinity | pitti: Well, that was kinda my point. Them not using UDD branches doesn't define how they're releasing. | 17:28 |
| * infinity shrugs. | 17:28 | |
| pitti | infinity: it's not just about releasing (although _if_ they release tarballs, then that certainly matters), it's also how they develop | 17:28 |
| pitti | and if their trunk can be different from our package, then it's not native, IMNSHO | 17:29 |
| * micahg hugs pitti | 17:29 | |
| infinity | pitti: So, before UDD, nothing was native? Or when UDD branches happened, any native package that didn't immediate switch all development work to that branch was wrong? | 17:29 |
| infinity | (Hint, we have a few) | 17:29 |
| pitti | infinity: I'm not speaking about UDD here; you can replace lp:ubuntu/precise with "apt-get source ebox" | 17:29 |
| infinity | And while the UDD machinery keeps them magically in sync, sometimes that breaks. | 17:29 |
| pitti | I just mean "whatever is in Ubuntu" | 17:29 |
| infinity | pitti: Ahh, then yes, AFAIK, 'apt-get source ebox/precise' matches their latest released version. | 17:30 |
| pitti | but anyway, I stated my opinion; it's apparently not unanimous, so I guess I STFU again and continue bug fixing :) | 17:30 |
| infinity | pitti: Since they only release it to Ubuntu. | 17:30 |
| infinity | pitti: That was sort of my point. :P | 17:30 |
| pitti | infinity: so if they change something, they apt-get source, change, upload? | 17:30 |
| pitti | that's certainly a very strange project indeed | 17:30 |
| maxb | Perhaps the way to express it is "It is native if the VCS branch used for upstream development and the VCS branch used for uploads to Ubuntu are the same branch" ? | 17:30 |
| infinity | pitti: No, they change it in their VCS and upload. Just like half the native packages we ship. | 17:31 |
| pitti | ok; that certainly is weird | 17:31 |
| pitti | but I guess they can get away with a native package then | 17:32 |
| jamespage | pitti, if you consider the project I don't think it is - its entirely based on Ubuntu | 17:32 |
| infinity | I don't see it as any different from how we do kernel development, or some installer bits, or, or... | 17:32 |
| infinity | The only argument here is that they're not devs, so they can't upload themselves, and somehow that's giving people hissy fits. | 17:32 |
| infinity | But the development model is identical to how we do plenty of our own native packages. | 17:33 |
| pitti | kernel is not native, FWIW, and it would certainly wrong for it to be | 17:33 |
| pitti | but I see what you mean | 17:34 |
| infinity | pitti: It often is, during development cycles, and flips non-native for release, actually. | 17:34 |
| pitti | but d-i is inherently a distro thing, while ebox isn't | 17:34 |
| infinity | pitti: Have you looked at ebox? | 17:34 |
| infinity | pitti: It's wildly distro-specific right now. | 17:34 |
| pitti | infinity: a few years ago, yes | 17:34 |
| pitti | not recently | 17:34 |
| pitti | frankly, I considered its concept quite broken back then, but that might have changed | 17:34 |
| infinity | It's not inherently so, in that it could be extended to work with others, but no one's doing that work. | 17:34 |
| infinity | I'm not a fan of it either, that's out of scope for this. :P | 17:35 |
| micahg | infinity: it's more than they're not devs, it's that while they're work is based on Ubuntu and for Ubuntu, it's not Ubuntu in that's it's not developed as part of the project for the archive | 17:36 |
| infinity | micahg: It is when you start uploading their for-the-archive releases to the archive? :P | 17:37 |
| micahg | s/they're/their/ | 17:37 |
| infinity | micahg: There seems to be some chicken and egg issue there. | 17:37 |
| micahg | infinity: no, distro-specific != native to the project | 17:37 |
| infinity | I disagree. | 17:37 |
| infinity | If it's distro-specific and in the archive, it's native. | 17:37 |
| infinity | Unless, as you claim you're not, you make the distinction based on the identity of the uploader. | 17:38 |
| infinity | s/uploader/changed-by/ | 17:38 |
| * infinity shrugs. | 17:38 | |
| infinity | Colin was smart enough to pretend not to have an opinion when asked. I might do the same and go back to work. :P | 17:38 |
| jamespage | well if you look at 'changed-by' most updates in the last 2 years have been done by ebox/zentyal guys... | 17:38 |
| jamespage | just as sponsored uploades | 17:39 |
| scott-work | cjwatson: please let me know if i can help with anything | 17:40 |
| micahg | I'd posit that regardless of what you're targetting, what matters is where the development is done, the development for ebox is done as part of the ebox/zentyal project, not the Ubuntu project | 17:40 |
| * scott-work realizes this is a pretty feeble offer | 17:40 | |
| dupondje | Got some question about modifying upstart scripts for cryptsetup. Now we have 2 init scripts that take care of the stop, and 2 upstart scripts to handle starting of the devices. Now I would like to integrate the init stuff in the upstart scripts. Now the thing is, should the dm-crypt mappings be removed manually by the script? Or can we let the kernel handle it? | 17:41 |
| infinity | micahg: I think that's again splitting hairs, if all releases are meant to be released to the Ubuntu archive, where the development "happens" doesn't matter to me. | 17:42 |
| * micahg is thinking of adding an item to the TB agenda if they're not dealing with more important issues | 17:42 | |
| infinity | micahg: All the development for my latest native upload happened on my hard drive. Totally not an Ubuntu-blessed VCS. And it was part of my own "flip bits on my hard drive until a package comes out" project. | 17:43 |
| infinity | (Which was successful, by the way, I'm a wizard with tiny magnets) | 17:43 |
| micahg | infinity: I'm not referring specifically to the VCS location either | 17:44 |
| infinity | micahg: The only difference at all between me and them is that I didn't need to beg a sponsor to bless my upload. | 17:44 |
| infinity | micahg: As an added point, my latest native package actually could be used on any system with upstart, probably. So it's even less valid as native than theirs is, but no one challenged it when I uploaded. :P | 17:44 |
| infinity | micahg: And, if I decide to convert it to something I could upload to Debian, then I'd un-native it, and do some upstream/distro split. | 17:45 |
| infinity | micahg: But as long as it exists in exactly one distro, and every change has been targetted at release to that one distro, that's perfectly valid as native. | 17:46 |
| cjwatson | scott-work: shouldn't be desperately hard, just rsyncing a current image | 17:51 |
| micahg | infinity: while I agree that defines it as native to Ubuntu, I don't agree that stuff in the archive should be like that :) | 17:52 |
| infinity | broder: Pingaling. I understand you have a lintian lab you might be able to let me play with (or play with on my behalf)? | 17:52 |
| infinity | broder: I need a broad grep -r of */debian for armel, so I can go through with a fine-toothed comb and make sure any armel tweaks/etc have been applied to armhf. | 17:54 |
| === beuno is now known as beuno-lunch | ||
| === beuno-lunch is now known as beuno | ||
| scott-work | cjwatson: well, my offer is not all philanthropical ;) , i'd like to learn whatever i can as well :-) | 17:59 |
| ScottK | infinity: One in particular to look for is !armel specifications in debian/control. I've been doing amd64 i386 powerpc instead for awhile knowing armhf was coming. | 18:00 |
| infinity | ScottK: Anything .*armel.* needs looking at, really. | 18:01 |
| ScottK | infinity: True, I just know there are !armel incantations around that are buggy. | 18:01 |
| infinity | Most of them are probably incorrect for armel too. | 18:01 |
| cjwatson | scott-work: it needs testing, but it's probably http://paste.ubuntu.com/880708/ in casper | 18:03 |
| cjwatson | or something along those lines | 18:03 |
| slangasek | Riddell: any news about soprano testing? | 18:24 |
| slangasek | ScottK: when you say that the farsight transition is fixed, that doesn't seem to encompass python-papyon being transitioned to python-farstream... did these packages simply get removed from the Kubuntu dependency stack? | 18:26 |
| ScottK | slangasek: The solution for python-papyon was removal. | 18:32 |
| ScottK | (from the archive) | 18:33 |
| ScottK | There's probably more that could be done to progress farsight/farstream, but the thing that was breaking the image builds is resolved. | 18:33 |
| dupondje | Got some question about modifying upstart scripts for cryptsetup. Now we have 2 init scripts that take care of the stop, and 2 upstart scripts to handle starting of the devices. Now I would like to integrate the init stuff in the upstart scripts. Now the thing is, should the dm-crypt mappings be removed manually by the script? Or can we let the kernel handle it? | 18:34 |
| stgraber | @pilot out | 18:42 |
| === udevbot changed the topic of #ubuntu-devel to: Precise Beta-1 Released. Archive: open | Development of Ubuntu (not support, not app development) | build failures -> http://bit.ly/xmGdCW | #ubuntu for support and general discussion for hardy -> oneiric | #ubuntu-app-devel for app development on Ubuntu | http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: | ||
| === MacSlow|dinner is now known as MacSlow | ||
| slangasek | ScottK: oh, now I see; somehow I thought empathy was being removed rather than upgraded, but apparently no | 18:47 |
| scott-work | cjwatson: thank you! | 18:58 |
| scott-work | cjwatson: i presume that this will properly configure jack in the liveFS which in turn will yield an installed FS which also is configured correctly, am i misunderstanding this? | 19:01 |
| Riddell | slangasek: oh sorry, soprano is all good | 19:17 |
| Riddell | did I fail to say that on the bug? | 19:17 |
| slangasek | Riddell: ah, apparently :) no worries, I'll upload now - thanks! | 19:17 |
| broder | infinity: i've been stalling on actually setting things up so i can give other people access, but i think it's actually time for me to come up with a real solution. give me a little while to come up with something | 19:28 |
| infinity | broder: Sure. If it's too much hassle, I'm happy with just the output of the above greppination. | 19:28 |
| infinity | broder: But being able to give access based on ssh keys from LP or something would be shiny. | 19:29 |
| broder | infinity: yeah, i've been meaning to set that up, and as of the last few weeks, i think we've crossed the threshold where it's more work for me to keep ad-hocing it for people than setting it up so i can use ssh keys from LP | 19:30 |
| * infinity just got the evil idea to write a launchpad->userdir-ldap import/sync shim. | 19:31 | |
| infinity | Some days, I don't like myself. | 19:31 |
| infinity | This is one of them. | 19:31 |
| broder | have to say, it is slightly irritating that i can just grab /+sshkeys but can't get it through the lp api anonymously | 19:35 |
| infinity | broder: Well, I suppose it's a potential information leak, since ssh keys are often in the form user@host. | 19:36 |
| broder | infinity: yeah, but https://launchpad.net/~broder/+sshkeys is accessible without authenticating | 19:37 |
| infinity | broder: Oh, it is? | 19:37 |
| infinity | Nevermind, then. | 19:37 |
| infinity | It's obviously broken in one direction or the other. :P | 19:37 |
| broder | maybe i shouldn't make too much fuss about it or someone might fix it the wrong way :-P | 19:37 |
| infinity | I'd probably be inclined to go that way, yeah. | 19:38 |
| infinity | Given that you can't see people's email addresses without being logged in, the potential disclosure issue in ssh public key comments is similar. | 19:38 |
| ajmitch | ssh-import-id sort of relies on it being publically accessible, doesn't it? | 19:39 |
| infinity | ajmitch: It does, yes. | 19:40 |
| infinity | ajmitch: Though, it could certainly be rewritten to be a launchpadlib application that requires authentication. | 19:40 |
| infinity | I'm not sure I care deeply, mind you. | 19:40 |
| infinity | But I don't really care about that level of disclosure in general. | 19:41 |
| infinity | People still wonder why I don't obfuscate my whois records and such. | 19:41 |
| cjwatson | scott-work: it does both separately, hence the separate casper-bottom and ubiquity-hooks scripts - the installed system starts by copying the squashfs contents, not by copying the live session | 19:41 |
| broder | the problem with making it a lplib application is that i now have to put my lp credentials on my server for it to be useful | 19:41 |
| infinity | broder: That's where my ud-ldap/launchpad shim idea comes in. | 19:42 |
| scott-work | cjwatson: okay, that makes more sense looking at the pastebin, thank you :) | 19:42 |
| infinity | broder: Since ud-ldap does central processing, then pushes bits out to machines, you wouldn't need to have credentials anywhere but that one spot. | 19:42 |
| broder | infinity: ah, sure. but ewww, ldap | 19:43 |
| infinity | broder: Meh. ud-ldap's ldap part could be repaced by anything, really. | 19:43 |
| infinity | broder: It's the ssh triggering or passing around nss-db bits (and keeping machines entirely independant of network failures) that's shiny. | 19:44 |
| infinity | s/or/of/ | 19:44 |
| === barry` is now known as barry | ||
| === rsalveti` is now known as rsalveti | ||
| kirkland | infinity: no, please no....requiring lp authentication would break many (most?) ssh-import-id use cases | 20:37 |
| kirkland | broder: I didn't catch your use case, sorry, but would ssh-import-id suffice for what you want to do? | 20:38 |
| broder | kirkland: not entirely. i wanted to create separate accounts for each person i was handing out access to | 20:38 |
| kirkland | broder: accounts where? in a cloud instance? | 20:40 |
| broder | kirkland: personal server | 20:40 |
| kirkland | broder: sudo adduser && ssh-import-id? | 20:40 |
| broder | pretty much what i did | 20:40 |
| kirkland | broder: ;-) | 20:41 |
| gang65 | !regression-alert | 20:48 |
| ubottu | cjwatson, jdong, pitti, skaet, ScottK, kees, Daviey, pgraner: reporting regression in a stable release update; investigate severity, start an incident report, perhaps have the package blacklisted from the archive | 20:48 |
| ScottK | gang65: What's up? | 20:49 |
| gang65 | bug #410262 | 20:49 |
| ubottu | Launchpad bug 410262 in xserver-xorg-video-openchrome (Debian) "[VX800]openchrome hangs when the mouse cursor is inside of a image in gimp" [Unknown,Confirmed] https://launchpad.net/bugs/410262 | 20:49 |
| gang65 | two patches was send instead of one | 20:50 |
| gang65 | 100_fix_xaa_display_issues.patch is correct | 20:50 |
| gang65 | 101_xaa_solid.patch is wrong | 20:51 |
| gang65 | It causing the system hangs | 20:51 |
| infinity | Given how long that bug's been open, I'm thinking it doesn't warrant use of the emergency broadcasting system. ;) | 20:53 |
| ScottK | infinity: The fix is rather more recent. | 20:54 |
| infinity | ScottK: Yes, but it's only in -proposed, is it not? | 20:55 |
| ScottK | infinity: No, it's in updates | 20:55 |
| infinity | Oh, indeed. | 20:55 |
| infinity | I missed that. | 20:55 |
| ScottK | It's been there for a week, so there's probably no point in blocking it now, but it should be addressed. | 20:56 |
| infinity | Oh, no question that it should be fixed. | 20:56 |
| infinity | Just that it doesn't appear world-endingly incident-report-needing. | 20:56 |
| ScottK | bryceh: Can you look into this oneiric-proposed regression ^^^ | 20:56 |
| ScottK | infinity: Usually they aren't unless they affect you. | 20:57 |
| infinity | ScottK: Well, it looks like it might just be trading one hang for another. ;) | 20:57 |
| ScottK | infinity: Someone will need to start an incident report and all that stuff too. Can you drive? | 20:57 |
| ScottK | Dunno. | 20:57 |
| infinity | ScottK: I'd prefer someone closer to the issue (ie: bryceh) do the reporting. | 20:58 |
| infinity | He's in a better position to tell if it's actually necessary, and what steps should be taken. | 20:58 |
| infinity | (And I was about to head to lunch) | 20:58 |
| * ScottK is at EOD. | 20:58 | |
| * ScottK looks for maybe slangasek. | 20:58 | |
| ScottK | He should be on that alert too. | 20:58 |
| infinity | Normally, I probably should be too. No idea who to talk to about mangling it. | 20:59 |
| slangasek | mangling what? | 21:00 |
| * mneptok perks | 21:00 | |
| infinity | Either way, I'm not sure about the severity of this one, reading through the logs. It seems the upload solved problems for some, and possibly caused problems for others. If removing that one patch makes it work for everyone, yay, but I don't think things are "worse" now, just "different". | 21:00 |
| infinity | slangasek: The regression-alert thingamajig. | 21:01 |
| gang65 | The main problem with this bug is that two patches was pushed: | 21:01 |
| slangasek | oh, the bot output? I don't know | 21:01 |
| ScottK | slangasek: In any case we need someone to drive this regression alert to ground and I'm EOD and infinity is just about to leave. | 21:02 |
| infinity | gang65: I see that. You also reported that it worked for you, though. Can you reproduce the hang that the other reporter is seeing? | 21:02 |
| ScottK | I think it's mostly hunting down Bryce and making him look at it. | 21:02 |
| gang65 | yes I could reproduce this | 21:02 |
| infinity | gang65: Ahh. The bug log isn't clear on that point. | 21:03 |
| infinity | (hint) | 21:03 |
| gang65 | And Thomas Schlichter also | 21:03 |
| infinity | Anyhow, I have to run out for 30 minutes. | 21:05 |
| slangasek | gang65: can you confirm whether or not precise is affected? | 21:05 |
| scott-work | cjwatson: is line #17 correct in http://paste.ubuntu.com/880708/ ? | 21:06 |
| slangasek | bryceh: around? Seems to have been a regression in the recent openchrome SRU ^^ | 21:06 |
| scott-work | should it include a pair of parenthesi ? | 21:06 |
| gang65 | @slangasek No. Precise is not affected (it has a new openchrome version) | 21:08 |
| udevbot | Error: "slangasek" is not a valid command. | 21:08 |
| slangasek | gang65: ok, thanks | 21:08 |
| Q-FUNK | ev: it appears that whoopsie leaves an obsolete config from early releases. | 21:32 |
| broder | Q-FUNK: i'm confused. i added a bluez.maintscript that should be cleaning up the conffile... | 21:45 |
| Q-FUNK | broder: apparently, it doesn't work as intended. | 21:46 |
| broder | grr | 21:46 |
| broder | ok, looking | 21:46 |
| bryceh | slangasek, I'm off today. Does it need solved now or can it wait? | 21:47 |
| bryceh | slangasek, probably should just revert both patches to be safe | 21:48 |
| slangasek | bryceh: I imagine it can wait until tomorrow; the SRU was published a week ago and the regression is just now coming to light | 21:49 |
| bryceh | slangasek, I had sru'd them under the belief that the patches were well tested and safe; since it appears that's not the case, it's not worth having as an sru | 21:49 |
| slangasek | bryceh: the second patch is reported to not be upstream at all, the first patch is confirmed by two users to improve things? | 21:50 |
| slangasek | (including the user reporting the regression) | 21:50 |
| bryceh | slangasek, well the trouble is that VIA hardware for testing openchrome is rather rare (I haven't got any), so validating changes is especially tough | 21:51 |
| slangasek | it seems there are at least two users available to test, which meets the SRU criteria | 21:52 |
| bryceh | slangasek, well I'm thinking this might be one of those self-selecting cases | 21:52 |
| bryceh | i.e. people who have the bug test... but if the patch breaks people that have different hardware, we won't get those test results until it goes out live | 21:53 |
| bryceh | which presumably is what happened here | 21:53 |
| slangasek | no, gang65 who tested the SRU was also able to confirm the regression afterwards; so this particular one wasn't an issue with differing hardware | 21:54 |
| slangasek | the regression was just a corner case he didn't test initially | 21:54 |
| bryceh | hmm, ok. does the upstream patch alone fix it? iirc some commenters said only with both patches did the original issue go away | 21:55 |
| slangasek | as far as I understand the bug log, yes, the first upstream patch is sufficient | 21:56 |
| slangasek | actually, now I'm doubting | 21:57 |
| slangasek | since the regression reported by Thomas Schlichter is simply that the original bug was not fixed | 21:58 |
| bryceh | slangasek, see last few comments on http://www.openchrome.org/trac/ticket/402 | 21:58 |
| slangasek | so I can't understand how gang65 both confirmed the regression, *and* correctly verified the fix in the first place | 21:58 |
| bryceh | yeah, it's a bit confusing | 21:58 |
| slangasek | ok | 21:59 |
| slangasek | muddled history, not actually a regression (just a case of the bug not really being fixed); so not urgent at all | 21:59 |
| bryceh | slangasek, okie. shall I still keep it on my todo list to look at tomorrow? | 22:00 |
| slangasek | bryceh: that would be appreciated | 22:01 |
| bryceh | will do. | 22:01 |
| broder | cyphermox: are you still possibly uploading bluez soon? i've spotted the bug in my change | 22:05 |
| broder | (just want to check if we're going to step on each others' toes) | 22:05 |
| === yofel_ is now known as yofel | ||
| broder | Q-FUNK: spotted the bug - i screwed up the version number when i call dpkg-maintscript-helper | 22:06 |
| Q-FUNK | broder: that would explain it. :) | 22:07 |
| broder | Q-FUNK: i had the upload prepped, and then discovered that cyphermox had already uploaded bluez, so i had to merge his changes in and forgot to update it | 22:08 |
| broder | so if you had upgraded from 4.98-2ubuntu1 instead...:) | 22:08 |
| Q-FUNK | broder: do you actually need to specify the last applicable version though? | 22:08 |
| broder | Q-FUNK: it's not strictly necessary, but it makes sure that the migration code only runs once | 22:09 |
| chilicuil | hi there, I'm trying to test if an app is completly translated in the latest ubuntu release, I do have a chroot environment (pbuilder) with it, how can I make it?, I know that the package is not complety translated, since I've it in ubuntu oneiric, I'd like to translate what's left, I've tried to branch the lp:pkg branch with no sucess, and the lp page https://launchpad.net/ubuntu/+source/klavaro has the "translations" link grayed out | 22:10 |
| dupondje | Got some question about modifying upstart scripts for cryptsetup. Now we have 2 init scripts that take care of the stop, and 2 upstart scripts to handle starting of the devices. Now I would like to integrate the init stuff in the upstart scripts. Now the thing is, should the dm-crypt mappings be removed manually by the script? Or can we let the kernel handle it? | 22:14 |
| === salem_ is now known as _salem | ||
| slangasek | kenvandine: hi, are you planning to follow up on the farsight->farstream transition so that we're not left carrying around an obsolete source package in universe for precise? | 22:18 |
| slangasek | dupondje: what is it you're trying to accomplish by integrating this into the upstart jobs? That's a high risk change that I think is clearly not appropriate for a post-FF change | 22:20 |
| slangasek | dupondje: all of our filesystem teardown in 12.04 is still being done via sysvinit | 22:20 |
| dupondje | slangasek: now we have 4 init scripts for cryptsetup. Would like to only use upstart for it. | 22:21 |
| dupondje | and not for FF btw, but for Precise+1 :) | 22:21 |
| slangasek | well, we use init scripts for the teardown because we use init scripts for all the fs teardown | 22:22 |
| slangasek | so any changes there need to include the big picture | 22:22 |
| dupondje | Thats getting changed or ? | 22:22 |
| slangasek | there aren't any plans about changing it yet | 22:22 |
| Nisstyre | Why hasn't Ubuntu added a "python2" symlink to "python" yet? | 22:23 |
| dupondje | Ok, cause its a bit dirty imo to have 4 scripts for 1 'service' :) | 22:23 |
| dupondje | I'm thinking for some ways to make it bit cleaner | 22:24 |
| slangasek | Nisstyre: because /usr/bin/python is already assured to be python2, so adding that symlink would just encourage creating unportable scripts | 22:26 |
| Nisstyre | slangasek: it would make them more portable according to pep 394 | 22:26 |
| jtaylor | that pep is not accepted yet | 22:26 |
| Nisstyre | since "python" will invoke the python 3 interpreter on some systems | 22:27 |
| Nisstyre | fair enough | 22:27 |
| slangasek | on what systems? Any system using 'python' to refer to python 3 is horribly broken | 22:27 |
| slangasek | and pep 394 offers no clean upgrade path | 22:27 |
| Nisstyre | slangasek: Arch Linux as well as Gentoo in the future | 22:28 |
| slangasek | really? broken | 22:28 |
| Nisstyre | slangasek: it's not manditory that python should refer to python 2 | 22:28 |
| Nisstyre | *mandatory | 22:28 |
| Nisstyre | It would be nice if there were something that could work across all major distros, such as "python2" | 22:29 |
| broder | Nisstyre: it would be nice if distros like Arch and Gentoo didn't arbitrarily go breaking every Python script in existence | 22:29 |
| infinity | Until very recently, that thing was 'python'... | 22:29 |
| dupondje | slangasek: would it for example be possibel to add 'stop on runlevel [016]' to the upstart? This would emulate the same as the current init script does? | 22:32 |
| slangasek | dupondje: definitely not | 22:32 |
| jtaylor | oh interesting pep 394 was accepted recently | 22:33 |
| dupondje | myea no sequence number :( | 22:33 |
| slangasek | dupondje: right. also, the jobs are tasks, so they're stopped as soon as they finish, so 'stop on' won't help :) | 22:33 |
| dupondje | so I guess there is not really a more clean way then the current situation? | 22:34 |
| slangasek | dupondje: yep, not really | 22:35 |
| slangasek | not without significant changes to the shutdown | 22:35 |
| dupondje | 'to the shutdown' as in upstart you mean then? | 22:35 |
| slangasek | dupondje: I mean a systematic transition for /etc/rc6.d | 22:36 |
| dupondje | now finding a clean way to patch this in debian :) so we can sync in the future | 22:37 |
| doko | Nisstyre, slangasek: "python should refer to the same target as python2 but may refer to python3 on some bleeding edge distributions". so no, it won't point to python3 in Ubuntu | 22:41 |
| Nisstyre | doko: Sorry if I wasn't clear. I never said Ubuntu should point python to python3 | 22:42 |
| dupondje | anyway slangasek thanks for the info :) | 22:42 |
| infinity | doko: I think that was already well-established, he was saying that we should also have python2 pointing to python2.7 | 22:42 |
| jtaylor | which it already does in precise btw | 22:42 |
| slangasek | oh, does it really? | 22:42 |
| doko | yes | 22:43 |
| === jbicha is now known as Guest1267 | ||
| slangasek | doko: when this was discussed last on debian-python, wasn't it agreed that it was a bad idea to provide this? Is it there now because the PEP has been approved? | 22:43 |
| infinity | Oh, it seems upstream was changed to provide the python->python2->python2.7 link chain. | 22:44 |
| jtaylor | I think the opinion was its a bad idea but if the pep gets accepted it will go in | 22:44 |
| infinity | Nisstyre: So, there you have it. It does what you want. | 22:44 |
| Nisstyre | infinity: thanks for the information then | 22:45 |
| doko | slangasek, I never thought it would be a bad idea, but some people did want to have the pep formally approved | 22:46 |
| slangasek | doko: right | 22:46 |
| slangasek | doko: fwiw I don't think it was a good idea either, but we might as well go along with it :) | 22:47 |
| broder | it's good that, after the python community went through all the trouble of separating out the backwards-incompatible changes, they've decided to open the door for making a backwards-incompatible change | 22:48 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!
