| shoutme | pitti: should gssd.service just have a ConditionVirtualization=!container added? | 00:00 |
|---|---|---|
| shoutme | maybe we should just allow the rpc mounts... | 00:05 |
| shoutme | but adding that to run-rpc_pipefs.service does work | 00:07 |
| === shoutme is now known as hallyn | ||
| nacc | slangasek: apologies for the delay, i think i've got the split main/universe build for php7.0 working with just a one-variable chagne between the two src packages ... build & testing now, will let you know | 00:33 |
| nacc | jgrimm: checksecurity merge request sent | 00:35 |
| nacc | smoser: thanks for your help! | 00:35 |
| === dasjoe_ is now known as dasjoe | ||
| === psivaa_ is now known as psivaa | ||
| === balkamos_ is now known as balkamos | ||
| === daxcat is now known as dax | ||
| jgrimm | nacc: cool, thanks! | 01:46 |
| === juliank is now known as Guest26968 | ||
| === juliank_ is now known as juliank | ||
| === pepee- is now known as pepee | ||
| stgraber | Pici: found the issue with the jenkins image importer, fixed now, it's processing its backlog which should take quite a few hours (about 200 images to download, unpack, update, repack, sign, ...) | 03:27 |
| stgraber | pitti: ^ | 03:27 |
| stgraber | Pici: sorry, bad tab completion :) | 03:27 |
| === tsimonq2alt is now known as tsimonq2- | ||
| === tsimonq2- is now known as tsimonq2 | ||
| pitti | stgraber: yay, thanks for fixing the image builds | 04:05 |
| pitti | Good morning | 04:05 |
| darkxst | can someone nuke this from the sponsorship queue https://code.launchpad.net/~maozhou/ubuntu/utopic/tomboy/bug-12345/+merge/283581 | 04:33 |
| darkxst | it was just someone playing around with merges by the looks of it | 04:34 |
| pitti | darkxst: set to "rejected", that should do | 04:52 |
| darkxst | pitti, thanks! | 04:52 |
| === marcusto_ is now known as marcustomlinson | ||
| === kitterma is now known as ScottK | ||
| darkxst | @pilot in | 05:38 |
| === udevbot changed the topic of #ubuntu-devel to: Wily (15.10) Released! | Archive: open | Devel of Ubuntu (not support or app devel) | build failures: http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of precise-wily | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: darkxst | ||
| === wilhelm.freenode.net changed the topic of #ubuntu-devel to: Wily (15.10) Released! | Archive: open | Devel of Ubuntu (not support or app devel) | build failures: http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of precise-wily | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: | ||
| pitti | yofel, debfx: both our telepathy-qt and telepathy-qt5 packages are wildly out of date, use gstreamer 0.10 etc., and it seems the reason for the split is long gone: Debian's telepathy-qt builds both qt 4 and qt5 packages | 05:51 |
| pitti | can we just sync/merge this? | 05:51 |
| pitti | yofel, debfx: see bug 1538772, keeping notes there | 05:53 |
| ubottu | bug 1538772 in telepathy-qt5 (Ubuntu) "Stop build-depending on libfarstream-0.1-dev" [Undecided,Confirmed] https://launchpad.net/bugs/1538772 | 05:53 |
| === tjaalton_ is now known as tjaalton | ||
| pitti | yofel, debfx: I put a merged test package into my PPA, some testing would be great | 06:16 |
| === mfisch is now known as Guest38484 | ||
| cpaelzer | good morning | 06:28 |
| darkxst | anyone able to add gitg to desktop-extra packageset (I am sure it was meant to be done already, but apparently not) | 07:07 |
| tjaalton | how come https://launchpad.net/ubuntu/+source/xserver-xorg-video-amdgpu shows the package is in universe when apt-cache policy shows the binary is in main? | 07:29 |
| pitti | xserver-xorg-video-amdgpu | 1.0.1-1build2 | xenial | amd64, arm64, armhf, i386, powerpc, ppc64el, s390x | 07:37 |
| pitti | xserver-xorg-video-amdgpu | 1.0.1-1build2 | xenial/universe | source | 07:37 |
| pitti | xserver-xorg-video-amdgpu-dbg | 1.0.1-1build2 | xenial/universe | amd64, arm64, armhf, i386, powerpc, ppc64el, s390x | 07:37 |
| pitti | tjaalton: wrong overrides; where is this supposed to be? | 07:37 |
| tjaalton | main | 07:38 |
| tjaalton | https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video-amdgpu/+bug/1543659 | 07:38 |
| ubottu | Launchpad bug 1543659 in xserver-xorg-video-amdgpu (Ubuntu) "MIR: xserver-xorg-video-amdgpu" [High,Fix released] | 07:38 |
| pitti | tjaalton: ok, fixed | 07:38 |
| tjaalton | thanks! | 07:38 |
| dax | tjaalton: been fielding support questions about fglrx recently. checking i'm reading right: no more fglrx in xenial onwards, right? | 07:40 |
| tjaalton | dax: right | 07:40 |
| tjaalton | amd finally confirmed it in public | 07:40 |
| dax | thanks (and thanks for getting rid of it, though it'll make #ubuntu fun for a cycle or two i'm glad it's gone) | 07:40 |
| tjaalton | there's going to be a userspace blob at some point, but it's only for the amdgpu stack | 07:41 |
| dax | *nod* | 07:41 |
| dholbach | good morning | 07:41 |
| dax | i've been using radeon for ages and have been reading about amdgpu. just wasn't sure if it was yet another temporary delay in xorg compat or if it was permanent | 07:41 |
| tjaalton | http://www.phoronix.com/forums/forum/phoronix/latest-phoronix-articles/857070-ubuntu-is-deprecating-fglrx-catalyst-in-16-04-lts/page6?_=1457549209785 | 07:41 |
| tjaalton | comments by bridgman and twriter | 07:42 |
| tjaalton | I emailed tim yesterday and begged that they'd make it public :) | 07:42 |
| tjaalton | there's probably going to be a more formal announcement too | 07:43 |
| tjaalton | now if only it'd be ok to build a fully featured mesa and then just put some binaries in universe that'd be cool (vaapi, opencl..), but main/universe split makes it impossible | 07:46 |
| pitti | wgrant: hey William, how are you? | 07:48 |
| pitti | wgrant: I did a boo-boo with process-removals (had some 'y's in the input buffer) | 07:49 |
| pitti | wgrant: can I un-remove a package from xenial, or do I need to reupload/rebuild? | 07:49 |
| wgrant | pitti: Morning. | 07:52 |
| wgrant | pitti: You can use copy-package to revive it. | 07:52 |
| pitti | wgrant: copy from where then? | 07:52 |
| wgrant | pitti: copy-package --from-suite=xenial --to-suite=xenial -e 1.2.3-4 -b --auto-approve --force-same-destination somepackage | 07:53 |
| pitti | wgrant: hah, lol; thanks | 07:53 |
| wgrant | The -e picks a version other than the current one. | 07:53 |
| wgrant | So it doesn't matter if it's published or not. | 07:54 |
| pitti | yofel, debfx: qtmobility got removed in Debian, only rdepends in Ubuntu is artikulate; is this still something we want to keep? | 08:03 |
| pitti | (it also uses the obsolete gstreamer0.10) | 08:04 |
| debfx | pitti: qtmobility-dev likely just needs to be dropped from build-deps | 08:10 |
| yofel | ^ | 08:10 |
| debfx | where does it use gstreamer0.10? I only see a dep on libqt5gstreamer-1.0-0 | 08:12 |
| pitti | Comment: (From Debian) ROM; will not get ported to GST 1.0, superseded by Qt5; Debian bug #802642 | 08:13 |
| ubottu | Debian bug 802642 in ftp.debian.org "RM: qtmobility -- ROM; will not get ported to GST 1.0, superseded by Qt5" [Normal,Open] http://bugs.debian.org/802642 | 08:13 |
| pitti | that's what the Debian removal bug says | 08:13 |
| pitti | and it also seems generally obsolete | 08:13 |
| pitti | debfx: libqtmultimediakit1 depends on libgstreamer0.10-0 | 08:14 |
| debfx | right, so applying http://anonscm.debian.org/cgit/pkg-kde/applications/artikulate.git/commit/?id=609f5b1 and killing qtmobility is the solution | 08:16 |
| pitti | debfx: ah, thanks; so good to remove? | 08:18 |
| debfx | qtmobility? sure. would be nice if someone could fix artikulate before. | 08:25 |
| darkxst | @pilot out | 08:30 |
| pitti | debfx: uploaded/removed | 08:36 |
| pitti | xnox: hey! do you have some time to look at the s390x test failures of upstart? | 08:38 |
| jamespage | please could an archive admin promote python-pika-pool to main? MIR bug 1552827 approved - the old version oslo.messaging in the release pocket is causing test failures right now for openstack testing | 08:41 |
| ubottu | bug 1552827 in python-pika-pool (Ubuntu) "[MIR][FFE] Please sync python-pika-pool (0.1.3-1) from Debian (unstable)" [Undecided,Fix committed] https://launchpad.net/bugs/1552827 | 08:41 |
| pitti | jamespage: it's not on http://people.canonical.com/~ubuntu-archive/component-mismatches.txt -- you need to make something in main depend on it | 08:46 |
| pitti | otherwise the next AA will demote it back | 08:46 |
| jamespage | pitti, python-oslo.messaging is depwaiting on it | 08:47 |
| jamespage | letme check again | 08:47 |
| pitti | jamespage: ah sorry, it's on http://people.canonical.com/~ubuntu-archive/component-mismatches-proposed.txt | 08:48 |
| jamespage | pitti, yup | 08:48 |
| pitti | promoted | 08:48 |
| jamespage | pitti, I'll also need a binary only of python3-pika please | 08:49 |
| jamespage | source already in main | 08:49 |
| pitti | jamespage: I did all the ones on the above list, including that | 08:50 |
| jamespage | pitti, thankyou | 08:52 |
| pitti | nacc: php5.6 got removed in Debian, do we want to follow suit? I assume yes as you're heading for 7.0, but want to confirm | 09:31 |
| pitti | nacc: well, I remove it for now, our only change was an FTBFS fix; I can bring it back if necessary | 09:33 |
| rbasak | nacc won't be up for a while. I know the plan is to remove 5.6. I didn't know what stage nacc was at for that though. | 09:33 |
| rbasak | Presumably all the reverse deps are gone now? | 09:33 |
| pitti | * php-redis (for php5.6-dev) | 09:34 |
| pitti | * php5.6-json (for php5.6-dev) | 09:34 |
| pitti | rbasak: php5.6-json was also removed (I just did that in Ubuntu) | 09:34 |
| pitti | rbasak: and php-redis needs a rebuild against php7, I just synced the new Debian package | 09:34 |
| pitti | rbasak: i. e. yes, all gone | 09:34 |
| rbasak | Not sure about php-redis. php5.6-json is 5.6-specific. 7.0 has a replacement json that doesn't need a separate source package IIRC. | 09:34 |
| pitti | I also removed a whole bunch of obsolete php-* stuff (via debian removals), should help a bit | 09:35 |
| pitti | (I also synced dh-php and php-igbinary, as php-redis needs those) | 09:37 |
| pitti | Unit193: do you still care about dvdstyler? it's the only thing which still holds the obsolete wxsvg in Ubuntu (got removed in Debian bug 813151) | 09:49 |
| ubottu | Debian bug 813151 in ftp.debian.org "RM: wxsvg -- RoM; unmaintained, library without rev deps" [Normal,Open] http://bugs.debian.org/813151 | 09:49 |
| Unit193 | I did the last upload because it didn't function at all, afact there's no new version that ports from wxsvg. | 09:55 |
| pitti | Unit193: right, my question was in the direction of "is dvdstyler obsolete and should be removed?" or is there still some upstream for it | 10:20 |
| Unit193 | pitti: Ah! Well they did just release a new version in Jan, but I don't actually know much more than that, never used it myself. Sorry. | 10:21 |
| * pitti tries to find some ubuntustudio folks | 10:23 | |
| pitti | zequence: ^ hey, how are you? do you know about dvddstyler? ^ | 10:24 |
| pitti | juliank: apparently some amd64-ism crept into apt's test suite? tests now fail on anything except amd64 | 10:33 |
| pitti | dpkg: error processing archive /tmp/tmp.tKhfFn1igl/aptarchive/pool/pkgb_1_amd64.deb (--unpack): | 10:33 |
| pitti | package architecture (amd64) does not match system (i386) | 10:33 |
| juliank | pitti: Yes, I'm aware of that and forwarded it yesterday to DonKult | 10:33 |
| pitti | juliank: ah, danke | 10:33 |
| juliank | pitti: In the meantime, ignoring them is the way to go. (Problem being that while we set APT's architecture, we do not configure dpkg's architecture, but install packages, which fails) | 10:34 |
| juliank | pitti: Fixed in https://anonscm.debian.org/cgit/apt/apt.git/commit/?id=e457c94 | 10:46 |
| pitti | juliank: yay you, danke | 10:47 |
| juliank | bb | 10:47 |
| juliank | oops | 10:47 |
| juliank | i386 also failed the (flaky) download progress test again | 10:48 |
| xnox | pitti, upstart is not used on s390x at all =) | 10:55 |
| xnox | it's only used in desktop sessions, and there are no desktops on s390x. | 10:55 |
| pitti | xnox: oh, so it's not even installed by default? | 10:55 |
| pitti | xnox: indeed, only rdepends on my system is unity-greeter (ugh, there should be some more for sure..) | 10:56 |
| pitti | xnox: you mean we could/should remove the s390x binaries? | 10:56 |
| xnox | pitti, i don't think we will like an arch skew, nor the build depends skew (there are things that depend on libupstart et.al.) | 10:57 |
| xnox | but it's definitely not supported =) | 10:57 |
| pitti | well, it's ftbfs on s390x; we could also disable the tests on s390x | 10:57 |
| xnox | i can look at the test failures out of interest. | 10:57 |
| pitti | xnox: oh, I don't have libupstart1 installed | 10:57 |
| xnox | however, upstart is a good kernel tester. | 10:57 |
| pitti | only libupstart-dev depends on it | 10:58 |
| xnox | horum. there should have been deps in app-launchers and things, unless they have switched to dbus direct. | 10:59 |
| smoser | pitti, around? i've got some systemd networking questions. | 11:05 |
| smoser | https://public.etherpad-mozilla.org/p/cloud-init-networking has some background. | 11:05 |
| smoser | see description around line 39 there. | 11:05 |
| zequence | pitti: Seems my assistance was not needed :) | 11:06 |
| pitti | zequence: why? there was no other answer about this so far (nor an upload) | 11:07 |
| pitti | smoser: (be with you in a sec) | 11:07 |
| smoser | k. thanks. | 11:07 |
| pitti | zequence: i. e. it's still "do we want to keep and update dvdstyler or remove it" | 11:07 |
| zequence | pitti: Oh, I thought someone was on it | 11:07 |
| zequence | Ah, right. Yes, I'll check with Len Ovens, who is the one in our team who is most informed on that package | 11:08 |
| flexiondotorg | smb, ogasawara, seb128 Hello Pilots - If you could take a look at my sponsoring requests during your pilot sessions today I'd really appreciate it :-) | 11:10 |
| pitti | smoser: these steps seem fine to me; let me see where cloud-init-local hooks in right now, i. e. that it's a proper place for this | 11:11 |
| smoser | http://bazaar.launchpad.net/~cloud-init-dev/cloud-init/trunk/view/head:/systemd/cloud-init-local.service | 11:12 |
| zequence | pitti: I'll get back to you about the package within a day or so. Just double checking with Len first. | 11:12 |
| pitti | smoser: ah, was just doing "systemctl cat" on a cloud instance | 11:12 |
| muktupavels | flexiondotorg, did you test compiz? why did not you update your branch for review? | 11:12 |
| pitti | zequence: great, thanks a lot for your efforts | 11:12 |
| flexiondotorg | muktupavels, Because I work on this stuff in my spare time and my time is limited :-( | 11:13 |
| flexiondotorg | muktupavels, It is 2nd on my list though. | 11:14 |
| smoser | pitti, thanks for systemctl cat. did not know. | 11:14 |
| pitti | smoser: so, cloud-init is after=local-fs.target, but at first sight I don't see a strict enough Before= that would cause networking stuff to wait? | 11:14 |
| smoser | yeah. at the moment networking is not blocked at all. | 11:14 |
| pitti | smoser: "systemctl show -p After cloud-init-local" is also quite useful | 11:15 |
| pitti | smoser: as that shows you the properties "all combined" | 11:15 |
| smoser | cloud-init-local needs filesystems (and yes, /usr) | 11:15 |
| pitti | i. e. if some other unit bar.foo does Before=foo", then showing foo.service will show After=bar | 11:15 |
| pitti | smoser: can/should we just redefine cloud-init-local to block bringup of network, or is there stuff happening there that already needs network? | 11:16 |
| pitti | smoser: (if so, it would be wrong as it doesn't depend on networking, but still asking) | 11:16 |
| smoser | no. it should not need network | 11:16 |
| smoser | it looks at local sources of information such as attached disks or stuff in the filesystem | 11:16 |
| smoser | or as described there to add 'ip=' flag | 11:17 |
| flexiondotorg | muktupavels, I see you've got a merge proposal in. | 11:17 |
| pitti | smoser: btw, this might not run as early as you think, as it doesn't have DefaultDependencies=no | 11:17 |
| flexiondotorg | muktupavels, What help do you require from me to progress this? | 11:17 |
| pitti | smoser: in old SysV terms, this runs in rc2, not in rcS (which you'd get with DefaultDeps=no) | 11:17 |
| muktupavels | flexiondotorg, what merge proposal? | 11:17 |
| flexiondotorg | https://code.launchpad.net/~albertsmuktupavels/compiz/gwd-marco-gsettings/+merge/287820 | 11:18 |
| muktupavels | flexiondotorg, just merge it in your branch and test it. I pushed that only as example. | 11:19 |
| smoser | yeah, goal is "as early as i can pallet". i think i'm probably ok. . i need /var/lib/cloud, /usr/bin/cloud-init really want /run . | 11:20 |
| pitti | smoser: /run is always there, that's no problem | 11:20 |
| pitti | smoser: do you support craziness like /var on NFS for cloud-init? | 11:20 |
| pitti | (as that would be a circular dependency then) | 11:20 |
| pitti | for c-i-local.service | 11:21 |
| smoser | at this point i dont think so. | 11:21 |
| smoser | i think if someone really wanted such a thing, then we might try to get there, but it wouldnt work right now. | 11:21 |
| pitti | smoser: so, I left some notes in the pad | 11:22 |
| smoser | pitti, thanks. wrt seriallized boot, you may be interested in the generator i added, which means you can completely disable cloud-init (well,. other than the generator running) | 11:24 |
| pitti | smoser: line 70 → is that a systemd generator? or some other kind? (as these run even earlier) | 11:24 |
| smoser | yeah, the generator is what allows you to disable cloud-init entirely | 11:25 |
| smoser | i'd also like at some point it to be able to change cloud-init to only run in a way that is guaranteed to not foobar your ENI | 11:25 |
| * pitti yays lots of shell in early boot :) | 11:26 | |
| pitti | smoser: any chance to at least drop the shell parsing of /proc/cmdline? | 11:26 |
| pitti | you can add ConditionKernelCommandLine= to any unit to run (or not run) it for certain kernel command line options | 11:26 |
| pitti | smoser: is =enabled and =disabled already released API? (most other kernel options use =1 or =0, or no value at all) | 11:28 |
| smoser | pitti, i'm not opposed to changing =enabled or =disabled. to =1 or =0, but one seems less magic. | 11:32 |
| smoser | the kernel command line parsing also supports reading the environment variable which could be set in lxd (right now lxc does not mask /proc/cmdline) | 11:32 |
| smoser | i dont think performance is likely an issue in reading proc cmdline. the logging in that script probably is much more a performance issue | 11:34 |
| smoser | actually, the one fork i make (systemd-detect-virt) is probably 90% of the time for that functionality | 11:36 |
| pitti | smoser: ConditionKernelCommandLine= actually does just that | 11:37 |
| pitti | smoser: if it's booting on a real kernel, it parses /proc/cmdline, otherwise it takes the argv of pid1 | 11:38 |
| pitti | i. e. lxc's flavor of a "kernel"(ish) command line | 11:38 |
| pitti | and there's ConditionVirtualization= which also avoids the fork | 11:38 |
| pitti | (but I think you don't actually need that | 11:38 |
| flexiondotorg | muktupavels, OK, will do. | 11:39 |
| pitti | smoser: anyway, that's quibbling over less code/optimizing etc; I guess the important bit here is the Before=network-pre.target (and moving earlier into the boot) of c-i-local? | 11:40 |
| smoser | yeah. | 11:40 |
| pitti | smoser: where does this $KERNEL_CMDLINE thing come from? | 11:40 |
| smoser | it would allow you to set that in lxc's pid1 | 11:41 |
| smoser | i dont know that the argv of pid1 would be sufficient or not | 11:41 |
| smoser | can i run '/sbin/init cloudinit=1' and systemd not be bothered by that ? | 11:41 |
| smoser | KERNEL_CMDLINE is not standardized in any way. i picked an environment variable name. if there is a more appropriate one, good with that. | 11:43 |
| pitti | smoser: well, "bothered", that's how every init is called; it will of course pick out stuff like systemd.log-level or so, but it ignores unknown arguments, yes | 11:43 |
| pitti | (or quiet/debug/emergency) | 11:44 |
| pitti | so you can e. g. do sudo lxc-start -n adt-wily /sbin/init rescue -F | 11:44 |
| pitti | starting a container or a kernel isn't much different wrt. kernel command line parsing really | 11:44 |
| pitti | for clarity, the -F belongs to lxc-start, so like: sudo lxc-start -F -n adt-wily /sbin/init debug cloudinit=1 | 11:45 |
| pitti | systemd will recognize the "debug" as somethign it knows, and just ignore the cloudinit= | 11:45 |
| smoser | ok. i'll consider that, adn the systemd conditions in the generator too | 11:45 |
| smoser | 2 things i'd like generally... | 11:46 |
| pitti | smoser: generators don't have conditions (as they are not units), they always run | 11:46 |
| smoser | i'd like to be able to read "is this a container" (systemd-detect-virt) without a fork | 11:46 |
| pitti | well, you can programatically check for stuff of course | 11:46 |
| pitti | i. e. my point is, I believe you don't need the generator at all | 11:46 |
| smoser | i'd like to be able to read the cmdline without a fork too (reading /proc/1/cmdline and /proc/1/environ are null terminated. easy for anything but shell) | 11:47 |
| pitti | I think this boils down to ConditionKernelCommandLine=!cloud-init=disabled | 11:47 |
| smoser | maybe, yeah. | 11:47 |
| pitti | and you don't really need the dynamic enaling then, as the condition will already make cloud-init*.service a no-op if disabled | 11:48 |
| pitti | and the detect-virt goes away as ConditionKernelCommandLine= DTRT for both "real" kernels and container pid 1's | 11:49 |
| smoser | and ConditionPathExists! | 11:49 |
| smoser | pitti, oh. the other thing i thouht i got from the generator. | 11:49 |
| smoser | was that i have no bottlnecks in boot | 11:49 |
| smoser | ie, one thing runs and then if disabled, the others do not run | 11:50 |
| smoser | rather than having the bottleneck come down to cloud-init-local and then checking for that file | 11:50 |
| pitti | well, they don't actually fork/run anything | 11:51 |
| pitti | "they" -> Condition* | 11:51 |
| smoser | no. but they force a bottleneck | 11:51 |
| smoser | ie, if cloud-init-local blocks networkign coming up, then there is a bottleneck at boot down to that one job | 11:51 |
| smoser | and then another at the point where i want cloud-init to run | 11:52 |
| pitti | ah, you'd make network-pre.target run after local-fs.target, yes | 11:52 |
| smoser | where with the generator i thought i incur the single cost of the generator and if disabled, then cloud-init has *no* affect on boot | 11:52 |
| pitti | which is not really a biggie as everything that actually touches network config also needs After=local-fs.target | 11:52 |
| smoser | well, then i'm free to do what ever silly things i want to do to boot. | 11:54 |
| pitti | smoser: well, cloud-init-local.service really doesn't do much serialization (other than network-pre.target after local-fs.target); I guess the stating and symlinking and parsing that you do there is probably a dozen times heavier :) | 11:54 |
| smoser | but i think its probably really a very small optimization. | 11:54 |
| smoser | also cloud-init.service forces some bottlenecks. | 11:55 |
| pitti | for sshd.service etc. | 11:55 |
| smoser | its fine. i think this is mostly in the terms of "small" then. i was more concerned that cloud-init's presense on disk had negative affects on boot when it wasn't utilized. | 11:55 |
| smoser | i'd like for peple to not think 'cloud-init sucks, purge it' | 11:55 |
| smoser | but rather cloud-init could be useful, i'll just disable it. | 11:55 |
| smoser | you've convinced me its a small thing, and i'm not opposed to looking into your path for sure. | 11:56 |
| pitti | smoser: so cloud-init.service serializing ssh.service after network-online.target is the main serialization that I see | 11:56 |
| smoser | (and i have another email to you about ssh.service and pollinate) | 11:56 |
| pitti | smoser: for that a generator might make sense | 11:56 |
| smoser | i do want cloud-init.service to generally block everything it can | 11:58 |
| smoser | for just about all of boot to serialize on it (and cloud-confnig.service) so that they can affect as much of boot as possible. | 11:58 |
| === _salem is now known as salem_ | ||
| smoser | pitti, that make sense? generally speaking i *want* to serialize boot. so that users can provide user-data that will run "as soon as networking is up" and affect other parts of boot. | 12:04 |
| smoser | unfortunately, it seems that systemd is not as dynamic as upstart was in that regard | 12:04 |
| smoser | they can't just drop new units in and have them consumed via inotify | 12:05 |
| pitti | smoser: sure; you can hook into network-online.target to block that (and everything that waits on it) | 12:05 |
| smoser | how can i hook into it ? | 12:05 |
| pitti | right, you need to enable new units | 12:05 |
| pitti | smoser: Before=network-online.target | 12:05 |
| pitti | (or whichever other target you want to "block") | 12:06 |
| smoser | and that will run when networking is up | 12:06 |
| smoser | but block anything else that would need it ? | 12:06 |
| pitti | of course you can't then simultaneously have After=network-online.target as it does rigth now | 12:06 |
| pitti | you could add an After=networking.service (for ifupdown), if you don't care about other methods | 12:07 |
| smoser | so cloud-init.service will need to use the configured networking to go looking for a datasource | 12:07 |
| pitti | then you'd have networking.service -> cloud-init -> network-online.target -> everything that depends on that | 12:07 |
| smoser | so yeah, thats what i want. but that is only accomplishable on ubuntu ? | 12:07 |
| pitti | but of course not all services depend on that, so if you really want to affect *all* services you can only run a generator | 12:08 |
| pitti | (but then have literally no assumptions) | 12:08 |
| xnox | .... and dhcp request sent with "wrong" hostname.... | 12:08 |
| smoser | xnox, well, you'll be happy to know that on azure, they bounce the dhcp interface so that it does it with the right one | 12:08 |
| pitti | smoser: network-online (and pretty much all other targets) are cross-distro; *.service are often distro specific, e. g. networking.service is "ifupdown" | 12:08 |
| xnox | smoser, excellent. I guess i just need s390x on azure then =) | 12:09 |
| pitti | smoser: so indeed if you run on a distro that doesn't have ifupdown, you can't use this (but they your network config bit wouldn't work in teh first place -- you probably want to ship a networkd config or somethign such) | 12:09 |
| smoser | pitti, yeah. well, a cross distro blocking "network is up" event is what i'm after. | 12:09 |
| pitti | smoser: that's network-online.target, pretty much | 12:09 |
| smoser | yeah. other than the blockign part :) | 12:10 |
| pitti | smoser: but I meant, a lot of services don't wait for that, but already start before | 12:10 |
| smoser | pitti, you've been so very helpful, thank you. | 12:10 |
| xnox | there is a generic event for "network is available" network-online.target, but things that provide network block that, and don't create an alias... | 12:10 |
| pitti | say, postgres or ssh | 12:10 |
| pitti | smoser: the blocking is your decision (adding a Before=n-o.t) | 12:10 |
| xnox | it could be networkd, networkmanager, ifupdown, what not. So I don't think there is a generic way to block /those/ things that configure the network. | 12:11 |
| xnox | unless you opportunistically encode all of their names. | 12:11 |
| pitti | xnox: yeah, that'd be network.target | 12:11 |
| pitti | (sorry, I thought you meant "use the network") | 12:11 |
| xnox | pitti, i thought that e.g. "before=network.target" unit, may still run in between say networkd and network.target. | 12:12 |
| xnox | as e.g. networkd is simply before network.target.... no? | 12:12 |
| smoser | well, yeah. i want to be able to run code when the network is up that basically blocks all other code that would expect the network to be up. | 12:12 |
| smoser | but i want to not know what brought that networking up | 12:12 |
| smoser | i want to be special! | 12:12 |
| xnox | ah. | 12:12 |
| pitti | xnox: right, sorry, network-pre | 12:12 |
| pitti | you are talking about two different things | 12:12 |
| xnox | pitti, oh, that one, ok. | 12:12 |
| xnox | right. | 12:12 |
| pitti | smoser talks about "using the network" (but after configuring it) -> network-online.target | 12:13 |
| pitti | xnox talks about "things that bring up interfaces" (network-pre.target) | 12:13 |
| smoser | yes. i need both. | 12:13 |
| smoser | cloud-init-local before network-pre.target | 12:13 |
| smoser | and | 12:13 |
| smoser | cloud-init after network-online.target | 12:14 |
| smoser | but what i want is | 12:14 |
| smoser | cloud-init=network-online.target | 12:14 |
| pitti | smoser: right, the -local bit should run very early (as said in the pad, that shows how to put it earlier) | 12:14 |
| xnox | you can make cloud-init to be required by network-online.target, and just wait for network to be up. | 12:14 |
| xnox | because that target is a blocking one already. | 12:14 |
| smoser | hm.. | 12:15 |
| pitti | well, depends | 12:15 |
| * xnox with his upstartish ways of doing things | 12:15 | |
| pitti | stuff like postgres or haveged or whatnot isn't caring about network | 12:15 |
| smoser | right. somet hings i can't affect. thats fine. | 12:15 |
| pitti | so those things need to be configured in -local then | 12:15 |
| xnox | or local should install a firewall rule =) har har | 12:16 |
| pitti | smoser | cloud-init=network-online.target | 12:16 |
| pitti | smoser: ^ what does that mean? | 12:16 |
| smoser | Before and After | 12:16 |
| smoser | :) | 12:16 |
| pitti | well, a target is a synchronization point, it doesn't "do" anything | 12:16 |
| pitti | i.e. you can run before or after, but not "in" it | 12:17 |
| smoser | right. but i need to run after it is there and want to stop evyerthing else that would run 'After' it | 12:17 |
| xnox | and by default that target is empty, and a thing that brings up network has a helper to say "network is online". | 12:17 |
| pitti | that's similar to upstart, yuou can either do "on starting" or "on started" (before or after) | 12:17 |
| xnox | so on ubuntu | 12:17 |
| smoser | right. | 12:17 |
| pitti | smoser: that concept of "I want to be the only one" doesn't exist in any init system any more | 12:18 |
| xnox | network-online.target.wants -> [networking.service, NetworkManager-wait-online.service] | 12:18 |
| pitti | (not even sysv with inssersv) | 12:18 |
| pitti | because, what happens if there's another package which wants to be the only one? :-) | 12:18 |
| xnox | thus on ubuntu you want to be (a) wantedby -online.target (b) after = [networking.service, NetworkManager-wait-online.service] | 12:18 |
| smoser | pitti, you're completely missing the point. *I* want to be special | 12:18 |
| smoser | i dont care about other people! | 12:18 |
| smoser | :) | 12:18 |
| pitti | oh, right :) | 12:19 |
| xnox | you can add wanted by everywhere, and to work everywhere you should add After = networkd | 12:19 |
| xnox | and that's it. | 12:19 |
| pitti | reminds me of those bug reports that say "this must be the last thing on boot" | 12:19 |
| pitti | (and of course I've seen at least three *different* people/packages claiming that) | 12:19 |
| pitti | smoser: so yes, if you want to block a target, do Before=network-online.target, and wait on the specific thing you just configured, like networking.service | 12:20 |
| smoser | there shoudl be a target "basically-last-thing-in-boot" | 12:20 |
| pitti | smoser: and if/once cloud-init learns how to setup networkd, you can add After=systemd-networkd.service too | 12:20 |
| smoser | rc.local (what it used to provide) is such a very useful thing for normal humans. | 12:20 |
| xnox | we call that "multiuser.target" =) | 12:20 |
| smoser | but, lets not go there :) | 12:20 |
| pitti | well, that conceptually isn't possible :) | 12:20 |
| smoser | and 147 things run at 'multiuser.target' | 12:20 |
| pitti | (and that's completely independent of insserv/upstart/systemd) | 12:20 |
| xnox | not systemd-networkd.service, but after systemd-networkd-wait-online.service. | 12:20 |
| smoser | hey. | 12:21 |
| smoser | i really do have to run now. | 12:21 |
| pitti | ok, time for lunch then | 12:21 |
| smoser | xnox and pitti have been very, very helpful | 12:21 |
| smoser | thank you | 12:21 |
| smoser | pitti at your leisure, yuou have an email about pollinate from me too. | 12:21 |
| smoser | thanks again. | 12:21 |
| smoser | best irc chat ever. | 12:22 |
| xnox | smoser, but given our on/off thing, your cloud init generator will need to install "cloud-init" wanted by "network-online", the After= lines can be encoded for all the world wide known network-online.target wanted'bys.... | 12:22 |
| smoser | really, thank you! | 12:22 |
| xnox | or even better the generator can sniff those off disk. | 12:22 |
| xnox | cause you want to create network-online.target.wants/cloud-init.service & create cloud-init.service.d/after.conf -> and that conf will list [Unit]\n After=`ls /etc/systemd/system/network-online.target.wants` | 12:23 |
| pitti | xnox: urgh, that sounds way too hackish | 12:27 |
| xnox | =) | 12:27 |
| pitti | xnox: cloud-init can only configure ifupdown anyway, so there's little point waiting for the others | 12:27 |
| xnox | pitti, it's not about configuring network however. ifupdown can only be done by cloud-init-local. I think what smoser here is after "network is configured by whatever" now block all services and wait for cloud-init to finsih installing/upgrading packages; configure users etc..... do everything. And then unblock network services to spawn everything else. | 12:29 |
| xnox | e.g. sshd server. | 12:29 |
| pitti | xnox: correct, which is just Before=network-online.target in cloud-init.service | 12:29 |
| xnox | pitti, can one be wantedby & before network-online.target? | 12:30 |
| xnox | it can't be before network-online.target, as then it will before network is actually configured.... | 12:31 |
| pitti | xnox: yes, that's by far the most common behaviour (it's unusual for something to want a dependency, but that dependency should run *after* oneseelf) | 12:31 |
| xnox | e.g. before network-online.target, will be before networking.service/NetworkManager-wait-online.service | 12:31 |
| xnox | no? | 12:31 |
| pitti | xnox: right, hence cloud-init.service being After=networking.service Before=network-online.target | 12:32 |
| xnox | that's racy. | 12:32 |
| pitti | as we don't (currently) care a bout anything else in cloud-init than ifupdown | 12:32 |
| xnox | ok. so it's racy in network configs that support -wait-online stuff properly (e.g. networkmanager, networkd) | 12:32 |
| pitti | if you want to block on those too, then add them to After=, yes | 12:33 |
| xnox | right, gotcha. | 12:33 |
| flexiondotorg | muktupavels, I've built Compiz with you changes stacked on mine here - https://launchpad.net/~ubuntu-mate-dev/+archive/ubuntu/crazy-mate/+build/9327928 | 12:35 |
| flexiondotorg | muktupavels, And tested it. Works great. Thanks for your help on this, it is much appreciated :-) | 12:36 |
| === yofel_ is now known as yofel | ||
| flexiondotorg | muktupavels, Changes merged in the proposal - https://code.launchpad.net/~ubuntu-mate-dev/compiz/marco-gsettings/+merge/282882 | 12:38 |
| flexiondotorg | Trevinho, I've merged and tested the changes muktupavels suggested for the improve Marco integration in Compiz. Please review https://code.launchpad.net/~ubuntu-mate-dev/compiz/marco-gsettings/+merge/282882 | 12:40 |
| === francisco is now known as Guest63468 | ||
| knome | could somebody look at bug 1555046 and help us get it uploaded? the shimmer-themes package is snatched from xubuntu by some dependencies to the kubuntu packageset so we're unable to do that ourself | 13:15 |
| ubottu | bug 1555046 in shimmer-themes (Ubuntu) "Please upload shimmer-themes-2.1.1-0ubuntu1 to xenial" [Undecided,Confirmed] https://launchpad.net/bugs/1555046 | 13:15 |
| knome | cheers! | 13:15 |
| smoser | pitti, "conflicts/before=shutdown.target" ? | 14:22 |
| pitti | smoser: that's to ensure that it gets stopped on shutdown (shouldn't be relevant, it's just standard practice; see man systemd.service DefaultDependencies) | 14:29 |
| smoser | ah. ok. | 14:29 |
| smoser | is there a way that i can get systemd to print a log with microsecond timestampos of services and targets ? | 14:30 |
| smoser | that were started thus far. | 14:30 |
| smoser | pitti, ^ is that just an ignorant question ? | 14:54 |
| pitti | smoser: (in meeting, bbl) | 14:54 |
| smoser | perfectly acceptable. thanks. | 14:54 |
| === Pici- is now known as Pici | ||
| pitti | smoser: jounralctl -o short-precise? | 15:00 |
| pitti | smoser: journal always stores microseconds, it's just output formatting/presentation | 15:00 |
| smoser | but that is just stuff that got written to journal | 15:02 |
| smoser | (had journal output or somethingt) | 15:03 |
| smoser | suytemd ran a bunch of servivces and decided that some targets were reached. | 15:03 |
| smoser | it did that at certain points in the boot | 15:03 |
| smoser | i'd like to get timestamps of every one of those. | 15:04 |
| smoser | systemd-analyze critical-chain is useful | 15:04 |
| pitti | smoser: yes, these are recorded in the journal too | 15:20 |
| pitti | smoser: Mär 10 05:01:27.102984 donald systemd[1]: Starting Load Kernel Modules... | 15:21 |
| pitti | smoser: something like this "Starting/Started", coming from systemd itself) | 15:21 |
| pitti | smoser: yeah, systemd-analyze can massage these nicely too; "plot" for the visually inclined :) | 15:22 |
| caribou | infinity: regarding the mstflint adujstment of yesterday I have a few final questions | 15:23 |
| caribou | infinity: trusty's version is 1.4-OFED-1.4.2-1ubuntu1 and wily's version is 3.7.0+1.18.gcdb9f80-3.1ubuntu2. I supposed that the versionned Breaks should be << 3.7.0+1.18.gcdb9f80-3.1ubuntu2 (wily's) ? | 15:24 |
| smoser | pitti, ok. i was just not seeing what i was looking for becausae systemd shows the 'Description' there | 15:24 |
| smoser | which then you have to map back to the unit | 15:24 |
| smoser | ie, if i want to know about 'pollinate' | 15:25 |
| smoser | # journalctl -o short-precise | grep Seed | 15:25 |
| smoser | that works | 15:25 |
| smoser | but this does nto | 15:25 |
| smoser | # journalctl -o short-precise | grep pollinate | 15:25 |
| smoser | not even | 15:25 |
| pitti | smoser: systemctl show <unit> also shows the timestamp, in case that's easier | 15:25 |
| smoser | what is the MONOTONIC things there ? | 15:27 |
| smoser | unless its hidden in one of those, 'show' only seems to show 1 second granularity | 15:28 |
| pitti | smoser: clock_gettime(CLOCK_MONOTONIC); probably not relevant for you, unless you deal with ntp or TZ shifts in between | 15:28 |
| pitti | clock_gettime(3) has the gazillion different clocks that Linux provides | 15:29 |
| pitti | barry: so pysmbc is on http://people.canonical.com/~ubuntu-archive/component-mismatches.txt wanting to go to universe | 16:07 |
| pitti | barry: a bit curious, I thought we wanted to kill python *2* stuff | 16:08 |
| barry | pitti: this is all caught up in the samba madness | 16:08 |
| barry | pitti: in some respects python3-samba should stay in main because it can get installed on-demand by system-config-printer. but it's off the desktop iso now, so...? | 16:09 |
| pitti | barry: so I guess it can go, it's expected to not be there by default | 16:11 |
| pitti | ? | 16:11 |
| barry | pitti: i think that's fine for now. unfortunately py2 won't get booted off the desktop in 16.04 because of gvfs-backends. we'll have to make more progress on upstream samba get any further. boot it to universe for now | 16:12 |
| coreycb | pitti, I had 2 packages in the xenial new queue that aren't showing up now (python-neutron-lib and python-aodhclient). should I re-upload? | 16:12 |
| barry | pitti: (possible it will get re-mained in 16.10) | 16:12 |
| pitti | coreycb: err, no idea, did someone reject them? (you should have gotten a mail about that) | 16:15 |
| coreycb | pitti, I don't see anything, I'll try to upload again | 16:17 |
| === JanC_ is now known as JanC | ||
| pitti | rbasak: I'm a bit confused, why does the ubuntu-server metapackage want to go to universe? | 16:22 |
| pitti | rbasak: are we not using that any more? I. e. intended (and should it perhaps be removed?) or unintentional? | 16:23 |
| ogra_ | main got to small for it | 16:23 |
| ogra_ | it now wants the whole thing :) | 16:23 |
| pitti | I thought that was apt-get install fillherup | 16:23 |
| * ogra_ assumes thats a bug ... we still produce server isos | 16:24 | |
| pitti | well, there was talk about unifying cloud and server images etc., so it's not entirely implausible that it's by intent | 16:24 |
| rbasak | smoser: ^ | 16:24 |
| ogra_ | well, we definitely want the server task ... not sure if the metapackage is (was ever) actually needed | 16:25 |
| rbasak | I think smoser wants the metapackage so that it's clear when removing packages that you're removing ubuntu-server. | 16:25 |
| rbasak | So it defines what ubuntu-server is better. | 16:26 |
| smoser | i certainly dont want ubuntu-server in universe. | 16:26 |
| ogra_ | (does it anything more than installing openssh-server on top of ubuntu-standard ? ) | 16:26 |
| ogra_ | ah, right, removals | 16:26 |
| * ogra_ didnt think of that | 16:26 | |
| pitti | also, dist-upgrades | 16:34 |
| pitti | those are the reasons why we keep the package in main for desktop | 16:34 |
| pitti | and we seed the metapackage into "itself" | 16:34 |
| smoser | pitti, so yes, i guess we should seed that package | 16:36 |
| pitti | hm, it wasn't seeded in wily either | 16:36 |
| pitti | ah! | 16:36 |
| pitti | it's new in xenial | 16:36 |
| smoser | its new in xenial | 16:36 |
| smoser | seeding a metapackage derived from the seed seemed to circular tom e | 16:36 |
| pitti | the metapackage doesn't define the seed | 16:37 |
| pitti | we do have (a lot of) seeds without metapackages, too | 16:37 |
| pitti | smoser: ok, thanks for cleaning that up; this was a bit confusing | 16:37 |
| nacc | is it expected that dpgk-gencontrol doesn't respect -N in DH_OPTIONS? | 16:37 |
| pitti | nacc: yes, DH_* is a debhelper option | 16:38 |
| pitti | nacc: if you mean dh_gencontrol, then no | 16:38 |
| * pitti waves good night, still not feeling too well | 16:40 | |
| smoser | pitti, the metapackage is derived from the seed. | 16:42 |
| nacc | pitti: err, sorry, meant that, yeah | 16:43 |
| smoser | so adding it to the seed seems circular | 16:43 |
| nacc | pitti: will investigate | 16:44 |
| attente | juliank: hi. is there some way to trigger an apt update over dbus (with aptdaemon or packagekit or some other service)? | 17:17 |
| juliank | Yes, with both | 17:18 |
| juliank | don't ask me how | 17:18 |
| attente | juliank: ok. i was trying with org.debian.apt.RefreshCache but for whatever reason it doesn't seem to do anything... | 17:24 |
| * juliank would use PK's org.freedesktop.PackageKit.Transaction.RefreshCache () | 17:27 | |
| === adrian is now known as adrian|sick | ||
| nacc | slangasek: is it just a matter of timing, or is there a reason php7.0 is stil in excuses? I see "Valid candidate" so that just means it hasn't been moved yet? | 18:36 |
| Pharaoh_Atem | :( | 18:43 |
| Pharaoh_Atem | ubuntu-devel is moderated :( | 18:43 |
| nacc | Pharaoh_Atem: yeah.. you get used to it | 18:43 |
| Pharaoh_Atem | what's amazing is that none of the other distro MLs I'm on are | 18:44 |
| Pharaoh_Atem | or at least, they aren't anymore | 18:44 |
| dobey | hmm, why isn't x11-xserver-utils migrated | 19:07 |
| nacc | dobey: relatively the same question i just had about php7.0 -- seems like there a few "Valid candidates" that are a bit old | 19:09 |
| nacc | dobey: not sure how that works | 19:09 |
| dobey | yeah, but i don't need php7 to get 60Hz on 4K monitor :) | 19:10 |
| nacc | dobey: heh | 19:10 |
| dobey | do need full stack for xrandr 1.5 though | 19:10 |
| === pepee- is now known as pepee | ||
| streulma | hello, am I right here for 16.04 questions ? | 19:13 |
| streulma | shim disabled Secure Boot... How can I enable it again ? | 19:14 |
| dobey | #ubuntu is the general support channel; #ubuntu+1 is for "next release" stuff, so might be more appropriate | 19:17 |
| brendand | hi, having a hard time creating a static cp binary on trusty | 19:23 |
| brendand | please don't ask why | 19:24 |
| brendand | got and configured coreutils source | 19:25 |
| brendand | then 'make SHARED=0 CC="gcc -fPIC -static -std=gnu99"' | 19:25 |
| sarnold | that's a funny CC | 19:27 |
| sarnold | try CFLAGS="-fPIC -static -std=gnu99" instead | 19:27 |
| sarnold | alternatively grab sash or busybox or something? :) | 19:28 |
| sarnold | brendand: ^^^ | 19:28 |
| lewq | maybe http://askubuntu.com/questions/530617/how-to-make-a-static-binary-of-coreutils ? | 19:28 |
| brendand | is the one in busybox static? | 19:29 |
| brendand | sarnold: but CFLAGS did the trick, thanks | 19:29 |
| === funkyHat_ is now known as funkyHat | ||
| rharper | smoser: rbasak: please git-dsc-import tgt to ubuntu-server-dev in launchpad when you get a chance; | 19:31 |
| smoser | k | 19:31 |
| chiluk | is anyone else running xenial having massive issues with network-manager not respecting DNS settings when connecting to VPNs? | 19:34 |
| * Pharaoh_Atem shrugs | 19:34 | |
| chiluk | basically whenever I connect to the vpn it uses the vpn dns servers in spite of the fact I've told it not to. | 19:34 |
| Pharaoh_Atem | sounds like an NM 1.0.x issue | 19:35 |
| Pharaoh_Atem | which vpn type are you using? | 19:35 |
| sarnold | chiluk: there's a handful of bugs about dhc* issues.. apparently an isc dhcpcd or dhclient runs with threads but one of the isc bind libraries is not thread safe.. | 19:38 |
| chiluk | I was leaning more towards network-manager being the culprit. | 19:44 |
| juliank | tkamppeter: Maybe you know why hplip has a hplip-kubuntu.desktop, and why the names are different? The reason given is 'Kubuntu doesn't have any application categorised in "Settings"' - but the hplip.desktop (now?) uses Categories=Application;Utility; - I assume that's fine? | 21:15 |
| * juliank is doing a massive hplip packaging cleanup | 21:15 | |
| juliank | (in Debian) | 21:16 |
| stefanct | minor bug in glibc(?) package in xenial: http://dpaste.com/042441N (i am upgrading a test machine right now) | 21:31 |
| nacc | stefanct: hrm, it's escaped in xenial for me | 21:34 |
| nacc | stefanct: and that's not a bug in libc, it's a reported warning in the specified perl file | 21:34 |
| nacc | afaict | 21:34 |
| nacc | stefanct: both are escaped in my (current) install of xenial | 21:35 |
| stefanct | it is but apparently triggered by configuring the libc package... i have not looked at the code | 21:35 |
| nacc | i mean, it *should* complain about every package, i think | 21:35 |
| nacc | not just libc | 21:35 |
| nacc | as it's going to complain about the deprecation on every load of that file | 21:35 |
| nacc | stefanct: what perl do yo have installed (apt-cache policy perl) | 21:36 |
| nacc | stefanct: err, rather debconf | 21:36 |
| stefanct | it definitely does not for every other package (i have seen it only for glibc yet) but i can look at the log later | 21:36 |
| stefanct | well, right now 1.5.58ubuntu1 but it might have been updated already | 21:37 |
| nacc | stefanct: yeah, i'm on that version and the referred to source file does not have the referred to issue | 21:39 |
| nacc | stefanct: xenial is a moving target, so i think it's been fixed | 21:39 |
| nacc | stefanct: looking at the changelog that was fixed in wily (1.5.57ubuntu1) | 21:42 |
| nacc | stefanct: technically in debian, 1.5.57 | 21:42 |
| nacc | stefanct: it's possible the perl update is what caused the deprecation to get emitted (as the chagnelog mentions the message shows up with 5.22 and on) | 21:42 |
| stefanct | ill check the log when it is done to look for the sequence and versions of perl and debconf upgrades | 21:43 |
| nacc | yeal, wily had 5.20, it seems, so if it was a wily -> xenial upgrade, i think those messages may be possible, not sure | 21:44 |
| nacc | rbasak: hey, so trying to understand why php7.0 hasn't migrated yet, can you explain how that works? | 21:52 |
| rbasak | nacc: so in update_excuses.html, we see "Valid candidate", so next is to look at update_output.txt | 21:52 |
| rbasak | Here, it's trying to find a combination of packages to migrate to the release pocket such that the number of uninstallable packages does not increase. | 21:53 |
| rbasak | trying: php7.0 | 21:53 |
| rbasak | * amd64: fusiondirectory, fusiondirectory-plugin-addressbook, fusiondirectory-plugin-alias... | 21:53 |
| nacc | rbasak: ah that's what i was missing! this other file | 21:53 |
| rbasak | These are the packages that it says will become uninstallable in the release pocket if php7.0's binaries were to migrate to the release pocket. | 21:53 |
| rbasak | Trying easy from autohinter: php7.0/7.0.3-9ubuntu1 phpunit/5.1.3-1+ubuntu3 php-defaults/32ubuntu1 php-codesniffer/2.5.1-1ubuntu4 | 21:53 |
| rbasak | Here you can see that it's trying to migrate multiple packages at once, but it hits the same problem. | 21:54 |
| rbasak | I'd start by seeing why fusiondirectory is uninstallable. "chdist apt-get xenial-proposed install fusiondirectory" may tell us enough. | 21:54 |
| nacc | rbasak: yep, thanks! | 21:55 |
| nacc | rbasak: in this case, i know what's goi gon | 21:55 |
| rbasak | The following packages have unmet dependencies. | 21:55 |
| rbasak | fusiondirectory : Depends: php-imap but it is not going to be installed | 21:55 |
| rbasak | Depends: php-mcrypt but it is not going to be installed | 21:55 |
| nacc | gosa at least is blocked | 21:55 |
| nacc | yep | 21:55 |
| nacc | i am working on fixing that now | 21:55 |
| nacc | we have to split hte src package | 21:56 |
| nacc | effectively | 21:56 |
| nacc | so that the universe targets can build | 21:56 |
| rbasak | OK, great. More information at https://wiki.ubuntu.com/ProposedMigration | 21:56 |
| nacc | rbasak: so that makes more sense to me | 21:56 |
| nacc | rbasak: thank you very much! | 21:56 |
| rbasak | No problem! | 21:56 |
| nacc | rbasak: so in the split, we have two control files, the universe one adds the universe build-deps to the base source ... would it be better to just add a substituion variable and keep all the differences between the two packages confined to debian/rules? | 22:02 |
| nacc | rbasak: a control fine two different packages, to be clear | 22:02 |
| rbasak | Unfortunately you can't do that in the source section of the control file, AFAIK. | 22:03 |
| rbasak | (so build deps) | 22:03 |
| nacc | rbasak: ah ok, answers that question then :) | 22:04 |
| nacc | rbasak: i was trying to find the cleanest "delta" (not a proper delta, but basically waht is needed to build the unvierse package given the main source package) | 22:04 |
| stefanct | nacc: first perl (5.22.1-8) over (5.18.2-2ubuntu1.1); then libc6:amd64 (2.21-0ubuntu6) over (2.19-0ubuntu6.7); then debconf (1.5.58ubuntu1) over (1.5.51ubuntu2) | 22:06 |
| nacc | stefanct: ah so it's an artifact of the ordering, i guess | 22:06 |
| nacc | stefanct: as after debconf is upgraded, the message is gone | 22:06 |
| stefanct | and it was from trusty | 22:07 |
| nacc | rbasak: it seems like one suggestion is to use sed and a marker in the clean override, but that doesn't seem so much better to justify adding the complexity | 22:07 |
| stefanct | i am not so sure about that... the message came exactly two times. for libc6 and libc-dev-bin. and actually i think it was the "unpacking" stage that produced it... it's a bit hard to tread from the log because it sees to be slightly out of order (is there any parallelism?) | 22:10 |
| nacc | stefanct: why aren't you sure? the perl upgrade led to the deprecated warning, which is emmited by debconf Perl files when libc6 gets configured, then debconf gets upgrade and silences the warning | 22:12 |
| nacc | s/silences/fixes/ | 22:12 |
| stefanct | there were lots of packages in between | 22:13 |
| nacc | stefanct: between the perl and debconf upgrades? | 22:14 |
| nacc | stefanct: sorry, I read the above, as the actual order and packages | 22:14 |
| stefanct | between both paris respectively | 22:15 |
| nacc | stefanct: can you pastebin the log? | 22:15 |
| stefanct | *pairs :) | 22:15 |
| stefanct | well, i have that information from the screenlog because it seems to be the only one containing all the information including the message - but it is rather unreadable | 22:16 |
| stefanct | the apt.log might be suitable i guess? | 22:16 |
| nacc | yeah, maybe | 22:17 |
| stefanct | (if you trust me on the bogus messages :) | 22:17 |
| stefanct | ill pastebin both | 22:17 |
| rharper | how does one systemd services using Type=notify and a daemon that's supposed to sd_notify ? | 22:22 |
| stefanct | oh well... the screenlog is almost 2MB and neither dpaste nor debian.net like that. apt.log: http://paste.debian.net/413989/ | 22:22 |
| nacc | rbasak: no need to reply, but it seems like for the univesre source packge, that i can dh_installdocs --link-doc to php7.0-common; is that ok? | 22:23 |
| nacc | rbasak: that's per hte debian policy, i mean | 22:23 |
| nacc | slangasek: ok, i've got a split package working with everything but php-interbase, which i think needs some extra tweaking (will work on that next). I think that will clear out a lot of the queue (as php7.0 should migrate then) | 22:56 |
| nacc | slangasek: so my plan is to send it in a bug as d ebdiff for php7.0 and a new pckage request for the universe source package | 22:56 |
| slangasek | nacc: sounds good, thanks | 23:08 |
| nacc | slangasek: np, i think i've got interbase figured, out just need to get the right configure tweak in place; it seems like the extension is relying on something from the -common makefile that isn't run now. Sorry it's taken so long! Had to learn a bit about makefiles :) | 23:10 |
| === salem_ is now known as _salem | ||
| mwhudson | i wonder when the last time the "Package has already been uploaded to" check in dput actually helped anyone was | 23:56 |
| nacc | mwhudson: :) | 23:58 |
| mwhudson | i guess i should just alias dput='dput -f' | 23:58 |
| nacc | mwhudson: i think dput -f for PPAs is probably fine, I got in the habit of the same myself | 23:59 |
| nacc | although that wsa the result of the (bad?) habit of not inserting changelog entries for one-off builds | 23:59 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!