Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.debian.bugs.dist > #1011208 > unrolled thread

Bug#881719: libcdio 2.1.0 and lubcdio++

Back to article view | Back to linux.debian.bugs.dist

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Bug#881719: libcdio 2.1.0 and lubcdio++ "Gabriel F. T. Gomes" <gabriel@inconstante.net.br> - 2020-05-24 23:50 +0200
    Bug#881719: libcdio 2.1.0 and lubcdio++ "Gabriel F. T. Gomes" <gabriel@inconstante.net.br> - 2020-06-01 00:50 +0200
      Bug#881719: libcdio 2.1.0 and lubcdio++ "Gabriel F. T. Gomes" <gabriel@inconstante.net.br> - 2020-06-01 01:10 +0200
        Bug#881719: libcdio 2.1.0 and lubcdio++ Bálint Réczey <balint@balintreczey.hu> - 2020-06-01 13:30 +0200
          Bug#881719: libcdio 2.1.0 and lubcdio++ "Gabriel F. T. Gomes" <gabriel@inconstante.net.br> - 2020-06-02 00:50 +0200
            Bug#881719: libcdio 2.1.0 and lubcdio++ Bálint Réczey <balint@balintreczey.hu> - 2020-06-02 13:20 +0200
              Bug#881719: libcdio 2.1.0 and lubcdio++ "Gabriel F. T. Gomes" <gabriel@inconstante.net.br> - 2020-06-02 14:10 +0200
                Bug#881719: libcdio 2.1.0 and lubcdio++ "Gabriel F. T. Gomes" <gabriel@inconstante.net.br> - 2020-06-29 19:40 +0200
                  Bug#881719: libcdio 2.1.0 and lubcdio++ Mattia Rizzolo <mattia@debian.org> - 2020-07-10 17:30 +0200
                  Bug#881719: libcdio 2.1.0 and lubcdio++ "Gabriel F. T. Gomes" <gabriel@inconstante.net.br> - 2020-07-26 01:20 +0200
                    Bug#881719: libcdio 2.1.0 and lubcdio++ "Gabriel F. T. Gomes" <gabriel@inconstante.net.br> - 2020-07-26 18:40 +0200

#1011208 — 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

[toc] | [next] | [standalone]

#1012159

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

[toc] | [prev] | [next] | [standalone]

#1012161

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

[toc] | [prev] | [next] | [standalone]

#1012214

Hi Gabriel,

Vasyl Gello <vasek.gello@gmail.com> 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

[toc] | [prev] | [next] | [standalone]

#1012278

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

[toc] | [prev] | [next] | [standalone]

#1012327

Hi Gabriel,

Gabriel F. T. Gomes <gabriel@inconstante.net.br> 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

[toc] | [prev] | [next] | [standalone]

#1012333

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.

[toc] | [prev] | [next] | [standalone]

#1015791

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.

:)

[toc] | [prev] | [next] | [standalone]

#1017430

[Multipart message — attachments visible in raw view] — view raw

On Fri, Jul 10, 2020 at 06:53:33AM +0000, 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  `-

[toc] | [prev] | [next] | [standalone]

#1019298

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

[toc] | [prev] | [next] | [standalone]

#1019371

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

[toc] | [prev] | [standalone]

Back to top | Article view | linux.debian.bugs.dist

csiph-web