| nacc | rbasak: smoser: after pushing the gitattributes change to allow for a source-change-less import, I was able to re-import php7.0, merge it and build it using `usd` only. | 00:31 |
|---|---|---|
| nacc | jgrimm: --^ | 00:32 |
| nacc | to mirror the upload, i just pushed up a corresponding upload/ tag; we'll see if the importer picks it up on the next import run (it should, it has in other cases) | 00:35 |
| nacc | jgrimm: also, we're in-sync with debian on tomcat8; i saw it was on the blueprint? | 00:41 |
| === salem_ is now known as _salem | ||
| ypwong | cyphermox, can bug 1561834 be closed since both tpm2 packages are already in xenial? | 04:06 |
| ubottu | bug 1561834 in Ubuntu "[FFE] [needs-packaging] tpm2-tss and tpm2-tools" [Wishlist,Confirmed] https://launchpad.net/bugs/1561834 | 04:06 |
| nacc | rbasak: would you have time to sync up again tmrw AM before the UOS session? | 05:14 |
| cpaelzer | cjwatson: thanks for the links to get my test env more like the LP infrastructure | 06:46 |
| cpaelzer | one question in general - what openstack flavors is the infrastructure using - as I start to assume it might be a race the number of cpu/memory might be important | 06:47 |
| cpaelzer | and good morning everybody sharing my TZ (good any other part of the day to everyone else) | 06:49 |
| pitti | Good morning | 07:14 |
| cpaelzer | hi pitti | 07:28 |
| pkern | Laney: So we managed to get bash into the sponsorship queue 1.5w ago and still nothing happened. I suppose the 3w old+ list is just too scary. | 07:49 |
| Mirv | LocutusOfBorg: hi! it seems in zesty-proposed cmake-extras is not possible to install (despite the newest uploads) because cmake < 3.7z requirement, and 3.7.0-1ubuntu1 is higher than 3.7z | 08:46 |
| pitti | LocutusOfBorg: eek -- 3.7.z then, I figure? | 08:53 |
| pitti | sorry for the bad piece of advice | 08:53 |
| jamesh | should probably be 3.8~ ? | 08:53 |
| pitti | better, just a lot more difficult to compute with a shell snippet in debian/rules :) | 08:54 |
| Laney | pkern: I had hoped that someone would pick it up, but luckily I'll be sponsoring this week at some point | 09:13 |
| juliank | dholbach: Can you add me to ~ubuntu-sponsors? - I currently occasionally sponsor some stuff mentioned on IRC, but let's formalize things a bit :) | 09:31 |
| juliank | Laney: pkern: That patch actually looks quite nice, if I had a trusty chroot, I'd sponsor it (and yes, I can set one up right now...) | 09:35 |
| Laney | juliank: thanks ;-) | 09:35 |
| rbasak | nacc: UOS sync> yes, though am also doing the MySQL session. ping when you're in? | 09:39 |
| juliank | whoa, seems that actually fit into my chroots partition. | 09:40 |
| dholbach | juliank, done | 09:47 |
| juliank | dholbach: thx | 10:00 |
| juliank | Laney, pkern: built, verified that it fixes the bug and uploaded it | 10:01 |
| juliank | Ooops, it misses a ":" after the LP in the changelog | 10:01 |
| juliank | Come on, one character, what world are we living in? | 10:02 |
| juliank | If someone rejects that, I'll upload again with a ":" in the changelog | 10:03 |
| LocutusOfBorg | pitti, yep indeed, thanks Mirv | 10:04 |
| Laney | juliank: you don't need to wait for the reject | 10:04 |
| LocutusOfBorg | thanks dholbach <3 virtual hug for you :) | 10:05 |
| juliank | Laney: Can I just replace the files in the queue? I mean, I don't want to create yet another changelog entry... | 10:05 |
| pitti | juliank: you can -- just fix the changelog, rebuild the source, reupload | 10:05 |
| pitti | juliank: i. e. same version number and all that | 10:05 |
| LocutusOfBorg | does anybody know how to git-git import in launchpad, to use a daily-build recipe for a particular package? | 10:05 |
| LocutusOfBorg | https://code.launchpad.net/~costamagnagianfranco/boinc-upstream/master | 10:05 |
| juliank | Ah cool | 10:05 |
| LocutusOfBorg | this is failing because signed commits/bzr missing feature | 10:05 |
| LocutusOfBorg | I would like to switch to git-git native stuff | 10:05 |
| pitti | juliank: (and rejected) | 10:06 |
| juliank | OK, re-uploaded with correct bug closure :) | 10:08 |
| juliank | That was easy. | 10:12 |
| juliank | I'm unsure about the coming apt 1.2.16 SRU - I cherry-picked commits making the time parser only accept UTC values for Valid-Until - I don't exactly remember why, but I think the other patches fixing the other locale bugs depend on them. Does that sound fine for xenial, or do we think it's too risky (no one seems to have complained about that in yakkety so far - we have that in 1.3 since June) | 10:22 |
| * dholbach hgus LocutusOfBorg back :) | 10:26 | |
| juliank | Yep, that was the reason. | 10:27 |
| juliank | So, I can either do some changes that were never tested elsewhere for xenial to keep things minimal, or stop accepting Release files that specify "Valid-Until" in a time zone other than UTC (we never respected the timezone specified) | 10:28 |
| * juliank prefers the well-tried commits | 10:29 | |
| pkern | juliank: Thanks! :) | 10:39 |
| juliank | pkern: (often) happy to help :) | 10:41 |
| * juliank would say always, but sometimes he really has more important things to do :/ | 10:42 | |
| === JanC is now known as Guest44518 | ||
| === JanC_ is now known as JanC | ||
| LocutusOfBorg | Mirv, seems fixed in proposed :) please confirm | 10:51 |
| === saurik_ is now known as saurik | ||
| juliank | We don't really have concrete test cases for #1592817 and #1611010 - I think the SRU in xenial-proposed (1.2.16) fixes the issues, but testing them? So many variables to account for. | 10:54 |
| juliank | bug 1592817 and bug 1611010 | 11:00 |
| ubottu | bug 1592817 in apt (Ubuntu Xenial) "gdebi-gtk crashed with ValueError in update_interface(): could not convert string to float: '0,0000'" [Undecided,In progress] https://launchpad.net/bugs/1592817 | 11:00 |
| ubottu | bug 1611010 in apt (Ubuntu Xenial) "yakkety desktop - non-english installation crashes with /plugininstall.py: ValueError: invalid literal for int() with base 10: ''" [Critical,In progress] https://launchpad.net/bugs/1611010 | 11:00 |
| === _salem is now known as salem_ | ||
| Mirv | LocutusOfBorg: not yet in repos it seems but yes that should do it, thanks! :) | 11:20 |
| Mirv | oh, I'm using a mirror | 11:20 |
| Mirv | switching to main | 11:20 |
| Mirv | LocutusOfBorg: yes, so confirming fixed! | 11:21 |
| philroche | xnox: Odd_Bloke pointed me in your direction to see what your thoughts were on an issue we are having trying to unmount after running apt-key or apt-add-repository within a chroot. See https://gist.github.com/philroche/0fdeb0c31887bbf7300ef64e20e9b6db on how to reproduce. This is blocking us in creating some custom Yakkety cloud images. | 11:41 |
| xnox | philroche, run away processes from gnupg2. But why are you doing this? | 11:42 |
| xnox | philroche, export the key as a file, and drop it as a file into /etc/apt/trusted.gpg.d/<your-name>.gpg | 11:43 |
| xnox | you really should not be hitting the network to retrieve the keys | 11:44 |
| philroche | We want to be able to add a PPA within a chroot to produce an image with a package from that PPA installed. | 11:44 |
| xnox | but don't run apt-key inside the chroot to do that. | 11:44 |
| xnox | export the key into a file, commit it to your repository or what not, no need to call chroot, no need to copy resolve.conf | 11:45 |
| philroche | xnox: OK. Initially we were only using apt-add-repository but I presume this calls apt-key | 11:45 |
| xnox | simply $ cp my-ppa.gpg squashfs-root/etc/apt/trusted.gpg.d/ | 11:46 |
| xnox | ditto the lines you want for the /etc/apt/sources.list.d/ | 11:46 |
| philroche | xnox: excellent. Thank you. I will try this | 11:47 |
| xnox | yes add-apt-repository does call apt-key and it does leave run-away processes. but you can do everything statically by just copying the exported key in place, & the text-file with deb http.... lines | 11:47 |
| cpaelzer | cjwatson: I wanted to thank you - with your hints on how I get my build env closer to LP I was finally able to reproduce the issue | 11:47 |
| cjwatson | cpaelzer: Not completely certain, but I believe that amd64 and i386 are on 4 vCPUs, 4GiB RAM, 4GiB swap, 60GiB disk, while arm64, armhf, and ppc64el are on the same but with 8GiB RAM. powerpc and s390x aren't using openstack yet. | 12:02 |
| cjwatson | cpaelzer: np :) | 12:02 |
| cjwatson | LocutusOfBorg: I'm at the production-testing stage of git-to-git imports, so nearly done, but they aren't yet enabled for everyone to create. Probably later this week. | 12:03 |
| doko | xnox: looking at https://bugs.launchpad.net/ubuntu/+source/libuv1/+bug/1641628, missing a subscriber. should be the same as for cmake, but this is kubuntu-bugs. any suggestion? | 12:17 |
| ubottu | Launchpad bug 1641628 in libuv1 (Ubuntu) " [MIR] libuv1" [Undecided,New] | 12:17 |
| xnox | doko, why does it need a MIR? if it's only used in cmake-extras, it should only ever be a build-depends, no? | 12:18 |
| * xnox checks that assumption | 12:19 | |
| xnox | $ reverse-depends cmake-extras | 12:19 |
| xnox | No reverse dependencies found | 12:19 |
| xnox | oh cmake itself...?! | 12:20 |
| doko | xnox: yes | 12:20 |
| doko | so currently uninstallable in -proposed | 12:20 |
| xnox | $ reverse-depends -c main cmake | 12:20 |
| xnox | No reverse dependencies found | 12:20 |
| xnox | how is cmake seeded? | 12:20 |
| * xnox guess we probably do want cmake in main... then again we don't have to. | 12:21 | |
| xnox | i'd rather push cmake to universe =) | 12:21 |
| xnox | somehow i see cmake-doc seeded into supported. | 12:21 |
| doko | well, pushing it into universe doesn't mean we don't have to maintain it ... | 12:22 |
| xnox | sure. but it means we don't have to security support it on end-user machines | 12:23 |
| LocutusOfBorg | thanks cjwatson | 12:23 |
| * xnox does want to know how come cmake is in main though | 12:23 | |
| xnox | supported-development-common: * cmake | 12:24 |
| xnox | that's how. | 12:24 |
| pitti | xnox: http://people.canonical.com/~ubuntu-archive/germinate-output/ubuntu.zesty/all | 12:24 |
| pitti | (yes, that shows that it's just seeded) | 12:25 |
| doko | well, it's used as a b-d for a lot of the phone package, so we should keep it seeded | 12:27 |
| xnox | doko, looks like cmake has embedded copy of libuv that one can use; or one can use a system one. It is only required for the cmake server mode, which unfortunately is not a separate binary. | 12:31 |
| xnox | but one can compile cmake without server mode enabled, and thus without libuv internal or external dependency | 12:31 |
| xnox | https://cmake.org/cmake/help/v3.7/manual/cmake-server.7.html | 12:31 |
| xnox | yeah, make bootstraps harder, as it's one more thing to build. | 12:31 |
| xnox | potentially. | 12:32 |
| xnox | but that too is work. | 12:32 |
| xnox | subscribe foundations-bugs and be done with it? | 12:33 |
| xnox | bdmurray, do we want to take on libuv? | 12:33 |
| doko | xnox: yes, that was my suggestion. and maybe foundations should subscribe to cmake too, because you're the expert? | 12:38 |
| xnox | haha | 12:39 |
| doko | one advantage of having a separate library is that the testsuite runs | 12:46 |
| doko | cpaelzer: libvirt-python is dep-wait on a newer libvirt. do you intend to update / merge this version? | 12:52 |
| doko | also ftbfs on amd64 and i386 | 12:53 |
| doko | tvoss: location-service and mir ftbfs in zesty-proposed | 12:53 |
| doko | same with thumbnailer | 12:54 |
| tvoss | Ack and thx | 12:58 |
| cpaelzer | doko: hi, I discussed with smb just yesterday to merge a newer libvirt this cycle - although that will not be like tomorrow | 13:00 |
| doko | ok | 13:00 |
| * LocutusOfBorg smells libuv1 mir | 13:05 | |
| mdeslaur | @pilot in | 13:05 |
| === udevbot changed the topic of #ubuntu-devel to: Yakkety Yak (16.10) Released | Archive: open | Devel of Ubuntu (not support or app devel) | build failures: http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of precise-yakkety | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | Patch Pilots: mdeslaur | ||
| doko | seb128, willcooke, Laney: please subscribe ubuntu-desktop to emacs25 (emacs24 getting demoted) | 13:08 |
| Laney | ok | 13:10 |
| LocutusOfBorg | thanks doko :) for both | 13:10 |
| cpaelzer | doko: if you meant the current libvirt FTBFS that I'm on atm btw - althou reproducibility is a nightmare so far | 13:16 |
| doko | well, isn't libvirt a nightmare on its own? | 13:16 |
| * cpaelzer wonders why he seems to attract work on packages that people say things like that about | 13:19 | |
| === chrisccoulson_ is now known as chrisccoulson | ||
| seb128 | doko, Laney, why do we maintain emacs? | 13:39 |
| Laney | seb128: I would guess that's always been there, but if you want to figure it out and get it demoted then feel free | 13:42 |
| Laney | It's more "maintain" than maintain, at least for our team | 13:42 |
| seb128 | right | 13:42 |
| seb128 | just feels weird | 13:42 |
| pitti | seb128, Laney "usb" seed → gettext → gettext-el → emacs-defaults → emacs → emacs24 (see http://people.canonical.com/~ubuntu-archive/germinate-output/ubuntu.zesty/all) | 13:49 |
| seb128 | pitti, thanks | 13:50 |
| pitti | oh, gettext is also being pulled in by more bits (and I think we do want/need to keep that) | 13:50 |
| Laney | pitti: Right (I know how to chase that down) - the question is why is it the desktop team rather than any other one | 13:50 |
| seb128 | wonder if that's something that could be simplified, at the same time can't be bothered to spend work on that | 13:50 |
| Laney | wee, glib went in | 13:51 |
| pitti | seb128: so we could unseed gettext-el | 13:51 |
| pitti | and emacs-goodies-el from supported-development-desktop seed | 13:52 |
| pitti | (I'm not saying we want to unsupport emacs -- probably we do want to support it) | 13:52 |
| seb128 | pitti, right, let's keep things as their are, easier/less work, it's not like it was costing us much maintainance work, I was just a bit suprised to see emacs in main/desktop maintained | 14:02 |
| Laney | don't peek into the supported seeds ;-) | 14:04 |
| * Laney eek | 14:04 | |
| seb128 | lol | 14:08 |
| doko | seb128, Laney, pitti: also seeded for the desktop | 14:13 |
| doko | maybe because there is no real emacs-gtk package | 14:13 |
| === BrAsS_mOnKeY is now known as g2 | ||
| barry | jsalisbury: i think LP:# 1627198 might be back for zesty | 15:16 |
| barry | LP: #1627198 | 15:16 |
| ubottu | Launchpad bug 1627198 in linux (Ubuntu Yakkety) "4.8.0 kernels do not complete boot process on VM" [Critical,Fix released] https://launchpad.net/bugs/1627198 | 15:16 |
| nacc | rbasak: ack, i should be fully available at the hour | 15:30 |
| smoser | nacc, 'git show do-no-push' ? | 15:46 |
| smoser | second question... | 15:49 |
| smoser | i just imported cluod-initramfs-tools, and it seems like i have double namespacing on the pristine-tar branches | 15:49 |
| smoser | http://paste.ubuntu.com/23480958/ | 15:50 |
| bdmurray | xnox: What was your question? | 15:53 |
| xnox | bdmurray, please subscribe libuv to foundations-bugs such that we are stuck maintaining it if it goes rougue, because cmake picked up an optional feature that depends on libuv | 15:54 |
| xnox | and cmake is important, supposedly | 15:55 |
| jsalisbury | barry, ack, looks like seth is taking a look | 15:56 |
| barry | jsalisbury: thanks! | 15:56 |
| barry | i have things set up right now to test new kernels without too much pain | 15:57 |
| nacc | smoser: ignore do-not-push, it's an artifact of gbp | 15:57 |
| nacc | smoser: hence the name | 15:57 |
| nacc | smoser: it only exists on the importer system, it will not be pushed to LP, which is the bit that matters | 15:57 |
| smoser | right. ok. | 15:58 |
| nacc | smoser: yes, pristine-tar is namespaced; in theory, ubuntu and debian could be using different orig tarballs | 15:58 |
| nacc | smoser: it could be smarter about it, but that was the easier route | 15:58 |
| nacc | smoser: so to use pristine-tar, right now, you have to do a `git branch -M` | 15:58 |
| nacc | smoser: iirc | 15:59 |
| bdmurray | xnox: done | 15:59 |
| smoser | nacc, that wasnt my question | 15:59 |
| smoser | look at the paste | 15:59 |
| smoser | importer/importer/debian/dsc | 16:00 |
| nacc | yes | 16:00 |
| smoser | importer/importer/debian/pristine-tar | 16:00 |
| nacc | importer/ specific branches are nested | 16:00 |
| nacc | so when they get pushed to LP they are in importer/ | 16:00 |
| nacc | this is why i'm convinced using the imported tree directly is sort of wrong | 16:00 |
| nacc | import, push, use `usd clone` | 16:00 |
| nacc | it will look 'correct' | 16:00 |
| smoser | no. | 16:00 |
| nacc | or import and ignore the leading 'importer/' | 16:00 |
| smoser | i did that. | 16:01 |
| nacc | oh right, it won't matter | 16:01 |
| nacc | because importer is the remote then | 16:01 |
| nacc | so still, ignore 'importer', that's just a namespace, right? (per remote) | 16:01 |
| nacc | the first importer | 16:01 |
| nacc | the second 'dir' is the purpose, sort of -- 'importer' is for importer-internal branches, 'ubuntu' for Ubuntu series tracking, 'debian' for Debian series tracking | 16:02 |
| smoser | well, "just a namespace" .... "just a name" .... wherefore art though romeo. | 16:02 |
| nacc | having the pristine-tar and dsc branches a level up meant having to special-case them everywhere | 16:02 |
| smoser | yeah, i can see that. | 16:03 |
| smoser | but this just looks wrong. | 16:03 |
| nacc | why? | 16:03 |
| nacc | it's just a naming choice | 16:03 |
| nacc | i guess we could have flipped those to be pristine-tar/debian and pristine-tar/ubuntu | 16:03 |
| nacc | would you prefer that? | 16:03 |
| nacc | and dsc/debian, dsc/ubuntu | 16:03 |
| smoser | it'd look less wrong with importer/pristine-tar/debian | 16:04 |
| smoser | yeah, that swhat i was going to suggest. | 16:04 |
| smoser | it would seem less "wrong" then. | 16:04 |
| smoser | or maybe just picking something other than 'importer' . maybe 'dist' or 'pristine' or something | 16:05 |
| nacc | what is 'wrong' about it? you not liking it doesn't make it 'wrong' :) | 16:05 |
| smoser | i dont know. | 16:05 |
| smoser | it looks like an error | 16:05 |
| smoser | xnox, fwiw, you could test petiboot itself without ppc64 nv | 16:15 |
| smoser | as it just builds an initramfs | 16:15 |
| smoser | kvm -kernel ... -initrd ... | 16:15 |
| smoser | the difference really then woudl be the version and features of the loader kernel that the ppc64el firmware has, and the version of petitboot that is in it | 16:16 |
| xnox | horum. | 16:16 |
| xnox | smoser, shall i just enable it for ppc64el and wait for bug reports?! =) | 16:16 |
| === BrAsS_mOnKeY is now known as g2 | ||
| mdeslaur | @pilot out | 16:26 |
| === udevbot changed the topic of #ubuntu-devel to: Yakkety Yak (16.10) Released | Archive: open | Devel of Ubuntu (not support or app devel) | build failures: http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of precise-yakkety | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | Patch Pilots: | ||
| === JanC_ is now known as JanC | ||
| Diziet | Is there an IRC channel where I can get help with summit ? I want to remotely attend a session and 1. there is something wrong with my account in summit and 2. I would like to test my setup beforehand. | 16:34 |
| cjwatson | dholbach: ^- | 16:36 |
| Diziet | cjwatson: Hi, and thanks. | 16:36 |
| dholbach | mhall119, popey ^ can you maybe help? I'm in a session right now | 16:36 |
| cjwatson | (Also it possibly depends on exactly what's wrong with your account in summit, e.g. it might actually be an SSO issue) | 16:36 |
| cjwatson | I won't be able to attend the session in question, unfortunately - prior commitment | 16:37 |
| Diziet | cjwatson: summit -> log in -> "personal data request" from Ubuntu One -> "yes" -> The username (ijackson) with which you tried to log in is already in use for a different account | 16:37 |
| Diziet | Very likely the other account is another copy of me from a time when summit and launchpad had different account databases. | 16:37 |
| cjwatson | Yeah, I was just about to say the same | 16:38 |
| mhall119 | Diziet: watching or running a session? | 16:40 |
| Diziet | I will want to be watching it. | 16:40 |
| mhall119 | Diziet: you don't need to be logged in for that | 16:41 |
| Diziet | And ideally, if that's what can happen, have my video appear in the conf room. | 16:41 |
| mhall119 | Diziet: but it sounds like your OpenID id has changed in SSO at some point | 16:41 |
| Diziet | I might want to scribble in the pad. | 16:41 |
| Diziet | I don't know if the system allows remote participants to share their video. | 16:42 |
| mhall119 | Diziet: if you want to be on the hangout, ask the host for the hangout URL | 16:42 |
| Diziet | OK. So I may need to create a google account then. | 16:42 |
| mhall119 | otherwise the video is just a youtube broadcast, anybody can see it | 16:42 |
| mhall119 | Diziet: to be on the hangout, yes, you need a google account | 16:43 |
| Diziet | And presumably I can test the hangouts bit separately. | 16:43 |
| mhall119 | separately from summit.ubuntu.com yes | 16:43 |
| Diziet | Do I need to be logged in to edit the pad ? | 16:43 |
| Diziet | Right. | 16:43 |
| cjwatson | You need to be logged in via SSO to edit the pad | 16:43 |
| mhall119 | yes, but you need to login to pad.ubuntu.com not summit.ubuntu.com | 16:43 |
| Diziet | Oh my account is probably not borked there. | 16:44 |
| mhall119 | there's a good chance of that :) | 16:44 |
| Diziet | PS wot no https link from summit to pad ? | 16:44 |
| Diziet | Also ssl cert error on https://pad | 16:44 |
| cjwatson | Yeah, it's probably not actually necessary to unbreak summit.ubuntu.com login for any of this - that's only needed for registering attendance I think, which isn't really required | 16:45 |
| Diziet | I tried following the pad link for the session in question and it says | 16:45 |
| Diziet | Either you have not been granted access to this resource or your entitlement has timed out. Please try again. | 16:45 |
| mhall119 | Diziet: file a bug on lp:summit for us to fix the link | 16:45 |
| Diziet | The https url is 404 | 16:46 |
| mhall119 | Diziet: you need to join the lp:~ubuntu-etherpad team to edit the pad | 16:46 |
| mhall119 | hmm, might not have https configured for pad.ubuntu.com | 16:46 |
| cjwatson | (This is because otherwise it gets ridiculous amounts of predictable ASCII-art body parts scribbled all over it by vandals) | 16:47 |
| Diziet | cjwatson: Yes. | 16:47 |
| * mhall119 blames phoronix | 16:47 | |
| Diziet | OK now I am in that team but the error message is the same. | 16:48 |
| Diziet | | You have successfully joined Users of the Ubuntu Etherpad instance. | 16:48 |
| Diziet | Funny that it didn't want me to get any approval. | 16:48 |
| Diziet | Oh I'm in "Pending approval" | 16:48 |
| Diziet | That's rather a misleading headline. | 16:48 |
| cjwatson | yes it is, I will fix that | 16:48 |
| Diziet | Well I'm glad I have over an hour to wrestle all this. | 16:49 |
| popey | approved | 16:49 |
| cjwatson | Huh, except the code says it should be "Your request to join ${team} is awaiting approval." | 16:49 |
| cjwatson | you may need to log out of pad and back in | 16:49 |
| cjwatson | since it's probably remembered your team memberships from the openid exchange | 16:49 |
| cjwatson | message> ah, I see, this is specifically for delegated teams | 16:50 |
| Diziet | Can I navigate away from this page with the misleading message or do you want it for something ? | 16:50 |
| mhall119 | Diziet: what's your LP nickname? | 16:50 |
| Diziet | ijackson | 16:50 |
| cjwatson | go ahead and navigate away | 16:50 |
| mhall119 | I've approved your membership in the team | 16:50 |
| mhall119 | try going to pad.ubuntu.com again | 16:51 |
| Diziet | I can't create a google account because my mobile phone is at home. | 16:52 |
| Diziet | FFSA | 16:52 |
| Diziet | I guess I can probably change this number later. | 16:53 |
| Diziet | popey: Thanks for the approval | 16:54 |
| popey | np | 16:54 |
| Diziet | Yay now I have etherpad | 16:54 |
| popey | huzzah | 16:54 |
| Diziet | Should I file a bug about my summit account ? It would be nice to fix it for next time even if I don't need it now. | 16:55 |
| mhall119 | Diziet: file an RT, this happens when SSO and Launchpad disagree on what your OpenID id is | 16:55 |
| Diziet | I don't suppose you could point me to the RT instructions ? Email address, magic subject thingy, etc. | 16:57 |
| mhall119 | email rt@ubuntu.com tell them the problem you have, give them your LP name and SSO email so they can check it out | 16:57 |
| Diziet | https://help.ubuntu.com/community/RT <- clearly not what I wanted :-) | 16:57 |
| Diziet | Ta | 16:57 |
| cjwatson | SSO and Launchpad> hm, maybe I can help with that then | 16:58 |
| Diziet | I have sent a mail to RT | 17:01 |
| Diziet | I assume an ack from RT will be forthcoming when it has got through my greylist. | 17:01 |
| smoser | pitti, around ? | 17:21 |
| smoser | wondering if i can get some time to talk to you about a cloud-init sru with its systemd changes. | 17:22 |
| slangasek | smoser: hi there | 17:30 |
| smoser | hey. | 17:32 |
| smoser | so, rharper and i are currently under the belief that the systemd changes do not regress anything on xenial. systemd-networkd and cloud-init remain tricky as discussed in bug 1636912 | 17:34 |
| ubottu | bug 1636912 in systemd (Ubuntu Xenial) "systemd-networkd runs too late for cloud-init.service (net)" [High,Triaged] https://launchpad.net/bugs/1636912 | 17:34 |
| smoser | but that isn't a wide spread or supported use (cloud-init + systemd-networkd) | 17:35 |
| rharper | specifically, xenial + cloud-init in the cloud-images still use ifupdown; | 17:35 |
| slangasek | smoser: "the systemd changes" being the ones in the previous submitted SRU? | 17:35 |
| smoser | slangasek, well, current zesty | 17:37 |
| smoser | http://paste.ubuntu.com/23481409/ is the combined result | 17:37 |
| rharper | smoser: bbiab, afk for now | 17:37 |
| slangasek | smoser: ok, so it includes the changes as discussed on the bugs? | 17:38 |
| slangasek | specifically, the Before=basic.target fix | 17:38 |
| smoser | yes. | 17:38 |
| slangasek | ok | 17:39 |
| slangasek | then I'm +1 for this :) | 17:39 |
| smoser | slangasek, ok.. so i'm putting together some more info at http://pad.ubuntu.com/tMdgYGEvgL | 17:40 |
| smoser | describing all of the changes for systemd. | 17:40 |
| slangasek | smoser: well, it should be possible to discern all relevant information from the changelog, so that the context isn't lost later when we can't find that pad url ;) | 17:42 |
| nacc | rbasak: do you have permission to set the hangout URL? | 17:42 |
| smoser | slangasek, i dont know that that is true... | 17:43 |
| smoser | changelog entries are supposed to be terse | 17:43 |
| rbasak | nacc: no. I guess I'll need to set it up and send you the URLs? | 17:43 |
| smoser | i'm willing to put text wherever you want it (and it exists in upstream git commits) but i dont think you really want it in the debian/changelog | 17:43 |
| nacc | rbasak: yeah, i guess so | 17:43 |
| smoser | nacc, rbasak i'll sit in the hangout there if you'd like | 17:44 |
| smoser | or not if you'd like that too :) | 17:44 |
| slangasek | smoser: well, for an SRU I want the changelog to explain each change and why (where "why" may just be a pointer to a bug that has details) | 17:44 |
| rbasak | smoser: please | 17:44 |
| smoser | slangasek, well, i'll try to get all in such a state and upload. | 17:45 |
| rbasak | smoser, nacc: https://hangouts.google.com/hangouts/_/ytl/yq07F04I9D_f6YnWIxoB7HycyY363CimE_hAfjF8Ptc=?hl=en_GB&authuser=0 | 17:47 |
| rbasak | brb | 17:47 |
| rbasak | nacc: http://youtu.be/TuSe0eBjMxE | 17:49 |
| Odd_Bloke | slangasek: Could you copy the yakkety google-cloud-sdk in partner forward to zesty, please? | 17:50 |
| cjwatson | https://code.launchpad.net/~cjwatson/launchpad/join-delegated-team-message/+merge/310908 (ignoring the terrible ancient doctests) should fix the misleading messages that Diziet saw. | 17:53 |
| slangasek | rbasak, nacc: would you like anyone from Foundations on that HO? e.g. barry or myself | 17:55 |
| nacc | slangasek: it would probably be good to have some representation, presuming we can get it working :) | 17:55 |
| barry | i'm happy to hangout | 17:55 |
| slangasek | barry: https://hangouts.google.com/hangouts/_/ytl/FfvzFcwTgW8qXQc2vOX5pYOQS51NOMYubPQfO1XGCfU=?hl=en_US&authuser=0 ; #ubuntu-uos-community | 17:59 |
| smoser | shoot. | 17:59 |
| barry | slangasek: it says i'm not authorized to start the call | 18:00 |
| rbasak | smoser: ^ working for you? | 18:00 |
| slangasek | barry: wiggle the 'authuser' setting? | 18:00 |
| smoser | pitti, https://code.launchpad.net/~smoser/cloud-init/+git/cloud-init/+merge/310547 cloud-init-local.service still has 'Before=basic.target' i wonder if that is right or if that should also be 'Before=sysinit.target' | 18:00 |
| barry | slangasek: yay! i'm the first one there | 18:01 |
| slangasek | barry: you're really not ;) | 18:01 |
| barry | it looks pretty lonely ;) | 18:01 |
| slangasek | barry: 8 of us in the HO | 18:01 |
| rbasak | Pad link: http://pad.ubuntu.com/uos-1611-git-based-merge-workflow | 18:02 |
| barry | slangasek: wtf? oh well, irc-only i guess | 18:03 |
| bdmurray | What does marked_keep with python-apt mean? https://apt.alioth.debian.org/python-apt-doc/library/apt.package.html | 19:11 |
| bdmurray | I ask as the release upgrader is showing some strange behavior. An upgrade from X to Y shows the following. | 19:13 |
| bdmurray | ipdb> pkg.name, pkg.marked_install, pkg.marked_upgrade, pkg.marked_keep, pkg.is_installed | 19:14 |
| bdmurray | ('linux-image-4.8.0-22-generic', False, False, True, False) | 19:14 |
| sarnold | bdmurray: neither 'hold' nor 'held' appear in the doc, I wonder if "keep" is their spelling of "hold" | 19:14 |
| bdmurray | sarnold: I'd think either of those imply is_installed though. | 19:15 |
| sarnold | bdmurray: huh. good point. | 19:15 |
| bdmurray | So I don't see why its marked_keep and nothing else. | 19:16 |
| juliank | bdmurray: That's a very good question | 19:30 |
| juliank | I'm not sure if it means hold or if it means "marked for keep by the solver" | 19:30 |
| nacc | smoser: fyi, dgit does have the same behavior (e.g., 'dgit/dgit/sid') | 19:31 |
| smoser | ) | 19:31 |
| smoser | :) | 19:31 |
| juliank | bdmurray: As far as I can tell, one of the solver thingies uses that to mark packages it wants to keep | 19:31 |
| juliank | maybe because it can't be upgraded? | 19:32 |
| doko | juliank: I noticed that apt show doesn't show the component / file location any more. is this intended? | 19:32 |
| doko | compared to apt-cache show | 19:32 |
| juliank | doko: Yeah, I think so. It's kind of pointless in a high-level user-friendly view. | 19:33 |
| juliank | s/high-/higher-/ | 19:33 |
| juliank | bdmurray: But really, if it uses the upgrade function thing, then that also marks hold back packages as keep first | 19:34 |
| doko | juliank: lacking some information doesn't sound user friendly ... | 19:34 |
| juliank | doko: Well, for the normal user, it's arguably more useful to know which source the file is from (APT-Sources), rather than the path inside that source | 19:34 |
| juliank | It's not like they navigate to that in the web browser or download via curl | 19:35 |
| juliank | But oh well, I'll ask the others if you want Filename as well | 19:35 |
| sarnold | heh, I sometimes do use apt-cache show to find the url to download via wget, heh | 19:35 |
| doko | ta | 19:35 |
| Unit193 | juliank: Howdy. | 19:36 |
| juliank | Alright, it's Unit193 again :) | 19:36 |
| bdmurray | juliank: okay, thanks for the information | 19:37 |
| juliank | bdmurray: The reason why the docs are so unclear is that I did not really know a lot back when I wrote them... | 19:38 |
| pitti | smoser: yes, I answered in https://code.launchpad.net/~smoser/cloud-init/+git/cloud-init/+merge/310919 | 19:59 |
| smoser | pitti, thanks. | 19:59 |
| smoser | pitti, but DefaultDependencies=no doesn't say Before=basic.target, it just doesn't say After=basic.target | 19:59 |
| smoser | right ? | 19:59 |
| pitti | smoser: correct; it's not equivalent, just says "I want to run this early"; the Before=sysinit means "I have to run it early", but AFAIK you really only want to run it before c-i, so I find it redundant | 20:02 |
| pitti | smoser: but, it's just a stylistic question, so go ahead :) | 20:02 |
| smoser | yeah | 20:05 |
| smoser | slangasek, http://paste.ubuntu.com/23482240/ | 20:14 |
| smoser | does that debian/changelog look acceptable to you? | 20:14 |
| pitti | smoser: "+ add Before=basic.target." → I thought you wanted to move that to sysinit.target? | 20:15 |
| smoser | pitti, well, i will, but what is in zesty now is Before=basic.target | 20:16 |
| smoser | and i'd rather copy what is in zesty since its innocent | 20:16 |
| smoser | so, its there for now. | 20:16 |
| pitti | smoser: oh, that's for xenial, I see | 20:16 |
| slangasek | smoser: MAAS: improve the debugging tool - is there a bug for this? | 20:16 |
| smoser | no. its not code that is executed at runtime | 20:17 |
| smoser | but i can open a bug if youw ant me to. | 20:17 |
| smoser | its only run if someone runs: python3 -m cloudinit.sources.DataSourceMAAS | 20:17 |
| pitti | smoser: I didn't check, but please don't land the changes in bug 1636912 yet -- it's not actually that easy to run networkd before dbus.service | 20:17 |
| ubottu | bug 1636912 in systemd (Ubuntu Xenial) "systemd-networkd runs too late for cloud-init.service (net)" [High,Triaged] https://launchpad.net/bugs/1636912 | 20:17 |
| slangasek | smoser: ok, I can ignore that then | 20:18 |
| smoser | gah. pitti what changes do you mean ? | 20:18 |
| smoser | i'm not going to change systemd-networkd | 20:18 |
| pitti | smoser: I mean right now you can't run anything After=systemd-networkd.service and Before=sysinit.target | 20:19 |
| smoser | but i believe the cloud-init changes are sufficient to mark ti as fixed. or i can change it to not fixed and drop that bug mention if you'd rather. | 20:19 |
| slangasek | smoser: ok lgtm | 20:19 |
| slangasek | (the changelog) | 20:19 |
| smoser | pitti, now i'm really confused. | 20:20 |
| smoser | you acked that https://code.launchpad.net/~smoser/cloud-init/+git/cloud-init/+merge/310547 | 20:20 |
| smoser | unless i misunderstood something | 20:20 |
| pitti | smoser: yes, that c-i side looks good, but it assumes the networkd side of that bug | 20:21 |
| pitti | smoser: (and back then I thought it was a simple thing to do) | 20:22 |
| rharper | pitti: it's only an issue of there's a netplan yaml on the system | 20:23 |
| pitti | correct (or if networkd got enabled by the admin) | 20:23 |
| rharper | otherwise netplan generator won't trigger bringing in networkd as a wants | 20:23 |
| pitti | then you'll get dep cycles | 20:24 |
| smoser | ok, thats what i thought. got cnfused for am inute. | 20:24 |
| rharper | smoser: so it feels like cloud-init + networkd is blocked until the dbus.service issue is resolved; | 20:26 |
| rharper | pitti: on that issue (networkd not getting dbus control); would a simple restart of networkd after dbus.service is up be OK ; since networkd doesn't touch/modify up'ed interfaces; would that restore dbus control and not bother the current network config ? | 20:27 |
| pitti | rharper: it will attempt DHCP though | 20:27 |
| rharper | really? | 20:27 |
| rharper | that seems at odds with the 'don't bother already up interfaces' that I read about networkd | 20:27 |
| rharper | that's due to networkd being the client itself | 20:28 |
| rharper | unfortunate | 20:28 |
| pitti | well, it will add new (manual) addresses and request DHCP if the config asks for it; it will not *remove* existing addresses or down interfaces | 20:28 |
| rharper | certainly it shouldn't bother to run DHCP on an up'ed interface though ? | 20:28 |
| pitti | rharper: well, it puts the lease into /run, maybe it won't reattempt | 20:28 |
| rharper | that's worth testing | 20:29 |
| pitti | (I was testing all day with failed DHCP, and restart does reattempt that) | 20:29 |
| rharper | that's unsuccessful DHCP in the first place though | 20:29 |
| pitti | right | 20:29 |
| rharper | vs. successful attempts | 20:29 |
| * rharper plays with restart networkd | 20:29 | |
| rharper | how do you test for the dbus control of networkd ? | 20:29 |
| pitti | rharper: d-feet, or "busctl introspect org.freedesktop.network1 /org/freedesktop/network1" or something | 20:30 |
| rharper | cool | 20:31 |
| pitti | rharper: current idea is to teach it to re-attempt D-Bus connection and hostname setting when it gets a SIGUSR | 20:31 |
| rharper | OK, and if that comes through into zesty than SRU to xenial, we could land the changes | 20:32 |
| rharper | and there's no way for dbus.service to SD_NOTIFY that it's now up and consumers wanting dbus could listen to SD_NOTIFY events ? probably because that's implemented on dbus, right ? | 20:33 |
| pitti | rharper: no, that's a simple Unix socket, I think | 20:34 |
| pitti | rharper: but regardless of whether it's SIGUSR1 or sd_notify -- the action is the interesting part (less important to which signal handler you hook it into) | 20:34 |
| rharper | yeah | 20:34 |
| rharper | pitti: it appears from the log, that networkd did re-DHCP | 20:35 |
| rharper | =( | 20:35 |
| rharper | brb | 20:35 |
| smoser | pitti, the re-attempt on SIGUSR is acceptable to upstream? | 20:41 |
| pitti | I didn't discuss it yet | 20:41 |
| pitti | that was in #debian-systemd with mbiebl | 20:41 |
| === salem_ is now known as _salem | ||
| rharper | https://github.com/systemd/systemd/issues/1546 | 20:55 |
| rharper | it appears that it does DHCP again, but if that's right, it shouldn't break connection if the lease is the same; but I suppose this is only relevant w.r.t the timeframe for SIGUSR being acceptable and SRUable vs. a restart in the short term | 20:56 |
| pitti | rharper: right; triggering a restart seems more brittle, but in the restricted context of cloud-init and netplan it may be acceptable | 20:57 |
| rharper | pitti: I ran busctl, but I don't have what it *should* look like vs. what it does when networkd doesn't get dbus connection ; | 20:58 |
| pitti | rharper: oh, right -- it actually gets dbus activated, so if it's not running, it will be once you try and talk to it via dbus | 21:00 |
| pitti | rharper: if it's not on teh bus, you should get an error like "Unknown object" | 21:00 |
| rharper | pitti: interesting | 21:04 |
| rharper | pitti: hrm, let me confirm that in my ubuntu-core with cloud-init and networkd that I'm running networkd without After=dbus.service; if so, then it appears to "Just Work (tm)" if the busctl output is a proper test | 21:05 |
| rharper | ah, I'm not; | 21:06 |
| * rharper tries that version | 21:06 | |
| pitti | $ busctl get-property org.freedesktop.network1 /org/freedesktop/network1 org.freedesktop.network1.Manager OperationalState | 21:06 |
| pitti | s "routable" | 21:06 |
| pitti | if something like that works, you're good | 21:06 |
| rharper | yeah, that's what I got but I need to test with the removal .. I suspect it fails as you say | 21:06 |
| pitti | (in case you don't know, it has full command line completion) | 21:06 |
| pitti | and even the completion should fail if it's not running | 21:07 |
| rharper | ok | 21:07 |
| rharper | smoser: so, for the SRU, then we need to backout the After=systemd-networkd-wait-online.service then (and I suppose fix up Yakkety too) until we get a networkd dbus service solution; | 21:07 |
| rharper | does that sound right ? | 21:07 |
| smoser | reading | 21:08 |
| smoser | rharper, so it would seem you mean we should back out everywhere. | 21:11 |
| smoser | right ? | 21:11 |
| rharper | yes | 21:11 |
| smoser | with the justification that an unresolvable boot sequence is worse than cloud-init.service running to early | 21:12 |
| rharper | I really doubt anyone is using it that way; but the regression potential is real; but it does seem limited to dbus control of networkd | 21:12 |
| smoser | the system is busted in either case. | 21:12 |
| rharper | smoser: right, there's a good change that cloud-init gets kicked out ( | 21:12 |
| smoser | either you dont get networking, or you dont get cloud-init.service. | 21:13 |
| smoser | either way, you're sol on first boot for sure | 21:13 |
| rharper | if you've modified your image such that it includes a netplan yaml | 21:13 |
| smoser | and better off if cloud-init.service loses in other boots. | 21:13 |
| rharper | then, it will run but cloud-init won't "wait" on it | 21:13 |
| rharper | if we tell cloud-init to wait on it, then we get a loop, unless we drop the dbus.service requirement on networkd | 21:13 |
| rharper | if we drop it, then we break dbus control of networkd | 21:14 |
| rharper | messy | 21:14 |
| * rharper relocates, bb in 20 | 21:14 | |
| smoser | bah. | 21:14 |
| smoser | ping when you're back. | 21:15 |
| smoser | slangasek, ^ go ahead and hold off on that. | 21:25 |
| slangasek | smoser: the potential regression is networkd + cloud-init in xenial? | 21:25 |
| pitti | yes, if both are enabled you'll get a dep cycle | 21:26 |
| smoser | so what happens right now is that you get a race on cloud-init running before network is configured. | 21:26 |
| pitti | current: networkd after dbus.service after sysinit.target; new: cloud-init before sysinit.target after networkd | 21:26 |
| slangasek | right, as they would be both enabled for certain ubuntu-core use cases | 21:26 |
| smoser | neither dep cycle or race is good. | 21:27 |
| slangasek | smoser: I'm deep in the current review so I'll leave it in the queue for cross-comparison with whatever you upload next | 21:27 |
| smoser | right, the change would be http://paste.ubuntu.com/23482542/ | 21:27 |
| slangasek | smoser: doesn't that reintroduce the previous race? | 21:31 |
| smoser | of course. | 21:31 |
| slangasek | ok | 21:31 |
| slangasek | so it's 'back out this one change and get the rest of the SRU in' | 21:32 |
| smoser | yeah | 21:32 |
| smoser | pitti, are you ther e? | 21:33 |
| pitti | -ish | 21:34 |
| pitti | so http://paste.ubuntu.com/23482542/ would simply not yet bring netplan support with cloud-init | 21:34 |
| pitti | which seems acceptable | 21:34 |
| smoser | s/netplan/any systemd-networkd/ | 21:34 |
| pitti | it's actually not really a race -- it's guaranteed to not work :) | 21:34 |
| pitti | smoser: right, sorry (in the context of xenial, netplan is the main consumer though) | 21:35 |
| smoser | its probably a race in xenial now | 21:35 |
| smoser | so what about cloud-init.service waiting (via /lib/systemd/systemd-networkd-wait-online) if it determines that it needs to | 21:35 |
| smoser | possibly even just: | 21:35 |
| smoser | [ -e /etc/netplan/netplan/*.yaml | 21:36 |
| rharper | smoser: I don't think we can work around the fact that networkd currently requires dbus, and cloud-init.service wants to explicity run *before* it's available; | 21:36 |
| rharper | smoser: netplan already has a generator on that sort of thing | 21:36 |
| rharper | if cloud-init.service wants to run after networkd-wait-online, and also wants to run before dbus.service; we're boned until networkd can run without dbus; and then when dbus is available, regain it's dbus control interface; | 21:37 |
| smoser | cloud-init doesnt have to run before dbus specifically | 21:38 |
| smoser | that was just fallout of resolvd | 21:38 |
| smoser | rharper, so can you show me how to make a system use netplan so i canplay a bit ? | 21:38 |
| smoser | i think just put something in /etc/netplan/my.yaml | 21:39 |
| rharper | I don't think there's an alternative in cloud-init today to deal with early DNS timing out on resolvd ; technically in xenial we don't have systemd-resolved., but it could show up (and we'd divirge on systemd unit files) | 21:39 |
| rharper | smoser: yeah | 21:39 |
| smoser | and then somehow disable ifupdown | 21:39 |
| rharper | yes | 21:39 |
| rharper | I'll send you a paste | 21:39 |
| pitti | remove /e/n/i and create a /etc/netplan/my.yaml with the first example in man netplan (for ens3) | 21:40 |
| smoser | remote eni as in dpkg --remove ifupdown ? | 21:41 |
| pitti | just moving the file aside is fine | 21:42 |
| pitti | (or comment out the ens3 stanza at lealst) | 21:43 |
| rharper | http://paste.ubuntu.com/23482607/ | 21:43 |
| rharper | smoser: that has a DHCP on all ethernet v2 yaml | 21:44 |
| rharper | then you just need to remove the source in eni to prevent ifupdown from "seeing" fallback config from cloud-init | 21:44 |
| slangasek | smoser: I don't understand the 'RequiresMountsFor=/var/lib'. This is fixing the dep loop problem on LP: #1611074 that I pointed out on the last round, right? Why is /var/lib the relevant path here - shouldn't you specify the full path that you care about from within cloud-init-local (e.g. /var/lib/cloud)? | 21:50 |
| ubottu | Launchpad bug 1611074 in cloud-init (Ubuntu Xenial) "Reformatting of ephemeral drive fails on resize of Azure VM" [Medium,Confirmed] https://launchpad.net/bugs/1611074 | 21:50 |
| smoser | that probably is more correct. | 21:52 |
| slangasek | smoser: do you mind changing that to be more correct as part of the SRU? | 21:53 |
| smoser | i think initially i was just hesitant, and figured it was good enough. | 21:55 |
| smoser | i'm willing to change that though. | 21:56 |
| slangasek | smoser: I think it's best to change it | 21:57 |
| slangasek | smoser: also, I notice cloud-init.service has Wants=sshd-keygen.service and sshd.service; that seems wrong, cloud-init shouldn't be the thing deciding to start these services, it really only cares about ordering? But this is not a regression / not SRU relevant, so feel free to redirect me to a bug report | 21:57 |
| smoser | slangasek, i generally prefer known working to "seems correct" | 21:58 |
| juliank | doko: DonKult does not really want Filename in apt without a specific usecase why it should be there it seems | 21:58 |
| smoser | zesty has this, anad no issues known since friday or so | 21:58 |
| slangasek | smoser: that no longer sounds like "I'm willing to change it" :) | 21:58 |
| smoser | slangasek, i'm willing to. | 21:58 |
| doko | juliank: ok, but how do you get the component? | 21:59 |
| smoser | but in almost all cases i prefer working to more correct. | 21:59 |
| juliank | doko: You mean main, etc? I think you can read that in Apt-Sources | 21:59 |
| smoser | and the case here that is solved by adding '/cloud' is a case where /var/lib/cloud is on its own mountpoint in /etc/fstab | 22:00 |
| doko | juliank: but source and binaries can have different components | 22:00 |
| smoser | which is fine, and yeah, it does seem more correct, but it seems a very limited case | 22:00 |
| smoser | one that i'm certainly willing to fix in trunk and eventually sru though | 22:00 |
| smoser | but... all that said, ifyou'd prefer me to commit to trunk, upload to zesty and do the re-sru at the same time, i'll defer to you | 22:01 |
| slangasek | smoser: if you're committing to making the change in trunk that's enough for me for now. The case that's fixed by being more correct is marginal | 22:01 |
| juliank | doko: Well, I don't know how it's laid out in the pool. So you're saying one could be in a "universe" sources.list entry and be in a pool/main directory? Doesn't dists/DIST/<component> match pool/<component>? | 22:02 |
| smoser | i'll file a bug and fix in trunk right now. | 22:02 |
| doko | juliank: not sure about debian, but in ubuntu, you can have the source and some binaries in main, and other binaries in universe | 22:02 |
| slangasek | smoser: but it's definitely more correct; it will work (and would be tested as part of the SRU anyway so you don't have to take my word for it, which you shouldn't); and in addition to helping the small minority of users making a mountpoint of /var/lib/cloud, it makes it more obvious why that line is there so that future editors don't make thinkos | 22:02 |
| juliank | doko: I got that. But then I'd expect the universe binaries to be in pool/universe and in the universe Packages file, or are you saying the universe binaries are in pool/main | 22:03 |
| smoser | i've just been through enough "definitely more correct" with systemd recently to be gunshy | 22:03 |
| rharper | small minority of users with a separate /var/lib/cloud mountpoint is zero; at least users of the cloud-images we build | 22:04 |
| juliank | Because: APT-Sources gives you the Packages file the file will be fetched from basically, it will always show the binary component. | 22:04 |
| rharper | I don't think it's unreasonable to defer the correctness bugs to be filed by said users of cloud-init outside of the cloud-images we build | 22:04 |
| doko | so how do I get the component of a binary package? | 22:04 |
| slangasek | rharper: except then it's not obvious why you're listing /var/lib at all | 22:05 |
| slangasek | /var/lib/cloud is much clearer | 22:05 |
| juliank | You look at "APT-Sources: http://localhost:3142/ubuntu yakkety-proposed/main amd64 Packages" (for example) and see that it says /main after the archive name | 22:05 |
| smoser | i completely agree with slangasek, and i trust slangasek. but i trust 4 days of "working" more. | 22:05 |
| smoser | :) | 22:05 |
| juliank | That says: This binary is in main. | 22:06 |
| rharper | slangasek: I agree, with both; but I don't think it's sufficient to put /var/lib/cloud for a non-existent use-case | 22:06 |
| juliank | If you want the source component, you'd have to look up the corresponding source package. | 22:06 |
| rharper | either we actually document in the changelog (or the file itself) the systemd magic that is invoked with RequiresMountPoint | 22:06 |
| * juliank has the feeling he is missing something | 22:07 | |
| rharper | or we just assume magic; if we're supposed to tell systemd wichi mountpoints the service depends on, that seems awkward; but maybe that's the price of DefaultDependencies=No | 22:07 |
| rharper | if so, we should document it, and it should also include /var/log as well , and /etc and other dirs that cloud-init writes to itself; | 22:07 |
| rharper | that leaves open the fact that user-data may want to write to other locations on the system that we can't know at build time | 22:08 |
| juliank | doko: If there's something I'm missing, name me an example package (one binary in main, other in universe) I can look at - I don't know one right now | 22:09 |
| doko | juliank: gcc-6 source, gcc-6 binary in main, gcj-6 binary in universe | 22:10 |
| infinity | (base)adconrad@nosferatu:~$ apt show gcc-6 gcj-6 2>/dev/null | grep ^APT-Sou | 22:11 |
| infinity | APT-Sources: http://us.archive.ubuntu.com/ubuntu zesty/main amd64 Packages | 22:11 |
| infinity | APT-Sources: http://us.archive.ubuntu.com/ubuntu zesty/universe amd64 Packages | 22:11 |
| infinity | doko: ^-- Yes, that works fine. | 22:11 |
| juliank | ^ exactly | 22:11 |
| doko | ta | 22:12 |
| infinity | Of course, the stderr that I filtered out is: | 22:12 |
| infinity | WARNING: apt does not have a stable CLI interface. Use with caution in scripts. | 22:12 |
| infinity | ;) | 22:12 |
| juliank | Yep :) | 22:12 |
| juliank | infinity: I must say the whole core-dev thing is working out well. I sponsored some stuff in the past months, although I don't really have a count of how much, LP does not seem to keep track of everything :/ | 22:15 |
| infinity | https://launchpad.net/~juliank/+uploaded-packages ? | 22:16 |
| juliank | Yeah, that has some stuff in it. It misses some stuff I uploaded, but I can't recall exactly what that was... | 22:16 |
| infinity | It should have everything signed by you, in theory. | 22:16 |
| infinity | Signed and directly uploaded, that is. | 22:17 |
| infinity | Oh, no. Hrm. Maybe that only has the Changed-by stuff. Since it also has some things sponsored by others. | 22:18 |
| juliank | Yeah, I think so. Sponsored stuff like the ark one I signed does not appear. | 22:18 |
| infinity | We might be missing a section for actual uploads. | 22:18 |
| infinity | File an LP bug? :) | 22:19 |
| infinity | LP does track uploader (as you can see in any sponsored upload), so it should be trivial-ish to provide a history/count. | 22:20 |
| infinity | The part where we've overloaded the term "uploader" is less helpful. :P | 22:21 |
| infinity | But that really predates Ubuntu. The .changes fields have never made sense. | 22:21 |
| infinity | We just made it worse. Apparently. | 22:22 |
| juliank | I suspect there probably already is a LP bug for that | 22:22 |
| infinity | It may be 4 or 5 digits, even. | 22:22 |
| juliank | https://bugs.launchpad.net/launchpad/+bug/155956 is related at least | 22:22 |
| ubottu | Launchpad bug 155956 in Launchpad itself "+me/+packages should present different sections for sponsored uploads" [Low,Triaged] | 22:22 |
| infinity | If you ask wgrant, he can usually recite them. | 22:22 |
| infinity | Because he's weird. | 22:23 |
| infinity | And possibly not human. | 22:23 |
| juliank | One thing that annoys me is that I set my contact email to my gmail recently, and the sponsored stuff now appears as signed-by: <gmail address> | 22:23 |
| infinity | Yeah, because when we process the incoming upload, we map your GPG sig to your LP account. | 22:24 |
| juliank | That's a bit annoying, it'd look better with the @ubuntu.com one ... | 22:24 |
| infinity | And uploader is stored in the DB as a pointer to your LP users, not the key. | 22:24 |
| infinity | And then we present your primary address as the user in the UI. | 22:24 |
| juliank | I used to have juliank@ubuntu.com as my primary address, but that might have only gotten half of the emails; and there are rumours of redirect loops | 22:25 |
| infinity | juliank: So, I think the feature you'd be asking for is to decouple "display address" and "contact address" as two different objects. | 22:25 |
| juliank | Yeah, I think there's a bug report for that | 22:25 |
| infinity | Which is a valid feature request, IMO. | 22:25 |
| infinity | Especially for the reason you note. | 22:26 |
| infinity | People are encouraged to NOT use @ubuntu or @canonical as their primary, for fear of looping the automagic machinery. | 22:26 |
| infinity | But it's likely the one they want on display. | 22:26 |
| juliank | https://bugs.launchpad.net/launchpad/+bug/5292 | 22:27 |
| ubottu | Launchpad bug 5292 in Launchpad itself "People setting preferred contact address to @ubuntu.com" [Low,Triaged] | 22:27 |
| juliank | And LP people don't know how the aliasing works, as IS does that | 22:28 |
| juliank | that's all I know | 22:28 |
| infinity | 4 digits. Nice. | 22:29 |
| infinity | So, the LP argument 6 years ago that the forwarding thing is an IS bug is technically true, but it's still an LP bug that display and contact are lumped together. | 22:30 |
| infinity | I want humans to see one and machines to send to another. | 22:30 |
| infinity | Maybe I'll resurrect this one. | 22:30 |
| juliank | Right. This also makes more sense than dealing with that in the redirect, because why sent it via all redirects, if I can just tell launchpad the real address behind the alias. | 22:31 |
| infinity | It becomes a non-trivial bug when phrased the way I do, though, since we need to grep the full source and make a case-by-case decision on every occurrence of Person.email as to whether it's being used to send stuff or to display stuff. | 22:31 |
| smoser | slangasek, uploaded. delta versus the last upload: http://paste.ubuntu.com/23482797/ | 22:32 |
| juliank | infinity: Well, it does not have to be "perfect" at the beginning. Just better than the status quo | 22:32 |
| juliank | infinity: And the field just says "Display Contact Address (beta, might not be used everywhere yet)" | 22:33 |
| juliank | :) | 22:34 |
| infinity | juliank: It would also solve the longstanding misfeature where logged-in users can see your email in various places. | 22:34 |
| juliank | You could specifiy "No Display address" | 22:34 |
| infinity | juliank: As we can allow your *display* address to be a spam blocker or nothing at all. | 22:34 |
| infinity | Right. | 22:34 |
| Unit193 | Now I just need to find a way where people can't just hit that shiny "Contact user" button. >_> | 22:35 |
| rbasak | mwhudson: forgot the link> yes. Thanks! | 22:35 |
| infinity | Unit193: "Do not display contact user button" would be a trivial change on top of this. :P | 22:35 |
| infinity | (Though, would also need to cascade down to "contact team", etc) | 22:36 |
| mwhudson | rbasak: no worries :) | 22:36 |
| juliank | infinity: Just "Do not show "..." button" avoids all the hard work (hopefully) | 22:36 |
| infinity | Contact user doesn't bug me, it's "contact team's admins" that bugs me the most, since I seem to be on that list for a lot of teams that people feel the overwhelming urge to have opinions at. | 22:36 |
| Unit193 | Oh, well if people expect a response, email may not be the best method. :D | 22:37 |
| juliank | The button does not even say anything about email ... | 22:37 |
| juliank | :) | 22:37 |
| infinity | It has an envelope icon! | 22:37 |
| Unit193 | infinity: Because you're here, know what https://twistedmatrix.com/trac/ticket/5350 (#5616) status change means to #907675? | 22:37 |
| juliank | But, but, it would be nice if LP could just send those messages via xmmp! | 22:38 |
| Unit193 | juliank: IRC! | 22:38 |
| juliank | It could use an XMPP transport for that | 22:38 |
| mwhudson | facebook message | 22:39 |
| infinity | juliank: rfc1149 | 22:39 |
| juliank | transport again! | 22:39 |
| Unit193 | mwhudson: Eww, that's the worst. | 22:39 |
| juliank | 22:39 | |
| juliank | that surely is worse | 22:39 |
| juliank | Like "everyone" uses it. | 22:40 |
| Unit193 | I might be the only one that hasn't. | 22:40 |
| juliank | I don't use it. | 22:40 |
| infinity | Unit193: Colin's the right person to talk to about that. | 22:41 |
| Unit193 | infinity: But he's scarier than you! :> | 22:41 |
| infinity | Nah, he shaved off the beard. | 22:41 |
| juliank | I only use my XMPP accounts, hangouts, signal, and fb messenger (almost never) | 22:41 |
| juliank | Before FB it was ICQ | 22:42 |
| infinity | I gave up on pretty much all forms of IM as everyone I knew who used them stopped doing so. | 22:42 |
| Unit193 | Skype count? | 22:42 |
| infinity | Sure. | 22:42 |
| juliank | Oh yeah, Skype too | 22:43 |
| * Unit193 adds juliank. | 22:43 | |
| juliank | Good luck! | 22:44 |
| juliank | At least I don't end up adding "friends" by accident like when I'm using FB on mobile phones... | 22:44 |
| juliank | or "like"ing stuff | 22:44 |
| Unit193 | juliank: Telegram? That's another popular one. | 22:45 |
| juliank | Oh sure, funny hate comments, let's read them. Oh no, I accidentally liked one. | 22:45 |
| juliank | Unit193: nah | 22:45 |
| juliank | I only use Signal for encrypted chats with my family basically. | 22:46 |
| * Unit193 looks it up. | 22:47 | |
| juliank | Sensitive stuff, like account numbers and so on | 22:47 |
| juliank | Whoa, jabber.org finally fixed their DNS servers after 1.5 days. | 22:53 |
| juliank | I only need that one to talk to mvo when he's not on IRC, though | 22:54 |
| juliank | Well, I also have some people like dholbach in my roster, but never seen them in the past years | 22:56 |
| * juliank probably should clean that up | 22:58 | |
| Unit193 | kirkland: | 23:09 |
| Unit193 | Er,. wjpp; | 23:09 |
| juliank | Now that you mention him, I always wonder if he'd like his picture flashed in a background on a screen in Mr. Robot somewhere. | 23:10 |
| juliank | or name | 23:11 |
| Unit193 | Well I didn't mean to, meant to ping you. Think I need people "last seen" in '13? :P | 23:11 |
| juliank | There's been a pretty absurd scene in Mr. Robot where Elliot was basically running apt-get update | 23:14 |
| juliank | It was entirely unclear why he was running apt-get update at that point, given that he ran it before already IIRC | 23:15 |
| Unit193 | I made it 3 episodes into season 2 and couldn't do more because it was slow and just him monologuing. | 23:15 |
| juliank | Try again | 23:16 |
| juliank | It's getting better | 23:16 |
| juliank | And let's just say reality is subjective | 23:17 |
| juliank | You gotta get to episode 7 before you understand what's going on | 23:19 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!