| === alan_g_ is now known as alan_g | ||
| tseliot | Eickmeyer, I am working on a backport of nvidia settings (460.39) for groovy, focal, bionic as part of LP: #1915003 . As for nvidia-modprobe, we don't package that, it comes from Debian | 09:35 |
|---|---|---|
| ubottu | Launchpad bug 1915003 in nvidia-settings (Ubuntu Groovy) "Always update the initramfs when changing power profile" [High,In progress] https://launchpad.net/bugs/1915003 | 09:35 |
| andrewsh | seb128: hi, are you around? | 09:37 |
| andrewsh | seb128: I’m sorry I was angry in LP: #1893563 | 09:37 |
| ubottu | Launchpad bug 1893563 in network-manager (Ubuntu) "netplan: can't login to ap mode with psk" [Medium,Fix committed] https://launchpad.net/bugs/1893563 | 09:37 |
| andrewsh | :) | 09:37 |
| andrewsh | seb128: I’d really like to get wpa in Debian and Ubuntu in sync as much as I can | 09:37 |
| andrewsh | ideally, zero delta | 09:37 |
| andrewsh | unfortunately, it seems there’s a been a divergence since late 2019 | 09:38 |
| andrewsh | with patches being cherry-picked from the upstream in a different order and under different names | 09:38 |
| seb128 | andrewsh, hey, the patch was already in Debian I think when I cherry picked it no? | 09:45 |
| seb128 | andrewsh, I'm not really maintaining that package, juliank had been doing most of the uploads in the past, I just helped landing some fixes | 09:46 |
| seb128 | andrewsh, but yeah, agreed, it needs to be merged with Debian and ideally be in sync, I will try to work on that and try to think ask you/forwarding requests to Debian | 09:47 |
| * juliank has not done any wpa work this cycle IIRC | 09:47 | |
| juliank | seb128: you basically did almost all the cherry picks after my merge in 2019, but I guess you don't have a full mind map of them either and it doesn't matter who merges | 09:51 |
| juliank | andrewsh: We should merge such that we get back to the delta in 1ubuntu1 | 09:51 |
| juliank | I think you mentioned that the session ticket patch might not be needed anymore, but then I have no idea about that | 09:52 |
| juliank | the other patch being the one adding IgnoreOnIsolate=yes | 09:53 |
| juliank | the rest is just git cherry-picks and security fixes, not intentional delta | 09:54 |
| andrewsh | seb128: well, yes you did, but since they all live under their own names in d/patches, it’s difficult to tell what is Ubuntu shipping what Debian isn’t | 09:54 |
| andrewsh | (I’m comparing patch series right now) | 09:55 |
| andrewsh | juliank: yeah, I see that, but it would have been so much better if at least the current release was worked on in Debian first or in sync | 09:55 |
| andrewsh | I haven’t been paying attention to Ubuntu packages for some time and now — bam! — there’s a delta :) | 09:56 |
| juliank | some people just don't care about forwarding :) | 09:56 |
| juliank | um :( | 09:56 |
| andrewsh | re IgnoreOnIsolate=yes: I’m curious whether it is useful in Debian or not | 09:57 |
| juliank | andrewsh: just be happy it's not grub2, that's at 2.04-1ubuntu39 atm | 09:57 |
| * juliank dreads the day that will have to be merged | 09:58 | |
| JackFrost | > debian-installer, live-build | 09:58 |
| andrewsh | guess why Apertis switched to Debian from Ubuntu | 09:58 |
| juliank | JackFrost: those are fine, they don't get merged :D | 09:58 |
| andrewsh | not only we had to deal with Apertis to Debian delta, but also with Apertis to Ubuntu to Debian delta :D | 09:59 |
| JackFrost | Yeah Ubuntu is on a *really* old version of live-build. | 09:59 |
| juliank | JackFrost: it's really just a fork of live-build that we use tiny bits of for building images | 10:00 |
| juliank | andrewsh: you shouldn't have to deal with the ubuntu to debian delta because well your base isn't debian, but ubuntu :D | 10:00 |
| juliank | that's like you saying you want to migrate from Debian to building from scratch because you otherwise not only have to deal with the derivative - debian delta, but also the debian - upstream delta | 10:01 |
| juliank | With the difference being that the ubuntu-debian delta is much smaller than the debian-upstream one | 10:01 |
| juliank | Also Apertis being based on Ubuntu means either there was a paid contract in place to allow redistribution of Ubuntu binaries, they were redistributed without a license, or you had to rebuild them all from source and remove ubuntu trademarks | 10:04 |
| juliank | OTOH, with Debian you gotta be super careful about not violating software patents, because of the "if nobody sued us, we don't care" policy | 10:08 |
| * juliank hates software patents | 10:08 | |
| * juliank also is super strict with legal, but in surprising ways that don't necessarily match the intention of the licenses | 10:12 | |
| * juliank has a personal Android app that does ship all the necessary legal notices in a copyright-format file inside the apk, but no way to view that file in the app | 10:13 | |
| juliank | (which is the opposite of the other app's incomplete notices that are visible; it's arguably technically more correct) | 10:14 |
| juliank | Then like I'm the person who'd file take down notices against archive.org for mirroring my website | 10:15 |
| juliank | Anyhow back to the topic of wpa patches | 10:16 |
| juliank | andrewsh: So I spent like 2 minutes and merged the branches back together | 10:20 |
| juliank | andrewsh: The additional patches we have that you don't are the | 10:21 |
| juliank | git_roaming_interface.patch | 10:21 |
| juliank | nl80211-Unbreak-mode-processing-due-to-presence-of-S.patch | 10:21 |
| juliank | git_dbus_bridge.patch | 10:21 |
| juliank | (in addition to those two already known ones) | 10:21 |
| andrewsh | juliank: yeah, I merged those in too already | 10:24 |
| juliank | eww, all my uploads yesterday need new glibc | 10:30 |
| juliank | eww | 10:30 |
| juliank | andrewsh: Dropping debian/patches/session-ticket.patch is something I'm happy to do in May if you think that this is something that was fixed in a different way, but I don't want to do it in the final third of the cycle; especially during a pandemic where people don't travel much and only see their home APs :( | 10:32 |
| andrewsh | juliank: sure | 10:33 |
| andrewsh | what about IsolateSomething | 10:33 |
| andrewsh | would it be useful in Debian? would it harm? | 10:34 |
| juliank | andrewsh: I don't really know, I guess it's useful if you go into single user mode and still have working wifi if all you have is wifi? (I think it would have that effect?) | 10:35 |
| juliank | Does it do harm? | 10:37 |
| juliank | I didn't hear any complaints | 10:37 |
| juliank | but I'm not subscribed to wpa bugs | 10:38 |
| juliank | anyhow this is already a lot cleaner now https://launchpad.net/ubuntu/+source/wpa/2:2.9.0-17ubuntu1 | 10:38 |
| juliank | Can't wait for -18ubuntu1 :D | 10:38 |
| andrewsh | probably more like -19ubuntu1 :) | 10:40 |
| juliank | andrewsh: and whee, it FTBFS | 10:42 |
| juliank | on ppc64el and s390x | 10:42 |
| juliank | amd64 was fine :( | 10:43 |
| juliank | ../src/p2p/p2p.c:1459:21: error: writing 2 bytes into a region of size 1 [-Werror=stringop-overflow=] | 10:43 |
| juliank | 1459 | p2p->op_reg_class = p2p->cfg->op_reg_class; | 10:43 |
| juliank | so odd | 10:45 |
| juliank | This file was not touched by patch changes, so I don't know | 10:47 |
| juliank | waiting for arm* results | 10:47 |
| juliank | arm64 is ok | 10:53 |
| juliank | Both LHS and RHS are "u8 op_reg_class" | 10:57 |
| juliank | doko: is there a compiler bug on ppc64el/s390x, did osmething change there? | 10:57 |
| juliank | see backlog to 11:42 | 10:57 |
| juliank | p2p->op_reg_class = p2p->cfg->op_reg_class is just assigning to a member of a struct pointer | 10:58 |
| juliank | ending up with: error: writing 2 bytes into a region of size 1 [-Werror=stringop-overflow=] seems like completely off | 10:58 |
| doko | juliank: unlikely. could you try to build with -O3 on amd64 as well? | 10:58 |
| juliank | doko: it also fails on 390x, which is -O2 too | 10:59 |
| doko | yes, and uses more aggressive inlining by default | 10:59 |
| andrewsh | juliank: builds on Debian :) | 11:00 |
| juliank | doko: yup, fails with -O3 on amd64 | 11:01 |
| juliank | let's try wpa from release pocket | 11:01 |
| doko | andrewsh: s390x has a lower baseline in Debian, ppc64el defaults to -O2 in Debian | 11:03 |
| juliank | doko: So I added _Static_Assert that both operands are sizeof() == 1, which passed, but it then errors out | 11:06 |
| juliank | so this is super weird | 11:06 |
| juliank | I'm going to pop patches now and see if I can get it to build | 11:06 |
| juliank | doko: Heh no, actually the static assert makes it work, so definitely triggering a compiler bug | 11:08 |
| juliank | But this is too hard to forward | 11:08 |
| andrewsh | doko: oh, interesting | 11:10 |
| seb128 | juliank, thanks for the wpa merge | 11:13 |
| juliank | Should I build it at -O1 on ppc64el/s390x to workaround it? | 11:14 |
| juliank | I don't want to know what code it generates that it lands at that error :D | 11:14 |
| juliank | ../src/p2p/p2p.c:1457:21: warning: writing 2 bytes into a region of size 1 [-Wstringop-overflow=] | 11:22 |
| juliank | oh I see | 11:22 |
| juliank | Old release had it as warning, new one as error | 11:24 |
| juliank | It's building with -Werror now | 11:25 |
| juliank | wpa_supplicant/Makefile | 11:26 |
| juliank | 181:CFLAGS += -Werror -DEAPOL_TEST | 11:26 |
| juliank | andrewsh: So it fails on ppc64el/s390x because CONFIG_EAPOL_TEST is now set | 11:27 |
| juliank | andrewsh: Which enables -Werror, which is clearly wrong | 11:27 |
| juliank | So we gotta patch that out I believe | 11:28 |
| juliank | because it violates common sense to build distribution packages with -Werror in any case | 11:29 |
| juliank | CONFIG_EAPOL_TEST says "development testing" | 11:29 |
| juliank | then we can also drop -Wno-error=array-bounds $(warning WARNING: Building with -Wno-error=array-bounds) | 11:31 |
| juliank | otoh, super security relevant, so maybe keeping werror on is actually useful? | 11:35 |
| juliank | wondering who actually does wpa on ppc64el and s390x :D | 11:45 |
| juliank | I passed -Wno-error=stringop-overflow -Wno-error=format-truncation for now | 11:49 |
| === Spads_ is now known as Spads | ||
| andrewsh | juliank: oh | 12:14 |
| andrewsh | juliank: I guess eapol-test can have its own cflags | 12:15 |
| andrewsh | juliank: | 12:30 |
| andrewsh | cp -v --remove-destination $(WPASUPPLICANT_DOT_CONFIG) wpa_supplicant/.config | 12:30 |
| andrewsh | + CFLAGS="$(CFLAGS) -Wno-error=stringop-overflow -Wno-error=format-truncation" \ | 12:30 |
| andrewsh | dh_auto_build --sourcedirectory=wpa_supplicant \ | 12:30 |
| juliank | andrewsh: Standard policy is to never build distribution packages with -Werror and patch it out of upstreams if they force it | 12:32 |
| juliank | andrewsh: because that stuff means that if a compiler introduces a new warning you get FTBFS on rebuilds and that sucks | 12:33 |
| juliank | andrewsh: I added those options globally for now, but I think a patch to remove -Werror from wpa_supplicant/Makefile is the right approach longer term at least | 12:34 |
| andrewsh | ...or adding -Wno-error :) | 12:53 |
| andrewsh | ...before the Debian-specific cflags | 12:54 |
| andrewsh | hmm, it didn’t work | 13:21 |
| rbasak | cjwatson, wgrant: may I have an ack from one of you please on the changes file header additions I intend to start using in git-ubuntu? I've had no response to my post on vcs-pkg-discuss@ at the Debian end, and I think the Ubuntu thread is concluded. | 13:27 |
| rbasak | AFAICT, Launchpad isn't affected, but I'd appreciate your consideration for any future foot-shooting I may be doing here. | 13:28 |
| andrewsh | juliank: pushed some commits | 13:35 |
| juliank | andrewsh: I was surprised the -Wno-error=... bars worked, despite coming before -Werror, also scared if -Wno-error would have disabled -Werror=string-format thingy | 13:49 |
| juliank | andrewsh: commits lgtm | 13:50 |
| andrewsh | juliank: maybe they didn’t :D | 13:54 |
| andrewsh | I didn’t test on Ubuntu s390x builders | 13:54 |
| juliank | andrewsh: they do work, but it was odd, I'd have expected -Werror to override any former -Wno-error | 13:55 |
| andrewsh | hmm | 13:55 |
| andrewsh | interesting | 13:55 |
| andrewsh | reformulated the package descriptions | 13:55 |
| andrewsh | "IEEE 802.11 AP and IEEE 802.1X/WPA/WPA2/EAP Authenticator" is really *not* the best possible way to describe what hostapd does | 13:56 |
| doko | rbalint: Setting up systemd (247.3-1ubuntu2) ... | 14:20 |
| doko | cp: '/etc/resolv.conf' and '/run/systemd/resolve/stub-resolv.conf' are the same file | 14:20 |
| doko | $ ls -l /etc/resolv.conf /run/systemd/resolve/stub-resolv.conf | 14:22 |
| doko | lrwxrwxrwx 1 root root 39 Nov 11 09:54 /etc/resolv.conf -> ../run/systemd/resolve/stub-resolv.conf | 14:22 |
| doko | -rw-r--r-- 1 systemd-resolve systemd-resolve 746 Feb 2 12:05 /run/systemd/resolve/stub-resolv.conf | 14:22 |
| andrewsh | a bit of an off-topic question: is it possible to update non-core packages in the LTS Ubuntu? | 14:31 |
| andrewsh | more specifically, I’m interested in debos | 14:31 |
| andrewsh | juliank: pkgconf is in universe, pkg-config is in main, will it make difference for Ubuntu if I start preferring (with |) pkgconf? | 14:38 |
| cjwatson | You'd want to look at https://wiki.ubuntu.com/StableReleaseUpdates to start with | 14:45 |
| cjwatson | Core or non-core isn't necessarily a controlling factor | 14:45 |
| cjwatson | rbasak: I will queue it up to think about, but I think this is probably best done without an annoying low-level headache | 14:47 |
| andrewsh | cjwatson: well, my understanding is that updating a leaf package has less potential of introducing breakage | 14:53 |
| cjwatson | andrewsh: Agreed in general, but I'm not active in reviewing SRUs these days so all I can do is point you at the docs | 14:55 |
| === lucas_ is now known as Guest82362 | ||
| andrewsh | juliank: if the pkgconf | pkg-config change makes things inconvenient for you, please shout | 15:06 |
| juliank | andrewsh: were allowed to use universe stuff during build, just not link to it or depend on it from the binaries | 15:16 |
| andrewsh | ack | 15:23 |
| andrewsh | pkgconf/pkg-config is purely a build dependency | 15:23 |
| Eickmeyer | tseliot: Hi! Thanks for the info. The problem is that there seems to be an incompatibility and nvidia-smi seems to be failing. The only explanation we could come up with is that nvidia-settings and nvidia-modprobe aren't matching. | 15:58 |
| tseliot | Eickmeyer, all nvidia-modprobe does is load modules, and create devices. nvidia-smi calls that, when available. I'm not sure what the error is. | 16:01 |
| Eickmeyer | tseliot: I'm not sure what the error is either. I'll probe deeper. | 16:02 |
| Eickmeyer | tseliot: Just figured it out. '/usr/bin/nvidia-modprobe: unrecognized option: "-s"' | 16:03 |
| Eickmeyer | That's what happens when I run nvidia-smi. | 16:03 |
| tseliot | Eickmeyer, maybe try nvidia-modprobe from hirsute | 16:05 |
| Eickmeyer | tseliot: Yeah, that might be the only option, but this is affecting the OEM that I work for that uses focal. | 16:06 |
| tseliot | Eickmeyer, you can rebuild the one from hirsute in focal | 16:07 |
| Eickmeyer | tseliot: I actually just installed the .deb and everything seems to work fine. This might require a backport. | 16:08 |
| Eickmeyer | I'm a MOTU, so I can help if you would like. | 16:08 |
| tseliot | Eickmeyer, it's in multiverse, so it's not something that we support | 16:09 |
| Eickmeyer | tseliot: Right, which means I should be able to sponsor the backport myself and ping the living junk out of people like teward. | 16:10 |
| Eickmeyer | (for reasons) | 16:11 |
| tseliot | yes, it shouldn't be a problem | 16:11 |
| Eickmeyer | tseliot, teward (because reasons): LP# 1915534 | 16:58 |
| Eickmeyer | LP: #1915534 | 16:58 |
| ubottu | Launchpad bug 1915534 in nvidia-modprobe (Ubuntu Groovy) "Please backport nvidia-modprobe 460.32.03-1 (multiverse) from hirsute" [Undecided,New] https://launchpad.net/bugs/1915534 | 16:58 |
| teward | Eickmeyer: not sure why you have Focal and Groovy tasks - backports won't trigger those 'fix released' items i don't think | 17:04 |
| teward | since backports sits outside the standard updates process | 17:05 |
| Eickmeyer | My SRU instincts kicked-in. | 17:05 |
| Eickmeyer | (removed now) | 17:06 |
| Eickmeyer | teward: My question is, is anyone even working on backports? | 17:08 |
| teward | not really, but getting things into backports isn't *too* hard if there's valid reason for it | 17:09 |
| teward | the problem is the way backports have been *anyone* can request backports. | 17:09 |
| teward | so there's always been burnout | 17:09 |
| Eickmeyer | I see. | 17:09 |
| teward | and the proposal I made a year or more ago hasn't been put into effect yet. | 17:09 |
| teward | because things kind of got problematic | 17:09 |
| teward | so i haven't chased it | 17:09 |
| Eickmeyer | Well, considering I'm working on behalf of an OEM making an official request, I wonder if that would have some influence. | 17:12 |
| teward | maybe. but i'm always hesitant touching anything from 'restricted' or 'multiverse' | 17:14 |
| teward | the main reason for this is because backports still need someone to actually keep an eye on the package and opt to keep it updated with security etc. | 17:15 |
| teward | because that's a Big Thing | 17:15 |
| juliank | Shouldn't this be SRUed? | 17:16 |
| teward | it probably SHOULD | 17:17 |
| teward | which requires Kernel and Foundations to look at it | 17:18 |
| teward | Eickmeyer: backports to fix bugs is not the proper approach ;P | 17:18 |
| juliank | Either backport all of nvidia-modprobe as an SRU (the changes are small and probably necessary for the full 460 stack that's in focal), or just the fix to add -s | 17:19 |
| teward | i'm more concerned that the 460 stack can't install as is currently in this system o.O | 17:20 |
| teward | and it's a 20.04 system AND ubuntu-drivers LISTS it as a viable driver | 17:20 |
| juliank | teward: you don't need nvidia-modprobe for normal operatio nafaict | 17:21 |
| teward | that i believe | 17:21 |
| teward | i still however can't install the 460 stack ;) | 17:21 |
| juliank | oh well | 17:21 |
| teward | juliank: this should still be SRU'd, however as it's Multiverse i'm not touching it with a 20 foot pole ;) | 17:23 |
| teward | not without the relevant teams evaluating the SRU first | 17:24 |
| teward | but as a backport to fix a bug that doesn't make sense for -backports | 17:24 |
| juliank | teward: it's completely free software though, it's a Debian contrib package, so the diff is easy to review :D | 17:25 |
| juliank | but yeah, kernel sdhould have a look I guess, I don't know | 17:25 |
| teward | juliank: perhaps, but given the... i'll call it 'fiasco' of the 20.04.2 fallout of the HWE stack, I'd still like kernel to look at it | 17:25 |
| juliank | ack | 17:26 |
| teward | because I have *no idea* if this actually requires the HWE stack or not or such, or the minimum required kernel version for compat, etc. | 17:26 |
| teward | whereas Kernel team does know | 17:26 |
| juliank | tseliot: ^ https://bugs.launchpad.net/ubuntu/+source/nvidia-modprobe/+bug/1915534 | 17:29 |
| ubottu | Launchpad bug 1915534 in nvidia-modprobe (Ubuntu) "Please SRU nvidia-modprobe 460.32.03-1 (multiverse) from hirsute" [Undecided,New] | 17:29 |
| * juliank renamed from backport to SRU | 17:30 | |
| Eickmeyer | teward: juliank: Do you think I should reformat it as an SRU then? | 17:35 |
| juliank | I'd wait for feedback before putting in the work | 17:35 |
| teward | well you DO need to put the SRU template in place yes | 17:35 |
| teward | at the very least | 17:35 |
| Eickmeyer | Can do. | 17:35 |
| teward | and then wait for feedback | 17:35 |
| juliank | also describing what the problem actually is would be helpful | 17:35 |
| juliank | like what does that script do, how does it fail, and why is that bad for the user | 17:36 |
| juliank | and for which users | 17:36 |
| Eickmeyer | Basically, anyone using nvidia-smi is the issue here. | 17:36 |
| juliank | Eickmeyer: remember that SRU team are not domain experts and have no idea what nvidia-smi is or does | 17:37 |
| Eickmeyer | juliank: I included text from the help output for that reason in the SRU. | 17:43 |
| Eickmeyer | juliank, teward, tseliot: Uploaded, awaiting approval. | 17:47 |
| === ijohnson is now known as ijohnson|lunch | ||
| === lucas_ is now known as Guest12216 | ||
| === ijohnson|lunch is now known as ijohnson | ||
| teward | juliank: i wouldn't be surprised if Kernel is asked to comment on the bug though from Eickmeyer, because it needs to be compatible with the kernels available in the target releases. In the off chance these changes can't work or not with older releases. :P | 21:36 |
| Eickmeyer | teward: It is, it doesn't contain any actual binary drivers. | 21:37 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!