| skaet | slangasek, hiya, its Tuesday now, so can you start the freeze for Alpha 1? | 00:04 |
|---|---|---|
| bdmurray | that's interesting - https://errors.ubuntu.com/problem/fa095349a2a96bc2138b8372276f7ad69d05671f | 00:21 |
| sarnold | haha, nice | 00:27 |
| doko | Logan_, well, do them, but maybe using dh-autoreconf. if you do watch the changes ML, you'll see a bunch of uploads for another port where autotools-dev is not enough | 00:34 |
| Logan_ | ppc64lezgfeigzze? | 00:34 |
| Logan_ | Or whatever it's called. | 00:34 |
| Logan_ | doko: Wait, so... dh-autotools-dev is not enough for ppc64el? | 00:36 |
| === jppunaqyre is now known as wcchandler | ||
| doko | kees, well, I can't sync, because I disabled the diversion, and removed the the old gcc diversions | 00:37 |
| cjwatson | Logan_: sometimes but not always; any package that uses libtool tends to need the patch from https://launchpad.net/ubuntu/+source/libtool/2.4.2-1.3ubuntu2 applied, which dh-autoreconf usually manages | 00:37 |
| cjwatson | but bear in mind that dh-autoreconf on its own won't necessarily always update config.guess/sub (though it always does at least when libtool is involved) | 00:38 |
| cjwatson | care and understanding is needed :) | 00:38 |
| Logan_ | Fun. | 00:38 |
| cjwatson | ppc64el does need *at least* config.guess/sub updates | 00:39 |
| Logan_ | Also...why do we call it el? Isn't it le? | 00:39 |
| Logan_ | "endian little" | 00:39 |
| cjwatson | mipsel | 00:39 |
| StevenK | Logan_: mipsel | 00:39 |
| cjwatson | precedent tends to win | 00:39 |
| Logan_ | Oh right. | 00:39 |
| StevenK | There was a proposal for sh4eb too | 00:40 |
| cjwatson | and of course armel | 00:40 |
| cjwatson | though you could retcon the "e" as "EABI" there | 00:40 |
| Logan_ | Oh, and another unrelated question. Devscripts was recently updated to make the default urgency "medium," and it's affecting the priority of new uploads coming from trusty when it comes to the buildds. Should the priority formula be tweaked? | 00:41 |
| cjwatson | Is it really necessary to do anything there? | 00:41 |
| cjwatson | It doesn't make that much difference | 00:42 |
| Logan_ | I suppose... | 00:42 |
| StevenK | It's 10 versus 5 | 00:42 |
| Logan_ | I'm thinking we should revert the change in Ubuntu. It's making changelogs confusing for the enduser, I think. | 00:42 |
| === ejv_ is now known as ejv | ||
| cjwatson | And we're not often backlogged there | 00:43 |
| Logan_ | Because they'll be like, "why was a typo fix medium urgency?" | 00:43 |
| cjwatson | I'd rather not have deltas we don't really need | 00:43 |
| Logan_ | Well then we should SRU it, imo. All or nothing. It doesn't make sense to have uploads coming from t+ being medium urgency, and s- low urgency. | 00:43 |
| cjwatson | I think that'll balance out against the people who go "why was this OMG vital critical fix low urgency" at the moment | 00:43 |
| cjwatson | I think we should just leave well alone and not make work for ourselves :) | 00:44 |
| Logan_ | Lol, it's killing my OCD | 00:44 |
| cjwatson | it'll balance out in a few years | 00:44 |
| YokoZar | Clearly we prioritize uploads coming from people actually running the dev version. | 00:45 |
| Logan_ | Just to push my agenda, I just did an autotools update for black-box, and it built immediately on ppc64el, before the 10785-job backlog (with a dependency wait, of course). I guess I shouldn't be complaining. :P | 00:52 |
| cjwatson | honestly, it doesn't much matter which order that backlog builds in | 00:53 |
| cjwatson | if we want something quickly we'll score it up | 00:53 |
| Logan_ | I know, I'm just being annoyingly pedantic. :P | 00:54 |
| cjwatson | also, anything in proposed would already have built ahead of most of the backlog (the bulk of which is in the release pocket, with a lower score) | 00:54 |
| * Logan_ shuts up. | 00:54 | |
| cjwatson | so it didn't advance it all that much | 00:54 |
| cjwatson | only by 250 jobs or so | 00:55 |
| cjwatson | which at this rate amounts to an hour or two :) | 00:56 |
| cjwatson | (I like fast architectures) | 00:56 |
| Logan_ | It is impressive how quickly ppc64el is chugging through the packages, given the growing pains that the arm64 buildds had during the Saucy cycle. | 00:59 |
| cjwatson | yeah, great difference between experimental hardware and solid server-class | 01:01 |
| cjwatson | it'll be quicker than LP's estimate | 01:03 |
| cjwatson | I bet 6 days earlier today, but it's gone from 11 to 9 in twelve hours or so, so I suspect even that estimate is generous | 01:04 |
| Logan_ | How much money on the bet? ;P | 01:06 |
| Logan_ | JackYu: Please fix your connection, or ubottu will eat you for dinner. | 01:11 |
| xnox | bdmurray: cool =) fork-bomb? | 02:42 |
| Logan_ | xnox: https://launchpad.net/ubuntu/+source/libtk-img/1:1.3-release-12ubuntu2 --> https://launchpad.net/ubuntu/+source/libtk-img/1:1.3-release-12ubuntu3 | 03:32 |
| Logan_ | *cough* *cough* :P | 03:32 |
| Logan_ | (fwiw, I just tested it, and the mentioned bug is happening again) | 03:32 |
| xnox | Logan_: lol :P | 03:33 |
| xnox | Logan_: is that ABI break on img::tiff side and can be fixed for real? | 03:34 |
| xnox | Logan_: src:tiff3 is now filed for removal ther literarly is nothing depending on it, but this package. | 03:34 |
| Logan_ | I honestly have no idea. All I know is that reverting back to libtiff4-dev fixes it. | 03:34 |
| Logan_ | Yeah... :/ | 03:35 |
| Logan_ | Maybe move it to proposed? | 03:35 |
| xnox | well, a revert is not an option any more. it needs to be fixed properly. | 03:35 |
| Logan_ | Actually... http://packages.qa.debian.org/libt/libtk-img/news/20131215T173505Z.html | 03:36 |
| Logan_ | Maybe the new release fixes it. I'll do a test build and test. | 03:36 |
| Logan_ | If it works, I'll sync. | 03:36 |
| xnox | Logan_: maybe we want the libtiff patches from fedora/gentoo? http://sources.gentoo.org/cgi-bin/viewvc.cgi/gentoo-x86/dev-tcltk/tkimg/files/ | 03:38 |
| xnox | Logan_: i wonder if that's the same patchset =) | 03:38 |
| Logan_ | Quite possibly. | 03:38 |
| StevenK | There is this thing, called diff, perhaps you guys have heard of it ... | 03:39 |
| Logan_ | Not sure what you're trying to go for here. | 03:40 |
| Logan_ | Oh, haha. Comparing the patches? | 03:41 |
| Logan_ | xnox: Oh goodie. The new Debian version FTBFSed. | 03:42 |
| * Logan_ cries. | 03:42 | |
| xnox | Logan_: well there is interdiff as well. | 03:42 |
| Logan_ | 'JPEG_LIB_VERSION' undeclared | 03:42 |
| Logan_ | Seems like a linking issue. | 03:42 |
| xnox | StevenK: =))))) at 3:42am my care factor for libtiff for tk is not that high =)))) | 03:43 |
| Logan_ | ...or maybe just a lack of declaration issue. | 03:43 |
| xnox | StevenK: to like actually read diffs ;-) | 03:43 |
| StevenK | xnox: To quote Matthew Garrett, perhaps you should read some autoconf macros to induce a coma. | 03:44 |
| xnox | StevenK: =)))))))))))))))))) brilliant ! | 03:44 |
| Logan_ | xnox: http://paste.ubuntu.com/6592395/ <-- my local build log for libtk-img 1:1.4.2-3 | 03:44 |
| xnox | Logan_: missing multi-arch ? | 03:46 |
| xnox | Logan_: #define JPEG_LIB_VERSION 80 is in /usr/include/$(DEB_HOST_MULTIARCH)/jconfig.h | 03:47 |
| Logan_ | xnox: wait how do you do that what | 03:47 |
| xnox | =)))))))))) | 03:48 |
| xnox | let me actually grab the source. | 03:48 |
| Logan_ | command plz | 03:48 |
| Logan_ | did you just grep it | 03:49 |
| xnox | nah just a hunch. similar defines are usually part of a config.h or some such, and usually end up being multiarched into multiarch location. | 03:50 |
| xnox | however | 03:51 |
| Logan_ | $ sudo grep -R 'define JPEG_LIB_VERSION' /usr/include | 03:51 |
| Logan_ | /usr/include/x86_64-linux-gnu/jconfig.h:#define JPEG_LIB_VERSION 80 | 03:51 |
| Logan_ | look I can be all linuxy too | 03:51 |
| xnox | i did pull-debian-source and it builds fine in trusty sbuild | 03:51 |
| Logan_ | Which arch? | 03:51 |
| Logan_ | And are you sure you did the right version? Because p-d-s got the old version for me before I explicitly specified the new one | 03:52 |
| xnox | or more precise which version =) apperantly pull-debian-source doesn't know about 1.4 yet | 03:52 |
| Logan_ | ^ | 03:52 |
| xnox | it's building it's own copy of zlib =/ i thought that is autorejected by ftp-masters /o\ | 03:54 |
| slangasek | e-gratuitous-use-of-sudo | 03:54 |
| * xnox really does not like this package | 03:54 | |
| Logan_ | slangasek: oh shush :P | 03:54 |
| * slangasek complies, and leaves the keyboard as he promised himself he would | 03:55 | |
| xnox | slangasek: have you seen the 13.10 thread? the argument is based on XP users being upgrade savvy... =) | 03:55 |
| Logan_ | Oh no, I installed grep from a rogue repository, and now it's taking over my computer! ;P (but touché) | 03:55 |
| xnox | Logan_: well we did have ext4 zero out files before.... | 03:56 |
| Logan_ | xnox: I think it's a perfectly valid argument, but it's way too late. | 03:56 |
| StevenK | Logan_: I must of missed the patch to grep that has it farm for bitcoins | 03:57 |
| Logan_ | xnox: back to more important things than my VM which is not currently being zeroed out | 03:57 |
| Logan_ | StevenK: dogecoins, actually | 03:57 |
| xnox | Logan_: honestly not a single xp user will notice 2014 come and go. They have already been getting enough warnings, and MS did bump xp support cycle multiple times now.... | 03:58 |
| Logan_ | xnox: did it fail in your build | 03:58 |
| Logan_ | *sbuild | 03:58 |
| xnox | looks like it's building against a local copy of libjpeg and a system one, which seems very odd. | 04:01 |
| Logan_ | Wait, why does it have it's own jconfig.h? | 04:01 |
| Logan_ | *its | 04:01 |
| Logan_ | in libjpeg/libjpeg | 04:02 |
| Logan_ | Looks like we reached the same conclusion. :P | 04:02 |
| Logan_ | I'm going to examine the diff to see if this was caused by the new upstream release. | 04:03 |
| Logan_ | There's some weird shit going on in this package. There's a patch for "dynamic linking to system-wide libjpeg." | 04:05 |
| kees | doko_: which diversion did you disable? | 04:17 |
| kees | (and why?) | 04:17 |
| xnox | Logan_: http://paste.ubuntu.com/6592467/ ? | 04:20 |
| Logan_ | xnox: Does it work? | 04:21 |
| xnox | Logan_: did locally, testing in sbuild. | 04:21 |
| Logan_ | Okay. Looks good to me. Although why did you change those other lines? | 04:22 |
| xnox | i'm building cross-toolchain at the same time so my machine is busy. | 04:22 |
| Logan_ | I'm a bit of a n00b when it comes to multiarch, so I'd like to know. | 04:22 |
| xnox | Logan_: i needed DEB_HOST_MULTIARCH, and instead of +1 line, i could remove all of those. | 04:22 |
| Logan_ | I see. | 04:22 |
| xnox | and use default.mk which include architecture.mk which defines all combinations of DEB_* variables | 04:22 |
| Logan_ | Alright, gotcha. | 04:22 |
| Logan_ | I'll save that diff for future reference. :P | 04:24 |
| Logan_ | It'll go in my folder of "smart things Ubuntu/Debian developers have done to fix things that I'll definitely encounter in the future." | 04:25 |
| Logan_ | Well, I hopefully won't encounter a package this odd in the future, but you never know. | 04:25 |
| xnox | ... i rather hope nobody ever encounters that =) | 04:28 |
| xnox | Logan_: the bigger question however, is to see if it works ;-) | 04:28 |
| Logan_ | Oh right. Forgot about that. | 04:29 |
| xnox | and that bug is not present. | 04:29 |
| darkxst | pitti, hi, is it possible to get a source packages dependencies from LP api? | 05:14 |
| Logan_ | xnox: If you're still around, would you mind helping me figure out why this isn't building? https://launchpad.net/ubuntu/+source/ns2/2.35+dfsg-1ubuntu1/+build/5360743 | 05:15 |
| xnox | Logan_: checking for libtcl8.5... no | 05:16 |
| xnox | Logan_: probably fails to find multiarch tcl, and it's trying to parse the compat tctConfig.sh script direct instead of sourcing it | 05:16 |
| xnox | Logan_: there should be a configure option to pass, with exact / multiarch location for tcl | 05:17 |
| Logan_ | Okay, I'll check it out. Looks like this similar bug might have a potential fix: https://bugs.launchpad.net/ubuntu/+source/db/+bug/1160445 | 05:19 |
| ubottu | Ubuntu bug 1160445 in db (Ubuntu) "FTBFS: update for m-a tclConfig.sh path" [Undecided,Fix released] | 05:19 |
| Logan_ | xnox: I passed --with-tcl=/usr/lib/$(DEB_HOST_MULTIARCH) to debian/rules, but now it fails with this: http://paste.ubuntu.com/6592645/ | 05:24 |
| Logan_ | It appears to have fixed the libtcl8.5 part but broken everything else. :( | 05:24 |
| Logan_ | Well I'm stupid. There's a patch fixing this in Debian's BTS. :P | 05:29 |
| xnox | debian has tcltk multiarched as well now, so all patches should be forwarded to debian and/or become a debian bug as well. | 05:30 |
| Logan_ | We're all good now. | 05:38 |
| pitti | darkxst: not that I know of | 06:07 |
| pitti | Good morning | 06:07 |
| darkxst | pitti, ok, I couldnt see anything either, time to find a new plan... | 06:08 |
| pitti | darkxst: what's wrong with getting it from python-apt? | 06:08 |
| === tvoss is now known as tvoss|test | ||
| === tvoss|test is now known as tvoss | ||
| darkxst | pitti, only that the server I am running the script on is not ubuntu, however I guess I can do just that in a chroot | 06:15 |
| pitti | darkxst: have a look at chdist, it's really useful for things like that | 06:15 |
| pitti | and it only needs the Packages indexes, not the actual packages (i. e. full chroot) | 06:15 |
| darkxst | server is not debian either, so need a chroot to even run chdist! | 06:17 |
| pitti | darkxst: ah, in that case it might perhaps suffice to wget -O- http://archive.u.c./.../Sources.gz | gzip -cd | <some perl magic to grep for the Package: and Build-Deps> ? | 06:33 |
| pitti | or copy grep-dctrl to that server, to at least ease that bit | 06:33 |
| pitti | ldd /usr/bin/grep-dctrl → doesn't use anything special, just libc | 06:34 |
| darkxst | pitti, ok, thanks. will look into it | 06:34 |
| xnox | .... m4 .... my eyes are sore, hunting down two stray spaces =/ | 06:35 |
| xnox | pitti: morning =) | 06:36 |
| pitti | anyone from ubuntu-release around at this hour? | 06:38 |
| pitti | infinity: could you plese set an exfail/britney hint for adequate? its autopkgtest requires "breaks-testbed" and we cannot currently handle that with our null runner | 06:39 |
| pitti | it holds back the new perl version, which in turn holds back some other stuff | 06:39 |
| infinity | pitti: I can do. | 06:39 |
| pitti | ah, it's also part of the a1 freeze, but at least it'll promote automatically after it then | 06:40 |
| infinity | pitti: I can't do it unversioned, though, so it'll have to be bumped with each sync. Maybe we should just introduce a delta that disables that test? | 06:40 |
| pitti | I was looking for the excuses/update_output for postgresql-9.1 and postgis, but it seems it's gone from update_output | 06:40 |
| pitti | infinity: ah, ok; I'll look into that then; we can drop the breaks-testbed and just run the most important test | 06:41 |
| infinity | pitti: Kay, that's probably the saner way to go for now. | 06:41 |
| pitti | infinity: so, never mind | 06:41 |
| infinity | pitti: And maybe make a note of any packages you mangle in such a way in a TODO reminder for if/when our testbeds support breaking. :P | 06:41 |
| pitti | *nod* | 06:41 |
| pitti | oh, it's just one test anyway, so we can drop it | 06:42 |
| infinity | pitti: Kay, that'd definitely better than skipping testing for the whole package. | 06:43 |
| infinity | (Which is what force-badtest would do) | 06:43 |
| pitti | now, let's see whether it actually works | 06:43 |
| pitti | argh, and of course it fails | 06:56 |
| alkisg | I found a bug in Trusty, does someone know about e.g. ssh client changes that might have triggered it? The following work from a 12.04 client but not from a 14.04 client: | 06:59 |
| alkisg | tty1# ssh -MS /tmp/socket user@server [OK] | 06:59 |
| alkisg | tty2# ssh -S /tmp/socket user@server ls [Control socket connect(/tmp/socket): Connection refused] | 06:59 |
| alkisg | And another thing that worked in 12.04 but not in Trusty: | 07:20 |
| alkisg | # iptables -t nat -D POSTROUTING -s 192.168.67.0/24 -j MASQUERADE | 07:20 |
| alkisg | iptables: No chain/target/match by that name. | 07:20 |
| pitti | infinity: ok, adequate tests fixed | 07:35 |
| alkisg | OK changing "-D POSTROUTING" to "-A POSTROUTING" made the iptables command work, | 07:39 |
| alkisg | so only the ssh socket problem remains, which btw breaks LTSP logins... :( | 07:39 |
| tjaalton | is there an image to use on a pandaboard anymore? | 07:41 |
| tjaalton | guess 13.04 is the la(te)st | 07:44 |
| sarnold | tjaalton: I believe the intention is that the generic armhf kernel ought to work well enough on pandaboard so that no device-specific thing is needed | 07:48 |
| tjaalton | ahh | 07:48 |
| tjaalton | indeed | 07:48 |
| xnox | / headless / that is | 07:50 |
| sarnold | they can have a head? :) | 07:52 |
| sarnold | (actuall i was mighty impressed with our 12.04 LTS install experience on the panda, it was much snappier than I expected) | 07:52 |
| sarnold | xnox: thanks for the warning. :) | 07:52 |
| pitti | infinity: there are a couple of postgresql extensions which don't work with 9.3 any more, and they seem to be pretty dead upstream (orafce, pljava); bugs are filed in Debian; I'd like to remove them from trusty without blacklisting, so that they'll get synced back once they are ported; does that sound ok? | 07:54 |
| * pitti is doing the final steps for the 9.1 -> 9.3 transition for trusty | 07:55 | |
| xnox | pitti: yeap, it's called "demote to proposed" there is a script in archive tools to do that. | 07:55 |
| xnox | pitti: this way the source & binaries are available in proposed and are carried over & never released. | 07:56 |
| pitti | xnox: hah, thanks | 07:56 |
| xnox | pitti: yet will come back via debian. It's equivalent of "remove from testing, keep in unstable". | 07:56 |
| xnox | pitti: do note, that you may need to block with a bug and/or release hint, if britney just would migrate it straight back. | 07:57 |
| pitti | $ demote-to-proposed -m "does not work with PostgreSQL 9.3, Debian #731515" orafce | 07:57 |
| ubottu | Debian bug 731515 in orafce "orafce: Please build postgresql-9.3 extension only" [Important,Open] http://bugs.debian.org/731515 | 07:57 |
| xnox | as long as it's not installable, looks good =) | 07:58 |
| xnox | do note I'm not AA / ReleaseTeam =) | 07:58 |
| pitti | xnox: it's FTBFS, but I guess that wouldn't stop britney | 07:58 |
| pitti | it would become uninstallable once postgresql-9.1 propagates | 07:58 |
| pitti | but it can only do that once I removed orafce and friends from trusty | 07:58 |
| pitti | so, blocker bug it is | 07:58 |
| xnox | import-bug-from-debian 731515 and tag "block-proposed" | 07:58 |
| ubottu | Debian bug 731515 in orafce "orafce: Please build postgresql-9.3 extension only" [Important,Open] http://bugs.debian.org/731515 | 07:58 |
| xnox | yeap =) | 07:58 |
| pitti | I guesss I can just take 1260718 | 07:59 |
| pitti | bug 1260718 | 07:59 |
| ubottu | bug 1260718 in repmgr (Ubuntu Trusty) "Move to postgresql-9.3" [Undecided,Confirmed] https://launchpad.net/bugs/1260718 | 07:59 |
| xnox | =) | 07:59 |
| pitti | https://launchpad.net/ubuntu/+source/orafce/+publishinghistory | 08:01 |
| pitti | so it's deleted from trusty, but not added to trusty-proposed? | 08:01 |
| pitti | Rejected: | 08:05 |
| pitti | orafce 3.0.4-1 in trusty (binaries conflicting with the existing ones) | 08:05 |
| pitti | just got that as mail | 08:05 |
| pitti | well, they'll auto-sync back once they get fixed | 08:05 |
| pitti | worked for repmgr, though | 08:08 |
| === tkamppeter__ is now known as tkamppeter | ||
| alkisg | The problem in ssh sockets seems related to overlayfs, it works fine if I use /run which is tmpfs, but not if I use the LTSP or casper's overlayfs /* | 08:24 |
| sarnold | interesting.. | 08:24 |
| xnox | alkisg: use /run. everything else is not appropriate for sockets. | 08:24 |
| xnox | alkisg: or, if there is support for that, use abstract linux sockets. | 08:24 |
| sarnold | alkisg: I'm surprised the filesystem type matters, once it can support a socket file type anyway.. | 08:25 |
| alkisg | xnox: that goes for users too? so users would create a socket in /run/tmp ? | 08:25 |
| alkisg | (the user $HOME is not appropriate, it can be sshfs or worse) | 08:25 |
| xnox | alkisg: normal users should create sockets in $XDG_RUNTIME_DIR which is guranteed to be set for all user-pam sessions. | 08:25 |
| xnox | alkisg: see the XDG spec. | 08:25 |
| alkisg | Thank you xnon, I'll update the LTSP code accordingly | 08:26 |
| alkisg | *xnox, sorry | 08:26 |
| xnox | (typically XDG_RUNTIME_DIR is "something like tmpfs" and on ubuntu it's /run/user/UID/... or somesuch) | 08:26 |
| alkisg | Hmm it's not set in ssh logins in 12.04 | 08:26 |
| alkisg | OK we'll use some fallback logic | 08:26 |
| alkisg | I think /run/user/UID was implemented after 12.04... | 08:27 |
| xnox | alkisg: the right thing is to check for the var, and otherwise pick something else. again as per XDG spec. | 08:27 |
| alkisg | Cool | 08:27 |
| xnox | alkisg: it was implemented in 12.10 I believe. | 08:27 |
| alkisg | Gotcha, thanks again, /me gets back in his coding dungeon... :) | 08:27 |
| jamesh | sil2100: would you have time to do a packaging review for the new media scanner? | 08:29 |
| sil2100 | jamesh: hello! Sure, new media scanner? A new package? | 08:31 |
| jamesh | sil2100: lp:mediascanner/v2 -- this is a new code base. One new request I've got is to make it parallel installable with the old code base, to make it easier to integrate without breaking all old users | 08:33 |
| doko_ | kees: GCC 4.2, 4.3 and 4.5 on all archs, and ld.gold on arm64 | 09:02 |
| === schmidtm_ is now known as schmidtm | ||
| === doko_ is now known as doko | ||
| === oSoMoN_ is now known as oSoMoN | ||
| dholbach-- | dpm_: I'm still struggling with my laptop :/ | 09:22 |
| dholbach-- | did anyone else run into a libc6-amd64 surprise on an upgrade today? | 09:23 |
| jamesh | sil2100: for the parallel install issue in mediascanner, I think I've got the libraries/headers sorted out. I was wondering if there is any guidelines for the package naming. With some pointers, I might be able to get some of those issues out of the way. | 09:24 |
| sil2100 | jamesh: let me take a look a those after the meeting | 09:29 |
| jamesh | okay | 09:30 |
| xnox | jamesh: boost, tcl, tk, python, db, are all co-installable multiple versions of the same library (most of them, most of the time) | 09:31 |
| xnox | jamesh: we do try to minimise the amount of versions. In practice it's only runtime libraries that are needed to be co-installble. The -dev packages may conflict with each other, simply because one does clean builds in chroots one at a time anyway. | 09:32 |
| xnox | jamesh: but some do offer co-installation of -dev packages as well. e.g. qt4 and qt5, gtk2 and gtk3 (althought they are significantly different to warrant that) | 09:33 |
| jamesh | xnox: well, I made the headers and pkg-config files co-installable, simply because the old implementation had done half the work already (putting headers in a sub directory, version number in pkg-config file, etc) | 09:33 |
| xnox | =) fair enough ;-) | 09:34 |
| dpm_ | dholbach__, argh, good luck :/ | 09:35 |
| dholbach__ | dpm_: https://wiki.ubuntu.com/Touch/Emulator → 'if you are on amd64' | 09:35 |
| dholbach__ | dpm_: that's what has got me again | 09:36 |
| dholbach__ | bbiab | 09:36 |
| dpm_ | dholbach__, ah, so it's not actually fixed? | 09:36 |
| dholbach__ | dpm_: I had an upgrade of libc today which got me into a "/bin/ls: not found" situation again | 09:37 |
| dholbach__ | so I guess that's the case - I'm online from a live session right now | 09:37 |
| dpm_ | :( | 09:38 |
| dholbach__ | brb | 09:40 |
| doko | jamespage, infinity: i386 now runs openjdk zero. munin given back | 09:58 |
| rbasak | stgraber: fyi, bug 1261088. It looks like a minor though valid point to me. | 10:13 |
| ubottu | bug 1261088 in openvpn (Ubuntu) "init.d script: rm of $NAME.status file uses incorrect pathname" [Undecided,New] https://launchpad.net/bugs/1261088 | 10:13 |
| rbasak | I presume there's a /var/run -> /run symlink on every Trusty system? | 10:14 |
| jamespage | doko, great - thanks! | 10:19 |
| dholbach | can anyone help me with a libc6 upgrade problem? I'm seeing http://paste.ubuntu.com/6593456/ because of what I believe to be the aftermath of https://wiki.ubuntu.com/Touch/Emulator (the '/!\ If you are on amd64' bit) | 10:20 |
| randomcpp | dholbach, ping | 10:27 |
| alkisg | gnome-panel in 12.04, 14.04 etc has a race condition and many times it won't load correctly, especially on slow /home (e.g. sshfs). | 10:30 |
| alkisg | By creating a wrapper that only does this: "/usr/bin/gnome-panel &", it works fine (!), while if I omit the last "&", it still has the problem | 10:30 |
| alkisg | ...but I can't imagine what could be to blame there, and how a simple "&" fixes it... any idea? | 10:31 |
| randomcpp | dholbach, ping | 10:39 |
| dholbach | randomcpp, pong | 10:39 |
| dholbach | randomcpp, I'm in the middle of fixing a broken libc installation on my main system, so I'm a bit preoccupied - it might be better if you send me an email so I can get back to you later; or if anybody else can probably help, just ask in here | 10:41 |
| xnox | rbasak: yes, but things should start using /run by default. | 10:41 |
| randomcpp | dholbach, I heard you had an issue while updating libc6 on amd64, I just had one, now my system is completely broken (it hangs with a kernel panic while booting). How have you solved? (here's the apt log http://paste.ubuntu.com/6593483/ ) | 10:41 |
| dholbach | randomcpp, no, not fully solved yet | 10:41 |
| dholbach | randomcpp, check out https://wiki.ubuntu.com/Touch/Emulator (the '/!\ If you are on amd64' bit) | 10:42 |
| dholbach | I got my system to boot again, but I'm stuck in between libc versions right now | 10:42 |
| randomcpp | I have touch emulator installed, but I've never removed it | 10:42 |
| xnox | dholbach: there is a simple command that one can run to recover. let try to find where it was. | 10:42 |
| dholbach | yeah, it doesn't matter - it's more about having had the broken version of it installed early on | 10:42 |
| randomcpp | and I have both amd64 and 32bit version of libc installed | 10:42 |
| xnox | dholbach: ld.so is actually directly executable and using it direct one can fix the system. | 10:42 |
| xnox | randomcpp: that is ok, as long as it's libc6:amd64 and libc6-i386, not the other way around =/ | 10:43 |
| randomcpp | dholbach, how did you get the system boot again? mine can't load /bin/init at the moment :/ | 10:45 |
| rbasak | xnox, stgraber: right, so it does look like a merge error but a minor one. | 10:46 |
| dholbach | randomcpp, with a ubuntu live session on a usb stick | 10:47 |
| dholbach | randomcpp, did you try the instructions on the wiki page? | 10:47 |
| randomcpp | I'm going to try now, brb | 10:48 |
| xnox | infinity: ^ do you remember the ld.so way of fixing the broken symlink form like initramfs break-bottom to recover the libc6 removal resulting in broken ld.so ? | 10:48 |
| dholbach | brb | 10:51 |
| infinity | xnox: /lib/x86_64-linux-gnu/ld-2.18.so /bin/ln -s /lib/x86_64-linux-gnu/ld-2.18.so /lib64/ld-linux-x86-64.so.2 | 10:55 |
| infinity | xnox: Adjust paths to taste if doing it from an initramfs mount. | 10:56 |
| xnox | infinity: thanks, darn both affected people gone | 10:59 |
| infinity | xnox: It helps if you think of ELF executables as "ld.so scripts", so the same way you'd invoke "/bin/sh foo.sh" or "/usr/bin/python foo.py", you can do with ELF binaries. | 11:04 |
| infinity | xnox: And, indeed, that's exactly what the kernel does. | 11:05 |
| xnox | infinity: right, thanks. that is indeed a good framework =) | 11:05 |
| infinity | (Parses the PI out of the header, the same way it parses your interpreted from a shebang) | 11:05 |
| infinity | interpreter* | 11:05 |
| * xnox Inception - the IT crowd edition | 11:06 | |
| jamesh | sil2100/xnox: I've made the parallel install changes for mediascanner/v2 here: https://code.launchpad.net/~jamesh/mediascanner/parallel-install/+merge/199440 -- I'm still interested in a general packaging review though. | 11:06 |
| xnox | doko: is openjdk-6 will be fixed in a similar fashion openjdk-7, after eglibc-2.18 breakage? | 11:11 |
| xnox | fashion as openjdk-7? | 11:12 |
| doko | I fashon removal | 11:12 |
| caribou | could dholbach's libc6 issue be tied to the most recent server .iso image not being able to install ? | 11:13 |
| caribou | I'm getting "Loading libc6-udeb failed for unknown reason" when trying to install Trusty from the latest server image | 11:13 |
| xnox | doko: ack. I fashion excuse to make android build not depend on java at all (the android system images that is) | 11:17 |
| xnox | infinity: doko: thanks for making this critical ;-) | 11:17 |
| infinity | xnox: The bug was always there, AFAICT, it just seemed to surface randomly before, and now more consistently with glibc 2.18. :/ | 11:18 |
| infinity | xnox: I need to find some time to see if I can sort out what openjdk is doing wrong. | 11:18 |
| infinity | (At least, googling for it brings up a lot of very similar backtraces going back many years) | 11:18 |
| xnox | infinity: meh, i'll just make sure java is not on the critical path for ubuntu-touch =) | 11:18 |
| doko | infinity, xnox: no, it wasn't seen on i386. and the amd64 issues were only seen with downloaded code not found in the distribution | 11:20 |
| stgraber | rbasak: oh, thanks for openvpn. I'll make a note to fix that on Thursday | 11:26 |
| xnox | stgraber: re: goldfish vs generic. The device name is generic, and that's what used in initramfs / udev rules et al. Can the device be named generic on the system-image side as well? | 11:33 |
| xnox | stgraber: or is there something named inconsistent somewhere, and hence "goldfish" was picked up on the system-image side of things? | 11:34 |
| stgraber | xnox: cdimage.u.c says goldfish | 11:34 |
| xnox | ogra_: ! it's generic, not goldfish. | 11:36 |
| xnox | stgraber: that needs changing =) | 11:36 |
| ogra_ | xnox, it isnt for the images | 11:36 |
| ogra_ | only for the device | 11:36 |
| xnox | ogra_: it should match the getprop name, otherwise a few things break and for the sake of consistency. | 11:36 |
| xnox | ogra_: the device name is generic. | 11:37 |
| xnox | ogra_: both in Cyonogenmod, AOSP and everywhere =) | 11:37 |
| stgraber | xnox: if you want to change the name to generic, we'll need to coordinate the landing as both need to change at the same time and I need to do some hacks to transition any from goldfish to generic | 11:37 |
| stgraber | (as in, not today since I'm off ;)) | 11:37 |
| === alkisg is now known as work_alkisg | ||
| ogra_ | xnox, well, i belive rsalveti introduced that naming because the build target in CM and AOSP is called goldfish | 11:37 |
| xnox | stgraber: well there are none that use goldfish at the moment. | 11:37 |
| stgraber | (and jetlagged, and have an headache, ... really, just on IRC because I'm waiting for a train and don't have much else to do ;)) | 11:37 |
| xnox | ogra_: custom product in CM is called goldfish, to do separate config. in AOSP it's called "full" | 11:38 |
| ogra_ | xnox, the build uses goldfish | 11:38 |
| ogra_ | the output of the android build is called golfish in the zip name | 11:38 |
| xnox | ogra_: actual generated images by "goldfish-cm" product are "generic" and the device name is generic. | 11:38 |
| ogra_ | xnox, the output in the anbdroid package disagrees | 11:38 |
| xnox | ogra_: and? getprop device name is generic, and that's what we go by in system-image cli utility, initramfs hooks, udev rules..... | 11:39 |
| ogra_ | (happy to help solving that after my vacation if it actually needs solving) | 11:39 |
| ogra_ | yes | 11:39 |
| xnox | ogra_: yeah, it needs solving system-image updates are broken for emulator at the moment =) | 11:39 |
| ogra_ | we do the same for other arches too ... :) | 11:39 |
| xnox | ogra_: enjoy your vacation =) | 11:39 |
| ogra_ | their build name also differs from the image name sometimes ;) | 11:39 |
| * ogra_ doesnt mind how we call it, as long as we can later make it arch distinct (generic-x86 vs generic-armhf or some such) so we can have emulators for different arches identified in the image names | 11:41 | |
| ogra_ | (i didnt pick goldfish :) ) | 11:42 |
| xnox | ack. | 11:42 |
| rsalveti | xnox: let's fix that once we switch to 4.4 | 11:42 |
| dholbach | xnox, did you find the magic command somewhere? O:-) | 11:42 |
| rsalveti | which should happen soon | 11:43 |
| xnox | dholbach: I did, added to the wiki page. | 11:43 |
| dholbach | thanks! | 11:43 |
| rsalveti | as the naming might change again anyway | 11:43 |
| xnox | dholbach: it can be run from e.g. just broken machine whilst it's still running | 11:43 |
| xnox | dholbach: or by booting with "break=bottom" on cmdline without actually needing to boot a live-cd for example. | 11:43 |
| xnox | dholbach: it's just when booted with "break=bottom" the rootfs is mounted elsewhere, check output from $ mount | 11:44 |
| xnox | rsalveti: hm =/ well system-image server is blocking system-image updates on the emulator for barry. | 11:44 |
| xnox | rsalveti: stgraber: any way to alias "generic" to "goldfish" on the system-image.ubuntu.com for the time being? | 11:44 |
| stgraber | xnox: nope, we can alias channels, not devices | 11:45 |
| xnox | ack. | 11:45 |
| stgraber | xnox: but I could do some ugly hacks if needed, I just don't think it's that urgent | 11:46 |
| ogra_ | right, that wuld have to happen inside system-image client side i guess | 11:46 |
| xnox | rsalveti: i'd rather change goldfish -> generic sooner than later. not many people are using it at the moment. | 11:46 |
| stgraber | and as ogra_ said, we probably want that named generic-armhf instead | 11:46 |
| xnox | stgraber: that will break a lot of things. | 11:46 |
| stgraber | xnox: well, better break them when we don't have any user than wait until someone asks for generic-amd64 and we have to start renaming stuff | 11:47 |
| xnox | stgraber: i'll check the x86 device name, i think it goes by generic for armhf, generic-mipse/-x86 for the others. | 11:47 |
| ogra_ | xnox, not if the build already calls it like that (so that getprop returns the arch name too) | 11:47 |
| xnox | if the are already i386 & mipsel names sure. if all of them are generic, then we do need to rename all of them. | 11:47 |
| * xnox please hold, your call is important to us. We will be back with you shortly. | 11:47 | |
| * ogra_ thinks generic-arm64 is more realistic than generic-amd64 ;) | 11:48 | |
| xnox | well we have workitems to build generic-x86 (as in i386/atom) images this cycle. | 11:48 |
| ogra_ | yeah | 11:48 |
| ogra_ | thats why i poked at the disctinct naming above :) | 11:48 |
| doko | xnox, gccxml still in main? | 11:48 |
| xnox | doko: yes, didn't merge latest boost yet. will do it soon. Actually i think i can do it now / today. | 11:50 |
| xnox | rsalveti: stgraber: are recovery OTA keys used at all? that's the only reason java is pulled into the android build. | 11:52 |
| stgraber | xnox: I don | 11:55 |
| stgraber | don't think so | 11:55 |
| stgraber | our OTA updates use standard gpg | 11:55 |
| ogra_ | xnox, java used to be needed for the zip creation of the android side ... unrelated to ubuntu and i belive sergio actually patched out the need for it completely (i might mis-remember thoough) | 11:57 |
| xnox | ogra_: yeah, it is optional. but at the moment the java tools are part of the build targets, and thus are pointlessly compiled each time. | 11:58 |
| ogra_ | i thought that was ripped out ... weird | 11:58 |
| ogra_ | (or did goldfish bring it back) | 11:59 |
| dholbach | xnox, because I was in the middle of the libc upgrade, I had to repoint a bunch of symlinks to the 2.17 version, then manually installed the libc* packages again and right now it looks like it all might work out, at least 'dpkg --configure -a' was happy again | 12:00 |
| dholbach | just saying... in case I drop off again and randomcpp needs another suggestion :) | 12:00 |
| xnox | dholbach: if anything runs, than you are good to go =) | 12:00 |
| xnox | s/than/then/ | 12:01 |
| xnox | without ld.so, nothing runs =) | 12:01 |
| dholbach | I was at the point a couple of times before, but the upgrade would complain about *2.18*.so files lying around | 12:01 |
| dholbach | but anyway, let's see how this goes now | 12:01 |
| === dpm_ is now known as dpm | ||
| === dholbach_ is now known as dholbach | ||
| dholbach | xnox, thanks again for the help | 12:11 |
| dholbach | seems like I'm all set | 12:11 |
| xnox | Laney: pull-debian-source appears to be pulling from testing, instead of unstable. Have you noticed this? | 12:11 |
| xnox | Laney: even with specifying "sid" | 12:11 |
| xnox | had to pass explicit version number =/ | 12:12 |
| Laney | no | 12:12 |
| Laney | give me a package name | 12:12 |
| Laney | laney@iota> pull-debian-source ghc ~/temp | 12:14 |
| Laney | pull-debian-source: Downloading ghc version 7.6.3-6 | 12:14 |
| xnox | Laney: boost1.54 | 12:20 |
| Laney | it's because rmadison is out of date | 12:22 |
| Laney | rmadison -u debian -a source -s sid boost1.54 | 12:22 |
| xnox | ah, thanks. | 12:27 |
| xnox | applies not my problem field | 12:28 |
| rsalveti | xnox: no, you can remove the ota keys | 12:52 |
| rsalveti | xnox: sorry, what is currently blocked in the system-image server side? | 12:53 |
| rsalveti | not sure if I understood correctly what is the issue with the wrong device name in there | 12:53 |
| rsalveti | and we can fix the device name now as well, but I'm currently rebasing our patches for 4.4 | 12:54 |
| rsalveti | and that will change anyway | 12:54 |
| xnox | rsalveti: system-image cli does getprop device name and gets "generic", it then talks to https://system-image.ubuntu.com/devel/ and gets 404 since there is no "generic" device, only "goldfish" | 12:54 |
| rsalveti | we'd also need a different name for the x86 version, like goldfish_x86 or similar | 12:54 |
| xnox | impedance missmatch =) | 12:54 |
| rsalveti | right, but system-image updates is not supported in the emulator right now anyway | 12:54 |
| xnox | rsalveti: that's what I need to check. if the names are different between armhf, x86 and mipsel. than we can use them. | 12:55 |
| xnox | rsalveti: sure, but barry is blocked at enabling that =) | 12:55 |
| rsalveti | well, we first need to fix our image to avoid any custom stuff on top of it | 12:55 |
| xnox | rsalveti: and there is emulator.... and there are image updates on the server.... | 12:55 |
| rsalveti | so it can boot in ro mode | 12:55 |
| rsalveti | if you really want it to be updated with the default method | 12:55 |
| xnox | sure, sure. =) one can system-image update a rw image as well, via command line ;-) | 12:55 |
| xnox | which is a good way to enable it. | 12:56 |
| xnox | if it's "generic" across all arches, then we need to customize them indeed. | 12:56 |
| rsalveti | hm, right, but that will not necessarily work for most of the times | 12:56 |
| xnox | rsalveti: so no changes are needed on the android side. | 12:56 |
| rsalveti | well, I think goldfish is a CM specific codename | 12:56 |
| xnox | rsalveti: it's the syste-image.ubuntu.com website that should be publishing "generic" device name instead of "goldfish" at the moment. as that seems to be the odd one out. | 12:56 |
| rsalveti | then we have generic, generic_x86 and generic_mips | 12:57 |
| rsalveti | we'd need to either use generic for everything, or replace generic with goldfish | 12:57 |
| xnox | rsalveti: yeap. same conclusion here as well. it's "full" targets and "generic" device name in AOSP and (non-working) in CM. | 12:57 |
| rsalveti | and have goldfish, goldfish_x86, etc | 12:57 |
| xnox | well, there are more things that use generic already. | 12:57 |
| xnox | although arguably goldfish is a fancier codename than boring "generic" | 12:58 |
| xnox | or emulator, as adb devices reports it =) | 12:58 |
| rsalveti | right | 12:58 |
| rsalveti | would indeed be nice to have only one codename across all tools | 12:58 |
| === Sweetsha1k is now known as Sweetshark | ||
| dholbach | @pilot in | 13:49 |
| === udevbot changed the topic of #ubuntu-devel to: Ubuntu 13.10 released! | Archive: open | Devel of Ubuntu (not support or app devel) | build failures -> http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of lucid -> saucy | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: dholbach | ||
| happyaron | dholbach: have time to sponsor this package? https://bugs.launchpad.net/ubuntu/+bug/1261825 | 13:54 |
| ubottu | Ubuntu bug 1261825 in Ubuntu "Please sponsor fcitx-qimpanel-configtool/0.1.3-0ubuntu1" [Undecided,New] | 13:54 |
| dholbach | happyaron, I'll add it to my list | 13:55 |
| happyaron | great, thanks | 13:56 |
| xnox | happyaron: do subscribed ubuntu-sponsors to the sponsorship request bug report as per https://wiki.ubuntu.com/SponsorshipProcess that way it would appear on the queue to be sponsored. Otherwise they do not. | 14:08 |
| xnox | happyaron: it's faster if it's in the queue. | 14:08 |
| dholbach | zyga, is anyone looking at https://bugs.launchpad.net/ubuntu/+bug/1254831? | 14:23 |
| ubottu | Ubuntu bug 1254831 in Ubuntu "plainbox needs packaging" [Undecided,New] | 14:23 |
| zyga | dholbach: it's on my todo list today | 14:26 |
| dholbach | zyga, ok cool | 14:26 |
| zyga | dholbach: just doing some more code reviews and I'll get right to it | 14:26 |
| dholbach | super, thanks | 14:27 |
| dholbach | just looked at it because I'm patch piloting today | 14:27 |
| === brandon is now known as Guest67170 | ||
| === freeflying is now known as freeflying_away | ||
| barry | xnox, rsalveti: i like goldfish because it kind of fits in with the naming scheme :) but whatever. system-image ultimately doesn't care, as long as the device and system-image.ubuntu.com are in agreement (and the latter requires stgraber) | 14:59 |
| dholbach | @pilot out | 14:59 |
| === udevbot changed the topic of #ubuntu-devel to: Ubuntu 13.10 released! | Archive: open | Devel of Ubuntu (not support or app devel) | build failures -> http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of lucid -> saucy | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: | ||
| xnox | barry: i had no idea, it's so long, and thanks for all the fish ;-) naming theme. | 15:01 |
| barry | :) | 15:01 |
| Laney | xnox: I poked UDD and rmadison is now right (for now) | 15:03 |
| xnox | Laney: you can poke _debian_ madison?! *_* | 15:03 |
| Laney | yeah I have uddadm | 15:04 |
| xnox | Laney: I see ;-) noted | 15:05 |
| Laney | oh no, you go ahead and forget that now :P | 15:05 |
| xnox | Laney: there is no lastic that can erase permament ink biro inscriptions in my Ubuntu Orange notebook =) | 15:06 |
| Laney | hoho | 15:08 |
| Laney | anyone got an example of creating a locale in a package build? | 15:08 |
| Laney | is the script gcc uses best practice for that? | 15:08 |
| xnox | i wouldn't call gcc packaging to be best practices of anything =))))))) | 15:08 |
| xnox | didn't bzr do locale tests or some such? | 15:09 |
| Laney | hmm, not seeing it | 15:15 |
| === Wubix_ is now known as Wubix | ||
| infinity | Laney: The easiest way to get a locale in a package build is to build-dep on the language-pack for the locale you want. | 15:40 |
| Laney | infinity: I'd like it to be Debianable | 15:40 |
| infinity | Laney: build-dep on "locales-all | language-pack-en" | 15:41 |
| Laney | I'm calling localedef myself now, will see if it works | 15:41 |
| infinity | Laney: locales-all is all locales in Debian. And we'll have it soon too, when I change our packaging. | 15:41 |
| pitti | localedef needs the /usr/share/i18n/ data, though | 15:41 |
| pitti | so you can b-dep on "locales" and call localedef yourself, yes | 15:42 |
| Laney | yeah, from locales | 15:42 |
| pitti | and set LOCPATH | 15:42 |
| Laney | yep, that's the recipe | 15:42 |
| infinity | Or, you can just build it yourself and set the path, sure. :P | 15:42 |
| infinity | But the build-dep on locale-all seems less hackish. | 15:42 |
| infinity | And less code. :P | 15:42 |
| pitti | Laney: http://bazaar.launchpad.net/~ubuntu-branches/ubuntu/trusty/langpack-locales/trusty/view/head:/debian/local/test-locales | 15:42 |
| Laney | is there a reason that locale-gen doesn't output in LOCPATH? | 15:42 |
| pitti | Laney: well, it does, but you can't do that during package build (write to /usr/lib/, I mean) | 15:43 |
| infinity | pitti: Hence the build-dep suggestion. | 15:43 |
| infinity | (Which seems to have fallen on deaf ears) | 15:43 |
| pitti | yes, locale-all, but we don't have that just yet | 15:43 |
| pitti | or do we? | 15:43 |
| infinity | pitti: Yeah, but "locales-all | language-pack-langiwant" works. | 15:44 |
| pitti | *nod* | 15:44 |
| infinity | pitti: We'll have locales-all in my next glibc upload, I didn't do it for 2.18, cause I needed to get it done this year. :P | 15:44 |
| Laney | Yeah, that would; I'll do it if this test doesn't work out | 15:44 |
| Laney | I try to avoid alternate build-deps if possible though | 15:44 |
| pitti | won't be for long :) | 15:44 |
| infinity | We can drop a few deltas when I bring in locales-all, so that will be nice. | 15:45 |
| infinity | pitti: Do language-packs unconditionally call locale-gen? | 15:46 |
| pitti | infinity: they call install-language-pack, which then calls locale-gen | 15:46 |
| infinity | pitti: We might want to make that smarter to depend on 'locales | locales-all' and not call locale-gen if it's not on the system. | 15:46 |
| pitti | install-language-pack is a script from langpack-locales, so that we can centrally modify it wihtout having to rebuild a gazillion langpacks | 15:46 |
| infinity | pitti: locales-all doesn't ship it, for obvious reasons. | 15:46 |
| pitti | infinity: oh, does locales-all COnflicts:/Replaces: locales? I thought the two would go on top of each other | 15:47 |
| infinity | pitti: There's no conflict, but also no dependency, and no need to call locale-gen if locales-all is installed, cause you already have all the locales. | 15:48 |
| pitti | *nod* | 15:48 |
| pitti | so we need to make {install,remove}-language-pack smarter | 15:48 |
| infinity | Actually, it Provides: locales, so no need to change the dependency, just need to detect that the local already exists and not try to call locale-gen. | 15:49 |
| hallyn_ | hi - i'm suffering from a misunderstanding about package installs and upstart jobs. | 15:49 |
| hallyn_ | if a package ships an upstart job, and that upstart job, in pre-start, does {stop; exit 0;}, | 15:49 |
| hallyn_ | i would have thought that would count as 'ok' | 15:49 |
| hallyn_ | but in practice, package install says it fails | 15:50 |
| infinity | hallyn_: I would expect that to be fine. | 15:50 |
| hallyn_ | <4>init: cgroup-lite pre-start process (491) terminated with status 127 | 15:51 |
| hallyn_ | start: Job failed to start | 15:51 |
| infinity | hallyn_: Perhaps the whole job would be more enlightening? | 15:51 |
| hallyn_ | infinity: this is the cgroup-lite package, in precise-proposed. | 15:51 |
| hallyn_ | apparmor can prevent it from mounting the cgroups. In that case I want the upstart job to not be running, so that userspace can easily tell it can't rely on it | 15:51 |
| hallyn_ | but having package install fail because of it seems hard-core | 15:52 |
| hallyn_ | now maybe i'm just wasting time, and i should just have the upstart job succeed... | 15:54 |
| Laney | seems it did work | 15:57 |
| infinity | hallyn_: I can't seem to reproduce this. | 15:57 |
| Laney | thanks for the wisdom infinity and pitti | 15:57 |
| Laney | I'll drop it as soon as we get locales-all | 15:57 |
| infinity | Oh. | 15:59 |
| hallyn_ | infinity: you can't reproduce the failure to install? if so, just 'sudo lxc-create -t ubuntu-cloud -n u1 -- -r precise; sudo lxc-start -n u1; and in that container update to proposed and install cgroup-lite | 15:59 |
| infinity | hallyn_: I can't reproduce it because I don't have /bin/cgroups-umount installed, I bet. | 15:59 |
| hallyn_ | actually just ln -s /bin/false /bin/cgroups-mount and -umount should work to reproduce :) | 16:00 |
| infinity | hallyn_: So, you're calling "stop" if cgroups-mount doesn't work, which then calls cgroups-umount, which also fails to work, and you exit non-zero. | 16:00 |
| hallyn_ | oh. | 16:00 |
| infinity | hallyn_: At least, that's my guess. | 16:00 |
| hallyn_ | that makes sense ;) lemme try | 16:00 |
| hallyn_ | hm, adding '|| true' to umount doesn't change the result of 'start cgrou-lite'. trying fresh install | 16:01 |
| infinity | hallyn_: Yeah, if I take all the "stop"s out of your start clauses it works fine. | 16:02 |
| infinity | hallyn_: In any of those cases, do you actually WANT to try to umount? | 16:02 |
| infinity | hallyn_: If not, then the stops shouldn't be there. | 16:02 |
| alexmuro | If I wanted to start hacking on nautalis file manager where would I find the source code, any ideas? | 16:03 |
| hallyn_ | i see. i thought 'stop' kept it from proceeding to the 'start' state (and only did that) | 16:03 |
| infinity | hallyn_: Nah, exit will take care of making sure it goes nowhere. :P | 16:03 |
| hallyn_ | infinity: though yes, if it failed partway into mounting, i want it all unmounted | 16:03 |
| infinity | hallyn_: Anyhow, || true after the umount also works for me. | 16:03 |
| infinity | hallyn_: Well, my umount is /bin/false, but... | 16:04 |
| hallyn_ | what do you get when you have || true? | 16:04 |
| infinity | Oh, nevermind, upstart thought it was "already running" and wasn't starting it. | 16:05 |
| infinity | There. THis works. | 16:06 |
| infinity | hallyn_: http://paste.ubuntu.com/6594934/ | 16:06 |
| infinity | hallyn_: So, that lets you still try to umount if start blows up somehow. But if that's not likely, just removing the stops is also sane. | 16:07 |
| hallyn_ | ah, i see, 'true' wasn't helpful but exit 0 is | 16:07 |
| hallyn_ | i'll agree it's not likely - but then in theory this case shouldn't have been likely either :) | 16:07 |
| xnox | infinity: hallyn_: "is this a convoluted 'task' " job ? =) | 16:08 |
| hallyn_ | what the heck. infinity: your version looks nicer at 'start cgroup-lite', but still fails pkg install | 16:09 |
| xnox | task + script -> one instance that runs and finishes. | 16:09 |
| xnox | another job "start on shutdown" -> task + script to unmount them. | 16:09 |
| xnox | but upstart doesn't handle shutdown / unmounting. so no need at all actually to unmount things ever. | 16:10 |
| xnox | hallyn_: that job does not make sense on upgrade, nor on install. it should be "dh_installinit --no-restart-on-upgrade --no-start" | 16:11 |
| hallyn_ | xnox: the unmounting isn't being done for at shutdown. it's being done in case you decide you want things mounted a dfferent way (i.e. cgroup-bin, fstab, etc) | 16:11 |
| hallyn_ | xnox: why does it not make sense on install? | 16:11 |
| hallyn_ | if you install cgroup-lite, you want the cgroup fs's installed. 'now' | 16:11 |
| infinity | hallyn_: How is it failing at package install? | 16:12 |
| hallyn_ | infinity: http://paste.ubuntu.com/6594968/ | 16:12 |
| xnox | hallyn_: possibly. I just somehow see it as "to be installed by d-i / installer" and started "on boot". I guess you'd install it and start lxc container and everything should work without prior cgroup-lite. | 16:13 |
| infinity | xnox: No, it's perfectly reasonable for that to start on install. | 16:13 |
| xnox | hallyn_: but in that case, it's definately "--no-restart-on-upgrade" cause you do not want to tear down _existing_ cgroups and mount fresh ones =/ | 16:14 |
| xnox | infinity: ack. | 16:14 |
| hallyn_ | xnox: good point. | 16:14 |
| infinity | hallyn_: That paste just leads me to believe you're not using a new version of the script. :P | 16:14 |
| hallyn_ | xnox: if i wasn't working to make cgroup-lite obsolete, i'd open a bug for that :) | 16:14 |
| xnox | hallyn_: and in the paste you are doing upgrade, not fresh install. | 16:14 |
| hallyn_ | yes. | 16:14 |
| hallyn_ | http://paste.ubuntu.com/6594980/ | 16:15 |
| xnox | hallyn_: also with eat-my-data upstart may not get inotify for the new upstart script, and hence not notice that it should be using the new job.... fyi | 16:15 |
| xnox | hallyn_: so you really shouldn't be testing this on overlayfs, nor under eatmydata ;-) | 16:15 |
| hallyn_ | and the actual script: http://paste.ubuntu.com/6594988/ | 16:15 |
| hallyn_ | xnox: oh, good point.... | 16:15 |
| hallyn_ | xnox: it's not overlayfs, it's btrfs that's making me do this :( | 16:16 |
| xnox | hallyn_: post-strop can just be "/bin/cgroups-umount || exit 0" no? that extra if/fi does add anything does it? | 16:17 |
| hallyn_ | xnox: you rock! | 16:17 |
| hallyn_ | xnox: yeah, now that we do ||, we can drop the if. | 16:17 |
| hallyn_ | and yes, when i force upstart to reread i works. thanks! | 16:17 |
| hallyn_ | infinity: xnox: thanks, will push new version to hopefully be done with this | 16:17 |
| xnox | \o/ | 16:20 |
| hallyn_ | guess i really should upgrade to newer kernel and see if the fsync issue in btrfs is fixed | 16:31 |
| === hholtmann_ is now known as hholtmann | ||
| === superm1_ is now known as superm1 | ||
| arges | cjwatson: hi. I'm working on bug 785394. The default crashkernel parameter doesn't work with default ubuntu installs and needs to be increased. I created a patch here: http://people.canonical.com/~arges/lp785394/fix-lp785394.debdiff before I push, can you review? | 17:01 |
| ubottu | bug 785394 in kexec-tools (Ubuntu) "Hard-coded crashkernel=... memory reservation in /etc/grub.d/10_linux is insufficient" [Medium,In progress] https://launchpad.net/bugs/785394 | 17:01 |
| cjwatson | arges: I don't really know much about that, can't review effectively | 17:04 |
| cjwatson | arges: I split it out from grub2 so I'd never have to look at it again :-) | 17:04 |
| arges | cjwatson: ok, well I just saw you having the last commit that split it out so I'd figured i'd ask you | 17:04 |
| cjwatson | yeah, that was me washing my hands of it ;-) | 17:04 |
| cjwatson | I never got my head around the specific semantics there | 17:05 |
| arges | i spoke with smb, caribou etc, and we've done testing with it already | 17:05 |
| cjwatson | (anyway, I have to run now, I'm afraid) | 17:05 |
| arges | cjwatson: ok thanks | 17:05 |
| hallyn_ | xnox: infinity: well now i'm really confused. on a different host, no overlayfs or btrfs, no eatmydata. i add-apt-repository ppa:serge-hallyn/virt which has my new package. install cgroup-lite, it fails. remove cgroup-lite, rm /etc/init/cgroup-lite.conf; install cgroup-lite, it succeeds. | 17:17 |
| hallyn_ | there is no /etc/init/cgroup-lite.conf before i first install cgroup-lite | 17:17 |
| * hallyn_ confused | 17:17 | |
| hallyn_ | oh. haha. | 17:17 |
| hallyn_ | the install did not reinstall the upstart job | 17:17 |
| hallyn_ | ok i guess i just have to not do 'stop' on pre-start failure | 17:18 |
| xnox | hallyn_: before doing clean install, do $ apt-get remove --purge cgroup-lite. such that package is removed, and the upstart job is removed. | 17:26 |
| xnox | hallyn_: and do check that it's stopped / unmounted. | 17:26 |
| xnox | hallyn_: $ sudo status cgroup-lite should return error unknown job. | 17:27 |
| hallyn_ | xnox: it was a brand new container. there was no cgroup-lite installed | 17:27 |
| xnox | ack. | 17:27 |
| hallyn_ | xnox: i've decided this is madness. i'm going to properly sru the changes from trusty instead. | 17:27 |
| xnox | hallyn_: still, i don't understand why this is a "long running daemon", when there is no daemon. | 17:28 |
| xnox | hallyn_: this should be "task" job, which only mounts the filesystems. | 17:28 |
| xnox | hallyn_: one shouldn't want to unmount them, if one does want that a separate job could be provided to unmount. | 17:28 |
| xnox | hallyn_: the semantics of the "task" job are quite different. It starts, starting is emitted, it runs, finishes and stops. At the end "started" is emitted, or it goes to fail "stop/waiting" state. | 17:29 |
| xnox | thus it's never reaches "start/running", which should only be needed if there is a daemon to monitor. | 17:30 |
| xnox | hallyn_: how does the job look like in trusty? | 17:31 |
| hallyn_ | xnox: bc this way you can tell if cgroup-lite is running | 17:31 |
| hallyn_ | if it was a task, then you couldn't tell at some random time if it's running. you'd have to check the mountpoints themselves... | 17:31 |
| xnox | hallyn_: it only tells you that at one point in the past cgoup-lite did run. which you can also tell for a task job with "status cgroup-lite 2>/dev/null" | 17:31 |
| hallyn_ | in trusty, /bin/cgroups-mount is a bit different. | 17:31 |
| xnox | hallyn_: one could have unmounted those filesystems, after cgroup-lite finished. and you have non-deterministic expectations. | 17:32 |
| hallyn_ | oh? hm. but really i'm sure i followed an example from the cookbook when i did this... years ago... | 17:32 |
| hallyn_ | sounds like a task may ahve been better, but again i'm hoping cgroup-lite is basically gone in trusty | 17:32 |
| hallyn_ | (in the archive, but obsolete) | 17:32 |
| xnox | hallyn_: that's how things should check for other things. If I want to be sensitive to the other job, I do "status foo" to check that foo is available. And then if I require a particular state of foo, I can also check for that or wait for it to reach a particular state. | 17:33 |
| xnox | given that "cgrou-lite" will be run-once on installation or on boot, "status cgroup-lite" with any status infromation text in stdout deterministically indicates that this did happen. | 17:34 |
| xnox | if there is non-zero return code, or stderr output, then it's not there or otherwise failed (e.g. connection to upstart or status information denied for some reason) | 17:36 |
| xnox | actually, yeah just zero / non-zero return code from "status cgroups-lite" is sufficient. | 17:36 |
| hallyn_ | xnox: http://upstart.ubuntu.com/cookbook/ '4.1.1.3 abstract jobs' is what i guess i was going after | 17:38 |
| hallyn_ | xnox: i disagree that a separate upstart job should exist to umount the filesystems. | 17:39 |
| hallyn_ | it's a nice clean symmetry. start mounts, stop umounts. why would i 'start umount-cgroups' to umount them? | 17:39 |
| xnox | hallyn_: well, since there is no "stop on" it really is better suited to be a 4.1.1.1 Task job. | 17:40 |
| hallyn_ | note that it being a task wouldn't have solved this bug. so i see no advantage to it being a task rather than abstract job | 17:40 |
| hallyn_ | xnox: i manually stop it very frequently | 17:40 |
| xnox | hallyn_: you can do e.g. start cgroups UNMOUNT=TRUE | 17:40 |
| hallyn_ | stop cgroups is shorter :) | 17:41 |
| hallyn_ | xnox: what is the advantage to it being a task? | 17:41 |
| xnox | hallyn_: the problem however, is that "$ restart cgroups" will not unmount and mount them afresh as post-stop is not executed. | 17:41 |
| xnox | hallyn_: also "$ reload cgroups" does nothing. | 17:42 |
| hallyn_ | xnox: bah, same shortcoming with libvirtbint | 17:42 |
| hallyn_ | libvirt-bin | 17:42 |
| hallyn_ | i call that an upstart shortcoming | 17:42 |
| xnox | (send "reload signal" to the main process group, of which there are none) | 17:42 |
| xnox | hallyn_: i call it, you ain't got a daemon to restart nor to reload, though you shall be a task =) | 17:42 |
| xnox | hallyn_: also "tasks" are always blocking. | 17:43 |
| hallyn_ | what does that mean? | 17:43 |
| hallyn_ | maybe post-stop in cgroup-lite should ahve been pre-stop | 17:43 |
| xnox | hallyn_: is there any time, when you want to start on "starting cgroups" and prevent or block cgroups from mounting? if all of your clients use "start on started cgroups" that's also a strong indication that "a task" job is better suited for you. | 17:43 |
| xnox | hallyn_: and if for any reason pre-stop hangs, you'll never stop nor reload =/ that is actually upstart bug =) and quite tricky. because again, somebody else can block/prevent cgroups job from doing that by having "start on stopping cgroups" | 17:44 |
| xnox | and then your manual "$ stop cgroups" from command line does _not_ unmount them. | 17:44 |
| hallyn_ | so 'start on started cgroup's, with a task, would wait until it is done, and with abstract job, does not? | 17:44 |
| xnox | .... hm. it should with either. | 17:45 |
| hallyn_ | though since cgroup-lite does its work in pre-start, that's moot | 17:45 |
| === Zic is now known as Guest7180 | ||
| rbasak | Is there Debian policy that says that packages that provide daemons should start them? Or is it up to each individual maintainer? | 17:46 |
| xnox | hallyn_: there was events sequence for task vs normal jobs. i think i should find it. | 17:46 |
| rbasak | (I thought it was expected that daemons would be running after a package is installed, but could be controlled by policy-rc.d, but I can't find anything in policy) | 17:46 |
| xnox | but i'm close to eod and need to run soon. | 17:46 |
| xnox | rbasak: if and only if there is a sensible default configuration for a daemon. if for example must answer debconf question, and one is running non-interractive ui, the package settings are not configure and the daemon shouldn't be started. | 17:47 |
| xnox | rbasak: there is a whole sections on init scripts / systems. | 17:48 |
| xnox | hallyn_: abastract jobs are meant only as "synchronisation" points, or boot/shutdown barriers. | 17:48 |
| rbasak | xnox: is there anything I can cite? nginx appears to not start intentionally, but I can't find anything relevant in policy. | 17:49 |
| xnox | hallyn_: they do not convey state. | 17:49 |
| rbasak | xnox: policy talks about invoke-rc.d, so *how* maintainer scripts should start daemons, but I can find nothing that says that they *should* start them. | 17:49 |
| hallyn_ | xnox: but they do convey state. | 17:51 |
| hallyn_ | xnox: in any case, if i were starting it fresh now i'd follow your advice... | 17:51 |
| xnox | rbasak: hm, can't find it quickly. maybe cjwatson can provide better policy reference. | 17:51 |
| === debfx_ is now known as debfx | ||
| hallyn_ | xnox: but for precise i don't think i can change that :) | 17:51 |
| === alexlist` is now known as alexlist | ||
| hallyn_ | ok let's hope my third version works | 17:52 |
| xnox | hallyn_: there is little to know support for state, e.g. there is no reliable way to convey "run while (cgroups and networking IFACE!=lo)" and stop me if those conditions become false, and start me up again when that is true. since e.g. cgroups event fires, then networking event fires, and you are started. | 17:53 |
| xnox | hallyn_: subsequently network goes down, you are stopped, network comes back up, networking event is fired, yet the job is still stuck in waiting state - waiting for the new "cgroups" events which will never arrive (cgroups never went down) | 17:54 |
| xnox | thus as soon as one tries to do any "complex", as in one "and" conditions state information is not available. events are one-time only.... events. | 17:55 |
| === Guest7180 is now known as Zic | ||
| hallyn_ | xnox: i don't believe what you are sayin gis possible with tasks either. that's what bugs a few years ago were opened about iirc... | 17:56 |
| hallyn_ | xnox: but with cgmanager, you'll have a real daemon to check :) | 17:57 |
| hallyn_ | if i can get past this stuff and get back to cgmanage, that is | 17:57 |
| xnox | hallyn_: correct, it's not possible with tasks either. but look at this case: $ sudo start cgroups; sudo umount /cgroups; sudo start cgroups | 18:01 |
| hallyn_ | xnox: tha'ts ok, /cgroups is not related :) | 18:01 |
| xnox | hallyn_: with a task it will be mounted afresh, since none are currently mounted. with abstract job, you get error "cgroups job is already running" | 18:01 |
| hallyn_ | yeah. | 18:01 |
| xnox | hallyn_: if that's what you want, then by all means use abstract job =) | 18:02 |
| hallyn_ | xnox: and what would 'status' output look like again after it had run? | 18:02 |
| hallyn_ | xnox: i want ppl to not mess with their cgroup mouns :) | 18:02 |
| xnox | hallyn_: for a task? | 18:02 |
| hallyn_ | xnox: yeah | 18:02 |
| hallyn_ | xnox: it sounds like you're right. if i were to find time later to change to a task, do you think that'd be sru-able? | 18:04 |
| xnox | hallyn_: for a task it will be in "stop/waiting" | 18:07 |
| xnox | hallyn_: our most common bug against "networking" job is people doing "stop networking" or "restart networking" and expecting that to be equivalent to if up / if down sequence. | 18:07 |
| xnox | hallyn_: in practice it tears down system dbus and most desktop, as stopping networking is about equivalent to switching to just before runlevel S | 18:07 |
| xnox | (runlevel 1) | 18:07 |
| xnox | task job, would make it immune to people "messing" with it by stop/restart, and start will do no harm. | 18:08 |
| kees | doko: why did you remove the diversions for those things? | 18:08 |
| hallyn_ | xnox: i see. so networking.conf should be a task you're saying? | 18:09 |
| hallyn_ | "tears down system dbus" gives me a warm fuzzy. but i digress | 18:09 |
| xnox | hallyn_: =) | 18:10 |
| smoser | xnox, are you going to fix the ssl issue in offlineimap in debian ? | 18:42 |
| doko | kees, why do you want diversions for things which don't exist? | 20:47 |
| Noskcaj | When is the next 19UTC DMB meeting? | 21:28 |
| Laney | https://wiki.ubuntu.com/DeveloperMembershipBoard/Agenda January 27 | 21:29 |
| Noskcaj | Or could i apply at a different time, since i cannot attend at 15UTC | 21:29 |
| Noskcaj | ;( That's the first day back at school, so i wouldn't be able to attend | 21:29 |
| Noskcaj | Is there a recommended alternate way to apply? (for xubuntu packageset and MOTU) | 21:32 |
| Noskcaj | And any chance you could give me a testimonial for either? https://wiki.ubuntu.com/Noskcaj#Testimonials | 21:35 |
| doko | tedg, ping | 21:36 |
| tedg | doko, Howdy | 21:36 |
| Noskcaj | xnox, Any chance you could try and update the ubuntu/transmission bzr? | 21:43 |
| Noskcaj | It is very outdated | 21:43 |
| xnox | hallyn_: i think it's too late to change networking to a task job. | 22:17 |
| xnox | Noskcaj: can you open a bug against project "udd" please? | 22:18 |
| xnox | smoser: yeah, when i have time. badly need to update btrfs-tools & offlineimap in debian. | 22:18 |
| xnox | smoser: NMUs are welcome =) | 22:18 |
| xnox | smoser: or upload direct into ubuntu, i'll sync it all up. | 22:18 |
| YokoZar | At the risk of opening a can of worms, how often are the launchpad buildd's upgraded? Once per LTS? | 22:19 |
| YokoZar | (been waiting on https://bugs.launchpad.net/launchpad-buildd/+bug/915505 for about 2 years now) | 22:20 |
| ubottu | Ubuntu bug 915505 in launchpad-buildd "0.4 recipes: bzr: ERROR: exceptions.AttributeError: 'cStringIO.StringI' object has no attribute 'split' [blocked on migration of PPAs to builderstack]" [Critical,Triaged] | 22:20 |
| xnox | YokoZar: what do you mean by "upgrade" and which builders specifically do you mean? | 22:20 |
| YokoZar | xnox: The above bug comes from not installing a newer version of a package on the builder, so I'm talking about software upgrade. | 22:20 |
| xnox | YokoZar: that's not distro buildds, but ppa builders which are very different (due to isolation, and untrusted code execution) | 22:21 |
| YokoZar | ahh, that makes a little more sense | 22:21 |
| xnox | YokoZar: and the bug says it all, "blocked on migration of PPAs to builderstack" as in openstack. | 22:21 |
| YokoZar | Ahh, I suppose launchpad migrating significant infrastructure to openstack would be quite a project | 22:22 |
| robert_ancell | slangasek, hey, can you reject unity-system-compositor from the NEW queue? It was supposed to go to a PPA | 22:38 |
| robert_ancell | Or anyone else in ~ubuntu-archive, not sure who's online atm | 22:38 |
| Noskcaj | xnox, ok. Should i be ok to copy the current source into the bzr so i can merge? | 22:38 |
| robert_ancell | cjwatson, ^ if online | 22:39 |
| slangasek | robert_ancell: done | 22:39 |
| robert_ancell | slangasek, thanks! | 22:39 |
| xnox | Noskcaj: use merges.ubuntu.com & grab-merge script which provides enverything one needs to a merge by-hand and generate a debdiff suitable for sponsorship or a .dsc/.changes suitable for upload. | 22:39 |
| Noskcaj | ok | 22:40 |
| robert_ancell | slangasek, hmm, bad day for typos for me, I actually meant unity-control-center. Was there a u-s-c in the queue? | 22:40 |
| slangasek | robert_ancell: you know, I didn't actually look? ;) Yeah, there wasn't, now I get the correct output line when rejecting u-c-c | 22:40 |
| robert_ancell | phwew | 22:41 |
| xnox | i have no split personality issues =) https://launchpad.net/ubuntu/+source/armel-cross-toolchain-base/1.103 | 23:55 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!