Re: Packaging homeassistant in Debian
Hi! Thomas Goirand writes: > Dear friends, > > Together with a bunch of people during debcamp, we decided to package > homeassistant. This is a huge task, with hundreds of > dependencies. Since there's too many, we've been told to no Cc: > debian-devel@l.d.o when filing the ITPs, and instead write a summary > (as per developper's ref). Cool! > Well, we wont write such a summary, but everyone can follow our > progress on this wiki page, which fills the same purpose: > > https://wiki.debian.org/Python/HomeAssistant > > As you may see, there are 600+ packages to do. Since we're a lot of > people on the task, we believe it can be done. > > I've written 13 packages myself, and uploaded most already. Edward > Betts beated me by a very much higher numbers! billchenchina1 and > omnidapps already wrote many packages waiting in the NEW queue too. As the current maintainer of python-zigpy, on which at least 4 of those unpackaged items depend (+ probably HomeAssistant itself?): Would you be willing to adopt python-zigpy too? I've stalled a bit with keeping it up to date, mostly due to upstream seeming to not always take copyright very seriously [1]. That issue has been fixed, and as far as I know the current release (0.64.3) should be DFSG-compliant. However, as I'm not actively using ZigPy myself anymore, I've put updates on the backburner. A similar (imho unfixed) issue [2] can be seen in another package from the list, zigpy-znp. Learning of your HomeAssistant efforts, it seems sensible to hand python-zigpy off to your new team, if you'd agree. Apart from upstream's aforementioned issue, the package is very straightforward. The git repo [3] is up to date. Let me know what you think. [1] https://github.com/zigpy/zigpy/issues/1357 [2] https://github.com/zigpy/zigpy-znp/issues/206 [3] https://salsa.debian.org/gspr/zigpy/ Best, Gard signature.asc Description: PGP signature
Bug#1080526: ITP: python-multiurl -- Python package for downloading multiple URLs at once
Package: wnpp Severity: wishlist Owner: Gard Spreemann X-Debbugs-Cc: debian-devel@lists.debian.org, g...@nonempty.org * Package name: python-multiurl Version : 0.3.1 Upstream Contact: European Centre for Medium-Range Weather Forecasts * URL : https://github.com/ecmwf/multiurl * License : Apache-2.0 Programming Lang: Python Description : Python package for downloading multiple URLs at once Python package for downloading multiple URLs at once This package is a simple prerequisite of python-cads-api-client [1]. I aim to maintain the package myself, together with the reverse dependencies (python-api-cads-client and python-cdsapi). [1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1078809 signature.asc Description: PGP signature
Bug#920912: ITP: phat -- header-only library for boundary matrix reductions over Z/2Z
Package: wnpp Severity: wishlist Owner: Gard Spreemann * Package name: phat Version : 1.5 Upstream Author : Ulrich Bauer, Michael Kerber, Jan Reininghaus * URL : https://bitbucket.org/phat-code/phat * License : LGPL-3+ Programming Lang: C++ Description : header-only library for boundary matrix reductions over Z/2Z PHAT is a C++ library for performing the filtered Z/2Z (co)boundary matrix operations commonly needed when computing (persistent) (co)homology in topological data analysis. The library implements several of the state-of-the-art algorithms in the field of topological data analysis. As of version 1.5, the library seems to be slow-moving and solidified upstream. The package is useful as a fundamental tool in the mathematical field of topological analysis. Having stabilized upstream, and consisting only of headers and a simple standalone binary built from those, it should be easy to maintain by myself. I do need a sponsor. I will inquire with the sponsors of other packages I maintain.
Reusing source package name of long-removed, unrelated package
Hello, I filed an ITP (#920912) regarding a package I'm preparing. The upstream name for this package is "phat", which doesn't appear in the archives from jessie to the present day. After filing the ITP and uploading my package to mentors, I realized that there was an unrelated "phat" with a different upstream present in the archives from 2005 to 2014 [1]. It was removed from the archives because it was abandoned by upstream (#751276). I understand that 3.3.2 of the policy mandates that I at least bump the epoch, but I wanted to ask the list to make sure: is reusing the source package name of an unrelated, long-removed package like this OK, or should I consider using a different name? [1] https://tracker.debian.org/pkg/phat Best regards, Gard
Re: Reusing source package name of long-removed, unrelated package
Ian Jackson writes:
> Gard Spreemann writes ("Reusing source package name of long-removed,
> unrelated package"):
>> I understand that 3.3.2 of the policy mandates that I at least bump the
>> epoch, but I wanted to ask the list to make sure: is reusing the source
>> package name of an unrelated, long-removed package like this OK, or
>> should I consider using a different name?
>
> I would recommend using a different source package name.
Thanks for your input. I'll wait a bit and see if there are other
opinions before renaming the source.
By the way, is it OK if the (renamed) source package produces a binary
package with the same name as one of those produced by the old source?
Thanks.
Best,
Gard
Re: Reusing source package name of long-removed, unrelated package
(Apologies if you receive this message twice; I dropped a ball juggling
e-mail identities).
Ian Jackson writes:
> Julien Cristau writes ("Re: Reusing source package name of long-removed,
> unrelated package"):
>> I would say reusing binary package names is usually worse than reusing
>> source package names, in that it's a lot more likely to affect users.
>> Sometimes it happens anyway, but IMO it's best avoided.
>
> To an extent that depends how many people are likely to have had the
> previous binary package installed, still, and where it might be
> referred to (eg in dependencies). So the problem with reusing a
> binary package name becomes less severe, the longer the gap between
> the two uses of the name.
FWIW, popcon suggests the number of users declined steadily after the
removal, and has now plateaued at 15 [1].
> To Gard: waiting for a few more opinions and then deciding is a good
> plan.
Will do. Thanks for your feedback so far, everyone.
[1] https://qa.debian.org/popcon.php?package=phat
Best,
Gard
Re: Reusing source package name of long-removed, unrelated package
Ian Jackson writes:
> Julien Cristau writes ("Re: Reusing source package name of long-removed,
> unrelated package"):
>> I would say reusing binary package names is usually worse than reusing
>> source package names, in that it's a lot more likely to affect users.
>> Sometimes it happens anyway, but IMO it's best avoided.
>
> To an extent that depends how many people are likely to have had the
> previous binary package installed, still, and where it might be
> referred to (eg in dependencies). So the problem with reusing a
> binary package name becomes less severe, the longer the gap between
> the two uses of the name.
FWIW, popcon suggests the number of users declined steadily after the
removal, and has now plateaued at 15 [1].
> To Gard: waiting for a few more opinions and then deciding is a good
> plan.
Will do. Thanks for your feedback so far, everyone.
[1] https://qa.debian.org/popcon.php?package=phat
Best,
Gard
Preferred git branch structure when upstream moves from tarballs to git
Hi, For one of my packages, I maintain two public git branches: one is upstream/latest, where I've been importing upstream's released tarballs, and the other is debian/sid that contains the packaging. Recently, upstream has finally started using git. What is the recommended way for me to maintain a sane branch structure for the packaging repository while starting to use upstream's git master as the upstream branch to follow? (My first thought is to track upstream's master as upstream/latest-git or something, and start merging from that into debian/sid, but I don't know if there's a better way.) Best, Gard
Re: Preferred git branch structure when upstream moves from tarballs to git
My initial question resulted in a lot of useful advice and opinions, and spurred quite an interesting discussion. Thanks to everyone who contributed, and apologies for not contributing myself.
Re: Towards lapack / lapack64 packaging
Hi, Incidentally, and somewhat off-topic: Do you know if a similar effort is being made for the PETSc and SLEPc packages (src petsc and slepc)? Best, Gard
Re: Content Rating System in Debian
Bagas Sanjaya writes: > Regarding freedom, yes it can be affected by CRS because CRS can limit > freedom to use programs for some users > (particularly non-adults). But CRS limit such freedom in order to protect > psychology users for long term from negative > impacts of programs they used. Surely this would be a direct conflict with the DFSG? Best, Gard
Bug#932726: ITP: python-pyspike -- Python library for the numerical analysis of spike train similarity
Package: wnpp Severity: wishlist Owner: Gard Spreemann * Package name: python-pyspike Version : 0.6.0 Upstream Author : Mario Mulansky * URL : https://mariomulansky.github.io/PySpike/ * License : BSD-2-clause Programming Lang: Python, C Description : Python library for the numerical analysis of spike train similarity PySpike is a Python library for the numerical analysis of spike train similarity. Its core functionality is the implementation of the ISI-distance and SPIKE-distance as well as SPIKE-Synchronization. It provides functions to compute multivariate profiles, distance matrices, as well as averaging and general spike train processing. Mario Mulansky, Thomas Kreuz, PySpike - A Python library for analyzing spike train synchrony, SoftwareX, (2016), ISSN 2352-7110, http://dx.doi.org/10.1016/j.softx.2016.07.006. The library seems simple and mature, and I will be capable of maintaining it on my own. I will need a sponsor, and will enquire with the DDs that have sponsored packages for me in the past.
Re: tag2upload service architecture and risk assessment - draft v2
Scott Kitterman writes: > Several time people have said they feel it's important to be able to verify > from contents of the archive. Hi all, Please forgive my ignorance if this is stupid, or if it's already been discussed and I overlooked it. I'm not posing this as a suggestion, but rather as a way for me to help myself understand the technical aspects of this very interesting debate better. Why could there not be specified new (complementary, not superseding!) formats of .dsc and .changes files wherein those files are not expected to be signed themselves, but instead are expected to refer to signed git tags? When ftp-master sees this particular format, it could perform a shallow git clone of the required tag, verify it, and consider that as the source of the package. That source object in the archives is then verifiably from the signer, and requires no intermediate service (apart from the current problems of people changing keys etc.). Obviously I'm missing something here, and I feel I'd learn something interesting if someone could explain. Thanks, and sorry for the potential small distraction from the conversation. -- Gard
Clarification regarding Qt 4 removal (and #875036 in particular)
Hi, I maintain src:gudhi, which build-depends on libqglviewer-dev-qt5 and depends on libqglviewer2-qt5. Because of the Qt 4 removal, src:libqglviewer, which provides the two aforementioned binaries, seems to be marked for autoremoval (#875036), and thus src:gudhi too has been marked for autoremoval according to the tracker. Can someone help clarify why the Qt 4 removal causes all of src:libqglviewer to be marked for removal? Surely its Qt 5 binaries could stay? Is there any course of action I should take as maintainer of gudhi? I tried contacting the maintainer of libqglviewer a few weeks ago, but got no reply. Thanks for any pointers. Best, Gard
Re: Clarification regarding Qt 4 removal (and #875036 in particular)
Scott Kitterman writes: > On September 5, 2019 7:36:01 AM UTC, Gard Spreemann wrote: >>Can someone help clarify why the Qt 4 removal causes all of >>src:libqglviewer to be marked for removal? Surely its Qt 5 binaries >>could stay? > > All binaries from a source package are removed as a set, so if the Qt4 > packages are RC buggy, they all have to go. Ah, of course, that makes sense. Thanks. >>Is there any course of action I should take as maintainer of gudhi? I >>tried contacting the maintainer of libqglviewer a few weeks ago, but >>got >>no reply. > > You might investigate if there are remaining rdepends for the Qt4 > packages and if not, an NMU to drop them might be in order if you > continue not to hear from the maintainer. I see. The problem with that is I'm only a DM with uploading rights for a few packages. I'll try to contact the last uploader as well. Best, Gard
Re: allow missing description fields and empty long descriptions for Rust/etc packages?
Hi, Paul Wise writes: > […] since the Rust packages are basically only used as build-deps and > therefore have no human users. I just wanted to raise awareness that some of us humans do use librust-*-dev packages directly, having put cargo in permanent offline mode and having swapped out its cargo.io package source for Debian's packages on the local filesystem. Otherwise no objection to your overall point here. Best, Gard signature.asc Description: PGP signature
Re: allow missing description fields and empty long descriptions for Rust/etc packages?
Hi Johannes, Johannes Schauer Marin Rodrigues writes: > Quoting Gard Spreemann (2023-09-20 09:26:58) >> Paul Wise writes: >> > […] since the Rust packages are basically only used as build-deps and >> > therefore have no human users. >> I just wanted to raise awareness that some of us humans do use librust-*-dev >> packages directly, having put cargo in permanent offline mode and having >> swapped out its cargo.io package source for Debian's packages on the local >> filesystem. > > do you have more details on how you achieve this? > > I'm using Debian's rust packages instead of creates.io using this wrapper > script to cargo: > > https://salsa.debian.org/josch/nocrates.io/-/blob/master/cargowrapper.sh > > How do you do it? My ~/.cargo/config.toml reads: [net] offline = true [source] [source.crates-io] replace-with = "debian" [source.debian] directory = "/usr/share/cargo/registry" This works really well in my case. As far as smooth solutions for opting in to crates.io in particular circumstances, I and others have collected some notes on [1]. But in reality I get very far with the above Cargo config + manually adding the odd crate (or crate version) when it's not available in Debian. [1] https://stackoverflow.com/q/69802360/453616 Best, Gard signature.asc Description: PGP signature
Re: Bug#1041731: Hyphens in man pages
On October 16, 2023 2:41:08 AM GMT+02:00, "Trent W. Buck" wrote: >FWIW, there are lighter alternatives than pandoc: > >pandoc:After this operation, 174 MB of > additional disk space will be used. >sphinx-doc (sphinx-build -b man): After this operation, 140 MB of > additional disk space will be used. >rst2man (python3-docutils):After this operation, 37.6 MB of > additional disk space will be used. >pod2man (perl):perl is already the newest version > (5.36.0-9). > >I'm not going to bother measuring docbook ;-) I've also found scdoc to be a quite pleasant and very lightweight alternative: https://tracker.debian.org/pkg/scdoc -- Gard
Understanding what's missing for Rust dynamic linking (was: Proposal for how to deal with Go/Rust/etc security bugs)
Hello. Paul Wise writes: > On Thu, 2024-01-25 at 00:24 +, Wookey wrote: > >> People keep telling us (@ARM) how marvellous Rust is, and we keep >> telling them that it's useless in the real world until it sorts out >> the stable ABI/dynamic linking problem. > > IIRC that has been worked on for some years now, and IIRC > the static linking wiki page has some references about this. > > https://wiki.debian.org/StaticLinking This reminded me that I'm not even sure that I fully understand what Rust's remaining technical obstacles to achieving dynamic linking (at least within Debian) are. I'm ignoring the potential cultural or political issues that have been alluded to by others. My understanding – and please do correct me! – has been that three components are missing: (1) A stable ABI. (2) A way of dealing with generic types/functions across dynamic linking boundaries. (3) A way of dealing with macros across dynamic linking boundaries. From Debian's perspective, is really (1) all that important given that a stable release only has to deal with a specific version of the compiler? Could we not live with every new version of *just* rustc in sid introducing a transition with a rebuild of every Rust package? As for (2): Since Debian has the privilege of having a complete overview of the "closed system" of all Rust packages that we need to consider, could we not conceivably make a pass across all Rust packages in the entire archive and record every concrete version of every generic type/function ever used? Then when a particular library package is built, we would force the monomorphization of all the relevant types/functions in that shared library's public interface. This would require tooling support from upstream to force generation of monomorphized versions of types/functions when building each shared library, but that in itself does not seem impossible. (As a curious effect, the introduction of a new package may then trigger the need to rebuild some of its own dependencies due to new monomorphic versions of functions being needed that had not been seen in the archive before.) Similarly, for (3), could we expand every macro in every library as needed by every depending package in the archive? Just trying to get a handle on how far we are from a solution of sorts, apologies for any stupid questions. Best, Gard signature.asc Description: PGP signature
Re: xz backdoor
On 31 March 2024 12:39:55 CEST, Johannes Schauer Marin Rodrigues wrote: > >Another example is when I wanted to run a GUI program inside an unshared chroot >environment. Wayland does not seem to be happy about that and I didn't find a >way to test my GUI application successfully. But maybe my container environment >just fails to set up some things? Does there exist a way to test GUI >applications inside a container without requiring superuser privileges to run >the container? Hi, At least with (unprivileged) Podman containers, I have success with just passing the host's Wayland socket as a volume with the -v switch. -- Sent from my Android device with K-9 Mail. Please excuse my brevity.
Bug#977907:
Package: wnpp Severity: wishlist Owner: Gard Spreemann X-Debbugs-Cc: debian-devel@lists.debian.org, g...@nonempty.org * Package name: CLBlast Version : 1.5.1 Upstream Author : Cedric Nugteren and others * URL : https://cnugteren.github.io/clblast/clblast.html * License : Apache-2.0 Programming Lang: C++ Description : Tuned OpenCL BLAS library CLBlast is an OpenCL BLAS library that often can sometimes offer better performance than the clblas that's already in the archive. I will maintain the package, although I might also reach out to the science team.
Re: Fixed release dates are hurting quality
Andrey Rahmatullin writes: > On Sun, Feb 07, 2021 at 02:20:28PM +0100, Samuel Thibault wrote: >> > the packages being untouched for a long time in some cases meaning there is >> > no guarantee for quality. >> >> Sure, but if there is no serious issue left with the package, we can as >> well ship it. > Strictly speaking, there is a big logical error here. > If a package doesn't have RC bugs that doesn't mean it's fit for a > stable release, doesn't have serious issues, or even is usable. Wouldn't it be quite the massive paradigm shift to give up on the notion of tracking problems (= bugs), and instead try to track positive attributes like fitness for release, though? -- Gard signature.asc Description: PGP signature
Re: Fixed release dates are hurting quality
Adrian Bunk writes: > On Sun, Feb 07, 2021 at 05:19:17PM +0100, Gard Spreemann wrote: >> and instead try to track positive attributes like fitness for >> release, though? > > Can you provide a less lofty description of what you want to implement? I didn't suggest that anything be implemented. I (mis-)read the parent message as suggesting that instead of absence of bugs being sufficient for release, we should consider instead "presence of quality" (anti-bugs, if you will). That felt like a major paradigm shift, but I was misunderstanding. -- Gard signature.asc Description: PGP signature
Re: I'm orphan my packages and leave the project as maintainer
Timothy M Butterworth writes: > The FSF with out RMS would be like the Linux Foundations with out > Linus. To me, and I dare guess, to most people, the actions of RMS are not being weighted against the important contributions he has made. Many of us believe that he has crossed certain lines that cause his behavior to be a problem nomatter how enormous his contributions are. > With their personality quirks it is sometimes hard for some people to > like them but at the end of the day they get the job done. I hope that you do see that there is not a general agreement that the term "personality quirks" covers the behavior being dicussed. > RMS has done alot for FLOSS it would be sad to see his contributions > come to a halt but he can always write software and contribute that > way I guess. This is not a debate about whether or not RMS has done enough for free software for his behavior to be excused. -- Gard signature.asc Description: PGP signature
Re: Changed Github download URLs are affecting lots of existing watch files
Phil Morrell writes: > Sounds like you're asking for a new github redirector on qa.debian.org > as there is for sf.net, which could use the official api for stability. This got me thinking: the version checking mechanism of d/watch files is useless if the outside world changes, i.e. if upstream's URLs change. Why do we then ship this logic with the packages at all, when packages are meant to be useful for an extended amount of time? Would it not be better to decouple the version-checking aspect of d/watch entirely from the actual package tarball? Uscan could then unconditionally pull version information from something à la det the sf.net and PyPI redirectors. The data in that system is then kept updated when upstream changes. -- Gard signature.asc Description: PGP signature
Re: Cancel "culture" is a threat to Debian
Dmitry Smirnov writes: > Nobody is perfect. Everybody said a foolish thing at least once in a > lifetime. If we cancel those who love what they do, those who are good > with what they do, those who are passionate and caring for what they do > for something they have said somewhere else then eventually there will > be nobody left. In order to calibrate what is considered merely "a foolish thing said" from your perspective, I feel a need to ask: what is, from your perspective, the least of the sufficiently bad things that a person can do in order for Debian to officially call out said person's behavior? What is (roughly) the smallest offense that *you* would consider too bad for Debian to accept? Best, Gard signature.asc Description: PGP signature
Have the watch file checks stopped?
Hi list, Have the uscan watch file checks that feed qa.debian.org stopped? Is it on purpose? Perhaps a consequence of the recent release? Best, Gard signature.asc Description: PGP signature
Re: Have the watch file checks stopped?
Mattia Rizzolo writes: > On Mon, Aug 23, 2021 at 12:59:39PM +0200, Gard Spreemann wrote: >> Have the uscan watch file checks that feed qa.debian.org stopped? Is it >> on purpose? Perhaps a consequence of the recent release? > > That's one part that's included in the UDD downtime reported here: > https://lists.debian.org/debian-qa/2021/08/msg0.html Thanks, and sorry for the noise - I should have checked the QA list. -- Gard signature.asc Description: PGP signature
Consequences of the NEW queue's length [Was: Remove packages from NEW queue?]
Hi all. Johannes Schauer Marin Rodrigues writes: > slightly related question: if I upload a new version to NEW, will the Age of > the package be reset? I'm asking because my package has been in NEW for four > months already and I'd like to avoid loosing that place by an upload of a new > upstream version. Every time I see stories like this, I wonder what the consequences of the NEW queue's current workings are. This is *not* criticism of the heroic work of the FTP Masters, nor is it criticism of the objectives they have in processing the NEW queue. I do, however, worry that months of waiting to see the fruits of one's labor might be detrimental to attracting new contributors, or indeed to motivate already active ones. It also seems to be a not insigificant impediment to getting useful work, such as a SONAME bump, done quickly. At least personally, I find it harder to put in small pieces of work that result in incremental improvements if the result is having to wait months – with the added uncertainty of having to do it all again (for good reasons, but nevertheless). It may well be that I'm asking the impossible here, but it does seem to be a problem that other distributions don't suffer under to the same extent. Is it merely a matter of their standards being lower, or is there some room for improvement on our part? Apologies in advance if this is something that has been discussed a lot in the past. I'd be very interested in being pointed in the right direction in that case! Best, Gard signature.asc Description: PGP signature
Re: Consequences of the NEW queue's length [Was: Remove packages from NEW queue?]
Simon Richter writes: > Hi, > > On 11/18/21 4:08 PM, Stephan Lachnit wrote: > >> I guess this raises the (maybe already answered) question if the >> additional license QA from NEW is for the end-product (i.e. Debian >> stable) or for the servers that run the Debian infrastructure, which >> of course includes experimental. > > The latter. > > The license must allow Debian to redistribute the package. This is > checked very thoroughly on the initial upload, and updates are > expected to keep the same licensing. Whether that expectation still > holds with upstreams who prefer vendor copies over using external > packages is another matter, but in general these packages require more > handholding anyway. I struggle to see how this assumption is reasonable at all, even keeping vendoring upstreams out of the picture. It is hardly uncommon for non-giant projects to re-license themselves one or more times after the initial Debian package has cleared the NEW queue. The larger our archive, and the more time passes, the more packages we can expect to be shipping whose d/copyright's relationship with reality was never checked by the FTP Masters. -- Gard signature.asc Description: PGP signature
Re: Consequences of the NEW queue's length [Was: Remove packages from NEW queue?]
Andrey Rahmatullin writes: > On Thu, Nov 18, 2021 at 04:08:23PM +0100, Stephan Lachnit wrote: >> > > I don't know if that has been proposed before, but how about waiving >> > > the NEW queue requirement for experimental packages as a start? >> > > [...] Since packages in experimental will never land in any >> > > official release, I think dropping the NEW queue requirement has no >> > > negative impact. >> > This makes no sense as NEW is mostly about checking licenses. >> >> I think this is exactly why it makes sense. I think we can trust the >> DDs to not make any large mistakes (e.g. putting steam in main). > The existence of NEW means we currently don't, for completely new > packages. > >> Since packages in experimental aren't supposed to be used by anyone else >> but the DDs themselves, the "damage" of a potentially missing / wrong >> license is minimal, considering that DDs are aware of the fact that the >> packages aren't "official". > The "damage" that's usually being discussed is Debian distributing > something we can't, not users e.g. getting non-free software thinking it's > free. Packages in NEW aren't even publicly accessible because of this, > and discussions of switching to git-based source packages end with "we > can't publish git history of random repos as we don't want to review > and rewrite it". > >> However I find that view a bit weird. Any update can change the license >> or add new files with different licenses, nothing is ever checked by the >> ftp-masters (that would be insanity). > Sure. And in light of the above, assume: - Source package foo with a single binary package foo, entered Debian under thorough FTP Masters checking 20 years ago, has had a very active upstream and rapid development (including numerous rewrites and language changes) since then, but always just that single binary package. - Source package bar that ships a binary libbarN, entered Debian under thorough FTP Masters checking a few weeks ago after NEW queueing for months. Slowly developing upstream with few, very limited and organized, changes over time. Needs a SONAME bump. Or needs to add a new bar-utils binary, or something. If the goal is to maximize our users' confidence that foo and bar can be assumed DFSG-compliant, then it does not to me seem like the best use of our (FTP Masters') limited resources to subject bar to another thorough review (perhaps having it spend another 4 months in NEW?), while trusting the maintainer of foo with no further scrutiny. I'd go as far as to say that if we could not trust the maintainer of foo the way we do, we could not reasonably make Debian work. And if we can trust the maintainer of foo with a task where it's arguably easier to make a mistake than it is for the maintainer of bar, and we cannot trust the maintainer of bar in that safer case, then we are quite inconsistent. I would argue that this inconsitency is problematic, both because it leads to a misapplication of resources, because it may well convey a false sense of safety onto our users, and because it may be detrimental to attracting new volunteers. -- Gard signature.asc Description: PGP signature
Re: Looking for DDs to sign my keys in Norway, Bergen area
On November 22, 2021 5:24:57 PM GMT+01:00, Marius Gripsgard wrote: >Hi, > > >I am looking for someone to sign my keys, but due to covid this has not >been easy to do, so im looking for someone in my local area that would >be up to do a key signing. I have already looked at the offering page, >but none is close to me. (closed is oslo, this might be an option, but >its a 8H drive/train). If you are close to bergen, norway and are >willing to sign my key, please hit me up. > > >Thank you, > >Marius Gripsgard > Hi Marius, I'll be in Bergen the week before christmas, from Wednesday at least. I'm happy to sign your key if we can meet downtown at a reasonable hour. Let me know! Best, Gard -- Sent from my Android device with K-9 Mail. Please excuse my brevity.
Re: uscan roadmap
Paul Wise writes: > I also wonder if it is time to split debian/watch out of Debian source > packages, since upstream download locations generally change > independently of the Debian package and so information about upstream > download locations probably should be maintained independently. I very much agree. I don't understand the logic of tying upstream checking to a particular version of a source package. The fact that some version of a package once upon a time could locate and download new upstream versions using a particular recipe is of no use if said recipe becomes outdated at any later time. It makes a lot more sense to provide this service in a way that allows it to be modified/updated/improved/fixed with no regards to the actual packages that may use it. That could be as simple as a uscan service with watch files that can be individually and independently modified. Best, Gard signature.asc Description: PGP signature
Re: uscan roadmap
Jonas Smedegaard writes: > Quoting Gard Spreemann (2021-12-02 12:31:30) >> >> Paul Wise writes: >> >> > I also wonder if it is time to split debian/watch out of Debian >> > source packages, since upstream download locations generally change >> > independently of the Debian package and so information about >> > upstream download locations probably should be maintained >> > independently. >> >> I very much agree. I don't understand the logic of tying upstream >> checking to a particular version of a source package. The fact that >> some version of a package once upon a time could locate and download >> new upstream versions using a particular recipe is of no use if said >> recipe becomes outdated at any later time. >> >> It makes a lot more sense to provide this service in a way that allows >> it to be modified/updated/improved/fixed with no regards to the actual >> packages that may use it. That could be as simple as a uscan service >> with watch files that can be individually and independently modified. > > I find it helpful for our packages to include information about where > and how (at the time of its release) that package was monitoring for > upstream releases. It helps working decentralized - both for preparing > packages for Debian and for working on Debian-derived packages, both > without needing access to somewhere central for this "watch" > information. Would it make sense for a package to contain a snapshot of the relevant metadata in the hypothetical "centralized-and-often-updated watch service" at the time in enters into the archives? > Therefore I like the proposal to have Debian project scanners > aggressively look for _newest_ watch file for a packaging project, > including looking up declared Vcs-* hints for not-yet-released work. Indeed, that sounds like a better idea than what I suggest above! -- Gard signature.asc Description: PGP signature
Re: uscan roadmap
Jonas Smedegaard writes: > Quoting Gard Spreemann (2021-12-02 13:09:17) >> >> Jonas Smedegaard writes: >> >> > Quoting Gard Spreemann (2021-12-02 12:31:30) >> >> >> >> Paul Wise writes: >> >> >> >> > I also wonder if it is time to split debian/watch out of Debian >> >> > source packages, since upstream download locations generally >> >> > change independently of the Debian package and so information >> >> > about upstream download locations probably should be maintained >> >> > independently. >> >> >> >> I very much agree. I don't understand the logic of tying upstream >> >> checking to a particular version of a source package. The fact that >> >> some version of a package once upon a time could locate and >> >> download new upstream versions using a particular recipe is of no >> >> use if said recipe becomes outdated at any later time. >> >> >> >> It makes a lot more sense to provide this service in a way that >> >> allows it to be modified/updated/improved/fixed with no regards to >> >> the actual packages that may use it. That could be as simple as a >> >> uscan service with watch files that can be individually and >> >> independently modified. >> > >> > I find it helpful for our packages to include information about >> > where and how (at the time of its release) that package was >> > monitoring for upstream releases. It helps working decentralized - >> > both for preparing packages for Debian and for working on >> > Debian-derived packages, both without needing access to somewhere >> > central for this "watch" information. >> >> Would it make sense for a package to contain a snapshot of the >> relevant metadata in the hypothetical "centralized-and-often-updated >> watch service" at the time in enters into the archives? > > Not _instead_ of current location: What I find helpful is to have the > watch file available with the source package. I am unaware if there > would be some benefit of _additionally_ embedding the watch file in > binary packages (if that's what you meant). > > >> > Therefore I like the proposal to have Debian project scanners >> > aggressively look for _newest_ watch file for a packaging project, >> > including looking up declared Vcs-* hints for not-yet-released work. >> >> Indeed, that sounds like a better idea than what I suggest above! > > Not sure if you noticed, but (since I won't steal credit) I basically > emphasized Pabs' suggestion in last paragraph of what you previously > quoted: > > Quoting Paul Wise (2021-12-02 00:47:44) >> Alternatively, perhaps we could workaround outdated debian/watch files >> by having vcswatch extract debian/watch files from the repo specified >> in the Vcs-* URLs. Apologies; I somehow thought that he meant auto-generating watch files from *upstream* VCSs. My bad, and thanks for clarifying! -- Gard signature.asc Description: PGP signature
Re: What are the most important projects that Debian ought to work on?
Sébastien Delafond writes: > Hello, > > As part of an upcoming survey that we are preparing, we plan to ask > Debian developers to rank, by order of importance, the most popular > ideas of improvements for Debian. > > However, there's no easy way to identify what are the most popular ideas > of improvements that Debian ought to make. We know of the > "grow-your-ideas" project on Salsa, but it's far from exhaustive: > > https://salsa.debian.org/debian/grow-your-ideas > > That's where you come into play: it would be nice if you could share > what are — according to you — the most important projects/improvements > that Debian ought to make. You can share your ideas here by replying to > this email, but it would be interesting to file them as new issues in > the "grow-your-ideas" project and then reply here pointing to your new > issue: I've added https://salsa.debian.org/debian/grow-your-ideas/-/issues/11 about the NEW queue. Best, Gard signature.asc Description: PGP signature
Re: Lottery NEW queue (Re: Are libraries with bumped SONAME subject of inspection of ftpmaster or not
Jonas Smedegaard writes: > Quoting Vincent Bernat (2022-01-25 21:38:01) >> I didn't comment at first because I thought someone else would raise >> the idea. But it seems people still like the idea of a NEW queue. Not >> me. The NEW queue is a hindrance. > > For the record, I don't "like" the NEW queue. > > I don't like current copyright laws, and I suspect a fair amount of > people involved in Free Software doesn't. > > I just don't think the solution is to ignore copyright or licensing > statements. To me, the elephant in the room is this question: Does the way the NEW queue currently works provide good (good enough?) assurances to ourselves that we are *not* ignoring copyright or licensing? It feels like we are answering "yes" based on the amount of heroic work the FTP masters put in, and the amount of waiting developers have to suffer through. We're gauging our solution to a problem solely by the amount of effort, sweat and tears we put in, so to speak. Best, Gard signature.asc Description: PGP signature
Re: Lottery NEW queue (Re: Are libraries with bumped SONAME subject of inspection of ftpmaster or not
Adam Borowski writes: > On Tue, Jan 25, 2022 at 09:38:01PM +0100, Vincent Bernat wrote: >> For me, the copyright check is just a bad excuse. People upload >> non-distributable stuff everywhere and it seems the world continue to go >> round. What amount of non-distributable packages is stopped by the NEW >> queue? >> >> I think we should forego the NEW queue. If people want to check >> packages, they can do it once they are in unstable with regular bugs. > > Without the NEW queue, there would be no point at which packaging receives > any sort of review. I'd prefer Debian to deliver at least some level of > quality. > > Otherwise, we'd fall to the level of NPM. And there's ample examples what > that would mean. Is this not the job of the Policy and of community self-policing by means of RC bugs? Best, Gard signature.asc Description: PGP signature
Re: Please participate in Debian Med sprint (Was: 20 years of Debian Med list :-) and suggested sprint date)
Andreas Tille writes: > Hi again, > > I've just created a preliminary Sprint page[2]. At the top I've added a > table to summarise first responses of participants about the date. > Seems we have a vague preference for the date 2022-02-18 - 2021-02-20. > > I'd be really happy if more interested people would show up and add > the prefered date to get a final decision about the sprint date. I don't have push access to the repo, but feel free to add that I can probably join on the 18th and on the 20th of February, if you end up picking 18-20. -- Gard signature.asc Description: PGP signature
Re: LESS copyright, not more!
Adam Borowski writes: > Guys, once again we had a complaint about forcing people to waste their time > on copyright matters then wait months or years for review of said matters > -- just for the discussion degenerate into a proposal to bring even MORE > copyright into our life! > >> - What is REUSE? >> The REUSE specification [1] is a specification to make copyright >> machine-readable in the source files itself. It is straightforward to >> implement, add (e.g.) "SPDX-FileCopyrightText: 2019 Jane Doe > [...] >> The spec is made by the Free Software Foundation Europe (FSFE) and is >> already implemented in several projects [3]. > > ... and this proposal includes gems such as an extra copyright-only file per > every image. Dᴏ ɴᴏᴛ ᴡᴀɴᴛ! > > The Social Contract says clearly: > "Our priorities are our users and free software" > -- NOT copyright lawyers. > > I, and probably others, consider copyright to be a crime against humanity > -- and this is not just a figure of speech[1]. We are forced to comply > with these laws, risking fines and violence if we don't, but why should > we put more effort than the minimum necessary? To better protect our users as they exercise point 1 of the DFSG, obviously! We can disagree about what the right amount of such effort is, and its diminishing returns, but I don't see how the intention/objective itself is at question here. -- Gard signature.asc Description: PGP signature
Re: No mips64el porterbox?
Julien Puydt writes: > Hi, > > one of my package has a failure on mips64el and upstream is ready to > help me find the cause and debug the issue. > > Unfortunately, on https://db.debian.org/machines.cgi I only see five > developer machines on this architecture -- all buildd! > > Is there really no mips64el porterbox, or is it only a transitory > situation? Hi, How about eller.debian.org? $ uname -a Linux eller 4.19.0-18-octeon #1 SMP Debian 4.19.208-1 (2021-09-29) mips64 GNU/Linux $ lscpu Architecture:mips64 Byte Order: Little Endian -- Gard signature.asc Description: PGP signature
Re: isa-support -- exit strategy?
Bastian Blank writes: > On Sun, Apr 03, 2022 at 02:17:15PM +0300, Adrian Bunk wrote: >> SIMDe (or similar approaches) could be used to build variant(s) of the >> library that have compile-time emulation of SIMD instructions in the >> lower baseline builds of vectorscan. > > But why? Who in their right mind would ever try to use those aweful > slow implementations? I don't know in this particular case, but somewhat analogously: Very few people in their right minds do deep learning on CPUs. Yet, I'm extremely happy that PyTorch is in Debian (thanks to the hard work of Mo Zhou!), even if it's CPU-only. It means that I can develop and test-run code on my machine using just Debian packages, before shipping it off to the actual compute infrastructure where GPUs do the heavy lifting on a GPU-enabled non-Debian PyTorch. I can imagine that there are people who do the same with lacking SIMD instructions. Best, Gard signature.asc Description: PGP signature
Re: Bug#1012712: ITP: ai -- PHP library to develop easily SQL queries usable in web pages
Georges Khaznadar writes: > Package: wnpp > Severity: wishlist > Owner: Georges Khaznadar > X-Debbugs-Cc: debian-devel@lists.debian.org > > * Package name: ai > Version : 0.03 > Upstream Author : François Élie > * URL : https://gitlab.adullact.net/felie/ai > * License : AGPL > Programming Lang: PHP > Description : PHP library to develop easily SQL queries usable in web > pages > > AI is an Allmighty Intelligence: just think about the SQL query which > you would use in MySQL's command line, or in phpmyadmin, and AI offers you > the right code to display its results in a web page. Unfortunately, AI > can not yet read your mind directly: you've got to type the query. Hi, The proposed very generic, two-letter source package name "ai" seems like too prime namespace real estate for something like this, being an established initialism for a well-known and entirely unrelated concept. How about something along the lines of "allmighty-intelligence"? Best, Gard signature.asc Description: PGP signature
Bug#1017994: ITP: zigpy -- Python Zigbee stack
Package: wnpp X-Debbugs-Cc: debian-devel@lists.debian.org Owner: Gard Spreemann Severity: wishlist * Package name: zigpy Version : 0.50.1 Upstream Author : Russell Cloran and contributors * URL : https://github.com/zigpy/zigpy * License : GPL-3+ Programming Lang: Python Description : Python Zigbee stack zigpy is a hardware independent Zigbee protocol stack integration project to implement Zigbee standard specifications as a Python 3 library. Zigbee integration via zigpy allows you to connect one of many off-the-shelf Zigbee Coordinator adapters using one of the available Zigbee radio library modules compatible with zigpy to control Zigbee based devices. There is currently support for controlling Zigbee device types such as binary sensors (e.g., motion and door sensors), sensors (e.g., temperature sensors), lights, switches, buttons, covers, fans, climate control equipment, locks, and intruder alarm system devices. The package is useful for interacting over the increasingly widespread Zigbee home automation and IoT protocol. An RFP was made last year [1]. I intend to maintain the package myself. [1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1002638 signature.asc Description: PGP signature
Current NEW review process saps developer motivation [Was: Looking for new maintainer(s) for GStreamer packages]
On August 25, 2022 10:52:56 AM GMT+02:00, "Sebastian Dröge" wrote: >PS: To preempt any questions as for why, the background for my decision >to stop maintaining any packages is this thread, but it's really just >the straw that broke the camel's back > > https://alioth-lists.debian.net/pipermail/pkg-rust-maintainers/2022-August/022938.html > A bit off-topic, but I think we really ought to discuss (address?) this elephant in the room once more. I don't have the answers, but Sebastian's email yet again clearly illustrates how the status quo is hurting the project. This clear example comes in addition to worries raised before about what the status quo does to recruitment of new developers. PS: I do not imply that the elephant in the room is the ftpmasters. I'm thinking of the *process*. The people involved put in admirable work in carrying out said process. -- Sent from my Android device with K-9 Mail. Please excuse my brevity.
Re: Current NEW review process saps developer motivation [Was: Looking for new maintainer(s) for GStreamer packages]
Jonas Smedegaard writes: > Quoting Gard Spreemann (2022-08-26 08:49:21) >> On August 25, 2022 10:52:56 AM GMT+02:00, "Sebastian Dröge" >> wrote: >> >PS: To preempt any questions as for why, the background for my decision >> >to stop maintaining any packages is this thread, but it's really just >> >the straw that broke the camel's back >> > >> > https://alioth-lists.debian.net/pipermail/pkg-rust-maintainers/2022-August/022938.html >> > >> >> A bit off-topic, but I think we really ought to discuss (address?) >> this elephant in the room once more. I don't have the answers, but >> Sebastian's email yet again clearly illustrates how the status quo >> is hurting the project. This clear example comes in addition to >> worries raised before about what the status quo does to recruitment >> of new developers. >> >> PS: I do not imply that the elephant in the room is the >> ftpmasters. I'm thinking of the *process*. The people involved put >> in admirable work in carrying out said process. > > The way I see it, the process is clear: provide *source* to build from. > > If there is "source" built from another source, then that other source > is the true source. > > If ftpmasters sometimes approve intermediary works as source, then that > is not a reason to complain that they are inconsistent - it is a reason > to acknowledge that ftpmasters try their best just as the rest of us, > and that the true source is the true source regardless of misssing it > sometimes. > > Yes, this is painful. Yes, upstreams sometimes consider us stupid to > care about this. Nothing new there, and not a reason to stop do it. > > If you disagree, then please *elaborate* on what you find sensible - > don't assume we all agree and you can only state that the process is an > elephant. Apologies, I should have been a lot clearer. I did not mean the exact issue of what is the "true source" of something in a package. Rather, I was referring to the process itself (looking in particular to the last three paragraphs and the PS in Sebastian's linked email [1]). Whatever the correct answer to what a "true source" is, in the current process, a developer has to make an attempt at doing the right thing, and then wait *weeks or possibly months* to know for sure whether it was OK. And if it's deemed not OK, the reasoning may be entirely specific to the exact package and situation at hand, and therefore extremely hard to generalize and to learn from. (Do not construe the above as "ftpmasters should work faster and give more lengthy reasoning!" – adding *more* work to the process would make things even worse in my opinion.) Although I maintain a very small number of packages, and ones that also very rarely have to re-clear NEW, even I feel sapped of motivation from the process. And I read Sebastian's email partly as an expression of the same thing (apologies if I misconstrue your views, Sebastian). I do believe similar points of view have been aired on the list before by others too. As to your last point, elaborating on what I find sensible: I sadly don't have a good suggestion. I do believe it is possible to point out that the status quo is harmful without knowing how to sensibly fix it, though. That's what discussions are for :-) I am presently unable to find the message I'm thinking of, but I seem to recall one proposal being raised in the past: trust that a developer has done everything right, and introduce a class of bugs that can cause complete removal from the archive instead. Afterall, we do assume that the developer does the technical things correctly, until such a time as a bug is filed. Could we not also make the same assumptions for Policy and Social Contract things? [1] https://alioth-lists.debian.net/pipermail/pkg-rust-maintainers/2022-August/022938.html Best, Gard signature.asc Description: PGP signature
Re: Comments on proposing NEW queue improvement (Re: Current NEW review process saps developer motivation
"M. Zhou" writes: > To be honest, in terms of volunteered reviewing work, waiting > for several months is not something new. In academia, it may > take several months to years to get a journal paper response. Sure, but (1) that situation isn't popular in academia either, (2) at least you can put your work on arXiv or similar and have it be useful to people right away, and (3) a paper that's finally accepted (usually) doesn't ever have to be updated, and doesn't risk needing to go through the process again. And new papers don't require updates to old papers, usually. An analogy following from (3): how great fun it would be if a substantial paper correction would require no review from the publishing journal, but a title change would require a completely new peer review process! (Yes, the idea of a title change is far fetched, but still.) Seems a bit arbitrary to me. > I've ever tried to think of possible ways to improve the process, but > several observations eventually changed my mind, and I'm willing > to accept the status quo. > > * there is a trade-off between rigorousness and efficiency. > Any change in the process may induce disadvantages, where > the most difficult thing is to reach an agreement. > * we will add more work for ftp team if we get them involved in the > discussion of possible (but unsure) ways to improve NEW. > > My ultimate opinion on NEW processing is neutral, and my only > hope for ftp team is to increase the pace of hiring new members. > To be concrete, it is much harder to write a concrete proposal > to debian-vote@l.d.o than discussing possibilities. > > I understand we may have the enthusiasm to sprint on something. > However, in terms of the long-term endeavor on Debian development, > the negligible popcon number won't be less disappointing than > a long-term wait to clear the NEW queue. I don't think I'm worried about people being disappointed (by say an RC bug being filed due to a copyright issue – correctness is far more important than not being disappointed). I'm worried about the extremely long time horizons putting people off from contributing in the first place, because it requires focus and planning across a time gap that is so many orders of magnitude longer than the time spent doing the actual contributing work. In some sense, contributing to Debian becomes mostly about waiting. (Sure, there is something to be said about extremely short, fragmented attention spans being unhealthy – but some contributions are naturally short and easy, and we certainly don't want to drive those away.) > If one's enthusiasm on working on some package is eventually > worn out after a break, then try to think of the following question: > > Is it really necessary to introduce XXX to Debian? I hope we won't try to define what "necessary" means, or have it become a criterion for inclusion :-) > Must I do this to have fun? I don't think Debian contribution has ever been a necessary condition for fun. That's an incredibly high bar. If we were only to attract people whose only idea of fun was contributing to Debian, I think we'd become a very unhealthy project (and one severely lacking in contributors). > Strong motivations such as "I use this package, seriously" are not > likely to wear out very easily through time. Packages maintained > with a strong motivation are better cared among all packages in our > archive. I humbly disagree. Even from my own point of view, I may well be very motivated to package something I use seriously all the time, seriously. But then I see its dependency chain of 10 unpackaged items, start thinking about the probability that they'll *all* clear the NEW queue, and how long that would take, and I give up. And then there's the problem of attracting smaller contributions, as mentioned above: I really believe that people get put off from putting in 30 minutes of work for a nice MR on Salsa if they can't expect their work to hit the archives for months and months (suppose for example they contributed to a package whose SONAME is being bumped). > Why not calm down, and try to do something else as interesting > as Debian development when waiting for the NEW queue? Sure. That's what I do. My list of joyful and less joyful things to fill my days with is enormous. **BUT: I worry for the project if our solution to the problem at hand is "maybe just contribute less to Debian".** Is that really what we want? Best, Gard signature.asc Description: PGP signature
Re: Current NEW review process saps developer motivation
Paul Wise writes: > There are a lot of examples of busywork in Debian, such as documenting > licenses, packaging dependencies, removing non-free files that are only > in source packages, runtime selection of correct CPU instructions, > fixing build failures, porting reverse dependencies to newer versions > of APIs etc. All of these are things that contributors complain about > and get burned out by us requiring or even suggesting. All of them > however are necessary in some way. I think the requirements around > source and building are just another example of this. Indeed. But is it necessary that this busywork be checked in the way it's currently checked, as the package passes through NEW? Why does it only have to be checked this way when a package name changes or there's a new binary being built? The rest of the time we seem fine catching all of these kinds of things through bug reports. We trust each other not to violate Policy. If we do find violations, we file serious bugs, and expect those to be acted upon. But not if there's a new package name! Oh no, then we instead insist that related work stops, and have the developer wait for months for detailed manual review by overworked reviewers. Best, Gard signature.asc Description: PGP signature
Re: Current NEW review process saps developer motivation
Gard Spreemann writes: > Oh no, then we instead insist that related work stops Sorry, this was imprecise of me. We of course don't insist that related work stops. But I really fear that that is the consequence in a great many cases. -- Gard
Re: Comments on proposing NEW queue improvement (Re: Current NEW review process saps developer motivation
"M. Zhou" writes: > On Sat, 2022-08-27 at 09:50 +0200, Gard Spreemann wrote: >> >> I humbly disagree. Even from my own point of view, I may well be very >> motivated to package something I use seriously all the time, >> seriously. But then I see its dependency chain of 10 unpackaged >> items, >> start thinking about the probability that they'll *all* clear the NEW >> queue, and how long that would take, and I give up. And then there's >> the >> problem of attracting smaller contributions, as mentioned above: I >> really believe that people get put off from putting in 30 minutes of >> work for a nice MR on Salsa if they can't expect their work to hit >> the >> archives for months and months (suppose for example they contributed >> to >> a package whose SONAME is being bumped). > > I agree with your disagreement but I keep my opinion. My track record > involves maintaining loads of reverse dependency libraries. I've > already gone through all kinds of pains from the NEW queue and > eventually learned to take a break immediately after uploading > something to new. > I consider you quite the hero for your massive contributions to the Debian deep learning ecosystem. But I do worry that there aren't enough Mo Zhous in the world ;-) > That said, if someone presents a GR proposal I'll join. In Debian, > it is not that easy to push something forward unless it hurts everyone. > Our NEW queue mechanism has been there for decades, and people are > already accustomed to it (including me). From multiple times of > discussion in the past, I don't see the NEW queue problem hurting > too many people. If nothing gets changed in the NEW queue mechanism, > people may gradually get used to it, following the "do not fix it > if it ain't wrong" rule. The voice will gradually vanish. … or people quietly vanish from contributing. Best, Gard signature.asc Description: PGP signature
GPL for package under MIT license upstream; repack?
Hello, A package I maintain (src:gudhi) was mostly under GPL-3+ up to and including the current version in the archives. Since then, upstream has switched to an MIT license, but with the caveat that many parts of the code has GPL dependencies and that "for practical purposes this code is GPL-3 for the user" [1]. Instead of having to carefully figure out precisely which parts of the code should be considered GPL for the Debian package, I'm tempted to consider the whole codebase GPL for this purpose. Does this sound sane? Are there some particular steps I should follow? Should I create a Debian repack of the source where every file's copyright header reflects the above, or do I only need to do this for (header) files included in the binary packages? Or does it suffice for d/copyright to reflect it? Any advice is appreciated. [1] http://gudhi.gforge.inria.fr/licensing/ Best, Gard
Re: GPL for package under MIT license upstream; repack?
Filippo Rusconi writes: > Greetings, > > On Tue, Sep 24, 2019 at 10:41:07AM +0200, Gard Spreemann wrote: >>Hello, >> >>A package I maintain (src:gudhi) was mostly under GPL-3+ up to and >>including the current version in the archives. Since then, upstream has >>switched to an MIT license, but with the caveat that many parts of the >>code has GPL dependencies and that "for practical purposes this code is >>GPL-3 for the user" [1]. > >From the page you provide a link to, the following shows little understanding >of > licensing issues: > > 8< > > GPLv3 is a Copyleft license that gives the user the right to use, copy and > modify the code freely for non-commercial purposes. > > >8 Oh, yeah, I missed that on the license page. I'll raise it as an issue with upstream. > Maybe you would like to ensure with them that they understand what they are > doing with this mixing of modules/licenses. I did have a short discussion with them regarding the topic in general [2]. [2] https://lists.gforge.inria.fr/pipermail/gudhi-users/2019-September/000320.html Thanks for your feedback. Best, Gard
Re: GPL for package under MIT license upstream; repack?
Colin Watson writes: > On Tue, Sep 24, 2019 at 10:41:07AM +0200, Gard Spreemann wrote: >> A package I maintain (src:gudhi) was mostly under GPL-3+ up to and >> including the current version in the archives. Since then, upstream has >> switched to an MIT license, but with the caveat that many parts of the >> code has GPL dependencies and that "for practical purposes this code is >> GPL-3 for the user" [1]. >> >> Instead of having to carefully figure out precisely which parts of the >> code should be considered GPL for the Debian package, I'm tempted to >> consider the whole codebase GPL for this purpose. >> >> Does this sound sane? Are there some particular steps I should follow? >> Should I create a Debian repack of the source where every file's >> copyright header reflects the above, or do I only need to do this for >> (header) files included in the binary packages? Or does it suffice for >> d/copyright to reflect it? > > I don't think you need to (or even should) change the licence notices on > individual files. But if I don't even change this in the header files (installed with libgudhi-dev), isn't there a significant risk that I will mislead Debian users into thinking that they may use every part of the GUDHI library under the MIT? Best, Gard
Re: doxygen 1.8.16 is ready for unstable, 10+ packages will FTBFS on amd64
Hi, Paolo Greppi writes: > The 10 remaining packages all fail with latex-related errors. > Unfortunately I know nothing about latex so I cant' help with those. > But I filed bugs or updated the existing open bug: > - ccfits, "Overfull \hbox" latex error, see: https://bugs.debian.org/943423 > - fltk1.3, "! Undefined control sequence." latex error, see: > https://bugs.debian.org/943426 > - frobby, LaTeX Error: File `listofitems.sty' not found, see: > https://bugs.debian.org/921300 > - lapack, easy to fix by just removing one line from d/rules, see: > https://bugs.debian.org/943431 > - librostlab, LaTeX Error: File `listofitems.sty' not found, see: > https://bugs.debian.org/943420 > - libstxxl, LaTeX Error: File `listofitems.sty' not found, see: > https://bugs.debian.org/921298 > - openms, "! Undefined control sequence." latex error, see: > https://bugs.debian.org/943450 > - ppl, "! Undefined control sequence." latex error, see: > https://bugs.debian.org/943451 > - qevercloud, LaTeX Error: File `listofitems.sty' not found, see: > https://bugs.debian.org/921297 > - sdformat, LaTeX Error: File `listofitems.sty' not found, see: > https://bugs.debian.org/943421 Do the listofitems.sty-related errors go away if you build-depend on texlive-plain-generic? Best, Gard
Bug#943817: ITP: ripser -- Fast computation of persistent homology of Vietoris-Rips complexes
Package: wnpp Severity: wishlist Owner: Gard Spreemann * Package name: ripser Version : 1.1 Upstream Author : Ulrich Bauer * URL : http://ripser.org * License : MIT Programming Lang: C++ Description : Fast computation of persistent homology of flag complexes Ripser computes persistent homology of flag complexes (such as Vietoris-Rips complexes) only, allowing significant gains in computation time and memory usage. See https://arxiv.org/abs/1908.02518. The package is widely used in the field of topological data analysis. It is mature, slow-moving and has very few dependencies. I will be maintaining the package for myself. I would currently need a sponsor, but I am in the process of becoming a DD.
Bug#949381: ITP: python-pot -- Python optimal transport library
Package: wnpp Severity: wishlist Owner: Gard Spreemann * Package name: python-pot Version : 0.6.0 Upstream Author : Rémi Flamary * URL : https://github.com/rflamary/POT/ * License : MIT Programming Lang: Python, C++ Description : Python optimal transport library Python library with solvers for optimization problems related to optimal transport. The library seems useful in its own right. My primary motivation for packaging it will become a dependency of GUDHI [1] as of that package's next upstream version. I will maintain the package myself. I currently would require a sponsor. However, my DD process is almost complete, and if the outcome is positive I would not require a sponsor to upload. [1] https://tracker.debian.org/pkg/gudhi
Bug#950783: ITP: python-cdsapi -- Python interface for the ECMWF CDS API
Package: wnpp Severity: wishlist Owner: Gard Spreemann * Package name: python-cdsapi Version : 0.2.5 Upstream Author : ECMWF * URL : https://pypi.org/project/cdsapi * License : Apache-2.0 Programming Lang: Python Description : Python interface for the ECMWF CDS API Python library for the API of the European Centre for Medium-Range Weather Forecasts' (ECMWF) Climate Data Store (CDS). More information about the CDS can be found on https://cds.climate.copernicus.eu I plan to maintain the package myself.
Re: Overinterpretation of DFSG? QR code for receiving donation is non-free???
Jeremy Bicha writes: > Let's say I take a photo of myself to include in an app so that users > can appreciate what I look like. What is the "preferred form of > modification"? If it's 15 years later and I no longer look the same, > would I edit the photo with free software to make it look like me or > would I just take another photo? Or, another example that I can imagine plausibly arising in practice: suppose a terrabyte of raw data was collected from a scientific experiment or simulation in order to produce (among other things) a plot in the form of a 100 KB image that it is useful to distribute in documentation that goes along with some DFSG-free code. Clearly the "preferred form of modification" is the raw data, together with the code that processed it, but it seems unpractical to expect the maintainer to go through a laborious process that perhaps even requires highly specialized expertise in order to distribute the raw data and reassemble the plot from it. -- Gard
Re: Overinterpretation of DFSG? QR code for receiving donation is non-free???
Mo Zhou writes: > On Wed, Apr 01, 2020 at 10:37:07AM +0200, Gard Spreemann wrote: >> Or, another example that I can imagine plausibly arising in practice: >> suppose a terrabyte of raw data was collected from a scientific >> experiment or simulation in order to produce (among other things) a plot >> in the form of a 100 KB image that it is useful to distribute in >> documentation that goes along with some DFSG-free code. Clearly the >> "preferred form of modification" is the raw data, together with the code >> that processed it, but it seems unpractical to expect the maintainer to >> go through a laborious process that perhaps even requires highly >> specialized expertise in order to distribute the raw data and reassemble >> the plot from it. > > In this case I agree that distributing the resulting image as is, is the > sensible thing to do. Another thing came up in my mind, quite > interesting, is that if the resulting product is a pre-trained neural > network, I get completely reversed conclusion ... > > Further, some neural networks are trained from the wikipedia dump > (CC-licensed). Are we uploading wikipedia dumps to the archive when our > users need to use these models? > > What's the essential difference between a jpg picture and a pretrained > neural network then? They are both multi-dimensional numerical arrays > from an abstract perspective, but a normal human can understand and > modify the picture pixels, while not being able to understand or modify > the network prarameters. Indeed. So we have a situation where there's 100% DFSG free code, 100% DFSG free data, and 100% DFSG free output produced with those, using perhaps vast and expensive computational resources. It seems to me to be a bit of a shame if this overinterpretation of the DFSG, or perhaps the lack of an update to the DFSG to account for this reality, would mean said output cannot be distributed and duplicated for the greater good in Debian. -- Gard
Re: Salsa update: no more "-guest" and more
Bernd Zeimetz writes: > On 4/25/20 10:05 PM, IOhannes m zmölnig (Debian/GNU) wrote: >> On 4/25/20 8:34 PM, Bernd Zeimetz wrote: >>> Hi, >>> >>> https://docs.gitlab.com/ee/security/two_factor_authentication.html >>> >>> Enforce that (if Salsa is doing that in the meantime, ignore me). >> >> i hope you don't suggest to enforce 2FA system-wide for all users of salsa. >> i read you original mail as a requirement to enforce 2FA for users who >> want to use salsa as an authentication provider for their own >> applications (which is fine with me) > > > Actually I think 2FA should be enforced for everybody. > Even debian.org related passwords might get lost. Right, but what's the threat model here? For some of us, losing the Salsa password is essentially only possible if we have had our PGP dongle or offline private key backup compromised. In this case, the attacker can sign uploads to the archive anyway, which is arguably more serious than a compromised Salsa account. -- Gard
Re: RFC: threading-aware virtual BLAS/LAPACK
Mo Zhou writes: > Please comment: > 1. Do we have a better solution where we can retain high performance and > avoid threading trouble at the same time? > 2. If we don't have a better solution, is my proposal acceptable? > 3. In which way can my proposal be improved? Hi Mo, Your proposal seems sane to be, and a real service to the users! However, I am a little bit worried about the maintenance burden you are setting up for the future; may it be promising too much to the users to provide every single combination? Since this is BLAS, one could imagine adding yet another couple of versions for each of the options, targeting ever fancier vector instructions, etc. – at what point are special needs best left to the user to cover? I wish I had more constructive criticism. Thanks for the work! An aside: do autopkgtest or other CIs currently test packages with varied combinations of BLAS/LAPACK providers? Best, Gard
Temporary(?) bundling of code that may not warrant its own package
Hi list, Upstream for a package I maintain has as of its latest release started bundling and requiring a third-party header-only library. I am considering packaging that third-party library (it's useful to me, at the very least) but I think it's a borderline case of whether it warrants being a package on its own. In particular, it does not do versioned releases, and it comes with no documentation (though its use is clear if one is well-versed with the academic side of what the library does and one inspects the header files). In light of this, I am tempted to – at least temporarily – accepting the bundling from upstream until such time as the bundled library becomes more fit for separate packaging, or I go ahead package it anyway. I would track the bundling as a bug and act on it when/if a separate package enters Debian. Is this within the realm of acceptable bundling? Best, Gard
Re: Temporary(?) bundling of code that may not warrant its own package
Wookey writes: > On 2020-05-20 10:16 +0200, Gard Spreemann wrote: >> Hi list, >> >> Upstream for a package I maintain has as of its latest release started >> bundling and requiring a third-party header-only library. I am >> considering packaging that third-party library (it's useful to me, at >> the very least) but I think it's a borderline case of whether it >> warrants being a package on its own. In particular, it does not do >> versioned releases, and it comes with no documentation > > I don't think those are reasons particularly in favour of > bundling. Plenty of software doesn't do proper releases any more. Just > use 0~ type versioning to allow for them eventually doing a > release 0.1 or whatever. Again obscure software is quite often poorly > documented - you are expected to know the field. Thanks your feedback. Is there any community consensus on putting the bundling in place temporarily while the separate package is held up in NEW? Being the maintainer of both, I would be able to quickly react to the separate package having cleared NEW, and rid the other package of its bundled copy. > If it is useful beyond this one package (and it sounds like it is) I'd > just package it. A headers-only library is relatively quick and easy to do. > >> I would track the bundling as a bug and act on it when/if a separate >> package enters Debian. > > Would you necessarily notice when another package using this > dependency enters the archive? Another package using another bundled copy of the package-to-be, or another package using my package's bundled copy? In the former case I'd hope that that package's maintainer would notice and keep track of my ITP. In the latter I'd hope they'd be aware of my package's bundling bug. Best, Gard
Re: RFC: threading-aware virtual BLAS/LAPACK
Mo Zhou writes:
> Hi fellow devs,
>
> I've suddenly got some inspiration on this problem, which resulted in a
> much better solution for the problem the original proposal confronts.
>
> I like this overhauled solution.
>
> No extra shared libs, no extra SONAMEs. No extra burden for the
> BLAS/LAPACK maintainers. Minor patching work for maintainers with
> special demands.
>
> --- New solution ---
>
> 1. BLAS providers create new directory under
> /usr/lib//libblas-/
>and put another copy of their alternative symlinks into the
>directories.
>
>e.g. libopenblas-pthread provides the extra symlink:
> /usr/lib//libblas-pthread/libblas.so{,.3}
>
> 2. Maintainers of reverse dependencies, when they have specific
>requirement on the threading implemetation, add the
> /usr/lib//libblas-/
>directory to the RPATH property of the resulting ELF binaries.
>In that way the programs can use the BLAS implementation without
>worring about the uncertainty of the alternatives configuration.
>
>Other packages insensitive to the threading implementations will
>use the libblas.so.3 in the global scope:
> /usr/lib//libblas.so.3 (a symlink)
>
> --- end solution ---
>
> That's it, much simpler and much more efficient than my first version.
>
> Comments please?
Would it make sense for DH to acquire functionality to automate dealing
with this?
> On Wed, May 13, 2020 at 10:54:00PM +0200, Gard Spreemann wrote:
>>
>> An aside: do autopkgtest or other CIs currently test packages with
>> varied combinations of BLAS/LAPACK providers?
>
> No. But that's easy to implement.
>
> For example, we can add the following test cases in the autopkgtest
> control file of openblas:
>
> Test-Command: run-numpy-unit-test.sh
> Depends: libopenblas-pthread-dev
>
> Test-Command: run-numpy-unit-test.sh
> Depends: libopenblas-openmp-dev
>
> Test-Command: run-numpy-unit-test.sh
> Depends: libopenblas-serial-dev
>
> In this way we BLAS/LAPACK maintainers can immediately spot regressions
> in important packages. (adding these tests seems like my work)
D'oh, I should have thought of that. Thanks!
-- Gard
Re: Temporary(?) bundling of code that may not warrant its own package
Wookey writes: > On 2020-05-20 13:42 +0200, Gard Spreemann wrote: >> >> Wookey writes: > >> Is there any community consensus on putting the bundling in place >> temporarily while the separate package is held up in NEW? Being the >> maintainer of both, I would be able to quickly react to the separate >> package having cleared NEW, and rid the other package of its bundled >> copy. > > Would you not just put them both into NEW at approx the same time, > library first? In practice no-one will stop you bundling in the > initial upload, then uploading the separate library, then removing the > bundle in a second upload of the main package once the library is > through NEW. But that's more work that just doing it right in the first > place. Ah, but one of the packages is in Debian and has been for a while. It's just that the latest upstream version of *that package* has started bundling a third-party library that wasn't used in any way before. Now the question is do I package the software the upstream bundles (the one without proper releases or documentation)? If so, may I allow the bundling until such time as that package (the one that is bundled by upstream) clears NEW? Sorry for the confusion. Best, Gard
Re: Temporary(?) bundling of code that may not warrant its own package
Adam Borowski writes: > If, for whatever reason, you feel urgency, the ftpmasters are very good at > prioritizing your needs. There's just no information attached to packages > normally -- you need to let them know. One way is popping up in #debian-ftp > and whining. > > I've never had them refuse a request to speed up a review. A package stuck > in NEW is stalling further work? Ask to prioritize. A package is job > related and your manager wants it in? A derivative is about to freeze? A > customer requested a backport? All of these are valid reasons. I had no idea. I guess I'll try to ask them nicely. Thanks! -- Gard
Bug#961784: ITP: hera -- Library for computing bottleneck and Wasserstein distances between persistence diagrams
Package: wnpp Severity: wishlist Owner: Gard Spreemann * Package name: hera Version : 0~git20200309 Upstream Author : Arnur Nigmetov * URL : https://github.com/grey-narn/hera * License : BSD-3-clause Programming Lang: C++ Description : Library for computing bottleneck and Wasserstein distances between persistence diagrams Hera is a header-only library that implements algorithms from Michael Kerber, Dmitriy Morozov, and Arnur Nigmetov, "Geometry Helps to Compare Persistence Diagrams.", Journal of Experimental Algorithmics, vol. 22, 2017, pp. 1--20. (conference version: ALENEX 2016). that exploits geometry to compute Wasserstein and bottleneck distances between persistence diagrams much faster than plain matching-based algorithms. The library is being packaged because it is now an upstream dependency of GUDHI (src:gudhi). I intend to maintain the package myself.
Lintian status reporting on packages overview broken?
Hello list, It seems to me that the "Lintian E+W" column on the QA packages overview page currently incorrectly shows a checkmark even when there are Lintian warnings for a package. Is this a known bug? Best, Gard signature.asc Description: PGP signature
Re: DEP-14: renaming master to main?
Michael Biebl writes: > there has been a lot of talk recently about how master is a loaded term > that should be avoided. > If I read the news correctly, github and others are going to change the > default master branch to main. > I don't really have any strong opinion on that matter myself. > > That said, what I care about is consistency and predictability across > the archive. > If we deem that "main" is a better term, should we change the defaults > in salsa/gitlab and maybe update DEP-14? Since DEP-14 already accepts naming according to release codenames, perhaps recommending debian/sid for the main development branch would be a better course of action? Best, Gard
Re: Nitrokey for DDs
Zlatan Todorić writes: > I saw there was mention of GNUK and Yubikeys but I didn't see anyone > mentioned Nitrokey. > > https://www.nitrokey.com/ > > They are a small German-based vendor, producing some nice products > (among other "keys") and they (AFAIK) are doing it all in FLOSS spirit > (aka they released everything in open). > > https://github.com/nitrokey I'll throw in my personal anecdote about Nitrokey. I've used their NitroKey Pro (first gen.) for many years now, and I continue to be very happy with the product. Most importantly, I found the people very helpful: I once lost the cap that protects the plug (it didn't fall off, I left it behind on a train), emailed them and was promptly supplied with several replacements for free without even being charged for international shipping. -- Gard signature.asc Description: PGP signature
Problems with the CI infrastructure?
Hi, I must admit I don't know much about the CI/autopkgtest infrastructure, but I've noticed over summer that the frequency at which my packages are being tested has decreased a lot, especially when it comes to ordinary tests in unstable (as opposed to tests that pick a few packages from experimental). Has there been some change to the CI infrastructure? Is it experiencing problems? Am I just missing something? Best, Gard signature.asc Description: PGP signature
Re: how to add small console application to debian linux distribution?
pe pi writes: > 1) Open Terminal > > 2) Type: sudo nano /etc/default/grub > > 3) Find the line starting with GRUB_CMDLINE_LINUX_DEFAULT, and add > video=hyperv_fb:[the resolution you want]. >So my line ends up looking like this: > GRUB_CMDLINE_LINUX_DEFAULT="quiet splash video=hyperv_fb:1366x768" > > 4) Write the changes and quit nano > > 5) Run: sudo update-grub > > 6) Reboot the virtual machine run: sudo reboot > > ... and i have developed console application which do it this way ... > > sudo hypervscrres --set grub 1366x768 update reboot yes > > ... and all application variants of use looks like this ... > > sudo hypervscrres --help > sudo hypervscrres --get grub > sudo hypervscrres --set grub 1366x768 > sudo hypervscrres --set grub 1366x768 update > sudo hypervscrres --set grub 1366x768 update reboot > sudo hypervscrres --set grub 1366x768 update reboot yes > yes | sudo hypervscrres --set grub 1366x768 update reboot Hello, Are you sure that potential users of your program will find it easier to install your program and run it than it is to perform the original task that your program is meant to replace? -- Gard
Bug#972680: ITP: eagerpy -- Wrapper around various Python multidimensional array types
Package: wnpp Severity: wishlist Owner: Gard Spreemann X-Debbugs-Cc: debian-devel@lists.debian.org, g...@nonempty.org * Package name: eagerpy Version : 0.29.0 Upstream Author : Jonas Rauber * URL : https://eagerpy.jonasrauber.de/ * License : MIT Programming Lang: Python Description : Wrapper around various Python multidimensional array types EagerPy is a Python framework that lets you write code that automatically works natively with PyTorch, TensorFlow, JAX, and NumPy. The package is useful because it allows you to abstract away various types of multidimensional arrays and write common code. I will maintain the package, although I might also reach out to the science team.
Bug#838381: ITP: ripser -- Software for computing persistent homology of Vietoris-Rips filtrations
Package: wnpp Severity: wishlist Owner: Gard Spreemann * Package name: ripser Version : 1.0.1 Upstream Author : Ulrich Bauer * URL : http://ripser.org * License : LGPL-3.0+ Programming Lang: C++ Description : Software for computing persistent homology of Vietoris-Rips filtrations Ripser is specialized in computing persistent homology of Vietoris-Rips filtrations, useful in the mathematical field of applied algebraic topology, very efficiently. It does not aim for the generality of for example PHAT, but takes advantage of the special filtration outperform more general software. Ripser is useful to people doing work in topological data analysis and applied topology in general, and is a self-contained small program whose package should be relatively easy to maintain. I would need a sponsor for the package. Best regards, Gard Spreemann
Bug#840686: ITP: gudhi -- C++ template library for topological data analysis
Package: wnpp Severity: wishlist Owner: Gard Spreemann * Package name: gudhi Version : 1.3.1 Upstream Author : Gudhi project / INRIA * URL : http://gudhi.gforge.inria.fr/ * License : GPL-3+ Programming Lang: C++ Description : C++ template library for topological data analysis The GUDHI library is a generic open source C++ library for Topological Data Analysis (TDA) and Higher Dimensional Geometry Understanding. The library offers state-of-the-art data structures and algorithms to construct simplicial complexes and compute persistent homology. The GUDHI library is developed as part of the GUDHI project supported by the European Research Council. I have initial packaging of the libgudhi-dev (the headers for this template-based library) done, and will add the comprehensive set of examples later. I would need a sponsor. Best regards, Gard Spreemann
Bug#852376: ITP: tikzit -- Graphical tool for rapidly creating and editing node-and-edge style graphs in TikZ.
Package: wnpp Severity: wishlist Owner: Gard Spreemann * Package name: tikzit Version : 1.0 Upstream Author : Aleks Kissinger * URL : http://tikzit.sourceforge.net/ * License : Mostly GPL-3+, some LGPL-2+ Programming Lang: Mostly Objective C Description : Graphical tool for rapidly creating and editing node-and-edge style graphs in TikZ. TikZiT is a graphical tool for rapidly creating and editing node-and-edge style graphs. It was originally created to aid in the typesetting of "dot" diagrams of interacting quantum observables (see arXiv:0906.4725), but can be used as a general graph editing program. I used to maintain a version of this software in an Ubuntu PPA that was moderately popular. To this day a few people e-mail me requesting updated versions of the software, so I believe this package will be useful. There was little development following the 2013 release of version 1.0. However, development has recently restarted and a version 1.1 appears to be forthcoming. I would need a sponsor for the package.
Bug#811069: ITP: lbfgsb -- Limited-memory quasi-Newton bound-constrained optimization
Package: wnpp Severity: wishlist Owner: Gard Spreemann * Package name: lbfgsb Version : 3.0 Upstream Author : Ciyou Zhu, Richard Byrd, Jorge Nocedal, Jose Luis Morales * URL : http://users.iems.northwestern.edu/~nocedal/lbfgsb.html * License : BSD-3-clause Programming Lang: Fortran Description : Limited-memory quasi-Newton bound-constrained optimization The library is a widely used implementation of a bounded, limited-memory BFGS algorithm. A search on codesearch.debian.net reveals that at least the following packages in Debian bundle duplicates of the code: - python-scipy (see also #778635) - vxl - nwchem - plastimatch - psi4 I believe that Debian should provide lbfgsb as a standalone library, as it is useful in its own right and its presence could lead to code deduplication in the future. Note that upstream's tarball (http://users.iems.northwestern.edu/~nocedal/Software/Lbfgsb.3.0.tar.gz) contains a few prebuilt binaries, and is also a minor tarbomb. Upstream seems very inactive in the sense that the code appears to be "done". I have maintained a package for personal use since 2013 and have never experienced problems. I thus feel I could handle maintaing the package also for a wider user base going forward. I would need a sponsor.
Re: Bits from DPL / Feedback on attracting newcomers
Marc Haber writes: > On Tue, 10 Dec 2024 09:18:06 +0100, Gard Spreemann > wrote: >>The BTS is core to Debian. > > And it is one of the best Bugtrackers I have ever encountered. I agree. > It could be faster, yes, but its features trump the waiting time by > far. Without knowing anything about the internal workings of the BTS: It seems we could have a lot more responsiveness without giving up any of those features. Best, Gard signature.asc Description: PGP signature
Re: Bits from DPL / Feedback on attracting newcomers
Since several people seem to be sharing their experiences with (undesirable) challenges in becoming a DD, I thought I'd add a point that seemingly hasn't been covered yet: The BTS is core to Debian. It is e-mail based. While I personally think e-mail-based workflows can be quite nice, the BTS' asynchronous nature did cause me a lot of extra pointless work when I was an outsider attempting to learn the ropes. Being not 100% confident with the system, I way too often found myself waiting minutes – as much as 10 or 15 – for replies to simple operations. Not only because being assigned a bug number is actually necessary in order to move on with some processes like initial packaging, but also because of the mental toll that comes from not knowing that a past operation successfully completed, and worrying that I'd have to return to it. Admittedly, I still feel like that at times, some six years later (a DD for four). I suspect that this highly asynchronous nature of the BTS significantly puts off new contributors. This is not meant as an argument against e-mail based systems (although I do suspect that that is also a hindrance to some new contributors). Nor is it meant to suggest that we need to embrace instant gratification. We certainly should not – but it is not unreasonable to expect to be able to see a syntax error in bug report modification without waiting ten minutes. Just my 0.1 monetary units. Best, Gard signature.asc Description: PGP signature
Re: Bits from DPL / Feedback on attracting newcomers
Andrey Rakhmatullin writes: > On Tue, Dec 10, 2024 at 09:18:06AM +0100, Gard Spreemann wrote: >> Since several people seem to be sharing their experiences with >> (undesirable) challenges in becoming a DD, I thought I'd add a point >> that seemingly hasn't been covered yet: >> >> The BTS is core to Debian. It is e-mail based. While I personally think >> e-mail-based workflows can be quite nice, the BTS' asynchronous nature >> did cause me a lot of extra pointless work when I was an outsider >> attempting to learn the ropes. Being not 100% confident with the system, >> I way too often found myself waiting minutes – as much as 10 or 15 – for >> replies to simple operations. > > TBH there is a difference between "email based and asynchronous" and > "needs at least 10 minutes to process a request". It seems to be a problem > specific to the BTS. Absolutely. I of course also don't know whether it's just my e-mails taking 10 minutes to reach the BTS, but I would suspect that a lot of improvements can be had in the system's response time. Best, Gard signature.asc Description: PGP signature
Re: DEP-14: Default branch name 'debian/latest' objections?
Gioele Barabucci writes: > On 24/01/25 09:30, Gard Spreemann wrote: >>> I would be curious to hear why people are *not* adopting 'debian/latest'? >> I call the branch debian/sid simply because sid is already what we call >> the distribution where we by default do work on the "latest stuff". > > You mean debian/unstable, don't you? :P > > "unstable" is what is written in changelog and "debian/unstable" is DEP-14 > compatible: > >> In Debian this means that uploads to unstable and experimental should >> be prepared either in the debian/latest branch or respectively in the >> debian/unstable and debian/experimental branches. > debian/latest = UNRELEASED (may be unstable or experimental) > > debian/unstable = This will be uploaded to unstable. I appreciate the distinction being pointed out. For stuff that is not clearly slated for upload anywhere, but still meant to be shared through git, I usually use a descriptive name for whatever the purpose of the branch is (debian/testing-out-new-major-upstream-version-x, whatever). Either that branch gets abandoned, or it gets merged into debian/sid (and uploaded to unstable). This has probably been discussed a lot already, so sorry if I'm rehashing tired points, but I don't really see the point of a consistent name for a branch that may or may not ever feature uploads anywhere. Surely the goal is an upload to unstable – hence my thinking when calling the main branch debian/sid (or debian/unstable, as you point out earlier). Best, Gard signature.asc Description: PGP signature
Re: DEP-14: Default branch name 'debian/latest' objections?
Julien Plissonneau Duquène writes: > Le 2025-01-24 09:37, Gioele Barabucci a écrit : >> Even if we were to keep "master" instead of "latest", it's much better to use >> "upstream/master" and "debian/master": no name clashes and no ambiguity about >> which "master" one is referring to. > > Or maybe `debian/main` to keep up with the popular trend, and as `main` is a > better choice anyways, regardless of some popular controversial arguments. Indeed. I don't really understand what "latest" is meant to convey. Latest what? "Latest work ever done on this package at any given moment"? We surely don't want to discourage branches with specific topics that surely can hold later work? signature.asc Description: PGP signature
Re: DEP-14: Default branch name 'debian/latest' objections?
Otto Kekäläinen writes: > Hi! > > Current https://dep-team.pages.debian.net/deps/dep14/ states that the > default Debian branch name is 'debian/latest': > >> In Debian this means that uploads to unstable and experimental should be >> prepared either in >> the debian/latest branch or respectively in the debian/unstable and >> debian/experimental >> branches. > ... >> The helper tools that do create those repositories should use a command like >> git symbolic-ref >> HEAD refs/heads/debian/latest to update HEAD to point to the desired branch. > > I would be curious to hear why people are *not* adopting 'debian/latest'? I call the branch debian/sid simply because sid is already what we call the distribution where we by default do work on the "latest stuff". Best, Gard signature.asc Description: PGP signature
Re: Proposal for a Yearly Stable Release Cycle for Educational Institutions
Sarbjit Singh Sandhu writes: > I am writing to propose the creation of a new Debian branch that > offers a stable release every year, as opposed to the current 5-year > cycle. It's really great to see young people interested in Debian. I do need to point out that the current cycle has been approximately 2 years long for quite a while, not 5. Best, Gard signature.asc Description: PGP signature
