| cjwatson | I guess it actually wants to be https://paste.ubuntu.com/p/Y7ryfJPtKx/ to handle upgrades from systems that already had the wlroots package installed | 00:00 |
|---|---|---|
| soreau | cjwatson: wow, that is confusing | 00:02 |
| cjwatson | I have to take the puppy outside and then go to bed, but I'm sure any other Ubuntu developer should be able to explain points of confusion if needed | 00:04 |
| cjwatson | Good luck | 00:04 |
| soreau | and where did the number '10' come from in 'libwlroots10'? Seems quite arbitrary | 00:04 |
| cjwatson | It's the number from your library's SONAME | 00:04 |
| soreau | huh, I thought it should be 15 then | 00:04 |
| cjwatson | -rw-r--r-- root/root 751368 2021-07-07 00:50 ./usr/lib/x86_64-linux-gnu/libwlroots.so.10 | 00:04 |
| soreau | oh ok | 00:04 |
| cjwatson | SONAME is *not* the same as the package version number | 00:04 |
| soreau | well it sure should be | 00:04 |
| soreau | lol | 00:04 |
| cjwatson | There is a rant in the libtool documentation about why it shouldn't :) | 00:05 |
| sarnold | lol | 00:05 |
| soreau | heh | 00:05 |
| cjwatson | Seems to be set in "soversion = 10" in meson.build (though I don't really speak meson very well) | 00:05 |
| cjwatson | But basically, the idea is that a SONAME bump is a compatibility break | 00:07 |
| soreau | that's the same for the project major version | 00:08 |
| cjwatson | Apparently not here! | 00:08 |
| soreau | there* | 00:08 |
| cjwatson | Certainly some upstream library maintainers arrange things so that their major versions match their SONAME | 00:09 |
| cjwatson | But it's not universal, and the thing that the system's dynamic linker pays attention to is the SONAME in ELF object metadata, not the major version | 00:09 |
| cjwatson | (objdump -p on any .so file shows it among its output) | 00:10 |
| === genii is now known as genii-core | ||
| RAOF | soreau: One wrinkle here is that source compatibility and binary compatibility are not the same. Generally for libraries you expect the major version to bump when the API changes - that is, when your existing source won't compile against the new library. | 02:54 |
| RAOF | But there are tons of things you can do that break binary compatibility without breaking source compatibility (and visa versa). | 02:54 |
| soreau | RAOF: are you talking ABI vs API? | 02:56 |
| RAOF | soreau: Mainly? There are subtleties, but ABI vs API is a reasonable simplification. | 03:28 |
| soreau | RAOF: well thanks, but ultimately I'm just strugling with the package depends. I can understand build depends but for depends, do you have to list every dependent (non-dev) package? | 03:36 |
| RAOF | So, there's a bunch of packaging infrastructure that should automatically populate the Depends: field (or, more correctly, populate the ${shlibs:Depends} variable) with all the DSOs anything in the package directly link to. | 03:38 |
| RAOF | So mostly you should only need to explicitly list things which aren't linked to, but are required - usually that's any external binaries that get called, or data that is required. | 03:39 |
| RAOF | (`dh_shlibdeps` is the relevant bit of packaging infrastructure) | 03:40 |
| RAOF | Also, that's assuming things using dynamic linker; for things like python programs you need to list (python) library dependencies explicitly, as there's no general way to automatically determine the list of python libraries required. | 03:43 |
| RAOF | There's no automated tooling for populating the Depends: field of a -dev package, but I guess there could be? | 03:46 |
| RAOF | Like, it'd not terribly hard to write a `dh_pkgconfigdeps` that looked at all the .pc files shipped in the package and added the packages that provided those pc files to a variable like `${pkgconfig:Depends}`. | 03:47 |
| RAOF | But that infrastructure doesn't currently exist. | 03:47 |
| soreau | RAOF: ok thanks for that | 04:15 |
| === cpaelzer_ is now known as cpaelzer | ||
| rbasak | tjaalton: missing SRU information in bug 1931547? In particular there's not test plan. | 10:54 |
| ubottu | Bug 1931547 in xorg-server (Ubuntu Impish) "DisplayLink displays are black after Mesa update" [High, Triaged] https://launchpad.net/bugs/1931547 | 10:54 |
| rbasak | Are you planning to test the evdi and udl cases separately? | 10:55 |
| tjaalton | rbasak: ah right | 10:55 |
| tjaalton | the reporter has displaylink, not evdi | 10:57 |
| rbasak | tjaalton: I'm just looking at the code changes! | 11:00 |
| tjaalton | udl is older displaylink, evdi is newer | 11:01 |
| tjaalton | now that I checked | 11:01 |
| tjaalton | I'm not planning to test that | 11:01 |
| tjaalton | since I don't have the hw | 11:01 |
| xnox | sil2100: i still don't see adt results for https://bileto.ubuntu.com/#/ticket/4594 =( | 11:02 |
| xnox | it should be xenial. if not, i guess i'll have to run them myself somehow. | 11:02 |
| tjaalton | rbasak: sru info added | 11:26 |
| rbasak | tjaalton: thanks. How do you normally handle testing SRU changes for hardware you don't have available? Land the change anyway and hope for the best? | 11:32 |
| tjaalton | rbasak: the reporter has it | 11:32 |
| rbasak | Only for one of the two variants being changed though? | 11:33 |
| tjaalton | and how would the other break? | 11:33 |
| tjaalton | the evidence is strong enough that doing it is right for both | 11:33 |
| rbasak | I don't know the specifics. Usually when we talk about regression risk, we identify areas that could break, with no requirement at review time to demonstrate definitively that they will. | 11:34 |
| rbasak | Instead we usually demostrate at SRU verification time that they haven't regressed. | 11:35 |
| rbasak | tjaalton: the evidence is strong enough that doing it is right for both> could you at least document that judgement call in the bug then please? | 11:37 |
| tjaalton | hw issues are special since it requires the hw. and in this case the difference is just the identifier string | 11:37 |
| tjaalton | okay | 11:37 |
| rbasak | afk for lunch now, but I can come back to this later. With that decision documented it sounds OK to me. | 11:42 |
| slyon | hmm.. which packages provides /etc/nsswitch.conf in Ubuntu? I cannot find it in base-files.. | 11:42 |
| seb128 | slyon, /var/lib/dpkg/info/libc-bin.postinst: install_from_default /usr/share/libc-bin/nsswitch.conf /etc/nsswitch.conf | 11:50 |
| slyon | thanks seb128! | 11:51 |
| seb128 | np! | 11:51 |
| nibbon_ | o/ | 12:46 |
| nibbon_ | question: for kernel dump coming from 5.4.0-58 can I use >= linux-image-5.4.0-74-generic-dbgsym or I do need the specific package linux-image-5.4.0-58-generic-dbgsym? | 12:46 |
| ogra` | nibbon_, most likely rather a question for #ubuntu-kernel ... but indeed you need the symbols for exactly the version you are running | 13:09 |
| nibbon_ | ogra` thanks for the hint. Actually I've already asked that question in #ubuntu-kernel but nobody answered | 13:10 |
| sil2100 | xnox: argh, so the ADT tests are running but bileto fails to publish the results, huh, had this issue once - let me see how to fix this | 13:29 |
| sil2100 | xnox: ok, hopefully it should be better in ~30 mins | 13:33 |
| * laney pats sil2100 | 13:35 | |
| sil2100 | laney: hey! Quick question - when I'm on the staging rabbitmq-server/6 , is there an easy way I could check the AMQP queues there? | 14:00 |
| laney | sil2100: check how? | 14:01 |
| laney | the size or the contents? | 14:01 |
| sil2100 | Like, the contents (size maybe as well?) since I'm investigating why AMQP requests from my security britney ESM instance aren't actually doing anything - I only checked the rabbitmq logs and saw that authentication passed, but nothing else | 14:02 |
| sil2100 | hm, wait | 14:03 |
| sil2100 | Actually maybe some worker picked it up | 14:03 |
| sil2100 | And I'll check the logs there | 14:03 |
| sil2100 | ! | 14:03 |
| laney | heh | 14:03 |
| laney | sil2100: well the answer is no, you can probably take filter-amqp and turn that into print-amqp though | 14:04 |
| laney | that might be a useful debugging tool to live in tools/ if you did that | 14:04 |
| laney | or the code from /running | 14:04 |
| sil2100 | Ok, thanks! I guess I found the actual error | 14:04 |
| laney | 👍 | 14:05 |
| laney | or you could hack /running to display private jobs if it's just for testing | 14:05 |
| laney | I guess | 14:05 |
| webchat40 | -z | 14:10 |
| icey | hey bdmurray - the upstream python 3.9.6 seems to still have the changes from the commit named on https://bugs.launchpad.net/ubuntu/+source/breezy/+bug/1932313 , when you said that it was reverted, did you mean in Ubuntu? | 14:18 |
| ubottu | Launchpad bug 1932313 in breezy (Ubuntu) "Breezy 3.2.0+bzr7543-1 FTBFS" [Undecided, New] | 14:18 |
| bdmurray | icey: I think you are looking for doko | 14:28 |
| icey | bdmurray: ah you're right, so many people joining the conversation :-D | 14:28 |
| tjaalton | rbasak: ok it took a while, but how does the reasoning look now? I tried to search if someone had actually complained about the older 'udl' devices, but at least the newer type has been tested, and they both are similar hardware when it comes to X | 14:29 |
| ijohnson[m] | hi folks, can someone tell me what the vertical axis here is? https://errors.ubuntu.com/?release=Ubuntu%2021.04&snap=True&period=day I see values like 0.17, but I don't know what that means, like 0.17 * 1000 = 170 errors ? | 15:08 |
| ijohnson[m] | bdmurray: maybe you know the answer to ^ ? | 15:13 |
| bdmurray | ijohnson[m]: I don't recall exactly and wasn't involved in creating the vertical axis | 15:15 |
| ijohnson[m] | ah okay, sorry someone mentioned to me maybe you would recall | 15:15 |
| bdmurray | ijohnson[m]: Well I do maintain it so I might be able to figure it out | 15:21 |
| ijohnson[m] | it's not a high priority thing so feel free to take a look when you get a chance | 15:21 |
| laney | ijohnson[m]: https://wiki.ubuntu.com/ErrorTracker#errors.ubuntu.com | 15:22 |
| laney | and bdmurray I guess | 15:22 |
| laney | it's an mpt-ish thing :-) | 15:22 |
| laney | seems like it's supposed to have a label | 15:23 |
| ijohnson[m] | ah interesting, so it's 0.17 errors per machine per day | 15:23 |
| laney | if the calculations are right :p | 15:24 |
| ijohnson[m] | :-D | 15:31 |
| rbasak | tjaalton: I was expecting you to be more specific in the Test Plan with your reasoning on why it's OK to skip explicit testing of one of the two variants. | 16:17 |
| rbasak | But I'm accepting because I think it's clear on IRC at least and there's no point carrying on back and forthing on this. | 16:17 |
| === cpaelzer_ is now known as cpaelzer | ||
| tjaalton | rbasak: I added more meat to the next section, probably the wrong place.. anyway, thanks! | 17:02 |
| === lucas_ is now known as lucascastro | ||
| === sem2peie- is now known as sem2peie | ||
| === jdstrand_ is now known as jdstrand | ||
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!