Hi Hannah, Once again, sorry for the long delay. I was also waiting for consensus at #998165, because source:Description does not yet appear to be permitted by Debian Policy.
Hannah Rittich <v...@rittich.net> writes: >> For the "debian" group, <snip> > > I am fine with that. So, that means, someone with the right permissions > needsto create the repositories martchus-cpp-utilities, > martchus-qtutilities andsyncthing-tray in the Debian group on Salsa and > give me the permission to push > to these repos, right? Yes, I can create the first two at what will probably be round two of the reviews, but I recommend waiting for syncthing-tray, because you may prefer a "gbp" style repository for it, for ease of unbundling using Files-Excluded. Syncthing-tray also shouldn't be uploaded until the first two packages clear the NEW queue, so there's no rush. >> I think these links will be enough for you to figure it out: >> >> https://martchus.no-ip.biz/gitea/Martchus/syncthingtray/commit/6ab7662a649bb10edb1a15e8da542aca87317fa1 >> https://github.com/Martchus/syncthingtray/tree/master/libsyncthing >> >> https://github.com/Martchus/syncthing/tree/0b016895447adea3e8537f27cff045cabf5c128a >> https://github.com/syncthing/syncthing > I am still confused here. What I have found out (correct my, if I am wrong): > > 1. The upstream source of libsynthing is the Syncthing Tray > repository. It looks to me like Martchus is bundling a subset of his fork of upstream Syncthing. This should be excluded from the Debian orig.tarball. This can be done with a script and a source-cleaning git branch, plus merging the cleaned tag to debian/main rather than merging the upstream tag. Alternatively, it can be automated by using gbp's support for Files-Excluded. > 2. The library libsyncthing.so is still considered experimental and > therefore not built by default. Hence, the syncthingtray binary > package does not contain a libsyncthing.so or anything similar. > > Considering these points, I do not know, what you mean by "unbundling > libsyncthing". Since, the upstream source of libsyncthing is the > Syncthing Tray there should be no other source package for libsyncthing, > and since libsyncthing is not built (and IMHO shouldn't, because it is > still experimental) there is no libsyncthing.so that could be unbundled > from the binary package. > The definition of "unbundling" depends on the context. Sometimes it means a source package split, but in this case it means deleting Marchus' fork from Syncthing-Tray's source. If it's unused, then this shouldn't cause any problems at this time. If at some point it becomes default then it is better for the build to fail loudly rather than link against a custom libsyncthing. At that time the decision becomes: 1) depend on Debian's Syncthing source and link it into the expected place, or use a build-system config key to point Syncthing-Tray's build system to the correct location. 2) Use a build-system config key to explicitly disable this functionality. > Let me put it that way: I am not interestend in Golang per se, but I'd > like to see recent versions of Syncthing in Debian, and if I can help by > Golang packaging, I might be interested. > > The thing is, like most of us, I am more limited with respect to time > than with respect to motivation. I guess, I can pick up some packaging > tasks here and there, but for now I cannot promise to allocate much time > for this. > Ok :-) Currently progress here is blocked while waiting for team feedback on the gopsutil v2 to v3 migration. >> If your eventual objective is "Debian Maintainer" or "Debian >> Developer" status, then it may be useful to cultivate a rapport with >> another DD, because you'll need two advocates for the application. >> It's totally optional, of course! > > Haven't though about that, TBH. My current motivation is just to bring > Syncthing Tray into Debian, but being a maintainer could be something I > could be interested in. Cool, and of course, no pressure. The main reason I propose this is because it gives you increased autonomy (allows you to upload a set of packages without needing a sponsor). When I had to depend on someone for every single upload I was frustrated an demotivated by the long waits...because unfortunately it seems that windows of free time often don't align, you know? > I know the Debian New Maintainers' Guide and the Debian Policy Manual. I > have digested them to a decent degree (it is a large amount of text), > but I wouldn't claim knowing them by heart. > Wonderful! I'm not sure if anyone knows them by heart by the way. Most people probably just remember where to look something up when to confirm that someone is currently Policy-compliant or current best-practises. > Regarding lintian, I am using sbuild, so I am using lintian and I am > also confident that the dependencies are correctly specified. > > The current lintian warnings/errors I have are > > - in all three packages the "unreleased-changes" warning, which I'll > remove once the packages are ready for upload. Ack > - in all three packages the "source: unknown-field Description" warning > is shown. This is considered a false positive of lintian and will > change in a new release. See #998115. It looks to me like Policy doesn't yet allow source:Description. That's a cool idea though :-) See #998165 for the discussion. In Debian, Policy contains the rules, and Lintian checks for compliance with the rules, plus various other (often opinionated) checks and recommendations. Lintian output at the Error and Warning level usually indicates release critical faults that block an upload, and likewise, technical decisions that aren't Policy-compliant also must not be uploaded. > - in the syncthingtray package the "package-name-doesnt-match-sonames > libsyncthingconnector1.1.10 libsyncthingmodel1.1.10 > libsyncthingwidgets1.1.10". Since these are quite specific libraries > that are only used for Syncthing Tray, I do not see a point in > making separate binary packages for each of them. Hence, I would > suggest to ignore these warnings for now. > At this time I'm not thinking about this issue; Let's return to this question after the two dependencies have been uploaded. Policy will need to be consulted https://www.debian.org/doc/debian-policy/ch-sharedlibs.html Be it resolved that the current state is indeed the correct direction, a minimum solution is a lintian override. >> First, file ITP (Intent to Package) bug reports for the two >> dependencies using their prefixed source package names. You will >> close these bugs in each package's first changelog entry. This is >> required. Yes, I was lazy and didn't file ITPs for cpp-utilities, >> qtutilities--even though I was working on them. Yes, I should have >> filed them. > > Done. See #998178 and #998179. > Thanks! I'll start a review at #998178. Most of that will probably also apply to #998179, so the two will probably end up being uploaded in quick succession. > I have created the debian/copyright to my best knowledge. If I am > interpreting <https://wiki.debian.org/CopyrightReview> correctly, the > review should be done by someone other than me, I guess. Hence, if you > have time for the review, that would be awesome. > A quick glance at cpp-utilities looked good to me. Yes, in addition to your review, your sponsor is also responsible for verifying the asserted copyright is correctly represented, that both the source and generated binary packages are DFSG-compliant, and also sometimes to check for obviously plagiarised source. Then ftpmasters check again. Usually the longest wait is when waiting for ftpmasters to review the package once it's been uploaded to the NEW queue. > I have seen your feature request on Qt ForkAwesome > <https://github.com/Martchus/qtforkawesome/issues/2>. I was wondering, > why it would be necessary to do runtime font rendering, instead of > pre-rendering the icons. Let's return to this issue once the two deps are in the NEW queue. >Qt ForkAwesome allows you to specify the font file to use at build >time. Hence, fonts-fork-awesome would then just be a build >dependency. Currently, fonts-fork-awesome does not, however, include >all necessary files. I have sent a patch to the maintainer (#998147). > Thank you for sending this patch. If I remember correctly, some of the font icons from font-awesome had to be removed for DFSG reasons. Assuming this is also the case with fonts-fork-awesome, the Syncthing-Tray source package also cannot contain the non-DFSG content. Additionally, no Debian package should bundle fonts (or font-icons). I'm going to take a quick break and then compile my notes about cpp-utilities into a review. Cheers, Nicholas
signature.asc
Description: PGP signature
