[04:25] <mwhudson> vorlon: do you happen to remember what happened to your c-ares patch? https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1062032
[04:25] -ubottu:#ubuntu-devel- Debian bug 1062032 in src:c-ares "c-ares: NMU diff for 64-bit time_t transition" [Serious, Open]
[05:18] <vorlon> mwhudson: eh c-ares went weird because the maintainer pointed out that instead of making it t64 we could just fix the existing lintian warning about runtime package name; and I don't remember beyond that
[08:27] <mwhudson> vorlon: the bug says "This patch is being uploaded to unstable." though
[08:27] <mwhudson> maybe i should just upload it
[08:27] <mwhudson> oh boo rdeps
[11:03] <waveform> @pilot in
[11:39] <bluca> could someone please click on retries/migration refs for the test fails of https://ubuntu-archive-team.ubuntu.com/proposed-migration/update_excuses.html#openssh
[11:45] <bdrung> bluca, done
[11:57] <bluca> ta
[12:22] <bdrung> LocutusOfBorg, i fixed autopilot in parallel
[12:22] <LocutusOfBorg> bdrung, thanks!
[12:22] <LocutusOfBorg> please upload because I can't understand the last failure
[12:22] <LocutusOfBorg> :/
[12:23] <bdrung> that took me some time as well. That test has been broken for a long time but only the fix now reveals it.
[12:25] <bdrung> LocutusOfBorg, we have https://pad.riseup.net/p/nbs-noble-keep to coordinate the NBS fixes
[13:36] <ahasenack> looking at libnettle8
[13:36] <ahasenack> hm, it's not in https://ubuntu-archive-team.ubuntu.com/nbs-no-amd64.html, just in the pad
[13:38] <rbasak> kanashiro: is it expected that "apt install resource-agents" now fails on Noble?
[13:38] <rbasak> (feel free to say yes)
[13:39] <ahasenack> yeah, fails with noble-proposed too
[13:39] <ahasenack> maybe athos knows something?
[13:39] <rbasak> It's because there's no transitional package AFAICT.
[13:39] <rbasak> (or Provides)
[13:39] <rbasak> But it might be intentional?
[13:45] <ahasenack> so, issues I can see atm: a) if docs say to install 'resource-agents'; b) if something else in the archive depends on 'resource-agents'
[13:45] <ahasenack> (b) would usually prevent migration, but it might have slipped through
[14:17] <rbasak> Unit193: do you know why paste.ubuntu.com got dropped at https://github.com/pastebinit/pastebinit/commit/5c668fb3ed9b4a103eb22b16e603050a539951e0 please? It still works fine? Noble switches to dpaste.com as a result. Is this intentional?
[14:17] -ubottu:#ubuntu-devel- Commit 5c668fb in pastebinit/pastebinit "Prune dead pastebins, add paste.centos.org, update distro defaults."
[14:33] <tjaalton> how to launch the installer from a terminal? it's not starting up here on a prerelease hw, and I want to know why :)
[14:33] <tjaalton> the gui, desktop is up
[14:38] <tjaalton> 'ubuntu-desktop-bootstrap', seems to be some issue with mounts, as no snap works
[14:47] <Eickmeyer> rbasak: Presumably because paste.ubuntu.com requires a login and a lot of people here on IRC weren't willing to get a SSO account.
[14:49] <Eickmeyer> At least, IIRC, that's how the IRC Ops Team decided at the time.
[14:53] <rbasak> Eickmeyer: OK that makes sense as a reason, but what's that got to do with the IRC Op Team?
[14:53] <Eickmeyer> rbasak: That's who made the decision.
[14:54] <Eickmeyer> Unit193 just made the changes.
[14:54] <rbasak> Is that documented anywhere, and I'm still confused as to what it's got to do with them?
[14:54] <rbasak> Earlier I was wondering whether it was an accident and should add a delta to change it back. I'm still wondering that!
[14:54] <Eickmeyer> Unit193 is on the IRC Council. I don't think it's documented anywhere.
[14:54] <JanC> my guess: when people give support & users are told to use pastebinit, it's really annoying if it doesn't work (OOTB)...
[14:55] <rbasak> OK, so that's a very valid concern as a user, but that's only a subset of the users of this tool.
[14:57] <rbasak> It doesn't make sense for representative of a subset of users to make a decision for the entire set without documenting it and without telling anyone :-/
[14:57] <JanC> you can override the default?
[14:58] <rbasak> On my system. It's a pain to do on every single VM or container I spin up on a regular basis.
[14:58] <JanC> makes sense to have a good default for the users who are least likely to know how to configure it
[14:59] <rbasak> I would prefer for defaults from the Ubuntu archive to use Ubuntu infrastructure when that's available. I accept that a login requirement that exists here but not elsewhere might be good reason to switch the default, but in that case can we make a decision as a team please, not as a subset of one that has a particular agenda?
[15:00] <Eickmeyer> I'd argue that support and customer service trumps that.
[15:00] <rbasak> You're arguing about the decision, not how the decision is made
[15:01] <rbasak> I'm arguing about how it was made, not about the decision itself
[15:01] <Eickmeyer> Ok, then it's a matter of governance. IRC Council is directly under CC.
[15:01] <rbasak> What a tool inside Ubuntu does is clearly not within the remit of the IRC Council - especially when there are non-IRC uses of this tool, too.
[15:02] <Eickmeyer> Then who controls pastebinit?
[15:02] <rbasak> But it shouldn't be necessary to get into that.
[15:02] <rbasak> MOTU.
[15:03] <rbasak> But anyway, we make decisions by consensus. Structure only matters when that's skipped. This doesn't sound like it was consensus.
[15:03] <kanashiro> rbasak uninstallability of resource-agents in noble is not expected, let me check
[15:03] <rbasak> Oh, this is in main, so core devs as part of Ubuntu develoeprs at large I guess.
[15:04] <Eickmeyer> I do see not even a bug was raised regarding this. Concern is definitely valid.
[15:05] <rbasak> Also the reason isn't present in the commit message
[15:05] <rbasak> It seems like it's part of "Prune dead pastebins" and that's wrong here. If I hadn't thought to ask, I might have just added a delta since, as written, it's clearly a mistake.
[15:06] <JanC> change was made upstream though?  maybe *they* changed it after people complained?
[15:06] <rbasak> Also, if we're not going to use it, perhaps it would be nice to tell Canonical so they don't have to bother running the service at all? It's rude not to.
[15:08] <Eickmeyer> I mean, it kinda became useless for support reasons when it got locked down (the requests in #ubuntu which requires it are massive), but I understand your argument.
[15:09] <JanC> it's quite likely *upstream* got direct complaints too
[15:12] <Eickmeyer> JanC: Not likely. It was smart enough to detect which distro you were running and figure out which Pastebin to use therefore. For instance, if you were using Fedore it would use centos's Pastebin, Debian would use Debian's Pastebin, etc.
[15:13] <kanashiro> rbasak now I see what you meant about resouce-agents, this is expected behavior, at this point user should install resource-agents-{base,extra}. resource-agents binary was a transitional package in the previous LTS and was removed for noble
[15:13] <JanC> but Ubuntu users might have complained it used an "unusable password-locked pastebin" by default for them...
[15:13] <Eickmeyer> JanC: That's what's being discussed, but that's not upstream here is it?
[15:14] <JanC> as the change happened upstream, some Ubuntu users might have complained directly to them...?
[15:15] <Eickmeyer> JanC: pastebinit is directly maintained by a team of Ubuntu and Debian contributors in Github. And no, there are no complaints there that I could see.
[15:15] <rbasak> I'm not keen on relying on third party services when not necessary, especially ad-supported ones. I have no reason to distrust the current operator, but in general, these things tend to go wrong sooner or later.
[15:15] <rbasak> But I accept the difficulties in #ubuntu with users not having logins.
[15:16] <rbasak> So we need to make a team decision about how that trade-off falls.
[15:16] <Eickmeyer> rbasak: I agree. It seems like it was a unilateral decision.
[15:16] <JanC> people might even have logins, but not have them around, or not able to access them because they need to fix their system first for that...
[15:17] <Eickmeyer> rbasak: I just tend to play devil's advocate as I also tend to know both sides of the coin. :)
[15:22] <JanC> isn't there a better solution for whatever the SSO is used for?
[15:22] <rbasak> I think they did it to tackle a spam problem.
[15:22] <Eickmeyer> ^ That's why they put in in place.
[15:22] <JanC> (that's probably also some topic for another channel)
[15:22] <rbasak> (it wasn't always there)
[15:23] <Eickmeyer> Nah, it's relevant here, JanC, as it's a development problem related to a tool developed here.
[15:23] <rbasak> What sort of numbers of pastes does Ubuntu produce compared to others? Will dpaste.com notice if we change, and will that just move a spam problem to them?
[15:24] <rbasak> I think it's relevant here because it's up to Ubuntu developers to make decision now as to what we want the default to be.
[15:24] <rbasak> (for the Ubuntu package specifically)
[15:24] <Eickmeyer> ^ 💯
[15:24] <Eickmeyer> Also should probably be brought before the ML, IMO.
[15:25] <rbasak> I'm planning to write the ML shortly
[15:25] <Eickmeyer> Probably should have been brought before the ML before a unilateral decision was made.
[15:25] <JanC> I'm pretty sure current usage numbers of the Ubuntu pastebin are pretty low _because_ of the SSO...   ;)
[15:26] <Eickmeyer> Would be nice to compare pre-SSO to post-SSO, but then we'd be including spam numbers.
[15:27] <liushuyu> https://code.launchpad.net/~liushuyu-011/ubuntu/+source/rust-glib-sys/+git/rust-glib-sys/+merge/464244 so what's the status of this MP?
[15:27] <JanC> was it spam or malware that was the problem though?
[15:27] <Eickmeyer>  ¯\_(ツ)_/¯
[15:28] <Eickmeyer> liushuyu: Looks like a question for dbungert :)
[15:28] <JanC> I know some ransomware used public pastebins to "host" the information of how victim could pay to unlock for example (but not sure if they ever used the Ubuntu pastebin)
[15:30] <liushuyu> someone asked the question on Debian Rust channel https://matrix.to/#/!IChHcfHvgTXPMMthqR:matrix.org/$171307980819297AwSZU:matrix.org?via=matrix.org&via=fosdem.org&via=cripslock.undef.tools
[15:32] <dbungert> that patch is very strange.  if someone understands it enough feel free to upload.
[15:33] <Eickmeyer> Heh, I got nothin'.
[15:48] <rbasak> I'm planning to write the ML shortly> Sent.
[15:56] <athos> rbasak: ahasenack: we dropped the transitional package for this cycle. Back during the merge, we did verify that there were no reverse depends on that; Cc kanashiro
[15:59] <ahasenack> ok, and https://ubuntu.com/server/docs/pacemaker-resource-agents looks correct
[16:00] <ahasenack> it just doesn't make it clear that bin:resource-agents no longer exists, and I guess it still does in older releases
[16:01] <ahasenack> what made it look like a bug is that apt didn't say something like "this package doesn't exist"
[16:01] <kanashiro> the resource-agents binary package exists in all previous releases
[16:01] <ahasenack> it hinted that other packages still referred to "resource-agents", but I couldn't find them
[16:01] <ahasenack> there were no rdeps indeed
[16:10] <rbasak> athos, kanashiro: OK. Thanks! I'll update my instructions.
[16:12] <vorlon> @pilot in
[16:12] <vorlon> mwhudson: yeah, I don't know why c-ares went missing after that
[16:32] <waveform> @pilot out
[17:18] <liushuyu> vorlon: there seems to be still a few packages left on the etherpad, do you want to pull someone in to fix them or just get them out of the archive?
[17:30] <sudip> ncl-ncarg fails to install as it depends on libsphere0d which is not available..
[17:32] <sudip> ok, spherepack was removed by vorlon for FTBFS. maybe ncl-ncarg should also be removed then
[17:38] <bdrung> can someone have a look why setting _TIME_BITS is not enough to fix the build failure? https://bugs.launchpad.net/ubuntu/+source/xf86-input-multitouch/+bug/2061591
[17:38] -ubottu:#ubuntu-devel- Launchpad bug 2061591 in xf86-input-multitouch (Debian) "FTBFS: error: ‘const struct input_event’ has no member named ‘time’" [Undecided, New]
[17:40] <liushuyu> bdrung: this is because struct input_event will hide some fields if you define _TIME_BITS=64
[17:42] <liushuyu> the reason for that is to force the programs to use newer APIs that don't use deprecated fields (that is not time_t 64-bit safe)
[17:42] <bdrung> liushuyu, if I read https://bugs.launchpad.net/ubuntu/+source/xf86-input-multitouch/+bug/2061591/comments/1 correct, 'time' is available if _TIME_BITS=64 is defined
[17:42] -ubottu:#ubuntu-devel- Launchpad bug 2061591 in xf86-input-multitouch (Ubuntu) "FTBFS: error: ‘const struct input_event’ has no member named ‘time’" [High, New]
[17:46] <liushuyu> bdrung: it can also be something undefined certain macros, I can take a look on my local ARM device
[17:46] <bdrung> liushuyu, thanks.
[17:47] <sudip> bdrung: its "!defined(__USE_TIME_BITS64)", it will be  false if __USE_TIME_BITS64 is defined
[17:48] <bdrung> aah, i missed the inversion.
[17:48] <bdrung> so that software needs porting now
[17:49] <liushuyu> it could be a very simple fix
[17:49] <bdrung> this line must be ported: s->evtime = syn->time.tv_usec / ms + syn->time.tv_sec * ms;
[17:50] <liushuyu> just change it to s->evtime = syn->input_event_usec / ms + syn->input_event_sec * ms;
[17:51] <bdrung> thanks
[17:51] <liushuyu> Tested on my local ARM device that this works
[17:51] <liushuyu> ... although there are some implicit declarations
[17:51] <liushuyu> I guess not an issue though
[17:51] <bdrung> what is the simplest way to find the header for the implicit declaration?
[17:52] <liushuyu> bdrung: just build the project?
[17:52] <liushuyu> I can give you the list:
[17:52] <liushuyu> driver/multitouch.c:42:33: warning: implicit declaration of function ‘XIGetKnownProperty’
[17:52] <liushuyu> driver/multitouch.c:160:9: warning: implicit declaration of function ‘XIRegisterPropertyHandler’
[17:52] <liushuyu> src/test.c:63:9: warning: implicit declaration of function ‘close’;
[17:53] <liushuyu> -- end of the list
[17:53] <bdrung> i mean how to find it? "grep XIGetKnownProperty /usr/include"?
[17:53] <liushuyu> bdrung: Yes, given you have the B-D installed
[17:54] <liushuyu> `close(...)` is defined in `unistd.h`
[17:54] <bdrung> that feels so clumsy to find the correct header
[17:55] <liushuyu> For C++ projects, I recommend you to search on https://en.cppreference.com/w/cpp since grep'ing will produce too many noises
[17:56] <liushuyu> bdrung: if you are just concern about slow search speed, I recommend installing ripgrep (command: `rg`)
[17:56] <liushuyu> ... because there is no good way to search function/macro definitions in C/C++
[17:57] <bdrung> rust and python are so much nicer than C/C++
[17:57] <vorlon> liushuyu: it would be helpful if someone would look at the remaining packages on the etherpad, analyze them, and make recommendations to the archive team about what to remove
[17:58] <liushuyu> (there are now tools that is syntactic-aware of the content it is currently search, but for C/C++, usually there will be some limitations on what they will be able to understand)
[17:58] <liushuyu> vorlon: ... or if they can be fixed?
[17:59] <vorlon> liushuyu: if you're going to fix them that doesn't go through the archive team
[17:59] <liushuyu> vorlon: okay
[18:01] <liushuyu> bdrung: rust and python are so much nicer than C/C++ > if you are not doing something weird (like getattr(...)/eval(...) in Python or proc_macro in Rust)
[18:01] <bdrung> getattr is useful in some cases (but do not overuse it)
[18:05] <liushuyu> speaking of which, there are now a lot of Python tooling started to use Rust, like https://astral.sh/ruff, https://github.com/astral-sh/uv and https://github.com/mtshiba/pylyzer
[18:06] <bdrung> it would be nice if ruff would land in noble (currently fails to build)
[18:06] <liushuyu> bdrung: ... or you can use the Snap version
[18:07] <jbicha> juliank: are you planning to handle bug 2054908 before noble's release?
[18:07] -ubottu:#ubuntu-devel- Bug 2054908 in ubuntu-release-upgrader (Ubuntu) "gpg-wks-server pulls in postfix" [High, Confirmed] https://launchpad.net/bugs/2054908
[18:08] <liushuyu> uv is a faster alternative to pip/venv combo; pylyzer is a faster alternative to mypy/pyright combo
[18:10] <liushuyu> currently testing fixes for squeak-plugins-scratch st tcpxtract whitedune uhub
[18:19] <juliank> jbicha: Got moved to 2060578
[18:20] <jbicha> thanks!
[18:53] <liushuyu> I remember someone mentioned there is a script that could be used to open merge proposals in the ubuntu-dev-tools package
[18:53] <liushuyu> Which script was it? I can't find it
[18:59] <liushuyu> squeak-plugins-scratch fix: https://code.launchpad.net/~liushuyu-011/ubuntu/+source/squeak-plugins-scratch/+git/squeak-plugins-scratch/+merge/464345
[18:59] <liushuyu> tcpxtract fix: https://code.launchpad.net/~liushuyu-011/ubuntu/+source/tcpxtract/+git/tcpxtract/+merge/464346
[18:59] <liushuyu> whitedune fix: https://code.launchpad.net/~liushuyu-011/ubuntu/+source/whitedune/+git/whitedune/+merge/464349
[18:59] <liushuyu> uhub fix: https://code.launchpad.net/~liushuyu-011/ubuntu/+source/uhub/+git/uhub/+merge/464348
[19:05] <seb128> !dmb-ping
[19:05] <teward> seb128: not available due to illness
[19:21] <liushuyu> st fix: https://code.launchpad.net/~liushuyu-011/ubuntu/+source/st/+git/st/+merge/464350
[19:54] <vorlon> @pilot out
[20:05] <vorlon> liushuyu: "sponsorship required" please provide the link to what needs sponsoring! https://pad.riseup.net/p/migrate-list-amd64
[20:07] <liushuyu> vorlon: added now
[20:07] <vorlon> liushuyu: thanks
[20:26] <vorlon> liushuyu: rust-glib-sys uploaded, which clears a good half of https://ubuntu-archive-team.ubuntu.com/proposed-migration/noble_uninst.txt
[20:30] <liushuyu> vorlon: Thanks! Debian Rust team also wanted to take this patch (but it's a  bit hacky). I might talk to the upstream to see if they could do something
[21:57] <Unit193> rbasak: It was intentional, paste.ubuntu.com has become less and less accessible so the IRC team had an internal discussion which seemed to indicate that dpaste was the optimal choice.  Since pastebinit hasn't been maintained very well for a while, someone willing to maintain it (and part of the team that "was" maintaining it) took it over and made changes.
[22:01] <Unit193> (dpaste.com has been used by gentoo for years, IIRC archlinux and several others too.  It came out on top because of decent expire times, syntax highlighting, reliable, and used already by several big projects.)
[22:10] <vorlon> liushuyu: https://pad.riseup.net/p/migrate-list-amd64 has entries that say "need implicit-declaration-function fix uploaded" but have no packages ready for upload; I'm deleting these comments
[22:11] <liushuyu> vorlon: those comments were not mine
[22:13] <liushuyu> will these disasters (not fixed, but binaries were removed) come back after 24.04 is released?
[22:16] <vorlon> liushuyu: no; these are not considered 'done' until a new version of the package migrates from -proposed
[22:25] <liushuyu> vorlon: understood
[22:49] <mitchdz> Can someone take a look at moving noble rsync proposed into the updates pocket? https://bugs.launchpad.net/ubuntu/+source/rsync/+bug/2060967
[22:49] -ubottu:#ubuntu-devel- Launchpad bug 2060967 in rsync (Ubuntu) "noble/rsync buffer overflow detected" [Critical, In Progress]
[23:06] <Eickmeyer> Unit193: The objection was mostly because there was no team discussion other than the IRC Team because more teams other than IRC use it, so now the discussion is at https://lists.ubuntu.com/archives/ubuntu-devel/2024-April/042960.html. I highly recommend participating in that discussion.
[23:28] <Unit193> Eickmeyer: Yeah it was pretty well abandoned, I'd already fixed several deprecation and traceback and I had to wrangle the maintainers pretty hard just for those.
[23:29] <Unit193> Kinda feels like people are now caring after the fact, but certainly didn't for several years. :/
[23:31] <Eickmeyer> Unit193: Right, they're considering an Ubuntu delta for it to change it back (which is always an option; not everything has to be done upstream).
[23:31] <Unit193> Urgh, that's quite annoying.
[23:32] <Unit193> Where else is it even used?  Could easily ship some xdg config in ubuntu-dev-tools if that's where it'd be useful.
[23:32] <Eickmeyer> I highly suggest getting involved in the discussion in the ML. I don't have much of a horse in the race.
[23:34] <Unit193> Meh, if it's reverted I'll just tell the team and recommend we change our documentation just to use termbin instead, nc should be pretty much everywhere.
[23:34] <Eickmeyer> My involvement was limited to presenting your side of the argument when you weren't around.
[23:35] <Eickmeyer> And being an overall devil's advocate because I'm good at that. :)
[23:36] <Unit193> Well, it wasn't really a "unilaterial" change, and being on the IRCC had ziltch to do with it.  Really was more "This is abandonded, and the defaults really aren't good anymore."
[23:37] <Eickmeyer> Right, I'll admit in retrospect that part was misrepresented with further knowledge.
[23:39] <Eickmeyer> I think the perspective wasn't so much it's "abandoned" so much as it's "inherently stable" and doesn't bit-rot, but maybe taken-for-granted is more apt.
[23:40] <Unit193> I mean, traceback when run doesn't scream "stable" to me, but I guess YMMV.
[23:40] <Unit193> LodgetIt based pastebins were broken for years, private pastes I had a patch to fix for years too. :/
[23:40] <Eickmeyer> Well, yes, but not everybody sees that. That's what I mean by "taken-for-granted."
[23:41] <Unit193> Also, TIL `dpaste` is a package and binary.  Huh.
[23:41] <Eickmeyer> `Pastebin using OpenDHT distributed hash table` Nice
[23:43] <Unit193> I was looking for libapp-nopaste-perl
[23:44] <Unit193> "Prior to Noble" heh, more Lunar than Noble.  Oh well.
[23:45] <Eickmeyer> `pnopaste` `Pastebin with syntax highlighting` Amazing stuff you find on archaeological digs through the repo.