| === blahdeblah_ is now known as blahdeblah | ||
| seb128 | cjwatson, launchpadlib's getRequestedReviews() doesn't seem to list git merge proposals, do you know if that's a known issue? or maybe I'm using it wrong? | 08:42 |
|---|---|---|
| cjwatson | seb128: Rings a bell ... ah yes, https://code.launchpad.net/~cjwatson/launchpad/git-getRequestedReviews/+merge/271136 | 09:02 |
| cjwatson | I need to finish a moderately large refactoring to make that work | 09:03 |
| seb128 | :/ | 09:03 |
| seb128 | do you have any workaround solution you can think of? | 09:04 |
| cjwatson | Not really, short of maybe scraping the web UI | 09:05 |
| seb128 | k, what I though | 09:05 |
| seb128 | oh well | 09:05 |
| seb128 | thanks cjwatson! | 09:06 |
| cjwatson | Adding a card for myself to revive that MP | 09:06 |
| seb128 | cjwatson, thanks! | 09:11 |
| rbasak | mvo: that was quick! | 09:32 |
| rbasak | I asked security in #ubuntu-hardened | 09:32 |
| mvo | rbasak: I will reply to the other questions in the bug | 09:33 |
| rbasak | infinity: ^ did you see my comment? | 09:36 |
| infinity | rbasak: I read your comment pretty much as I was clicking accept. We both noticed the subsequent commit (hence why mvo was so "quick" :P) | 09:37 |
| rbasak | Ah :) | 09:37 |
| infinity | rbasak: I don't think the security concern is valid, FWIW. If it is, we've done something very wrong, as UUIDs from libuuid are *never* guarnteed to be truly random. | 09:38 |
| infinity | rbasak: It's just that in some cases, they're kinda more random than others. | 09:38 |
| infinity | rbasak: So, I mean, if someone wants to hunt down if we're stupid, hunt away, but it shouldn't block this SRU even if it turns out we are stupid, we just need to stop being stupid. | 09:39 |
| rbasak | If the collision risk goes from small to big, then that can introduce a security issue where there wasn't one before (iff we were relying on unguessable UUIDs for security purposes) | 09:39 |
| infinity | rbasak: I can't see how we'd be relying on that, to be fair. | 09:40 |
| infinity | rbasak: Any UUID generated on a build system is known to the world, and can be reproduced by, y'know, copying and pasting. | 09:40 |
| rbasak | What about on a production system? | 09:40 |
| rbasak | cloud-init + openstack does weird stuff | 09:41 |
| rbasak | Anyway, I can't pin down a specific case; I was only concerned that there might be one. So it's not possible for me to win this argument by showing you a case :) | 09:41 |
| rbasak | I just wanted someone else who can think about it to think about it harder. | 09:42 |
| rbasak | I guess you've done that :) | 09:42 |
| rbasak | (also I hear you're on the security team :-P | 09:42 |
| infinity | rbasak: The second-oldest active member! | 09:43 |
| rbasak | Sounds like you're adding arbitrary qualifiers to work your way up the rank. Speaking as the oldest non-white (I think) SRU team member :-P | 09:45 |
| infinity | Hahaha. | 09:45 |
| infinity | rbasak: Is that (you think you're the oldest non-white member) or (you think you're non-white)? | 09:45 |
| rbasak | The former. But the latter amuses me :) | 09:46 |
| infinity | rbasak: I mean, you're one of the most stereotypically English people I know. Is it possible you're just wearing a brown suit to throw everyone off? | 09:47 |
| rbasak | :-P | 09:48 |
| rbasak | Stereotypically English but with a handy bonus race card :-) | 09:49 |
| infinity | rbasak: Does being Indo-British mean you get to enjoy tea twice as hard? | 09:50 |
| mvo | rbasak: I can dig some more into the question especially if and how much the randomness might regress. | 09:50 |
| mvo | rbasak: unless you two consider this settled here :) | 09:50 |
| mvo | tea++! | 09:51 |
| rbasak | I think we're OK as long as some smart people have thought about it. | 09:51 |
| rbasak | mvo and infinity both qualify :) | 09:51 |
| infinity | mvo: With the second commit, on a running system with decent entropy, the overall result should be "basically the same as before". In very early boot, randomness will definitely regress, but I really can't think of many times you generate a UUID in early init *and* care that it's globally unique. | 09:51 |
| mvo | infinity: totally agree | 09:52 |
| infinity | (Plus, while the RFC and the name UUID claims global uniqueness, any mathmetician will tell you that's literally impossible to guarantee, it's the statisticians who will say "close enough") | 09:52 |
| mvo | infinity: I also think parted is just silly | 09:52 |
| mvo | infinity: it calls (indirectly) random_get_bytes 4 times when just doing "parted p" | 09:52 |
| infinity | And any security expert who listens to statisticians over mathmeticians is likely to have a bad day. | 09:52 |
| mvo | infinity: so definitely something fishy going on there, fixing parted is probably also nice. I didn't want to waste too much time on this though (parted has way more layers :) | 09:53 |
| infinity | parted is evil incarnate. | 09:53 |
| cjwatson | Would be nice to work out where that is in parted. It might be specific to the disk layout ... | 09:53 |
| infinity | Why are you even using parted instead of something simpler like sfdisk? | 09:53 |
| mvo | infinity: I don't know, sorry, but afaik sfdisk has a similar problem a9cf659e0508c1f56813a7d74c64f67bbc962538 mentions sfdisk | 09:55 |
| mvo | infinity, cjwatson I can look at gparted and timebox it | 09:55 |
| mvo | its an interessting problem for sure :) | 09:56 |
| infinity | mvo: So, wait. Both sfdisk and parted are calling uuidgen when *growing* partitions, and they don't actually use the result for anything? | 09:56 |
| infinity | mvo: Cause if so, lol? | 09:56 |
| infinity | Or does growing imply giving it a new UUID because reasons? | 09:57 |
| mvo | infinity: parted even call random_get_bytes (indirectly) when you just print partitions | 09:58 |
| mvo | infinity: I have not looked at sfisk at all | 09:58 |
| cjwatson | The calls here are in gpt_alloc and gpt_partition_new | 09:58 |
| sladen | depends on the version of the UUID being requested to be generated ... eg. version 1 is MAC address + timestamp, which with reproducible builds, should produce the same result every time | 09:58 |
| cjwatson | mvo: Are you using GPT on this disk? | 09:59 |
| mvo | cjwatson: yes | 09:59 |
| cjwatson | Arguably a bug in parted's GPT code then. When it's constructing internal data structures to match what's on the disk, it generates GUIDs even though it's about to read the new ones off disk. | 10:02 |
| cjwatson | s/the new ones/the existing ones/ | 10:02 |
| cjwatson | parted shares a fair bit of code between "create actual new partition" and "create new partition data structure and fill it in from what's on disk", and in this case the GUID generation is probably in the wrong place. | 10:03 |
| cjwatson | It might need some kind of internal marker to do lazy GUID generation. | 10:05 |
| cjwatson | Do file a bug - it's not completely simple but shouldn't be too hard. | 10:05 |
| cjwatson | I think it's just GPT. | 10:07 |
| mvo | cjwatson: I filed 1783973 but I think its probably overkill to fix as long as we don't need crypto strengh randomness for uuids | 10:22 |
| infinity | mvo: Meh, it's wrong for anything to suck your entropy dry when it doesn't actually need any. | 10:26 |
| infinity | Valid bug, even if the impact is minimized by the libuuid fix. | 10:26 |
| Unit193 | ..I don't suppose anyone would be interested in sponsoring irssi right now? | 11:08 |
| chu | Need a maintainer? | 11:14 |
| Unit193 | chu: I like merging from Debian, but alas I am but a measly packageset uploader. | 11:15 |
| chu | I thought about applying to look after the newest emacs but seems quite hectic | 11:17 |
| Unit193 | I think I looked at that package once, bailed the crap out of there. | 11:17 |
| chu | Smart choice | 11:18 |
| Unit193 | dget -x https://sigma.unit193.net/source/irssi_1.1.1-1ubuntu1.dsc if anyone is interested++ | 11:19 |
| chu | Fancy | 11:21 |
| juliank | cyphermox: https://netplan.io/reference says different things than the netplan manpage, about timeouts specifically - netplan.io says they depend on the renderer, manpage says they are ms. | 13:18 |
| gromero | Hi. I think there is an issue with with 18.04.1 PPC64 ISO. 'isoinfo' complains about Joliet SVD not being present in the ISO: | 13:19 |
| gromero | root@pub:/var/lib/libvirt/isos# isoinfo -J -i ./bionic-live-server-amd64.iso # OK | 13:19 |
| gromero | root@pub:/var/lib/libvirt/isos# isoinfo -J -i ./bionic-live-server-ppc64el.iso # Fail | 13:19 |
| gromero | isoinfo: Unable to find Joliet SVD | 13:19 |
| gromero | I see a difference regarding the # of partitions: | 13:19 |
| gromero | root@pub:/var/lib/libvirt/isos# file ./bionic-live-server-amd64.iso | 13:19 |
| gromero | ./bionic-live-server-amd64.iso: DOS/MBR boot sector; partition 2 : ID=0xef, start-CHS (0x3ff,254,63), end-CHS (0x3ff,254,63), startsector 1590408, 4672 sectors | 13:19 |
| gromero | root@pub:/var/lib/libvirt/isos# file ./bionic-live-server-ppc64el.iso | 13:19 |
| gromero | ./bionic-live-server-ppc64el.iso: DOS/MBR boot sector; partition 1 : ID=0x96, active, start-CHS (0x3ff,255,63), end-CHS (0x3ff,255,63), startsector 0, 1634024 sectors; partition 2 : ID=0xff, start-CHS (0x3ff,255,63), end-CHS (0x3ff,255,63), startsector 2129919, 1936615684 sectors | 13:19 |
| gromero | Basically it forbids virt-install --location flag to work properly on that ISO: https://pastebin.com/raw/A0XZaNmM | 13:20 |
| gromero | Does anybody have any clue on that? | 13:20 |
| juliank | gromero: I'm not an expert, so, what is that, how is it used, and is it relevant for ppc64el? | 13:21 |
| juliank | AFAICT, it is used when certain files are unicode encoded. | 13:22 |
| gromero | juliank: Hi. Basically that error on Joliet SVD missing on that ISO, as far as I can tell, forbids that ISO to work properly with virt-install, i.e. I can't install a VM using the ISO on PPC64. | 13:22 |
| gromero | juliank: I see. But do you know what's exactly the difference between Intel/AMD ISO and PPC64 that could trigger that error in isoinfo? | 13:24 |
| gromero | juliank: you mean any file in the ISO? | 13:25 |
| gpiccoli | infinity might be aware of this difference, let's see what he thinks when available | 13:25 |
| gromero | (using unicode encode) | 13:25 |
| gromero | gpiccoli: ok | 13:25 |
| cyphermox | juliank: sure, the netplan.io website needs an update, that doesn't happen automatically | 13:32 |
| juliank | cyphermox:it just got pointed out to me today, hence I thought I'd let you know :) | 13:33 |
| cyphermox | yup, thanks | 13:42 |
| cyphermox | pointed out by? | 13:42 |
| cyphermox | (feel free to send them my way, new features, bugs, etc.) | 13:43 |
| juliank | ugh | 13:48 |
| juliank | $ petname -u | 13:48 |
| juliank | -yeti | 13:48 |
| juliank | no adjective with y? | 13:48 |
| juliank | grr | 13:48 |
| ogra | yodeling ? | 13:49 |
| xnox | gromero, huh, that makes no sense =) | 13:56 |
| xnox | gromero, amd64 has joliet, because it has uefi, and ppc64el, doesn't because it does not do eufi.... | 13:56 |
| xnox | gromero, you will find that e.g. arm64 is also joliet. | 13:57 |
| xnox | gromero, this sounds like a bug in virt-install to me, and i'm not sure if that support ppc64el at all....?! does it work with any other ppc64el images for any other distro? | 13:57 |
| xnox | gromero, also, why bother to use virt-install, when you can just directly boot ppc64el cloud-image that we provide? | 13:57 |
| xnox | and provide appropriate metadata ISO to customize the instance, and resize the drive to needed size. | 13:58 |
| gromero | xnox: virt-install just crash because of the Joliet error returned by make isoinfo. I would expect that virt-install is not that arch-specific also (aside from isoinfo issue). Let me try with RHEL. I simply don't want to use cloud-image. Which cloud-image are you talking about specifically? | 14:01 |
| xnox | gromero, https://cloud-images.ubuntu.com/bionic/current/ bionic-server-cloudimg-ppc64el.img | 14:02 |
| xnox | gromero, which is pre-installed ubuntu-server, in qcow2 format, bootable, with cloud-init available, and awaiting e.g. seed.iso to be booted on the instance for autodiscovery and configuration | 14:02 |
| xnox | gromero, at the bottom of https://cloudinit.readthedocs.io/en/latest/topics/datasources/nocloud.html there is a section on how to create a custom seed.iso with your own ssh keys, packages to isntall/configure, tec. | 14:04 |
| gromero | ok I'll use that to move on. thanks for the hint. However I really not satisfied yet about the complains of isoinfo. I would like to understand what's really going on, so if anybody could explain I would be glad. Let me try with RHEL (will get back soon). ;) | 14:04 |
| xnox | gromero, at the bottom of https://cloudinit.readthedocs.io/en/latest/topics/datasources/nocloud.html there is a section on how to create a custom seed.iso with your own ssh keys, packages to install/configure, etc. | 14:04 |
| gromero | xnox: ok. I'll check that. Thanks! | 14:04 |
| xnox | gromero, my initial suspection is that virt-install is expecting x86_64 .iso image with UEFI joilet partition for booting in e.g. uefi mode... which is all very x86_64 specific. | 14:05 |
| xnox | gromero, i typically download and boot cloud images =) either directly with cmdline, via virt-manager, or with like uvt command line tool; or like with multipass command line tool, which provide the "give me a vm, ssh into it, quickly" | 14:06 |
| xnox | depending on what i'm doing. | 14:06 |
| xnox | gromero, but i also have access to ppc64el openstack and MAAS =) so i have all the toys available to me to play with everything. | 14:06 |
| gromero | xnox: I see. Openstack and MAAS is too overkill to my case... multipass and uvt sounds better tho :) | 14:08 |
| gromero | xnox: thanks for the hints. I'll try uvt | 14:09 |
| xnox | gromero, everything does work on x86_64... and if it doesn't for some reason on ppc64el, do shout and we'll try to fix all the things. | 14:09 |
| xnox | gromero, our cloud-images and cloud-init are working on all arches to be directly launched to create VMs -> i.e. all launchpad builders for all 7 arches work like that. | 14:10 |
| gromero | xnox: ok. I'll experiment other ISOs to see how it goes. I still think the root cause is that isoinfo is not able to list files in the ISO with -J -i <ISO> -p on ppc64le | 14:10 |
| gromero | xnox: do you use multipass and uvt with the cloud images? | 14:11 |
| xnox | gromero, sure, but it is arch specific whether or not .iso is a joilet or not. | 14:11 |
| xnox | gromero, they default to our cloud images, yes. | 14:11 |
| gromero | xnox: ah, ok. I'll check that so. | 14:11 |
| xnox | i think i did on x86_64 and arm64 and s390x.... mostly. | 14:11 |
| gromero | xnox: yes, but isoinfo should detect the differences between ISOs and handle it nicely I think. | 14:12 |
| xnox | and sans bugs, it should all just work on ppc64el too. I mean booting with a custom seed.iso as per docs about does work on ppc64el and i have done that. | 14:12 |
| gromero | yes, cloud image I'll probably work fine on ppc64le | 14:13 |
| gromero | what bugs me is that it didn't work with the ISO + virt-install as it does for other archs | 14:13 |
| gromero | xnox: it does work perfectly with a RHEL 7.5 image: https://hastebin.com/raw/gobonexuwe | 14:21 |
| gromero | xnox: just because isoinfo is able to list the content o RHEL's ISO | 14:22 |
| xnox | gromero, please do $ ubuntu-bug virt-install | 14:22 |
| xnox | and file details, and maybe we can figure out if patches to virt-install are needed, and/or isoinfo, and/or the way we produce our .iso images on ppc64el. | 14:22 |
| xnox | gromero, i mean, we don't sabotage our images on purpose and we would rather them be as universally consumable as possible =) | 14:24 |
| gromero | xnox: I would never think that Canonical sabotage their images or anything to be honest. And I still think the issue is with buggy isoinfo that is not smart enough to figure out the ISO particularities... | 14:26 |
| gromero | ok. I can file a bug | 14:26 |
| xnox | gromero, can even make the bug affect all the things you see should be fixed. in practice, silly things like that should just work, irrespective of the details. | 14:27 |
| gromero | I don't think that not being able to list the ISO contents is a detail, but I'll file all the details I have in the bug. thanks. | 14:28 |
| === walbon is now known as gwalbon | ||
| dannf | dmj_s76: not generally, no. why? | 15:10 |
| === TheMaster is now known as Unit193 | ||
| === TheMaster is now known as Unit193 | ||
| Unit193 | LocutusOfBorg: Howdy, you alive? | 20:52 |
| LocutusOfBorg | Unit193, if you want to give me a merge... might be | 20:56 |
| LocutusOfBorg | but going to sleep in 10 min | 20:56 |
| Unit193 | LocutusOfBorg: https://sigma.unit193.net/source/irssi_1.1.1-1ubuntu1.dsc how did you know?! :D | 20:58 |
| LocutusOfBorg | I was going to ask you why you didn't gave me an irssi merge, already two days ago :) | 20:59 |
| Unit193 | Please make sure to check the changelog so we don't anger $other_people | 21:00 |
| LocutusOfBorg | what do you mean? | 21:01 |
| LocutusOfBorg | dpkg-buildpackage -S -sa -d -v1.0.7-1ubuntu1 | 21:01 |
| LocutusOfBorg | and I'm going to sponsor | 21:01 |
| LocutusOfBorg | I don't get why the patch is applied only in Ubuntu, but meh | 21:01 |
| LocutusOfBorg | dput refuses to upload "devel" codename, but dupload does | 21:04 |
| LocutusOfBorg | I think I did it | 21:04 |
| Unit193 | Perhaps you mean dput-ng? I use dput. | 21:06 |
| LocutusOfBorg | I don't remember... | 21:07 |
| LocutusOfBorg | one for doing dcut dm, the other fails to do it | 21:08 |
| LocutusOfBorg | and then I install again the other one | 21:08 |
| LocutusOfBorg | and then I change it back once somebody asks me to allow a package | 21:08 |
| LocutusOfBorg | meh, :/ | 21:08 |
| LocutusOfBorg | I never found one tool to rule them all | 21:08 |
| Unit193 | dput just does what you tell it, dput-ng tries to lint first (which is good, except when it doesn't know better and won't let you do something.) It does make certain Debian specific things easier though. | 21:10 |
| bdmurray | slangasek: the package installation in bug 1784065 includes dpkg and libglib2.0-0 but libglib2.0-0 happened first | 21:30 |
| ubottu | bug 1784065 in glib2.0 (Ubuntu) "package libglib2.0-0 2.48.2-0ubuntu3 failed to install/upgrade: triggers ci file contains unknown directive `interest-await'" [Undecided,Incomplete] https://launchpad.net/bugs/1784065 | 21:30 |
| slangasek | bdmurray: yeah, the dpkg SRU is unrelated | 21:30 |
| bdmurray | dpkg:amd64 (1.17.5ubuntu5.8, 1.18.4ubuntu1.4) ? | 21:32 |
| bdmurray | slangasek: its an upgrade from Trusty to Xenial | 21:33 |
| slangasek | bdmurray: oh | 21:34 |
| slangasek | bdmurray: did no one verify that trusty dpkg supported this syntax before we started changing xenial packages? | 21:35 |
| bdmurray | slangasek: did no one suggest checking that? seriously I don't recall talking to juliank about it | 21:37 |
| slangasek | bdmurray: I assumed there were other people more familiar with dpkg involved in this who would have checked :) | 21:39 |
| slangasek | bdmurray: so, it's ok to still have the triggers changed, but it means that every package with this new syntax needs to have a pre-depends on newer dpkg | 21:44 |
| bdmurray | slangasek: yes, I see that now | 21:44 |
| bdmurray | slangasek: Are you updating the bug or shall I? | 21:50 |
| slangasek | bdmurray: please do | 21:50 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!