| nacc | slangasek: *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 inconsistent | 00:09 |
|---|---|---|
| nacc | slangasek: and i have a really difficult time undersatnding how s390 gets a different (successful) result then the two failing archs | 00:10 |
| slangasek | nacc: 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 math | 00:11 |
| nacc | slangasek: right, it's really odd | 00:11 |
| nacc | unless some double rounding is off in php | 00:11 |
| nacc | slangasek: let me also say the upstream ImageMagick coding standards are ... poor :) | 00:13 |
| nacc | so many empty commits | 00:13 |
| nacc | empty commit messages, i mean | 00:13 |
| slangasek | yeah, I noticed that | 00:13 |
| nacc | slangasek: 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 again | 00:22 |
| === _salem is now known as salem_ | ||
| === _salem is now known as salem_ | ||
| nacc | slangasek: 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 it | 01:17 |
| === salem_ is now known as _salem | ||
| === _salem is now known as salem_ | ||
| nacc | slangasek: 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 |
| slangasek | nacc: the latter | 01:39 |
| slangasek | actually, it doesn't automatically retrigger at all, but I'm retriggering them manually | 01:39 |
| nacc | slangasek: ah, well, thank you very much! | 01:39 |
| nacc | slangasek: i suppose it would be a lot of potential churn if it was automatic | 01:39 |
| slangasek | well, I believe there's an outstanding bug report about making that automatic | 01:42 |
| GunnarHj | robert_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 |
| ubottu | bug 1554878 in unity-control-center (Ubuntu) "fix up usage of XDG_CURRENT_DESKTOP" [Medium,Triaged] https://launchpad.net/bugs/1554878 | 01:48 |
| robert_ancell | GunnarHj, I'm not working on it right now, if you want to make MPs for the remaining issues please do | 01:49 |
| GunnarHj | robert_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 | ||
| cpaelzer | good morning | 05:27 |
| Mirv | pitti: 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 button | 07:14 |
| dholbach | good morning | 07:34 |
| pitti | Good morning | 07:49 |
| pitti | Mirv: "no space left on device", argh | 07:49 |
| khfeng | Hi all. | 07:53 |
| khfeng | Can anyone help me setting "Also affects distribution/package" for Trusty in LP:1557893 | 07:53 |
| Mirv | pitti: thank you, seems working now | 08:09 |
| pitti | Mirv: yes, but not for long, I'm working on avoiding running out of inodes more permanently | 08:09 |
| Mirv | ok | 08:10 |
| pitti | Mirv: ok, should survive longer now :) | 08:59 |
| === spineau is now known as spineau_afk | ||
| Mirv | pitti: great! | 09:00 |
| Laney | doko: did you see the pyzmq problems? | 10:41 |
| doko | Laney, yes | 10:41 |
| Laney | ok | 10:42 |
| === spineau_afk is now known as spineau | ||
| lamont | doko: smb cyphermox I am now all over bind9 | 13:15 |
| cyphermox | yay | 13:15 |
| smb | awesomeness | 13:15 |
| lamont | it's mixed awesomenes, since it became a hardblocker for my team last night. :/ | 13:16 |
| cyphermox | oops | 13:20 |
| cyphermox | not much response from the other guy? | 13:20 |
| === _salem is now known as salem_ | ||
| smoser | pitti, 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 |
| xnox | and i guess running before udev cold-plug is too early, as disk and things might not exist then yet. | 13:41 |
| xnox | smoser, run -local in the initramfs?! =) | 13:41 |
| smoser | the 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 |
| smoser | xnox, yeah, but / isn't even mounted rw at that point | 13:41 |
| smoser | initramfs | 13:41 |
| smoser | but yes, generally that is kind of the path that others have taken | 13:42 |
| xnox | and 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 |
| pitti | smoser: 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 |
| smoser | it seemed to me that possibly i could make the cloud-init-local RequiredBy ifup@.service | 13:42 |
| xnox | horum. | 13:43 |
| pitti | well,l ifup@ is already After=network-pre.target | 13:43 |
| pitti | but that doesn't matter for things which are started explicitly | 13:43 |
| pitti | (which is done by /lib/udev/ifupdown-hotplug) | 13:44 |
| pitti | so RequiredBy=ifup@.service in c-i-local should work indeed | 13:45 |
| pitti | although it's a bit of a crowbar really | 13:45 |
| smoser | yeah. | 13:45 |
| pitti | smoser: 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 |
| smoser | well, i guess | 13:46 |
| smoser | a.) in a stock image, we still have 'auto eth0' and 'dhcp' in ENI | 13:46 |
| pitti | smoser: the RequiredBy= probably blows up in your face if you disable cloud-init on the command line? | 13:46 |
| Odd_Bloke | Ooh, exciting, running sbuild on my desktop unmounts my ecryptfs home directory. | 13:46 |
| smoser | b.) in a stopped and snapshotted image, you'd have the 'old' data in ENI | 13:47 |
| pitti | smoser: ah -- well, that we need to get rid of, but I thought that was the whole point of that exercise | 13:47 |
| pitti | "auto eth0" is EBW | 13:47 |
| pitti | b) is an interesting point | 13:48 |
| smoser | c.) 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 |
| smoser | in 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 |
| smoser | but i was kind of hopign to just avoid dealing with that. | 13:49 |
| smoser | EBW ? | 13:49 |
| * pitti pushes away the thought that we are reinventing NetworkManager here | 13:49 | |
| ogra_ | just seed it and use nmcli :P | 13:50 |
| pitti | smoser: not tested (and distracted), but does it work better if you add Requires=network-pre.target to ifup@.service? | 13:51 |
| pitti | then 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-local | 13:51 |
| pitti | smoser: I have a gut feeling that nothign is actually starting network-pre.target right now, this should rectify this | 13:53 |
| smoser | :) | 13:53 |
| pitti | oh, and adding Requires=network-pre.target to networking.service too | 13:53 |
| pitti | I think that was an oversight when we wrote those units | 13:53 |
| smoser | pitti, 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 |
| smoser | i'll try your suggestion | 13:56 |
| pitti | smoser: 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 for | 13:59 |
| Odd_Bloke | pitti: 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 |
| ubottu | bug 1430557 in schroot (Debian) "sbuild / schroot unmounted encrypted home directory" [Unknown,Confirmed] https://launchpad.net/bugs/1430557 | 14:07 |
| smoser | pitti, that seems to have worked. | 14:11 |
| smoser | the one other hting that i want/need is to be able to rename interfaces | 14:12 |
| tyhicks | Odd_Bloke: hi - can you paste the corresponding schroot fstab file (/etc/schroot/<PROFILE>/fstab) and /proc/self/mountinfo ? | 14:12 |
| smoser | maybe 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 |
| smoser | cloud-init is writing udev rules, but the rule to rename might have already been written. | 14:14 |
| smoser | oh shoot. | 14:14 |
| Odd_Bloke | tyhicks: o/ /etc/schroot/sbuild/fstab -> http://paste.ubuntu.com/15401660/, /proc/self/mountinfo -> http://paste.ubuntu.com/15401663/ | 14:15 |
| smoser | seems like bridges might be too late also. | 14:16 |
| smoser | hm.. 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-hotplug | 14:18 |
| smoser | and actually that would have already decided (based on the /etc/network/itnerfaces at the time) if the interface was 'auto' or not. | 14:19 |
| tyhicks | Odd_Bloke: nothing odd in there | 14:20 |
| tyhicks | Odd_Bloke: what about ubuntu release was in the chroot that you were using? | 14:20 |
| tyhicks | bah | 14:20 |
| tyhicks | typo | 14:20 |
| tyhicks | Odd_Bloke: what ubuntu release was in the chroot that you were using? | 14:21 |
| tyhicks | Odd_Bloke: I see the problem. You're hitting bug 1438942 | 14:24 |
| ubottu | bug 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/1438942 | 14:24 |
| tyhicks | Odd_Bloke: I was really wanting to get feedback from schroot maintainers on that fix before uploading it but it is dragging on for too long | 14:25 |
| tyhicks | Odd_Bloke: I'll poke the Debian bug and then go ahead and upload the fix in Ubuntu | 14:26 |
| Odd_Bloke | tyhicks: Great, thanks! | 14:28 |
| Odd_Bloke | (It was trusty in the chroot :) | 14:28 |
| tyhicks | yep :) | 14:28 |
| tyhicks | Odd_Bloke: schroot is mounting a new tmpfs over /dev/shm in your *host* | 14:30 |
| tyhicks | Odd_Bloke: ecryptfs-utils keeps some state in /dev/shm so it causes problems when an entirely new tmpfs is mounted over /dev/shm | 14:31 |
| tyhicks | Odd_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 it | 14:31 |
| awe | anybody know who controls the ACL lists for the wiki? One of my test plan pages has become imumutable, and I can't update it anymore | 14:32 |
| rbasak | awe: are you accidentally logged out? | 14:33 |
| awe | nope | 14:33 |
| awe | I tried logging out and back in again | 14:33 |
| awe | and they didn't do it | 14:33 |
| awe | s/they/that/ | 14:33 |
| seb128 | rbasak, https://launchpad.net/ubuntu/+source/software-properties/0.96.19 btw, just for info | 14:41 |
| rbasak | seb128: ? | 14:51 |
| seb128 | rbasak, it was not you who were asking about unattended-upgrades/software-properties depends? sorry, need to check my IRC logs | 14:51 |
| rbasak | seb128: ah yes, I was. | 14:51 |
| seb128 | k | 14:51 |
| seb128 | well, fix uploaded ^ | 14:51 |
| seb128 | just I was just letting you know | 14:52 |
| rbasak | Ah. Thanks! | 14:52 |
| seb128 | yw! | 14:52 |
| bdmurray | seb128: will that software-properties upload fix bug 1554099? | 14:55 |
| ubottu | bug 1554099 in software-properties (Ubuntu Xenial) "Changing what action for security updates unusable" [High,Confirmed] https://launchpad.net/bugs/1554099 | 14:55 |
| pitti | smoser: worked> nice! | 14:55 |
| seb128 | bdmurray, yes, sorry forgot about that bug/to list it in the changelog | 14:55 |
| bdmurray | seb128: no problem | 14:56 |
| smoser | pitti, i think i've convinced myself that bridge and vlan (which run at 40-* in /lib/udev/rules.d) wont be a problem for me | 14:56 |
| pitti | smoser: 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 |
| smoser | butrenaming devices seems like it still will. | 14:56 |
| smoser | ^ is for network-pre ? | 14:57 |
| seb128 | bdmurray, we discussed it with m_vo on IRC, unattended-upgrade does autodownload so that option isn't needed to be set to 1 | 14:57 |
| pitti | smoser: yes, that was a quote from the manpage | 14:57 |
| pitti | smoser: renaming happens in 80-net-setup-link.rules | 14:58 |
| pitti | smoser: 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 name | 14:58 |
| smoser | right. | 14:59 |
| smoser | pitti, cloud-init writes /etc/udev/rules.d/70-persistent-net.rules . which would work on next reboot | 15:00 |
| pitti | smoser: right (don't forget to call update-initramfs -u too) | 15:00 |
| pitti | smoser: what's that for, OOI? can you define interface names in user-data? | 15:00 |
| smoser | update-initramfs -u : yuck. | 15:00 |
| pitti | smoser: it's not strictly necessary if you have a controlled environment, but safer | 15:01 |
| pitti | smoser: there's things like open-iscsi and friends which talk to network interfaces in the initrd already | 15:01 |
| pitti | if you can rule these out, then they can be renamed after initrd | 15:01 |
| smoser | the 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 |
| doko | Mirv, 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.gz | 15:02 |
| smoser | the 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 |
| smoser | right now maas can declare the interface name when it installs a system. | 15:04 |
| smoser | as it runs in the install environment and the peristent-rule are written before reboot | 15:04 |
| smoser | so 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 cmdline | 15:04 |
| ogra_ | ) | 15:04 |
| smoser | so at this point the network-config allows you to declare "the device with MAC=XX:XX:XX is to be named foobar0" | 15:05 |
| smoser | i'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 file | 15:07 |
| ogra_ | (from your initrd) | 15:07 |
| ogra_ | assuming your yaml can be pulled from some server via network | 15:08 |
| smoser | ogra_, 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_ | yeah | 15:09 |
| ogra_ | i thought you wanted a persistent name from start to end though | 15:09 |
| smoser | that'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 |
| smoser | or if you did, you need to declare it to the intiramfs, and then cloud-init would need to respect that. | 15:11 |
| smoser | the way ii'm looking at that is that 'ip=' on the command line is actually definitive over a network-config. | 15:11 |
| smoser | similar to the way that command line flag would override environment variable or config file | 15:11 |
| ogra_ | yeah | 15:11 |
| smoser | pitti you said 80-net-setup-link.rules sets naming ? | 15:14 |
| smoser | if thats true, then i'd have thought it woudl run *after* 80-ifupdown.rules | 15:15 |
| smoser | which would have tried to ifup the nic with the old value of $INTEFACE | 15:15 |
| pitti | smoser: no, RUN is executed after all rules for a device are processed | 15:19 |
| smoser | ah. ok. that makes more sense then. | 15:20 |
| pitti | it should probably have been 85-ifupdown.rules or so to avoid confusion, but it won't make a practical difference | 15:20 |
| nacc | slangasek: fyi, got access to a s390x system, so will debug that issue today | 15:26 |
| smoser | pitti, so do i have a chance at this ? | 15:31 |
| smoser | is there any way something run on ADD can dynamically determine the name and set it ? | 15:32 |
| smoser | IMPORT would seem possible, but i think setting NAME= in via import would only affect the env{NAME} not the NAME | 15:33 |
| pitti | smoser: yes, you can run something with IMPORT | 15:33 |
| pitti | smoser: ah, you can do PROGRAM="echo-my-name", NAME="$result" | 15:35 |
| pitti | smoser: or rever to any $env{VARNAME} or similar | 15:35 |
| pitti | IMPORT and PROGRAM are synchronous in one rule, RUN+= gets queued after rule processing | 15:35 |
| Son_Goku | nacc: what do I need to do to request php7.0-fpm to be in main? | 15:35 |
| pitti | Son_Goku: nothing | 15:36 |
| pitti | it already is :) | 15:36 |
| Son_Goku | it is? | 15:36 |
| Son_Goku | wooo! | 15:36 |
| pitti | it was on component-mismatches a few days ago, so I promoted it | 15:36 |
| Son_Goku | awesomeness | 15:37 |
| pitti | things were horribly uninstallble before | 15:37 |
| Son_Goku | pitti: thanks | 15:37 |
| nacc | Son_Goku: for reference, this is the MIR process for php5-fpm: LP: #1267255 | 15:37 |
| smoser | pitti, NAME="$result" ? | 15:37 |
| ubottu | Launchpad bug 1267255 in php5 (Ubuntu) "[MIR] php5 (php5-fpm binary)" [Wishlist,Confirmed] https://launchpad.net/bugs/1267255 | 15:37 |
| smoser | oh. all in one rule you coudl do that ? | 15:37 |
| pitti | smoser: this question no verb | 15:37 |
| pitti | smoser: yes, see man 7 udev | 15:38 |
| pitti | smoser: you can use various substitutions in ENV, NAME, etc. assignments | 15:38 |
| smoser | right. | 15:38 |
| smoser | ok, then. tell me how horrible you think this is. | 15:38 |
| smoser | the plan would be to add a rule with: IMPORT=<some-program>, NAME=env{NEWNAME} | 15:39 |
| pitti | smoser: 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 fully | 15:39 |
| doko | pitti, so the pyzmq triggered ipython autopkg test failure looks unrelated to pyzmq. please override it for this migration | 15:39 |
| pitti | smoser: well, with some additional ACTION==, SUBSYSTEM=="net", etc. :) | 15:40 |
| smoser | and IMPORT would block until cloud-init-nonet had found the data it was looking for. | 15:40 |
| Son_Goku | when is the next time xenial-proposed gets merged into xenial? | 15:40 |
| pitti | Son_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 |
| cjwatson | and that process runs multiple times an hour, typically | 15:40 |
| pitti | smoser: just make sure that it's really fast | 15:40 |
| pitti | smoser: i. e. milliseconds | 15:40 |
| smoser | well, it might not be on first boot. | 15:42 |
| pitti | doko: done | 15:43 |
| smoser | and even | 15:43 |
| smoser | time python3 -c 'pass' | 15:43 |
| pitti | erk, python? | 15:43 |
| ogra_ | uuh | 15:43 |
| smoser | is itself on the order of milliseconds (~ 0.04) | 15:43 |
| pitti | this runs on every add or change of a network device | 15:43 |
| pitti | well, at least add NAME=="" so that it doesn't re-run after it ran successfully once | 15:44 |
| smoser | right. but i need it to block until cloud-init-nonet has determined what the new name should be. | 15:44 |
| pitti | no, you can't do that | 15:44 |
| Son_Goku | nacc: is there a way to set conflicts or dependencies for enabling confs through a2enconf? | 15:44 |
| smoser | hm.. why not ? | 15:44 |
| pitti | you can run for a second or so and figure out the name, but you can't block indefinititely on some external async service to run | 15:44 |
| smoser | udev will just kill it if it thinks it is taking too long | 15:45 |
| smoser | is that right ? | 15:45 |
| pitti | right, that too | 15:45 |
| pitti | smoser: but the attributes -> name map should be in some easy to parse format somewhere on disk | 15:45 |
| pitti | and if it's not there, just don't assign a name | 15:46 |
| pitti | if it's not configured, nothing should use the device | 15:46 |
| smoser | so 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 |
| smoser | but this event may come in before cloud-init-nonet has run | 15:46 |
| smoser | (or run to completion) | 15:46 |
| Son_Goku | nacc: 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 enabled | 15:46 |
| smoser | so 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 |
| smoser | if the file (/run/cloud-init/simple-parse-file) is not present, it would block and wait for it to appear. | 15:47 |
| nacc | Son_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 guess | 15:47 |
| pitti | smoser: cloud-init-nonet could trigger change events for network cards if it actually has any assignments | 15:47 |
| pitti | then they'll re-run | 15:47 |
| Son_Goku | nacc: they don’t care, and I wrote the php7.0-fpm a2enconf stuff | 15:48 |
| Son_Goku | technically, nothing will blow up if you do it with mine, as it just won’t do anything if php7.0 is active | 15:48 |
| * Son_Goku gets really confused with mod/conf system | 15:49 | |
| doko | nacc, slangasek: the zeromq3 and php-defaults transitions are coupled. what's the status of the failing autopkgtest for php-imagick? | 15:53 |
| nacc | doko: debugging it as we speak | 15:55 |
| doko | ta | 15:55 |
| smoser | pitti, 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 |
| smoser | and 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 |
| smoser | but i admit to not understanding 80-net-setup-link.rules | 16:05 |
| smoser | oh. now that i read it i undderstand more. | 16:06 |
| tjaalton | why 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 | ||
| nacc | slangasek: ugh, at least on s390, we've got a string with a zero length, but pointing to a valid string | 16:23 |
| pitti | tjaalton: that (RefuseManualStart=yes) is an ubuntu speficic change | 16:23 |
| tjaalton | pitti: okay | 16:24 |
| pitti | tjaalton: that particular change was from bug 1540282 | 16:24 |
| ubottu | bug 1540282 in dbus (Ubuntu) "Breaks policykit/systemctl commands when restarted" [Low,Fix released] https://launchpad.net/bugs/1540282 | 16:24 |
| tjaalton | need to work around it in freeipa then | 16:24 |
| pitti | tjaalton: and the whole "don't stop on shutdown" is still from bug 1438612 | 16:24 |
| tjaalton | or just not run start, seems silly anyway | 16:24 |
| ubottu | bug 1438612 in dbus (Ubuntu) "remote file systems hang on shutdown, D-BUS stops too early" [High,Fix released] https://launchpad.net/bugs/1438612 | 16:24 |
| pitti | once we fix all consumers of d-bus interfaces on shutdown to DTRT we can drop it again | 16:25 |
| pitti | but things getting stuck on trying to talk to dbus on shutdown have caused tons of shutdown hangs | 16:25 |
| tjaalton | right, ok | 16:25 |
| pitti | so this was a dirty, but remarkably effective way of fixing those | 16:25 |
| pitti | tjaalton: I was hoping that by 16.04 we would have kdbus and none of this would be relevant any more :/ | 16:25 |
| tjaalton | heh :) | 16:25 |
| Son_Goku | pitti: well… there’s bus1, maybe someday possibly? | 16:27 |
| Son_Goku | who the hell knows anymore... | 16:27 |
| slangasek | doko: zeromq3 and php-defaults should not be coupled; I've uploaded php-defaults to not require a newer version of php-zmq | 16:30 |
| rbasak | xnox: 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 |
| xnox | rbasak, juju-mongodb should be built on all ubuntu architectures, there is no reason not to. | 16:38 |
| xnox | as juju works on all arches (and go, and mongodb) | 16:39 |
| xnox | rbasak, you should carry "Architecture: any". | 16:39 |
| rbasak | xnox: OK, so please could you explain this in the changelog at time of upload? | 16:39 |
| xnox | I did =) "Drop architecture restrictions." i'm not sure how else to phrase it, there is nothing arch-specific in the package. | 16:40 |
| rbasak | No, 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-parsing | 16:40 |
| xnox | rbasak, 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 |
| rbasak | xnox: yeah - 2.6 and 3.2 as new source packages. | 16:41 |
| rbasak | There may be porting issues. We'll see. | 16:42 |
| xnox | rbasak, 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 |
| xnox | and probably pick up linaro trees for arm64. | 16:42 |
| xnox | unless it's all upstream, but i don't think all has made it into 3.2. | 16:43 |
| sinzui | hi rbasak | 16:44 |
| rbasak | sinzui: xnox was talking above about porting suggestions for s390x, ppc64el and arm64. | 16:44 |
| rbasak | I noticed that your juju-mongodb 2.6 packaging was based on ubuntu4, and ubuntu5 adds some porting stuff. | 16:44 |
| rbasak | Do you know the current status of your 2.6 packaging wrt. those architectures please? | 16:45 |
| sinzui | rbasak: oops. I didn't realise how stale that package had become. I can and will use xenial's current package as the base | 16:45 |
| rbasak | sinzui: it's only a couple of minor changes, don't bother. | 16:46 |
| rbasak | sinzui: just apply those changes to the top of your tree or something. | 16:46 |
| xnox | rbasak, 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 |
| sinzui | rbasak: the 2,6 package was fine on ppc64el and arm64. | 16:47 |
| xnox | sinzui, s390x is brand new, and powerpc was added too. | 16:47 |
| sinzui | rbasak: I got access to s390x yesterday and need to solve hoe to build and test on it...it looks lile a fedora derivative | 16:47 |
| rbasak | sinzui: or if you prefer, I can leave it for now and wait for an update from you? | 16:48 |
| xnox | sinzui, you got access to the wrong thing =) | 16:48 |
| sinzui | xnox: Juju doesn't support powerpc but s390x is what we are adding | 16:48 |
| xnox | sinzui, you got access to a z/KVM, which should have libvirt running which can be used to launch ubuntu cloud image. | 16:48 |
| xnox | sinzui, 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 |
| xnox | sinzui, note that some of juju ppas have s390x enabled now, thus you can just use a launchpad ppa to be honest. | 16:49 |
| sinzui | xnox: yes, vish is there but was expecting ubuntu xenial | 16:49 |
| slangasek | doko: 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 through | 16:49 |
| xnox | sinzui, hence i said wrong thing. very little people actually need acess to z/KVM (rhel + virsh) | 16:50 |
| slangasek | nacc: zero length> another rounding bug? ;) | 16:50 |
| sinzui | xnox: The juju ppas are s390x enabled. and we have built | 16:50 |
| xnox | sinzui, do update your rt request to get normal ubuntu lpar / zvm | 16:50 |
| sinzui | thank you very much xnox | 16:51 |
| rbasak | sinzui: please run update-maintainer also, and check the architecture list. | 16:51 |
| rbasak | sinzui: Architecture: any might be more appropriate. It's fine to have unsupported architectures fail to build. Makes future porting easier. | 16:52 |
| nacc | slangasek: 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_stripos | 16:52 |
| nacc | slangasek: looking into it | 16:52 |
| * slangasek nods | 16:52 | |
| nacc | slangasek: doko: also i think i figured out the php-imagick issue | 16:53 |
| nacc | slangasek: missing some parentheses :/ | 16:53 |
| nacc | testing that now too | 16:53 |
| slangasek | nice :) | 16:53 |
| nacc | slangasek: ah ok, i think php7.0 upstream has a fix for the s390x bug | 16:54 |
| nacc | "fix incompatible pointers on 64-bit" :) | 16:54 |
| nacc | or, it might, at least | 16:54 |
| nacc | slangasek: going to try and build php7.0 from source on s390x to test | 16:54 |
| tjaalton | jamespage: 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 |
| tjaalton | and also the jar is three times bigger than on debian | 16:56 |
| nacc | tjaalton: 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 |
| tjaalton | nacc: what do you mean? install pki-ca, run pkispawn | 17:05 |
| tjaalton | it'll fail while trying to connect to the daemon, since it fails to start | 17:05 |
| nacc | tjaalton: which release? | 17:07 |
| smoser | pitti, is a generator guaranteed to run before udev events ? i'd guess it must be. | 17:08 |
| nacc | tjaalton: in xenial, i get: http://paste.ubuntu.com/15402793/ | 17:08 |
| tjaalton | xenial | 17:08 |
| xnox | smoser, 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 |
| smoser | right. | 17:08 |
| smoser | that sounds sane. | 17:09 |
| tjaalton | nacc: hostname foo.bar | 17:09 |
| nacc | tjaalton: doing that and updated /etc/hosts in my schroot, it started up and is asking me for a "Subsystem" | 17:10 |
| tjaalton | and it should only have [CA]? | 17:10 |
| tjaalton | hit enter | 17:11 |
| nacc | tjaalton: ok, Directory server is localhost? | 17:12 |
| tjaalton | oh right, you need that set up first | 17:13 |
| tjaalton | install 389-ds-base | 17:13 |
| === alexisb is now known as alexisb-afk | ||
| nacc | tjaalton: ok | 17:14 |
| tjaalton | run setup-ds | 17:14 |
| tjaalton | express | 17:14 |
| nacc | tjaalton: ok, one sec | 17:14 |
| pitti | smoser: not before the initrd's udev, but certainly before we re-start udev adn do the big udevtrigger | 17:18 |
| pitti | right, what xnox said | 17:18 |
| smoser | yeah. so woudl there be an easy way to say "am i shooting for the cloud-inti target" in udev ? | 17:19 |
| smoser | i can check for the .target file taht the generator would have written | 17:19 |
| nacc | tjaalton: might need more config to make it work in a sbuild :/ | 17:22 |
| pitti | smoser: 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 |
| tjaalton | nacc: no you need a real machine | 17:23 |
| tjaalton | aiui | 17:23 |
| nacc | tjaalton: :/ ok | 17:23 |
| nacc | tjaalton: not as easy for me to easily reproduce then :) | 17:24 |
| tjaalton | real as in proper install, virtual or otherwise | 17:24 |
| tjaalton | not chroot | 17:24 |
| rbasak | sinzui: 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 |
| ubottu | bug 1557830 in juju-mongodb (Ubuntu) "[needs-packaging] juju-mongodb2.6 in xenial, wily, and trusty" [Undecided,New] https://launchpad.net/bugs/1557830 | 17:27 |
| tjaalton | nacc: this seems related https://bugs.launchpad.net/ubuntu/+source/axis/+bug/894302 | 17:27 |
| ubottu | Launchpad bug 894302 in axis (Ubuntu Trusty) "jar files do not include OSGi metadata" [High,Triaged] | 17:27 |
| sinzui | thank you rbasak | 17:28 |
| nacc | tjaalton: ok, i can try and look into it if jamespage can't | 17:29 |
| tjaalton | heh, and https://bugs.launchpad.net/ubuntu/+source/libcommons-lang-java/+bug/1556647 | 17:29 |
| ubottu | Launchpad bug 1556647 in libcommons-lang-java (Ubuntu) "/usr/share/java/commons-lang.jar contains documentation" [Undecided,Confirmed] | 17:29 |
| tjaalton | explains why it's so big | 17:30 |
| tjaalton | and why it's broken | 17:30 |
| nacc | tjaalton: ok, one sec | 17:30 |
| === salem_ is now known as _salem | ||
| nacc | tjaalton: i'll try and reproduce & debug | 17:33 |
| nacc | tjaalton: you're right, that's almost certainly the underlying cause | 17:33 |
| === _salem is now known as salem_ | ||
| nlsthzn | quick 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 |
| nlsthzn | with all of the 16.04 images I have tried | 17:42 |
| nlsthzn | ubuntu / mate / xubuntu etc. | 17:42 |
| tjaalton | nacc: 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.gz | 17:43 |
| tjaalton | or maybe not | 17:44 |
| xnox | sinzui, 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 |
| xnox | pitti, now i see what you meant by all mongos everywhere. | 18:00 |
| pitti | xnox: it's astounding. time is fleeting! Maaaaadness takes its toll. | 18:00 |
| sinzui | xnox: 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 solution | 18:01 |
| pitti | leeeet's dooo the moooongoooo agaaaain ♪ | 18:01 |
| xnox | sinzui, e.g. like sqlite or something =) | 18:01 |
| sinzui | :) | 18:01 |
| pitti | if we could serialize juju's db, why bother and not just always use that serialization format *cough* :) | 18:02 |
| xnox | sinzui, as far as i can tell, we don't actually use anything mongo-ish in juju. | 18:02 |
| sinzui | xnox: 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_ | ||
| nacc | slangasek: great, s390x failures fixed, sending a debdiff for that and the twig failures (as it's a real bugfix too) | 18:37 |
| nacc | slangasek: LP: #1558201 | 18:41 |
| ubottu | Launchpad bug 1558201 in php7.0 (Ubuntu) "php-sabre-dav-2.1 testsuite failures in mb_stripos on s390x" [Undecided,New] https://launchpad.net/bugs/1558201 | 18:41 |
| nacc | tjaalton: weird, the build produces a good jar, but something but be messing it up, reproduced and debugging now | 18:53 |
| === salem_ is now known as _salem | ||
| slangasek | nacc: 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 diff | 19:07 |
| ubottu | Launchpad bug 1558201 in php7.0 (Ubuntu) "php-sabre-dav-2.1 testsuite failures in mb_stripos on s390x" [Undecided,New] https://launchpad.net/bugs/1558201 | 19:07 |
| === _salem is now known as salem_ | ||
| slangasek | (now that I've got the imagick hints the right way 'round) | 19:08 |
| nacc | slangasek: yes, i think so -- that will fix the two known issues we've hit in testing with php7.0 | 19:13 |
| slangasek | nacc: which are the two? I only saw the sabre-dav/s390x one | 19:14 |
| nacc | slangasek: sorry, the debdiff has two patches added | 19:14 |
| slangasek | ok | 19:14 |
| nacc | slangasek: i wasn't sure how to do that with the two bugs | 19:14 |
| slangasek | like that is fine :) | 19:14 |
| nacc | ok :) | 19:14 |
| nacc | tjaalton: i think i found it | 19:18 |
| nacc | tjaalton: but would need jamespage to review it | 19:18 |
| slangasek | nacc: 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 that | 19:21 |
| slangasek | then the php gallstone will be cleared and we can tie up loose ends | 19:21 |
| nacc | slangasek: great, thanks | 19: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 |
| ubottu | Launchpad bug 1557787 in git (Debian) "client/server RCEs in path_name()" [Unknown,Confirmed] | 19:23 |
| slangasek | nacc: debian/patches, please include Bug-Ubuntu references for clarity; do you want to fix those up or shall I? | 19:25 |
| slangasek | nacc: btw, provided proper Bug-Ubuntu headers, I favor generating the debian/changelog entries using dep3changelog | 19:26 |
| nacc | slangasek: ah sorry, i can fix that up, i didn't have one of the bugs opened yet. Let me do that and run that command | 19:26 |
| slangasek | (though the authorship of dep3changelog may imply some bias) | 19:26 |
| slangasek | nacc: 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 failure | 19:30 |
| nacc | slangasek: good question | 19:32 |
| slangasek | nacc: 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 |
| slangasek | I suppose because somebody could be building php against a stand-alone built of this library and it's ABI-changing | 19:33 |
| slangasek | nacc: oh look, php migrated | 19:33 |
| nacc | slangasek: awesome; and updated debdiff posted in that same bug | 19:34 |
| slangasek | nacc: ok, so reason #1 not to build with -Wall -Werror, the phpdbg build fails to configure when using those flags ;) | 19:51 |
| nacc | heh | 19:53 |
| nacc | slangasek: i wondered about that | 19:53 |
| nacc | slangasek: there are a ton of warnings already emitted | 19:53 |
| nacc | slangasek: so that's probably why | 19:54 |
| nacc | but they could possible turn on some flags | 19:54 |
| nacc | slangasek: upstream is finally fixing all the semicolon issues, but even that's not done yet, afaict | 19:54 |
| slangasek | and if I ignore that, I get http://paste.ubuntu.com/15404033/ | 19:54 |
| nacc | hrm | 19:55 |
| nacc | Pharaoh_Atem: do you know --^ ? | 19:55 |
| nacc | slangasek: in theory, could do -Werror -Wincompatible-pointer-types, right? | 19:56 |
| slangasek | the problem is the configure script is wrong about strtok_r not being defined, so it goes a bit off | 19:56 |
| nacc | oh i see | 19:56 |
| slangasek | nacc: yeah possibly | 19:56 |
| slangasek | I think there are probably a lot of other warnings you'd want turned on :) | 19:56 |
| nacc | slangasek: yeah, i can take that as another todo | 19:56 |
| nacc | slangasek: to at least look into | 19:57 |
| slangasek | nacc: yeah; it's not urgent, but chances are it'd turn up other latent bugs like the mbstring one | 19:57 |
| nacc | slangasek: yep | 19:57 |
| slangasek | nacc: -Wincompatible-pointer-types doesn't catch it, fwiw | 19:58 |
| slangasek | not sure what the right -W flag is, I guess doko might know | 19:58 |
| nacc | slangasek: 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 |
| slangasek | nacc: 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 run | 20:04 |
| nacc | slangasek: ah! i see, more timing nuance :) | 20:04 |
| slangasek | nacc: I haven't seen a new debdiff for php-imagick. you still working on that one? | 20:34 |
| nacc | slangasek: yeah, having issues with my adt-lxc at home | 20:52 |
| nacc | slangasek: let me try to resync my base image and start the tests up again | 20:52 |
| slangasek | nacc: ok no hurry, just trying to make sure I'm not dropping any balls | 20:54 |
| nacc | slangasek: 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 today | 20:55 |
| slangasek | ok | 20:56 |
| slangasek | nacc: do you know anything about this warning?: W: php-mongodb source: pear-package-without-pkg-php-tools-builddep | 21:04 |
| nacc | slangasek: i think it's this: https://lintian.debian.org/tags/pear-package-without-pkg-php-tools-builddep.html | 21:08 |
| nacc | slangasek: it's part of the debian php7.0 transition, iiuc | 21:08 |
| Son_Goku | yeah, as part of the update to php7, most distros are yanking pear specific requirements | 21:13 |
| Son_Goku | mainly to kill a couple of circular dependencies that are a pain to resolve when doing a bootstrap upgrade | 21:13 |
| Son_Goku | err, a bootstrap of a new php version for an upgrade | 21:14 |
| Son_Goku | not for bootstrap the js thingy | 21:14 |
| Unit193 | Hello. Is there any specific reason adobe-flashplugin is stuck in partner-proposed? I don't see it on the update excuses page. | 21:16 |
| lamont | cyphermox: smb doko any of you around? | 21:27 |
| cyphermox | lamont: yeah | 21:27 |
| lamont | wanna play with bind9 / isc-dhcp for me? | 21:27 |
| lamont | I'll be uploading to a couple of ppas momentarily | 21:27 |
| doko | lamont, where? | 21:28 |
| lamont | my ppa, and the maas ppa | 21:29 |
| lamont | once it gets any exposure, xenial | 21:29 |
| lamont | but zomfg | 21:29 |
| lamont | I 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 |
| lamont | ISC dropped the --enable-exportlib configure code | 21:30 |
| * doko thought that URL were common knowledge ;-P | 21:30 | |
| lamont | dpkg-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 | ||
| lamont | bah and bother | 21:31 |
| lamont | oh haha | 21:31 |
| lamont | and then, this weekend maybe (hahaha), I plan to roll to 9.10.3.dfsg.P4, because it's out | 21:43 |
| dasjoe | xnox: hey, come join us in #zfsonlinux ;) Never seen somebody with a s390x use it | 21:46 |
| xnox | dasjoe, well... ssssh | 21:46 |
| xnox | =) | 21:47 |
| slangasek | nacc: 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 why | 21:51 |
| tjaalton | nacc: I can sponsor libcommons-lang-java | 22:15 |
| nacc | tjaalton: ok, it looks like an obvious tweak to me and the generated jar seems correct now | 22:16 |
| tjaalton | nacc: yep | 22:16 |
| lamont | cyphermox: https://launchpad.net/~lamont/+archive/ubuntu/ppa/+build/9360619 | 22:16 |
| lamont | still building, and once it finishes, I'll upload isc-dhcp | 22:16 |
| nacc | slangasek: 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 ArrayAccess | 22:20 |
| nacc | that, in turn, implicitly calls getOffset() for the $table variable | 22:20 |
| nacc | getOffset is declared as getOffset($offset) | 22:21 |
| nacc | but, it seems like when [] is used, $offset is empty | 22:21 |
| nacc | so it can't be accessed and throws an error | 22:21 |
| slangasek | nacc: 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 decade | 22:22 |
| nacc | slangasek: 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 up | 22:23 |
| nacc | slangasek: is it possible for me to see the autopkgtst results for 1.7-1? | 22:25 |
| tjaalton | nacc: uploaded | 22:25 |
| slangasek | nacc: http://autopkgtest.ubuntu.com/packages/p/php-zeta-console-tools/ ? | 22:25 |
| slangasek | nacc: seems it passed with php5 5.6.17+dfsg-3ubuntu1, and fails before and after | 22:25 |
| nacc | slangasek: indeed | 22:29 |
| nacc | i wish i knew what "bug #10710" is referring to | 22:29 |
| ubottu | bug 10710 in Ubuntu "linux86: FTBFS on amd64: elksemu's file format not recognized." [High,Fix released] https://launchpad.net/bugs/10710 | 22:29 |
| nacc | err, sorry, it's definitely *not* referring to that :) | 22:29 |
| nacc | slangasek: asking on their IRC channel | 22:33 |
| nacc | slangasek: would you be able to review LP: #1543803? to fix my AWS error | 22:37 |
| ubottu | Launchpad 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/1543803 | 22:37 |
| nacc | slangasek: that's one of the two holdups for php-monolog | 22:37 |
| Logan | hey 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 |
| slangasek | nacc: yeah, still on my todo list | 22:45 |
| lamont | doko 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 test | 22:46 |
| pitti | Logan: see debian bug 798618, looks like it wasn't applied in Debian yet, so it needs merging | 22:46 |
| ubottu | Debian bug 798618 in chef "chef-client: autopkgtest race condition" [Normal,Open] http://bugs.debian.org/798618 | 22:46 |
| Logan | pitti: ok, mind if I grab the merge in that case? | 22:47 |
| pitti | Logan: of course I don't mind, thank you! | 22:47 |
| Logan | of course :) | 22:47 |
| Logan | hmm, spoke too soon. the package needs to reduce its dependency on the plist gem as well :| | 22:53 |
| smb | lamont, Right now I only see bind9 there. But since yesterday's tomorrow just became today, I will have a look in a few hours | 23:05 |
| nacc | slangasek: fyi, the php-zeta-console-tools is a bug in php, fixed upstream, narrowing it down now | 23:30 |
| lamont | heh | 23:49 |
| lamont | smb: /me typoed the upload url :( | 23:52 |
| lamont | _now_ it's uploaded | 23:53 |
| lamont | and building | 23:53 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!