/srv/irclogs.ubuntu.com/2016/04/28/#ubuntu-devel.txt

infinity:(00:00
sidiCurrently 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 lib00:03
sidiyes 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
sidihave a usr/lib/ARCH/... libdir, and that the common package (with Multi-Arch: any) uses the usual usr/lib/...00:04
sidior 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
infinityDEB_HOST_MULTIARCH is always set.00:05
infinityBut installing foobar.sh to LIBDIR is wrong anyway, it should be LIBEXECDIR00:06
infinityWhich 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
slangasekwhere "your makefile" == "debian/rules"00:07
infinityIt's always set for dh(1) targets, isn't it?00:07
slangasekinfinity: yes, that also00:07
slangasekwith the proper compat level etc etc00:08
infinitysidi: 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
infinitysidi: That one might take an upstream patch to fix, but it's also The Right Thing To Do.00:09
sidiaw00:11
sidiinfinity, 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
infinityAnd yet, you're spending time trying to figure out how to multiarch it...00:12
sidithe 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 lib00:12
slangasekyes, ironically multiarching the world had the side effect of undoing the FHS's attempted merge of libdir and libexecdir00:12
sidiif i try to do the right thing i probably lose one or two weeks00:12
sidiinfinity, yes because it makes other packages uninstallable00:12
sidii 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 rest00:13
sidiAlso this is a Linux only package for the matter :-) It's based on Linux namespaces00:13
sidiknowing 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
infinitysidi: Well, there's no rule that you have to keep the paths that "make install" gives you. :P00:15
infinitysidi: Just move things around a bit after dh_auto_install00:15
sidiif i change the paths i need to patch the original app :-) it somehow expects those .sh files in /usr/lib, sadly00:15
infinityYes...00:15
infinitySo, keep the .sh files there.  They belong there.00:16
infinityAnd put the libraries in the multiarch paths.00:16
infinityAnd you win.00:16
infinityYou don't have to accept where the upstream makefile puts things as final.00:16
sidiinfinity, right so I need to ensure the Makefile uses libdir only for actual .so libraries00:16
sidiand patch the makefile and voila?00:16
infinityNo.00:16
infinityJust install with libdir=multiarch as you were, then mv multiarch/firefail/fshaper.sh to usr/lib00:17
Unit193Hah, nice typo.00:18
infinityOr do so with a .install file, which I assume you already have for your package split.00:18
infinityUnit193: Freudian.00:18
sidiUnit193, wait what? :p00:20
sidiinfinity, 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 packages00: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
infinityLooks like those are the two that need special treatment.00:22
infinitysidi: 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
infinityYMMV, have fun, etc.00:24
* infinity deletes the source before he's tempted to do the work.00:25
sidiinfinity, thanks00:25
sidiinfinity, you would be wasting your time anyway :-) my fork has an extra libraries on top of the existing mess :-)00:25
smoserhey, 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
ubottubug 1575572 in init-system-helpers (Ubuntu) "apache2 fails to start if installed via cloud config (on Xenial)" [High,Confirmed] https://launchpad.net/bugs/157557200:53
infinitysmoser: How is that not a cloud-init bug?  Installing services and expecting them to start *while still booting* is a bit nutty.00:56
smoserit has worked since before lucid00:57
infinityBecause pre-systemd, you probably ran in rc200:58
infinityOr you ran in rcS, and then apache started when you reached rc2.00:58
smoserno. apache started when it was installed like it should have.01:00
infinityThen you were running your install in rc2.01:00
smoserpossibly. you're probably right that 'runlevel' would provide some actual useful output rather than 'unknown'01:01
smoserit doesnt seem that odd for a service to insall other packages and do so as it runs in boot.01:02
smoserpuppet or chef probably do this.01:03
infinityThey most certainly don't.01:03
smoserreally?01:03
infinityThey run a daemon post-boot that checks for sanity and reconciles desired system state.01:03
smoserwhen is 'post-boot' ?01:03
infinityAt least puppet actually has a delay built in.01:04
infinityBut it's tripped from cron, so at least cron needs to be running.01:04
smoserah.. sleep 12 should cover it.01:04
smoserthis coudl be tripped really by anthing01:05
smoserboot system01:05
smoserssh starts01:05
smoseruser sshes in01:05
smoserapt-get install package01:05
=== Wulf4 is now known as Wulf
smoseruser expects package is installed01:05
smoserbut systemd isn't "finished"01:05
smosers/ssh/logs in at console/01:06
infinityIn 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
smoseri 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
smoserby your suggestion, installation of packages in rc.local would not be possible without some background and poll.01:09
smoserreally seems broken.01:10
infinityAnyhow, 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
smoserthat is not entirely unreasonable. not entirely.01:11
smoserbut it wont start after moving to rc2 because systemd calculates its dependencies and such one time01:11
infinityToday'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
xnoxinfinity, hahahahahahaha02:22
xnoxbeen there done that02:22
=== _unixpro1970 is now known as unixpro1970
=== unixpro1970 is now known as _unixpro1970
=== _unixpro1970 is now known as unixpro1970
xnoxinfinity, smoser - i fell disturbance of the force due to lack of $ systemctl daemon-reload in apache2.postinst02:23
xnox*feel02:24
xnoxpitti, should packages that ship init scripts only, call systemctl daemon reload?02:24
infinityxnox: The systemd trigger covers that.02:48
infinityxnox: (So, that's not the problem here)02:49
sarnoldis there any long-term plan to .. clean up after the N init systems at some point?02:49
sarnoldthere'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
infinitysarnold: Once we no longer have any upstart sessions anywhere in any of our products, we can completely kill upstart.02:50
infinitysarnold: Keeping sysvinit for all things in Debian is likely going to continue forever.02:50
infinityOr, at least, a long time.02:50
sarnoldinfinity: well, that's something I guess.02:51
dmickanyone 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
sarnoldzounds that was quick, I glanced over 90-console and had -zero- idea what it did :)03:00
dmickwell, I am sort of in the middle of this problem :)03:00
cyphermoxdmick: I can look it up03:00
cyphermoxnot nearly the semi-god install-fu of cjwatson, but installers are my thing ;)03:01
dmickI'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 there03:02
dmickI suppose it's also possible it's just ab ug.03:02
cyphermoxdmick: the best thing is probably for you to tell us exactly what is the problem you're trying to solve though03:03
dmickspecifically, I started off trying to understand how /etc/init/ttySN.conf got written to enable getty on 'the console' SoL device03:03
dmick(which appears to match the console= given to the install kernel cmdline)03:03
dmickand really that's still the goal; the questions above are in service of that underlying question03: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
infinitydmick: It's not necessary because systemd doesn't statically configure gettys.03:07
dmickwell yes but we're still provisioning  trusty systems03:08
infinityOh, we magically fixed in there too? ;)03:08
dmickbut yeah, I caught the bit about systemd doing this now03:08
infinityWhat is your console device?03:08
dmick/dev/ttySn where n is 0, 1, or 2 depending on the platform03:08
infinityfwiw, rawconsole just looks like a bug.03:10
dmickI was starting to think that03:10
dmicka harmless one, no doubt03:10
infinityQuite.03:10
cyphermoxunless it comes from some d-i C code that runs finish.d03:10
infinityAs for your provisioning, if you're setting console on the commandline, it should Just Work.03:10
infinityThere shouldn't be need to do anything manual.03:11
dmickit seems like it does03:11
dmicklike I say, the question was "how", and cjwatson pointed me to this script, which held most of the answer03:11
dmickso now I'm just filling out the whole picture.  any ideas about the origin of /var/run/console-device?03:11
dmickoh duh I hadn't grepped d-i yet03:12
infinityIt's from rootskel.03:13
dmickyep03:13
infinityWhich the finish-install changelog mentions.03:13
cyphermoxthere you go03:13
dmickreopen-console-linux, looks like03:13
dmickheh, and, amusingly, there's a "console_raw" in that script03:13
dmickwow.  grepping for a kernel message03:14
dmickand then eventually what probably happens: grepping /proc/cmdline03:14
dmickawesome.03:14
dmickthat feels right03:14
infinitydmick: The sketchy ringbuffer grepping is only on ancient kernels.  We can probably tear all that out upstream now.03:16
dmickso 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
infinitysrc/sbin/get-real-console-linux.c is still correct, though.03:16
dmickah.  nice info: /dev/console is magical03:17
dmick*awesome*.  that's much more than I paid for.  you guys are teh awesome03:20
cyphermoxdmick: /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 like03:21
dmickoh sorry, you said /dev/console.  ok.03:22
dmickright.  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 coincidence03:22
dmickthat really nails home a lot of stuff I haven't fully understood for a long time; thanks03:23
dmickso it looks like the active branch of reopen-console-linux is likely the one that calls get-real-console-linux03:30
lfaraoneIs the header for pages like http://releases.ubuntu.com/xenial/ maintained in some bzr branch somewhere I could submit a patch to?03:31
dmickcyphermox: infinity: really appreciate it.  thanks a mil.03:40
infinitylfaraone: lp:ubuntu-cdimage03:47
sarnold"The Breezy Colony 5 release was".. oy vey :)03:49
=== unixpro1970 is now known as _unixpro1970
cpaelzergood morning04:51
=== NCommander is now known as mcasadevall
pittixnox: as Adam said06:01
=== _unixpro1970 is now known as unixpro1970
=== unixpro1970 is now known as _unixpro1970
=== _unixpro1970 is now known as unixpro1970
Bluefoxicyhilarious06:41
BluefoxicyI upgraded from 14.04 to 15.10, and now I'm upgrading to 16.0406:41
Bluefoxicyin 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
pittiBluefoxicy: missing linux-generic  metapackage?07:09
Bluefoxicymaybe07:11
Bluefoxicyit upgraded to 4.4 during do-release-update to 16.04 LTS07:11
=== athairus is now known as afkthairus
seb128could somebody from the SRU team look at gnome-software in the xenial queue?08:18
pittiseb128: ok, I'll do a round of sru processing08:20
seb128pitti, thanks08:20
seb128pitti, hey btw, wie gehts? still under snow?08:20
pittiugh, I got that queue empty yesterday, lots of uploads since then :)08:20
pittiseb128: non, il y a du soleil à nouveau \o/08:20
pittiseb128: mais il fait encore très froid, il n'y a qu'une degrée :/08:21
seb128pitti, c'est l'hiver...08:22
pittien effet !08:22
pittiles premières deux semaines d'avril était très bon08:22
pittiseb128: but I'm sure that next ween in Austin will be really warm :)08:22
seb128pitti, what sprint is that?08:23
pittiseb128: cloud sprint08:23
seb128oh ok08:23
seb128have fun there!08:23
pittimerci !08:23
pittiseb128: 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
seb128yes, I guess this one had no real reason to be a copy08:32
seb128sorry about that08:32
pittiseb128: also needs uploading to yakkety08:35
seb128pitti, ack08:38
seb128pitti, can't we just pocket copy? we used to do that early in the cycle08:39
pittiseb128: I'd rather not; we have a big compiler change, a libpng and other lib transitions already08:39
seb128k08:40
pittiand that's the kind of package that very well might link against libpng or libicu08:40
seb128we are working on rebasing on 2.20.2 we might just upload that one08:40
pittiarmhf test queue < 1000, yay08:50
ginggshi pitti, can you let json-c's tests run against u1db 13.10-6.1build1 in -proposed please?09:00
pittiginggs: I'll do a mass-retry of regressions as soon as the current backlog settles down09:00
pittiginggs: one "normal" round and one against --all-proposed09:00
pittito shake out the implicit/forgotten versioned dependencies09:01
rbasakxnox: are you planning SRUs for bug 1572613?10:05
ubottubug 1572613 in gcc-mingw-w64 (Ubuntu) "GCC stack access scheduled after stack deallocation" [Wishlist,Triaged] https://launchpad.net/bugs/157261310:05
rbasakFor MySQL, I'm expecting an SRU soon anyway.10:05
xnoxrbasak, yes and no.10:12
xnoxrbasak, so first there needs to be a gcc sru, and then rebuilds with fixed compiler.10:12
xnoxrbasak, doko did say that he wants to sru gcc when 5.4 is out (or something like that)10:12
xnoxand then i'll be looking into what needs fixing, and what "organically" fixes itself.10:13
xnoxrbasak, it also matters where we upload the compiler to.... cause e.g. imho it should be in security pockt.10:13
xnoxbut 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 -security10:14
xnox(affects kernel builds for live patching)10:14
apwchanging the compiler in a stable is always problematic, as i understand the world if we sru a compiler we10:25
apwhave to consider it for the security pocket, so that kernels and dkms packages are built with the same compiler10:25
apwand we alwyas use the -security compiler for the main kernel10:26
xnoxyeah, cause otherwise there lies madness10:26
xnoxapw, with that compiler bug it is tricky, cause it was not trigger on the kernel sources.... so far...10:26
xnoxbut it could be =(10:27
apwxnox, i am not saying that we shouldn't update the ocmpiler, i am just saying i think it has to go10:27
apwto the security pocket if we do10:27
xnoxquite for many reasons10:27
xnoxapw, but i don't want to do security uploads =) i don't think i ever done one. So up to doko really =)10:28
siretartmvo: 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
ubottuLaunchpad 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/145430610:38
ginggshi,  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
pittiginggs: yakkety's gcc now defaults to -fPIE10:45
pittiginggs: https://lists.ubuntu.com/archives/ubuntu-devel-announce/2016-April/001183.html10:46
pittiginggs: not sure how to revert that, though; -fPIE can't work with static linking10:46
pittiso maybe it's a gcc bug that it uses PIE for .a too?10:46
pittiginggs: also, static linking, *tsk* :010:47
mvosiretart: uh, I have not seen that. and help with the upload is very welcome, thanks a bunch for the offer!10:47
ginggspitti: this doesn't affect ppc64el though10:47
* pitti thought most libraries stopped shipping .a10:47
pittiginggs: right, it only was changed on amd6410:47
ginggsso isn't rebuilding papyrus with new flags a good thing to do?10:49
pittiginggs: yes, it should be, if you disable the -fPIE thing; but I'm not sure whether this is a bug in gcc or in papyrus10:49
pittidoko: ^?10:50
ginggsbut papyrus and gdcm both build fine without disabling -fPIE10:50
pittiI thought you just said it doesn't10:50
pittioh, with rebuilding both10:51
ginggsyeah10:51
pittiginggs: hm, that almost sounds like the rebuild would build the .a with PIE10:51
pittiwhich is wrong AFAIK10:51
ginggsi 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 PIE10:57
ginggshmm, and it is lunchtime10:57
siretartmvo: in order to build the package, I had to disable the pep8 and pyflakes unit test - both fail.10:59
siretartmvo: please confirm that you are OK with me uploading a package that disables both tests to rakety10:59
siretartmvo: hm, fixing both tests was easy, I'll upload with those changes11:06
rbasakxnox: 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
xnoxrbasak, will do will do11:10
dokoginggs, pitti: yes, rebuilding should be fine11:16
dokosbeattie, ^^^ still missing your list of static libs to rebuild :-/11:16
pittidoko: it's ok now to build static libs with -fPIE? (and apparently required now too)?11:17
dokopitti, if these are used to build binaries built with pie, yes11:18
pittidoko: ah ok, so that means in yakkety we'll rebuild all packages that ship an .a11:18
ginggsi think things will blow up if someone tries to link the .a into a .so11:18
pittidoko: thanks for the heads-up11:19
dokopitti, and no, we don't have infrastructure to build static libs fithout pie yet11:19
pittiginggs: well, .so were always supposed to be PIC/PIE, no?11:19
ginggspitti: i thought PIC yes, PIE no11:20
ginggsbut i don't know for sure11:21
pittiginggs: I keep confusing the two, I keep thinking of them as the same11:21
pittixnox, seb128, slangasek: should we talk about un-upstartifying the desktop session next week at UDS?12:33
xnoxpitti, that would be good12:34
pittiwe haven't had an upstart maintainer for a long time any more, and we're already having trouble finding someone who keeps it buildable12:34
pittiseb128, xnox: also sounds like a nice topic for a mini-sprint12:34
seb128+112:34
seb128is any distribution using systemd for user sessions nowadays?12:34
pittiseb128: unknown, but I figure most of them use good old gnome-session12:35
seb128right12:35
pittiand I'm sure we can at least replace some of them with dbus activation12:35
Laneydesrt says not12:35
Laneyi.e. someone should work on this :-)12:35
xnoxseb128, as far as i know we are the only ones to have an init for a user session at all.12:36
pittiso for example, unity-settings-daemon both has an xdg autostart and an upstart session job12:36
xnoxseb128, yolla kind of uses systemd, but it's single-user / system systemd, with many weird patches12:36
pittixnox: no, the user systemd unit runs pretty much everywhere, just nobody uses it for distro things yet12:36
xnoxpitti, yeah, i was keeping xdg autostart for systemd-xdg-autostart generator (not upstream)12:36
xnoxpitti, 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 place12:37
xnoxvery scary but totally usable12:38
xnoxbut none of that shipped anywhere.12:38
mapreriin 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
ubottuLaunchpad bug 1574745 in libreoffice-dictionaries (Ubuntu) "Missing symlinks to match locales" [High,Confirmed] https://launchpad.net/bugs/157474512:38
xnoxpitti, seb128 - but it would probably mean we need user dbus1, upgraded dbus1, and work out the kinks if we can use that.12:38
xnoxas there is no support of multiple systemd user sessions per user, like we currently have in upstart12:38
xnoxpitti, seb128 anyway, yes we should talk, and i should go to the airport soon.12:39
seb128is multiple-sessions-for-one-users something we support?12:39
pittiok, let me create a blueprint/UDS discussion about that12:39
pittixnox: oh, already?12:39
* pitti leaves on Sunday12:39
seb128xnox, safe flight12:39
xnoxpitti, i had a holiday from thrusday - monday, which i had to cut short, so i'm going to austin from budapest on sunday12:40
=== _salem is now known as salem_
xnoxand hence wasted money on a non-refundable flight from budapest to london, and one night of hotel.12:40
pittihttps://blueprints.launchpad.net/ubuntu/+spec/desktop-y-replace-upstart12:45
pittiah, I feel my lost TB powers already, I can't ack this for UOS any more nor for yakkety (only propose)12:46
pittidholbach: do you see this ^ on https://blueprints.launchpad.net/sprints/uos-1605 ? I apparently can't see proposed topics any more12:47
dholbachpitti, accepted12:49
pittidholbach: danke12:49
pittidholbach: wow, this really is the first BP for UOS12:50
dholbachsome folks filed "meetings" in summit directly12:50
dokoyofel, please could you sync/merge digikam?13:14
yofeldoko: sure... until when do you need it? (that's not a small thing)13:15
dokoyofel, blocks the lensfun transition (it's a small one), so not immediately13:15
yofelok, I'll take a look over the weekend then probably13:16
=== _morphis is now known as morphis
ginggsdoko: thanks for aster and getdp rebuilds, for some reason i thought they would not be necessary14:44
dokoginggs, pcl still ftbfs14:45
ginggsdoko: yeah, i saw :(14:46
ginggsdoko: at this stage i have no ideas what do about pcl and yade, both look like issues with boost 1.60 to me14:47
dokoginggs, when in doubt, ask xnox15:01
ginggsxnox said "don't use boost" or something like that :)15:05
ogra_thats just a macro in his IRC client :P15:08
shadeslayerheh xD15:12
cpaelzeris there a way that one can send a link (e.g. in a mail) to a file in a deb?15:25
cpaelzerI 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/filelist15:25
cjwatsonnot afaik15:25
cpaelzermaybe they are just never "extracted" and so can't be reached, but if they are let me know15:25
rbasakUnfortunately not, AFAIK.15:26
rbasakThe bzr importer used to do it, but doesn't for >= Xenial.15:26
cpaelzerrbasak: thanks, at least I can stop to search15:26
rbasaknacc's git importer may help when it's ready and running on dpdk.15:26
cjwatsoneven for the bzr importer that was only for source packages15:26
cjwatsonwhile cpaelzer was asking about debs15:26
rbasakIf 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
cjwatsonI'd love to have sources.d.n for Ubuntu15:27
rbasakOh.15:27
rbasakSorry!15:27
rbasakYeah, so most of what I said isn't relevant.15:27
cjwatsonbut am not volunteering!15:27
slangasekpitti: 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 credible15:35
pittislangasek: urgh, yes, that doesn't belong there indeed15:37
pittiwell, that still doesn't rule out that there's some shady package in ubuntu who does that15:37
pittibut we won't know really without a reproducer15:37
slangasekpitti: would have to be *very* shady, to simulate trial-and-error edits to /etc/fstab ;P15:38
pittislangasek: 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
cyphermoxslangasek: could it be the result of some weird "fix grub" app?15:38
pittibut I'm reasonably sure it's not that one for this case15:39
slangasekcyphermox: maybe.  Do we have such a thing in the archive? If so, we should blast it with a cannon15:39
cyphermoxlooking.15:39
dokohmm, what really is the rationale for building static libs with pie?15:44
slangasekdoko: 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
dokoslangasek, 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 damage15:47
dokonow rebuilding all rdeps for partclone15:49
slangasekdoko: 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 this15:50
slangasekand there are going to be plenty of those around, because if libtool convenience libraries if nothing else15:50
slangasek(so changing this in libtool is also not going to DTRT)15:50
cyphermoxslangasek: boot-repair looks like a possible culprit, that's *not* in the archive.16:01
tjaaltonanyone who knows qt5 around? why does building owncloud-client against qt5 break it's notificator (doesn't show up)?16:01
dokotjaalton, 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 Mirv16:04
tjaaltondoko: this is on xenial, actually it's been broken since wily16:04
tjaaltonbug 151105816:05
ubottubug 1511058 in owncloud-client (Ubuntu) "No application indicator" [Medium,Confirmed] https://launchpad.net/bugs/151105816:05
dokotjaalton, ok, then it's not me =)16:07
tjaaltonyeah :)16:07
flexiondotorgmdeslaur, Do you have a moment for a sort of security question?16:17
dokoseb128, Laney: please could you merge gtk3 and friends?16:43
_3by8Hi, 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
seb128doko, not this week, team sprint, maybe next but SRUs for the LTS to do first and I didn't install y vms/chroots/etc yet16:44
seb128but feel free to do it if you want16:44
seb128need to go, team diner16:44
_3by8I'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 image16:47
dobeybut not ubuntu-desktop and derivatives16:47
_3by8dobey: 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 in16:48
_3by8dobey: never mind, I'll use the network installer.16:48
_3by8dobey: thank you!16:48
dokoslangasek, so partclone ends up with:16:58
dokomake[3]: Entering directory '/«PKGBUILDDIR»/fail-mbr'16:58
dokosh compile-mbr.sh16:58
dokocollect2: error: ld returned 1 exit status16:58
doko /usr/bin/ld: attempted static link of dynamic object `fail-mbr.o'16:58
dokonow we build up everything for dynamic linkage, and then I assume we pass -no-pie to this builds ... :-/16:59
slangasekdoko: 'mbr' sounds like something that's meant to build freestanding?17:17
dokoyes17:17
slangasekdoko: are each of the objects built before that being passed compiler options that communicate 'freestanding'?  Could we infer no-pie from this?17:19
dokoslangasek, in this case, no, just -nostdlib is passed. unsure if I can assume if this always should be built with -no-pie17:23
slangasekdoko: maybe not "always" built with -no-pie, but maybe it would make sense to assume -no-pie by default?17:24
hallynwgrant: 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
slangaseknacc: 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 upgrade17:50
slangasekordering from xenial which isn't worth carrying a delta for17:50
smoseranyone able to tell me if this would work:17:55
smoser https://code.launchpad.net/~smoser/ubuntu-seeds/ubuntu.yakkety.cloudimg-is-server/+merge/29330817:55
smosernamely, 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
slangaseksmoser: 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 DTRT18:03
slangasek... if I'm not mistaken18:04
slangaseksmoser: 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 archive18:07
smoseri re-set the merge target (you probably saw that)18:08
smosercloud-image i dont think is a meta-package18:08
smoserit is a seed.18:08
smoserand 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 cjwatson18:10
naccslangasek: ack, thanks!18:12
slangaseksmoser: 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 there18:37
slangaseksmoser: STRUCTURE is a different sort of inheritance vs. depending on the metapackage18:37
slangasekanyway, that change LGTM18:38
slangaseknacc: 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
naccslangasek: yes, it's on my todo list for this week or next, I hope19:05
mwhudsondocker seems to have been running in autopkgtests for like 12+ hours, but it says "Running for: 35 min 55 s"19:25
mwhudsondoes it keep failing and getting retried or something?19:26
slangasekmwhudson: where do you see "12+ hours"?19:26
slangasekit's probably a retry of a failed run, or a run that went missing19:27
mwhudsonslangasek: it was running when i went to bed19:27
slangasekok19:27
mwhudsonwhich, sadly, i admit was not 12 hours ago19:27
mwhudsonbut definitely more than 35 mins19:27
slangasekmwhudson: did you definitely see in running, or just 'Test in progress'?19:27
mwhudsonslangasek: it's on http://autopkgtest.ubuntu.com/running.shtml19:28
slangasekyes, it is now19:28
slangasekbut 12 hours ago, was it? :)19:28
mwhudsonand yes, it was there with output and stuff last night too19:28
slangasekok fun19:28
slangasekthen the results were lost, I didn't know that was a thing19:28
mwhudsoni have learnt about the thing where "running" on excuses can actually mean "in the queue behind half of debian"19:28
mwhudsonalso 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 amd6419:30
mwhudsonbut i don't think it's linked from http://autopkgtest.ubuntu.com/packages/d/docker.io/yakkety/ppc64el/19:30
mwhudsoner19:30
mwhudson*failure on ppc64el19:30
slangasek... neat19:31
slangasekmwhudson: pitti should be apprised of these issues; can you file bugs on https://bugs.launchpad.net/auto-package-testing ?19:32
mwhudsonslangasek: ok19:33
mwhudsonhuh it's no longer on running.shtml but it's not on http://autopkgtest.ubuntu.com/packages/d/docker.io/yakkety/amd64/ either19:39
mwhudsonslangasek: is it britney that starts the autopkgtests running?19:40
mwhudsonit sort of seems like the results are getting lost so something is just scheduling them to run again?19:40
slangasekmwhudson: britney triggers them, yes.  britney won't trigger a second time though, so the something else that retriggered is probably a release team member19:41
slangasekmwhudson: so that's likely pitti, but he may not know that the tests ran before and had results lost as he probably batch-retried19:42
mwhudsonah ok19:44
mwhudsonthese tests are cursed, it seems :-)19:44
=== afkthairus is now known as athairus
smoseranyone know what urls 'snap install' hits ?20:29
pittimwhudson: 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
pittimwhudson: thus the test is just looping forever21:00
pittimwhudson: I'm not quite sure yet what to do about that infra-wise, as in general we *do* want to retry on ssh failures21:00
Unit193bdmurray: 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
pittimwhudson: yes, autopkgtest.u.c. browsing is a bit behind, that's on my TODO list21:04
pittimwhudson: the direct log links from britney should be okay though21:04
mwhudsonpitti: uggggh21:14
pittimwhudson: I updated your bug report, I'll ponder this tomorrow21:14
mwhudsonpitti: strange though, britney links to a log for ppc64el but not amd6421:15
pittimwhudson: why strange? as I said, it only loops on ppc64el21:16
pittimwhudson: err sorry, only on amd6421:16
pittimwhudson: the armhf queue just didn't get to it yet (armhf is lagging quite a bit)21:16
pittiand the others have results21:16
mwhudsonpitti: ah i think it *was* looping on ppc64el21:16
pittimwhudson: note that "in progress (always failed)" does not block promotion21:17
mwhudsonpitti: but then managed to fail more catastrophically and earlier, and got properly recorded as a failure21:17
pittimwhudson: it's the armhf test that does21:17
pittimwhudson: ah, could be :)21:17
mwhudsonpitti: yeah i'm not so worried about migration, but it would be nice for these tests to work :-)21:17
mwhudsontianon: ^^21:18
mwhudsonpitti: thanks for the updates21:20
mwhudsonpitti: oh one thing, are the logs for the runs that end with ssh dying kept anywhere?21:20
pittimwhudson: yes, I have them, but they aren't public right now21:20
pittimwhudson: want one?21:20
mwhudsonpitti: please21:21
mwhudsonpitti: i filed https://bugs.launchpad.net/ubuntu/+source/docker.io/+bug/1576419 too21:22
ubottuLaunchpad bug 1576419 in docker.io (Ubuntu) "autopkgtests kill ssh" [Undecided,New]21:22
pittimwhudson: followed up21:24
pittimwhudson: I have the complete logs too, but they are a bit difficult to haul across, and also uninteresting (AFAICS)21:25
mwhudsonpitti: thanks21:25
mwhudsonfair enough21:25
pittibut if you need them, I can get them21:25
mwhudsonpitti: i guess it *could* be OOM?21:25
pittimwhudson: yes, that's possible of course21:25
mwhudsonpitti: how much ram do the instances have?21:25
pittimwhudson: 1.5 GB normally21:25
mwhudsonok21:26
mwhudsonnext step is to run the tests in verbose mode i guess21:26
pittimwhudson: I can add docker.io to "big_tests" which would get them 8 GB21:26
mwhudsonpitti: if that's easy and not too disruptive it might be worth a try?21:26
pittibut if I do that now before going to bed, I risk blocking the quota for five runners perpetually21:27
pittimwhudson: *shrug* ok, done now21:28
pittiI can do another half hour21:28
mwhudsonhm well21:28
* pitti kills the currently running test21:28
mwhudsonpitti: are you the only one who has access to the infrastructure?21:29
pittimwhudson: no; Laney should know his way fairly well; infinity, slangasek and some others have too, but didn't get much hands-on training21:30
mwhudsonpitti: 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
slangasekyes, I have read the autopkgtest manual ;)21:31
slangasekbut oh, we're talking about the infrastructure, I would have to hunt for that21:32
pittihttps://wiki.ubuntu.com/ProposedMigration/AutopkgtestInfrastructure FTR21:32
pittianyway, next runner will grab it21:33
pittiI 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
mwhudsonnext question!21:35
mwhudsoni want to SRU golang 1.6.2 to xenial unchanged21:36
pittimwhudson: http://autopkgtest.ubuntu.com/running.shtml#pkg-docker.io is now running in an m1.large instance21:36
pittiand promptly hit the quota ceiling (but it will retry until it gets enough)21:36
mwhudsonis it considered best to just update the changelog of the yakkety version and upload that21:36
pittimwhudson: -backports?21:37
mwhudsonor put a new entry on top of the xenial version?21:37
mwhudsonpitti: no, -updates21:37
dokopitti, any idea about the open-vm-tools failure?21:37
pittiwell, unless you can make sure this is 100% backwards compatible -- we shouldn't introduce new FTBFS with an SRUed toolchain21:37
slangasekmwhudson: 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
mwhudsonpitti: golang upstream is super conservative about point releases21:38
pittidoko: not from the logs, this needs some deeper investigation; not today any more though (from me)21:38
pittiit's almost midnight and I'm still swamped in pings and new bug reports :)21:38
dokohmm, open-vm-tools doesn't even have a debian/tests dir?21:39
pittimwhudson: purely the changelog issue, I'd add a new record with " * backport yakkety release" and append a ~16.04.121:39
pittidoko: no, it's the dkms autodep8 test21:39
dokoahh21:39
pittimwhudson: aside from teh fact that yakkety has the same version than xenial21:39
dokoso then it's kernel module breakage on amd6421:40
dokoapw, ^^^21:40
mwhudsonpitti: append a new record to which changelog? :)21:40
pittimwhudson: well, golang's?21:40
mwhudsonpitti: i meant xenial's or yakkety's?21:40
mwhudsonoh and i should do trusty too21:40
pittimwhudson: 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 really21:41
mwhudsonpitti: ok21:41
mwhudsonpitti: thanks21:41
apwdoko. yep working on it ...21:41
pittimwhudson: oh, err:21:41
pitti golang | 2:1.6-1ubuntu4                 | yakkety                   | all21:41
pitti golang-1.6 | 1.6.2-0ubuntu2     | yakkety                 | source, all21:42
pittimwhudson: this is confusing21:42
mwhudsonwaait21:42
mwhudsongolang should have been removed21:42
mwhudsonoh no, binaries21:42
mwhudsoni should have said golang-1.6 above sorry21:42
mwhudsonhttps://launchpad.net/ubuntu/+source/golang-1.621:42
pittiright, the other was golang-defaults, sorry21:42
pittimwhudson: no, m1.large didn't help, reverting the big_tests21:51
mwhudsonpitti: 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 not21:52
mwhudsoni guess i should try to repro on ec2 or someting21:52
pittimwhudson: would also be interesting to repro it locally with qemu, and ssh into teh instance while the test is running21:52
mwhudsonyeah, or that21:52
pittimwhudson: if it's your only adt-run with qemu, it'll be port 22000 on localhost (ubuntu:ubuntu)21:53
mwhudsonoh yeah, i made an image when we were looking at juju21:53
nacchallyn: something with DEB_BUILDHOST?21:53
nacchallyn: don't see why that should matter, though21:54
nacchallyn: and nm, i see where it's defined now21:55
hallynnacc: yeah it's weird...21:55
hallynwell i need to get the animals fed before they tear each other apart - bbl21:56
pittimwhudson: sorry, port 1002221:56
pitti22000 is my "run this VM" script21:56
pittimwhudson: running this now: adt-run --apt-pocket=proposed -U docker.io --- qemu /srv/vm/adt-yakkety-amd64-cloud.img21:57
mwhudsonpitti: oh ok21:58
mwhudsoni hadn't even gotten started really :)21:58
pittimwhudson: well, and the VM doesn't boot after dist-upgrading to -proposed :/21:58
* pitti re-runs without -U22:02
pittimwhudson: wow, the docker.io tests install the entire build toolchain22:02
mwhudsonthey're pretty heavy, yeah22:04
pittimwhudson: wohoo, what are these tests doing??22:11
pitti$ mount22:11
pittimount: failed to read mtab: No such file or directory22:11
pittithere's no proper /proc any more, "mounts" is a dead symlink22:11
mwhudsonthere's definitely a reason they have all the scary control flags they do22:11
pittimwhudson: 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
mwhudsonpitti: haha ok, i didn't realize that they were /that/ destructive22:12
pittiStep 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-test22:12
pitti ---> Running in e064dc8c380922:12
pittiContainer command not found or does not exist.22:12
pitti./hack/make.sh: line 258: local: can only be used in a function22:12
pittiit has hung here for several minutes now22:12
mwhudsonoh right22:13
pittinothing in dmesg22:13
mwhudsonmy experience is that once you get that "local: can only be used in a function" message, the tests are dead22:13
pittianyway, if you can investigate this in local qemu, that'd be great -- really bedtime here, sorry22:13
mwhudsonpitti: but it didn't kill ssh?22:13
pittimwhudson: not yet, now22:13
mwhudsonpitti: sleep well?22:13
pittis/now/no/22:13
mwhudsonpitti: sleep well!, rather22:13
mwhudsoni'll try to poke with ssh22:13
pittimwhudson: but it didn't even get to running the tests that I saw in the log when that happened22:14
mwhudsoner qemu rather22:14
mwhudsoncan't type this morning22:14
pittimwhudson: http://paste.ubuntu.com/16120559/22:14
pittimwhudson: that's how far I got with the local run22:14
pittiI had two screenfuls more in the production log22:15
dokowhy 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/963966122:15
dokoand forgot to say, it builds locally ...22:16
slangasekdoko: because it wants to assert not is fail, and it is fail22:16
slangasekdoko: did you try a straight retry?22:17
dokotwo22:17
slangasekfun22:17
dokoone more ...22:17
pittidoko: your local mirror might not have new enough -proposed packages in sbuild?22:19
pittianyway, -EBEDTIME, really; /me waves22:20
sarnoldsee you ina few hours :)22:20
dokopitti, not using local mirrors for that reason22:21
slangasekdoko: are you building -B or -b?22:21
dokoslangasek, -b22:22
dokofailed again22:29
mwhudsonoops forgot to build check my golang upload :(22:32
dokogiving up on cgal for now ...22:45
wgranthallyn: I have git mirroring half done, but currently on hold due to some more important work.23:24
sbeattiedoko: 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
sbeattiedoko: 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!