Bug#881719: libcdio 2.1.0 and lubcdio++
Hi Gabriel! Let me explain more briefly how I see the future of Kodi from Debian according to my grand plan. July 26, 2020 4:33:22 PM UTC, "Gabriel F. T. Gomes" написав(-ла): >Hmm, that's not a decision to be made lightly. Would the backport to >buster fix any bugs or add features that users have requested? The core feature of v19 is improved PVR experience. This is a feature users have long asked for. >>This will also greatly simplify add-on management as I have prepared the full >>binary addon repository for Kodi. >>Now stable has,17.6, unstable 18.7 and experimental will feature 19.0~. > >Perhaps I do not understand the whole picture, but addons that work >with stable alone (i.e. stable without backports) have to be maintained >anyway (not every stable user enables backports). I don't see how >having an updated version in backports simplifies anything. It's >actually the other way around, as it adds more work for us. Of course all the bugs in addons currently hosted in stable are addressed and will be under my maintenance. The updated version in backports simplifies everything, because the stable user will have a choice - either stick with current Debian release and get only security fixes reported by 3rd party researchers, or enable backports and get the release maintained by upstream. Since Kodi upstream does not have a dedicated security team and focuses on backporting serious+ bug fixes in the branch version prior to current (i.e consider 19.0 as experimental, 18.8 as stable and 17.6 as oldstable and bugfixes are ported from 19.0 to 18.8 but not to 17.6), this really helps the end-user and package maintainers. >I don't think so, as it defeats the purpose of having a stable >distribution. And, in any case, people using the stable distribution >without backports enabled will keep using the older set of addons, >which might have security and serios functionality bugs, so we have to >take care of them anyway. Again, my intention is not to blatantly discard older versions, and I will check if there are unfixed CVEs affecting 17.1 and 17.6 present in oldoldstable and oldstable but I clearly realize it would be purely a Debian fix as upstream only accepts security and serious functional regression issues to 18.8. Given how many addons are there in old(old)stable, it is not a big waste of my time to check it. Cheers! -- Vasyl Gello == Certified SolidWorks Expert Mob.:+380 (98) 465 66 77 E-Mail: vasek.ge...@gmail.com Skype: vasek.gello == 호랑이는 죽어서 가죽을 남기고 사람은 죽어서 이름을 남긴다 signature.asc Description: PGP signature
Bug#881719: libcdio 2.1.0 and lubcdio++
Hi, Vasyl, On 26 Jul 2020, Vasyl Gello wrote: >I need it to satisfy kodi build dependency in libcdio++. Actually, when Kodi >19.0 goes live officially, >I would like to have it in unstable, testing (if it gets released before the >freeze takes place) That sounds reasonable, and I'm already working on the upload to unstable (I'll check that libcdio reverse dependencies [1] work well with the new package, then make the upload). [1] https://release.debian.org/transitions/html/auto-libcdio.html >and at least, >stable-bpo so end users have a chance to get backported, tested version >without upgrading the whole installation. Hmm, that's not a decision to be made lightly. Would the backport to buster fix any bugs or add features that users have requested? Maintaining a package in backports is more work. >This will also greatly simplify add-on management as I have prepared the full >binary addon repository for Kodi. >Now stable has,17.6, unstable 18.7 and experimental will feature 19.0~. Perhaps I do not understand the whole picture, but addons that work with stable alone (i.e. stable without backports) have to be maintained anyway (not every stable user enables backports). I don't see how having an updated version in backports simplifies anything. It's actually the other way around, as it adds more work for us. >All addon sets are incompatible with each other and upstream backports only >security and serious+ functionality >bug fixes. Sticking to the latest release in all branches is a good move. I don't think so, as it defeats the purpose of having a stable distribution. And, in any case, people using the stable distribution without backports enabled will keep using the older set of addons, which might have security and serios functionality bugs, so we have to take care of them anyway. Let me know if I got anything wrong. :) Cheers, Gabriel
Bug#881719: libcdio 2.1.0 and lubcdio++
Hi Gabriel! July 25, 2020 11:11:05 PM UTC, "Gabriel F. T. Gomes" написав(-ла): >On 25 Jul 2020, Vasyl Gello wrote: >>Without that, we can not upload backport to buster-bpo. > >I'm sorry if you have mentioned this before, but why is a backport >needed? I need it to satisfy kodi build dependency in libcdio++. Actually, when Kodi 19.0 goes live officially, I would like to have it in unstable, testing (if it gets released before the freeze takes place) and at least, stable-bpo so end users have a chance to get backported, tested version without upgrading the whole installation. This will also greatly simplify add-on management as I have prepared the full binary addon repository for Kodi. Now stable has,17.6, unstable 18.7 and experimental will feature 19.0~. All addon sets are incompatible with each other and upstream backports only security and serious+ functionality bug fixes. Sticking to the latest release in all branches is a good move. -- Vasyl Gello == Certified SolidWorks Expert Mob.:+380 (98) 465 66 77 E-Mail: vasek.ge...@gmail.com Skype: vasek.gello == 호랑이는 죽어서 가죽을 남기고 사람은 죽어서 이름을 남긴다 signature.asc Description: PGP signature
Bug#881719: libcdio 2.1.0 and lubcdio++
Hi, Vasyl, On 25 Jul 2020, Vasyl Gello wrote: > >Can you please upload libcdio to unstable? Yes. The upload to experimental didn't help *me* much with the testing of pragha, because, in order for pragha to use the new version, I also had to rebuild (locally) libcdio-paranoia (if I install libcdio-paranoia-dev from the archive, it pulls in libcdio18, which makes pragha try to load libcdio.so.18, instead of libcdio.so.19). Anyhow, I'll upload the new libcdio to unstable. >Without that, we can not upload backport to buster-bpo. I'm sorry if you have mentioned this before, but why is a backport needed? Cheers, Gabriel
Bug#881719: libcdio 2.1.0 and lubcdio++
Hi Gabriel! Can you please upload libcdio to unstable? Without that, we can not upload backport to buster-bpo. -- Vasyl Gello == Certified SolidWorks Expert Mob.:+380 (98) 465 66 77 E-Mail: vasek.ge...@gmail.com Skype: vasek.gello == 호랑이는 죽어서 가죽을 남기고 사람은 죽어서 이름을 남긴다 signature.asc Description: PGP signature
Bug#881719: libcdio 2.1.0 and lubcdio++
On Fri, Jul 10, 2020 at 06:53:33AM +, Vasyl Gello wrote: > Hi Gabriel! > > I investigated the reprotest failure on libcdio and it seems a reborn > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=795690 > Is it possible to exclude GMT-14 from reprotest or is it better to try fixing > upstream instead? No, even if it was possible I'd disagree to it: why should something knowingly fail in a known timezone? (TBH, even exporting TZ=UTC in d/rules is IMHO just a workaround) -- regards, Mattia Rizzolo GPG Key: 66AE 2B4A FCCF 3F52 DA18 4D18 4B04 3FCD B944 4540 .''`. More about me: https://mapreri.org : :' : Launchpad user: https://launchpad.net/~mapreri `. `'` Debian QA page: https://qa.debian.org/developer.php?login=mattia `- signature.asc Description: PGP signature
Bug#881719: libcdio 2.1.0 and lubcdio++
Hi Gabriel! I investigated the reprotest failure on libcdio and it seems a reborn https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=795690 Is it possible to exclude GMT-14 from reprotest or is it better to try fixing upstream instead? -- Vasyl Gello == Certified SolidWorks Expert Mob.:+380 (98) 465 66 77 E-Mail: vasek.ge...@gmail.com Skype: vasek.gello == 호랑이는 죽어서 가죽을 남기고 사람은 죽어서 이름을 남긴다 signature.asc Description: PGP signature
Bug#881719: libcdio 2.1.0 and lubcdio++
Hi, Vasyl, On Mon, 29 Jun 2020, Vasyl Gello wrote: > The MR I amended after Gabriel's review is stuck since June 2nd. Yes, my bad. > Gabriel, can you please revise the MR and upload the fixed package to the > queue? Will do (I'll try to do it today)! Thanks for the heads-up. :)
Bug#881719: libcdio 2.1.0 and lubcdio++
Dear colleagues, The MR I amended after Gabriel's review is stuck since June 2nd. Gabriel, can you please revise the MR and upload the fixed package to the queue? -- Vasyl Gello == Certified SolidWorks Expert Mob.:+380 (98) 465 66 77 E-Mail: vasek.ge...@gmail.com Skype: vasek.gello == 호랑이는 죽어서 가죽을 남기고 사람은 죽어서 이름을 남긴다 June 2, 2020 7:09:03 PM UTC, Vasyl Gello написав(-ла): >Hi Gabriel, Balint! > >Please check merge request to debian/cdio. Reprotest still fails at a first >glance, but lintian warnings have gone. >I will try fixing it but I need to install reprotest hook inside my pbuilder. > >If you manage to fix reprotest, please let me know. >-- >Vasyl Gello >== >Certified SolidWorks Expert > >Mob.:+380 (98) 465 66 77 > >E-Mail: vasek.ge...@gmail.com > >Skype: vasek.gello >== >호랑이는 죽어서 가죽을 남기고 사람은 죽어서 이름을 남긴다 signature.asc Description: PGP signature
Bug#881719: libcdio 2.1.0 and lubcdio++
Hi Gabriel, Balint! Please check merge request to debian/cdio. Reprotest still fails at a first glance, but lintian warnings have gone. I will try fixing it but I need to install reprotest hook inside my pbuilder. If you manage to fix reprotest, please let me know. -- Vasyl Gello == Certified SolidWorks Expert Mob.:+380 (98) 465 66 77 E-Mail: vasek.ge...@gmail.com Skype: vasek.gello == 호랑이는 죽어서 가죽을 남기고 사람은 죽어서 이름을 남긴다 signature.asc Description: PGP signature
Bug#881719: libcdio 2.1.0 and lubcdio++
On Tue, 02 Jun 2020, Bálint Réczey wrote: > > Done. I've omitted the last commit because I suggest using -1~exp0 > Debian version for the upload to experimental. IMO looks nicer when > the upload to unstable has -1. Thanks for the review. I'll fix this, then upload again to mentors.
Bug#881719: libcdio 2.1.0 and lubcdio++
Hi Gabriel, Gabriel F. T. Gomes ezt írta (időpont: 2020. jún. 2., K, 0:46): > > On 01 Jun 2020, Bálint Réczey wrote: > > > >I've checked the package and it refers to > >https://salsa.debian.org/debian/libcdio as the packaging repo while it > >is not present. > >I fyou agree let me clone your packaging repo there, then I can review > >the changes. > > Oh, please. And thank you. :) Done. I've omitted the last commit because I suggest using -1~exp0 Debian version for the upload to experimental. IMO looks nicer when the upload to unstable has -1. I've also added Salsa CI configuration, please see the results at: https://salsa.debian.org/debian/libcdio/pipelines In general the changes look good and I'll sponsor the upload when I get my keys updated (unless Mattia or someone else does it earlier). Going forward I recommend converting debian/rules to modern debhelper style and fixing reprotest would also be nice. Cheers, Balint > >I can't upload in the next few days (weeks?) because my keys are > >expired and I'm waiting for the next keyring push to get them > >refreshed. > > No problem. > > > Cheers, > Gabriel
Bug#881719: libcdio 2.1.0 and lubcdio++
On 01 Jun 2020, Bálint Réczey wrote: > >I've checked the package and it refers to >https://salsa.debian.org/debian/libcdio as the packaging repo while it >is not present. >I fyou agree let me clone your packaging repo there, then I can review >the changes. Oh, please. And thank you. :) >I can't upload in the next few days (weeks?) because my keys are >expired and I'm waiting for the next keyring push to get them >refreshed. No problem. Cheers, Gabriel
Bug#881719: libcdio 2.1.0 and lubcdio++
Hi Gabriel! I have just checked the mentors page for libcdio & found out Lintian is mad about some issues. Let me fix it quickly and file a new PR. Vasyl On Mon, 1 Jun 2020 13:23:48 +0200 =?UTF-8?B?QsOhbGludCBSw6ljemV5?= wrote: > Hi Gabriel, > > Vasyl Gello ezt írta (időpont: 2020. jún. 1., H, > 7:49): > > > > Hi Gabriel! > > > > >The package is now on mentors: > > > > > >https://mentors.debian.net/package/libcdio > > I've checked the package and it refers to > https://salsa.debian.org/debian/libcdio as the packaging repo while it > is not present. > I fyou agree let me clone your packaging repo there, then I can review > the changes. > > I can't upload in the next few days (weeks?) because my keys are > expired and I'm waiting for the next keyring push to get them > refreshed. > > Cheers, > Balint > > > > > > >Balint, could you review it and, if everything is fine, sponsor it? > > >(I'm asking because Vasyl mentioned you are guiding the packaging of > > >Kodi, if I got it right) > > > > Yes, you are correct. I also did upload two Kodi dependencies, but they are > > covered by separate > > RFS. > > -- > > Vasyl Gello > >
Bug#881719: libcdio 2.1.0 and lubcdio++
Hi Gabriel, Vasyl Gello ezt írta (időpont: 2020. jún. 1., H, 7:49): > > Hi Gabriel! > > >The package is now on mentors: > > > >https://mentors.debian.net/package/libcdio I've checked the package and it refers to https://salsa.debian.org/debian/libcdio as the packaging repo while it is not present. I fyou agree let me clone your packaging repo there, then I can review the changes. I can't upload in the next few days (weeks?) because my keys are expired and I'm waiting for the next keyring push to get them refreshed. Cheers, Balint > > > >Balint, could you review it and, if everything is fine, sponsor it? > >(I'm asking because Vasyl mentioned you are guiding the packaging of > >Kodi, if I got it right) > > Yes, you are correct. I also did upload two Kodi dependencies, but they are > covered by separate > RFS. > -- > Vasyl Gello
Bug#881719: libcdio 2.1.0 and lubcdio++
Hi Gabriel! >The package is now on mentors: > >https://mentors.debian.net/package/libcdio > >Balint, could you review it and, if everything is fine, sponsor it? >(I'm asking because Vasyl mentioned you are guiding the packaging of >Kodi, if I got it right) Yes, you are correct. I also did upload two Kodi dependencies, but they are covered by separate RFS. -- Vasyl Gello signature.asc Description: PGP signature
Bug#881719: libcdio 2.1.0 and lubcdio++
On 31 May 2020, Gabriel F. T. Gomes wrote: > >we will need a sponsor. The package is now on mentors: https://mentors.debian.net/package/libcdio Balint, could you review it and, if everything is fine, sponsor it? (I'm asking because Vasyl mentioned you are guiding the packaging of Kodi, if I got it right) Cheers, Gabriel
Bug#881719: libcdio 2.1.0 and lubcdio++
Hi, Vasyl, On 24 May 2020, Vasyl Gello wrote: > >Yes experimental is OK for me, even though I uploaded libshairplay & >libudfread to unstable queue. Balint asked me initially to target Kodi 19.0 to >experimental so I will probably re-upload both libraries to experimental to >keep everything consistent. Awesome. I accepted your merge request and I prepared the package for experimental. It will take a while to get there though, because I'm not a DD yet (my process is still ongoing), so we will need a sponsor. Also, since it adds new binary packages, it will also have to go through the new queue. Cheers, Gabriel
Bug#881719: libcdio 2.1.0 and lubcdio++
Hi Gabriel! May 24, 2020 9:40:59 PM UTC, "Gabriel F. T. Gomes" написав(-ла): > >Initially, and because I was a little >uncomfortable with the soname change, I thought about uploading to >experimental first. Would that work for you? > Yes experimental is OK for me, even though I uploaded libshairplay & libudfread to unstable queue. Balint asked me initially to target Kodi 19.0 to experimental so I will probably re-upload both libraries to experimental to keep everything consistent. I will dedicate some time to check iso9660 & udf images processing within Kodi and let you know how it goes! Sincerely, -- Vasyl Gello
Bug#881719: libcdio 2.1.0 and lubcdio++
Hi, Vasyl, on 24 May 2020, Vasyl Gello wrote: > >Gabriel has prepared 2.1.0 in his Salsa repo and I added C++ interfaces needed >by Kodi 19.0: >https://salsa.debian.org/gabrielftg-guest/libcdio/-/merge_requests/1 Thank you so much for writing this pull requests. I wasn't aware that there was a C++ interface in libcdio. I'm actually very new to libcdio; I only came across it because it is a dependency of another project (pragha) that I mantain. I'll review your merge request as soon as possible, then I'll prepare a package for uploading. Initially, and because I was a little uncomfortable with the soname change, I thought about uploading to experimental first. Would that work for you? >Can the version 2.1.0 be pushed into distribution? Please bear in mind that we will have to go through the NEW queue, because of the new binary packages (not just the C++ libraries, but also because of the soname bump on the C library). Cheers, Gabriel
Bug#881719: libcdio 2.1.0 and lubcdio++
Dear colleagues, Gabriel has prepared 2.1.0 in his Salsa repo and I added C++ interfaces needed by Kodi 19.0: https://salsa.debian.org/gabrielftg-guest/libcdio/-/merge_requests/1 Can the version 2.1.0 be pushed into distribution? -- Vasyl Gello signature.asc Description: PGP signature
