| arraybolt3[m] | I have a possibly silly question. I see that the zlib and libpng use the same license. I'm dealing with a project that had all of libpng included in it, and am writing the debian/copyright file for it. I think I can mark the libpng section as licensed under the zlib license according to this site: https://opensource.org/licenses/Zlib But I can see that older versions of libpng used a different license, and I'm wondering - do I | 03:13 |
|---|---|---|
| arraybolt3[m] | need to include all of that? If so, I should use libpng as the short name rather than zlib and then include the whole long thing. Which way is more preferable? | 03:13 |
| arraybolt3[m] | (If you're wondering why on earth this project incorporates libpng rather than using the version installed on the system, that's how upstream decided to do it, who am I to question them?) | 03:14 |
| === JanC is now known as Guest5510 | ||
| === JanC_ is now known as JanC | ||
| === Guest5510 is now known as JanC | ||
| === JanC is now known as Guest9810 | ||
| === Guest8900 is now known as JanC | ||
| === paride7 is now known as paride | ||
| === arraybolt3 is now known as JoeBk | ||
| === JoeBk is now known as ArrayBolt3 | ||
| xypron | I am looking for a sponsor for LP #1986664. | 08:52 |
| ubottu | Launchpad bug 1986664 in Ubuntu "[needs-packaging] Package HSS payload generator for Polarfire Icicle board" [Undecided, Confirmed] https://launchpad.net/bugs/1986664 | 08:52 |
| === JanC_ is now known as JanC | ||
| === JanC is now known as Guest5931 | ||
| === JanC_ is now known as JanC | ||
| mitya57 | sil2100: Hi! This week bileto builds get stuck for an hour. For example, this one: https://bileto.ubuntu.com/log/4900/build/5/info/ | 11:29 |
| mitya57 | 2022-08-15 19:46:19,755 INFO Point of no return! Job can no longer be cancelled. | 11:29 |
| mitya57 | 2022-08-15 20:46:30,667 INFO Uploaded kinetic/compiz to PPA. | 11:29 |
| mitya57 | And later they fail with psycopg2.OperationalError. Can you please look when you have time? | 11:29 |
| sil2100 | mitya57: hey! hm, I'll try taking a look | 11:41 |
| mitya57 | Here is an example from today: https://bileto.ubuntu.com/log/4903/build/2/ | 11:42 |
| ahasenack | rbasak: hi, hm, any quick tips on how to revert a delta I added to a debian package and make it a sync again, when there is no new debian upload yet? | 12:32 |
| ahasenack | debian is 4.4.0-4, my upload was 4.4.0-4ubuntu1 | 12:32 |
| ahasenack | bite the bullet, do a 4ubuntu2 without the delta, and when debian 4.4.0-5 comes along, sync it? | 12:32 |
| rbasak | Yeah that works. I think there was some other thing mentioned on ubuntu-devel@ recently | 12:34 |
| * rbasak looks | 12:34 | |
| ahasenack | maybe upload 4.4.0-4.1, or 4.4.0-5~build1 (ugh)? | 12:35 |
| ahasenack | unsure if I can upload something without an ubuntu suffix, though | 12:35 |
| rbasak | You can. There's no limitation there. | 12:35 |
| rbasak | Here's the thread: https://lists.ubuntu.com/archives/ubuntu-devel/2022-May/042099.html | 12:37 |
| ahasenack | "Version string to auto-sync an Ubuntu delta (maysync1 vs ~willsync1) | 12:37 |
| ahasenack | " | 12:37 |
| ahasenack | that one? | 12:37 |
| ahasenack | yep | 12:37 |
| rbasak | I'm not sure that really helps here. | 12:39 |
| rbasak | It used to be the norm for everyone to check their own TIL using grep-merges in time for feature freeze. | 12:41 |
| rbasak | That method would work. | 12:41 |
| rbasak | Which reminded me that I should do that. | 12:41 |
| rbasak | Looks like I have a few :-/ | 12:41 |
| ahasenack | I subscribe to the debian tracker for the packages I touched | 12:42 |
| ahasenack | works quite well | 12:42 |
| ahasenack | hm, I can't use `maysync` here because it's lower than ubuntu | 12:43 |
| rbasak | Right | 12:43 |
| rbasak | That's what I meant by "not sure that really helps here" | 12:43 |
| ahasenack | i can use willsync, but that creates the problem if we need another ubuntu update to the package before the sync happens | 12:43 |
| rbasak | Right :) | 12:43 |
| rbasak | Turns out that overloading the version string like this doesn't really work | 12:44 |
| rbasak | (or, at least, breaks these edge cases) | 12:44 |
| ahasenack | I guess 4.4.0-4ubuntu2 is the easiest one to understand, even though it will have zero delta | 12:44 |
| ahasenack | or 4.4.0-5~build1 perhaps | 12:44 |
| ahasenack | is that too ugly? | 12:44 |
| * ahasenack searches for prior art | 12:45 | |
| rbasak | I would use ubuntu2 I think. | 12:46 |
| rbasak | The later merge will be trivial. We just have to notice and do it; that's all. | 12:46 |
| ahasenack | what about 4.4.0-4u3? | 12:46 |
| ahasenack | I mean, 4.4.0-4u2 | 12:48 |
| ahasenack | too mysterious? | 12:48 |
| ahasenack | the changelog would make it clear what happened | 12:48 |
| ahasenack | I'll email that thread and wait a few hours | 12:48 |
| rbasak | 4.4.0-4u2 is lower than the current 4.4.0-4ubuntu1 though I think? It's the same issue. | 12:50 |
| rbasak | You can't switch back and forth without running out of hacks. | 12:50 |
| rbasak | Since they have to be ordered | 12:51 |
| ahasenack | oh? I didn't test yet, but it was mentioned as one alternative in that thread | 12:51 |
| ahasenack | let me check | 12:51 |
| ahasenack | ah | 12:51 |
| ahasenack | hmpf | 12:51 |
| ahasenack | or keep using u3, u4, u5 | 12:51 |
| ahasenack | yeah, it's lower | 12:52 |
| rbasak | I suppose it's possible to use -1ubuntu1 -> -1willsync1 -> -1willsync1notreally1ubuntu1 -> -1willsync1really1 etc | 12:52 |
| rbasak | I think it's cleaner to just forget about it and use grep-merges/TIL. | 12:53 |
| ahasenack | yeah | 13:12 |
| ahasenack | I *could* use 4.4.0-5~willsync1 | 13:32 |
| ahasenack | just like ~build1, but with a somewhat clearer indication that it's not just a rebuild, but an intent-to-sync | 13:33 |
| ahasenack | and we we then add delta, hm, ubuntu is lower than w | 13:33 |
| ahasenack | oh well | 13:33 |
| ahasenack | rabbit hole warning | 13:33 |
| ahasenack | in that sense, 4.4.0-5~build1 is better, we can still use 4.4.0-5~ubuntu1 | 13:33 |
| ahasenack | later | 13:33 |
| rbasak | schopin: please could you merge ruby-mysql2? | 13:36 |
| rbasak | Logan_: please could you merge rp-pppoe? | 13:38 |
| ueberall | Hi. Anyone knows why it's now possible to copy files into non-existent directories in debian/rules Makefiles on Debian Sid, but the same (still) fails on Ubuntu Kinetic/Jammy/Focal? (See OpenSSL 3.0.5-2, for example.) | 14:39 |
| oSoMoN | sil2100, bug #1985066 points out that with refresh app awareness being enabled by default, updates to the firefox snap won't be installed while it is running. This is true, can we maybe add a line in the release notes to make it explicit? | 15:01 |
| ubottu | Bug 1985066 in firefox (Ubuntu) "cannot refresh snap 'firefox': snap 'firefox' has running apps (firefox)" [Undecided, Invalid] https://launchpad.net/bugs/1985066 | 15:01 |
| === eitteabs is now known as sbeattie | ||
| ogra | oSoMoN, they will be applied ... but with a 60day delay 😉 | 16:28 |
| ogra | (after the timer runs out, you get a forced upgrade even with the app running) | 16:29 |
| oSoMoN | ogra, right, but coming from 20.04 where firefox was delivered as a deb and upgraded silently in the background (being a security update), this is indeed a change in the default behaviour | 16:30 |
| ogra | yeah | 16:31 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!