| infinity | :( | 00:00 |
|---|---|---|
| sidi | Currently splitting a pretty insane package into multiarch. I'm separating my existing pkg into a bin package, a common package and a lib-0 / lib-dev multiarch package. the source package has scripts under /usr/lib/foobar.sh, and the binaries of that package hardcode a path to that lib | 00:03 |
| sidi | yes I could spend the entire night writing new patches instead of sleeping, but if this is going to my -common package (it's scripts after all), how can I write my rules to ensure that only the Multi-Arch: same packages have a / | 00:04 |
| sidi | have a usr/lib/ARCH/... libdir, and that the common package (with Multi-Arch: any) uses the usual usr/lib/... | 00:04 |
| sidi | or in other words, is /$(DEB_HOST_MULTIARCH) defined when Multi-Arch: is set to any? in that case my current LIBDIR := usr/lib/$(DEB_HOST_MULTIARCH) line in rules should do what I need, right? | 00:05 |
| infinity | DEB_HOST_MULTIARCH is always set. | 00:05 |
| infinity | But installing foobar.sh to LIBDIR is wrong anyway, it should be LIBEXECDIR | 00:06 |
| infinity | Which may or may not be the same thing, depending on platform. | 00:06 |
| slangasek | ... if you are building with dpkg-buildpackage it is always set. Since policy allows you to build by calling ./debian/rules build, you should be setting it in your makefile with DEB_HOST_MULTIARCH ?= $(shell dpkg-architecture -qDEB_HOST_MULTIARCH). | 00:07 |
| slangasek | where "your makefile" == "debian/rules" | 00:07 |
| infinity | It's always set for dh(1) targets, isn't it? | 00:07 |
| slangasek | infinity: yes, that also | 00:07 |
| slangasek | with the proper compat level etc etc | 00:08 |
| infinity | sidi: Anyhow, LIBDIR and LIBEXECDIR are different for a reason. They may often be the same on, say, RedHat, but they differ on Debian, and differ wildly on BSD (where /usr/libexec is a thing), so yeah. Callable programs don't live in LIBDIR. | 00:09 |
| infinity | sidi: That one might take an upstream patch to fix, but it's also The Right Thing To Do. | 00:09 |
| sidi | aw | 00:11 |
| sidi | infinity, the thing is this goes into a PPA and my main concern is that I need the fix pushed asap to my study participants so I can stop throwing money out of the window :-) and all of these packages get burnt to the ground the second I don't need them... | 00:11 |
| infinity | And yet, you're spending time trying to figure out how to multiarch it... | 00:12 |
| sidi | the original package is firejail. the upstream app doesnt respect any conventions for build chains, and the existing package doesnt have patches to use libexec instead of lib | 00:12 |
| slangasek | yes, ironically multiarching the world had the side effect of undoing the FHS's attempted merge of libdir and libexecdir | 00:12 |
| sidi | if i try to do the right thing i probably lose one or two weeks | 00:12 |
| sidi | infinity, yes because it makes other packages uninstallable | 00:12 |
| sidi | i have some existing multiarch libs in my PPA that now depend on this package's actual .so libraries (as part of my research). I need to split those from the rest | 00:13 |
| sidi | Also this is a Linux only package for the matter :-) It's based on Linux namespaces | 00:13 |
| sidi | knowing this, what would be the least resistance path for me? should i just move all those .sh files to /usr/share/ or something, patch the package's binaries' hard coded paths and go to bed? | 00:14 |
| infinity | sidi: Well, there's no rule that you have to keep the paths that "make install" gives you. :P | 00:15 |
| infinity | sidi: Just move things around a bit after dh_auto_install | 00:15 |
| sidi | if i change the paths i need to patch the original app :-) it somehow expects those .sh files in /usr/lib, sadly | 00:15 |
| infinity | Yes... | 00:15 |
| infinity | So, keep the .sh files there. They belong there. | 00:16 |
| infinity | And put the libraries in the multiarch paths. | 00:16 |
| infinity | And you win. | 00:16 |
| infinity | You don't have to accept where the upstream makefile puts things as final. | 00:16 |
| sidi | infinity, right so I need to ensure the Makefile uses libdir only for actual .so libraries | 00:16 |
| sidi | and patch the makefile and voila? | 00:16 |
| infinity | No. | 00:16 |
| infinity | Just install with libdir=multiarch as you were, then mv multiarch/firefail/fshaper.sh to usr/lib | 00:17 |
| Unit193 | Hah, nice typo. | 00:18 |
| infinity | Or do so with a .install file, which I assume you already have for your package split. | 00:18 |
| infinity | Unit193: Freudian. | 00:18 |
| sidi | Unit193, wait what? :p | 00:20 |
| sidi | infinity, alright, let me type this all up and check if it works. im writing the install files right now. well. i'm trying to guess what should be in there from other packages | 00:20 |
| infinity | install -c -m 0755 src/ftee/ftee $(DESTDIR)/$(libdir)/firejail/. | 00:22 |
| infinity | install -c -m 0755 src/fshaper/fshaper.sh $(DESTDIR)/$(libdir)/firejail/. | 00:22 |
| infinity | Looks like those are the two that need special treatment. | 00:22 |
| infinity | sidi: Note that the configure script does know what libexecdir means, so you could also fix it in the upstream Makefile.in with libexecdir=@libexecdir@ and twiddling those two lines. | 00:24 |
| infinity | YMMV, have fun, etc. | 00:24 |
| * infinity deletes the source before he's tempted to do the work. | 00:25 | |
| sidi | infinity, thanks | 00:25 |
| sidi | infinity, you would be wasting your time anyway :-) my fork has an extra libraries on top of the existing mess :-) | 00:25 |
| smoser | hey, if anyone wants to look at bug 1575572 i'd appreciate it. basically init-system-helpers is broken for installation of a package before systemd is entirely booted. | 00:53 |
| ubottu | bug 1575572 in init-system-helpers (Ubuntu) "apache2 fails to start if installed via cloud config (on Xenial)" [High,Confirmed] https://launchpad.net/bugs/1575572 | 00:53 |
| infinity | smoser: How is that not a cloud-init bug? Installing services and expecting them to start *while still booting* is a bit nutty. | 00:56 |
| smoser | it has worked since before lucid | 00:57 |
| infinity | Because pre-systemd, you probably ran in rc2 | 00:58 |
| infinity | Or you ran in rcS, and then apache started when you reached rc2. | 00:58 |
| smoser | no. apache started when it was installed like it should have. | 01:00 |
| infinity | Then you were running your install in rc2. | 01:00 |
| smoser | possibly. you're probably right that 'runlevel' would provide some actual useful output rather than 'unknown' | 01:01 |
| smoser | it doesnt seem that odd for a service to insall other packages and do so as it runs in boot. | 01:02 |
| smoser | puppet or chef probably do this. | 01:03 |
| infinity | They most certainly don't. | 01:03 |
| smoser | really? | 01:03 |
| infinity | They run a daemon post-boot that checks for sanity and reconciles desired system state. | 01:03 |
| smoser | when is 'post-boot' ? | 01:03 |
| infinity | At least puppet actually has a delay built in. | 01:04 |
| infinity | But it's tripped from cron, so at least cron needs to be running. | 01:04 |
| smoser | ah.. sleep 12 should cover it. | 01:04 |
| smoser | this coudl be tripped really by anthing | 01:05 |
| smoser | boot system | 01:05 |
| smoser | ssh starts | 01:05 |
| smoser | user sshes in | 01:05 |
| smoser | apt-get install package | 01:05 |
| === Wulf4 is now known as Wulf | ||
| smoser | user expects package is installed | 01:05 |
| smoser | but systemd isn't "finished" | 01:05 |
| smoser | s/ssh/logs in at console/ | 01:06 |
| infinity | In systemd parlance, though, it would be "systemctl is-system-running" that is interesting before going and doing apt/dpkg things, I'd say. | 01:06 |
| smoser | i think its a bug. this worked for at least 3 consecutive LTS releases, probaly worked in gutsy, but i dont really have the interest to check. | 01:09 |
| smoser | by your suggestion, installation of packages in rc.local would not be possible without some background and poll. | 01:09 |
| smoser | really seems broken. | 01:10 |
| infinity | Anyhow, if there's any bug there, it's that we're not starting apache after moving into rc2. Starting a service in an unknown system state is exactly what an init system is meant to prevent. | 01:10 |
| smoser | that is not entirely unreasonable. not entirely. | 01:11 |
| smoser | but it wont start after moving to rc2 because systemd calculates its dependencies and such one time | 01:11 |
| infinity | Today's painful lesson: Never type 'telinit 2' on a systemd system. | 01:18 |
| === fginther` is now known as fginther | ||
| === Wulf4 is now known as Wulf | ||
| xnox | infinity, hahahahahahaha | 02:22 |
| xnox | been there done that | 02:22 |
| === _unixpro1970 is now known as unixpro1970 | ||
| === unixpro1970 is now known as _unixpro1970 | ||
| === _unixpro1970 is now known as unixpro1970 | ||
| xnox | infinity, smoser - i fell disturbance of the force due to lack of $ systemctl daemon-reload in apache2.postinst | 02:23 |
| xnox | *feel | 02:24 |
| xnox | pitti, should packages that ship init scripts only, call systemctl daemon reload? | 02:24 |
| infinity | xnox: The systemd trigger covers that. | 02:48 |
| infinity | xnox: (So, that's not the problem here) | 02:49 |
| sarnold | is there any long-term plan to .. clean up after the N init systems at some point? | 02:49 |
| sarnold | there's a certain lack of elegance in having /etc/init/foo.conf /etc/init.d/foo.sh and .. uhh wherever it is that foo.unit files are stored. | 02:50 |
| infinity | sarnold: Once we no longer have any upstart sessions anywhere in any of our products, we can completely kill upstart. | 02:50 |
| infinity | sarnold: Keeping sysvinit for all things in Debian is likely going to continue forever. | 02:50 |
| infinity | Or, at least, a long time. | 02:50 |
| sarnold | infinity: well, that's something I guess. | 02:51 |
| dmick | anyone else got cjwatson-level install-fu, or cjwatson: so I understand most of what finish-install's 90-console does, except 1) who writes /var/run/console-device (kernel?)and 2) where does $rawconsole come from. (I think I got all the 500MB of pieces of debian-installer, but I can't find that string anywhere in it, where I'd expect it) | 02:59 |
| sarnold | zounds that was quick, I glanced over 90-console and had -zero- idea what it did :) | 03:00 |
| dmick | well, I am sort of in the middle of this problem :) | 03:00 |
| cyphermox | dmick: I can look it up | 03:00 |
| cyphermox | not nearly the semi-god install-fu of cjwatson, but installers are my thing ;) | 03:01 |
| dmick | I'm not even sure how it would be passed to this script; AIUI it's running as a postinstall during package installation, and it's surprising that something as specific as 'rawconsole' would be defined in its env, but I don't know how else it could get there | 03:02 |
| dmick | I suppose it's also possible it's just ab ug. | 03:02 |
| cyphermox | dmick: the best thing is probably for you to tell us exactly what is the problem you're trying to solve though | 03:03 |
| dmick | specifically, I started off trying to understand how /etc/init/ttySN.conf got written to enable getty on 'the console' SoL device | 03:03 |
| dmick | (which appears to match the console= given to the install kernel cmdline) | 03:03 |
| dmick | and really that's still the goal; the questions above are in service of that underlying question | 03:04 |
| dmick | (the reason is, we have provisioning code that was configuring this automatically that appears to no longer be necessary, but I'm unwilling to remove it without at least trying to understand why it's not necessary anymore) | 03:06 |
| infinity | dmick: It's not necessary because systemd doesn't statically configure gettys. | 03:07 |
| dmick | well yes but we're still provisioning trusty systems | 03:08 |
| infinity | Oh, we magically fixed in there too? ;) | 03:08 |
| dmick | but yeah, I caught the bit about systemd doing this now | 03:08 |
| infinity | What is your console device? | 03:08 |
| dmick | /dev/ttySn where n is 0, 1, or 2 depending on the platform | 03:08 |
| infinity | fwiw, rawconsole just looks like a bug. | 03:10 |
| dmick | I was starting to think that | 03:10 |
| dmick | a harmless one, no doubt | 03:10 |
| infinity | Quite. | 03:10 |
| cyphermox | unless it comes from some d-i C code that runs finish.d | 03:10 |
| infinity | As for your provisioning, if you're setting console on the commandline, it should Just Work. | 03:10 |
| infinity | There shouldn't be need to do anything manual. | 03:11 |
| dmick | it seems like it does | 03:11 |
| dmick | like I say, the question was "how", and cjwatson pointed me to this script, which held most of the answer | 03:11 |
| dmick | so now I'm just filling out the whole picture. any ideas about the origin of /var/run/console-device? | 03:11 |
| dmick | oh duh I hadn't grepped d-i yet | 03:12 |
| infinity | It's from rootskel. | 03:13 |
| dmick | yep | 03:13 |
| infinity | Which the finish-install changelog mentions. | 03:13 |
| cyphermox | there you go | 03:13 |
| dmick | reopen-console-linux, looks like | 03:13 |
| dmick | heh, and, amusingly, there's a "console_raw" in that script | 03:13 |
| dmick | wow. grepping for a kernel message | 03:14 |
| dmick | and then eventually what probably happens: grepping /proc/cmdline | 03:14 |
| dmick | awesome. | 03:14 |
| dmick | that feels right | 03:14 |
| infinity | dmick: The sketchy ringbuffer grepping is only on ancient kernels. We can probably tear all that out upstream now. | 03:16 |
| dmick | so this provisioning code originated as far back as oneiric, and I bet that either 1) at the time we weren't using the right console= options, or order, in the install boot, and/or 2) it was not quite as smart in those days. so we just hadn't noticed it was automatic now. | 03:16 |
| infinity | src/sbin/get-real-console-linux.c is still correct, though. | 03:16 |
| dmick | ah. nice info: /dev/console is magical | 03:17 |
| dmick | *awesome*. that's much more than I paid for. you guys are teh awesome | 03:20 |
| cyphermox | dmick: /dev/console is just whatever was last set as console= | 03:21 |
| cyphermox | (ie. if you set it multiple times on the cmdline, or it's some default based on the platform or something) | 03:21 |
| dmick | ...assuming all that other stuff in reopen-console-linux falls through, yes, looks like | 03:21 |
| dmick | oh sorry, you said /dev/console. ok. | 03:22 |
| dmick | right. and it's got its own maj/min, but the ioctl gets you the real one. on my desktop running X, it's tty7; on this headless machine I was looking at, it's .. wait for it... ttyS1, what a coincidence | 03:22 |
| dmick | that really nails home a lot of stuff I haven't fully understood for a long time; thanks | 03:23 |
| dmick | so it looks like the active branch of reopen-console-linux is likely the one that calls get-real-console-linux | 03:30 |
| lfaraone | Is the header for pages like http://releases.ubuntu.com/xenial/ maintained in some bzr branch somewhere I could submit a patch to? | 03:31 |
| dmick | cyphermox: infinity: really appreciate it. thanks a mil. | 03:40 |
| infinity | lfaraone: lp:ubuntu-cdimage | 03:47 |
| sarnold | "The Breezy Colony 5 release was".. oy vey :) | 03:49 |
| === unixpro1970 is now known as _unixpro1970 | ||
| cpaelzer | good morning | 04:51 |
| === NCommander is now known as mcasadevall | ||
| pitti | xnox: as Adam said | 06:01 |
| === _unixpro1970 is now known as unixpro1970 | ||
| === unixpro1970 is now known as _unixpro1970 | ||
| === _unixpro1970 is now known as unixpro1970 | ||
| Bluefoxicy | hilarious | 06:41 |
| Bluefoxicy | I upgraded from 14.04 to 15.10, and now I'm upgrading to 16.04 | 06:41 |
| Bluefoxicy | in the past several months, I never noticed that the upgrade kept the 3.16 kernel and never upgraded to 4.2. No 4.2 kernels installed under Wily. | 06:42 |
| pitti | Bluefoxicy: missing linux-generic metapackage? | 07:09 |
| Bluefoxicy | maybe | 07:11 |
| Bluefoxicy | it upgraded to 4.4 during do-release-update to 16.04 LTS | 07:11 |
| === athairus is now known as afkthairus | ||
| seb128 | could somebody from the SRU team look at gnome-software in the xenial queue? | 08:18 |
| pitti | seb128: ok, I'll do a round of sru processing | 08:20 |
| seb128 | pitti, thanks | 08:20 |
| seb128 | pitti, hey btw, wie gehts? still under snow? | 08:20 |
| pitti | ugh, I got that queue empty yesterday, lots of uploads since then :) | 08:20 |
| pitti | seb128: non, il y a du soleil à nouveau \o/ | 08:20 |
| pitti | seb128: mais il fait encore très froid, il n'y a qu'une degrée :/ | 08:21 |
| seb128 | pitti, c'est l'hiver... | 08:22 |
| pitti | en effet ! | 08:22 |
| pitti | les premières deux semaines d'avril était très bon | 08:22 |
| pitti | seb128: but I'm sure that next ween in Austin will be really warm :) | 08:22 |
| seb128 | pitti, what sprint is that? | 08:23 |
| pitti | seb128: cloud sprint | 08:23 |
| seb128 | oh ok | 08:23 |
| seb128 | have fun there! | 08:23 |
| pitti | merci ! | 08:23 |
| pitti | seb128: btw, reviewing syncs for SRUs is a royal pain; any chance that these can become proper uploads? | 08:32 |
| pitti | (fine for this one, but for the future) | 08:32 |
| seb128 | yes, I guess this one had no real reason to be a copy | 08:32 |
| seb128 | sorry about that | 08:32 |
| pitti | seb128: also needs uploading to yakkety | 08:35 |
| seb128 | pitti, ack | 08:38 |
| seb128 | pitti, can't we just pocket copy? we used to do that early in the cycle | 08:39 |
| pitti | seb128: I'd rather not; we have a big compiler change, a libpng and other lib transitions already | 08:39 |
| seb128 | k | 08:40 |
| pitti | and that's the kind of package that very well might link against libpng or libicu | 08:40 |
| seb128 | we are working on rebasing on 2.20.2 we might just upload that one | 08:40 |
| pitti | armhf test queue < 1000, yay | 08:50 |
| ginggs | hi pitti, can you let json-c's tests run against u1db 13.10-6.1build1 in -proposed please? | 09:00 |
| pitti | ginggs: I'll do a mass-retry of regressions as soon as the current backlog settles down | 09:00 |
| pitti | ginggs: one "normal" round and one against --all-proposed | 09:00 |
| pitti | to shake out the implicit/forgotten versioned dependencies | 09:01 |
| rbasak | xnox: are you planning SRUs for bug 1572613? | 10:05 |
| ubottu | bug 1572613 in gcc-mingw-w64 (Ubuntu) "GCC stack access scheduled after stack deallocation" [Wishlist,Triaged] https://launchpad.net/bugs/1572613 | 10:05 |
| rbasak | For MySQL, I'm expecting an SRU soon anyway. | 10:05 |
| xnox | rbasak, yes and no. | 10:12 |
| xnox | rbasak, so first there needs to be a gcc sru, and then rebuilds with fixed compiler. | 10:12 |
| xnox | rbasak, doko did say that he wants to sru gcc when 5.4 is out (or something like that) | 10:12 |
| xnox | and then i'll be looking into what needs fixing, and what "organically" fixes itself. | 10:13 |
| xnox | rbasak, it also matters where we upload the compiler to.... cause e.g. imho it should be in security pockt. | 10:13 |
| xnox | but i don't know what plan doko had for the gcc sru, and whether e.g. apw / arges will be annoyed if we do put the kernel into -security | 10:14 |
| xnox | (affects kernel builds for live patching) | 10:14 |
| apw | changing the compiler in a stable is always problematic, as i understand the world if we sru a compiler we | 10:25 |
| apw | have to consider it for the security pocket, so that kernels and dkms packages are built with the same compiler | 10:25 |
| apw | and we alwyas use the -security compiler for the main kernel | 10:26 |
| xnox | yeah, cause otherwise there lies madness | 10:26 |
| xnox | apw, with that compiler bug it is tricky, cause it was not trigger on the kernel sources.... so far... | 10:26 |
| xnox | but it could be =( | 10:27 |
| apw | xnox, i am not saying that we shouldn't update the ocmpiler, i am just saying i think it has to go | 10:27 |
| apw | to the security pocket if we do | 10:27 |
| xnox | quite for many reasons | 10:27 |
| xnox | apw, but i don't want to do security uploads =) i don't think i ever done one. So up to doko really =) | 10:28 |
| siretart | mvo: any chance you could upload the changes in your apt-btrfs-snapshot branch? Did you see my question to you in LP: #1454306? - can I help you with doing the upload for you? | 10:38 |
| ubottu | Launchpad bug 1454306 in apt-btrfs-snapshot (Ubuntu) "apt-btrfs-snapshot supported reports "Sorry, your system lacks support for the snapshot feature" since update of btrfs-tools to 4.0-2 in debian/testing" [High,Confirmed] https://launchpad.net/bugs/1454306 | 10:38 |
| ginggs | hi, gdcm ftbfs on amd64 only since yakkety (xenial was fine) while linking against libpapyrus3-dev (a static-only lib) "lib/libPapyrus3.a(PapyError3.c.o): relocation R_X86_64_32 against `.rodata.str1.8' can not be used when making a shared object; recompile with -fPIC". If I do a no-change rebuild of papyrus, then gdcm builds again on amd64. Does this make sense? If so, what should I put in papyrus' changelog? | 10:45 |
| pitti | ginggs: yakkety's gcc now defaults to -fPIE | 10:45 |
| pitti | ginggs: https://lists.ubuntu.com/archives/ubuntu-devel-announce/2016-April/001183.html | 10:46 |
| pitti | ginggs: not sure how to revert that, though; -fPIE can't work with static linking | 10:46 |
| pitti | so maybe it's a gcc bug that it uses PIE for .a too? | 10:46 |
| pitti | ginggs: also, static linking, *tsk* :0 | 10:47 |
| mvo | siretart: uh, I have not seen that. and help with the upload is very welcome, thanks a bunch for the offer! | 10:47 |
| ginggs | pitti: this doesn't affect ppc64el though | 10:47 |
| * pitti thought most libraries stopped shipping .a | 10:47 | |
| pitti | ginggs: right, it only was changed on amd64 | 10:47 |
| ginggs | so isn't rebuilding papyrus with new flags a good thing to do? | 10:49 |
| pitti | ginggs: yes, it should be, if you disable the -fPIE thing; but I'm not sure whether this is a bug in gcc or in papyrus | 10:49 |
| pitti | doko: ^? | 10:50 |
| ginggs | but papyrus and gdcm both build fine without disabling -fPIE | 10:50 |
| pitti | I thought you just said it doesn't | 10:50 |
| pitti | oh, with rebuilding both | 10:51 |
| ginggs | yeah | 10:51 |
| pitti | ginggs: hm, that almost sounds like the rebuild would build the .a with PIE | 10:51 |
| pitti | which is wrong AFAIK | 10:51 |
| ginggs | i can't think of a difference between building the .a with PIE and bundling the paprus source into gdcm and building the whole lot with PIE | 10:57 |
| ginggs | hmm, and it is lunchtime | 10:57 |
| siretart | mvo: in order to build the package, I had to disable the pep8 and pyflakes unit test - both fail. | 10:59 |
| siretart | mvo: please confirm that you are OK with me uploading a package that disables both tests to rakety | 10:59 |
| siretart | mvo: hm, fixing both tests was easy, I'll upload with those changes | 11:06 |
| rbasak | xnox: OK, thanks. Well just FYI then, when you're ready it might be worth checking if an SRU has already landed or I still have one planned. | 11:10 |
| xnox | rbasak, will do will do | 11:10 |
| doko | ginggs, pitti: yes, rebuilding should be fine | 11:16 |
| doko | sbeattie, ^^^ still missing your list of static libs to rebuild :-/ | 11:16 |
| pitti | doko: it's ok now to build static libs with -fPIE? (and apparently required now too)? | 11:17 |
| doko | pitti, if these are used to build binaries built with pie, yes | 11:18 |
| pitti | doko: ah ok, so that means in yakkety we'll rebuild all packages that ship an .a | 11:18 |
| ginggs | i think things will blow up if someone tries to link the .a into a .so | 11:18 |
| pitti | doko: thanks for the heads-up | 11:19 |
| doko | pitti, and no, we don't have infrastructure to build static libs fithout pie yet | 11:19 |
| pitti | ginggs: well, .so were always supposed to be PIC/PIE, no? | 11:19 |
| ginggs | pitti: i thought PIC yes, PIE no | 11:20 |
| ginggs | but i don't know for sure | 11:21 |
| pitti | ginggs: I keep confusing the two, I keep thinking of them as the same | 11:21 |
| pitti | xnox, seb128, slangasek: should we talk about un-upstartifying the desktop session next week at UDS? | 12:33 |
| xnox | pitti, that would be good | 12:34 |
| pitti | we haven't had an upstart maintainer for a long time any more, and we're already having trouble finding someone who keeps it buildable | 12:34 |
| pitti | seb128, xnox: also sounds like a nice topic for a mini-sprint | 12:34 |
| seb128 | +1 | 12:34 |
| seb128 | is any distribution using systemd for user sessions nowadays? | 12:34 |
| pitti | seb128: unknown, but I figure most of them use good old gnome-session | 12:35 |
| seb128 | right | 12:35 |
| pitti | and I'm sure we can at least replace some of them with dbus activation | 12:35 |
| Laney | desrt says not | 12:35 |
| Laney | i.e. someone should work on this :-) | 12:35 |
| xnox | seb128, as far as i know we are the only ones to have an init for a user session at all. | 12:36 |
| pitti | so for example, unity-settings-daemon both has an xdg autostart and an upstart session job | 12:36 |
| xnox | seb128, yolla kind of uses systemd, but it's single-user / system systemd, with many weird patches | 12:36 |
| pitti | xnox: no, the user systemd unit runs pretty much everywhere, just nobody uses it for distro things yet | 12:36 |
| xnox | pitti, yeah, i was keeping xdg autostart for systemd-xdg-autostart generator (not upstream) | 12:36 |
| xnox | pitti, so folks at intel have demostrated full user systemd session with like even "start xfce.target" after a "start gnome.target" with gnome tearing down, xfce coming up with applications staying in place | 12:37 |
| xnox | very scary but totally usable | 12:38 |
| xnox | but none of that shipped anywhere. | 12:38 |
| mapreri | in lp #1574745 can i have a xenial task instead of a milestone in the main task, so that yakkety can be fixed separately? | 12:38 |
| ubottu | Launchpad bug 1574745 in libreoffice-dictionaries (Ubuntu) "Missing symlinks to match locales" [High,Confirmed] https://launchpad.net/bugs/1574745 | 12:38 |
| xnox | pitti, seb128 - but it would probably mean we need user dbus1, upgraded dbus1, and work out the kinks if we can use that. | 12:38 |
| xnox | as there is no support of multiple systemd user sessions per user, like we currently have in upstart | 12:38 |
| xnox | pitti, seb128 anyway, yes we should talk, and i should go to the airport soon. | 12:39 |
| seb128 | is multiple-sessions-for-one-users something we support? | 12:39 |
| pitti | ok, let me create a blueprint/UDS discussion about that | 12:39 |
| pitti | xnox: oh, already? | 12:39 |
| * pitti leaves on Sunday | 12:39 | |
| seb128 | xnox, safe flight | 12:39 |
| xnox | pitti, i had a holiday from thrusday - monday, which i had to cut short, so i'm going to austin from budapest on sunday | 12:40 |
| === _salem is now known as salem_ | ||
| xnox | and hence wasted money on a non-refundable flight from budapest to london, and one night of hotel. | 12:40 |
| pitti | https://blueprints.launchpad.net/ubuntu/+spec/desktop-y-replace-upstart | 12:45 |
| pitti | ah, I feel my lost TB powers already, I can't ack this for UOS any more nor for yakkety (only propose) | 12:46 |
| pitti | dholbach: do you see this ^ on https://blueprints.launchpad.net/sprints/uos-1605 ? I apparently can't see proposed topics any more | 12:47 |
| dholbach | pitti, accepted | 12:49 |
| pitti | dholbach: danke | 12:49 |
| pitti | dholbach: wow, this really is the first BP for UOS | 12:50 |
| dholbach | some folks filed "meetings" in summit directly | 12:50 |
| doko | yofel, please could you sync/merge digikam? | 13:14 |
| yofel | doko: sure... until when do you need it? (that's not a small thing) | 13:15 |
| doko | yofel, blocks the lensfun transition (it's a small one), so not immediately | 13:15 |
| yofel | ok, I'll take a look over the weekend then probably | 13:16 |
| === _morphis is now known as morphis | ||
| ginggs | doko: thanks for aster and getdp rebuilds, for some reason i thought they would not be necessary | 14:44 |
| doko | ginggs, pcl still ftbfs | 14:45 |
| ginggs | doko: yeah, i saw :( | 14:46 |
| ginggs | doko: at this stage i have no ideas what do about pcl and yade, both look like issues with boost 1.60 to me | 14:47 |
| doko | ginggs, when in doubt, ask xnox | 15:01 |
| ginggs | xnox said "don't use boost" or something like that :) | 15:05 |
| ogra_ | thats just a macro in his IRC client :P | 15:08 |
| shadeslayer | heh xD | 15:12 |
| cpaelzer | is there a way that one can send a link (e.g. in a mail) to a file in a deb? | 15:25 |
| cpaelzer | I can't get to the actual content from here https://launchpad.net/ubuntu/+source/dpdk/2.2.0-0ubuntu8 or http://packages.ubuntu.com/xenial/all/dpdk-doc/filelist | 15:25 |
| cjwatson | not afaik | 15:25 |
| cpaelzer | maybe they are just never "extracted" and so can't be reached, but if they are let me know | 15:25 |
| rbasak | Unfortunately not, AFAIK. | 15:26 |
| rbasak | The bzr importer used to do it, but doesn't for >= Xenial. | 15:26 |
| cpaelzer | rbasak: thanks, at least I can stop to search | 15:26 |
| rbasak | nacc's git importer may help when it's ready and running on dpdk. | 15:26 |
| cjwatson | even for the bzr importer that was only for source packages | 15:26 |
| cjwatson | while cpaelzer was asking about debs | 15:26 |
| rbasak | If the package is in Debian, then sources.debian.net can do it, but presumably that doesn't apply to dpdk right now. | 15:27 |
| cjwatson | (there is of course overlap) | 15:27 |
| cjwatson | I'd love to have sources.d.n for Ubuntu | 15:27 |
| rbasak | Oh. | 15:27 |
| rbasak | Sorry! | 15:27 |
| rbasak | Yeah, so most of what I said isn't relevant. | 15:27 |
| cjwatson | but am not volunteering! | 15:27 |
| slangasek | pitti: fwiw that UUID shown in that /etc/fstab on the bug is the GPT partition UUID (as the latest bug followup confirms), which no tool would ever have put in /etc/fstab automatically because it doesn't work; this is why the submitter's claim to have never edited /etc/fstab by hand is not credible | 15:35 |
| pitti | slangasek: urgh, yes, that doesn't belong there indeed | 15:37 |
| pitti | well, that still doesn't rule out that there's some shady package in ubuntu who does that | 15:37 |
| pitti | but we won't know really without a reproducer | 15:37 |
| slangasek | pitti: would have to be *very* shady, to simulate trial-and-error edits to /etc/fstab ;P | 15:38 |
| pitti | slangasek: well, I've had my share with ecryptfs-setup-swap breaking stuff :) (and it's still not done, got another case reported recently) | 15:38 |
| cyphermox | slangasek: could it be the result of some weird "fix grub" app? | 15:38 |
| pitti | but I'm reasonably sure it's not that one for this case | 15:39 |
| slangasek | cyphermox: maybe. Do we have such a thing in the archive? If so, we should blast it with a cannon | 15:39 |
| cyphermox | looking. | 15:39 |
| doko | hmm, what really is the rationale for building static libs with pie? | 15:44 |
| slangasek | doko: besides "it's hard to exclude them", and "if your executables are going to be PIE the static libs linked into them need to be PIE"? | 15:46 |
| doko | slangasek, well, maybe for the former we should have patched libtool for most libs. Do we have any of these binaries for the latter? looks like collateral damage | 15:47 |
| doko | now rebuilding all rdeps for partclone | 15:49 |
| slangasek | doko: since we're building executables as PIE by default now, sure, any static lib in the archive that's being linked into an executable depends on this | 15:50 |
| slangasek | and there are going to be plenty of those around, because if libtool convenience libraries if nothing else | 15:50 |
| slangasek | (so changing this in libtool is also not going to DTRT) | 15:50 |
| cyphermox | slangasek: boot-repair looks like a possible culprit, that's *not* in the archive. | 16:01 |
| tjaalton | anyone who knows qt5 around? why does building owncloud-client against qt5 break it's notificator (doesn't show up)? | 16:01 |
| doko | tjaalton, is this related to png? there were some test failures in the last qt5 build, so I disabled these to the icu/libpng transition done. didn't hear yet back from Mirv | 16:04 |
| tjaalton | doko: this is on xenial, actually it's been broken since wily | 16:04 |
| tjaalton | bug 1511058 | 16:05 |
| ubottu | bug 1511058 in owncloud-client (Ubuntu) "No application indicator" [Medium,Confirmed] https://launchpad.net/bugs/1511058 | 16:05 |
| doko | tjaalton, ok, then it's not me =) | 16:07 |
| tjaalton | yeah :) | 16:07 |
| flexiondotorg | mdeslaur, Do you have a moment for a sort of security question? | 16:17 |
| doko | seb128, Laney: please could you merge gtk3 and friends? | 16:43 |
| _3by8 | Hi, sorry to bother you guys but I was pretty sure that someone in here could tell me how to figure out if a package comes preinstalled or not. Specifically, open-vm-tools. | 16:43 |
| seb128 | doko, not this week, team sprint, maybe next but SRUs for the LTS to do first and I didn't install y vms/chroots/etc yet | 16:44 |
| seb128 | but feel free to do it if you want | 16:44 |
| seb128 | need to go, team diner | 16:44 |
| _3by8 | I'm having an issue with it and I don't think #ubuntu is going to be able to help. Just to give you some more background, it's preinstalled on a VMWare guest where I need to have the regular VMWare tools. Is it a preinstalled package for all systems? I know I can remove it but I was wondering if there's a switch or something during installation to suppress that from happening if that's the case. | 16:45 |
| dobey | _3by8: it's installed by default in the ubuntu-server image | 16:47 |
| dobey | but not ubuntu-desktop and derivatives | 16:47 |
| _3by8 | dobey: can you exclude that package from being installed? | 16:47 |
| dobey | _3by8: if you install "ubuntu-dev-tools" you can run "seeded-in-ubuntu $package" to see what it's seeded in | 16:48 |
| _3by8 | dobey: never mind, I'll use the network installer. | 16:48 |
| _3by8 | dobey: thank you! | 16:48 |
| doko | slangasek, so partclone ends up with: | 16:58 |
| doko | make[3]: Entering directory '/«PKGBUILDDIR»/fail-mbr' | 16:58 |
| doko | sh compile-mbr.sh | 16:58 |
| doko | collect2: error: ld returned 1 exit status | 16:58 |
| doko | /usr/bin/ld: attempted static link of dynamic object `fail-mbr.o' | 16:58 |
| doko | now we build up everything for dynamic linkage, and then I assume we pass -no-pie to this builds ... :-/ | 16:59 |
| slangasek | doko: 'mbr' sounds like something that's meant to build freestanding? | 17:17 |
| doko | yes | 17:17 |
| slangasek | doko: are each of the objects built before that being passed compiler options that communicate 'freestanding'? Could we infer no-pie from this? | 17:19 |
| doko | slangasek, in this case, no, just -nostdlib is passed. unsure if I can assume if this always should be built with -no-pie | 17:23 |
| slangasek | doko: maybe not "always" built with -no-pie, but maybe it would make sense to assume -no-pie by default? | 17:24 |
| hallyn | wgrant: i've asked this before, think the answer was no... ther eis no way for me to do a git fetch on launchpad itself into a lp tree (in particular from debian anonscm) right? | 17:39 |
| slangasek | nacc: hi, fyi I'm going to sync the new version of php-defaults from Debian; this drops our delta to the versioned Breaks:, which is ok because there are newer versions of all of these packages now in yakkety except for php-imagick and php-radius, which need a merge; so php-defaults will just hang out in yakkety-proposed until those merges are done, and then it will have a minor impact on upgrade | 17:50 |
| slangasek | ordering from xenial which isn't worth carrying a delta for | 17:50 |
| smoser | anyone able to tell me if this would work: | 17:55 |
| smoser | https://code.launchpad.net/~smoser/ubuntu-seeds/ubuntu.yakkety.cloudimg-is-server/+merge/293308 | 17:55 |
| smoser | namely, can one seed list a meta-package that is derived from another ? I suspect it will work, but wonder if its a good idea or if there'd be other fallout. | 17:55 |
| slangasek | smoser: should probably target the right branch fwiw; but you don't need to make the seed depend on ubuntu-server, you just declare in STRUCTURE that it inherits from ubuntu-server and the fact that these seeds are both metapackages means germinate + ubuntu-meta will DTRT | 18:03 |
| slangasek | ... if I'm not mistaken | 18:04 |
| slangasek | smoser: ok, so I may be mistaken. You still want to do the STRUCTURE bit so that dependencies don't end up duplicated between the two metapackages, but you may indeed need that explicit ubuntu-server, judging by what I see of other packages in the archive | 18:07 |
| smoser | i re-set the merge target (you probably saw that) | 18:08 |
| smoser | cloud-image i dont think is a meta-package | 18:08 |
| smoser | it is a seed. | 18:08 |
| smoser | and bzr logging shows that once before i did make the change to show cloud-image: standard and then reverted it . my comment says that was per discussion with cjwatson | 18:10 |
| nacc | slangasek: ack, thanks! | 18:12 |
| slangasek | smoser: that was two years ago, and possibly based on different requirements at the time? would like to know what cjwatson's specific objections were there; certainly, given the goal of minimizing and then eliminating the delta between cloud-image and server, I would prefer explicit inheritance there | 18:37 |
| slangasek | smoser: STRUCTURE is a different sort of inheritance vs. depending on the metapackage | 18:37 |
| slangasek | anyway, that change LGTM | 18:38 |
| slangasek | nacc: btw, are you pushing the stage1 patches up to Debian? Do you have a list of these, should I drop them when merging packages that I'm TIL on and wait for them to come back in from upstream (or not)? | 19:02 |
| nacc | slangasek: yes, it's on my todo list for this week or next, I hope | 19:05 |
| mwhudson | docker seems to have been running in autopkgtests for like 12+ hours, but it says "Running for: 35 min 55 s" | 19:25 |
| mwhudson | does it keep failing and getting retried or something? | 19:26 |
| slangasek | mwhudson: where do you see "12+ hours"? | 19:26 |
| slangasek | it's probably a retry of a failed run, or a run that went missing | 19:27 |
| mwhudson | slangasek: it was running when i went to bed | 19:27 |
| slangasek | ok | 19:27 |
| mwhudson | which, sadly, i admit was not 12 hours ago | 19:27 |
| mwhudson | but definitely more than 35 mins | 19:27 |
| slangasek | mwhudson: did you definitely see in running, or just 'Test in progress'? | 19:27 |
| mwhudson | slangasek: it's on http://autopkgtest.ubuntu.com/running.shtml | 19:28 |
| slangasek | yes, it is now | 19:28 |
| slangasek | but 12 hours ago, was it? :) | 19:28 |
| mwhudson | and yes, it was there with output and stuff last night too | 19:28 |
| slangasek | ok fun | 19:28 |
| slangasek | then the results were lost, I didn't know that was a thing | 19:28 |
| mwhudson | i have learnt about the thing where "running" on excuses can actually mean "in the queue behind half of debian" | 19:28 |
| mwhudson | also excuses links to https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-yakkety/yakkety/ppc64el/d/docker.io/20160428_134742@/log.gz which is a failure on amd64 | 19:30 |
| mwhudson | but i don't think it's linked from http://autopkgtest.ubuntu.com/packages/d/docker.io/yakkety/ppc64el/ | 19:30 |
| mwhudson | er | 19:30 |
| mwhudson | *failure on ppc64el | 19:30 |
| slangasek | ... neat | 19:31 |
| slangasek | mwhudson: pitti should be apprised of these issues; can you file bugs on https://bugs.launchpad.net/auto-package-testing ? | 19:32 |
| mwhudson | slangasek: ok | 19:33 |
| mwhudson | huh it's no longer on running.shtml but it's not on http://autopkgtest.ubuntu.com/packages/d/docker.io/yakkety/amd64/ either | 19:39 |
| mwhudson | slangasek: is it britney that starts the autopkgtests running? | 19:40 |
| mwhudson | it sort of seems like the results are getting lost so something is just scheduling them to run again? | 19:40 |
| slangasek | mwhudson: britney triggers them, yes. britney won't trigger a second time though, so the something else that retriggered is probably a release team member | 19:41 |
| slangasek | mwhudson: so that's likely pitti, but he may not know that the tests ran before and had results lost as he probably batch-retried | 19:42 |
| mwhudson | ah ok | 19:44 |
| mwhudson | these tests are cursed, it seems :-) | 19:44 |
| === afkthairus is now known as athairus | ||
| smoser | anyone know what urls 'snap install' hits ? | 20:29 |
| pitti | mwhudson: yes, I'm aware of the docker loop; somewhere in the middle it kills the sshd server-side process which results in ssh returning with 255, which we currently treat as "temporary failure" | 21:00 |
| pitti | mwhudson: thus the test is just looping forever | 21:00 |
| pitti | mwhudson: I'm not quite sure yet what to do about that infra-wise, as in general we *do* want to retry on ssh failures | 21:00 |
| Unit193 | bdmurray: You could likely consider 1573404 a request to add an option to jump early from an LTS to LTS without the first point release. Currently silly blogs recommend you use '-d' and tell you to ignore the warnings, which can lead to fun if running this when there's an active development version. | 21:01 |
| pitti | mwhudson: yes, autopkgtest.u.c. browsing is a bit behind, that's on my TODO list | 21:04 |
| pitti | mwhudson: the direct log links from britney should be okay though | 21:04 |
| mwhudson | pitti: uggggh | 21:14 |
| pitti | mwhudson: I updated your bug report, I'll ponder this tomorrow | 21:14 |
| mwhudson | pitti: strange though, britney links to a log for ppc64el but not amd64 | 21:15 |
| pitti | mwhudson: why strange? as I said, it only loops on ppc64el | 21:16 |
| pitti | mwhudson: err sorry, only on amd64 | 21:16 |
| pitti | mwhudson: the armhf queue just didn't get to it yet (armhf is lagging quite a bit) | 21:16 |
| pitti | and the others have results | 21:16 |
| mwhudson | pitti: ah i think it *was* looping on ppc64el | 21:16 |
| pitti | mwhudson: note that "in progress (always failed)" does not block promotion | 21:17 |
| mwhudson | pitti: but then managed to fail more catastrophically and earlier, and got properly recorded as a failure | 21:17 |
| pitti | mwhudson: it's the armhf test that does | 21:17 |
| pitti | mwhudson: ah, could be :) | 21:17 |
| mwhudson | pitti: yeah i'm not so worried about migration, but it would be nice for these tests to work :-) | 21:17 |
| mwhudson | tianon: ^^ | 21:18 |
| mwhudson | pitti: thanks for the updates | 21:20 |
| mwhudson | pitti: oh one thing, are the logs for the runs that end with ssh dying kept anywhere? | 21:20 |
| pitti | mwhudson: yes, I have them, but they aren't public right now | 21:20 |
| pitti | mwhudson: want one? | 21:20 |
| mwhudson | pitti: please | 21:21 |
| mwhudson | pitti: i filed https://bugs.launchpad.net/ubuntu/+source/docker.io/+bug/1576419 too | 21:22 |
| ubottu | Launchpad bug 1576419 in docker.io (Ubuntu) "autopkgtests kill ssh" [Undecided,New] | 21:22 |
| pitti | mwhudson: followed up | 21:24 |
| pitti | mwhudson: I have the complete logs too, but they are a bit difficult to haul across, and also uninteresting (AFAICS) | 21:25 |
| mwhudson | pitti: thanks | 21:25 |
| mwhudson | fair enough | 21:25 |
| pitti | but if you need them, I can get them | 21:25 |
| mwhudson | pitti: i guess it *could* be OOM? | 21:25 |
| pitti | mwhudson: yes, that's possible of course | 21:25 |
| mwhudson | pitti: how much ram do the instances have? | 21:25 |
| pitti | mwhudson: 1.5 GB normally | 21:25 |
| mwhudson | ok | 21:26 |
| mwhudson | next step is to run the tests in verbose mode i guess | 21:26 |
| pitti | mwhudson: I can add docker.io to "big_tests" which would get them 8 GB | 21:26 |
| mwhudson | pitti: if that's easy and not too disruptive it might be worth a try? | 21:26 |
| pitti | but if I do that now before going to bed, I risk blocking the quota for five runners perpetually | 21:27 |
| pitti | mwhudson: *shrug* ok, done now | 21:28 |
| pitti | I can do another half hour | 21:28 |
| mwhudson | hm well | 21:28 |
| * pitti kills the currently running test | 21:28 | |
| mwhudson | pitti: are you the only one who has access to the infrastructure? | 21:29 |
| pitti | mwhudson: no; Laney should know his way fairly well; infinity, slangasek and some others have too, but didn't get much hands-on training | 21:30 |
| mwhudson | pitti: well, i can watch the tests for an hour or two and if it looks bad get one of them to at least move it out of bit_tests? | 21:31 |
| mwhudson | *big_tests? | 21:31 |
| slangasek | yes, I have read the autopkgtest manual ;) | 21:31 |
| slangasek | but oh, we're talking about the infrastructure, I would have to hunt for that | 21:32 |
| pitti | https://wiki.ubuntu.com/ProposedMigration/AutopkgtestInfrastructure FTR | 21:32 |
| pitti | anyway, next runner will grab it | 21:33 |
| pitti | I added it to big_tests locally (not committed to https://git.launchpad.net/~ubuntu-release/+git/autopkgtest-cloud/tree/worker-config-production yet) | 21:33 |
| mwhudson | next question! | 21:35 |
| mwhudson | i want to SRU golang 1.6.2 to xenial unchanged | 21:36 |
| pitti | mwhudson: http://autopkgtest.ubuntu.com/running.shtml#pkg-docker.io is now running in an m1.large instance | 21:36 |
| pitti | and promptly hit the quota ceiling (but it will retry until it gets enough) | 21:36 |
| mwhudson | is it considered best to just update the changelog of the yakkety version and upload that | 21:36 |
| pitti | mwhudson: -backports? | 21:37 |
| mwhudson | or put a new entry on top of the xenial version? | 21:37 |
| mwhudson | pitti: no, -updates | 21:37 |
| doko | pitti, any idea about the open-vm-tools failure? | 21:37 |
| pitti | well, unless you can make sure this is 100% backwards compatible -- we shouldn't introduce new FTBFS with an SRUed toolchain | 21:37 |
| slangasek | mwhudson: bear in mind that SRU requirements for 1.6.2 on top of 1.6.1, given that it would not be coinstallable, would be higher than for the previous golang-1.6 SRU -- ^^ what pitti says. But in terms of changelogs... "Meh" | 21:38 |
| mwhudson | pitti: golang upstream is super conservative about point releases | 21:38 |
| pitti | doko: not from the logs, this needs some deeper investigation; not today any more though (from me) | 21:38 |
| pitti | it's almost midnight and I'm still swamped in pings and new bug reports :) | 21:38 |
| doko | hmm, open-vm-tools doesn't even have a debian/tests dir? | 21:39 |
| pitti | mwhudson: purely the changelog issue, I'd add a new record with " * backport yakkety release" and append a ~16.04.1 | 21:39 |
| pitti | doko: no, it's the dkms autodep8 test | 21:39 |
| doko | ahh | 21:39 |
| pitti | mwhudson: aside from teh fact that yakkety has the same version than xenial | 21:39 |
| doko | so then it's kernel module breakage on amd64 | 21:40 |
| doko | apw, ^^^ | 21:40 |
| mwhudson | pitti: append a new record to which changelog? :) | 21:40 |
| pitti | mwhudson: well, golang's? | 21:40 |
| mwhudson | pitti: i meant xenial's or yakkety's? | 21:40 |
| mwhudson | oh and i should do trusty too | 21:40 |
| pitti | mwhudson: do a new upload to yakkety with normal versioning, then do the SRU with adding a new record with ~16.04.1 and a backport note; or just change the existing yakkety changelog record accordingly, I don't think it's that important really | 21:41 |
| mwhudson | pitti: ok | 21:41 |
| mwhudson | pitti: thanks | 21:41 |
| apw | doko. yep working on it ... | 21:41 |
| pitti | mwhudson: oh, err: | 21:41 |
| pitti | golang | 2:1.6-1ubuntu4 | yakkety | all | 21:41 |
| pitti | golang-1.6 | 1.6.2-0ubuntu2 | yakkety | source, all | 21:42 |
| pitti | mwhudson: this is confusing | 21:42 |
| mwhudson | waait | 21:42 |
| mwhudson | golang should have been removed | 21:42 |
| mwhudson | oh no, binaries | 21:42 |
| mwhudson | i should have said golang-1.6 above sorry | 21:42 |
| mwhudson | https://launchpad.net/ubuntu/+source/golang-1.6 | 21:42 |
| pitti | right, the other was golang-defaults, sorry | 21:42 |
| pitti | mwhudson: no, m1.large didn't help, reverting the big_tests | 21:51 |
| mwhudson | pitti: huh and :( | 21:51 |
| hallyn | ... so i have two libvirt trees, the only difference is http://paste.ubuntu.com/16120216/ . in one warnings are treated as errors, in the other not | 21:52 |
| mwhudson | i guess i should try to repro on ec2 or someting | 21:52 |
| pitti | mwhudson: would also be interesting to repro it locally with qemu, and ssh into teh instance while the test is running | 21:52 |
| mwhudson | yeah, or that | 21:52 |
| pitti | mwhudson: if it's your only adt-run with qemu, it'll be port 22000 on localhost (ubuntu:ubuntu) | 21:53 |
| mwhudson | oh yeah, i made an image when we were looking at juju | 21:53 |
| nacc | hallyn: something with DEB_BUILDHOST? | 21:53 |
| nacc | hallyn: don't see why that should matter, though | 21:54 |
| nacc | hallyn: and nm, i see where it's defined now | 21:55 |
| hallyn | nacc: yeah it's weird... | 21:55 |
| hallyn | well i need to get the animals fed before they tear each other apart - bbl | 21:56 |
| pitti | mwhudson: sorry, port 10022 | 21:56 |
| pitti | 22000 is my "run this VM" script | 21:56 |
| pitti | mwhudson: running this now: adt-run --apt-pocket=proposed -U docker.io --- qemu /srv/vm/adt-yakkety-amd64-cloud.img | 21:57 |
| mwhudson | pitti: oh ok | 21:58 |
| mwhudson | i hadn't even gotten started really :) | 21:58 |
| pitti | mwhudson: well, and the VM doesn't boot after dist-upgrading to -proposed :/ | 21:58 |
| * pitti re-runs without -U | 22:02 | |
| pitti | mwhudson: wow, the docker.io tests install the entire build toolchain | 22:02 |
| mwhudson | they're pretty heavy, yeah | 22:04 |
| pitti | mwhudson: wohoo, what are these tests doing?? | 22:11 |
| pitti | $ mount | 22:11 |
| pitti | mount: failed to read mtab: No such file or directory | 22:11 |
| pitti | there's no proper /proc any more, "mounts" is a dead symlink | 22:11 |
| mwhudson | there's definitely a reason they have all the scary control flags they do | 22:11 |
| pitti | mwhudson: I was going to check what's currently hanging locally with top, but that also just fails with "Error, do this: mount -t proc proc /proc" :) | 22:12 |
| mwhudson | pitti: haha ok, i didn't realize that they were /that/ destructive | 22:12 |
| pitti | Step 5 : RUN gcc -g -Wall -static userns.c -o /usr/bin/userns-test && gcc -g -Wall -static ns.c -o /usr/bin/ns-test && gcc -g -Wall -static acct.c -o /usr/bin/acct-test | 22:12 |
| pitti | ---> Running in e064dc8c3809 | 22:12 |
| pitti | Container command not found or does not exist. | 22:12 |
| pitti | ./hack/make.sh: line 258: local: can only be used in a function | 22:12 |
| pitti | it has hung here for several minutes now | 22:12 |
| mwhudson | oh right | 22:13 |
| pitti | nothing in dmesg | 22:13 |
| mwhudson | my experience is that once you get that "local: can only be used in a function" message, the tests are dead | 22:13 |
| pitti | anyway, if you can investigate this in local qemu, that'd be great -- really bedtime here, sorry | 22:13 |
| mwhudson | pitti: but it didn't kill ssh? | 22:13 |
| pitti | mwhudson: not yet, now | 22:13 |
| mwhudson | pitti: sleep well? | 22:13 |
| pitti | s/now/no/ | 22:13 |
| mwhudson | pitti: sleep well!, rather | 22:13 |
| mwhudson | i'll try to poke with ssh | 22:13 |
| pitti | mwhudson: but it didn't even get to running the tests that I saw in the log when that happened | 22:14 |
| mwhudson | er qemu rather | 22:14 |
| mwhudson | can't type this morning | 22:14 |
| pitti | mwhudson: http://paste.ubuntu.com/16120559/ | 22:14 |
| pitti | mwhudson: that's how far I got with the local run | 22:14 |
| pitti | I had two screenfuls more in the production log | 22:15 |
| doko | why does a package ftbfs with a syntax error on one arch when it succeeds on all others? https://launchpad.net/ubuntu/+source/cgal/4.8-3/+build/9639661 | 22:15 |
| doko | and forgot to say, it builds locally ... | 22:16 |
| slangasek | doko: because it wants to assert not is fail, and it is fail | 22:16 |
| slangasek | doko: did you try a straight retry? | 22:17 |
| doko | two | 22:17 |
| slangasek | fun | 22:17 |
| doko | one more ... | 22:17 |
| pitti | doko: your local mirror might not have new enough -proposed packages in sbuild? | 22:19 |
| pitti | anyway, -EBEDTIME, really; /me waves | 22:20 |
| sarnold | see you ina few hours :) | 22:20 |
| doko | pitti, not using local mirrors for that reason | 22:21 |
| slangasek | doko: are you building -B or -b? | 22:21 |
| doko | slangasek, -b | 22:22 |
| doko | failed again | 22:29 |
| mwhudson | oops forgot to build check my golang upload :( | 22:32 |
| doko | giving up on cgal for now ... | 22:45 |
| wgrant | hallyn: I have git mirroring half done, but currently on hold due to some more important work. | 23:24 |
| sbeattie | doko: static libs that need rebuilding for -fPIE: antlr, autogen, bglibs, binpac, gadap, i2util, libctl, orbit2, publib, pvm, unicon, zlib. I rebuilt them successfully in a ppa with yakkety-proposed enabled. | 23:45 |
| sbeattie | doko: I'll have a few more, but I need to finish verifying that they build okay. | 23:45 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!