| cyphermox | slangasek: ^ | 01:18 |
|---|---|---|
| cyphermox | seems to work correctly (as far as I could figure out for test cases) on ppc64el. | 01:18 |
| cyphermox | (that was for ltrace, obviously) | 01:19 |
| RAOF | Someone's having a joke with that package name :) | 05:27 |
| slangasek | cyphermox: I see a lot of backported arm commits, but only power bugs linked in the changelog; were these requested somewhere, needed somehow as deps of the power commits you cherry-picked? | 05:29 |
| cyphermox | they're required as deps of the POWER commits, sadly | 05:29 |
| cyphermox | or we could spend time to untie it all | 05:30 |
| slangasek | ok | 05:31 |
| slangasek | cyphermox: and which archs did you test the result on? | 05:32 |
| cyphermox | amd64, ppc64el, and briefly on armhf | 05:32 |
| cyphermox | on armhf, AFAICT it was already broken, it still is. | 05:32 |
| cyphermox | it's partly why I'm trying to set up my raspberry pi to have an environment in which I'm more certain of the starting state | 05:34 |
| pitti | infinity: ^ I'd appreciate if you could review this soon, as there's some urgency wrt. the IBM fix | 07:20 |
| pitti | (just three fixes and a couple of test improvements) | 07:20 |
| infinity | pitti: Don't virtio eth devices suffer exactly the same issue as ibmveth? | 07:28 |
| pitti | infinity: no, ifnames recognizes and names virtio devices, QEMU provides some kind of slot number | 07:28 |
| pitti | "ens3" | 07:29 |
| infinity | Hrm. I would think openfirmware gives some faux physical address to veth as well. | 07:29 |
| pitti | I looked through the udev dump and there was nothing except the MAC | 07:30 |
| pitti | so I was quite happy that the IBM engineer helpfully pointed out that the number in DEVPATH is "hardware"-assigned | 07:30 |
| pitti | (and that's what they want to use for naming them) | 07:30 |
| infinity | pitti: Ahh, yes, that's the of I/O address. | 07:31 |
| infinity | pitti: I didn't get that far in the comments yet. ;) | 07:31 |
| pitti | heh yeah, took a bit of back and forth to get there | 07:31 |
| infinity | And +1 for including it in the udeb. | 07:33 |
| pitti | that's crucial, yes; otherwise the installer would generate a wrong /e/n/i | 07:33 |
| infinity | Quite. | 07:33 |
| infinity | Which is why I was looking for it. :P | 07:34 |
| infinity | Cause I think we've been down that painful road before. | 07:34 |
| pitti | during that I noticed that we forgot to include 73-idrac.rules in the initrd | 07:34 |
| pitti | probably not that important, but presumably more important for ibmveth | 07:34 |
| pitti | thanks | 07:35 |
| pitti | tests will fail because of bug 1569204 | 07:35 |
| ubot5` | bug 1569204 in network-manager (Ubuntu Xenial) "xenial regression: does not start any more under upstart" [Critical,Triaged] https://launchpad.net/bugs/1569204 | 07:35 |
| pitti | I assume cyphermox is asleep now, so I'll get that fixed | 07:35 |
| infinity | pitti: Speaking of initrds, did you test that that rule DTRT in a busybox environment? | 07:35 |
| pitti | infinity: well, I tested that I get my eth0 device renamed to ibmveth2 in the initrd | 07:36 |
| infinity | Same thing. | 07:36 |
| pitti | I had to fudge the rule a bit to work with a qemu device, of course | 07:36 |
| infinity | qemu does ibmveth. | 07:37 |
| pitti | i. e. attach a fake ENV{XDEVPATH} and change teh rule to use XDEVPATH, but should be by and large the same | 07:37 |
| infinity | Oh, unless you were testing on x86. ;) | 07:37 |
| pitti | yeah, of course I was, I don't have that kind of access to ppc64el | 07:37 |
| pitti | (can't attach them to scalingstack instances) | 07:37 |
| infinity | qemu-system-ppc64 works on x86 too, mind you. | 07:37 |
| infinity | Just not super speedy. | 07:37 |
| pitti | oh, and that does ibmveth? | 07:37 |
| infinity | Yeah. | 07:38 |
| pitti | slick | 07:38 |
| infinity | pitti: Bah. I wish I could read. | 07:48 |
| infinity | pitti: You have mismatched quotes in there. | 07:48 |
| infinity | Which I didn't notice before I accepted... | 07:48 |
| infinity | pitti: Also, a trivial command-line test doesn't seem to work. | 07:49 |
| infinity | (base)adconrad@nosferatu:~$ export DEVPATH=/devices/vio/30000002/net/eth1(base)adconrad@nosferatu:~$ /bin/sh -ec 'D=${DEVPATH#*/vio/}; D=${D#3}; echo ${D%%%%/*} | sed s/^0*//' | 07:49 |
| infinity | 2/net/eth1 | 07:49 |
| infinity | Pretty sure that should be '2'? | 07:50 |
| pitti | did you replace %%%% with %% on the command line? | 07:50 |
| pitti | %% == % in an udev rule (escaping) | 07:50 |
| infinity | Oh. | 07:50 |
| infinity | Yeah, that works better. ;) | 07:50 |
| infinity | Still mismatched quotes, though, unless I can't read. | 07:50 |
| pitti | I might have wedged this up after testing, I added the match on ACTION==, I think | 07:50 |
| infinity | pitti: cmd="sh -ec 'cmd" | 07:51 |
| infinity | pitti: You seem to be missing the closing ' after cmd. | 07:51 |
| pitti | (and had to revert my testing changes) | 07:51 |
| * infinity says abiguously, after using 'cmd' twice in his example. | 07:52 | |
| pitti | argh, yes | 07:52 |
| Kamilion | many eyes... | 07:52 |
| infinity | pitti: Also, not sure if 30000000 is a valid address (ie: ibmveth0), but if it is, your rule won't work for that either. | 07:53 |
| pitti | infinity: ah, that would end up as "ibmveth" only, I suppose we want "ibmveth0" | 07:54 |
| infinity | We would, yeah. | 07:54 |
| pitti | infinity: thanks for the review, I'll fix both issues | 07:54 |
| infinity | pitti: Extra fun, cutting the 3 based on the IBM engineer's "it's always 3" is BS. | 07:56 |
| infinity | pitti: I have /sys/devices/vio/71000002/net/eth0 here. :P | 07:56 |
| infinity | pitti: That appears to be a qemu/kvm default setup. | 07:57 |
| pitti | infinity: so you get an ibmveth710002? | 08:02 |
| pitti | ^ that puts back the upstart job (above bug), tested in VM with current NM | 08:04 |
| infinity | 'D=${DEVPATH#*/vio/}; D=${D%%/*}; D=${D##*0}; echo ${D}' ... That solves the "start may not be 3" thing. Doesn't deal with the possibility of 0. | 08:06 |
| pitti | infinity: what's the problem with "cut off a leading 3 if it's there"? | 08:06 |
| pitti | D=${D#3} is a no-op if it doesn't start with 3 | 08:06 |
| infinity | pitti: Because I have a leading 71? :P | 08:06 |
| pitti | infinity: then that doesn't do anything | 08:06 |
| infinity | pitti: Yes, but then your sed doesn't sed. | 08:07 |
| pitti | right | 08:07 |
| pitti | but then I also don't really want it to | 08:07 |
| pitti | you might have a 3000001 and a 7000001 | 08:07 |
| infinity | I suppose I could have two virtual busses. Maybe. | 08:07 |
| pitti | unless there's some guarantee that this can't happen? | 08:07 |
| infinity | I've never seen a setup like that. | 08:08 |
| pitti | infinity: so in your rule you just cut out the inner 0's, making it "ibmveth712"? and "ibmveth32" for the original bug's example? | 08:09 |
| pitti | ah no, you cut out the prefix entirely | 08:10 |
| infinity | pitti: No, my rule ended up with the same result as yours, but... Yes. | 08:10 |
| pitti | infinity: if that is safe, that WFM | 08:11 |
| infinity | pitti: The only thing that's probably 100% safe is using the entire I/O address, but I can't see anyone liking that solution. | 08:11 |
| infinity | pitti: But I've never seen a setup with multiple virtual busses. 3* and 7* seem most common. | 08:12 |
| pitti | infinity: so adding a final echo ${D:-0} should solve the "300000" case as well | 08:12 |
| infinity | pitti: I miss 70-persistent-net.rules :P | 08:12 |
| pitti | I don't :) | 08:12 |
| pitti | but anyway, nothing stops you from creating one again, with pretty names :) | 08:13 |
| infinity | Indeed, 'D=${DEVPATH#*/vio/}; D=${D%%/*}; D=${D##*0}; echo ${D:-0}' | 08:13 |
| infinity | And no more sed. | 08:13 |
| infinity | Which was bugging me. | 08:13 |
| pitti | yeah, it's sad that shell globs don't work for a thing like "any number of '0's" | 08:13 |
| infinity | pitti: It's one of those "POSIX is old" things. :/ | 08:14 |
| pitti | infinity: ${D%%%%/*} is missing, or am I overlooking somethign? | 08:14 |
| infinity | pitti: bash has awesomely powerful regexes, but no can use. | 08:15 |
| infinity | pitti: It's there, I just didn't escape it. | 08:15 |
| pitti | infinity: well, I know bash has =~, but that doesn't work in ${var..} substitutions? | 08:15 |
| infinity | (Because I was testing on the CLI) | 08:15 |
| pitti | oh, ${var/pattern/string} | 08:16 |
| infinity | pitti: You can use #{haystack/needle/replacemen} | 08:16 |
| infinity | Yeah. | 08:16 |
| infinity | It's quite nice. | 08:16 |
| infinity | But if no one has declared bash the One True Shell yet, I don't think it's ever going to happen. | 08:17 |
| infinity | So, POSIX it is. | 08:17 |
| infinity | Untill we ditch UNIX entirely and start over. | 08:17 |
| Ukikie | I used ln -s /dev/null /etc/udev/rules.d/80-net-setup-link.rules >_> | 08:18 |
| infinity | pitti: As for the "you can write your own" argument, the nice thing about 70-persistent-net.rules being done automagically was that I had a template for how to write the rule. ;) | 08:19 |
| infinity | pitti: And then would rewrite it based on which device I wanted named what. | 08:19 |
| pitti | see /usr/share/doc/udev/README.Debian.gz | 08:19 |
| infinity | Cause ain't no one got time to learn how to write udev rules just because they want their interfaces renamed. | 08:19 |
| pitti | example rules how to name them by MAC, by USB ID, or PCI vendor/model | 08:19 |
| infinity | pitti: Aha, danke. | 08:20 |
| === sil2100_ is now known as sil2100 | ||
| infinity | pitti: That MAC address is a lot shorter than the one that used to be written by 70-persistent. | 08:21 |
| infinity | pitti: Was the rest just pointless fluff? :P | 08:21 |
| infinity | Old: | 08:21 |
| infinity | SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", ATTR{address}=="68:f7:28:77:e3:a8", ATTR{dev_id}=="0x0", ATTR{type}=="1", KERNEL=="eth*", NAME="eth0" | 08:21 |
| infinity | New: | 08:22 |
| infinity | SUBSYSTEM=="net", ACTION=="add", ATTR{address}=="11:22:aa:bb:cc:33", NAME="eth-dmz" | 08:22 |
| pitti | infinity: that was because the generator supported different kinds of matches, of which MAC only was one | 08:23 |
| pitti | (but I don't know why dev_id and type got matched, seems rather pointless) | 08:23 |
| infinity | Kay, well, the shorter rule is almost something a human could learn. | 08:24 |
| infinity | The long one was the reason I gave up trying. | 08:24 |
| pitti | [ 1.147326] virtio_net virtio0 ibmveth2: renamed from eth0 | 08:26 |
| pitti | and that happened in initramfs | 08:26 |
| pitti | yay | 08:26 |
| infinity | I can test this on a real ppc machine too, if you like. | 08:26 |
| pitti | that'd be nice; let me toss you the final commit once I pushed it (typing commit log ATM) | 08:27 |
| * infinity nods. | 08:28 | |
| pitti | http://anonscm.debian.org/cgit/pkg-systemd/systemd.git/commit/?id=66e67d1 | 08:29 |
| pitti | ah, forgot to mention the 'handle device number 0' in the commit log | 08:30 |
| infinity | You also kept the comment stating that it "usually starts with 3", but meh. :P | 08:31 |
| pitti | http://anonscm.debian.org/cgit/pkg-systemd/systemd.git/commit/?id=b83febe255 | 08:31 |
| infinity | (That's probably true on LPARs) | 08:31 |
| pitti | infinity: ah, let me fix that too | 08:31 |
| pitti | infinity: http://anonscm.debian.org/cgit/pkg-systemd/systemd.git/commit/?id=3dee9da | 08:32 |
| infinity | pitti: Rebooting. | 08:36 |
| infinity | 2: ibmveth2: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN mode DEFAULT group default qlen 1000 | 08:37 |
| infinity | [ 3.896825] ibmveth 71000002 ibmveth2: renamed from eth0 | 08:38 |
| pitti | LGTM | 08:40 |
| infinity | Yep. | 08:40 |
| pitti | infinity: ok, merging into Ubuntu, and reuploading; many thanks for your help! | 08:41 |
| infinity | pitti: Ta. | 08:41 |
| pitti | uploaded | 08:44 |
| pitti | this also adjusts one tests for NM 1.2 not logging to syslog by default any more | 08:45 |
| pitti | ... which seems like a bug, but it's not really systemd's concern | 08:45 |
| infinity | pitti: Not your bug but wow, that assumption that system and user locales are the same is special. :P | 08:46 |
| pitti | infinity: err, what? | 08:46 |
| infinity | pitti: In the n-m upstart job. | 08:47 |
| pitti | infinity: heh, yes | 08:47 |
| pitti | I put back the file as it was, let's not introduce conffile changes now | 08:47 |
| pitti | but apparently we got along with that for years | 08:47 |
| infinity | pitti: Well, I assume it's a fundamental architectural defect in n-m (as if it doesn't have enough of those). | 08:48 |
| infinity | pitti: Since one would expect a proper architecture would be for the daemon to pass C strings to the client, and have the client look them up based on *its* environment. | 08:49 |
| infinity | (or similar) | 08:49 |
| pitti | yeah, or error codes | 08:49 |
| Mirv | hmm, are the non-languagepack translations on track to be updated this cycle? it's reported that at least ubiquity does not have up-to-date translations, and bzr log po or debian/real-po shows they'd be last updated in October 2014 | 08:49 |
| pitti | but dgettext()ing them on the client side sounds fine too | 08:49 |
| pitti | (with NM's domain) | 08:49 |
| knome | ubiquity-slideshow-ubuntu needs an upload too | 08:50 |
| knome | Mirv, ^ | 08:50 |
| davmor2 | infinity: so I have an image in current from yesterday but nothing for today, I assume that is down to a test failure or something right? | 08:50 |
| Mirv | knome: yep, they're all listed at https://wiki.ubuntu.com/NonLanguagePackTranslationDeadline | 08:51 |
| knome | :) | 08:51 |
| Mirv | I'm just wondering since I remember there was reshuffling of responsibilities within Foundations team when colin stopped doing some of the things, and I wonder if this was assigned to someone | 08:52 |
| infinity | davmor2: I see a fresh daily for today, no idea why it's not in current/ yet. Ask your manager. :P | 08:52 |
| knome | Mirv, mhm, indeed | 08:52 |
| davmor2 | infinity: my manager is currently flying to managers sprint :P | 08:52 |
| infinity | davmor2: Anyhow, for QA people, I'd expect you to ignore the pending/current directories and just consume the most recent date. | 08:54 |
| infinity | davmor2: Especially given how often the smoketest infra breaks. | 08:54 |
| davmor2 | infinity: nope always import from current/pending as they tend to be the images that work :) | 08:55 |
| davmor2 | infinity: pending will be the most recent iirc | 08:56 |
| infinity | davmor2: pending should be the same as the most recent date, yes. | 08:56 |
| infinity | davmor2: current is a crap shoot. ;) | 08:56 |
| davmor2 | infinity: indeed pending is 12th but | 08:56 |
| pitti | FTR, one major reason (ssh startup failure) for failing tests got fixed a few days ago | 08:56 |
| davmor2 | infinity: I bet it is failing autopackage | 08:56 |
| infinity | autpkgtests don't relate to this at all. | 08:57 |
| infinity | Unless you mean something else. | 08:57 |
| infinity | You could also just be impatient. I don't know how to see into the guts of the ISO smoketests. | 08:57 |
| infinity | pitti sounds like he might know. | 08:57 |
| pitti | e. g. https://platform-qa-jenkins.ubuntu.com/job/ubuntu-xenial-desktop-i386-smoke-default/ | 08:58 |
| pitti | today's test is running | 08:58 |
| pitti | https://platform-qa-jenkins.ubuntu.com/job/ubuntu-xenial-desktop-amd64-smoke-default/ too | 08:58 |
| infinity | What a pretty graph... | 08:58 |
| pitti | https://platform-qa-jenkins.ubuntu.com/view/desktop/ actually looks pleasantly green (aside from the upgrades) | 08:59 |
| infinity | tar: Unexpected EOF in archive | 09:00 |
| infinity | tar: Error is not recoverable: exiting now | 09:00 |
| infinity | qemu: terminating on signal 15 from pid 8826 | 09:00 |
| infinity | That haunts us everywhere. | 09:00 |
| rbasak | Is overlayfs involved? | 09:09 |
| rbasak | There's a bug/interaction between tar and overlayfs that makes things break. | 09:09 |
| pitti | rbasak: it uses an overlay, but the qemu-img one | 09:11 |
| pitti | but I think this is some weird kind of hiccup with qemu's 9p file system | 09:11 |
| pitti | so far I got a few reports from here and there, but I didn't get ssh access to a machine which exhibits this | 09:12 |
| infinity | pitti: Ugh. I didn't think that through. It'll fail for LPARs with > 10 (or >16, not sure if that address is hex) interfaces. | 09:12 |
| pitti | I got some more reports from trusty hosts, apparently wily's/xenial's qemu behaves a bit better there | 09:12 |
| infinity | pitti: Might need to get sed back in the mix to actually write a real regex. :/ | 09:12 |
| pitti | infinity: oh, 3000102? | 09:13 |
| infinity | pitti: Well, or just 30000010 | 09:13 |
| infinity | pitti: Cause it's a greedy match for *0, so 10 would end up as 0. | 09:13 |
| pitti | ah, this certainly needs to be a non-greedy match, i. e. up to first 0 only | 09:13 |
| pitti | ^ u-d-common is just a simple FTBFS fix, FTR | 09:14 |
| infinity | pitti: I'm going to sleep before I break more things. :P | 09:14 |
| pitti | infinity: I'll stare at this harder and make more experiments in a VM | 09:15 |
| pitti | D=${D#*0} ought to work already | 09:15 |
| infinity | pitti: Cutting all the zeroes out of the middle when we don't know what the bus addresses might be is a bit of a pain. | 09:15 |
| infinity | Since you could have something like 30100010, and you want the result to be 10. | 09:16 |
| pitti | hmm, D=${D#*00} then? | 09:16 |
| apw | is that two fields in there or something ? | 09:16 |
| pitti | if we have some ugly-long names in utter corner cases it doesn't hurt | 09:16 |
| pitti | apw: bus number slot number, yes | 09:17 |
| infinity | pitti: Yeah, 00 gives us 100 interfaces, I think if they have more, sucks to be them. That's an alright compromise. | 09:17 |
| pitti | infinity: no, more should be fine, with non-greedy match and sed | 09:18 |
| pitti | $ X=300001002 | 09:18 |
| pitti | $ echo ${X#*00} | sed 's/^0*//' | 09:18 |
| pitti | 1002 | 09:18 |
| infinity | non-greedy would beak, say, 30020010 | 09:19 |
| infinity | I'm not sure how many digits are owned by the "bus" and how many by the "slot". | 09:20 |
| infinity | If that terminology even applies. | 09:20 |
| pitti | infinity: I think for 30020010 it sounds saver to name it ibmveth20010 | 09:20 |
| infinity | I think it might be just straight up I/O addresses. | 09:20 |
| pitti | if you configure 5-digit slot IDs, you get to keep both halves, I think | 09:20 |
| infinity | pitti: Kay. I'm down with that. | 09:21 |
| pitti | I don't know what a HMC is, but the IBM engineer said that you select the slot id there | 09:21 |
| infinity | pitti: In the wild, it seems 3000xxxx (for LPARs) and 7100xxxx (for qemu) seem to be the two most common anyway. | 09:21 |
| infinity | One can configure qemu to give you literally any address, but I think you get to keep the pieces if you do that. | 09:21 |
| infinity | pitti: An HMC is an external machine that pools all your chassis' into one configuration group so you can spin up LPARs on any of them. | 09:22 |
| infinity | pitti: Not really relevant to the discussion, except than it's the simple way to configure lots of LPARs. | 09:22 |
| davmor2 | infinity: go to sleep already :P | 09:23 |
| * pitti yays at "sudo udevadm test /class/net/eth0" being such an useful tool | 09:24 | |
| infinity | pitti: Okay, the other scenario I know of (kimchi, a libvirt frontend) appears to pretend to be an LPAR, and configures qemu with 3000xxxx addresses, so that would work with your double-0 and non-greedy fix. | 09:26 |
| infinity | Worst case, they'd get ibmveth1000, but meh. | 09:26 |
| pitti | we could also drop the "veth" in between | 09:26 |
| infinity | pitti: Though, that also lends some credence to those being 1234:1234 bus:slot. | 09:27 |
| pitti | so that we get ibm0 or ibm1000, but not sure if there's other ibm-ish devices and that'd be confusing | 09:27 |
| infinity | And maybe cutting the string in half before stripping leading zeroes would be sane. | 09:27 |
| infinity | Or ibm71s10 | 09:27 |
| infinity | Which would match the way PCI is done, sort of. | 09:27 |
| infinity | But also uglier. | 09:28 |
| pitti | PROGRAM="/bin/sh -ec 'D=${XDEVPATH#*/vio/}; D=${D%%%%/*}; D=${D#*00}; D=`echo $D | sed s/^0*//`; echo ${D:-0}'" | 09:28 |
| pitti | 3000000 → ibmveth0 | 09:28 |
| pitti | 3000002 → ibmveth2 | 09:29 |
| pitti | 3001002 → ibmveth1002 | 09:29 |
| pitti | don't like the sed, though | 09:29 |
| pitti | it could be replaced with a while loop and chopping off 0's one by one | 09:29 |
| pitti | which at least is pure sh | 09:29 |
| pitti | (no bash in initramfs) | 09:30 |
| infinity | That sed doesn't seem to be doing much there... | 09:30 |
| pitti | it transforms ibmveth0002 to ibmveth2 | 09:31 |
| pitti | I'll see to making that D=`echo $D | sed...` a bit more elegant | 09:31 |
| pitti | but I think from an "what's the effect" POV this seems to work fairly well now | 09:31 |
| apw | can we not find out the format of that number ? | 09:31 |
| apw | if that is an s390x thing, then i would expect it to be in 4 digit hex halves, as the channels are all 4 digit things | 09:32 |
| infinity | apw: ppc. | 09:33 |
| pitti | apw: we got it in the context of ppc64el, bug 1561096 | 09:33 |
| ubot5` | bug 1561096 in systemd (Ubuntu Xenial) "STC850:Brazos:Br16:Br16p05: Network ethernet port name changed under Ubuntu 16.04 with added adapters (ibmveth)" [High,Fix committed] https://launchpad.net/bugs/1561096 | 09:33 |
| pitti | for i in 1 2 3 4 5 6 7; do D=${D#0}; done | 09:34 |
| pitti | poor man's sed | 09:35 |
| pitti | and ugly as hell, but avoids calling sed and we know it can't be more than 6 0's | 09:35 |
| * pitti isn't sure if `seq 8` spanws a shell, but I guess it does | 09:35 | |
| pitti | oh, wait, can do with while | 09:36 |
| infinity | pitti: It's 8 chars, not 7. | 09:38 |
| pitti | right, we have 8 chars, minus bus ID, minus the two 0's we cut off anyway | 09:38 |
| pitti | so we should have at most 5 zeros | 09:38 |
| pitti | hm, while [ "${D%?*}" = 0 ]; do D=${D#0}; done doesn't do what I want | 09:38 |
| pitti | posix shell string manipulation sucks | 09:39 |
| pitti | /bin/sh -ec 'D=${XDEVPATH#*/vio/}; D=${D%%/*}; D=${D#*00}; while [ "${D#0}" != "$D" ]; do D=${D#0}; done; echo ${D:-0}' | 09:39 |
| pitti | that works | 09:40 |
| xnox | is there any info on as to how Task-* things get published from seeds? there is "Ubuntu Desktop Usb" task which is published for s390x and that one really shouldn't, as there is no ubuntu-desktop metapackage.... | 09:40 |
| cjwatson | germinate doesn't care whether the metapackage exists | 09:42 |
| cjwatson | xnox: I assume you actually only care about it being visible in tasksel? | 09:44 |
| xnox | yes. | 09:44 |
| xnox | or rather that it shouldn't be visible in tasksel on s390x... I would actually be quite happy with all them to exist, but hidden. | 09:44 |
| xnox | i already got one support request "i've tried installing 'Ubuntu Desktop Usb'...." | 09:45 |
| cjwatson | yeah, will fix. | 09:45 |
| xnox | i'm strugling to find where the Task-* stanzas are processed at all and/or published =) and greping ArchiveAdmin wiki page didn't find things. | 09:46 |
| xnox | thanks! | 09:46 |
| cjwatson | lp:ubuntu-archive-publishing is the main bit | 09:46 |
| cjwatson | but in this case it's more important how it's processed by tasksel itself | 09:47 |
| cjwatson | xnox: http://bazaar.launchpad.net/~ubuntu-core-dev/ubuntu-seeds/ubuntu.xenial/revision/2451 should deal with it | 09:49 |
| xnox | cool | 09:49 |
| infinity | pitti: Assuming it is groups of 4, replacing D=${D#*00} with D=${D#????} makes the result a bit saner. The whole thing is gross, though. :P | 09:49 |
| xnox | cjwatson, also we might want to just kill the whole of usb seed, because we are not limited by CD size, and Ev is no longer testing broken, odly shapped, usb sticks from china. =) | 09:50 |
| Kamilion | about as annoying as my dell machines calling their intel 10g nics p55p1 & p55p2... | 09:50 |
| cjwatson | xnox: not my problem :) | 09:51 |
| pitti | infinity: can do that as well, and it's a bit more predictable; I think I'll still keep the while loop to chop off '0's at the beginning, still better than calling sed IMHO | 09:51 |
| Kamilion | http://paste.ubuntu.com/15782157/ nic renaming gives me such a headache. | 09:51 |
| infinity | pitti: "better". :) | 09:51 |
| infinity | I miss the good old days when, to get the names I wanted, I had to reorder the cards in my chassis. | 09:56 |
| pitti | infinity: http://paste.ubuntu.com/15782387/ tested with all of the above scenarios again | 09:58 |
| pitti | it's that or just put four copies of D=${D#0} | 09:59 |
| infinity | pitti: I don't like it, but I've run out of better ideas. :P | 09:59 |
| pitti | -ACTION=="add", SUBSYSTEM=="net", NAME=="", DRIVERS=="ibmveth", PROGRAM="/bin/sh -ec 'D=${DEVPATH#*/vio/}; D=${D%%%%/*}; D=${D#????}; while [ ${D#0} != $D ]; do D=${D#0}; done; echo ${D:-0}'", NAME="ibmveth$result" | 09:59 |
| pitti | +ACTION=="add", SUBSYSTEM=="net", NAME=="", DRIVERS=="ibmveth", PROGRAM="/bin/sh -ec 'D=${DEVPATH#*/vio/}; D=${D%%%%/*}; D=${D#????}; D=${D#0}; D=${D#0}; D=${D#0}; D=${D#0}; echo ${D:-0}'", NAME="ibmveth$result" | 09:59 |
| pitti | wow, this is even shorter by 3 chars, and avoids a potentially infinite loop | 10:00 |
| infinity | pitti: Heh. Yeah, loops in udev rules seem a bit wrong. | 10:00 |
| infinity | pitti: Anyhow, I don't think we're going to make it much prettier without help from the kernel driver. | 10:01 |
| pitti | infinity: so I guess four copies instead of while it is | 10:01 |
| xnox | for s390x i just patched upstream systemd stock renaming rules.... =) | 10:01 |
| xnox | (in C, rather than shell in udev rules) | 10:01 |
| infinity | What names do we get on s390? | 10:02 |
| pitti | but that's for ccw, not for ibmveth | 10:02 |
| xnox | for a cccgroup-0.0.0100 -> which is a 00.0.0000-ff.f.ffff range we now get "enc100" that is "en" for ethernet, "c" for ccw bus, and full-id but with leading zeros stripped. | 10:03 |
| * infinity has a 70-persistent-net.rules on all his s390x hosts, so no idea what the names would be. | 10:03 | |
| xnox | short, stable, determenistic, pretty enough. | 10:03 |
| pitti | http://anonscm.debian.org/cgit/pkg-systemd/systemd.git/commit/?id=8b023317 it is | 10:03 |
| infinity | pitti: You may, indeed, want to suggest to IBM that if they care deeply about this, they commit something upstream, since they should understand their bus/id mapping better than we do. | 10:04 |
| infinity | pitti: But I think our hack is "good enough". | 10:04 |
| pitti | yeah | 10:04 |
| pitti | infinity: not sure if we want yet another upload right away, but if they want to test on a daily image ASAP, then I figure we do | 10:05 |
| infinity | pitti: Yeah, upload away. | 10:05 |
| infinity | Can never have too many. | 10:05 |
| pitti | uploaded | 10:07 |
| davmor2 | sudo goto sleep infinity | 10:08 |
| pitti | as soon as he reviews that upload :) | 10:08 |
| davmor2 | pitti: so it's your fault he is still awake shame on you ;) | 10:09 |
| pitti | yeah, I'm afraid today it is :( | 10:10 |
| infinity | pitti: Why did a patch move in series...? | 10:10 |
| pitti | infinity: it moved from "Debian patches" into "backported from upstream" as my upstream PR just landed | 10:10 |
| pitti | infinity: this is both for bookkeeping, but also for correctly being able to build "daily upstream" packages | 10:11 |
| infinity | Ahh. | 10:11 |
| pitti | as it needs to ignore the backported patches but apply the distro ones | 10:11 |
| pitti | http://anonscm.debian.org/cgit/pkg-systemd/systemd.git/commit/?id=a65bb9 | 10:11 |
| infinity | pitti: Your ch; ch; ch; change is accepted. | 10:11 |
| pitti | infinity: thanks; thanks; thanks! | 10:12 |
| pitti | and now sleep well | 10:12 |
| ogra_ | can someone let ubuntu-core-meta in please | 11:51 |
| doko | ogra_, done | 11:57 |
| * ogra_ hugs doko ... thanks ! | 11:58 | |
| Ukikie | owncloud? | 12:50 |
| mvo | hi, if I could get review/approval for snapd, that would be awesome | 13:04 |
| pitti | mvo: done | 13:11 |
| pitti | doko: base-files> is that supposed to go in now, or next week and this was just for having the upload ready when we need it? | 13:12 |
| doko | pitti, don't know. maybe wait for infinity | 13:13 |
| pitti | yeah, I left it in the queue for now | 13:13 |
| * mvo hugs pitti | 13:20 | |
| jdstrand | slangasek: re mass demote> I did not demote anything | 13:35 |
| mhall119 | infinity: slangasek Laney pitti I need somebody to look at https://bugs.launchpad.net/ubuntu/+source/muon/+bug/1562406 and tell the Kubuntu team if there's something more they need to do in order to get their package updated in xenial please | 13:41 |
| ubot5` | Launchpad bug 1562406 in muon (Ubuntu) "[FFe] Update to latest upstream version" [Undecided,Confirmed] | 13:41 |
| mhall119 | the folks who usually help them get their packages in have not been available lately, so they need someone else to help them | 13:42 |
| mgz | ha, was about to poke about juju-mongodb2.6 package and someone moved it forwards in the last hour. thanks! | 13:53 |
| slangasek | hmm, so who did accept juju-mongodb2.6, which I had put comments into the bug log on? (LP: #1557852) | 14:33 |
| ubot5` | Launchpad bug 1557852 in juju-mongodb (Ubuntu) "[needs-packaging] juju-mongodb3.2 in xenial, wily, and trusty" [Wishlist,Incomplete] https://launchpad.net/bugs/1557852 | 14:33 |
| pitti | not me, I thought you were handling that | 14:33 |
| slangasek | I was, until somebody accepted it out from under me ;) | 14:34 |
| doko | slangasek, me. based on infinity's approval to process NEW packages | 14:36 |
| slangasek | ok | 14:36 |
| slangasek | fair enough :) | 14:36 |
| doko | this gcc-5 upload has for bug fixed, two wrong-code issues on armhf and ppc*, a libgomp update, and an unrelated sh4 change, everything else is patch noise | 14:45 |
| mgz | slangasek: do you mean the 3.2 package or the 2.6 one? | 14:54 |
| mgz | I don't see any comments in the juju-mongodb2.6 bug | 14:54 |
| slangasek | mgz: where was the juju-mongodb2.6 bug? I was commenting on the 3.2 bug because I thought that was the only bug | 14:55 |
| slangasek | 1557830 maybe | 14:56 |
| mgz | slangasek: yeah. they're all linked from the juju ffe bug | 14:59 |
| mgz | slangasek: so, to clarify, 3.2 won't build on armhf | 14:59 |
| mgz | 2.6 is fine. | 14:59 |
| slangasek | ok | 14:59 |
| slangasek | mgz: then we probably want it built consistently across those archs (including armhf and i386) | 15:00 |
| mgz | er, I say "fine"... it builds but dies | 15:00 |
| mgz | there was some debate about what we do over that given we don't care about running state servers on armhf | 15:01 |
| mgz | see the bug | 15:01 |
| mvo | snapd is like super simple, one line change only :) | 15:26 |
| ogra_ | the one line that makes everything explode :) | 15:27 |
| kickinz1 | o/ | 15:46 |
| kickinz1 | I would like to get python-docker 1.8.0 into universe, it would be usefull for openstack magnum project. | 15:47 |
| kickinz1 | https://bugs.launchpad.net/ubuntu/+source/python-docker/+bug/1569424 | 15:47 |
| ubot5` | Launchpad bug 1569424 in python-docker (Ubuntu) "Please update python-docker to 1.8.0 from upstream" [Undecided,New] | 15:47 |
| slangasek | mvo: you want *passing* tests? crazy talk | 15:55 |
| mvo | slangasek: :) | 15:56 |
| slangasek | mvo: looks like there's a duplicate snapd upload though with the same version number | 15:57 |
| mvo | slangasek: yes, its the same, sorry, I was confused by the lack of a mail from the archive | 16:00 |
| mvo | slangasek: maybe my mailserver ate it | 16:00 |
| mvo | slangasek: just reject that duplicated one, sorry again | 16:00 |
| slangasek | mvo: done | 16:01 |
| mvo | ta | 16:01 |
| rbasak | ^ I think this (my) upload might be unnecessary. | 17:13 |
| rbasak | It was to delete src:mysql-5.6, but of course as it's an alternative I think not needed? If not needed, please reject. | 17:13 |
| rbasak | superm1: ^ | 17:14 |
| rbasak | infinity: around? Is this accurate please? ^^ | 17:15 |
| rbasak | I don't want to miss this and get stuck after FinalFreeze :-/ | 17:16 |
| tgm4883 | rbasak: talking about the mythtv upload? | 17:23 |
| rbasak | Yes | 17:24 |
| tgm4883 | rbasak: not sure if yours is necessary or not, but we need to do a new one later today | 17:25 |
| rbasak | tgm4883: it shouldn't cause any harm for Xenial to do it, since the 5.6 packages are intended to disappear soon anyway. But superm1 mentioned backporting, and I can see that this change could get in your way for backporting a little, so if it's unnecessary to do in Xenial then no point in making you maintain it differently. | 17:26 |
| rbasak | Now that I've thought about it I'm fairly sure it's unnecessary but I'd appreciate if an archive admin could confirm, since I don't want to end up stuck. | 17:27 |
| superm1 | it sounds to me that it's unnecessary at this point too | 17:27 |
| rbasak | slangasek: could you advise please if you're around? ^^ | 17:27 |
| slangasek | rbasak: looking | 17:28 |
| slangasek | rbasak: yes, the alternatives don't matter. They make reverse-depends less clear as a tool for processing removals but that's a tooling issue | 17:29 |
| slangasek | rbasak: you want me to reject? | 17:29 |
| rbasak | slangasek: yes please. Thanks! | 17:29 |
| slangasek | rbasak: done | 17:29 |
| rbasak | superm1, tgm4883: so go ahead and ignore that and upload your own ubuntu4 without my change. Sorry for the noise. | 17:30 |
| rbasak | nnnnnnnnnnnThanks again! | 17:30 |
| * rbasak will hold his Alt key down harder next time. | 17:30 | |
| slangasek | if they wanted to include that change that would also be an option :) | 17:31 |
| tgm4883 | superm1: can you do an upload later? | 17:31 |
| rbasak | Yes, but I don't think they do because they try to keep their backport delta small (presumably) | 17:31 |
| superm1 | yeah we use same packaging for backports, so keeping delta small is ideal | 17:31 |
| tgm4883 | I think there were questions whether I did it correctly last time. it was showing a bunch of changes? | 17:31 |
| mdeslaur | important samba update to fix Badlock vulnerabilities ^ | 17:35 |
| xnox | mdeslaur, so it's real... | 17:39 |
| mdeslaur | xnox: it's got a logo, it must be real! :) | 17:40 |
| slangasek | as opposed to an urban legend? :) | 17:40 |
| slangasek | mdeslaur: tested everywhere, same patches as in security pocket, etc? | 17:40 |
| teward | heh | 17:40 |
| slangasek | I guess you're taking the upstream release, so | 17:40 |
| slangasek | I know where to yell at them if it breaks | 17:40 |
| mdeslaur | slangasek: I've ran our usual QA scripts on it, and we're moving trusty and wily to that version also | 17:41 |
| mdeslaur | since the fix is over 400 commits | 17:41 |
| mdeslaur | yes, you've read that right | 17:42 |
| teward | mdeslaur: *four hundred* commits? o.O | 17:42 |
| mdeslaur | teward: yep | 17:42 |
| rbasak | slangasek: how do you feel about for example: Build-Depends-Indep: mysql-server-core-5.6 | mysql-server-core | 17:45 |
| rbasak | That would in theory work with src:mysql-5.6 removed. | 17:45 |
| rbasak | But maybe better to rebuild against 5.7 now? | 17:46 |
| rbasak | (this is amarok) | 17:46 |
| slangasek | rbasak: "rebuild against" - I would assume that's only used for tests at build time or something? | 17:46 |
| rbasak | I think so, yes. | 17:47 |
| slangasek | but why would it be in Build-Depends-Indep instead of Build-Depends, hmm | 17:47 |
| rbasak | However, if behaviour is different with 5.7, then the test using 5.6 wouldn't be valid. | 17:47 |
| rbasak | slangasek: digikam is the same (question), except BD not BDI. I think that's all the seeded reverse deps. | 17:52 |
| rbasak | (I will check again) | 17:52 |
| rbasak | (and akonadi is in unapproved) | 17:52 |
| lamont | http://paste.ubuntu.com/15799193/ <-- at some point, postfix had a blanket feature freeze exception for minor revs (which 3.0 -> 3.1 would qualify for)... is that still in effect? Nearly all of what I see in the current 3.1.0 release notes are things that I'd want to have (as an admin) in xenial, and upstream will unsupport 3.0 much sooner than 3.1, and ... who has better memory of things than me? | 19:22 |
| infinity | lamont: I don't think you ever had a blanket FFe or SRU exception for *minor* releases, though probably for micro. | 19:25 |
| infinity | lamont: That said, I think 3.1 is probably going to be safe enough anyway, and smart to get into xenial, so future updates are 3.1.x micros instead of 3.0.x micros. | 19:25 |
| infinity | lamont: But gimme some time to go over it a bit. | 19:25 |
| lamont | infinity: how about this... you review, ponder, scream at me as needed, and when you're happy, sync 3.1.0-2 from sid? | 19:26 |
| infinity | lamont: Sounds fair. | 19:26 |
| lamont | ta | 19:27 |
| lamont | (and when do I come begging next?) | 19:27 |
| infinity | lamont: In a few hours, probably, time's running out to be slack. :P | 19:28 |
| lamont | infinity: I know exactly what you mean | 19:29 |
| lamont | infinity: also, I assert that squid3 change above is (1) trivial, (2) benign, and (3) in something that's disabled anyway. :/ | 19:30 |
| lamont | infinity: and (4) perfectly fine for post-beta | 19:31 |
| rbasak | infinity: some advice please? Do I need to remove mysql 5.6 build deps when an alternative (to the right) uses a non-version-specific one that 5.7 provides? | 19:33 |
| rbasak | (scroll back ~90 minutes) | 19:33 |
| infinity | rbasak: That's a no, for both deps and build-deps. If this is causing you any issues, we should just remove mysql-5.6 | 19:35 |
| infinity | rbasak: It's entirely valid to have alternate deps that don't exist in xenial (for easy backporting or whatever). | 19:35 |
| rbasak | infinity: OK, and to be clear, the order of alternatives doesn't matter? | 19:41 |
| infinity | rbasak: Not one bit, *if* one of them doesn't exist. | 19:42 |
| infinity | rbasak: Matter a lot when they both do. | 19:42 |
| infinity | s/Matter/Matters/ | 19:42 |
| rbasak | OK, thanks. | 19:42 |
| rbasak | I'd been focusing on the seeded rdeps first. | 19:42 |
| rbasak | There are still universe deps on the old libmysqlclient18 binary, so I need to lose those next. | 19:42 |
| rbasak | I presume I can't request removal of 5.6 until those are done. | 19:42 |
| rbasak | (most are clear; just unrelated FTBFS left) | 19:43 |
| infinity | rbasak: Yeah, no can remove until the transition is done. | 19:44 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!