| cpaelzer | good morning btw | 05:28 |
|---|---|---|
| RoyK | mrnng | 05:29 |
| RoyK | n vwls t - t rl | 05:29 |
| utkarsh2102 | cpaelzer: o/ | 05:31 |
| cpaelzer | I need some serious abbreviation translator for this RoyK :-) | 05:35 |
| bryceh | no vowels too - to rule | 05:38 |
| cpaelzer | To enjoy that you must be living in https://en.wikipedia.org/wiki/Zzyzx,_California :-) | 05:41 |
| RoyK | cpaelzer: morning - no vowels yet - too early ;) | 05:48 |
| RoyK | perhaps that should be "n vwls yt…" - English is funny how y can be a vowel and a consonant at different places… | 05:50 |
| cpaelzer | indeed RK :-) | 05:52 |
| RoyK | vowels just don't work in the morning - you know ;) | 05:56 |
| bryceh | @RoyK, try telling that to Rhabarberbarbara | 05:58 |
| cpaelzer | And do so at the FinanzBilanzFranzToleranzTanz | 05:58 |
| RoyK | sometimes - preferably in the morning - slavic languages are quite easy to pronounce ;) | 06:00 |
| RoyK | travel from Brno to Plzeň and you'll learn a abit | 06:01 |
| RoyK | travel from Brno to Plzeň and you'll learn a bit | 06:01 |
| cpaelzer | and early enough on that morning you might feel smrt | 06:03 |
| RoyK | I haven't been to Brno yet, sadly, but Plzeň is nice, pronounced something like [ˈpl̩zɛɲ], two syllables, one vowel | 06:03 |
| RoyK | (brno is also two syllables, btw) | 06:04 |
| mirespace | good morning | 08:52 |
| utkarsh2102 | mirespace: o/ | 08:53 |
| mirespace | hi utkarsh2102 o/ | 08:53 |
| ahasenack | checmorning | 12:07 |
| athos | good morning! | 12:16 |
| * kanashiro waves | 12:17 | |
| cpaelzer | hi kanashiro | 13:07 |
| cpaelzer | ahasenack: I replied on libtpms, TL;DR yes d/p/no_local_check.patch is still needed | 13:07 |
| ahasenack | me too, +1 | 13:11 |
| cpaelzer | thanks | 13:16 |
| cpaelzer | now only waiting for foundations to reply as well | 13:16 |
| === almostdvs1 is now known as almostdvs | ||
| ahasenack | TIL systemd-sleep(8) | 13:36 |
| ahasenack | what has systemd NOT touched, I wonder | 13:36 |
| ahasenack | scripts in /lib/systemd/system-sleep/ | 13:36 |
| konstruktoid[m] | <ahasenack> "TIL systemd-sleep(8)" <- "systemd-hybrid-sleep.service is pulled in by hybrid-sleep.target to execute hybrid hibernation with system suspend and pulled in by suspend-then-hibernate.target" | 13:48 |
| konstruktoid[m] | what’s not to like? | 13:48 |
| ahasenack | heh | 13:49 |
| rbasak | bryceh: I don't see you in #launchpad, but given the work you're doing on reporting on MP status, it might be helpful for you to know that getRequestedReviews() currently can't return git-based MPs. | 14:14 |
| rbasak | It's blocked on https://code.launchpad.net/~cjwatson/launchpad/git-getRequestedReviews/+merge/271136 | 14:14 |
| rbasak | That might possibly impact you. I'm not sure. | 14:14 |
| * ahasenack shakes fist at unattended-upgrades running on a devel release | 14:17 | |
| athos | sergiodj: FYI: I am taking care of those ROCK rebuild requests | 14:30 |
| sergiodj | athos: thanks! | 14:30 |
| athos | facing odd issues in non x86_64 builders though: https://launchpadlibrarian.net/594109105/buildlog_oci_ubuntu_bionic_arm64_apache2-20.04_BUILDING.txt.gz | 14:30 |
| * sergiodj looks | 14:31 | |
| sergiodj | ops | 14:31 |
| sergiodj | huh, it was able to pull the image from dockerhub | 14:32 |
| athos | I was about to retry those, but since we have the pull rate limits, we better sort this out before doing so (all non x86 builds are failing) | 14:33 |
| athos | yup, the issue is in the ubuntu repositories | 14:33 |
| athos | when trying to `apt-get update` | 14:33 |
| sergiodj | we should ping the LP folks | 14:37 |
| sergiodj | just to confirm, I did an "apt update" inside an arm64 machine here and it succeeded | 14:38 |
| bryceh | rbasak, thanks for letting me know. I'm in the MM launchpad channel but don't monitor it closely | 14:51 |
| bryceh | rbasak, the MP system has a couple other limitations, I don't know if they're related to this one, but my workaround has been to download the HTML and parse it, and combine that with whatever info can be gleaned from LP, and go from there. | 14:52 |
| rbasak | It didn't occur to me to scrape. That might get me past my blocker too | 14:55 |
| rbasak | Thanks :) | 14:55 |
| bryceh | I worry it's a bit brittle in that if they change the HTML or LP API it'll break | 14:56 |
| bryceh | but probably a problem worth having, since that'd mean MP's were getting some coding attention :-) | 14:56 |
| bryceh | rbasak, fwiw I highly recommend using BeatifulSoup for the scraping work | 14:57 |
| sbeattie | bryceh, rbasak: do you have pointers to what you're doing with MPs? I am trying to scope out some work to make lingering MPs more visible for the security team, so having code and ideas to steal liberally^W^W re-use would be appreciated... | 15:06 |
| bryceh | I do; but hang on I'm in a meeting | 15:09 |
| sbeattie | bryceh: totally, no rush. | 15:38 |
| bryceh | sbeattie, ok, got the info together and be aware this is all still very WIP but I can share what I'm doing | 16:25 |
| bryceh | the top two commits on this branch have the MP code I'm working on - https://code.launchpad.net/~bryce/pdbq/+git/pdbq/+ref/merge-proposal-wip | 16:25 |
| bryceh | it's a class and a script, the former wrappers the LP MP, the latter combines that with some screenscraping to produce rich JSON data of the MPs | 16:26 |
| bryceh | here's what the JSON ends up looking like for our team - http://pinot.endarchy.org:3000/reviews | 16:26 |
| bryceh | the intent here is to pull that JSON data into a web frontend to display a better review page than we currently get from Launchpad, that is filtered, organized, and detailed differently (TBD spec) than the current page. | 16:28 |
| bryceh | sbeattie, I don't have a real mockup yet of what that report will look like, but here's the first cut I've made just to have something to throw darts at: http://www.bryceharrington.org/experimental/reviews-mockup.png | 16:29 |
| sbeattie | bryceh: nice! | 16:30 |
| bryceh | sbeattie, the nice thing of having the code emit JSON rather than a webpage directly is it should facilitate creating custom CLI's or other interfaces as desired | 16:30 |
| sbeattie | yeah | 16:30 |
| bryceh | longer term vision is to integrate the MP reviews with our package merge schedule, http://pinot.endarchy.org:4200/merges-schedule, but how that'll look/work is still vague but you can use your imagination :-) | 16:32 |
| sbeattie | oh yeah, that's really nice. | 16:34 |
| sbeattie | Thanks, that's some really useful stuff to look at. | 16:41 |
| bryceh | yeah I'd love if other teams can use or collaborate on any of this, and it's a goal to try to make more of our stuff sharable across teams | 16:43 |
| * bryceh lunch, bbl | 16:44 | |
| yurtesen | pfsmorigo: thanks for sponsoring my debdiff :) | 16:49 |
| pfsmorigo | yurtesen, np, please let me know if you have problems with this new version | 16:51 |
| yurtesen | pfsmorigo would you be interested in sponsoring non-security bug fixes? :) | 16:55 |
| yurtesen | I need to close at least one more bug report related to tomcat9 package. Somewhat important as it causes catalina.out log file to grow forever and fills up the disk eventually. This issue was caused by Ubuntu running rsyslog as syslog user unfortunately. But the fix ix very simple (just change the logrotate to run as syslog user). I already created debdiff for it. I believe this does | 16:59 |
| yurtesen | not effect bionic as it is using the old pre-systemd startup scripts with tomcat. | 16:59 |
| ddstreet | bryceh interesting lp caching, i have a branch of u-d-t i was working on to cache lp also in case it's useful to you https://code.launchpad.net/~ddstreet/ubuntu-dev-tools/+git/ubuntu-dev-tools/+ref/cache | 17:03 |
| richd | Hi, after updating a server running Ubuntu 16.x with Xen to Ubuntu 18.x, and again to Ubuntu 20.04.4, it won't boot the newly install 5.13.0-39-generic, with some error about the kernel not being an ELF file. It boots well with the previous 5.4 kernel. Is there a way to fix this? | 17:34 |
| bryceh | ddstreet, ooh cool yeah that looks interesting | 17:38 |
| ddstreet | i was working on it to use in detecting the list of bugs fixed in package version spans, e.g. what bugs were fixed between pkg 1.2.3 and 1.2.6, i got sidetracked though | 17:40 |
| bryceh | ddstreet, yeah I became aware of the ubuntutools/ module in ubuntu-dev-tools after I started this work, and it's been on my todo to see if I could either derive from that module directly, or contribute some enhancements. | 17:40 |
| bryceh | sidetracks are a way of life around here :-D | 17:41 |
| ddstreet | yeah the ubuntutools/lp/lpapicache module kind-of 'wraps' Launchpadlib but not entirely | 17:41 |
| ddstreet | yep | 17:41 |
| bryceh | yeah the lp module I am using for pdbq I sourced from bileto with some ideas from the old lpltk | 17:42 |
| bryceh | everyone solves the "wrap lpapi" | 17:42 |
| lotuspsychje | richd: if nobody recalls a bug on that right away, you might also consider creating a new !bug, aka ubuntu-bug linux will create one against your faulty kernel | 17:42 |
| ddstreet | is bileto just for prod eng? i don't know of anyone with bileto access besides prod eng teams | 17:43 |
| ddstreet | i asked for access but was denied :( | 17:44 |
| bryceh | cpaelzer or ahasenack are probably better to ask, I don't use it myself, but found the codebase to be super interesting | 17:45 |
| ChmEarl | richd, Xen will not support the zstd compressed in the 5.13.x kernel | 17:48 |
| bryceh | ddstreet, fwiw between christian, myself, and other team members, we have CLI tool bits and pieces that we think might be able to be cobbled together to provide bileto-like functionality (creating ephemeral ppas, running autopkgtest on the ppa, etc.), but without requiring anything server-side. | 17:48 |
| ChmEarl | richd upstream Xen added this support in 4.15.0 | 17:49 |
| bryceh | that's still just an inkling of an idea though, no POC yet | 17:49 |
| ddstreet | bryceh sorry i appear to have dropped for a sec did you paste a link? | 17:50 |
| bryceh | regarding bileto usage: cpaelzer or ahasenack are probably better to ask, I don't use it myself, but found the codebase to be super interesting | 17:50 |
| bryceh | ddstreet, fwiw between christian, myself, and other team members, we have CLI tool bits and pieces that we think might be able to be cobbled together to provide bileto-like functionality (creating ephemeral ppas, running autopkgtest on the ppa, etc.), but without requiring anything server-side. | 17:50 |
| bryceh | that's still just an inkling of an idea though, no POC yet | 17:50 |
| ddstreet | yeah definitely interested if you get something working | 17:51 |
| bryceh | great | 17:51 |
| ChmEarl | richd, https://xenbits.xen.org/gitweb/?p=xen.git;a=commit;h=049c1917fdea7aaaebdb449d769aaf625b1cfb6a | 17:53 |
| richd | ChmEarl: Many thanks. | 18:03 |
| sbeattie | bryceh: ohhh, yes, we have wanted bilete-like functionality forever, too, to avoid some issues we've hit when publishing security updates. | 18:32 |
| sbeattie | s/bilete/bileto/ | 18:32 |
| cpaelzer | ddstreet: AFAIK bileto is restrictred to core-devs | 18:55 |
| ddstreet | well i've been a coredev for years | 18:56 |
| yurtesen | pfsmorigo: what do you think? | 19:01 |
| richd | hi, so after upgrading to the 5.13 kernel, my server no longer renames its four network interfaces from eth0-3 to em[1-4], and now automatically renames them to eno[1-4]. This has really upset openvswitch. How do I make it go back to em[1-4]? | 19:12 |
| richd | I could dump and rebuild all of the OVS configurations, but that seems non-productive unless I can stop ubuntu from renaming all of the interfaces once and for all, otherwise rebuilding the openvswitch config would be undone if the next update decides to rename all the interfaces again | 19:16 |
| sarnold | richd: search for 'set-name' in https://netplan.io/reference/ | 19:17 |
| richd | @sarnold there doesn't seem to be any such thing on this machine. There are /lib/netplan, and /etc/netplan directories, but they are empty. This machine started as ubuntu 16. Perhaps netplan never installed during the upgrades | 19:27 |
| richd | why/what would be renaming the interfaces? can that just be disabled altogether, or is there a reason to not have eth[0-3] ? | 19:28 |
| ChmEarl | richd, did you have net.ifnames=0 on kernel cmdline on older kernels? | 19:29 |
| sarnold | you're going to laugh when you find out that the newer name styles are intended to be more deterministic than the ethN naming style.. | 19:29 |
| sarnold | never mind that the naming format seems to change every two or three years :( | 19:29 |
| richd | sarnold: indeed | 19:33 |
| richd | ChmEarl: no, i never set any such thing. When I first installed this server, it used the em[1-4] convention, and as it was a new install, I just left it the way it was. I figured "if that's the way Ubuntu wants it, that's what it will be." it never dawned on me that it would be randomly changed | 19:34 |
| Odd_Bloke | sarnold: To be fair, device names changing across kernel upgrade _is_ actually something that the newer deterministic naming would fix. :p | 19:37 |
| sarnold | Odd_Bloke: oh, sure, it's still an improvement to have nic names change on upgrades every N years rather than every third boot | 19:38 |
| sdeziel | richd: since you are coming from 16.04, it's possible this used the old naming scheme. As for the 'set-name' netplan directive, it's something you'll need to add to your /etc/netplan/*.yaml config if you want to have those interfaces named as em[1-4]. | 19:41 |
| richd | Odd_Bloke: whichever schema is better or worse is moot when the schema is changed out from under a production server with opt out, or even the slightest warning. It would be better if there were a banner of some sort "This update will break all of your network interfaces!" | 19:41 |
| richd | s/with opt/without an opt../ | 19:42 |
| ahasenack | back | 19:42 |
| richd | sdeziel: or...add " pre-up ip link set eno[x] name em[x]" to /etc/network/interfaces for each one | 19:47 |
| sdeziel | richd: /etc/network/interfaces is deprecated though | 19:47 |
| richd | sdeziel: perhaps, but for now, my problem is solved. | 19:48 |
| Odd_Bloke | richd: I believe you're still on the old schema: with the newer Ubuntu releases, userspace handles naming the interfaces consistently regardless of the name the kernel gives them. In this instance, you wouldn't have seen a change due to a kernel upgrade, the userspace naming parts would have handled keeping them consistent for you. Of course, that doesn't help you now. :) | 19:48 |
| richd | Odd_Bloke: all of this annoyance could have been easily avoided were it not for some malcontent deciding that eth[0-3] wasn't good enough. | 19:51 |
| richd | :) | 19:51 |
| richd | Odd_Bloke: sdeziel: many thanks, I'm going home. | 19:52 |
| Odd_Bloke | Not really, unfortunately: those names are assigned by the kernel in order of appearance. With NICs that take time to initialise, there's a race condition: your eth0 on one boot could be different to eth0 last boot. | 19:52 |
| richd | Odd_Bloke: udev used to keep that straight. | 19:53 |
| Odd_Bloke | Is it frustrating to deal with? Absolutely. :) | 19:53 |
| Odd_Bloke | udev still does, netplan.io just configures it/networkd/something. | 19:53 |
| Odd_Bloke | And IIRC, a different set of names was needed because udev can't rename eth1-which-was-eth0-last-boot to eth0 if eth0-which-was-eth1-last-boot hasn't been renamed, etc. | 19:54 |
| richd | Odd_Bloke: Of course it's frustrating. If I didn't want frustration, I would have kicked Linux to the curb decades ago. Linux can do anything, and it's free, but I do realize that at some point, I will still pay. | 19:56 |
| Odd_Bloke | :) | 19:56 |
| richd | many thanks, again... | 19:56 |
| sergiodj | athos: hey, I will go ahead and create a request on snapcraft.io to close the 20.04/21.04/21.10 tracks on all our snaps | 21:32 |
| sergiodj | actually, it looks like we can close the channels ourselves | 21:33 |
| sergiodj | let me see if I can do it | 21:33 |
| === elastic_1 is now known as elastic_dog | ||
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!
