| vorlon | arraybolt3: not sure that it got missed, kinetic queue processing may just have been slow for the past few weeks. I see several other packages age 4weeks in the queue which is a good indicator | 01:03 |
|---|---|---|
| vorlon | I'm not putting my SRU hat on today to process these I'm afraid | 01:03 |
| arraybolt3 | Ah, makes sense. Also, I accidentally posted this to the wrong channel :P | 01:03 |
| dannf | cpaelzer: nothing obvious to me, but I'll look a bit closer tomorrow. | 01:30 |
| zhsj | could someone retry these autopkgtest https://paste.ubuntu.com/p/fK3H9k5sXC/ | 02:49 |
| vpa1977 | Hi, would it be possible to retry https://autopkgtest.ubuntu.com/request.cgi?release=lunar&arch=amd64&package=jsurf-alggeo&trigger=openjdk-17%2F17.0.6%2B10-1 ? I have ran autopkgtest locally against lunar vm and it passes | 06:13 |
| vpa1977 | Hi, would it be possible to retry https://autopkgtest.ubuntu.com/request.cgi?release=lunar&arch=arm64&package=fdroidserver&trigger=openjdk-17%2F17.0.6%2B10-1. I have ran it against canonistack instance and it passed | 06:33 |
| ginggs | vpa1977: looking... | 06:50 |
| ginggs | zhsj: . | 06:57 |
| ginggs | vpa1977: . | 06:57 |
| vpa1977 | ginggs: thank you !!!! | 07:00 |
| zhsj | could someone retry https://autopkgtest.ubuntu.com/request.cgi?release=lunar&arch=amd64&package=arno-iptables-firewall&trigger=kmod%2F30%2B20221128-1ubuntu1 i suspect it's testbed related, and other failures on https://autopkgtest.ubuntu.com/packages/a/arno-iptables-firewall/lunar/amd64 are all same. | 10:25 |
| zhsj | is there any chance that net.netfilter.nf_conntrack_helper has random value in an isolated-machine test? | 10:46 |
| adrien | vorlon: huh, sorry, I thought I had removed it from the list; I had put it initially but decided to drop it upon close inspection, except that apparently I failed when editing my message | 11:25 |
| adrien | (long and repetitive links on irc don't really help) | 11:25 |
| adrien | others were: lintian, timed out with the last line being "Building in [snip] [167/1439]"; epson*: timeout during tests; cmake: timeout during tests for one arch and timeout during testbed preparation for the other | 11:26 |
| athos | zhsj: done | 11:27 |
| adrien | the epson* one has been triggered yesterday evening (and succeeded) | 11:27 |
| ahasenack_ | so I got this message from needrestart I think, about the microcode update I just installed: | 13:59 |
| ahasenack_ | "Restarting the system to load the new processor microcode will not be handled automatically, so you should consider rebooting" | 14:00 |
| ahasenack_ | what's the difference between "restarting the system" and "rebooting"? | 14:00 |
| cjwatson | ahasenack_: I don't particularly know this package, but I would read that as a distinction between automatic and manual rebooting, rather than a distinction between two different phrasings of rebooting | 14:24 |
| ahasenack_ | ah, could be | 14:25 |
| ahasenack_ | "you system will not be restarted automatically" | 14:25 |
| ahasenack_ | it should be the same case with a kernel update | 14:25 |
| cjwatson | I'm sure it could use rephrasing | 14:25 |
| ahasenack_ | I don't have the message for that case at hand, though | 14:26 |
| === tomreyn_ is now known as tomreyn | ||
| jawn-smith | bdmurray: I have confirmed that the boost1.81 arm64 test passes reliably locally | 17:41 |
| jawn-smith | going to start 1.74 now | 17:41 |
| bdmurray | vorlon: How do you feel about forcing boost1.81 to migrate given jawn-smith's testing? I had blacklisted it because it was continuously looping an clogging up the queue. | 17:48 |
| vorlon | bdmurray: given the only thing blocking it is a failure that's marked 'blacklisted', I think it's consistent that we would migrate it anyway | 18:23 |
| vorlon | but also, knowing we have good local tests is good | 18:23 |
| jawn-smith | bdmurray: boost1.74 also passed locally | 19:00 |
| === sem2peie- is now known as sem2peie | ||
| arraybolt3 | In the event anyone's interested, I started a channel #ubuntu-sponsors that I think might help future contributors be able to find sponsors for work they've done more easily. Anyone with archive access rights who's interested in possibly getting sponsorship requests is welcome to join. It's pretty new so there's not really any activity yet, and I'm developing it slowly, so it probably won't | 20:09 |
| arraybolt3 | have much activity for a while, but if that sounds cool, there it is. | 20:09 |
| bdmurray | arraybolt3: Is there a reason this channel was deemd inappropriate? | 20:50 |
| bdmurray | It already has a bunch of potential sponsors | 20:50 |
| arraybolt3 | bdmurray: No, I just meant to post in -release where the SRU team hangs out. | 20:50 |
| bdmurray | I mean why have a different ubuntu-sponsors channel instead of using this one. | 20:51 |
| vpa1977 | Hi, would it be possible to retry https://autopkgtest.ubuntu.com/request.cgi?release=lunar&arch=ppc64el&package=fdroidserver&trigger=openjdk-17%2F17.0.6%2B10-1 - the test failed against 2.1.2-1 version of the package, and autopkgtest failures were addressed in 2.2.0-3 which is now in release(universe) | 21:09 |
| mwhudson | vpa1977: done | 21:16 |
| vpa1977 | mwhudson: Thank you !!! | 21:16 |
| arraybolt3 | bdmurray: Oh. I misunderstood. | 21:35 |
| arraybolt3 | bdmurray: I mean this channel works, but it's used for other things frequently enough that it seems easy for a sponsorship request to get missed. My idea was that people would join the room and then if they saw it light up and were ready to help sponsor something, they'd know what was happening rather than being like "oh it's -devel again, I can probably just ignore that". | 21:38 |
| arraybolt3 | (I ignore probably 90% of what happens in here since it has nothing to do with what I work with yet.) | 21:38 |
| sergiodj | hi, would it be possible to add/enable ubuntuwire's reverse-dependency service for Kinetic? | 22:25 |
| sergiodj | I get an "Unkown release" there | 22:26 |
| liushuyu | Hi tjaalton, I am from the Foundations Team, the new Rust toolchain maintainer on the team. I need to upgrade Rust on JJ (22.04) and KK (22.10) however encountered a LLVM bug which was fixed in 15.0.7. I can see you use LLVM 15 for Mesa (HWE stack?), can you help me with upgrading LLVM 15 to 15.0.7 on these two series? Thanks! | 23:37 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!