[00:46] 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:59] chrstphrchvz: my /boot/grub is currently 8M. I just cleaned up a dozen kernels just yesterday, pity :/ [01:02] sarnold, I'm almost certain kernels are in /boot, not /boot/grub… [01:03] 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.. === shuduo_afk is now known as shuduo === _salem is now known as salem_ [03:47] pitti: Howdy. Since systemd is on the agenda for utopic, is Dracut as well? (LP: #1109029, LP: #1266516) [03:47] Launchpad bug 1109029 in linux (Ubuntu) "Depend on linux-initramfs-tools" [Wishlist,Triaged] https://launchpad.net/bugs/1109029 [03:47] Launchpad bug 1266516 in console-setup (Ubuntu) "New version available upstream: 1.104" [Wishlist,Confirmed] https://launchpad.net/bugs/1266516 [03:48] Good morning [03:48] Got you first. ;) [03:48] 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:50] address-book-service | 0.1.1+14.10.20140715-0ubuntu2 | utopic/universe | source, amd64, arm64, armhf, i386, powerpc, ppc64el [03:50] slangasek: ^ I do see those in http://ddebs.ubuntu.com/pool/universe/a/address-book-service/ [03:50] slangasek: where do you see it missing? [03:51] Unit193: dracut hasn't been discussed so far [03:51] Pity, would be nice as an option. [03:51] 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:52] Unit193: I'd rather invest some work to boot without any initramfs at all [03:52] 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] pitti: For the basics, you'd need the alt depend and console-setup updated, but yeah, that's understandable too. === salem_ is now known as _salem [04:02] pitti: one interesting bit is, that dracut supports systemd natively [04:03] (FWIW, I've tried dracut in Ubuntu and Debian.) [04:03] 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] pitti: it's kinda cool having the journal log from even within the journal [04:03] i. e. it's just wasted boot time on all cloud installs and most desktop installs [04:04] many server installs certainly use LVM etc., but I also know a lot which don't [04:04] pitti: oh sure, I agree. initramfs-less boots are interesting [04:04] 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] ATM you have to go back to root=/dev/sda2 etc., which would be sad/wrong [04:05] 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] pitti: heh [04:05] I remember hhoyer posting some numbers [04:05] that an initramfs didn't actually slow down boot [04:06] on the contrary [04:42] infinity, ScottK: I'd appreciate a review/accepting the new postgresql microrelease SRUs (lucid/precise/trusty), if you have some time [04:42] slightly bigger debian/ diff this time as we had to drop some patches which are now obsolete/included upstream [04:43] but they only apply to running the tests during build time, and that's proven to work by, well, the packages building :) [04:53] michagogo: how far down my queue> um not sure at this point [04:53] hallyn: cgm> I don't think the ftp team will hate you for doing the thing they asked you to do ;) [04:54] pitti: address-book-service - well, 0.1.1+14.10.20140715-0ubuntu2 is the version I just uploaded, so... [04:55] slangasek: oh, you mean 0ubuntu1 wasn't there? [04:55] pitti: it wasn't in the index, at least [04:55] slangasek: well, this was only one in a range of things which could go wrong [04:56] 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] slangasek: this should be better now as I fetch the ddebs from the previous day 4 times now instead of 1 [04:57] perhaps I shuold also add a "day-before-yesterday" to re-fetch those too [04:58] slangasek: this wasn't an indexing problem btw, the actual .ddebs are/were missing [05:07] pitti: right, I couldn't see any reason index-wise that those particular ones would be missing [06:00] 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:05] lp 1280109 [06:05] Launchpad bug 1280109 in skype (Ubuntu) "Upgrade to Skype for Linux version 4.3.0.37" [Wishlist,Triaged] https://launchpad.net/bugs/1280109 [06:15] Unit193: thanks [07:01] cjwatson: finally finished :) enjoy [07:02] good morning [07:02] @pilot in === 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 [07:16] 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:17] (it's in universe) [07:19] Tribaal, yes - which one is it [07:19] dholbach: https://code.launchpad.net/~tribaal/ubuntu/utopic/ubumirror/1341523-upstream-release/+merge/226654 [07:20] thanks Tribaal [07:21] dholbach: welcome :) There's no real hurry - but I was worried the procedure I followed is correct :) [07:21] Tribaal, no, looks like you did everyting all right :) [07:21] dholbach: cool :) [07:24] Tribaal, would you mind if I change the version number to 0.4 instead of 0.4ubuntu1? [07:24] dholbach: oh not at all. I thought the ubuntu1 thing was required [07:24] dholbach: what's the rule? [07:24] Tribaal, adding "ubuntu" to the version number usually indicates "we imported this version from Debian, and added Ubuntu-local changes" [07:24] as the package is not in Debian, 0.4 sould be fine [07:24] dholbach: ahhh ok [07:25] dholbach: yeah then by all means :) [07:25] rock and roll :) [07:26] Tribaal, uploaded [07:26] dholbach: woot ) [07:26] dholbach: thanks! [07:27] anytime [07:27] dholbach: my first changes to ubuntu, believe it or not :) [07:27] (ubuntu itself) [07:27] champagne! :) [07:27] indeed :) [07:32] Has something happened to the arm64 and ppc builders? two different packages have chroot problems for me currently [07:36] Noskcaj_, does it look something like https://launchpadlibrarian.net/180706189/buildlog_ubuntu-utopic-i386.ubumirror_0.4_CHROOTWAIT.txt.gz? [07:37] it's a plymouth issue [07:37] (on ppc) [07:37] that's the issue on arm64 [07:40] xnox, do you know if anyone is working on the gnustep-base ftbfs? [07:51] 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:52] dholbach: hi. yeah, I've kind of fallen off the planet :/ [07:52] this would be doable [07:53] tumbleweed, how was your time off the planet? :) [07:53] * dholbach hugs tumbleweed [07:53] :) [07:53] rather busy. that work-life balance thing is hard [07:54] tumbleweed, do you have plans to make it a little less work in the next time? :) [07:55] 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:56] man, I cross my fingers for you! all the best! :) [07:56] thanks [08:06] zul, can you take a look at bug 1328693? [08:06] 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:26] mvo_: infinity: cjwatson: https://launchpad.net/ubuntu/+source/openwsman/2.4.7-0ubuntu2 not fun, i'm having malta flashbacks. [08:49] dholbach, what an efficiency! [08:49] thanks a lot! [08:50] now let's hope somebody fix the chroot problems [09:09] mvo_: That apt bug is breaking buildd chroot upgrades in utopic now too. \o/ [09:09] mvo_: https://launchpadlibrarian.net/180716365/buildlog_ubuntu-utopic-i386.indicator-messages_13.10.1%2B14.10.20140725-0ubuntu1_CHROOTWAIT.txt.gz [09:10] 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:12] * 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:31] sarnold: yay, thanks [09:36] erk, FTBFS galore due to CHROOTWAITs [09:37] hm, plymouth/mountall don't upgrade, but neither of those changed recently [09:37] pitti: see what infinity said just a few lines back [09:38] I'll mangle the chroots right now to work around it so people are unblocked. [09:38] cjwatson: ah, thanks; sorry, I just rebooted and didn't see scrollback [09:51] infinity: thanks [09:52] mvo_: Grab that chroot now before I replace it. :) [09:57] infinity: just downloaded it [10:01] infinity: Surely it gets a new LFA when you do. :-) [10:01] (But yeah, would be GCed eventually) [10:03] cjwatson: Right. [10:05] mvo_: FWIW, it needs -proposed enabled to fail. Probably the addition of the new "init" package. [10:06] mvo_: An upgrade from that tarball to current, then to -proposed, works fine. Straight from the tarball to proposed will fail. [10:06] (Thank god for the former data point, that's how I'll work around it for now) [10:06] infinity: If so, that won't be true for very much longer. New init-system-helpers is migrating to utopic now === doko__ is now known as doko [10:07] You have a bit longer because it'll need another publisher run after this one ... [10:07] cjwatson: Well, the new chroots are migrating to the librarian too. :) [10:07] Cool [10:08] 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] oh sorry, wrong paste [10:08] infinity: yeah, I can reproduce [10:08] doko, cjwatson http://paste.ubuntu.com/7854397/ [10:10] 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:11] Doesn't look like a toolchain problem [10:11] and why are you using ccache for package builds at all? [10:11] doko, helps a lot in speeding things up for local test builds [10:12] cjwatson, thanks, wasn't sure if it's a toolchain problem, or not [10:12] 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] (since that's basically the only google hit for "ccache-sbuild") [10:13] 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 === Sweetsha1k is now known as Sweetshark [10:13] cjwatson, we are usually following https://wiki.ubuntu.com/SimpleSbuild [10:14] cjwatson, but yeah, that points to the debian page [10:16] tvoss: OK, I think my answer is "when you figure out the problem please document it on the wiki" then :-) [10:16] cjwatson, yes, I got the script from there, and it worked until we switched to explicit gcc [10:23] LocutusOfBorg1, in 1348564 you seem to have attached the wrong diff [10:25] sorry [10:25] done now [10:26] elopio, does https://code.launchpad.net/~canonical-platform-qa/messaging-app/qmltests1/+merge/227661 need any action? [10:27] thanks LocutusOfBorg1 [10:27] pitti, jibel: is the autopkg test queue busy? wondering why the autopkg test for lava-server isn't run [10:28] doko, it ran but proposed-migration was stuck [10:29] doko, or more exactly it is running [10:29] thanks [10:30] sorry again dholbach, calling every file "debdiff" is a shame [10:30] :) [10:30] it's all right :) [10:30] LocutusOfBorg1, I'm adding the bug number to the changelog entry [10:33] thanks ;) === lubko is now known as citlivka === timrc-afk is now known as timrc [11:09] @pilot out === 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 [13:19] infinity: hi, this is not entirely trivial to debug, but it is definitely the init addition thats triggering the bug [13:20] 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 === tvoss|lunch is now known as tvoss [13:33] 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:48] 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:49] 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:51] 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] xnox: but shouldn't init also have an upstart alternative? [13:51] pitti: It does. [13:52] Pre-Depends: sysvinit-core | systemd-sysv | upstart [13:52] xnox: I see nothing "bad" about the init package being merged. [13:52] so, we only have upstart ATM [13:52] so that should be fine [13:52] xnox: Especially if the intent is to simplify and normalize dependencies. [13:52] pitti: we will not have sysvinit-core though. [13:52] xnox: So? [13:52] yeah [13:52] systemd-sysv at some point [13:53] 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] 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] xnox: So, it's harmless. [13:53] xnox: The transition won't be via that package in Debian either. [13:54] xnox: Anyhow, I see no reason to gratuitously diverge, the package is harmless. [13:54] 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:55] (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] infinity: it causes upstart to be pulled in, into more places than it used to be.. [13:55] xnox: It cause no harm, apt did. [13:55] why make upstart essential? [13:55] also it would need to be Multi-Arch:foreign, and it's not marked as such. [13:56] xnox: upstart is prio:required and transitively essential, where was it not being pulled in previously? [13:58] trying to work that bit out. I'm fuzzy on essential vs required. [13:58] 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] xnox: essential is "stuff you don't need to depend on". [14:02] but a chroot without an init is not broken. [14:03] xnox: It was likely wrong for us to *make* upstart part of that set, but it always has been. [14:03] yeah, nominally it was aimed at minimal. [14:04] 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] or it's my little world where i do $ apt-get remove upstart in chroots and watch it shrink. [14:04] also docker does that. [14:04] So, you type "yes, I know what I'm doing", and remove all the things that depend on it? Fair enough. [14:05] infinity: and, we will carry essential pointless packages for the sake of it? [14:05] You could still do that with this new package. [14:05] no, in trusty it doesn't ask me to type "yes, I know what I'm doing" [14:05] http://paste.ubuntu.com/7856047/ [14:06] xnox: Oh, no, you're right. It only makes you say that for essential, not required. [14:06] So, we could just drop the essential from this package, and otherwise leave it alone. [14:06] now, i will not be able to do so in utopic, since "init" is essential, and needs --force-remove-essential [14:06] infinity: ok, (a) drop essential (ubuntu-only) (b) mark it M-A:foreign (forward to debian) [14:07] I'd forward the first bit to Debian too. [14:07] sysvinit was never essential, same complaint there as here. [14:07] In fact, a bare Debian debootstrap has no init, while a bare Ubuntu does, they were always slimmer. [14:07] sbin/init that is, not the new package. :P [14:09] infinity: ok, can you nuke my init-helpers upload from utopic-proposed then? i will not bother fixing it. [14:09] infinity: and just send patches to debian for feedback. [14:11] xnox: Done. [14:30] 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] (newly essential) [14:31] huh? essential isn't closed. [14:31] note how libc6 isn't essential. [14:32] 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:33] 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] 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] infinity: at least that is now something to work with :) [14:33] cjwatson: i see. "isn't broken", sans bugs like "it breaks our apt each time" =) [14:34] but that's not because of the mere fact of an essential package pre-depending on non-essential packages. [14:34] xnox: A bug in apt doesn't make another package broken. [14:34] if it were, then our archive would have been broken for ten years. [14:34] apt-cache show util-linux [14:34] xnox: And this bug is exposed other places too, we need to fix it, not keep working around it. [14:34] for that matter, apt-cache show dpkg [14:35] yiikes. yeah. now i see it. horum. good luck mvo_ =) [14:36] (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] cjwatson: I keep waiting for libc7 to happen, just to prove the point. [14:37] i've never used computers with libc so name less than 6 =) [14:37] (kfreebsd notwithstanding) [14:37] I was about to say :) [14:38] You could have said "with a libc other than glibc2". ;) [14:38] Also, youngun. [14:38] libc5->libc6 was very painful. [14:38] oh, i remember that one [14:39] Is merge-o-matic known to be broken at the moment? [14:39] It was fine last I looked, and it should be mailing me if there are problems [14:39] It's generating buggy .src.tar.gz files (quilt patches applied, but no .pc directory) [14:39] eg. exim4 [14:39] Oh, that's just how it's always been I think [14:40] You probably just want to do such merges yourself [14:40] Or use http://people.canonical.com/~cjwatson/dpkg-quilt-setup to set up .pc [14:40] Ah - thanks. [14:40] We're mentoring new team members in #ubuntu-server, and everyone is hitting that. [14:41] I don't tend to use MoM much myself so didn't know about that. [14:41] Merges aren't a good thing for new people anyway, IMO. [14:42] I've been fighting against the notion that they're a sensible intro task for a long time now [14:42] We have a big pile of outstanding merges to do, and not enough people to do them :-/ [14:42] Yeah, but in general you need a fairly good understanding of packaging first. [14:43] 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] They seem to be doing a reasonable job of understanding the previous delta. [14:44] 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:45] (In cases where I can't do the merge in revision control, of course.) [14:50] 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:51] which we don't have, it looks. [15:02] jtaylor: Is there any reason we haven't yet synced new matplotlib from Debian? === psivaa-afk is now known as psivaa [15:16] pitti: ping [15:16] barry: ICMP command not implemented [15:17] barry: (TGIF) [15:26] do we have a version of http://people.canonical.com/~ubuntu-archive/nbs.html for -proposed? [15:27] barry was asking about zope.security promotion, which drops (NBS) python-zope.security-untrustedpython [15:27] but it's not there [15:30] 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] infinity: yeah, so I figured that http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#zope.security was due to NBS [15:31] but not seeing reverse deps anywhere is a bit inconvenient [15:31] "reverse-depends python-zope.security-untrustedpython" is good enough, but error prone (forgetting build deps, etc.) [15:31] anyway, I suppose britney doesn't want to promote it due to the NBS [15:31] pitti: reverse-depends -b? :) [15:31] even though the new package has a Provides: python-zope.security-untrustedpython [15:31] -b gives build-deps [15:32] yes, I know, still error prone :) [15:32] yeah ;) [15:32] so in theory the package shoudl be able to promote [15:32] Yeah, agreed, we should have a proposed one. [15:32] the provides is now in zope-untrustedpython [15:32] as the two rdepends are unversioned [15:32] pitti: If the new package has a provides, and nothing has versioned deps, we're good to go, remove away. [15:32] ack; just wanted to double-check my reasoning [15:33] pitti: Note that nbs.html doesn't handle that situation at all either, it would need the same manual checking. [15:33] pitti: It would tell you it was NBS, but unsafe to remove. [15:33] but list all deps [15:33] True, it does that. [15:33] barry: anyway, python-zope.security-untrustedpython removed [15:33] barry: so after the next publisher run, britney should stop whining [15:34] pitti: awesome, thanks. thanks too infinity [15:34] 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:35] 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] thanks infinity [15:35] infinity: also for untangling the chroots -- how did you LART them back into a working state, OOI? [15:35] 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:36] so i just want it consistent. i do need the libcgmangaer.la built before cgm [15:36] well, i supposei could have Makefile.am check if .libs/cgm exists, and if not run ./cgm [15:36] 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] pitti: But, if you're in that barfy situation, it also works to just do it twice. [15:37] pitti: ie: apt-get update ; apt-get dist-upgrade ; apt-get -f install ; apt-get dist-upgrade [15:37] heh, fun [15:38] leaves a stain of disappointment on the super cow powahs, though [15:44] 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:45] mvo_, is it a workaround to make the upgrade succeed or a fix to test ? [15:46] jibel: its a workaround for the upgrade, a by-product of my debugging, if it helps [15:46] jibel: if its too much trouble don't bother, its a 50:50 chance at this point [15:47] mvo_, no problem, I'll add this ppa [16:01] hallyn: looks correct. one needs to do $ make install, for proper binaries to be installed... [16:03] xnox: so jenkins is being weird by not having .libs/cgm ? [16:04] * hallyn is being hits by an old old bug https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=534964 :) [16:04] Debian bug 534964 in linux-2.6 "Please enable CONFIG_CGROUP_MEM_RES_CTLR" [Wishlist,Fixed] [16:04] the problem is it's nto mountable, but it shows up in /proc/cgroups. that's nto nice [16:04] hallyn: you shouldn't use .libs/cgm, looking more. one sec. [16:05] xnox: ./cgm does work, but it prefixes argv[0] with 'lt-'. [16:06] Well I suppose I can just hardcode the name as cgm :) simpler solution [16:06] use ./libtool --mode=execute [16:07] cjwatson: this is for running through help2man from Makefile though [16:07] ah [16:08] so i wasnt' thinking, simplest solution is probably just to fix up the argname inside cgm's usage statement itself [16:08] 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:09] hm [16:09] i did worry at first, but it seemed to be working out [16:11] xnox: still anything unclear after reading the email with the transition plan? [16:12] 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] hi [16:12] mbiebl: and we don't support sysvinit init, thus we'll need hard upstart -> systemd migration, when it's ready. [16:12] 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:13] or what method will allow me to find out? [16:13] melodie: rmadison gtk+3.0 [16:13] melodie: https://launchpad.net/ubuntu/+source/gtk+3.0 [16:13] xnox: I guess that needs to be figured out by the Ubuntu maintainers and means a debdiff for i-s-h [16:13] thanks! [16:14] xnox: i.e. no automerge anymore [16:14] cjohnston what is rmadison? [16:15] 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] hence no prior need for "sysvinit" package per se [16:16] yeah, I can understand that the init package is not really interesting for ubuntu [16:16] melodie: man rmadison [16:16] melodie: (it's in devscripts) [16:16] ah! I was wondering how to install it, thanks [16:16] and actually harmful as it is [16:16] mbiebl: that's the conclusion i came to, but infinity believe it's harmless. [16:17] mbiebl: out of the three packages listed, we only have upstart. so it doesn't seem to be harmful, just very pointless. [16:17] oh, you don't have the systemd-sysv package yet in utopic? [16:18] hey. i'm sure i'm doing something dumb. [16:18] mbiebl: nope, we are not ready yet. [16:18] but someone able to tell me what [16:18] xnox: ok, then yeah, it sounds like it shouldn't do any harm [16:18] http://paste.ubuntu.com/7857020/ [16:18] 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:19] sure [16:19] mbiebl: nothing of major importance, just like things like openstack. [16:19] :-) [16:19] could any of you guys upload a fix (https://bugs.launchpad.net/ubuntu/+source/parted/+bug/1333462) for me ? [16:19] Ubuntu bug 1333462 in parted (Ubuntu Precise) "Precise: Linux partitioning tools give GPT Linux partitions wrong type code" [Undecided,In progress] [16:20] full log at http://paste.ubuntu.com/7857090/ if helpful. [16:20] stgraber, or pitti ? [16:21] xnox: so out of curiosity, is the init script conversion being tracked somwhere? [16:22] hallyn: on ad-hoc basis atm. [16:22] hallyn, are you interested in a patch that allows for qemu / kvm live migration between Precise and Trusty? [16:23] alexbligh1: I am [16:23] hallyn, https://lists.nongnu.org/archive/html/qemu-devel/2014-07/msg03160.html & https://github.com/abligh/qemu/commit/dc5a04eb2a55ba5024726d2aae5a980315f3c885 [16:24] 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] hallyn, it adds a new machine type which matches qemu-kvm 1.0 (as opposed to qemu-1.0) [16:24] alexbligh1: Looks like it won't affect anything else, perfect. Does it actually work? [16:25] it chagnes vga size? (/me eyes glazing over) [16:25] 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] I don't think anyone used qxl in precise, so it would suffice for ubuntu without that [16:26] rharper: hey! [16:26] hallyn, vga ram size, yes. [16:26] rharper: ^ could you comment on that patch on the mailing list? It looks very nice to me... [16:26] hallyn, vga rom size is a different problem, caused by the size of the shipped roms changing. [16:26] alexbligh1: but you're able to migrate VMs from precise to trusty, despite that? [16:26] hallyn: looking [16:26] hallyn, rharper and it really could do with more eyes [16:27] hallyn, in a test environment on my laptop with the VMs that we produce, yes. [16:27] hallyn, If you send me a livemigrate to disk snapshot that doesn't work, I'll look at fixing them. [16:27] 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] hallyn, the complication is $work doesn't use libvirt. [16:28] in upstream, there was considerable effort to automate the generation of the migration structures automatically; [16:28] rharper, it's self-contained (i.e. a new machine type). So the worst that can happen is migration (still) fails. [16:28] no, it's worse [16:28] it'll succeed and you'll have data corruption [16:28] that's what I worry about [16:29] 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] rharper, unless I'm missing what you mean? [16:29] 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:30] we're attempting to resume "newer" devices with "older" machine state [16:30] that's risky [16:30] 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:32] 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:33] 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:36] 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] 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:37] yeah, I understand the challenges w.r.t consuming the unstable migration format; [16:37] 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:41] 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:44] 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:45] rharper, thanks; will do next time I ping the list - sounds of stones falling into wells so far [16:45] desrt: hey, are you back? [16:46] rharper, though fixing this way was bonzini's idea... [16:46] 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] 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] 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:47] alexbligh1: cool [16:47] alexbligh1: thanks! [16:47] 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]