| ogayot | Hi, could someone retrigger the failed cmake autopkgtest for me please? I'd appreciate it | 09:02 |
|---|---|---|
| ogayot | `retry-autopkgtest-regressions --series lunar | grep -F package=cmake` | 09:02 |
| seb128 | ogayot, retried | 09:04 |
| seb128 | or not, got some timeout it seems :/ | 09:04 |
| ogayot | seb128: thanks for trying! Sadly I've hit timeouts a couple times too this morning | 09:07 |
| ginggs | it should be safe to run that script again after a few minutes, it should not schedule things that are already in the queue | 09:10 |
| seb128 | 👍 | 09:11 |
| Eickmeyer | mapreri: Some very light reading for you: bug 1999524 :) | 15:14 |
| -ubottu:#ubuntu-devel- Bug 1999524 in scribus (Ubuntu) "Fix build for Poppler 22.09" [Undecided, Triaged] https://launchpad.net/bugs/1999524 | 15:14 | |
| === cpaelzer_ is now known as cpaelzer | ||
| juliank | I don't remember, did we have a build-profile for ubuntu-specific build dependencies? | 15:42 |
| schopin | If we do that's news to me, but that sounds like a good idea. | 15:44 |
| juliank | Now I'm mostly wondering if we made apt use Rust libraries and needed them packages as individual packages in Debian but vendored in Ubuntu, could we just have them in an apt-rust-sources package | 15:44 |
| schopin | juliank: remind me again which Rust lib you're interested in? | 15:54 |
| juliank | schopin: sequioa | 15:54 |
| schopin | juliank: but you'd use it from C (or C++), right? So basically what you'd want to depend on in APT would be a libsequoia-dev | 15:55 |
| schopin | Apparently sequoia has a FFI so it would make sense to actually build it as a .so in the distro. | 15:56 |
| juliank | schopin: I thought so but the Rust people said I should write my own Rust wrapper | 15:57 |
| schopin | Which Rust people? The #debian-rust people or the sequoia people? | 15:57 |
| juliank | schopin: the rust sequoia people | 16:26 |
| schopin | What's the point of flaunting an FFI if we're supposed to write a Rust wrapper? -_-' | 16:27 |
| === franksmcb_ is now known as franksmcb | ||
| === nicolasbock_ is now known as nicolasbock | ||
| === sforshee_ is now known as sforshee | ||
| murmel | Eickmeyer: so :)? | 18:42 |
| murmel | would definitely like to hear the reasoning | 18:43 |
| Eickmeyer | murmel: I mean, from even more senior developers than myself. | 18:43 |
| murmel | eh, and your take? | 18:43 |
| murmel | because, it holds up quite a bit when you want to package stuff for newer releases | 18:44 |
| Eickmeyer | Backporting (or an SRU of debhelper) to a stable release of debhelper could introduce breaking changes and change the way debhelper is used in the build system for that particular release, particularly the way it is used in the build system in Launchpad. | 18:44 |
| Eickmeyer | !latest | 18:45 |
| ubottu | Packages in Ubuntu may not be the latest. Ubuntu aims for stability, so "latest" may not be a good idea. Post-release updates are only considered if they are fixes for security vulnerabilities, high impact bug fixes, or unintrusive bug fixes with substantial benefit. See also !backports, !sru, and !ppa. | 18:45 |
| Eickmeyer | We keep things Stable for a reason. | 18:45 |
| Eickmeyer | So, unless there's a specific bug that needs to be fixed in debhelper, there's no reason to backport. | 18:45 |
| Eickmeyer | If you want to package stuff for newer releases, package it *in* that newer release. | 18:46 |
| murmel | Eickmeyer: why even offer -backports then? I mean just run the newer release then | 18:48 |
| Eickmeyer | murmel: For updates to applications, not development components. | 18:48 |
| murmel | Eickmeyer: pretty sure that even the -backports team sees this differently (specifically debhelper) | 18:49 |
| Eickmeyer | Well, then the backports team is welcome to chime-in. I'm not on the backports team, but I know some that are. ddstreet and teward for example. | 18:50 |
| Eickmeyer | That said, even a backport of debhelper could potentially break the entire backports repo. | 18:51 |
| murmel | oO how would that work ? | 18:52 |
| Eickmeyer | Remember, the packages have to build against everything in the repository they are entering. | 18:52 |
| Eickmeyer | So, we're talking no-change rebuilds for everything that's in there for a new debhelper version. | 18:52 |
| murmel | Eickmeyer: debhelper is not depending on anything, and nothing depends on it (as packages depend on the compat part) | 18:54 |
| Eickmeyer | debhelper is a build dependency for everything. | 18:54 |
| arraybolt3 | And keep in mind Britney doesn't exist in -backports, which adds to the danger. At least for -updates, Britney can control the migration of stuff out of -proposed so that it doesn't break people's systems as it builds and migrates. -backports? No such safety mechanism. | 18:54 |
| murmel | debhelper-compat = 13 is not debhelper | 18:54 |
| Eickmeyer | debhelper-compat merely defines the debhelper version it's compatible with, and debhelper along with it. | 18:55 |
| Eickmeyer | If you don't understand that, go back and re-read the Debian packaging manual. | 18:55 |
| murmel | brb in 25 mins | 18:56 |
| Eickmeyer | Also, Debian/rules executes dh directly, which is literally debhelper. | 18:56 |
| arraybolt3 | (What have I started... I went to study something for a request to see if it was safe and doable and now have sparked an explosion...) | 18:57 |
| ahasenack | juliank: any idea why apt-check would call lsb_release so many times? apt-check's pid is 352917 (line 39 of paste), and that's the PPID of every lsb_release call following that: https://paste.ubuntu.com/p/FKzBZ3k4nZ/ | 18:59 |
| ahasenack | # grep -E exec.*lsb_release apt-check.strace | wc -l | 19:00 |
| ahasenack | 856 | 19:00 |
| sarnold | ow | 19:01 |
| ahasenack | # time /usr/lib/update-notifier/apt-check --human-readable | 19:01 |
| ahasenack | 214 updates can be applied immediately. | 19:01 |
| ahasenack | To see these additional updates run: apt list --upgradable | 19:01 |
| ahasenack | real 0m7.877s | 19:01 |
| Eickmeyer | arraybolt3: Matrix DMs | 19:01 |
| sarnold | watching execsnoop or opensnoop while apt is doing things is always a mixture of impressive and depressing | 19:01 |
| ahasenack | sarnold: same for logging in, all the stuff that runs! ;) | 19:02 |
| sarnold | ahasenack: ugh yeah, especially in the days before the motd caching stuff.. | 19:04 |
| arraybolt3 | sarnold: lol @ impressive and depressing | 19:07 |
| sarnold | :) | 19:08 |
| arraybolt3 | TBF though, I'd guess most stuff in the guts of a computer are like that. It's awesome how many pieces have to work together just right for things to happen the way they're supposed to. | 19:08 |
| sarnold | oh yes, I'm shocked computers work well enough to get to a login: prompt these days | 19:10 |
| ahasenack | imagine looking at the assembly code of an apt-get update run | 19:10 |
| ahasenack | then you know where all those gigaherz go | 19:11 |
| sarnold | cpu goes 'zzzz' waiting for ram | 19:12 |
| Eickmeyer | sarnold: That's me waiting for coffee. | 19:18 |
| arraybolt3 | That's me waiting for a PPA to finish publishing a package right now. | 19:18 |
| ahasenack | I don't see that crazy amount of calls to lsb_release in kinetic | 19:18 |
| ahasenack | just one call to lsb_release -cs, actually | 19:19 |
| ahasenack | but less updates available (still about a dozen, not just one) | 19:19 |
| arraybolt3 | (Speaking of coffee, /me now thinks about getting a second cup of said energy boost) | 19:20 |
| Eickmeyer | arraybolt3: Don't turn into teward, kthx | 19:21 |
| sarnold | lol | 19:22 |
| * arraybolt3 thunks Eickmeyer with the Nuclear Waffle Iron | 19:22 | |
| teward | i was pinged? | 19:22 |
| * arraybolt3 thunks teward with the Nuclear Waffle Iron | 19:22 | |
| teward | *bans arraybolt3 for !offtopic* | 19:23 |
| Eickmeyer | teward: Twice, once with a backport topic. | 19:23 |
| teward | Eickmeyer: because i'm still in the middle of stuff want to give me the quick overview of what's up? | 19:23 |
| Eickmeyer | teward: Brief backscroll, but person requesting backport of debhelper (solid no imo). | 19:23 |
| teward | you don't read | 19:24 |
| teward | https://wiki.ubuntu.com/UbuntuBackports#Special_Cases | 19:24 |
| teward | learn to read documentation Eickmeyer | 19:24 |
| murmel | Eickmeyer: sorry was kicked out of a store (closed for today). so rereading about the compat profiles, there are no breaking changes in those. so it shouldn't matter which version version of debhelper you are running as long as you have defined the correct compat profile | 19:24 |
| teward | we update that on the regular since we're building things today | 19:24 |
| teward | murmel: if you want something in -backports your request has to go to the Backporters team | 19:24 |
| teward | which Eickmeyer is not a member | 19:24 |
| teward | see https://wiki.ubuntu.com/UbuntuBackports | 19:24 |
| Eickmeyer | teward: murmel wants it in Jammy, which is LTS. | 19:25 |
| arraybolt3 | teward: Pretty sure he wanted debhelper in Jammy. | 19:25 |
| murmel | teward: we are talking about debhelper being in -backports or not | 19:25 |
| teward | myself, ddstreet, and mapreri review these requests and decide on our own | 19:25 |
| teward | we make the final decision for -backports | 19:25 |
| teward | that's under the purview of the Backporters team | 19:25 |
| teward | this said | 19:25 |
| teward | as you can see two things from the special cases section: | 19:25 |
| teward | "The following packages are allowed into the backports pockets of non-LTS releases, because they are deemed useful to always be available on the latest possible release." | 19:25 |
| teward | also | 19:25 |
| teward | "At the moment these 5 packages are handled by the Backport Team themselves. " | 19:26 |
| teward | this was a decision made in our earliest meetings | 19:26 |
| teward | if you want the Backports team to consider changing this, emails to the backports team is required and it will be discussed at the next meeting or internally depending on availabliity | 19:26 |
| Eickmeyer | teward: To be clear, I was not speaking on your behalf, but as someone who might be requested to sponsor. | 19:26 |
| teward | Eickmeyer: in which case you get a slap for not reading the docs anyways ;) | 19:27 |
| teward | you're my scapegoat today (normally it's Simon but he's away) | 19:27 |
| teward | ANYWAYS, back to the red-alert level crap for $DAYJOB law enforcement partners. | 19:27 |
| murmel | teward: so do I need to request to get debhelper into jammy? or is it done "at some point"? | 19:27 |
| sarnold | you're just playing command and conquer over there?? | 19:27 |
| Eickmeyer | sarnold: When is he not? | 19:30 |
| sarnold | lol | 19:30 |
| arraybolt3 | There's a reason we give him all things sysadmin over in Lubuntu-land and we stay out of it for the most part. He's really good at total control of his area of mastery. | 19:30 |
| * arraybolt3 yawns and goes back to testing a bugfix | 19:35 | |
| * sarnold yawns and goes back to tasting a bug | 19:35 | |
| teward | murmel: you can request it, but don't be surprised if we reject the request per our exceptions policy/rules, or if we say "we agree and will get to it within X timeframe" then one of the backporters will handle the package. However, regardless of the outcome, you have to **provide significant ample justification for the need for a backport**. debhelper usually ISN'T backported because most packages can simply change their targeted | 19:35 |
| teward | compat | 19:35 |
| teward | if they need to be backported. | 19:35 |
| teward | sarnold: incoming bugspam | 19:35 |
| arraybolt3 | sarnold: I've eaten grasshoppers before, they're pretty good roasted. | 19:35 |
| * sarnold hides behind procmail | 19:35 | |
| sarnold | arraybolt3: lol | 19:35 |
| sarnold | *maybe* with the right spicy sauce or something.. | 19:36 |
| murmel | teward: thanks :) | 19:36 |
| teward | murmel: also keep this in mind: | 19:38 |
| teward | if something *cannot* build on the older verison of dev libraries without an additional backport, it's probably *not* worth a backport | 19:38 |
| teward | debhelper for instance is one of those dev libraries that's usually left alone | 19:38 |
| teward | even in Debian backports | 19:38 |
| murmel | teward: oO how is it left alone when it always gets backported in debian? | 19:44 |
| teward | i've seen a case or two where it's NOT in the debian backports pockets | 19:44 |
| teward | however in Ubuntu we tend to leave it alone | 19:45 |
| teward | as i said, make your request, you'll get the backporters team response by the next meeting. | 19:45 |
| teward | however i am currently in the middle of some major stuff so i can't put any more cycles to this at the moment | 19:45 |
| murmel | teward: thanks :). no need anyway | 19:45 |
| === tomreyn_ is now known as tomreyn | ||
| arraybolt3 | Possibly silly question, but if I want to use "dput ssh-ubuntu" to upload something, I get a warning about a host key not being recognized or something (the usual thing you get when you first try to connect to a new SSH server). Is the host key for Launchpad documented anywhere so I can know I'm not about to expose anything important to a malicious third party? | 19:54 |
| arraybolt3 | (I don't know if ssh-ing into the wrong machine is dangerous, but I'd rather not find out the hard way.) | 19:54 |
| rbasak | arraybolt3: https://help.launchpad.net/SSHFingerprints | 19:57 |
| arraybolt3 | rbasak: Thanks, that looks like exactly what I was looking for. | 19:59 |
| ahasenack | I filed https://bugs.launchpad.net/ubuntu/+source/update-notifier/+bug/1999566 for the lsb_release barrage | 20:04 |
| -ubottu:#ubuntu-devel- Launchpad bug 1999566 in update-notifier (Ubuntu) "[lunar] Hundreds of calls to lsb_release from apt-check" [Undecided, New] | 20:04 | |
| jbicha | teward: btw, debhelper does have a history of being in backports for Ubuntu: https://launchpad.net/ubuntu/+source/debhelper | 20:42 |
| enr0n | Can a core dev please retry the autopkgtests blocking systemd in lunar (except one)? retry-autopkgtest-regressions --blocks systemd -s lunar | grep -v prometheus-ipmi-exporter | 20:42 |
| enr0n | The excluded one looks like it needs a migration-reference/0 test | 20:44 |
| teward | jbicha: true, but note that Backporters handles that package itself | 20:44 |
| teward | so while technically you're right, it's not something that the Backports team currently lets "anyone" backport. | 20:45 |
| teward | lots of testing, etc. | 20:45 |
| arraybolt3 | Are autopkgtests a thing in a PPA? I have a package that contains deliberate changes that entirely break an autopkgtest for a particular package - this is on purpose because I'm testing something. If autopkgtests are used in PPAs, will their failure prevent the package in question from being usable? | 20:45 |
| teward | arraybolt3: you can trigger autopkgtests against a PPA but it shouldn't impact the actual packages in proposed, etc. | 20:45 |
| teward | i don't think there's automatic triggering though | 20:45 |
| arraybolt3 | +1, alright, will attempt chaos to see if I can get things sorted out. | 20:45 |
| teward | or if there is i don't think it's available for $everyone | 20:45 |
| === pizzaiolo is now known as pizza | ||
| enr0n | Can a MOTU or core dev please sponsor bug 1999574? It is a simple cherry pick from upstream to resolve prometheus-ipmi-exporter autopkgtest | 21:31 |
| -ubottu:#ubuntu-devel- Bug 1999574 in prometheus-ipmi-exporter (Ubuntu) "autopkgtest fails due to API change in prometheus exporter-toolkit" [Undecided, New] https://launchpad.net/bugs/1999574 | 21:31 | |
| === cengizIO is now known as cengiz_io | ||
| bdmurray | enr0n: Is there a corresponding debian bug? | 22:05 |
| enr0n | bdmurray: not an existing one no, but I usually submit to debian afterwards | 22:06 |
| bdmurray | enr0n: okay, I won't worry about the order of operations | 22:09 |
| bdmurray | enr0n: uploaded | 22:36 |
| enr0n | bdmurray: awesome, thanks! | 22:36 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!