Re: supernovas upstream update -- needs sponsor
Congratulations Attila, to have your first package in Debian! To have
an overview, you may already know the package tracker,
https://tracker.debian.org/pkg/supernovas
BTW, Ubuntu did also pick it already up
https://launchpad.net/ubuntu/+source/supernovas
And thank you Nilesh for supporting this!
Cheers
Ole
Attila Kovacs <attipaci@gmail.com> writes:
> Hi Nilesh!
>
> Thanks for the update. Wow! That was fast. This is clearly thanks to
> you getting it in such excellent shape to start with.
>
> cheers,
>
> -- A.
>
>
>
> On 6/4/24 1:16 PM, Nilesh Patra wrote:
>> 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
Reply to: