| chrstphrchvz | Main question: does the size of /boot/grub vary by installation or over time, making it undesirable for separate partition? see description: http://ur1.ca/htmwi | 00:46 |
|---|---|---|
| sarnold | chrstphrchvz: my /boot/grub is currently 8M. I just cleaned up a dozen kernels just yesterday, pity :/ | 00:59 |
| chrstphrchvz | sarnold, I'm almost certain kernels are in /boot, not /boot/grub… | 01:02 |
| sarnold | chrstphrchvz: yes, I just don't know (and hanve't looked) to see if there's any per-kernel data in the /boot/grub that might have grown / shrunk over time.. | 01:03 |
| === shuduo_afk is now known as shuduo | ||
| === _salem is now known as salem_ | ||
| Unit193 | pitti: Howdy. Since systemd is on the agenda for utopic, is Dracut as well? (LP: #1109029, LP: #1266516) | 03:47 |
| ubottu | Launchpad bug 1109029 in linux (Ubuntu) "Depend on linux-initramfs-tools" [Wishlist,Triaged] https://launchpad.net/bugs/1109029 | 03:47 |
| ubottu | Launchpad bug 1266516 in console-setup (Ubuntu) "New version available upstream: 1.104" [Wishlist,Confirmed] https://launchpad.net/bugs/1266516 | 03:47 |
| pitti | Good morning | 03:48 |
| Unit193 | Got you first. ;) | 03:48 |
| pitti | slangasek: -dbg> yes, it does; in fact, if there is a -dbg it prefers that over a -dbgsym as they are sometimes built with extra options and are more reliably present | 03:48 |
| pitti | address-book-service | 0.1.1+14.10.20140715-0ubuntu2 | utopic/universe | source, amd64, arm64, armhf, i386, powerpc, ppc64el | 03:50 |
| pitti | slangasek: ^ I do see those in http://ddebs.ubuntu.com/pool/universe/a/address-book-service/ | 03:50 |
| pitti | slangasek: where do you see it missing? | 03:50 |
| pitti | Unit193: dracut hasn't been discussed so far | 03:51 |
| Unit193 | Pity, would be nice as an option. | 03:51 |
| pitti | Unit193: TBH that would sound a bit like busy-work, and lots of it; initramfs-tools works well, and probably a few dozen packages integrate with it, so it would be quite a transition | 03:51 |
| pitti | Unit193: I'd rather invest some work to boot without any initramfs at all | 03:52 |
| pitti | pretty much the only thing necessary for that (for standard installs) is to teach the kernel to read UUIDs for ext file systems | 03:52 |
| Unit193 | pitti: For the basics, you'd need the alt depend and console-setup updated, but yeah, that's understandable too. | 03:52 |
| === salem_ is now known as _salem | ||
| mbiebl | pitti: one interesting bit is, that dracut supports systemd natively | 04:02 |
| Unit193 | (FWIW, I've tried dracut in Ubuntu and Debian.) | 04:03 |
| pitti | I still don't quite share the obsession of always having an initramfs; unless you are using LVM or cryptsetup, they should be quite unnecessary | 04:03 |
| mbiebl | pitti: it's kinda cool having the journal log from even within the journal | 04:03 |
| pitti | i. e. it's just wasted boot time on all cloud installs and most desktop installs | 04:03 |
| pitti | many server installs certainly use LVM etc., but I also know a lot which don't | 04:04 |
| mbiebl | pitti: oh sure, I agree. initramfs-less boots are interesting | 04:04 |
| pitti | it's a bit sad that UUID reading in the kernel got dropped on the floor; it was tossed around as an idea once | 04:04 |
| pitti | ATM you have to go back to root=/dev/sda2 etc., which would be sad/wrong | 04:04 |
| pitti | mbiebl: oh and BTW: I'm glad that I'm not the only crazy person who starts working before 6 AM :) | 04:05 |
| * pitti ^5s mbiebl | 04:05 | |
| mbiebl | pitti: heh | 04:05 |
| mbiebl | I remember hhoyer posting some numbers | 04:05 |
| mbiebl | that an initramfs didn't actually slow down boot | 04:05 |
| mbiebl | on the contrary | 04:06 |
| pitti | infinity, ScottK: I'd appreciate a review/accepting the new postgresql microrelease SRUs (lucid/precise/trusty), if you have some time | 04:42 |
| pitti | slightly bigger debian/ diff this time as we had to drop some patches which are now obsolete/included upstream | 04:42 |
| pitti | but they only apply to running the tests during build time, and that's proven to work by, well, the packages building :) | 04:43 |
| slangasek | michagogo: how far down my queue> um not sure at this point <sigh> | 04:53 |
| slangasek | hallyn: cgm> I don't think the ftp team will hate you for doing the thing they asked you to do ;) | 04:53 |
| slangasek | pitti: address-book-service - well, 0.1.1+14.10.20140715-0ubuntu2 is the version I just uploaded, so... | 04:54 |
| pitti | slangasek: oh, you mean 0ubuntu1 wasn't there? | 04:55 |
| slangasek | pitti: it wasn't in the index, at least | 04:55 |
| pitti | slangasek: well, this was only one in a range of things which could go wrong | 04:55 |
| pitti | slangasek: sometimes the buildds are down for maintenance, or the apaches are hanging, or apt-ftparchive ran too long, etc. | 04:56 |
| * slangasek nods | 04:56 | |
| pitti | slangasek: this should be better now as I fetch the ddebs from the previous day 4 times now instead of 1 | 04:56 |
| pitti | perhaps I shuold also add a "day-before-yesterday" to re-fetch those too | 04:57 |
| pitti | slangasek: this wasn't an indexing problem btw, the actual .ddebs are/were missing | 04:58 |
| slangasek | pitti: right, I couldn't see any reason index-wise that those particular ones would be missing | 05:07 |
| Whoopie | Hi, where can I open a ticket against the partner repository? I'd like to ask for a skype update as version 4.3 was released. | 06:00 |
| Unit193 | lp 1280109 | 06:05 |
| ubottu | Launchpad bug 1280109 in skype (Ubuntu) "Upgrade to Skype for Linux version 4.3.0.37" [Wishlist,Triaged] https://launchpad.net/bugs/1280109 | 06:05 |
| Whoopie | Unit193: thanks | 06:15 |
| sarnold | cjwatson: finally finished :) enjoy | 07:01 |
| dholbach | good morning | 07:02 |
| dholbach | @pilot in | 07:02 |
| === udevbot changed the topic of #ubuntu-devel to: Archive: open | Devel of Ubuntu (not support or app devel) | build failures -> http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of lucid -> trusty | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: dholbach | ||
| Tribaal | hi all. I'm seeking sponsorship for an update to a particular ubuntu package (I'm the upstream maintainer). Does my work appearing on http://reqorts.qa.ubuntu.com/reports/sponsoring/index.html means I should just wait? | 07:16 |
| Tribaal | (it's in universe) | 07:17 |
| dholbach | Tribaal, yes - which one is it | 07:19 |
| Tribaal | dholbach: https://code.launchpad.net/~tribaal/ubuntu/utopic/ubumirror/1341523-upstream-release/+merge/226654 | 07:19 |
| dholbach | thanks Tribaal | 07:20 |
| Tribaal | dholbach: welcome :) There's no real hurry - but I was worried the procedure I followed is correct :) | 07:21 |
| dholbach | Tribaal, no, looks like you did everyting all right :) | 07:21 |
| Tribaal | dholbach: cool :) | 07:21 |
| dholbach | Tribaal, would you mind if I change the version number to 0.4 instead of 0.4ubuntu1? | 07:24 |
| Tribaal | dholbach: oh not at all. I thought the ubuntu1 thing was required | 07:24 |
| Tribaal | dholbach: what's the rule? | 07:24 |
| dholbach | Tribaal, adding "ubuntu<N>" to the version number usually indicates "we imported this version from Debian, and added Ubuntu-local changes" | 07:24 |
| dholbach | as the package is not in Debian, 0.4 sould be fine | 07:24 |
| Tribaal | dholbach: ahhh ok | 07:24 |
| Tribaal | dholbach: yeah then by all means :) | 07:25 |
| dholbach | rock and roll :) | 07:25 |
| dholbach | Tribaal, uploaded | 07:26 |
| Tribaal | dholbach: woot ) | 07:26 |
| Tribaal | dholbach: thanks! | 07:26 |
| dholbach | anytime | 07:27 |
| Tribaal | dholbach: my first changes to ubuntu, believe it or not :) | 07:27 |
| Tribaal | (ubuntu itself) | 07:27 |
| dholbach | champagne! :) | 07:27 |
| Tribaal | indeed :) | 07:27 |
| Noskcaj_ | Has something happened to the arm64 and ppc builders? two different packages have chroot problems for me currently | 07:32 |
| dholbach | Noskcaj_, does it look something like https://launchpadlibrarian.net/180706189/buildlog_ubuntu-utopic-i386.ubumirror_0.4_CHROOTWAIT.txt.gz? | 07:36 |
| Noskcaj_ | it's a plymouth issue | 07:37 |
| Noskcaj_ | (on ppc) | 07:37 |
| Noskcaj_ | that's the issue on arm64 | 07:37 |
| dholbach | xnox, do you know if anyone is working on the gnustep-base ftbfs? | 07:40 |
| dholbach | hey tumbleweed - long time no speak... how are you doing? do you think at some stage we could do another ubuntu-dev-tools upload? :) | 07:51 |
| tumbleweed | dholbach: hi. yeah, I've kind of fallen off the planet :/ | 07:52 |
| tumbleweed | this would be doable | 07:52 |
| dholbach | tumbleweed, how was your time off the planet? :) | 07:53 |
| * dholbach hugs tumbleweed | 07:53 | |
| tumbleweed | :) | 07:53 |
| tumbleweed | rather busy. that work-life balance thing is hard | 07:53 |
| dholbach | tumbleweed, do you have plans to make it a little less work in the next time? :) | 07:54 |
| tumbleweed | yeah. I'm planning to move to the US for a bit, which should through my life into enough disarray that I can reorganise it | 07:55 |
| dholbach | man, I cross my fingers for you! all the best! :) | 07:56 |
| tumbleweed | thanks | 07:56 |
| dholbach | zul, can you take a look at bug 1328693? | 08:06 |
| ubottu | bug 1328693 in fcoe-utils (Ubuntu) "Sync fcoe-utils 1.0.29+git0.09caead4-2 (universe) from Debian unstable (main)" [Wishlist,Incomplete] https://launchpad.net/bugs/1328693 | 08:06 |
| xnox | mvo_: infinity: cjwatson: https://launchpad.net/ubuntu/+source/openwsman/2.4.7-0ubuntu2 not fun, i'm having malta flashbacks. | 08:26 |
| LocutusOfBorg1 | dholbach, what an efficiency! | 08:49 |
| LocutusOfBorg1 | thanks a lot! | 08:49 |
| LocutusOfBorg1 | now let's hope somebody fix the chroot problems | 08:50 |
| infinity | mvo_: That apt bug is breaking buildd chroot upgrades in utopic now too. \o/ | 09:09 |
| infinity | mvo_: https://launchpadlibrarian.net/180716365/buildlog_ubuntu-utopic-i386.indicator-messages_13.10.1%2B14.10.20140725-0ubuntu1_CHROOTWAIT.txt.gz | 09:09 |
| infinity | mvo_: The upshot is that's a much smaller test case. Download http://launchpadlibrarian.net/174364588/chroot-ubuntu-utopic-i386.tar.bz2 configure sources.list for proposed, dist-upgrade.\ | 09:10 |
| * infinity is going to get some food, then do manual chroot surgery to get us back on track while mvo tries to figure out the real bug here. | 09:12 | |
| cjwatson | sarnold: yay, thanks | 09:31 |
| pitti | erk, FTBFS galore due to CHROOTWAITs | 09:36 |
| pitti | hm, plymouth/mountall don't upgrade, but neither of those changed recently | 09:37 |
| cjwatson | pitti: see what infinity said just a few lines back | 09:37 |
| infinity | I'll mangle the chroots right now to work around it so people are unblocked. | 09:38 |
| pitti | cjwatson: ah, thanks; sorry, I just rebooted and didn't see scrollback | 09:38 |
| mvo_ | infinity: thanks | 09:51 |
| infinity | mvo_: Grab that chroot now before I replace it. :) | 09:52 |
| mvo_ | infinity: just downloaded it | 09:57 |
| cjwatson | infinity: Surely it gets a new LFA when you do. :-) | 10:01 |
| cjwatson | (But yeah, would be GCed eventually) | 10:01 |
| infinity | cjwatson: Right. | 10:03 |
| infinity | mvo_: FWIW, it needs -proposed enabled to fail. Probably the addition of the new "init" package. | 10:05 |
| infinity | mvo_: An upgrade from that tarball to current, then to -proposed, works fine. Straight from the tarball to proposed will fail. | 10:06 |
| infinity | (Thank god for the former data point, that's how I'll work around it for now) | 10:06 |
| cjwatson | infinity: If so, that won't be true for very much longer. New init-system-helpers is migrating to utopic now | 10:06 |
| === doko__ is now known as doko | ||
| cjwatson | You have a bit longer because it'll need another publisher run after this one ... | 10:07 |
| infinity | cjwatson: Well, the new chroots are migrating to the librarian too. :) | 10:07 |
| cjwatson | Cool | 10:07 |
| tvoss | doko, cjwatson hey there, we are seeing some issues when using ccache with gcc 4.9 in sbuild: http://paste.ubuntu.com/7854399/ | 10:08 |
| tvoss | oh sorry, wrong paste | 10:08 |
| mvo_ | infinity: yeah, I can reproduce | 10:08 |
| tvoss | doko, cjwatson http://paste.ubuntu.com/7854397/ | 10:08 |
| cjwatson | That looks like a local config failure, maybe /var/cache/ccache-sbuild/ not mounted in the chroot or something, not sure why you're bothering doko with it | 10:10 |
| cjwatson | Doesn't look like a toolchain problem | 10:11 |
| doko | and why are you using ccache for package builds at all? | 10:11 |
| tvoss | doko, helps a lot in speeding things up for local test builds | 10:11 |
| tvoss | cjwatson, thanks, wasn't sure if it's a toolchain problem, or not | 10:12 |
| cjwatson | I assume you're following https://wiki.debian.org/sbuild#Using_.22ccache.22_with_sbuild - perhaps those wiki instructions are buggy or perhaps the sbuild profile is wrong | 10:12 |
| cjwatson | (since that's basically the only google hit for "ccache-sbuild") | 10:12 |
| cjwatson | Note that those instructions assume that the relevant schroot is using the sbuild profile - if it's using say "default" instead then you need to edit a different fstab | 10:13 |
| === Sweetsha1k is now known as Sweetshark | ||
| tvoss | cjwatson, we are usually following https://wiki.ubuntu.com/SimpleSbuild | 10:13 |
| tvoss | cjwatson, but yeah, that points to the debian page | 10:14 |
| cjwatson | tvoss: OK, I think my answer is "when you figure out the problem please document it on the wiki" then :-) | 10:16 |
| Saviq | cjwatson, yes, I got the script from there, and it worked until we switched to explicit gcc | 10:16 |
| dholbach | LocutusOfBorg1, in 1348564 you seem to have attached the wrong diff | 10:23 |
| LocutusOfBorg1 | sorry | 10:25 |
| LocutusOfBorg1 | done now | 10:25 |
| dholbach | elopio, does https://code.launchpad.net/~canonical-platform-qa/messaging-app/qmltests1/+merge/227661 need any action? | 10:26 |
| dholbach | thanks LocutusOfBorg1 | 10:27 |
| doko | pitti, jibel: is the autopkg test queue busy? wondering why the autopkg test for lava-server isn't run | 10:27 |
| jibel | doko, it ran but proposed-migration was stuck | 10:28 |
| jibel | doko, or more exactly it is running | 10:29 |
| doko | thanks | 10:29 |
| LocutusOfBorg1 | sorry again dholbach, calling every file "debdiff" is a shame | 10:30 |
| LocutusOfBorg1 | :) | 10:30 |
| dholbach | it's all right :) | 10:30 |
| dholbach | LocutusOfBorg1, I'm adding the bug number to the changelog entry | 10:30 |
| LocutusOfBorg1 | thanks ;) | 10:33 |
| === lubko is now known as citlivka | ||
| === timrc-afk is now known as timrc | ||
| dholbach | @pilot out | 11:09 |
| === udevbot changed the topic of #ubuntu-devel to: Archive: open | Devel of Ubuntu (not support or app devel) | build failures -> http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of lucid -> trusty | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: | ||
| === tvoss is now known as tvoss|test | ||
| === tvoss|test is now known as tvoss | ||
| === MacSlow is now known as MacSlow|lunch | ||
| === tvoss is now known as tvoss|lunch | ||
| === psivaa is now known as psivaa-afk | ||
| === _salem is now known as salem_ | ||
| === MacSlow|lunch is now known as MacSlow | ||
| mvo_ | infinity: hi, this is not entirely trivial to debug, but it is definitely the init addition thats triggering the bug | 13:19 |
| mvo_ | infinity: there are quite a few loop but they get correctly broken without the new init pkg and no longer with it. lets see whats causing it | 13:20 |
| === tvoss|lunch is now known as tvoss | ||
| xnox | mvo_: infinity: slangasek: that init package looks very bad, we should not have it in ubuntu. Especially since we don't have neither sysvinit-core, nor systemd-sysv, nor ready to support either of them. | 13:33 |
| infinity | mvo_: Well, if you can figure it out, it'll probably fix jibel's saucy->trusty issue too. The symptoms seem nearly identical, even if the cause isn't immediately obviously the same. | 13:48 |
| infinity | mvo_: But there's the part where two of the three times this has happened (before trusty release, and now in utopic), we found a change in the base set that was tickling the issue, but in the saucy->trusty case, it's not entirely obvious if that's happening... | 13:49 |
| pitti | xnox: in my current sysvinit merge I still dropped syvinit-core and sysvinit; I suppose we never want those two, even with "init" being around | 13:51 |
| pitti | xnox: but shouldn't init also have an upstart alternative? | 13:51 |
| infinity | pitti: It does. | 13:51 |
| pitti | Pre-Depends: sysvinit-core | systemd-sysv | upstart | 13:52 |
| infinity | xnox: I see nothing "bad" about the init package being merged. | 13:52 |
| pitti | so, we only have upstart ATM | 13:52 |
| pitti | so that should be fine | 13:52 |
| infinity | xnox: Especially if the intent is to simplify and normalize dependencies. | 13:52 |
| xnox | pitti: we will not have sysvinit-core though. | 13:52 |
| infinity | xnox: So? | 13:52 |
| pitti | yeah | 13:52 |
| pitti | systemd-sysv at some point | 13:52 |
| infinity | xnox: It's an OR dep, ones that don't exist are happily ignored, and the one you already have installed always wins. | 13:53 |
| xnox | infinity: for ubuntu, our transition will be not via init package though. For us, we will simply build upstart without sbin/init, and make systemd conflict & replace it.... | 13:53 |
| infinity | xnox: So, it's harmless. | 13:53 |
| infinity | xnox: The transition won't be via that package in Debian either. | 13:53 |
| infinity | xnox: Anyhow, I see no reason to gratuitously diverge, the package is harmless. | 13:54 |
| xnox | infinity: it's clearly not harmless, given the havoc it caused. And I still assert that it's uterly pointless in Ubuntu =) especially as an Essential package, give that our upstart is not Essential. | 13:54 |
| infinity | (Except for exposing the annoying apt bug, yet again, but we really really need to fix that, not keep reverting every change that trips it) | 13:55 |
| xnox | infinity: it causes upstart to be pulled in, into more places than it used to be.. | 13:55 |
| infinity | xnox: It cause no harm, apt did. | 13:55 |
| xnox | why make upstart essential? | 13:55 |
| xnox | also it would need to be Multi-Arch:foreign, and it's not marked as such. | 13:55 |
| infinity | xnox: upstart is prio:required and transitively essential, where was it not being pulled in previously? | 13:56 |
| xnox | trying to work that bit out. I'm fuzzy on essential vs required. | 13:58 |
| infinity | xnox: required is "your system is broken without these packages installed" and apt won't let you remove them without typing "Yes, I'm an idiot". | 13:58 |
| infinity | xnox: essential is "stuff you don't need to depend on". | 13:58 |
| xnox | but a chroot without an init is not broken. | 14:02 |
| infinity | xnox: It was likely wrong for us to *make* upstart part of that set, but it always has been. | 14:03 |
| xnox | yeah, nominally it was aimed at minimal. | 14:03 |
| infinity | xnox: So, whatever world you're remembering where you could set up a chroot without upstart isn't Ubuntu, or is pre-upstart. | 14:04 |
| xnox | or it's my little world where i do $ apt-get remove upstart in chroots and watch it shrink. | 14:04 |
| xnox | also docker does that. | 14:04 |
| infinity | So, you type "yes, I know what I'm doing", and remove all the things that depend on it? Fair enough. | 14:04 |
| xnox | infinity: and, we will carry essential pointless packages for the sake of it? | 14:05 |
| infinity | You could still do that with this new package. | 14:05 |
| xnox | no, in trusty it doesn't ask me to type "yes, I know what I'm doing" | 14:05 |
| xnox | http://paste.ubuntu.com/7856047/ | 14:05 |
| infinity | xnox: Oh, no, you're right. It only makes you say that for essential, not required. | 14:06 |
| infinity | So, we could just drop the essential from this package, and otherwise leave it alone. | 14:06 |
| xnox | now, i will not be able to do so in utopic, since "init" is essential, and needs --force-remove-essential | 14:06 |
| xnox | infinity: ok, (a) drop essential (ubuntu-only) (b) mark it M-A:foreign (forward to debian) | 14:06 |
| infinity | I'd forward the first bit to Debian too. | 14:07 |
| infinity | sysvinit was never essential, same complaint there as here. | 14:07 |
| infinity | In fact, a bare Debian debootstrap has no init, while a bare Ubuntu does, they were always slimmer. | 14:07 |
| infinity | sbin/init that is, not the new package. :P | 14:07 |
| xnox | infinity: ok, can you nuke my init-helpers upload from utopic-proposed then? i will not bother fixing it. | 14:09 |
| xnox | infinity: and just send patches to debian for feedback. | 14:09 |
| infinity | xnox: Done. | 14:11 |
| xnox | mvo_: that init package looks very broken. It's essential, and pre-depends on non-essential packages. There is no way to resolve that, is there? | 14:30 |
| xnox | (newly essential) | 14:30 |
| cjwatson | huh? essential isn't closed. | 14:31 |
| cjwatson | note how libc6 isn't essential. | 14:31 |
| mvo_ | xnox: I can not say that I feel good about it being essential, among other things it makes life more complicated for apt as it handles essential special, i.e. it wants to immediate-configure them. and it will do the same with all dependencies of essential packages which make upstart and its dependencies immediate configure and thus more work | 14:32 |
| cjwatson | you might not want it to be essential for other reasons, but "pre-depends on non-essential packages" isn't broken in and of itself :) | 14:33 |
| mvo_ | infinity: I have a reasonable testcase now http://paste.ubuntu.com/7856261/ - note how in line 26 procps is configured and in line 28 initscripts is configured, those need to be in the same line (they are a dependency loop) | 14:33 |
| mvo_ | infinity: at least that is now something to work with :) | 14:33 |
| xnox | cjwatson: i see. "isn't broken", sans bugs like "it breaks our apt each time" =) | 14:33 |
| cjwatson | but that's not because of the mere fact of an essential package pre-depending on non-essential packages. | 14:34 |
| infinity | xnox: A bug in apt doesn't make another package broken. | 14:34 |
| cjwatson | if it were, then our archive would have been broken for ten years. | 14:34 |
| cjwatson | apt-cache show util-linux | 14:34 |
| infinity | xnox: And this bug is exposed other places too, we need to fix it, not keep working around it. | 14:34 |
| cjwatson | for that matter, apt-cache show dpkg | 14:34 |
| xnox | yiikes. yeah. now i see it. horum. good luck mvo_ =) | 14:35 |
| cjwatson | (essential has to not be closed under (pre-)dependency, because otherwise it would be impossible to ever implement a library transition that affected the essential set.) | 14:36 |
| infinity | cjwatson: I keep waiting for libc7 to happen, just to prove the point. | 14:36 |
| xnox | i've never used computers with libc so name less than 6 =) | 14:37 |
| xnox | (kfreebsd notwithstanding) | 14:37 |
| cjwatson | I was about to say :) | 14:37 |
| infinity | You could have said "with a libc other than glibc2". ;) | 14:38 |
| infinity | Also, youngun. | 14:38 |
| infinity | libc5->libc6 was very painful. | 14:38 |
| ogra_ | oh, i remember that one | 14:38 |
| rbasak | Is merge-o-matic known to be broken at the moment? | 14:39 |
| cjwatson | It was fine last I looked, and it should be mailing me if there are problems | 14:39 |
| rbasak | It's generating buggy .src.tar.gz files (quilt patches applied, but no .pc directory) | 14:39 |
| rbasak | eg. exim4 | 14:39 |
| cjwatson | Oh, that's just how it's always been I think | 14:39 |
| cjwatson | You probably just want to do such merges yourself | 14:40 |
| cjwatson | Or use http://people.canonical.com/~cjwatson/dpkg-quilt-setup to set up .pc | 14:40 |
| rbasak | Ah - thanks. | 14:40 |
| rbasak | We're mentoring new team members in #ubuntu-server, and everyone is hitting that. | 14:40 |
| rbasak | I don't tend to use MoM much myself so didn't know about that. | 14:41 |
| cjwatson | Merges aren't a good thing for new people anyway, IMO. | 14:41 |
| cjwatson | I've been fighting against the notion that they're a sensible intro task for a long time now | 14:42 |
| rbasak | We have a big pile of outstanding merges to do, and not enough people to do them :-/ | 14:42 |
| cjwatson | Yeah, but in general you need a fairly good understanding of packaging first. | 14:42 |
| rbasak | I have the same opinion about bug triaging (for the server team anyway) - need a fairly good understanding of the underlying packages and use cases first. | 14:43 |
| rbasak | They seem to be doing a reasonable job of understanding the previous delta. | 14:43 |
| cjwatson | For merges I pretty much always debdiff myself and apply directly, using patch --dry-run until I've mangled either side into shape. I only use MoM for a listing and for a rough guideline. | 14:44 |
| cjwatson | (In cases where I can't do the merge in revision control, of course.) | 14:45 |
| xnox | mvo_: infinity: hm. in the bug report it was pointed out that in debian they already have another essential metapackage with exact same pre-depends. (sysvinit) | 14:50 |
| xnox | which we don't have, it looks. | 14:51 |
| mitya57 | jtaylor: Is there any reason we haven't yet synced new matplotlib from Debian? | 15:02 |
| === psivaa-afk is now known as psivaa | ||
| barry | pitti: ping | 15:16 |
| pitti | barry: ICMP command not implemented | 15:16 |
| pitti | barry: (TGIF) | 15:17 |
| pitti | do we have a version of http://people.canonical.com/~ubuntu-archive/nbs.html for -proposed? | 15:26 |
| pitti | barry was asking about zope.security promotion, which drops (NBS) python-zope.security-untrustedpython | 15:27 |
| pitti | but it's not there | 15:27 |
| infinity | pitti: We don't, no. Though update_excuses makes it sort of obvious to people who know how to read it, at least. | 15:30 |
| pitti | infinity: yeah, so I figured that http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#zope.security was due to NBS | 15:30 |
| pitti | but not seeing reverse deps anywhere is a bit inconvenient | 15:31 |
| pitti | "reverse-depends python-zope.security-untrustedpython" is good enough, but error prone (forgetting build deps, etc.) | 15:31 |
| pitti | anyway, I suppose britney doesn't want to promote it due to the NBS | 15:31 |
| infinity | pitti: reverse-depends -b? :) | 15:31 |
| pitti | even though the new package has a Provides: python-zope.security-untrustedpython | 15:31 |
| barry | -b gives build-deps | 15:31 |
| pitti | yes, I know, still error prone :) | 15:32 |
| barry | yeah ;) | 15:32 |
| pitti | so in theory the package shoudl be able to promote | 15:32 |
| infinity | Yeah, agreed, we should have a proposed one. | 15:32 |
| barry | the provides is now in zope-untrustedpython | 15:32 |
| pitti | as the two rdepends are unversioned | 15:32 |
| infinity | pitti: If the new package has a provides, and nothing has versioned deps, we're good to go, remove away. | 15:32 |
| pitti | ack; just wanted to double-check my reasoning | 15:32 |
| infinity | pitti: Note that nbs.html doesn't handle that situation at all either, it would need the same manual checking. | 15:33 |
| infinity | pitti: It would tell you it was NBS, but unsafe to remove. | 15:33 |
| pitti | but list all deps | 15:33 |
| infinity | True, it does that. | 15:33 |
| pitti | barry: anyway, python-zope.security-untrustedpython removed | 15:33 |
| pitti | barry: so after the next publisher run, britney should stop whining | 15:33 |
| barry | pitti: awesome, thanks. thanks too infinity | 15:34 |
| hallyn | hi - bit of autoconf help would be great for git://github.com/cgmanager/cgmanager. When I build locally, I get 'cgm' built as .libs/cgm, and ./cgm is a libtool-generated temporary wrapper script for .libs/cgm. | 15:34 |
| hallyn | can someone look at my configure.ac and tell me what i'm doing wrong to force that to happen? Is it the cgm_DEPENDENCIES? (though dropping that doesn't help) | 15:35 |
| pitti | thanks infinity | 15:35 |
| pitti | infinity: also for untangling the chroots -- how did you LART them back into a working state, OOI? | 15:35 |
| hallyn | the real problem is that in jenkins it's not doing that, so I get https://travis-ci.org/cgmanager/cgmanager/jobs/30841377 when help2man tries to run ./libs/cgm | 15:35 |
| hallyn | so i just want it consistent. i do need the libcgmangaer.la built before cgm | 15:36 |
| hallyn | well, i supposei could have Makefile.am check if .libs/cgm exists, and if not run ./cgm | 15:36 |
| infinity | pitti: I just upgraded them. Upgrading in two steps (to recent utopic, then to the new init) worked fine, it's in one step that apt barfs. | 15:36 |
| infinity | pitti: But, if you're in that barfy situation, it also works to just do it twice. | 15:36 |
| infinity | pitti: ie: apt-get update ; apt-get dist-upgrade ; apt-get -f install ; apt-get dist-upgrade | 15:37 |
| pitti | heh, fun | 15:37 |
| pitti | leaves a stain of disappointment on the super cow powahs, though | 15:38 |
| mvo_ | jibel: if you can still reproduce lp1347721 in the lab, would it be much work for you if you would put this ppa into the system https://launchpad.net/~mvo/+archive/ubuntu/lp1347721/ works around the bug? | 15:44 |
| jibel | mvo_, is it a workaround to make the upgrade succeed or a fix to test ? | 15:45 |
| mvo_ | jibel: its a workaround for the upgrade, a by-product of my debugging, if it helps | 15:46 |
| mvo_ | jibel: if its too much trouble don't bother, its a 50:50 chance at this point | 15:46 |
| jibel | mvo_, no problem, I'll add this ppa | 15:47 |
| xnox | hallyn: looks correct. one needs to do $ make install, for proper binaries to be installed... | 16:01 |
| hallyn | xnox: so jenkins is being weird by not having .libs/cgm ? | 16:03 |
| * hallyn is being hits by an old old bug https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=534964 :) | 16:04 | |
| ubottu | Debian bug 534964 in linux-2.6 "Please enable CONFIG_CGROUP_MEM_RES_CTLR" [Wishlist,Fixed] | 16:04 |
| hallyn | the problem is it's nto mountable, but it shows up in /proc/cgroups. that's nto nice | 16:04 |
| xnox | hallyn: you shouldn't use .libs/cgm, looking more. one sec. | 16:04 |
| hallyn | xnox: ./cgm does work, but it prefixes argv[0] with 'lt-'. | 16:05 |
| hallyn | Well I suppose I can just hardcode the name as cgm :) simpler solution | 16:06 |
| cjwatson | use ./libtool --mode=execute | 16:06 |
| hallyn | cjwatson: this is for running through help2man from Makefile though | 16:07 |
| cjwatson | ah | 16:07 |
| hallyn | so i wasnt' thinking, simplest solution is probably just to fix up the argname inside cgm's usage statement itself | 16:08 |
| cjwatson | I tend to think help2man is best used to generate a template which you then maintain manually henceforth; it's not cross-build-friendly to start with | 16:08 |
| hallyn | hm | 16:09 |
| hallyn | i did worry at first, but it seemed to be working out | 16:09 |
| mbiebl | xnox: still anything unclear after reading the email with the transition plan? | 16:11 |
| xnox | mbiebl: yes.... e.g. how to apply it to ubuntu that (a) broke all our chroots today on all buildds (b) we don't have sysvinit / essential:yes metapackage. | 16:12 |
| melodie | hi | 16:12 |
| xnox | mbiebl: and we don't support sysvinit init, thus we'll need hard upstart -> systemd migration, when it's ready. | 16:12 |
| melodie | I have a very simple question for I didn't find a way to find out this by myself : what exactly is the gtk3 version used in Trusty, please? | 16:12 |
| melodie | or what method will allow me to find out? | 16:13 |
| cjwatson | melodie: rmadison gtk+3.0 | 16:13 |
| xnox | melodie: https://launchpad.net/ubuntu/+source/gtk+3.0 | 16:13 |
| mbiebl | xnox: I guess that needs to be figured out by the Ubuntu maintainers and means a debdiff for i-s-h | 16:13 |
| melodie | thanks! | 16:13 |
| mbiebl | xnox: i.e. no automerge anymore | 16:14 |
| melodie | cjohnston what is rmadison? | 16:14 |
| xnox | mbiebl: sure, that's fine. It's just still very fuzzy to me how to do it properly, and e.g. we do have a few more places where we can quirk things (upgrade-manager) | 16:15 |
| xnox | hence no prior need for "sysvinit" package per se | 16:15 |
| mbiebl | yeah, I can understand that the init package is not really interesting for ubuntu | 16:16 |
| cjwatson | melodie: man rmadison | 16:16 |
| cjwatson | melodie: (it's in devscripts) | 16:16 |
| melodie | ah! I was wondering how to install it, thanks | 16:16 |
| mbiebl | and actually harmful as it is | 16:16 |
| xnox | mbiebl: that's the conclusion i came to, but infinity believe it's harmless. | 16:16 |
| xnox | mbiebl: out of the three packages listed, we only have upstart. so it doesn't seem to be harmful, just very pointless. | 16:17 |
| mbiebl | oh, you don't have the systemd-sysv package yet in utopic? | 16:17 |
| smoser | hey. i'm sure i'm doing something dumb. | 16:18 |
| xnox | mbiebl: nope, we are not ready yet. | 16:18 |
| smoser | but someone able to tell me what | 16:18 |
| mbiebl | xnox: ok, then yeah, it sounds like it shouldn't do any harm | 16:18 |
| smoser | http://paste.ubuntu.com/7857020/ | 16:18 |
| xnox | mbiebl: we merge systemd, but we are not building that one yet. We still have a lot of packages that have upstart jobs without either initscripts/units. | 16:18 |
| mbiebl | sure | 16:19 |
| xnox | mbiebl: nothing of major importance, just like things like openstack. | 16:19 |
| mbiebl | :-) | 16:19 |
| tinoco | could any of you guys upload a fix (https://bugs.launchpad.net/ubuntu/+source/parted/+bug/1333462) for me ? | 16:19 |
| ubottu | Ubuntu bug 1333462 in parted (Ubuntu Precise) "Precise: Linux partitioning tools give GPT Linux partitions wrong type code" [Undecided,In progress] | 16:19 |
| smoser | full log at http://paste.ubuntu.com/7857090/ if helpful. | 16:20 |
| smoser | stgraber, or pitti ? | 16:20 |
| hallyn | xnox: so out of curiosity, is the init script conversion being tracked somwhere? | 16:21 |
| xnox | hallyn: on ad-hoc basis atm. | 16:22 |
| alexbligh1 | hallyn, are you interested in a patch that allows for qemu / kvm live migration between Precise and Trusty? | 16:22 |
| hallyn | alexbligh1: I am | 16:23 |
| alexbligh1 | hallyn, https://lists.nongnu.org/archive/html/qemu-devel/2014-07/msg03160.html & https://github.com/abligh/qemu/commit/dc5a04eb2a55ba5024726d2aae5a980315f3c885 | 16:23 |
| alexbligh1 | hallyn, working in my (limited) environment. If there is a chance of upstreaming it either to qemu or to Ubuntu, then I will get it working more generally. | 16:24 |
| alexbligh1 | hallyn, it adds a new machine type which matches qemu-kvm 1.0 (as opposed to qemu-1.0) | 16:24 |
| hallyn | alexbligh1: Looks like it won't affect anything else, perfect. Does it actually work? | 16:24 |
| hallyn | it chagnes vga size? (/me eyes glazing over) | 16:25 |
| alexbligh1 | hallyn, it does in my limited use case (I don't use every option qemu provides). I know there is probably a bit of work to do on qxl, as that changed too. And it needs more testing. And, um, it would be helpful to have someone respond on qemu-devel and get some interest in taking it upstream. | 16:25 |
| hallyn | I don't think anyone used qxl in precise, so it would suffice for ubuntu without that | 16:25 |
| hallyn | rharper: hey! | 16:26 |
| alexbligh1 | hallyn, vga ram size, yes. | 16:26 |
| hallyn | rharper: ^ could you comment on that patch on the mailing list? It looks very nice to me... | 16:26 |
| alexbligh1 | hallyn, vga rom size is a different problem, caused by the size of the shipped roms changing. | 16:26 |
| hallyn | alexbligh1: but you're able to migrate VMs from precise to trusty, despite that? | 16:26 |
| rharper | hallyn: looking | 16:26 |
| alexbligh1 | hallyn, rharper and it really could do with more eyes | 16:26 |
| alexbligh1 | hallyn, in a test environment on my laptop with the VMs that we produce, yes. | 16:27 |
| alexbligh1 | hallyn, If you send me a livemigrate to disk snapshot that doesn't work, I'll look at fixing them. | 16:27 |
| rharper | my biggest concern with the migration data patching is that we're likely going t miss something, so different device, or different device state; | 16:27 |
| alexbligh1 | hallyn, the complication is $work doesn't use libvirt. | 16:27 |
| rharper | in upstream, there was considerable effort to automate the generation of the migration structures automatically; | 16:28 |
| alexbligh1 | rharper, it's self-contained (i.e. a new machine type). So the worst that can happen is migration (still) fails. | 16:28 |
| rharper | no, it's worse | 16:28 |
| rharper | it'll succeed and you'll have data corruption | 16:28 |
| rharper | that's what I worry about | 16:28 |
| alexbligh1 | rharper, I don't think I'm touching that bit really. When it failed before it failed hard (section IDs did not line up). | 16:29 |
| alexbligh1 | rharper, unless I'm missing what you mean? | 16:29 |
| rharper | right, so, we're stuffing old memory layout into new memory layouts; it's not clear to me that the new devices with old memory do all of the right things | 16:29 |
| rharper | we're attempting to resume "newer" devices with "older" machine state | 16:30 |
| rharper | that's risky | 16:30 |
| alexbligh1 | rharper, same memory layouts as previous versions of qemu, but they were advertised wrong; so, for intance, the piix4 acpi stuff was actually sending v3 format code, but advertising as v2. There has always been a v3 format reader there, it just wasn't being triggered. | 16:30 |
| alexbligh1 | rharper, same sort of thing for the 8259 PIT code. It's really that the qemu-kvm / qemu-merge was not at a single point in the format specification. I'm not using any new structures really. And it's heavilly based on the redhat patch I indicated (save I do it dynamically) - they tested all the migrate cases (apparently). The exception being rom size problems (because that's down to Ubuntu's packaging) | 16:32 |
| rharper | it still makes me uncomfortable w.r.t running a new machine type on the destination, you'll still want to make the switch to the new machine at some point (I would think w.r.t support). With any migration changes, I would recommend working with mdroth on #qemu (stable maintainer IIRC) | 16:33 |
| alexbligh1 | rharper, agree re wanting to make the switch some time. But in a situation where you have multiple live customers, 'when I upgrade my host OS' is not the best time for all customers to make the switch (assuming upgrading host OS means a live migrate). What we're doing is live migrate around OS upgrade, then on reboot we're upgrading to -M qemu-2.0. Don't think we can get around the 'new machine type' issue, if | 16:36 |
| alexbligh1 | you want to keep live migrates from 'real' qemu-1.0 type stuff working (which would include live migrates from q,r,s,t which were launched with -M qemu-1.0 IIRC). | 16:36 |
| rharper | yeah, I understand the challenges w.r.t consuming the unstable migration format; | 16:37 |
| alexbligh1 | rharper, though breaking them and making -M pc-1.0 do this by default and provifing pc-1.0-old would be a trivial change (s/qemu-1.0/pc-1.0/g; in the above) | 16:37 |
| alexbligh1 | rharper, hallyn well, it's there if you want it. Very happy to generalise it as far as possible, test, debug etc. if you want it for Ubuntu. If not we'll use it for our own use case. Will be trying to get it upstream anyway. | 16:41 |
| rharper | alexbligh1: right -- I'd really like to see Mike Roth or Juan Q. feedback on the patches, you might cc them in future rounds of the patch | 16:44 |
| alexbligh1 | rharper, thanks; will do next time I ping the list - sounds of stones falling into wells so far | 16:45 |
| hallyn | desrt: hey, are you back? | 16:45 |
| alexbligh1 | rharper, though fixing this way was bonzini's idea... | 16:46 |
| rharper | alexbligh1: if all of the "fixes" are related to misadvertised format; then I'd feel better; actual format deltas or other bugs w.r.t data not getting transfered or initialized is my worry | 16:46 |
| hallyn | alexbligh1: could you cc: me explicitly when you next send? (I subscribe to qemu-devel, but it pretty much goes straight to /dev/null ) | 16:46 |
| rharper | alexbligh1: qemu-devel is like that quite often, you can find most of the devs on #qemu on OFTC; worth popping in after a few rounds of resubmits; | 16:46 |
| rharper | alexbligh1: cool | 16:47 |
| hallyn | alexbligh1: thanks! | 16:47 |
| alexbligh1 | rharper, the two things that were actually breaking reloads were essentially misadvertised stuff. without the patch it goes stomping off the end of a structure and (inevitably fails). With the patch then (if fed an output from qemu-kvm-1.0) it actually has the right structure boundaries. | 16:47 |
| alexbligh1 | rharper, reading the redhat patch may help understand what I am doing. | 16:47 |
| rharper | alexbligh1: confined to how you launched your VMs | 16:47 |
| alexbligh1 | rharper, yes, but the only other one I /know/ of that's wrong is QXL video size. | 16:48 |
| rharper | alexbligh1: I went through it briefly, but qemu has *lots* of devices and *lots* of options; the migration format has had *lots* of bugs | 16:48 |
| rharper | alexbligh1: right, which is why I was hoping to leverage some of the 2.0 migration testing framework to iterate throug the various device configs to confirm misadvertisement versus other missing descriptors in the device layout | 16:49 |
| alexbligh1 | rharper, yes. amit did a JSON compare and we're catching all those catch (which isn't everything). But if there's another struct missize error/advertising error, it will be mismatched anyway as it is (that's what I meant by won't be any worse) | 16:49 |
| alexbligh1 | rharper, you mean amit's stuff? the trouble is he only tests what it /says/ it advertises, not what it actually sends. So it wouldn't have found these | 16:49 |
| alexbligh1 | rharper, ... or any others like it. | 16:50 |
| rharper | right, so the json work is step one, the next would to be to migrate and exercise the resulting VM to some degree to build confidence | 16:50 |
| alexbligh1 | rharper, indeed. And it probably also needs to survive a soft reboot for more general usage than mine, which will reexercise the ROMs. | 16:51 |
| rharper | yeah | 16:51 |
| rharper | there's no good fix for reloading of the roms | 16:51 |
| rharper | mdroth and I talked about that many times... | 16:51 |
| rharper | definitely the reboot is needed | 16:51 |
| rharper | as that's where the device will get reset with the new qemu; and potential explosions | 16:52 |
| alexbligh1 | rharper, you only really need to 'fix' it when the ROM size changes across a power of 2; last time I looked in my environment it was only the cirrus vga ROM which had done that, and the answer there might be to ship the Precise cirrus vga ROM binary with qemu, as you can change the rom binary from the command line (yuck). | 16:52 |
| alexbligh1 | rharper, if you don't do that, then even a blank file of the right length will work on migrate until soft reboot, at which point the user presumably says "hmm, odd, soft reboot failed, let's try hard reboot', which is not a disaster. | 16:53 |
| rharper | alexbligh1: right, the challenge is that any upgrade to the ROMs could trigger trouble if the sizes change enough; and it's possible for it to go either way (shrink or expand); we talked about some how bringing the source roms along; but that prevents upgrades | 16:54 |
| alexbligh1 | rharper, correct. But presumably we should not be permitting such changes in ROM size within a given release, and if we change them between releases, we should ship the old ones too. | 16:55 |
| alexbligh1 | rharper, AIUI the redhat way of doing things is that round(log2(romsize)) is a fixed constant forever. | 16:55 |
| rharper | alexbligh1: in general yes; but closing a CVE vs. not fixing -- | 16:55 |
| rharper | and then there are cases of migration between hosts which don't have the same version of the package | 16:56 |
| rharper | which can trip it up again (on soft-reboot post migration) | 16:56 |
| rharper | it's a non-trivial problem | 16:56 |
| alexbligh1 | rharper, re CVEs, sure, but none of them on Redhat has yet changed romsize across a power of 2 (AIUI). And re different versions, agree, which is why I said we may need to ship 'old roms', unless we are content for soft-reboot to fail potentially (though TBH why qemu reloads roms on soft reboot rather than using migrated rom data I don't know). | 16:57 |
| rharper | where are you going to put the migrated rom ? | 16:58 |
| rharper | there's no versioning of the actual rom file, nor a place to write it out to keep it around on a per-guest basis; | 16:58 |
| alexbligh1 | rharper, on /soft/ reboot, the qemu-kvm process won't even stop will it, so it could just stay in (host) RAM if it was migrated across. On /hard/ reboot, obviously qemu-kvm stops, and a new ROM will be loaded from disk. If it's larger, then the ROM size will grow and the memory map will change; if it's smaller it should work loaded into a larger slot. | 17:00 |
| rharper | alexbligh1: w.r.t soft reset reloading roms from disk, that's expected behavior, ala hitting reset on real hardware; what's happening though is that the underlying machine/hardware has changed | 17:00 |
| cjwatson | doko: any chance of sorting out an MIR for python-service-identity? python-twisted-core depends on it now, blocks e.g. apport build | 17:01 |
| rharper | alexbligh1: I forget where this ended, but even pushing the rom from the remote (which still could be a mismatch from the running process) and having the target write out those roms doesn't seem like a good idea; though it's been a while since I've walked through all of the steps and cases | 17:03 |
| alexbligh1 | rharper, I suspect it's pretty hard to get something that will work reliably in every scenario across reboot. However, I figure that reboot means the VM has no live data in, so a live migrate that simply provides different hardware across a reboot (perhaps you need to do a hard reboot instead) is still a huge step forward from 'I can't migrate my vm at all'. | 17:04 |
| alexbligh1 | rharper, and changing the way ROMs are dealt with on migration would be hugely invasive compared with what I'm proposing anyway. | 17:05 |
| rharper | alexbligh1: rom migration is a separate issue (though somewhat related via migration protocol); | 17:05 |
| smoser | xnox, thanks for your help. the cloud image now has systemd in it. and tomorrow should have cloud-init systemd units | 17:06 |
| rharper | alexbligh1: if we can do a bit more confirmation that all we're fixing is misadvertised migration data; I think the approach is reasonable; but since the guest ultimately has to be rebooted I still find the live migration to be less than ideal; | 17:07 |
| rharper | s/rebooted/restarted as a new machine type; | 17:07 |
| alexbligh1 | rharper, that (your bit starting 'but') is fair comment. Though for my own use I don't need it to survive a reboot, I /think/ all you need to do to make it survive a reboot is copy the Precise cirrus ROM file over and start with the appropriate command line. I'll check that over the weekend. | 17:09 |
| alexbligh1 | rharper, that was I think behaving differently on qemu-2.0.0-rc2 (as shipped on 14.04) and qemu-2.0.0 from git. I need to check why. | 17:10 |
| rharper | alexbligh1: yes, I think that'd do it; might be "fun" to get libvirt to talk two qemu installs and paths; but that should suffice for rom related reboot issues. | 17:11 |
| alexbligh1 | rharper, and if we wanted to, we could always ship the Precise ROM on trusty with some other filename (yes, I know it's disgusting) | 17:11 |
| rharper | alexbligh1: yes, and specify the rom in the xml | 17:12 |
| alexbligh1 | rharper, you are in libvirt land now so I shall pretend I don't know what you are talking about :-) (yes, I think so) | 17:12 |
| rharper | this slowly creeps into the rom versioning/signatures and compat for migration; | 17:12 |
| rharper | alexbligh1: you can specify the path to the romfile for any of the devices that take one | 17:13 |
| rharper | that's all | 17:13 |
| alexbligh1 | rharper, yep. Just an automated way of getting onto the qemu command line. | 17:13 |
| rharper | s/automated/massively complicated | 17:15 |
| alexbligh1 | rharper, I shall refer the honorable gentleman to the reply I gave earlier regarding not using libvirt :-) | 17:15 |
| rharper | =) | 17:16 |
| doko | cjwatson, yep, should do that ... will try on the weekend | 17:16 |
| === citlivka is now known as crack_fox | ||
| arges | hallyn: does bug 1348551 need to be fixed for utopic as well? | 17:58 |
| ubottu | bug 1348551 in qemu (Ubuntu) "qemu-kvm upstart configuration from qemu-system-x86 relies on binary from qemu-kvm" [High,Triaged] https://launchpad.net/bugs/1348551 | 17:59 |
| hallyn | arges: uh, isn't it? | 18:00 |
| hallyn | i pushed that fix this morning | 18:00 |
| arges | hallyn: i was just looking at the bug status, i'll look | 18:00 |
| hallyn | arges: thanks - it's possible i messed up. <ahem> unlikely of course | 18:01 |
| arges | does 2.0.0+dfsg-6ubuntu2 have the fix? | 18:01 |
| hallyn | yeah | 18:02 |
| sarnold | Trevinho: 1348668 :) | 18:02 |
| arges | hallyn: looks like it has some issues | 18:02 |
| arges | http://people.canonical.com/~ubuntu-archive/testing/utopic-proposed_probs.html | 18:02 |
| hallyn | slangasek: just pushed a new cgmanager to mentors. Would you mind taking a look? | 18:02 |
| arges | search for qemu on that page | 18:02 |
| hallyn | xnox: https://github.com/CameronNemo/cgmanager/commit/b809c1958e843de99b470a03d5c2dabdeb64d747 so should i merge that? I couldnt' quite follow the conversation | 18:03 |
| hallyn | arges: so how did -1 build? that didnt' change at all | 18:04 |
| arges | hallyn: i'm not entirely sure, may need to ask an AA what the issue is | 18:04 |
| hallyn | yeah. thanks for pointing it out. | 18:05 |
| arges | np | 18:06 |
| hallyn | cjwatson: ^ latest qemu upload is saying: E: Package 'qemu-user' has no installation candidate | 18:06 |
| hallyn | but debian/control isn't changed from teh last (successfully built) package | 18:06 |
| achiang | hallyn: hey, i'm trying to create a chroot whilst inside a container, but getting permission errors... | 18:23 |
| achiang | lxc.mount.entry = /var/lib/schroot var/lib/schroot none bind,optional,create=dir | 18:23 |
| achiang | ^^ that is in my config file, of how the schroot directory gets bind mounted into my lxc container | 18:23 |
| hallyn | and that succeeds? | 18:23 |
| achiang | hallyn: and inside the container, i am running with sudo, but still seeing a permissions error | 18:23 |
| achiang | PermissionError: [Errno 13] Permission denied: '/var/lib/schroot/chroots/click-ubuntu-sdk-14.10-armhf' | 18:23 |
| hallyn | achiang: what syscall is getting the eperm? | 18:24 |
| achiang | hallyn: mkdir | 18:25 |
| achiang | http://pastebin.ubuntu.com/7858012/ | 18:25 |
| hallyn | achiang: can you sudo mkdir /var/lib/schroot/chroots/click-ubuntu-sdk-14.10-armhf by hand? | 18:27 |
| hallyn | (I can...) | 18:27 |
| achiang | hallyn: i can't... so i'm suspecting pilot error on my part | 18:28 |
| achiang | hallyn: is it something weird with my bind mount? | 18:28 |
| hallyn | could be, lemme try | 18:28 |
| hallyn | hm, yeah, i can mkdir there | 18:29 |
| hallyn | (i bind-mounted /mnt to /var/lib/schroot) | 18:29 |
| hallyn | achiang: can you try subsituting /mnt for /var/lib/schroot in the lxc.mount.entry mount source? | 18:30 |
| achiang | hallyn: this is my new lxc mount entry: lxc.mount.entry = /mnt var/lib/schroot none bind,optional,create=dir | 18:33 |
| achiang | hallyn: and i'm still getting permission denied? i stopped and restarted the container | 18:33 |
| achiang | $ sudo mkdir -p /var/lib/schroot/chroots/click-ubuntu-sdk-14.10-armhf | 18:33 |
| achiang | mkdir: cannot create directory ‘/var/lib/schroot/chroots’: Permission denied | 18:33 |
| slangasek | hallyn: cgmanager> pulling | 18:33 |
| slangasek | hallyn: btw, do you want to VCS this thing somewhere so we don't have to shuttle source packages around? :) | 18:34 |
| hallyn | slangasek: hm, yeah. how do i create a tree at the debian git server? | 18:34 |
| hallyn | (so that when they take the pkg from me they can just take over the tree rahter than have to cloen my github tree :) | 18:35 |
| hallyn | achiang: please pastebin /proc/self/status, /proc/self/attr/current, /proc/self/uid_map | 18:35 |
| slangasek | hallyn: if you have an alioth account, you should be able to create something under the collab-maint tree; otherwise you can request a new project be set up if you want only explicitly approved people to be able to commit | 18:37 |
| achiang | hallyn: http://pastebin.ubuntu.com/7858087/ | 18:37 |
| hallyn | slangasek: I do have an account; I'll look into it | 18:37 |
| achiang | hallyn: my apparmor config outside the container needs to be fixed, i think is the problem | 18:52 |
| achiang | hallyn: looking into it now | 18:52 |
| hallyn | ok | 18:53 |
| achiang | hallyn: hm, even with this on my host, i still can't mkdir - http://pastebin.ubuntu.com/7858279/ | 19:06 |
| hallyn | achiang: what if you just use unconfined? | 19:07 |
| achiang | hallyn: let me try | 19:07 |
| achiang | hallyn: even that fails. very strange | 19:08 |
| achiang | $ cat .local/share/lxc/ubuntu-sdk/config | grep unconfined | 19:09 |
| achiang | lxc.aa_profile = unconfined | 19:09 |
| hallyn | slangasek: can't find an option to create a tree. i'll just push to github for now | 19:10 |
| hallyn | achiang: the mkdir is not done inside a chroot, right? that' s just in the container? | 19:11 |
| hallyn | you can do that mkdir on the host? | 19:12 |
| achiang | hallyn: yes, just in the container | 19:12 |
| achiang | hallyn: let me test on host | 19:12 |
| achiang | hallyn: yes, works on host | 19:12 |
| hallyn | slangasek: pushed to github.com/cgmanager/cgmanager-debian | 19:14 |
| hallyn | achiang: and then you *see* it in the container? | 19:14 |
| achiang | hallyn: yep | 19:14 |
| hallyn | does getfacl show anything funky for that contaienr? | 19:14 |
| hallyn | uh, that dir | 19:15 |
| hallyn | (the parent dir) | 19:15 |
| hallyn | and, to be sure, 'strace -f mdir /var/lib/schroot/chroots/click-ubuntu-sdk-14.10-armhf' shows that it's the final mkdir that is failing? | 19:15 |
| achiang | hallyn: i think so? http://pastebin.ubuntu.com/7858373/ see line 90 | 19:18 |
| achiang | hallyn: oh. maybe it has something to do with 777 perms? | 19:18 |
| achiang | well... that was from the command line so perhaps unrelated | 19:19 |
| hallyn | achiang: hold on. do you have lxc.id_map in the container config? | 19:20 |
| hallyn | i was beign silly, | 19:21 |
| achiang | mmm... yes i have that | 19:21 |
| hallyn | I think it's bc nobody is not mapped in | 19:21 |
| achiang | http://pastebin.ubuntu.com/7858405/ | 19:21 |
| achiang | ah | 19:21 |
| hallyn | add one more # to the last range | 19:21 |
| hallyn | you need 64536 I think to hit what userspace calls 'nobody' | 19:22 |
| achiang | really? | 19:22 |
| achiang | $ grep nobody /etc/passwd | 19:22 |
| achiang | nobody:x:65534:65534:nobody:/nonexistent:/usr/sbin/nologin | 19:22 |
| hallyn | hm | 19:23 |
| achiang | oh wait | 19:23 |
| achiang | my map goes to 64* | 19:23 |
| achiang | not 65* | 19:23 |
| achiang | duh | 19:23 |
| hallyn | no, bc you start at 1001 | 19:23 |
| achiang | interesting | 19:24 |
| hallyn | so when you ls -dl /var/lib/schroot/chroots in the container, what do you see exactly? | 19:25 |
| achiang | ubuntu@ubuntu-sdk:~$ ls -dl /var/lib/schroot/chroots/ | 19:25 |
| achiang | drwxr-xr-x 5 nobody nogroup 4096 Jul 25 19:16 /var/lib/schroot/chroots/ | 19:25 |
| hallyn | hm | 19:26 |
| slangasek | hallyn: please don't use debian-only git repos :( | 19:27 |
| achiang | making that change of 64536 didn't help | 19:27 |
| slangasek | hallyn: this git repo shows no upstream history | 19:27 |
| hallyn | slangasek: correct, was intended as a packaging tree only | 19:28 |
| slangasek | hallyn: yeah, those are horrible | 19:28 |
| slangasek | :) | 19:28 |
| hallyn | next week stgraber will teach me how to do that dpkg-git thing (or whatever it is) | 19:28 |
| slangasek | hallyn: meanwhile, 0.28-2 uploaded | 19:28 |
| hallyn | thanks | 19:30 |
| hallyn | achiang: what fs is your $HOME? | 19:31 |
| achiang | hallyn: uh. default? ext4 i'm pretty sure | 19:31 |
| achiang | /dev/sda1 on / type ext4 (rw,errors=remount-ro) | 19:32 |
| achiang | hallyn: i think i'm just going to give up for now, and wait until next week. a newer version of the click tool will appear in a PPA i need and i can create the directory outside the container | 19:38 |
| hallyn | achiang: fwiw i can reproduce it here. | 19:45 |
| achiang | hallyn: ah, interesting | 19:46 |
| hallyn | sarnold: hey, are you around, got a sec? | 20:03 |
| hallyn | hm, nm, my observations were tainted | 20:09 |
| hallyn | back to the kernel sources | 20:09 |
| hallyn | achiang: so the workaround really is to chown it to something other than nobody:nogroup | 20:11 |
| hallyn | i'm not sure if this is some awfully handled special-case in kernel, but it shouldn't be. | 20:11 |
| smoser | pitti, if / when you come around, bug and fix at bug 1348749 | 20:22 |
| ubottu | bug 1348749 in autopkgtest (Ubuntu) "autopkgtest fails sometimes with adt-virt-lxc" [Medium,Triaged] https://launchpad.net/bugs/1348749 | 20:22 |
| achiang | hallyn: that seems... weird | 20:23 |
| === timrc is now known as timrc-afk | ||
| hallyn | achiang: d'oh, i wasn't thinking | 20:33 |
| hallyn | achiang: inside your container there is a 65534 uid defined, mapped to some high uid. but 65534 on the host is not mapped into the container! | 20:34 |
| hallyn | and you're not allowed to map it | 20:34 |
| hallyn | so you simply must chown /var/lib/schroot/chroots to your own uid | 20:34 |
| hallyn | (:gid) | 20:34 |
| hallyn | or to some other uid mapped into your container | 20:34 |
| hallyn | now i feel silly :) | 20:35 |
| achiang | hallyn: why can't i map 65534 from host into container? | 20:36 |
| achiang | hallyn: on my host, /var/lib/schroot/chroots is owned by root. i don't think i really want to make that owned by my normal uid/gid? | 20:37 |
| hallyn | achiang: well, you *can*, you can add it to /etc/subuid and /etc/subgid | 20:40 |
| hallyn | i.e. i added | 20:40 |
| hallyn | serge:65534:1 | 20:40 |
| hallyn | then to the container config i added | 20:40 |
| hallyn | lxc.id_map = u 100002 65534 1 | 20:40 |
| hallyn | then i'm able to do it | 20:40 |
| achiang | hm... i did this step earlier: | 20:41 |
| achiang | # Assign UIDs/GIDs to your user for use by the container | 20:41 |
| achiang | $ sudo usermod --add-subuids 100000-165536 $USER | 20:41 |
| achiang | $ sudo usermod --add-subgids 100000-165536 $USER | 20:41 |
| achiang | i would have thought that should have been inclusive of 65534 | 20:42 |
| hallyn | how? :) | 20:42 |
| hallyn | arges: oh, I see, the last version of qemu was never released! qemu-user-binfmts is a new package | 20:42 |
| hallyn | infinity: ^ can you take a look at the new qemu package for utopic? It inherited some new binary packages from debian... dunno if I need to open a certain kind of bug in relation to those | 20:43 |
| hallyn | achiang: 100000-165536 does not include 65534... | 20:43 |
| achiang | um, right. i am dumb | 20:44 |
| hallyn | heh, i got lost in the same layer | 20:44 |
| hallyn | so i'll take the dunce cap | 20:44 |
| achiang | i must be honest, i am reading the subuid man page now and not sure i grok it | 20:45 |
| === timrc-afk is now known as timrc | ||
| hallyn | achiang: what's the question? | 20:48 |
| achiang | what is the 3rd field, 'count' ? | 20:49 |
| hallyn | "subordinate user id" is subuid, which is a uid on the host (not in teh container) | 20:49 |
| achiang | it's like, "goes up to" ? | 20:49 |
| achiang | starting from 2nd field? | 20:49 |
| hallyn | it's how big a range to map. so if subuid is 20, and count is 5, then it's 20-24 | 20:49 |
| achiang | ok | 20:49 |
| hallyn | so, you can pick any ids you want inside the container, but outside the container by default you can only map your own uid | 20:50 |
| hallyn | the subuids tell the setuid-root newuidmap and newgidmap programs to let you map other uids on the host | 20:50 |
| achiang | hallyn: i am feeling extra dumb today | 20:54 |
| achiang | i have this in my config: | 20:54 |
| achiang | lxc.id_map = u 100002 65534 1 | 20:54 |
| achiang | lxc.id_map = g 100002 65534 1 | 20:54 |
| achiang | and this in both /etc/subuid|subgid - achiang:65534:1 | 20:55 |
| achiang | still not able to do that sudo mkdir | 20:55 |
| hallyn | achiang: yes you still need to add the lines to your config | 20:55 |
| hallyn | lxc.id_map = u 100002 65534 1 | 20:56 |
| hallyn | and same for 'g' | 20:56 |
| hallyn | oh wait | 20:56 |
| hallyn | yeah, that's right, i'm misreading | 20:56 |
| achiang | hallyn: i have those? :) | 20:56 |
| hallyn | can you pb your whole config? | 20:56 |
| achiang | http://pastebin.ubuntu.com/7859078/ | 20:57 |
| hallyn | achiang: what kernel are you on? | 20:58 |
| achiang | hallyn: host or container? | 20:59 |
| achiang | 3.13.0-32-generic #57-Ubuntu | 20:59 |
| achiang | same, i guess | 20:59 |
| hallyn | hm, now that all looks ok. | 21:02 |
| hallyn | achiang: when you ls -l /var/lib/schroot/chroots now, does it show 100002:100002 at least owning it? | 21:03 |
| hallyn | achiang: the waste of time before was because it was showing 'nobody:nogroup', but it meant the real, unmapped, uid/gid -1, not 65534, known through /etc/{passwd,group} as nobody:nogroup :) | 21:03 |
| hallyn | as for now, i dunno | 21:03 |
| achiang | hallyn: it still shows as nobody:nogroup | 21:04 |
| hallyn | achiang: what about ls -lnd /var/lib/schroot ? | 21:05 |
| hallyn | uh, /var/lib/schroot/chroots | 21:05 |
| achiang | $ ls -lnd /var/lib/schroot/chroots/ | 21:07 |
| achiang | drwxr-xr-x 5 65534 65534 4096 Jul 25 19:16 /var/lib/schroot/chroots/ | 21:07 |
| hallyn | is that in the container? | 21:07 |
| achiang | yes | 21:07 |
| achiang | outside the container it is root:root | 21:07 |
| hallyn | and 'sudo mkdir /var/lib/schroot/chroots/xxx' still fails? | 21:07 |
| hallyn | wait. root:root? | 21:08 |
| hallyn | how does that work? | 21:08 |
| achiang | hallyn: perhaps i should mention that i also have http://pastebin.ubuntu.com/7859183/ in ~/.config/lxc/default.conf | 21:08 |
| achiang | hallyn: yes, outside container, /var/lib/schroot/chroots is owned by root:root | 21:09 |
| hallyn | but that paste is not consistent with the full paste you last posted. | 21:10 |
| hallyn | I thought that /var/lib/schroot/ was owned by root:root, and the chroots subdir was owned by nobody:nogroup | 21:10 |
| hallyn | that's the situation I was addressing | 21:10 |
| hallyn | achiang: if this is still a problem on monday, let's perhaps get on a shared tmux and pound it out | 21:11 |
| achiang | hallyn: i have both a ~/.config/lxc/default.conf and a ~/.local/share/lxc/ubuntu-sdk/config | 21:12 |
| hallyn | .config/lxc/default.conf is not consulted at lxc-start | 21:12 |
| achiang | hallyn: but sure, we can wait for monday | 21:12 |
| achiang | thanks for all the help today | 21:13 |
| hallyn | achiang: what does ls -ldn /var/lib/schroot{,/chroots} show on the host one more time? | 21:13 |
| achiang | http://pastebin.ubuntu.com/7859212/ | 21:14 |
| hallyn | achiang: I'm really confused. did you NOT say before that nobody:nogroup owned one of those? | 21:14 |
| achiang | hallyn: perhaps i was confusing -- i *thought* i said nobody:nogroup owned those *inside* the container and it was root:root *outside* | 21:15 |
| hallyn | d'oh :) | 21:15 |
| hallyn | achiang: which was extra-confusing bc of the multiplexing of those names | 21:15 |
| hallyn | achiang: so yeah, that can't be helped | 21:15 |
| hallyn | unless you map host's 0 into the container, which sort of defeats the purpose | 21:16 |
| achiang | ok | 21:16 |
| hallyn | So I recommend creating a subdir which the container can own | 21:16 |
| achiang | ok... the alternative is to create the schroot outside the container | 21:16 |
| hallyn | yeah, which due to mknod eaccess may be easiest anyway | 21:17 |
| achiang | hallyn: thanks again and sorry for misleading you earler | 21:19 |
| hallyn | achiang: np, I think ls mislead me, not you :) A cautionary tale for next time | 21:21 |
| achiang | hallyn: heh. ok. gracious of you, but i think i should have been more clear too :) | 21:22 |
| sarnold | hallyn: did you get it sorted out? | 21:34 |
| hallyn | sarnold: yeah, thanks | 21:37 |
| hallyn | I got my host and nsuids mixed up | 21:37 |
| hallyn | please don't comment on "if I can't get it right how can I expect others to" :) | 21:37 |
| sarnold | hallyn: yikes, I'm glad you got that sorted while I was at lunch! ;) hehe | 21:37 |
| sarnold | hallyn: meh, it's friday afternoon. | 21:37 |
| hallyn | yeah, but so much unresolved junk | 21:38 |
| hallyn | sarnold: any updates on the periodic qcow corruption? You're still running old qemu to avoid it? | 21:44 |
| hallyn | jdstrand: ^ | 21:44 |
| jdstrand | hallyn: still running old qemu. I am still on trusty. is there something you want me to test? | 21:52 |
| jdstrand | hallyn: actually, if you say in the bug what you want me to do, I'll find time to do it | 21:52 |
| jdstrand | hallyn: I'm heading out atm | 21:53 |
| hallyn | jdstrand: no, was just wondering if you had any new info - dopnt' have anything new for you to try. | 21:55 |
| hallyn | actually next week i'll try it out on a thinkpad, there *have* been other thinkpad-only bugs in qemu :) | 21:55 |
| sarnold | hallyn: the most recent corruption I had was in saucy images, so I just deleted them prematurely and hoped I wouldn't miss them.. heh | 21:56 |
| sarnold | hallyn: but I've been doing auditing lately instead of updates, so I haven't used VMs as much the last month or two | 21:56 |
| hallyn | ok - thx. | 21:57 |
| hallyn | have a good weekend everyone. | 22:02 |
| sarnold | bye hallyn :) | 22:03 |
| hallyn | oh wait, seems i have another cgmanager init script bug to deal with first | 22:04 |
| === salem_ is now known as _salem | ||
| === timrc is now known as timrc-afk | ||
| === sarnold_ is now known as sarnold | ||
| === mnepton is now known as mneptok | ||
| === beisner- is now known as beisner | ||
| === freeflying__ is now known as freeflying | ||
| === ]reed[ is now known as [reed] | ||
| === Ursinha_ is now known as Ursinha | ||
| === tarpman_ is now known as tarpman | ||
| hallyn | whoever wants to take a look and is good with sysvinit scripts, https://github.com/cgmanager/cgmanager/commit/9647f5c36d73b14ddb925586af3e3affbafb762a is what i'm thinking of pushing to cgmanager debian to fix a slew of open bugs | 23:40 |
| hallyn | *mbiebl: ^ that would be for yours :) ) | 23:40 |
| mbiebl | just a few comments in general | 23:42 |
| mbiebl | if you use s-s-d --retry= you don't need any sleeps between stop and start | 23:42 |
| mbiebl | using retry is almost always a good idea | 23:43 |
| hallyn | (i need to run, but will do this and grab any other comments when I get back - thanks much) | 23:43 |
| mbiebl | and to check whether a process is already running | 23:43 |
| mbiebl | you can use start-stop-daemon --test | 23:44 |
| mbiebl | (with the same arguments as you'd use for the real s-s-d call) | 23:44 |
| mbiebl | I still don't quite get the logic regarding starting/stoping the cgproxy sysvinit script from cgmanager | 23:45 |
| mbiebl | that seems broken somehow | 23:45 |
| mbiebl | maybe under sysvinit using a singler init script is actually cleaner | 23:46 |
| mbiebl | single, even | 23:46 |
| mbiebl | calling "service" on another init script from within an init script is pretty meh | 23:48 |
| === cjohnston_ is now known as cjohnston | ||
| slangasek | "calling service"? I thought that was already fixed pre-upload | 23:56 |
| mbiebl | slangasek: was referring to https://github.com/cgmanager/cgmanager/commit/9647f5c36d73b14ddb925586af3e3affbafb762a | 23:57 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!