Good news - it got accepted quickly. I did a source-only upload too and supernovas should now migrate to testing in about 5 days. https://qa.debian.org/excuses.php?package=supernovas On Mon, Jun 03, 2024 at 02:36:06AM +0530, Nilesh Patra wrote: > Hey, Hey! > > Alright, so after discussion it was concluded that using !cross would make the > package not reproducible[1] and that we should instead use some package specific > build profile. So I went ahead with "pkg.supernovas.ciodata" and mentioned about > it in d/README.Source, if in case someone wants to crossbuild it. > > Also passed in that build profile in salsa ci file so the CI keeps passing. It > isn't the best solution but a fair compromise. > > I also evaluated the feasibility of adding in a "Suggests" in libsupernova1 for > the 2 other library, but if someone runs these with --install-suggests, I am not > sure if the sort of circular dependency that created here and if it could become > unresolvable. So I skipped doing so for now -- I am not aware about how apt would > internally react to it. Could try once to check. > > We can add it in the subsequent upload if desired for sure. > > I have uploaded the package for now. It was a nice experience working with you! > > [1]: https://wiki.debian.org/ReproducibleBuilds > > Best, > Nilesh > > On Sun, Jun 02, 2024 at 07:47:31PM +0200, Attila Kovacs wrote: > > Hi Nilesh, > > > > > > Thanks a lot for all the good work you put into this. I really, really > > appreciate it. > > > > I must admit Debian packaging is quite overwhelming for a noob -- much more > > so than Fedora's. It's also less forgiving, and cumbersome (I found working > > with the patch queue especially annoying). And the relevant documentation > > tends to be quite scattered, and some of the documents can be at odds with > > one another (e.g. 'gbp import-orig' vs 'uupdate', not to mention the 'uscan' > > command you ended up using in the end)... On the good side, I did find the > > Debian package checking more thorough and helpful than Fedora's, and it > > helped catch a bunch of issues even before it landed on your desk... And > > best of all it's great to have experience people like you help out, and get > > things done right. > > > > Hopefully, my next packages will go more smoothly. (I'm planning to > > open-source a few more libraries over the next year or so, and will try to > > package them also). > > > > I owe you one! > > > > cheers, > > > > -- A. > > > > > > On 6/2/24 7:33 PM, Nilesh Patra wrote: > > > Hi Attila, > > > > > > On Sun, Jun 02, 2024 at 06:36:18PM +0200, Attila Kovacs wrote: > > > > Thanks Nilesh for cleaning things up nicely, and for offering to sponsor it. > > > > I'll gladly accept your offer! > > > > > > > > > > > > I'm generally OK with the renaming to follow the library style guide. I do > > > > find it a little particular (and awkward) though for two reasons: > > > > > > > > 1. the libsolsys1-1, and libsossys2-1 are somewhat awkward although if that > > > > is the standard for naming packaghed libs that have a number as part of > > > > their name, then it is what it is. > > > In general packages should match the name of the so that they provide unless you > > > have a very good reason not to. The .so in them are libsolsys1.so.1 and > > > libsolsys2.so.1 and hence the names. > > > > > > Maybe it'd make sense to rename .so files to something else as upstream? > > > Not sure, but it does not look like a big concern. > > > > > > > 2. For libsolsys1-1 and libsolsys2-1, the package names hide that these > > > > belong to the supernovas package (that they are optional packages thereof). > > > > I guess that's OK, since the dependencies are there. Perhaps you could add a > > > > 'Suggests' to libsupernovas1, so they are more easily discoverable by users > > > > who might be wondering what packages might provide the legacy > > > > functionalities... > > > Fine, can do. > > > > > > > I'm curious, how did you manage to import the upstream with the same version > > > > '1.0.1-2'? I have utterly failed doing that even though I wasted a full day > > > > trying as I might. :-) > > > I was pretty easy after fixing d/watch and removing the annoying uupdate. > > > > > > $ uscan -dd --verbose --download-version 1.0.1-2 > > > > > > worked. > > > > > > > Finally, I noticed you removed the version dependence on doxygen. Maybe > > > > that's OK, but the fact is that older versions of doxygen will caugh up an > > > > error with the Doxyfile configuration, as it contains settings that are not > > > > supported in earlier releases of doxygen. (If you do change your mind on > > > > specifying a minimum version, you probably want it to be the current one, > > > > which is 1.10, I think). > > > It was some automated tooling (cme) that did so. The uploads to packages go > > > through unstable and are built with packages in unstable. Sometimes you want to > > > backport things to stable, and very rarely to old-stable. Debian versions before > > > that are mostly unsupported. > > > > > > The version of doxygen in even old stable is 1.9.1 so the version dep is not > > > needed as such. Keeping it does not hurt, sure but there's no utility per se. > > > > > > There's some confusion going on on whether to use !cross profile or not and I'm > > > talking to people in #debian-bootstrap. Once that's closed, I'll make the change > > > for cross builds, add a suggests on libsupernovas1 for libsolsys* and upload to > > > the NEW queue. It will then be reviewed by the FTP masters before accepting it > > > into the archive. > > > > > > Best, > > > Nilesh > Best, > Nilesh Best, Nilesh
Attachment:
signature.asc
Description: PGP signature