naccslangasek: *super* confusingly ... it seems like debian's php-imagick only shows the one failure from before that the imagemagick backports should be resolving ... so possibly the backports introduce a regression? I'm debugging using upstream ImageMagick , but am also tempted to just skip this test as it seems inconsistent00:09
naccslangasek: and i have a really difficult time undersatnding how s390 gets a different (successful) result then the two failing archs00:10
slangaseknacc: well, for that matter, I don't see why it should be different between the failing archs and the succeeding 32-bit archs; this shouldn't be wordsize-sensitive math00:11
naccslangasek: right, it's really odd00:11
naccunless some double rounding is off in php00:11
naccslangasek: let me also say the upstream ImageMagick coding standards are ... poor :)00:13
naccso many empty commits00:13
naccempty commit messages, i mean00:13
slangasekyeah, I noticed that00:13
naccslangasek: ok, i just confirmed (agin) that upstream imagemagick works fine with the version of php-imagick we have in ubuntu, at least for that one test -- bisecting again00:22
=== _salem is now known as salem_
=== _salem is now known as salem_
naccslangasek: ok, so i need to look at php-proxy-manager (that's already on my list); i'm still learning to understand/pase the update_output.txt file, let me konw if there are more action items you want to extract from it01:17
=== salem_ is now known as _salem
=== _salem is now known as salem_
naccslangasek: also, i'm not sure i understand fully why php-defaults has regrssions for php-sabre-http and php-sabre-http-3 where those versions are superseded in proposed? is that just an ordering issue? or does it only retrigger as those propogate to the release pocket?01:38
slangaseknacc: the latter01:39
slangasekactually, it doesn't automatically retrigger at all, but I'm retriggering them manually01:39
naccslangasek: ah, well, thank you very much!01:39
naccslangasek: i suppose it would be a lot of potential churn if it was automatic01:39
slangasekwell, I believe there's an outstanding bug report about making that automatic01:42
GunnarHjrobert_ancell: Hi Robert, Do you plan to fix the u-c-c task at bug #1554878 (or possibly remove the rest of the XDG_CURRENT_DESKTOP queries)?01:48
ubottubug 1554878 in unity-control-center (Ubuntu) "fix up usage of XDG_CURRENT_DESKTOP" [Medium,Triaged] https://launchpad.net/bugs/155487801:48
robert_ancellGunnarHj, I'm not working on it right now, if you want to make MPs for the remaining issues please do01:49
GunnarHjrobert_ancell: I'm afraid it's above my head to decide if any non-Unity options need to be kept.01:50
=== juliank is now known as Guest66004
=== juliank_ is now known as juliank
=== salem_ is now known as _salem
=== shuduo-afk is now known as shuduo
cpaelzergood morning05:27
Mirvpitti: morning! trying to retry i386 from https://requests.ci-train.ubuntu.com/static/britney/xenial/landing-006/excuses.html , I get "A server error occurred." after clicking the login button07:14
dholbachgood morning07:34
pittiGood morning07:49
pittiMirv: "no space left on device", argh07:49
khfengHi all.07:53
khfengCan anyone help me setting "Also affects distribution/package" for Trusty in LP:155789307:53
Mirvpitti: thank you, seems working now08:09
pittiMirv: yes, but not for long, I'm working on avoiding running out of inodes more permanently08:09
pittiMirv: ok, should survive longer now :)08:59
=== spineau is now known as spineau_afk
Mirvpitti: great!09:00
Laneydoko: did you see the pyzmq problems?10:41
dokoLaney, yes10:41
=== spineau_afk is now known as spineau
lamontdoko: smb cyphermox I am now all over bind913:15
lamontit's mixed awesomenes, since it became a hardblocker for my team last night. :/13:16
cyphermoxnot much response from the other guy?13:20
=== _salem is now known as salem_
smoserpitti, xnox so my cloud-init units (specifically cloud-init-local) is not guaranteed to run before ifup@.service units, as those are run via hotplug events.13:40
xnoxand i guess running before udev cold-plug is too early, as disk and things might not exist then yet.13:41
xnoxsmoser, run -local in the initramfs?! =)13:41
smoserthe result (observed) is that cloud image with 'dhcp eth0' will dhcp before cloud-init woudl write other configuration for eth0. meaning i'd have to take the interface down to actually apply it. and worse, with ifdown insistening that the interfaces file is in the state it was in when ifup was run, i have to deal with that.13:41
smoserxnox, yeah, but / isn't even mounted rw at that point13:41
smoserbut yes, generally that is kind of the path that others have taken13:42
xnoxand e.g. in the systemd-networkd (if and when we switch to that) it also does everything via udev events. And there it's worse, one cannot really remove config at all.13:42
pittismoser: but ifconfig  wouldn't even have a configuration if c-i-local didn't run yet, so wouldn't that event be a no-op?13:42
smoserit seemed to me that possibly i could make the cloud-init-local RequiredBy ifup@.service13:42
pittiwell,l ifup@ is already After=network-pre.target13:43
pittibut that doesn't matter for things which are started explicitly13:43
pitti(which is done by /lib/udev/ifupdown-hotplug)13:44
pittiso RequiredBy=ifup@.service in c-i-local should work indeed13:45
pittialthough it's a bit of a crowbar really13:45
pittismoser: so I'm confused -- if that hotplug event already does *anything*, it means that there already is a config for that interface, and thus c-i-local must have run already?13:46
smoserwell, i guess13:46
smosera.) in a stock image, we still have 'auto eth0' and 'dhcp' in ENI13:46
pittismoser: the RequiredBy= probably blows up in your face if you disable cloud-init on the command line?13:46
Odd_BlokeOoh, exciting, running sbuild on my desktop unmounts my ecryptfs home directory.13:46
smoserb.) in a stopped and snapshotted image, you'd have the 'old' data in ENI13:47
pittismoser: ah -- well, that we need to get rid of, but I thought that was the whole point of that exercise13:47
pitti"auto eth0" is EBW13:47
pittib) is an interesting point13:48
smoserc.) if there was *not* anything there, then ifup would not do anything. but the cloud-init would have to ifup the interface itself.  i guess that is possible, but it seeemed more than ideal cloud-init just let the system bring up the networking.13:48
smoserin the future, the intent woudl be to be able to apply networking chagnes after boot, so cluod-init woudl then need to know how to re-set the running system (ideally with minimal change)13:49
smoserbut i was kind of hopign to just avoid dealing with that.13:49
smoserEBW ?13:49
* pitti pushes away the thought that we are reinventing NetworkManager here13:49
ogra_just seed it and use nmcli :P13:50
pittismoser: not tested (and distracted), but does it work better if you add Requires=network-pre.target to ifup@.service?13:51
pittithen any ifup@ should not only run after n-pre but also actually start it if it hasn't already, and thus also run c-i-local13:51
pittismoser: I have a gut feeling that nothign is actually starting network-pre.target right now, this should rectify this13:53
pittioh, and adding Requires=network-pre.target to networking.service too13:53
pittiI think that was an oversight when we wrote those units13:53
smoserpitti, my journalctl on a system right now does not seem to have any occurance of 'target.*network.*pre'13:55
smoser journalctl | grep -i 'target.*network.*pre'13:55
smoseri'll try your suggestion13:56
pittismoser: http://paste.ubuntu.com/15401586/ → not entirely sure that this is the right way to put them (as the intention is that things that want to run before pull it in, not things that run after it), but if that fixes it we at least know what to look for13:59
Odd_Blokepitti: tyhicks: I'm seeing bug 1430557 (or something very similar) when running sbuild even with schroot 1.6.10-1ubuntu3 installed. (I don't really know enough about how s(build|chroot) work to know if I should be doing something in addition to just installing the updated package)14:07
ubottubug 1430557 in schroot (Debian) "sbuild / schroot unmounted encrypted home directory" [Unknown,Confirmed] https://launchpad.net/bugs/143055714:07
smoserpitti, that seems to have worked.14:11
smoserthe one other hting that i want/need is to be able to rename interfaces14:12
tyhicksOdd_Bloke: hi - can you paste the corresponding schroot fstab file (/etc/schroot/<PROFILE>/fstab) and /proc/self/mountinfo ?14:12
smosermaybe cloud-init will just have to do that, but could do fairly freely knowing that the interfaces would not be ifup'ing at that point.14:12
smosercloud-init is writing udev rules, but the rule to rename might have already been written.14:14
smoseroh shoot.14:14
Odd_Bloketyhicks: o/ /etc/schroot/sbuild/fstab -> http://paste.ubuntu.com/15401660/, /proc/self/mountinfo -> http://paste.ubuntu.com/15401663/14:15
smoserseems like bridges might be too late also.14:16
smoserhm.. so my reaading is that bridges and device renames are going to cause me some pain. as udev would have already invoked /lib/udev/ifupdown-hotplug14:18
smoserand actually that would have already decided (based on the /etc/network/itnerfaces at the time) if the interface was 'auto' or not.14:19
tyhicksOdd_Bloke: nothing odd in there14:20
tyhicksOdd_Bloke: what about ubuntu release was in the chroot that you were using?14:20
tyhicksOdd_Bloke: what ubuntu release was in the chroot that you were using?14:21
tyhicksOdd_Bloke: I see the problem. You're hitting bug 143894214:24
ubottubug 1438942 in schroot (Ubuntu) "Host's /dev/shm is mounted over when entering 14.10 and older sbuild schroots" [High,In progress] https://launchpad.net/bugs/143894214:24
tyhicksOdd_Bloke: I was really wanting to get feedback from schroot maintainers on that fix before uploading it but it is dragging on for too long14:25
tyhicksOdd_Bloke: I'll poke the Debian bug and then go ahead and upload the fix in Ubuntu14:26
Odd_Bloketyhicks: Great, thanks!14:28
Odd_Bloke(It was trusty in the chroot :)14:28
tyhicksyep :)14:28
tyhicksOdd_Bloke: schroot is mounting a new tmpfs over /dev/shm in your *host*14:30
tyhicksOdd_Bloke: ecryptfs-utils keeps some state in /dev/shm so it causes problems when an entirely new tmpfs is mounted over /dev/shm14:31
tyhicksOdd_Bloke: I think a workaround in the meantime would be to unmount the extra tmpfs at /dev/shm after you've created the schroot session but before you destroy it14:31
aweanybody know who controls the ACL lists for the wiki?  One of my test plan pages has become imumutable, and I can't update it anymore14:32
rbasakawe: are you accidentally logged out?14:33
aweI tried logging out and back in again14:33
aweand they didn't do it14:33
seb128rbasak, https://launchpad.net/ubuntu/+source/software-properties/0.96.19 btw, just for info14:41
rbasakseb128: ?14:51
seb128rbasak, it was not you who were asking about unattended-upgrades/software-properties depends? sorry, need to check my IRC logs14:51
rbasakseb128: ah yes, I was.14:51
seb128well, fix uploaded ^14:51
seb128just I was just letting you know14:52
rbasakAh. Thanks!14:52
bdmurrayseb128: will that software-properties upload fix bug 1554099?14:55
ubottubug 1554099 in software-properties (Ubuntu Xenial) "Changing what action for security updates unusable" [High,Confirmed] https://launchpad.net/bugs/155409914:55
pittismoser: worked> nice!14:55
seb128bdmurray, yes, sorry forgot about that bug/to list it in the changelog14:55
bdmurrayseb128: no problem14:56
smoserpitti, i think i've convinced myself that bridge and vlan (which run at 40-* in /lib/udev/rules.d) wont be a problem for me14:56
pittismoser: so apparently the intention is "This passive target unit may be pulled in by services that want to run before any network is set up", i. e. which declare the Before=14:56
smoserbutrenaming devices seems like it still will.14:56
smoser^ is for network-pre ?14:57
seb128bdmurray, we discussed it with m_vo on IRC, unattended-upgrade does autodownload so that option isn't needed to be set to 114:57
pittismoser: yes, that was a quote from the manpage14:57
pittismoser: renaming happens in 80-net-setup-link.rules14:58
pittismoser: so if you want to rename something, the udev rule ought to exist before the device is processed by udev, otherwise you might already start things which depend on the old name14:58
smoserpitti, cloud-init writes /etc/udev/rules.d/70-persistent-net.rules . which would work on next reboot15:00
pittismoser: right (don't forget to call update-initramfs -u too)15:00
pittismoser: what's that for, OOI? can you define interface names in user-data?15:00
smoserupdate-initramfs -u : yuck.15:00
pittismoser: it's not strictly necessary if you have a controlled environment, but safer15:01
pittismoser: there's things like open-iscsi and friends which talk to network interfaces in the initrd already15:01
pittiif you can rule these out, then they can be renamed after initrd15:01
smoserthe goal woudl be to define the interface name in the 'network-config'. right now that network config would only come from the cloud provider. but thats no different really than coming from the user. same end result. something outside declares what they want.15:02
dokoMirv, pitti: is xvfb currently not working properly? https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-xenial/xenial/armhf/i/ipython/20160316_133657@/log.gz15:02
smoserthe initramfs only comes into play if 'ip=' on the command line. i think i might have to accept that any interface already configured is nto goign to be changed.15:03
smoserright now maas can declare the interface name when it installs a system.15:04
smoseras it runs in the install environment and the peristent-rule are written before reboot15:04
smoserso thats fine.15:04
ogra_(you could add something like "override.name= ..." to your kernel cmdline instead and have a script in the initrd that reads it ... that saves you from regenerating and you just need to change the cmdline15:04
smoserso at this point the network-config allows you to declare "the device with MAC=XX:XX:XX is to be named foobar0"15:05
smoseri'd like to support that if at all possible in the scenario where the network-yaml is consumed during boot.15:06
ogra_well, so you use that name pre-mount ... and post-mount you write it into the udev rule file15:07
ogra_(from your initrd)15:07
ogra_assuming your yaml can be pulled from some server via network15:08
smoserogra_, i think its ok if you have "dirty" persistent rules are fine as long as network is not left up after exiting initramfs.  ie, i think the *root*'s persistent-rules would still be consumed, right?15:09
ogra_i thought you wanted a persistent name from start to end though15:09
smoserthat'd be ideal, but i'mi ok at this point to say that booting iscsi root with 'ip=' on the command line you can't declarel the name of the nic.15:10
smoseror if you did, you need to declare it to the intiramfs, and then cloud-init would need to respect that.15:11
smoserthe way ii'm looking at that is that 'ip=' on the command line is actually definitive over a network-config.15:11
smosersimilar to the way that command line flag would override environment variable or config file15:11
smoserpitti you said 80-net-setup-link.rules sets naming ?15:14
smoserif thats true, then i'd have thought it woudl run *after* 80-ifupdown.rules15:15
smoserwhich would have tried to ifup the nic with the old value of $INTEFACE15:15
pittismoser: no, RUN is executed after all rules for a device are processed15:19
smoserah. ok. that makes more sense then.15:20
pittiit should probably have been 85-ifupdown.rules or so to avoid confusion, but it won't make a practical difference15:20
naccslangasek: fyi, got access to a s390x system, so will debug that issue today15:26
smoserpitti, so do i have a chance at this ?15:31
smoseris there any way something run on ADD can dynamically determine the name and set it ?15:32
smoserIMPORT would seem possible, but i think setting NAME= in via import would only affect the env{NAME} not the NAME15:33
pittismoser: yes, you can run something with IMPORT15:33
pittismoser: ah, you can do PROGRAM="echo-my-name", NAME="$result"15:35
pittismoser: or rever to any $env{VARNAME} or similar15:35
pittiIMPORT and PROGRAM are synchronous in one rule, RUN+= gets queued after rule processing15:35
Son_Gokunacc: what do I need to do to request php7.0-fpm to be in main?15:35
pittiSon_Goku: nothing15:36
pittiit already is :)15:36
Son_Gokuit is?15:36
pittiit was on component-mismatches a few days ago, so I promoted it15:36
pittithings were horribly uninstallble before15:37
Son_Gokupitti: thanks15:37
naccSon_Goku: for reference, this is the MIR process for php5-fpm: LP: #126725515:37
smoserpitti, NAME="$result" ?15:37
ubottuLaunchpad bug 1267255 in php5 (Ubuntu) "[MIR] php5 (php5-fpm binary)" [Wishlist,Confirmed] https://launchpad.net/bugs/126725515:37
smoseroh. all in one rule you coudl do that ?15:37
pittismoser: this question no verb15:37
pittismoser: yes, see man 7 udev15:38
pittismoser: you can use various substitutions in ENV, NAME, etc. assignments15:38
smoserok, then. tell me how horrible you think this is.15:38
smoserthe plan would be to add a rule with: IMPORT=<some-program>, NAME=env{NEWNAME}15:39
pittismoser: so roughly, PROGRAM/IMPORT are for *detecting* devices and determining their properties (but these programs can't do much with that new device), while RUN is about doing *something with* the newly found device and can use it fully15:39
dokopitti, so the pyzmq triggered ipython autopkg test failure looks unrelated to pyzmq. please override it for this migration15:39
pittismoser: well, with some additional ACTION==, SUBSYSTEM=="net", etc. :)15:40
smoserand IMPORT would block until cloud-init-nonet had found the data it was looking for.15:40
Son_Gokuwhen is the next time xenial-proposed gets merged into xenial?15:40
pittiSon_Goku: that happens automatically as soon as the thing in -proposed is ready (http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html)15:40
cjwatsonand that process runs multiple times an hour, typically15:40
pittismoser: just make sure that it's really fast15:40
pittismoser: i. e. milliseconds15:40
smoserwell, it might not be on first boot.15:42
pittidoko: done15:43
smoserand even15:43
smoser time python3 -c 'pass'15:43
pittierk, python?15:43
smoseris itself on the order of milliseconds (~ 0.04)15:43
pittithis runs on every add or change of a network device15:43
pittiwell, at least add NAME=="" so that it doesn't re-run after it ran successfully once15:44
smoserright. but i need it to block until cloud-init-nonet has determined what the new name should be.15:44
pittino, you can't do that15:44
Son_Gokunacc: is there a way to set conflicts or dependencies for enabling confs through a2enconf?15:44
smoserhm.. why not ?15:44
pittiyou can run for a second or so and figure out the name, but you can't block indefinititely on some external async service to run15:44
smoserudev will just kill it if it thinks it is taking too long15:45
smoseris that right ?15:45
pittiright, that too15:45
pittismoser: but the attributes -> name map should be in some easy to parse format somewhere on disk15:45
pittiand if it's not there, just don't assign a name15:46
pittiif it's not configured, nothing should use the device15:46
smoserso the goal is for cloud-init-nonet to find a network configuration that says "the nic with mac XX:YY should be named pittinet0"15:46
smoserbut this event may come in before cloud-init-nonet has run15:46
smoser(or run to completion)15:46
Son_Gokunacc: I can’t seem to find anything that indicates it’s possible, but I was hoping it’d be possible to make it so that when a2enconf php7.0-fpm is activated, it can switch on dependent modules, or indicate that it won’t run if php7.0 is enabled15:46
smoserso my plan would be for that IMPORT program to simply parse a file liek you suggest , but one written by cloud-init-nonet.15:47
smoserif the file (/run/cloud-init/simple-parse-file) is not present, it would block and wait for it to appear.15:47
naccSon_Goku: shouldn't that be something php7 upstream does? i dont' think it'd be uatomatic, it'd need soemthing we'd have to write, i guess15:47
pittismoser: cloud-init-nonet could trigger change events for network cards if it actually has any assignments15:47
pittithen they'll re-run15:47
Son_Gokunacc: they don’t care, and I wrote the php7.0-fpm a2enconf stuff15:48
Son_Gokutechnically, nothing will blow up if you do it with mine, as it just won’t do anything if php7.0 is active15:48
* Son_Goku gets really confused with mod/conf system15:49
dokonacc, slangasek: the zeromq3 and php-defaults transitions are coupled. what's the status of the failing autopkgtest for php-imagick?15:53
naccdoko: debugging it as we speak15:55
smoserpitti, but the 'RUN+' that does the ifup has to have the new name, and ideally not run until /etc/network/interfaces has been populated with the provided data.15:58
smoserand the CHANGE woudln't rename the interfaces i dont think. at least in the past via 70-persistent-net.rules, those were done only on ACTION=="add".15:58
smoserbut i admit to not understanding 80-net-setup-link.rules16:05
smoseroh. now that i read it i undderstand more.16:06
tjaaltonwhy does running 'systemctl start dbus' fail like it does on xenial, but not on debian?16:21
tjaalton"Failed to start dbus.service: Operation refused, unit dbus.service may be requested by dependency only."16:21
=== shuduo is now known as shuduo-afk
naccslangasek: ugh, at least on s390, we've got a string with a zero length, but pointing to a valid string16:23
pittitjaalton: that (RefuseManualStart=yes) is an ubuntu speficic change16:23
tjaaltonpitti: okay16:24
pittitjaalton: that particular change was from bug 154028216:24
ubottubug 1540282 in dbus (Ubuntu) "Breaks policykit/systemctl commands when restarted" [Low,Fix released] https://launchpad.net/bugs/154028216:24
tjaaltonneed to work around it in freeipa then16:24
pittitjaalton: and the whole "don't stop on shutdown" is still from bug 143861216:24
tjaaltonor just not run start, seems silly anyway16:24
ubottubug 1438612 in dbus (Ubuntu) "remote file systems hang on shutdown, D-BUS stops too early" [High,Fix released] https://launchpad.net/bugs/143861216:24
pittionce we fix all consumers of d-bus interfaces on shutdown to DTRT we can drop it again16:25
pittibut things getting stuck on trying to talk to dbus on shutdown have caused tons of shutdown hangs16:25
tjaaltonright, ok16:25
pittiso this was a dirty, but remarkably effective way of fixing those16:25
pittitjaalton: I was hoping that by 16.04 we would have kdbus and none of this would be relevant any more :/16:25
tjaaltonheh :)16:25
Son_Gokupitti: well… there’s bus1, maybe someday possibly?16:27
Son_Gokuwho the hell knows anymore...16:27
slangasekdoko: zeromq3 and php-defaults should not be coupled; I've uploaded php-defaults to not require a newer version of php-zmq16:30
rbasakxnox: please could you explain your upload of juju-mongodb 2.4.10-0ubuntu6? I'm reviewing updated juju-mongodb packaging for upload and want to know whether I need to carry that forward or not. It would help to know why.16:37
xnoxrbasak, juju-mongodb should be built on all ubuntu architectures, there is no reason not to.16:38
xnoxas juju works on all arches (and go, and mongodb)16:39
xnoxrbasak, you should carry "Architecture: any".16:39
rbasakxnox: OK, so please could you explain this in the changelog at time of upload?16:39
xnoxI did =) "Drop architecture restrictions." i'm not sure how else to phrase it, there is nothing arch-specific in the package.16:40
rbasakNo, that tells me _what_, not _why_. I can see _what_ by looking at a diff.16:40
ogra_"build with "Architecture: all""16:40
ogra_way easier for quick-parsing16:40
xnoxrbasak, horum, ok. Are you updating to new major upstream release or some such?16:40
ogra_(or "any" in this case)16:41
rbasak"Drop architecutre restrictions since there is nothing arch-specific in the package" would be better, for example. Or whatever other reasoning you want to give. Otherwise I don't know if there's some hidden reason I'm missing and have to investigate.16:41
rbasakxnox: yeah - 2.6 and 3.2 as new source packages.16:41
rbasakThere may be porting issues. We'll see.16:42
xnoxrbasak, you will probably need to cherrypick 2.6 & 3.2 branches from e.g. IBM for ppc64el and s390x ports....16:42
xnox(aka update/refresh the port patches that we include there)16:42
xnoxand probably pick up linaro trees for arm64.16:42
xnoxunless it's all upstream, but i don't think all has made it into 3.2.16:43
sinzuihi rbasak16:44
rbasaksinzui: xnox was talking above about porting suggestions for s390x, ppc64el and arm64.16:44
rbasakI noticed that your juju-mongodb 2.6 packaging was based on ubuntu4, and ubuntu5 adds some porting stuff.16:44
rbasakDo you know the current status of your 2.6 packaging wrt. those architectures please?16:45
sinzuirbasak: oops. I didn't realise how stale that package had become. I can and will use xenial's current package as the base16:45
rbasaksinzui: it's only a couple of minor changes, don't bother.16:46
rbasaksinzui: just apply those changes to the top of your tree or something.16:46
xnoxrbasak, sinzui - yeah we should not regress arch support, if there are troubles with ppc64el/s390x/arm64 do open a bug and let me know. there shouldn't be any porting required, just finding the right vendor repos on github and integrating them.16:47
sinzuirbasak: the 2,6 package was fine on ppc64el and arm64.16:47
xnoxsinzui, s390x is brand new, and powerpc was added too.16:47
sinzuirbasak: I got access to s390x yesterday and need to solve hoe to build and test on it...it looks lile a fedora derivative16:47
rbasaksinzui: or if you prefer, I can leave it for now and wait for an update from you?16:48
xnoxsinzui, you got access to the wrong thing =)16:48
sinzuixnox: Juju doesn't support powerpc but s390x is what we are adding16:48
xnoxsinzui, you got access to a z/KVM, which should have libvirt running which can be used to launch ubuntu cloud image.16:48
xnoxsinzui, for development and building things, you probably want an ubuntu lpar and/or ubuntu zvm. I have those available and can co-share access to that. It has like sbuild.16:49
xnoxsinzui, note that some of juju ppas have s390x enabled now, thus you can just use a launchpad ppa to be honest.16:49
sinzuixnox: yes, vish is there but was expecting ubuntu xenial16:49
slangasekdoko: ah I see, it's a one-way dep where php-defaults needs to happen first and then zeromq can go.  Yeah, I'm forcing php-defaults through16:49
xnoxsinzui, hence i said wrong thing. very little people actually need acess to z/KVM (rhel + virsh)16:50
slangaseknacc: zero length> another rounding bug? ;)16:50
sinzuixnox: The juju ppas are s390x enabled. and we have built16:50
xnoxsinzui, do update your rt request to get normal ubuntu lpar / zvm16:50
sinzuithank you very much xnox16:51
rbasaksinzui: please run update-maintainer also, and check the architecture list.16:51
rbasaksinzui: Architecture: any might be more appropriate. It's fine to have unsupported architectures fail to build. Makes future porting easier.16:52
naccslangasek: i think it might be an upstream php bug ... they do some extra init routines in mb_strpos that they don't do in mb_stripos16:52
naccslangasek: looking into it16:52
* slangasek nods16:52
naccslangasek: doko: also i think i figured out the php-imagick issue16:53
naccslangasek: missing some parentheses :/16:53
nacctesting that now too16:53
slangaseknice :)16:53
naccslangasek: ah ok, i think php7.0 upstream has a fix for the s390x bug16:54
nacc"fix incompatible pointers on 64-bit" :)16:54
naccor, it might, at least16:54
naccslangasek: going to try and build php7.0 from source on s390x to test16:54
tjaaltonjamespage: hi, libcommon-lang-java is broken because of the diff to debian (not using bnd). freeipa server fails because of that (more accurately pkispawn fails because of java.lang.NoClassDefFoundError: org/apache/commons/lang/StringUtils)16:55
tjaaltonand also the jar is three times bigger than on debian16:56
nacctjaalton: i'd like to help debug that ... can you provide me a configuration that i can use to reproduce? that is, where could/should i point pkispawn?17:04
tjaaltonnacc: what do you mean? install pki-ca, run pkispawn17:05
tjaaltonit'll fail while trying to connect to the daemon, since it fails to start17:05
nacctjaalton: which release?17:07
smoserpitti, is a generator guaranteed to run before udev events ? i'd guess it must be.17:08
nacctjaalton: in xenial, i get: http://paste.ubuntu.com/15402793/17:08
xnoxsmoser, well there is udev running in the initramfs, generators are run before udev-coldplug service at which point all events are retriggered if i understand things right.17:08
smoserthat sounds sane.17:09
tjaaltonnacc: hostname foo.bar17:09
nacctjaalton: doing that and updated /etc/hosts in my schroot, it started up and is asking me for a "Subsystem"17:10
tjaaltonand it should only have [CA]?17:10
tjaaltonhit enter17:11
nacctjaalton: ok, Directory server is localhost?17:12
tjaaltonoh right, you need that set up first17:13
tjaaltoninstall 389-ds-base17:13
=== alexisb is now known as alexisb-afk
nacctjaalton: ok17:14
tjaaltonrun setup-ds17:14
nacctjaalton: ok, one sec17:14
pittismoser: not before the initrd's udev, but certainly before we re-start udev adn do the big udevtrigger17:18
pittiright, what xnox said17:18
smoseryeah. so woudl there be an easy way to say "am i shooting for the cloud-inti target" in udev ?17:19
smoseri can check for the .target file taht the generator would have written17:19
nacctjaalton: might need more config to make it work in a sbuild :/17:22
pittismoser: udev rules can't wait for anything; the only thing you can do is to start a .service asynchronously from a rule (SYSTEMD_WANTS)17:22
tjaaltonnacc: no you need a real machine17:23
nacctjaalton: :/ ok17:23
nacctjaalton: not as easy for me to easily reproduce then :)17:24
tjaaltonreal as in proper install, virtual or otherwise17:24
tjaaltonnot chroot17:24
rbasaksinzui: I'm done reviewing bug 1557830. Most items are related to architecture support and patches. It may be easiest to resolve this with xnox. When done I'm happy to upload, or xnox can if he wants.17:27
ubottubug 1557830 in juju-mongodb (Ubuntu) "[needs-packaging] juju-mongodb2.6 in xenial, wily, and trusty" [Undecided,New] https://launchpad.net/bugs/155783017:27
tjaaltonnacc: this seems related https://bugs.launchpad.net/ubuntu/+source/axis/+bug/89430217:27
ubottuLaunchpad bug 894302 in axis (Ubuntu Trusty) "jar files do not include OSGi metadata" [High,Triaged]17:27
sinzuithank you rbasak17:28
nacctjaalton: ok, i can try and look into it if jamespage can't17:29
tjaaltonheh, and https://bugs.launchpad.net/ubuntu/+source/libcommons-lang-java/+bug/155664717:29
ubottuLaunchpad bug 1556647 in libcommons-lang-java (Ubuntu) "/usr/share/java/commons-lang.jar contains documentation" [Undecided,Confirmed]17:29
tjaaltonexplains why it's so big17:30
tjaaltonand why it's broken17:30
nacctjaalton: ok, one sec17:30
=== salem_ is now known as _salem
nacctjaalton: i'll try and reproduce & debug17:33
nacctjaalton: you're right, that's almost certainly the underlying cause17:33
=== _salem is now known as salem_
nlsthznquick comment/concern - I have been unable to get changes in alsamixer in the ammount of channels to stick (defaults to two, I change it to 6 for 5.1) When  reboot it is back to two again :/17:42
nlsthznwith all of the 16.04 images I have tried17:42
nlsthznubuntu / mate / xubuntu etc.17:42
tjaaltonnacc: here's the diff, if you plan on fixing it, should make it easier https://launchpadlibrarian.net/247122600/libcommons-lang-java_2.6-5ubuntu1_2.6-6ubuntu1.diff.gz17:43
tjaaltonor maybe not17:44
xnoxsinzui, rbasak, awww... we need 2.6 to in-place upgrade to 3.2 *sigh*. I would have thought we would be serialising juju and re-deploying for migration. E.g. because juju2 has different format for stuff anyway.18:00
xnoxpitti, now i see what you meant by all mongos everywhere.18:00
pittixnox: it's astounding. time is fleeting! Maaaaadness takes its toll.18:00
sinzuixnox: yeah, it is very disapointing. there was discussion in Juju about creating their own format to inport/export to. that might be the long term solution18:01
pittileeeet's dooo the moooongoooo agaaaain ♪18:01
xnoxsinzui, e.g. like sqlite or something =)18:01
pittiif we could serialize juju's db, why bother and not just always use that serialization format *cough* :)18:02
xnoxsinzui, as far as i can tell, we don't actually use anything mongo-ish in juju.18:02
sinzuixnox: it is both a document stoe and a file store which cloud be done both other things. Mongo offers some encapulation.18:03
=== alexisb-afk is now known as alexisb
=== salem_ is now known as _salem
=== _salem is now known as salem_
naccslangasek: great, s390x failures fixed, sending a debdiff for that and the twig failures (as it's a real bugfix too)18:37
naccslangasek: LP: #155820118:41
ubottuLaunchpad bug 1558201 in php7.0 (Ubuntu) "php-sabre-dav-2.1 testsuite failures in mb_stripos on s390x" [Undecided,New] https://launchpad.net/bugs/155820118:41
nacctjaalton: weird, the build produces a good jar, but something but be messing it up, reproduced and debugging now18:53
=== salem_ is now known as _salem
slangaseknacc: is LP: #1558201 the only patch needed for php7.0 right now?  I'll probably let the current round of packages migrate and then pick up that diff19:07
ubottuLaunchpad bug 1558201 in php7.0 (Ubuntu) "php-sabre-dav-2.1 testsuite failures in mb_stripos on s390x" [Undecided,New] https://launchpad.net/bugs/155820119:07
=== _salem is now known as salem_
slangasek(now that I've got the imagick hints the right way 'round)19:08
naccslangasek: yes, i think so -- that will fix the two known issues we've hit in testing with php7.019:13
slangaseknacc: which are the two? I only saw the sabre-dav/s390x one19:14
naccslangasek: sorry, the debdiff has two patches added19:14
naccslangasek: i wasn't sure how to do that with the two bugs19:14
slangaseklike that is fine :)19:14
naccok :)19:14
nacctjaalton: i think i found it19:18
nacctjaalton: but would need jamespage to review it19:18
slangaseknacc: ok, looks like we're going to need one more p-m run but this should really be the one now - unfortunately p-m made a wrong guess about the packages to hint together and pulled in php-zmq, but a manual hint should get past that19:21
slangasekthen the php gallstone will be cleared and we can tie up loose ends19:21
naccslangasek: great, thanks19:22
[reed]Could I get somebody to add precise to https://bugs.launchpad.net/ubuntu/+source/git/+bug/1557787 to get that fixed?19:23
ubottuLaunchpad bug 1557787 in git (Debian) "client/server RCEs in path_name()" [Unknown,Confirmed]19:23
slangaseknacc: debian/patches, please include Bug-Ubuntu references for clarity; do you want to fix those up or shall I?19:25
slangaseknacc: btw, provided proper Bug-Ubuntu headers, I favor generating the debian/changelog entries using dep3changelog19:26
naccslangasek: ah sorry, i can fix that up, i didn't have one of the bugs opened yet. Let me do that and run that command19:26
slangasek(though the authorship of dep3changelog may imply some bias)19:26
slangaseknacc: love the fix for the s390x mbstring problem. my only question is, why are we not building php7.0 with -Werror= flags that make this a build-time failure19:30
naccslangasek: good question19:32
slangaseknacc: also, when I say I "love the fix", what I actually mean is "why the heck did they not just fix the type of mbfl_string in the embedded libmbfl"19:32
slangasekI suppose because somebody could be building php against a stand-alone built of this library and it's ABI-changing19:33
slangaseknacc: oh look, php migrated19:33
naccslangasek: awesome; and updated debdiff posted in that same bug19:34
slangaseknacc: ok, so reason #1 not to build with -Wall -Werror, the phpdbg build fails to configure when using those flags ;)19:51
naccslangasek: i wondered about that19:53
naccslangasek: there are a ton of warnings already emitted19:53
naccslangasek: so that's probably why19:54
naccbut they could possible turn on some flags19:54
naccslangasek: upstream is finally fixing all the semicolon issues, but even that's not done yet, afaict19:54
slangasekand if I ignore that, I get http://paste.ubuntu.com/15404033/19:54
naccPharaoh_Atem: do you know --^ ?19:55
naccslangasek: in theory, could do -Werror -Wincompatible-pointer-types, right?19:56
slangasekthe problem is the configure script is wrong about strtok_r not being defined, so it goes a bit off19:56
naccoh i see19:56
slangaseknacc: yeah possibly19:56
slangasekI think there are probably a lot of other warnings you'd want turned on :)19:56
naccslangasek: yeah, i can take that as another todo19:56
naccslangasek: to at least look into19:57
slangaseknacc: yeah; it's not urgent, but chances are it'd turn up other latent bugs like the mbstring one19:57
naccslangasek: yep19:57
slangaseknacc: -Wincompatible-pointer-types doesn't catch it, fwiw19:58
slangaseknot sure what the right -W flag is, I guess doko might know19:58
naccslangasek: so i got e-mails from lp about the bugs being fixed for php-defaults/php7.0/php-universe-source7.0. But excuses still lists them all?20:01
slangaseknacc: excuses shows you what's currently under consideration; update_output shows you whether it's actually being promoted; they'll be gone from update_excuses as of the /next/ p-m run20:04
naccslangasek: ah! i see, more timing nuance :)20:04
slangaseknacc: I haven't seen a new debdiff for php-imagick. you still working on that one?20:34
naccslangasek: yeah, having issues with my adt-lxc at home20:52
naccslangasek: let me try to resync my base image and start the tests up again20:52
slangaseknacc: ok no hurry, just trying to make sure I'm not dropping any balls20:54
naccslangasek: the only thing i've submitted right now is the two patches to php7.0. I'm hoping to have php-proxy-manager and php-zend* fixed today20:55
slangaseknacc: do you know anything about this warning?: W: php-mongodb source: pear-package-without-pkg-php-tools-builddep21:04
naccslangasek: i think it's this: https://lintian.debian.org/tags/pear-package-without-pkg-php-tools-builddep.html21:08
naccslangasek: it's part of the debian php7.0 transition, iiuc21:08
Son_Gokuyeah, as part of the update to php7, most distros are yanking pear specific requirements21:13
Son_Gokumainly to kill a couple of circular dependencies that are a pain to resolve when doing a bootstrap upgrade21:13
Son_Gokuerr, a bootstrap of a new php version for an upgrade21:14
Son_Gokunot for bootstrap the js thingy21:14
Unit193Hello.  Is there any specific reason adobe-flashplugin is stuck in partner-proposed?  I don't see it on the update excuses page.21:16
lamontcyphermox: smb doko any of you around?21:27
cyphermoxlamont: yeah21:27
lamontwanna play with bind9 / isc-dhcp for me?21:27
lamontI'll be uploading to a couple of ppas momentarily21:27
dokolamont, where?21:28
lamontmy ppa, and the maas ppa21:29
lamontonce it gets any exposure, xenial21:29
lamontbut zomfg21:29
lamontI had to get out a hammer and smash -export back into the code... and I went with "let's not perturb the cleanup work that doko did, because I like that better than the old wya"21:30
lamontISC dropped the --enable-exportlib configure code21:30
* doko thought that URL were common knowledge ;-P21:30
lamontdpkg-shlibdeps: error: couldn't find library libisccc-export.so.140 needed by debian/libisccfg-export140/lib/x86_64-linux-gnu/libisccfg-export.so.140.3.0 (ELF format: 'elf64-x86-64'; RPATH: '')21:31
=== salem_ is now known as _salem
lamontbah and bother21:31
lamontoh haha21:31
lamontand then, this weekend maybe (hahaha), I plan to roll to 9.10.3.dfsg.P4, because it's out21:43
dasjoexnox: hey, come join us in #zfsonlinux ;) Never seen somebody with a s390x use it21:46
xnoxdasjoe, well... ssssh21:46
slangaseknacc: well, lintian locally gives me all the same information as that webpage about the message, was wondering if you knew that the message was a false-positive and why21:51
tjaaltonnacc: I can sponsor libcommons-lang-java22:15
nacctjaalton: ok, it looks like an obvious tweak to me and the generated jar seems correct now22:16
tjaaltonnacc: yep22:16
lamontcyphermox: https://launchpad.net/~lamont/+archive/ubuntu/ppa/+build/936061922:16
lamontstill building, and once it finishes, I'll upload isc-dhcp22:16
naccslangasek: ok, so the php-zeta-console-tools failure is ... not quite clear to me as being a real issue. That is, what is failing is the test is doing a variable assignment like: $table[][0]->format = "test", where $table is of type ezcConsoleTable, which inherits from ArrayAccess22:20
naccthat, in turn, implicitly calls getOffset() for the $table variable22:20
naccgetOffset is declared as getOffset($offset)22:21
naccbut, it seems like when [] is used, $offset is empty22:21
naccso it can't be accessed and throws an error22:21
slangaseknacc: I can help you bludgeon C compilers to get php to build, and dredge a path through p-m to get it into the archive; but I have remained blissfully ignorant of all changes to the PHP language's semantics for the past decade22:22
naccslangasek: yeah, i'm just not sure it's a "new" failure, as we weren't running the tests at build-time before the version we just picked up22:23
naccslangasek: is it possible for me to see the autopkgtst results for 1.7-1?22:25
tjaaltonnacc: uploaded22:25
slangaseknacc: http://autopkgtest.ubuntu.com/packages/p/php-zeta-console-tools/ ?22:25
slangaseknacc: seems it passed with php5 5.6.17+dfsg-3ubuntu1, and fails before and after22:25
naccslangasek: indeed22:29
nacci wish i knew what "bug #10710" is referring to22:29
ubottubug 10710 in Ubuntu "linux86: FTBFS on amd64: elksemu's file format not recognized." [High,Fix released] https://launchpad.net/bugs/1071022:29
naccerr, sorry, it's definitely *not* referring to that :)22:29
naccslangasek: asking on their IRC channel22:33
naccslangasek: would you be able to review LP: #1543803? to fix my AWS error22:37
ubottuLaunchpad bug 1543803 in aws-sdk-for-php (Ubuntu) "Sync aws-sdk-for-php 3.14.2-1 (universe) from Debian experimental (main)" [Wishlist,New] https://launchpad.net/bugs/154380322:37
naccslangasek: that's one of the two holdups for php-monolog22:37
Loganhey pitti - chef 12.3.0-3 fixes the FTBFS on rebuild, but I'm not sure if it's safe to sync over your delta (or whether it should be merged)22:45
slangaseknacc: yeah, still on my todo list22:45
lamontdoko cyphermox smb blake_r bind9 built, and isc-dhcp uploaded to https://launchpad.net/~lamont/+archive/ubuntu/ppa/+packages ( blake_r also to experimental3).  pls to test22:46
pittiLogan: see debian bug 798618, looks like it wasn't applied in Debian yet, so it needs merging22:46
ubottuDebian bug 798618 in chef "chef-client: autopkgtest race condition" [Normal,Open] http://bugs.debian.org/79861822:46
Loganpitti: ok, mind if I grab the merge in that case?22:47
pittiLogan: of course I don't mind, thank you!22:47
Loganof course :)22:47
Loganhmm, spoke too soon. the package needs to reduce its dependency on the plist gem as well :|22:53
smblamont, Right now I only see bind9 there. But since yesterday's tomorrow just became today, I will have a look in a few hours23:05
naccslangasek: fyi, the php-zeta-console-tools is a bug in php, fixed upstream, narrowing it down now23:30
lamontsmb: /me typoed the upload url :(23:52
lamont_now_ it's uploaded23:53
lamontand building23:53

Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!