Re: General resolution: non-free firmware
On Sun, Aug 28, 2022 at 12:56:43AM +, Thorsten Glaser wrote: > Debian Project Secretary - Kurt Roeckx dixit: > > >it are available at: https://www.debian.org/vote/2022/vote_003 > > Is there support for something like A but not enabled by default? > That is, you have to actively select a nōn-default option I don't believe so, because that doesn't solve the problem at hand. How exactly do you select a non-default option if you cannot see or hear it? > More and more graphics adapters now also want firmware uploads to provide any > non-basic functions. A simple basic (S)VGA-compatible framebuffer is not > enough for most users these days; modern desktops expect 3D acceleration, and > a lot of current hardware will not provide that without extra firmware. > Current generations of common Intel-based laptops also need firmware uploads > to make audio work (see the firmware-sof-signed package). https://blog.einval.com/2022/04/19#firmware-what-do-we-do https://peertube.debian.social/w/gpdBYkAuxJ5D8V9DmsTvJS signature.asc Description: PGP signature
Saturation of the FTP Team's available bandwidth processing NEW
On Wed Aug 24 23:20:30 BST 2022, Sean Whitton wrote: > I'm afraid I cannot respond to a message of this length. As I > mentioned previously, all the ftpteam really have the bandwidth to do > is process what's in NEW. * This is more concerning than its indirect effect on uploader motivation * Many thanks for what they do, and a successful decade of recruitment https://web.archive.org/web/201208/https://ftp-master.debian.org/ * That it's still a problem now means the only option left is to do less * Most copyright issues are merely RC bugs, not rejections or need RM * New uploads of existing sources should only have automated checks * Examples: binary splits/hijacks/soname, source clones/renames (other?) * Or this subset of NEW could be exposed as apt repo for manual checks * Somehow implement this without pestering the FTP Team for feedback https://salsa.debian.org/ftp-team/dak/-/merge_requests --- p.s. Sorry Gard for trimming your entire explanation, in the end I wanted to focus on message length rather than linking each point as a paragraph reply. I hope this encourages others to focus on how many times their email will be read. I'm also implicitly referencing all the existing discussions on this topic that end up in *long* threads e.g. https://lists.debian.org/debian-devel/2022/01/msg00360.html signature.asc Description: PGP signature
Re: Legal advice regarding the NEW queue
On Thu, Feb 03, 2022 at 09:43:16AM -0500, Scott Kitterman wrote: > I am a member of the FTP Team and have been participating, at least a bit, in > this thread. I am not, however, speaking for the team. Hello Scott, thank you for taking the time to follow this thread, there are two very specific questions outstanding that those outside the FTP team would like an answer to - if you're not willing to speak for the team on these then please can you encourage internal discussion and announcement of the team's opinion. 1. Is it ftpmaster's opinion and policy that there is no difference in NEW queue review process between bin and src? Namely that a full copyright review is necessary to catch the kind of issues you noticed and so it is unhelpful to ping a mention on e.g. IRC that something only needs a lighter review. Alternatively, is it true that bin-NEW is primarily about non-copyright checks and only if something looks egregiously wrong it becomes subject to a full review which may take more time. https://lists.debian.org/debian-devel/2022/01/msg00226.html > I would certainly not support the notion that we have too few licensing > documentation bugs in the archive and we can afford to dismantle the one > process we have in place that actually makes a difference in this area. That is not the challenge being made here. I don't believe anyone is arguing that licensing documentation bugs would be anything other than RC bugs according to policy §2.3, just that NEW processing is not the only possible mitigation for the Debian project's legal risk. 2. Is the ftpmaster team willing and able to select someone to represent the team in a collaboration with non-team members to seek further legal council on the current NEW copyright practices? Specifically, to compile a list of questions in advance and join a call where these questions are put, communicate the results to the team and obviously have buy-in that any changes needed can be worked with. As examples, there are doubts over: the "abundance of caution" approach to avoiding redistribution during the review; the above mentioned copyright review for bin-NEW; whether RC licensing bugs should be treated differently to other RC bugs. https://lists.debian.org/debian-devel/2022/01/msg00359.html I really hope you can help get the answers to these two questions, because without it there doesn't seem to be a way forward for those with time available outside the ftpmaster team. signature.asc Description: PGP signature
Re: Automated copyright reviews using REUSE/SPDX as alternative to DEP-5
On Thu, Jan 27, 2022 at 11:27:45AM +0100, Stephan Lachnit wrote: > On Thu, Jan 27, 2022 at 12:39 AM Phil Morrell wrote: > > > > TLDR: I think REUSE.software is a bad idea that is worse than what > > Debian already invented with Machine-readable debian/copyright file. I > > guess if upstream uses it, there's no reason not to ignore that as a > > source of copyright assertions. > > I expected some concerns about the complexity of the SPDX document, > but certainly not about standardized copyright information in source > files. > > Yes, Debian may have invented the machine-readable copyright bill, but > not machine-readable copyright information in source files. Erm, no that's not what I'm saying? I'll requote my agreement with > > I *am* a big fan of SPDX-License-Identifier I will admit I'm somewhat skeptical in how often file-level copies happen these days, rather than folder-level or whole project forks. But it's easy enough to convince people to slap a single-line license comment in to avoid ambiguity. > what REUSE is all about, and it greatly reduces manual labor - I don't > understand how this can be seen as bad. Because being REUSE-compliant IMO greatly *increases* manual labor as soon as you're dealing with non-text forms, multiple authors and aggregation of differing copyright assertions. These are all things that the debian copyright-format has already solved without (as much) manual busywork, so if upstream is agreeable to formally documenting their copyrights, I'd much rather they just used that format in LICENSE. > > Firstly, I didn't think it was called DEP-5 anymore - it was accepted > > into policy in 2012 as "copyright-format" titled "Machine-readable > > debian/copyright file", so no longer a proposal for enhancement. This > > would be a minor pedantic point (a colloquialism) except for the fact > > that REUSE encourages it as part of their interface: `.reuse/dep5`. > > Yes it is called "Machine-readable debian/copyright file Version 1.0", > but everybody knows it _is_ DEP-5, it is even in the spec in the > second sentence of the abstract. Sure, and that's fine as a colloquialism, but you haven't addressed my objection to REUSE formalising that as part of the spec. > The spec _is_ still DEP-5, being accepted doesn't change that. Sure it does, compare `#files-field` in both specs, from 2019 policy upgrading checklist 4.4.1. Perhaps that change should have bumped a version number, but it's a bit late now. > > I think this undermines your previous point about it being less prone to > > failure - if we could trust upstream assertions on copyright, the NEW > > review wouldn't be a problem in the first place. > > I strongly disagree. First of all, upstream knows way better where > they copy the code from than packagers do. > ... > And as a second point, if you write a debian/copyright, you are most > likely to trust what is in the header, and I suspect the copyright > review in NEW is not different from this regard. I mean how can one > even know if the copyright information is wrong? > Yes there are cases where copyright information is missing and one can > try to search it, I've done this not just once, but if a project uses > REUSE headers, this doesn't happen. That has not been my experience for projects without a long history, they tend to not care about copyright initially, slap a generic assertion on it at some point, but without noticing they've included e.g. an embedded copy of zlib or less formally - used an image with a vague gratis use but omitting a formal license. It's only either later, or from the ITP scrutiny that some confusion over pedigree comes to light, someone fires off an email to an early contributor and gets the accurate license information. Or for Debian, the path gets added to Files-Excluded and patched out of compilation. > And projects that use REUSE > are more likely to write that somewhere down as your average NPM > package that puts a "under MIT license" in the readme and copies > minified code from everywhere. Sure, but instead of wasting my time encouraging upstream to become REUSE-compliant, I would much rather promote a better standard like Debian's. I was curious and found approximately 40 instances of REUSE in codesearch, but multiple thousands of the (optional) copyright-format. signature.asc Description: PGP signature
Re: Services offered by Debian should be dogfooding the real packages on DSA hosts.
On Wed, Jan 26, 2022 at 01:35:51PM +0100, Raphael Hertzog wrote: > On Tue, 25 Jan 2022, Phil Morrell wrote: > > I have raised https://salsa.debian.org/debian/grow-your-ideas/-/issues/15 > > Thanks for this, but this issue like a few others that have been filed do > describe problems but fail to provide "project/improvement ideas". We are > good at figuring out what's sub-optimal but we are not good at proposing > solutions and implementing them. I completely agree with that limitation for Freexian funding, but this thread asked to rank "What are the most important projects that Debian ought to work on?" as a distinct question from "which projects are fully spec'ed enough to apply for Freexian funding". They are certainly projects that could inspire working groups, or guage support for certain team's ideas from the wider DDs that warrant looking into further, potentially culminating in a concrete application for funding. It's offputting to start a new high-impact project before even knowing if anyone other than yourself would appreciate it being part of Debian. signature.asc Description: PGP signature
Re: Automated copyright reviews using REUSE/SPDX as alternative to DEP-5
https://matija.suklje.name/how-and-why-to-properly-write-copyright-statements-in-your-code TLDR: I think REUSE.software is a bad idea that is worse than what Debian already invented with Machine-readable debian/copyright file. I guess if upstream uses it, there's no reason not to ignore that as a source of copyright assertions. On Wed, Jan 26, 2022 at 12:49:34PM +0100, Stephan Lachnit wrote: > It is straightforward to > implement, add (e.g.) "SPDX-FileCopyrightText: 2019 Jane Doe > " and "SPDX-License-Identifier: GPL-3.0-or-later" as > comments to your source file's header and you are done. I *am* a big fan of SPDX-License-Identifier, but the above being straightforward is only true for the most trivial of examples. REUSE advocate for sprinkling .license files around your repo for e.g. logos and other binaries. Same story with multiple authors, they recommend using multiple FileCopyrightText's initially, then split it out to a separate AUTHORS file and use something like "Project X contributors". https://reuse.software/tutorial/#binary-and-uncommentable-files Ultimately, when everything becomes too much, REUSE falls back to recommending Debian's copyright format anyway! So even if upstream sees the value in taking some copyright busywork off our hands, why not suggest they just use it in the first place in e.g. the LICENSE file. https://reuse.software/faq/#bulk-license > My idea is to allow SPDX documents in addition to DEP-5. Firstly, I didn't think it was called DEP-5 anymore - it was accepted into policy in 2012 as "copyright-format" titled "Machine-readable debian/copyright file", so no longer a proposal for enhancement. This would be a minor pedantic point (a colloquialism) except for the fact that REUSE encourages it as part of their interface: `.reuse/dep5`. > Note that I don't want DEP-5 to go away - it is unlikely that every > project will follow the REUSE spec and writing an SPDX document by > hand has no significant advantages over DEP-5. Besides, using the > file-exclusion function in DEP-5 for uscan is quite useful for ds/dfsg > packages (although that could also be moved to an external file). I think this undermines your previous point about it being less prone to failure - if we could trust upstream assertions on copyright, the NEW review wouldn't be a problem in the first place. The point about uscan is interesting, since if upstream does take on the hard work of license verification such that packaging is just checking, then they're unlikely to have any Files-Excluded, so that would have to merged somehow. signature.asc Description: PGP signature
Services offered by Debian should be dogfooding the real packages on DSA hosts.
On Mon, Jan 24, 2022 at 10:31:01AM +0100, Sébastien Delafond wrote: > > 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. > > 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 have raised https://salsa.debian.org/debian/grow-your-ideas/-/issues/15 # The problem If I had a magic wand, I would like to resolve the situation around official instances of packaged servers being unable to dogfood their packaging work. I think this sends the wrong message as "If it's not good enough for Debian to use, why should I?". # Actual situation From what I've noticed in DebConf talks, it's explained by the fact the service maintainers do not have root access on DSA machines. This leads to either using upstream installation methods or deploying to non-DSA machines. It seems to me that this is either a solved problem, or can be made so, given it's similar to University provided computing resources. # Expected situation For (a simplified) example that I'm familiar with, matrix.debian.social should be as trivial as `apt install matrix-synapse` plus a config file. Going by the existing docs on apache vhosts and email, one possible interface would be: echo matrix-synapse >> /srv/foo.debian.org/packages/install vi /srv/foo.debian.org/packages/etc/matrix-synapse/conf.d/social.yaml sudo -u foo package-setup foo.debian.org The permitted packages and config paths could even be managed by a whitelist under the control of DSA to prevent a complete wildwest. The important thing is that a service owner can make (certain) direct changes without having to co-ordinate DSA approval. # Additional information I first wrote directly to debian-admin but that list isn't publicly archived, so I'll only paraphrase the response I got: * Installation + configuration can have a risk of privilege escalation * DSA might be happy with MRs to the puppet setup for the simple cases * There is no external testing on the current puppet code, holding back collaboration by non-DSA * There have been small experiments with containerisation (IMO, that's abandoning the strength of Debian's *integration*) signature.asc Description: PGP signature
Re: Back to the topic of changed binary named
On Tue, Jan 25, 2022 at 10:50:01AM +0100, Stephan Lachnit wrote: > On Mon, Jan 24, 2022 at 8:15 AM Andreas Tille wrote: > > > > However, my point was that I want to know what policy ftpmaster applies > > to new binary names and to focus on this topic. I really want to know > > that policy of ftpmaster and I really would like to see that documented > > and I'm afraid that thread is drifting away from the original topic > > that I will not get any answer on this. > > > > So again: I see a conflict in my interpretation of the mail[1] (original > > posters again in CC) which suggests "an auto-approver" and what I'm > > currently observing and I would be really happy if we can document the > > policy for changed (and new) binary names of existing source packages. > > Since I feel my mail went lost in the discussion, here again my opinion: It's not been lost, there has been lots of discussion around the lottery idea C, but in changing the email subject I believe Andreas is trying to draw the distinction between the request to document *current* practice and your subthread about possible improvements to the overall process. signature.asc Description: PGP signature
Re: Are libraries with bumped SONAME subject of inspection of ftpmaster or not
On Mon, Jan 24, 2022 at 01:49:19PM -0500, Theodore Y. Ts'o wrote: > On Mon, Jan 24, 2022 at 08:15:30AM +0100, Andreas Tille wrote: > > > > its surely an interesting topic how to avoid binary name changes and its > > also interesting to discuss ABI changes and workarounds. > > > > However, my point was that I want to know what policy ftpmaster applies > > to new binary names and to focus on this topic. > > As far as I know, ftpmaster requires a long, laborious review every > single time there is a new binary package released. As a result, it > strongly disincentivizes maintainers from packaging up new releases > because it's a pain in the posterior. > > Even if it isn't formal policy, the long delay has happened enough > times that I just assume it will be there, and it influences my > behavior accordingly. I like the earlier thread idea of de-coupling the copyright review (eventually of NEW entirely? but for now, just bin NEW) from "the other checks and balances". Ultimately, a mistake in debian/copyright *can* be just considered a bug with priority determined just like any other, so long as it is still legal for Debian to distribute. However, this is an issue whenever upstream ships a new source file, not when a new binary is added, so I hope that good maintainers do their due diligence on new upstream releases. If that is agreed informally, then while a lottery review would be a cool addition, it would not be a prerequisite to dropping its requirement for sources which have already been accepted into the archive once. This could be formalised via a GR empowering the FTP team. That last has made me wonder if the ftp-master team could split the NEW source queue into two phases, one where a copyright review is performed and one where the other checks are. I can see pros and cons for either way round these phases could be done, but one should feed into the other. Presumably, that this has not already happened means there would be little benefit because of context switching? signature.asc Description: PGP signature
Re: Bundling
On Thu, Sep 30, 2021 at 10:24:01AM +0200, Alec Leamas wrote: > Just for the record: the issue about packaging wxWidgets 3.1 has already > been discussed with the maintainer: > > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=919903 Hi Alec, I get the impression there that the maintainer is strongly indicating that they think it's not worth it, but that doesn't necessarily rule out being ok with you maintaining the experimental uploads. -- emorrp1 signature.asc Description: PGP signature
task-laptop: please recommend automatic apt proxying
Package: task-laptop Version: 3.53 Severity: wishlist I'm not sure on the difference between auto-apt-proxy and squid-deb-proxy-client. Avahi is already pulled in by task-laptop. On Fri, Sep 10, 2021 at 09:33:56AM +0200, Helmut Grohne wrote: > On Wed, Sep 08, 2021 at 07:12:18PM -0400, Michael Stone wrote: > > Why not simply automate setting it at install time using preseed? I'm > > honestly not sure who the target audience for auto-apt-proxy is > > Laptops of end-user systems are the target, but also developers. When > people gather at a place (conference, hackspace, private meetup, etc.) > downloading of .debs should just work quickly by default. Many such > sites could easily provide a local cache and a number even do. BSPs tend > to have a blackboard with information including the local mirror to use. > Seriously, how many people change their mirror when they go to a BSP? If > we installed auto-apt-proxy by default, much of the local caching would > just work. -- System Information: Debian Release: 10.10 APT prefers oldstable-updates APT policy: (500, 'oldstable-updates'), (500, 'oldstable-debug'), (500, 'oldstable'), (100, 'buster-fasttrack'), (100, 'buster-backports') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.19.0-17-amd64 (SMP w/4 CPU cores) Kernel taint flags: TAINT_CRAP, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=en_GB.utf8, LC_CTYPE=en_GB.utf8 (charmap=UTF-8), LANGUAGE=en_GB:en (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages task-laptop depends on: ii anacron 2.3-28 ii tasksel 3.53 Versions of packages task-laptop recommends: ii avahi-autoipd 0.7-4+deb10u1 ii bluetooth 5.50-1.2~deb10u2 ii iw 5.0.1-1 ii powertop2.8-1+b2 ii wireless-tools 30~pre9-13 ii wpasupplicant 2:2.7+git20190128+0c1e29f-6+deb10u3 task-laptop suggests no packages. -- no debconf information signature.asc Description: PGP signature
Re: Finding rough consensus on level of vendoring for large upstreams
Thanks to Adrian and pabs for their corrections on documenting security support, and there wasn't too much objection to the summary, more to the sad state of affairs that leads to it and a bit of clarification. I believe all the major points have cc'd 907051, so would like to encourage someone more familiar with policy process than I am to draft an amendment. There should be enough written there now to expand the section accordingly with more recommendations, and possibly file wishlist bugs for maintainers to document their reasons in the source. https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=907051 signature.asc Description: PGP signature
Re: Epoch bump request for ksh
On Fri, Sep 10, 2021 at 07:37:55PM +0530, Anuradha Weeraman wrote: > ksh93u+m was a reboot attempt by Martijn Dekker et al. to build upon > the last stable 93u+ release (not on v2020, apart from some cherry > picked patches). This work has been taking place for over a year at this > point, with the objective of making incremental changes, by fixing long > standing issues, consolidating patches from RedHat, OpenSUSE, Solaris > etc, removing unused code, fixing the build system, and testing across > different UNIX variants. The distribution has come a long way, and the > upstream maintainers have been carefully curating fixes and maintaining > backwards compatibility. Ah I see, thanks for correcting my mistake about which project is which. That way round I completely agree there's no need to use alternatives and personally see no issue with bumping the epoch accordingly. signature.asc Description: PGP signature
Re: Epoch bump request for ksh
On Fri, Sep 10, 2021 at 05:18:13PM +0530, Anuradha Weeraman wrote: > As a result of a revert of v2020 of ksh last year, the current version > on sid for ksh is as follows: > > 2020.0.0+really93u+20120801-10 > > With the next upgrade, we're looking to move to the 93u+m community > maintained distribution that has a different versioning scheme (starting > with 1.0.0-beta.1). I was curious about why, and while I'm neither a ksh dev or user, in the context of Debian packaging it doesn't seem so simple. I'm trying not to step on your toes, or dredge up interpersonal conflict. https://github.com/att/ast/issues/1466 The impression I got is that there are at least 3 projects making claim to "ksh93" going forwards. 93u+2012 is the last known stable, compatible version that has been reverted to and, crucially, has been shipped in all Debian stable releases. There seems to be community demand and distro maintainers support for collaborating on keeping the build system working on modern systems, which will not be merged back into the att repo - do you know if this has happened, where the fork can be found? https://tracker.debian.org/pkg/ksh Then there appears to be this 93u+m project publishing essentially v2020 as 1.0.0 beta, tagged as 'v1.0.0-beta.1'. It's release notes say "This new fork is called ksh 93u+m as a permanent nod to its origin". It is making more invasive fixes to the codebase and trimming unused components, but there are some concerns noted over its backwards compatibility with 40 years of scripts. https://github.com/ksh93/ksh > However, I would like to request feedback to move to the following > version with a bump of the epoch: > > 1:93u+m-1.0.0~beta.1-1 1) If there are possible edge-case compatibility issues, have you considered a new source package and use of the alternatives system? This would let Debian users choose between the two options for their use case - maintaining existing systems, or writing new ksh scripts. 2) If you do go ahead with switching to the community distribution, then "93u+m" is part of the name, not the version number, so I'd suggest: 1:1.0.0~beta.1-1 signature.asc Description: PGP signature
Re: Finding rough consensus on level of vendoring for large upstreams
On Fri, Sep 03, 2021 at 02:46:20AM +0200, Jonas Smedegaard wrote: > First of all, thanks for compiling the list of reasonings. Thanks for taking the time to read through it, I was hoping it would be a useful observation. > I get the impression that you are framing current state of embedding as > a generally good thing to do, and if I understand that correctly then I > disagree with it. ish? I mostly tried to document current practice rather than have an opinion on it being good. I do think that the evidence of multiple independent maintainer teams coming to similar conclusions on the basis of lack of user benefit and drag on new version velocity indicates the positive side. I believe, based on only a day's investigation, that you are in the minority here. I don't mean that as a bad thing - 1/3 of DDs disagree(d) with offering non-free alongside main - but I'd like to hear why you think the maintainers I gave as examples should use their Debian time to unvendor everything? > I suspect that it helps if separating reasons for _encouraging_ > embedding (tiny upstream projects and deeply integrated sets of > upstreams, I guess) from reasons for _discouraging_ embdding (all other > cases, I guess). I think the expanded points I gave empower maintainers to make the best decision for their own packages. By laying out the permitted reasons clearly, it's implied other reasons are not valid, but there's probably something I haven't thought of. However #907051 also wanted more background on _why_ one might choose one way or the other, so please do elaborate on this if you can. > Quoting Phil Morrell (2021-09-03 00:38:35) > > 5. Where only a small number of unrelated projects are bundled, they > >SHOULD be uploaded as separate source packages. > > Concretely I think not I but ftpmaster objects to the above: Node.js > packages embed unrelated packages to meet ftpmaster requirement of a > minimum size source package. No, I think Node.js is covered by #7 (large number of deps). With #5 I was attempting to capture the current policy for when _not_ to bundle. Thanks for the additional background about why the bundling happens. -- emorrp1 signature.asc Description: PGP signature
Re: Finding rough consensus on level of vendoring for large upstreams
On Fri, Sep 03, 2021 at 01:03:35AM +0200, Jérémy Lal wrote: > - should a package debian/control list bundled dependencies to make > sure to avoid duplications ? Maybe? I noted in my final paragraph that Fedora has a mechanism for this that we don't, but perhaps Provides is sufficient. > - when a bundled package dependency is already available in debian, > and is the same (unpatched), should the upstream source tarball be > repacked without that dependency, or kept inside the source tarball ? I omitted this from the policy side, because it seems like this is already answered in ftp-master practice. Provided the vendored copy is not used during the build and unless there is a *different* reason for repacking with Files-Excluded, then I see no reason to remove it. -- emorrp1 signature.asc Description: PGP signature
Finding rough consensus on level of vendoring for large upstreams
Over this last year there seems to have been a noticeable divergence of maintainer opinion, on what has become known as vendoring, from a strict reading of [policy 4.13]. I think it's notable that the heading is [Embedded] copies and was [Convenience] copies since its inception, thankfully I found a request to expand this section using [vendoring]. [policy 4.13]: https://www.debian.org/doc/debian-policy/ch-source.html#embedded-code-copies [Embedded]: https://bugs.debian.org/955036 [Convenience]: https://bugs.debian.org/392362 [vendoring]: https://bugs.debian.org/907051 It is my reading of the situation that not only has this practice become more prevalent across multiple ecosystems since 2008, but that it can be a good thing when upstreams use it to better modularise their code. As a consequence, and in particular for large upstream projects, it is not a good use of maintainer time to package every single vendored library as a separate source package. See e.g. [kubernetes], [python BoF @25mins], [android-platform-tools], and even [uscan] grouping used by nodejs. [kubernetes]: https://bugs.debian.org/971515#172 [python BoF @25mins]: https://meetings-archive.debian.net/pub/debian-meetings/2021/DebConf21/debconf21-97-python-team-bof.webm [android-platform-tools]: https://salsa.debian.org/android-tools-team/admin/-/issues/40 [uscan]: https://manpages.debian.org/uscan#grouped_package Is there any objection to the following summary? 1. If the reused code is small and intended to be embedded into a package, then this MUST be documented in the [security-tracker]. 2. If the included project has already been packaged, then the Debian version SHOULD be used instead. 3. If modifications have been made, then those changes SHOULD be forwarded and/or the package ported to the official version. 4. When 2 or 3 are too onerous to maintain, the package MAY use the convenience copy but MUST document why in README.source and SHOULD be included in the [security-tracker]. 5. Where only a small number of unrelated projects are bundled, they SHOULD be uploaded as separate source packages. 6. If the upstream authors are largely the same, then vendored sub-projects MAY simply be built together as the same source. 7. A large number of vendored dependencies used only together for a single Debian package MAY be grouped into a single source upload. 8. If 6 or 7 are used initially but a new package has some overlap, then the new package MUST NOT duplicate the vendoring. The duplication SHOULD be packaged separately, then the original package SHOULD be updated to use the Debian version instead. 9. When upstream has a proven track record of promptly handling security vulnerabilities inside their vendored dependencies, then maintainers SHOULD follow the same practice, updating versions in lockstep. I might be misusing the MUST/SHOULD/MAY, so those can be dropped as needed, but I tried to capture the accepted practice and deliberately used all the different historical terms. For comparison, there's also [Fedora] policy, but apart from not having an in-band "bundled", I also think that the line has ended up being drawn marginally differently. [security-tracker]: https://salsa.debian.org/security-tracker-team/security-tracker/-/blob/master/data/embedded-code-copies [Fedora] https://docs.fedoraproject.org/en-US/packaging-guidelines/#bundling signature.asc Description: PGP signature
Re: next steps after usrunmess
On Fri, Aug 27, 2021 at 07:34:06PM +0200, Bastien ROUCARIES wrote: > Le ven. 27 août 2021 à 17:20, Theodore Ts'o a écrit : > > On Fri, Aug 27, 2021 at 03:39:57AM +0100, Phil Morrell wrote: > > > > - reverting the changes in deboostrap in sid, bullseye (and ideally > > > > in buster too), > > > > - reverting the notion that split-/usr is unsupported (which includes > > > > the extremely confusing interpretation about this applying to > > > > sid/testing too), and update documentation such as release-notes, > > > > > > This bullet point response confuses me - and then what? > > > > > > If I understand your position correctly, you don't want merged-/usr as > > > an end-goal and you disagree with usrmerge transition as a hack. In > > > order to achieve the result above without bypassing Debian processes, > > > the formal method would to pass a GR overriding the tech-ctte minority. > > > > But the question remains --- how do we as a community move forward? > > Debian is made up of volunteers, so we can't *force* the dpkg > > developers to do anything they don't want to do. So what then? > > > > Does someone need to create patches to dpkg which attempt to teach it > > that /bin/foo and /usr/bin/foo are the same file, if there exists a > > symlink from /bin to usr/bin? > > > > So I repeat the question to the entire community --- what is to be > > done? How do we move forward? > > See the proposal here of guillem: > https://wiki.debian.org/Teams/Dpkg/Spec/MetadataTracking Hi Bastien, it's hard for me to see as an outsider to dpkg how that proposal specifically addresses merged-/usr. It seems to be trying to solve a much, much more generalised problem of which merged-/usr is just a part. Is there no way to achieve the goal of making the dpkg database correspond with reality without that complexity? Secondly, assuming that this mechanism is needed, then according to that wiki page it appears to be almost complete? Can you confirm that the only thing needed to support merged-/usr as an option is these two remaining blockers? > [ ] (blocker) dpkg database access (.list and .md5sums) > * reportbug (no interface to map a db pathname to a pkgname) > [ ] (blocker) We cannot install .mtree files under /var/lib/dpkg/info/ > because old or new .debs could have shipped those, and these might be > invalid, or not match the contents. In general it seems like a bad > idea to store the files handled and generated by dpkg itself, with > files coming straight from the .debs. We need to separate them into > different directories. Perhaps /var/lib/dpkg/info/. > and /var/lib/dpkg/meta/. or similar. signature.asc Description: PGP signature
next steps after usrunmess
On Thu, Aug 26, 2021 at 02:56:21AM +0200, Guillem Jover wrote: > On Sun, 2021-08-22 at 09:18:25 +0200, Andreas Metzler wrote: > > Afaict we have still no idea on how to move on. > > > > 1 I think you agree that there is a significant number of usrmerged Debian > > installations out there. > > My wish would be to indeed salvage those systems, > that's why I implemented dpkg-fsys-usrunmess. > > > 2 As you have stated there are known issues with dpkg and usrmerged > > systems. Some of them are are triggered by moving files from / to /usr. > > Well, in my mind the first and most immediate action that would be > done, is to stop the bleeding, by: > > - reverting the changes in deboostrap in sid, bullseye (and ideally > in buster too), > - reverting the notion that split-/usr is unsupported (which includes > the extremely confusing interpretation about this applying to > sid/testing too), and update documentation such as release-notes, This bullet point response confuses me - and then what? If I understand your position correctly, you don't want merged-/usr as an end-goal and you disagree with usrmerge transition as a hack. In order to achieve the result above without bypassing Debian processes, the formal method would to pass a GR overriding the tech-ctte minority. Is the only reason you haven't proposed that as a GR that you've already sunk too much energy into this? Or that you don't trust that process? Lets say you get your wish: to achieve technical excellence the Project backs your position and recommends running usrunmess to ensure everyone's systems are back to split-/usr for Debian 12. However, hypothetically, and against your better judgement, the Project still wants the end-goal to be merged-/usr. It seems to me that most commentators are deferring to your knowledge of dpkg internals. Whether you call it a feature request or a long-standing bug, what patchset would you be willing to merge into dpkg to support the new layout? This is a similar scenario to Russ' parallel email: On Wed, Aug 25, 2021 at 01:23:19PM -0700, Russ Allbery wrote: > I do not believe it will be possible at this point to > convince the project as a whole to unwind usrmerge and go back to doing > individual package migrations. > > Given that as a design constraint (we will not be doing this transition > via one-by-one changes to each package), what would you support as a good > architectural solution to this transition? What is the technically excellent thing everyone else should be working on, that you will support in dpkg despite personally disagreeing with the end-goal of merged-/usr? Presumably this feature could also be implemented in time for Debian 12. Would it then be possible to make everyone's systems merged-/usr upon release of Debian 13, in 2025? I'm sorry, you won't know me from adam, so I hope you don't interpret this as pro-merged-/usr, but as a chance to explain how you getting your way doesn't stand in the way of what others consider timely progress. signature.asc Description: PGP signature
Re: Debian choice of upstream tarballs for packaging
On Wed, Aug 25, 2021 at 04:35:51PM +0200, Simon Richter wrote: > > I wrote this many times, but I don't see why we should use any "upstream > > tarball" when the Git repository itself contains the tarball with: > > > git archive --prefix=$(DEBPKGNAME)-$(VERSION)/ $(GIT_TAG) \ > > | xz >../$(DEBPKGNAME)_$(VERSION).orig.tar.xz > > "git archive" is reproducible, for simplicity I wouldn't use a prefix > though. For simplicity I *would* use a prefix, purely because that's what github/gitlab uses, so upstream can still choose to additionally sign the distributed tarball if they wish. name=CorsixTH-0.61-beta1 # don't ask me why there's no v, it's just what GitHub does git archive --prefix=$name/ -o ../$name.tar.gz v0.61-beta1 gpg --armor --detach-sign ../$name.tar.gz https://github.com/CorsixTH/CorsixTH/issues/1271#issuecomment-344882419 signature.asc Description: PGP signature
Re: Debian choice of upstream tarballs for packaging
On Tue, Aug 24, 2021 at 04:21:50PM -0700, Sean Whitton wrote: > On Wed 18 Aug 2021 at 10:10AM +02, Simon Josefsson wrote: > > Signing tarballs is the current > > established best practice -- moving to VCS builds needs a set of new > > schemes to be established and deployed, and I don't see any single > > universal solution today. > > From my point of view, signing git tags is no less well established a > best practice than signing tarballs -- in fact, to me, it seems *more* > well established. Maybe for upstreams the tooling is certainly easier for signed tags that are distributed with the git repo, rather than tarball signatures that have to be attached to a releases page after the fact. However, the debian tooling last I checked correctly passed on the upstream tarball signature intact to be available to the end-user (included in .dsc). uscan verifies signed tags only locally before throwing away the metadata - see also 3.0 (git) source format and tag2upload. It doesn't have to be full history clone, only IIRC the tag and its sole commit object from `git cat-file -p` to recreate them. signature.asc Description: PGP signature
Re: Q: Use https for {deb,security}.debian.org by default
On Sat, Aug 21, 2021 at 10:40:32AM +0200, Wouter Verhelst wrote: > On Fri, Aug 20, 2021 at 07:20:22PM +, Jeremy Stanley wrote: > > Yes transparent proxies or overridden DNS lookups could be used to > > direct deb.debian.org and security.debian.org to your alternative > > location, > > I've been thinking for a while that we should bake a feature in apt > whereby a network administrator can indicate somehow that there is a > local apt mirror and that apt should use that one in preference to > deb.debian.org. This already exists in the form of an avahi service announcement for _apt_proxy._tcp, issued by both squid-deb-proxy and apt-cacher-ng. Literally the only thing needed client-side is installation of squid-deb-proxy-client, which is also available in udeb form implying that d-i already uses it. > This could be useful for both the "I've got a slow uplink and would like > it to not be overwhelmed at the BSP I'm hosting for my Debian friends" > type as well as the "I'm an ISP and I want to provide a mirror to Debian > users so we can reduce our uplink connection a bit" type of situations. It's a great solution for everyone on the same wifi network, if everyone has squid-deb-proxy-client installed then just one person can spawn a proxy and suddenly everyone's caching through them. > However, I've not been able to come up with a scheme which is simple > enough to be doable on a LAN while at the same time be usable by larger > network providers, *and* which can't also be abused by MitM attackers. Isn't the MitM handled by archive signatures etc., hence why http is fine? True I haven't tested this in a large network, since usually configuration management is in place, but apparently mDNS can even traverse routers via Multicast BGP. signature.asc Description: PGP signature
Re: please document why a package has been dropped from Testing/Bullseye
On Mon, May 10, 2021 at 06:23:34AM -0500, Michael Lustfield wrote: > On Sun, 9 May 2021 07:30:04 +0200 > Harald Dunkel wrote: > > > > https://packages.debian.org/search?keywords=rsnapshot doesn't tell, so I > > wonder > > what is the recommended way to find out why rsnapshot (or any other package) > > has been dropped from Testing? > > I was wondering what the easiest and most sensible way would be to find/share > this information. My first thought was feeding something like > 'aptitude search ~o' into a script that checks for RM bugs in the bug tracker. > It seems like it would be an easy enough trigger to write, but it would be > time-consuming to run and would add a fair bit of load to the bug tracker. Hi Michael, it sounds like you would be interested in installing the how-can-i-help package, where you can run queries pre-filtered to the list of packages you have locally installed. how-can-i-help --old --show no-testing,testing-autorm signature.asc Description: PGP signature
Re: Who to contact about removing package from upcoming 11 release?
On Mon, May 03, 2021 at 11:18:04AM -0300, Kurt Fitzner wrote: > When the maintainers are unresponsive, I'm not sure the escalation process. > > - #926253 /usr/share/postfixadmin/lib/../templates_c does not exist on new > installation (Since Debian 9) > > The concern I have with this remaining in testing and then Debian 11 is > primarily #926253. Since about 2018, upstream's postfixadmin has required a > writeable tmp directory called templates_c. This is not created by the > installer and the application fails without it. Taking this entirely at face value, the escalation is quite straight forward. If you can confirm the issue "renders package unusable" on a fresh install of testing, then use `reportbug` to update #926253 to "grave" severity for version 3.3.5-1. https://www.debian.org/Bugs/Developer#severities > renders the package unusable, or mostly so, on all or nearly all > possible systems on which it could be installed (i.e., not a > hardware-specific bug); or renders package uninstallable or > unremovable without special effort If not, or if they disagree, then it's up to the maintainer's discretion. Please note that the currently listed Maintainer hasn't made an upload since 2014, and the Uploader explicitly requested in 2018 that someone else adopt it as "I can't test the package thoroughly". https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=897683
Re: Changed Github download URLs are affecting lots of existing watch files
On Fri, Mar 26, 2021 at 11:43:27PM +0100, Yadd wrote: > Le 26/03/2021 à 22:38, Andreas Tille a écrit : > > I just learned that what was formerly something like > > > > .*/archive/ > > > > became now > > > > .*/archive/refs/tags/ > > > > This breaks at least all Debian Med packages refereing to Github and > > probably way more. This means our toolset will fail to detect new > > upstream versions. FWIW, the github snippet in man uscan recommends `(?:.*?/)` which I can confirm has not broken with this update. > > Any idea what to do (besides uploading all packages obtained from > > Github right after the release)? You could make a lintian-brush filter to make Janitor prepare the change for you on next upload. In the meantime, I don't think there's a better way of tracking changes than to take a copy of all the affected watch files and uscan them locally/in CI. Watch files, homepage urls, signing keys are all just metadata that can occasionally change. > We could perhaps handle that with uscan then each time GitHub changes > its website, only uscan should be updated. > > IDEA 1: create a uscan macro > IDEA 2: create a uscan option: 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. signature.asc Description: PGP signature
Re: libgcc-s1 buster -> bullseye upgrade issues
On Sun, Feb 14, 2021 at 04:58:35PM +, Simon McVittie wrote: > On Sat, 13 Feb 2021 at 19:52:10 +0100, Paul Gevers wrote: > > [The release team are] pretty concerned about a couple of known RC bugs > > which need the proper attention of people familiar with upgrade paths > > as there's potential to leave upgrading systems unbootable and/or > > without a working apt. > ... > > https://bugs.debian.org/972936 / libgcc-s1 > > I wanted to provide some signal boost for this and related upgrade issues. > Ryan Pavlik, one of my colleagues at Collabora, ran into a similar upgrade > failure involving libgcc-s1 and has made a self-contained reproducer > for it: <https://salsa.debian.org/rpavlik/gcc-upgrade-testcase>. Hi Simon, That testcase is two months old, I take it you missed my update yesterday to both bugs after the bits email failing to reproduce it with current buster/bullseye. I have just re-run the upgrade with the addition of libreoffice installed and it completed without issue. I didn't close/downgrade the bug in case I was missing something, so please can you re-test your upgrade and confirm it's fixed? -- Phil Morrell (emorrp1) ``` # apt full-upgrade Reading package lists... Done Building dependency tree Reading state information... Done Calculating upgrade... Done The following packages were automatically installed and are no longer required: ant-contrib libboost-atomic1.67.0 libboost-chrono1.67.0 libboost-date-time1.67.0 libboost-filesystem1.67.0 libboost-iostreams1.67.0 libboost-locale1.67.0 libboost-system1.67.0 libboost-thread1.67.0 libcodec2-0.8.1 libcroco3 libcrystalhd3 libdbus-glib-1-2 libdc1394-22 libdvdread4 libfluidsynth1 libgail-common libgail18 libgdk-pixbuf-xlib-2.0-0 libgdk-pixbuf2.0-0 libgssdp-1.0-3 libgtk2.0-0 libgtk2.0-bin libgtk2.0-common libgupnp-1.0-4 libicu63 libidn11 libigdgmm5 libilmbase23 libip4tc0 libjson-c3 libllvm7 libmpdec2 libopenexr23 liborcus-0.14-0 libpoppler82 libpython3.7 libpython3.7-minimal libpython3.7-stdlib libreadline7 libreoffice-avmedia-backend-gstreamer libvpx5 libx264-155 libx265-165 python3.7-minimal Use 'apt autoremove' to remove them. The following packages will be REMOVED: g++-8 gcc-8 libgcc-8-dev libreoffice-style-tango libstdc++-8-dev python3.7 uno-libs3 The following NEW packages will be installed: alsa-topology-conf alsa-ucm-conf bsdextrautils cpp-10 fonts-noto-extra g++-10 gcc-10 gcc-10-base gcc-9-base gstreamer1.0-libav gstreamer1.0-plugins-good gstreamer1.0-plugins-ugly gstreamer1.0-x liba52-0.7.4 libaa1 libaacs0 libapt-pkg6.0 libasan6 libavc1394-0 libavfilter7 libavformat58 libbdplus0 libbluray2 libboost-filesystem1.74.0 libboost-iostreams1.74.0 libboost-locale1.74.0 libboost-thread1.74.0 libbrotli1 libc-devtools libcaca0 libcdio19 libclone-perl libcodec2-0.9 libcrypt-dev libcrypt1 libctf-nobfd0 libctf0 libdav1d4 libdc1394-25 libdeflate0 libdv4 libdvdread8 libdw1 libffi7 libfluidsynth2 libgcc-10-dev libgcc-s1 libgd3 libgdk-pixbuf-2.0-0 libgdk-pixbuf-xlib-2.0-0 libgssdp-1.2-0 libgupnp-1.2-0 libhogweed6 libicu67 libiec61883-0 libigdgmm11 libilmbase25 libinstpatch-1.0-2 libip4tc2 libisl23 libjson-c5 libjuh-java libjurt-java liblibreoffice-java libllvm11 libltc11 liblua5.3-0 libmariadb3 libmd0 libmfx1 libmpdec3 libmpeg2-4 libmysofa1 libnettle8 libnorm1 libnsl-dev libnsl2 libnss-nis libnss-nisplus libopencore-amrnb0 libopencore-amrwb0 libopenexr25 libopenni2-0 liborcus-0.16-0 liborcus-parser-0.16-0 libpcre2-8-0 libperl5.32 libpgm-5.3-0 libpocketsphinx3 libpoppler102 libpostproc55 libpython3.9 libpython3.9-minimal libpython3.9-stdlib libqrcodegencpp1 librabbitmq4 libreadline8 libreoffice-sdbc-mysql libridl-java librubberband2 libsdl2-2.0-0 libshout3 libsidplay1v5 libslang2 libsodium23 libsphinxbase3 libsrt1.4-gnutls libssh-gcrypt-4 libstdc++-10-dev libswscale5 libtag1v5 libtag1v5-vanilla libtirpc-common libtirpc-dev libtirpc3 libudfread0 libuno-cppu3 libuno-cppuhelpergcc3-3 libuno-purpenvhelpergcc3-3 libuno-sal3 libuno-salhelpergcc3-3 libunoil-java libunoloader-java libunwind8 libvidstab1.1 libvpx6 libvte-2.91-0 libvte-2.91-common libx264-160 libx265-192 libxcb-randr0 libxkbfile1 libxss1 libxxhash0 libz3-4 libzmq5 logsave mailcap manpages manpages-dev mariadb-common media-types mesa-vulkan-drivers mysql-common ocl-icd-libopencl1 perl-modules-5.32 pocketsphinx-en-us python3.9 python3.9-minimal systemd-timesyncd termit timgm6mb-soundfont uno-libs-private The following packages will be upgraded: adwaita-icon-theme ant ant-contrib ant-optional apparmor apt at-spi2-core base-files base-passwd bash binutils binutils-common binutils-x86-64-linux-gnu bsdutils build-essential bzip2 ca-certificates ca-certificates-java coinor-libcbc3 coinor-libcgl1 coinor-libclp1 coinor-libcoinmp1v5 coinor-libcoinutils3v5 coinor-libosi1v5 coreutils cpp dash dbus dbus-user-session dconf-gsettings-backend dconf
Re: devscripts: wrap-and-sort should default to -ast
On Wed, Feb 10, 2021 at 11:47:12AM +, Phil Morrell wrote: > To make that work as a default, there would need to be something like an > --short-preferred-unless-existing-indent sorry, going by the current default, that should be --align-preferred-unless-existing-short signature.asc Description: PGP signature
Re: devscripts: wrap-and-sort should default to -ast
On Tue, Feb 09, 2021 at 08:49:51PM +0100, Thomas Goirand wrote: > On 2/9/21 7:40 PM, Russ Allbery wrote: > > Jonas Smedegaard writes: > >> Let's see if Debian can agree on a single normalization of 822-ish > >> files. For starters, I disagree that "wrap-and-sort -a" is a suitable > >> normalization, as that will involve re-indentation when keys change. > > > > I've been using wrap-and-sort -ast on all of my packages for a while, with > > much the same justification. > > For packages generating a lot of binaries, the -b option is also quite > useful, don't you think? As a user of -satb, I'd like to point out that the flags are not all equal. Two of them support a (more objective?) desire that "addition to a list in line-based VCS should have no deletions". That is -at, whereas -s is a subjective prettifier and -b could remove information, hence -k. To make that work as a default, there would need to be something like an --short-preferred-unless-existing-indent to prevent constant reformatting. I disagree with jonas on the importance of -s because I'm not convinced that field names change, especially not often. signature.asc Description: PGP signature
Re: Package broke in stable due to old API. Fix in stable or backports?
On Sun, Jan 10, 2021 at 12:15:22AM +0800, Yao Wei wrote: > There should be many existing cases, that external service the stable > package is using deprecates the old API, which in turn breaks the > package. Do we have documented conventions that where the fixed package > should be uploaded to: stable-proposed-updates or backports? Yes, absolutely stable updates, as documented in both the dev-ref and backports site. https://www.debian.org/doc/manuals/developers-reference/pkgs.html#upload-stable > Backports are about additional features that are only offered in a new > version, not a replacement for getting fixes into stable - use stable-updates > for that. https://backports.debian.org/Contribute/#index1h3 signature.asc Description: PGP signature
Re: NEW queue almost empty
On Mon, Nov 02, 2020 at 10:56:57PM +0100, Joerg Jaspert wrote: > On 15940 March 1977, Christian Kastner wrote: > > > The NEW queue length is down a single digit, from ~500 not all too long > > ago. That's an amazing effort by ftp-master that must have consumed a > > *lot* of energy. > > It consumed quite a batch of my poor jelly beans. :) Package: ftp.debian.org Severity: important Summary: NEW queue graphs not updating since 21:00 UTC thanks /s There can never be too much of a good thing, so I just wanted to hand out another thank you to the FTP masters (and this year's trainees) for continued work on the NEW queue. Keeping on top of the tens of unblocked packages daily and managing to hit 0 is a great achievement. I don't envy you the next four months, but thank you in advance for bullseye and I hope this helps prevent any inappropriate abusive emails previously reported on or at least raise the ratio of appreciation. -- Phil Morrell signature.asc Description: PGP signature
Re: Lenovo discount portal update (and a few other things)
On Thu, Sep 03, 2020 at 03:18:21PM -0400, Mark Pearson wrote: > On 9/2/2020 9:18 PM, Paul Wise wrote: > > Many of the Debian membership benefits (link above) also apply to > > Debian Maintainers (folks who are not members but can do unsupervised > > uploads of particular packages) and Debian contributors in general, > > has Lenovo considered including one or both of these groups in the > > discount program? > > If there is a group missing that it makes sense to add we can look at that - > let me know. Using the debian.org email as a filter seemed like a neat and > simple solution when I discussed it with Jonathan originally. > I'd rather avoid having to manage lists of individual email addresses. > That's a real pain and IMO will only break in the long term. > Open to other suggestions if what we have implemented doesn't work but it > has to be balanced with the amount of effort involved. Oooh, as one of the 246 Debian Maintainers without a debian.org address, I would obviously appreciate it if we could be included in the offer. Some of the MemberBenefits offers accept a GPG-signed email to a special address, which can be checked against keyring.debian.org. On the other hand, I believe that would exclude Contributors such as translators, perhaps the FrontDesk team would have an idea of how a third-party could verify project status by email validity? https://nm.debian.org/public/stats/ https://nm.debian.org/public/findperson/?status=dm (uses /api/people/) https://wiki.debian.org/Teams/FrontDesk signature.asc Description: PGP signature
Re: Pimp your shell - Debian developer tips?
On Jo, 04 iun 20, 10:13:06, Michael Shuler wrote:
> For many years, I have taken a different approach; use the default and add
> only a few minor changes. Each stable update, I use /etc/skel/.bashrc and
> edit/add in my little bits.
for config in ~/.config/bash/*; do source "$config"; done
That is the entirety of my ~/.bashrc due to [WONTFIX], which allows you
to drop in symlinks, organise overrides and specify ordering. I'm
definitely bookmarking this thread to steal some useful snippets.
00_skel -> /etc/skel/.bashrc
10_xdg # alias dig="HOME=~/.config dig"
arguments # alias ls='ls --almost-all --color=auto --human-readable'
bash# see below
git-sh-prompt -> /usr/lib/git-core/git-sh-prompt
shortcuts # alias serve='nohup python3 -m http.server &>/dev/null &'
ssh # see below
ZZ_run # PROMPT_COMMAND='__git_ps1 "'"${PS1%\\*}"'" "\\\$ "'
## ~/.config/bash/bash
# allow sudo to use local aliases
alias sudo='sudo '
export EDITOR=vim
# infinite bash history (currently c. 1MiB)
export HISTFILE="$HOME/.local/share/bash_history"
export HISTFILESIZE=
export HISTSIZE=
export HISTTIMEFORMAT='[%F %T] '
# more filetypes like .log.1.gz
export LESSCLOSE='/usr/bin/lesspipe %s %s'
export LESSOPEN='| /usr/bin/lesspipe %s'
export PATH="$HOME/bin:$PATH"
shopt -s globstar
## ~/.config/bash/ssh
export SSH_AUTH_SOCK="$(gpgconf --list-dirs agent-ssh-socket)"
ensure_known_host() {
local hostname=$1
local known_hosts=${2:-~/.ssh/known_hosts}
ssh-keygen -F "$hostname" -f "$known_hosts" &>/dev/null \
|| ssh-keyscan -H -t ecdsa "$hostname" \
| tee --append "$known_hosts"
}
# hook in a custom git style subcommand
ssh() {
case $1 in
tunnel )
shift
while true; do
date '+%FT%T'
command ssh -R :localhost:22 user@server "$@"
done
;;
* ) command ssh "$@" ;;
esac
}
[WONTFIX]: https://savannah.gnu.org/support/?108134
signature.asc
Description: PGP signature
Re: Salsa update: no more "-guest" and more
On Sun, Apr 26, 2020 at 12:31:42AM +0200, Gard Spreemann wrote: > > Bernd Zeimetz writes: > > 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. Actually, there's a good reason I enable two-factor everywhere despite using a password manager. Password auth submits the same secret over the network on every login, whereas TOTP is based on a pre shared key, so an attacker needs to intercept that initial sharing or phish the OTP. It's probably a minor concern and over the top, but with the ease of use of pass-otp in debian or andOTP in f-droid, why not? I think I've talked myself out of suggesting requiring 2FA on Salsa, but if it's possible to have it by default (opt-out vs opt-in) then that'd be great. signature.asc Description: PGP signature
Re: Proposal: Repository for fast-paced package backports
On Tue, Jan 01, 2019 at 05:49:37PM +0530, Pirate Praveen wrote: > I think STS (Short term support) will fit nicely with LTS. If there is > no serious objections, I'd go with this. As debconf is finishing, though I don't know if either of you attended this year, has there been any progress on this idea? Is there an evergreen/sts/fasttrack destination I can put in my dput.cf to support normally unsuitable packages like jenkins/virtualbox/firefox/gitlab? signature.asc Description: PGP signature
Re: anti-tarball clause and GPL
(debian-devel following Holger's advice, guessing all authors are subscribed) On Thu, Jul 25, 2019 at 10:43:12PM -0300, Yao Wei (魏銘廷) wrote: > What if, one of the upstream authors consider it violating GPL _without_ the > clause? I mean, it could happen. Indeed, and I'd argue this is already the case (implicitly). Consider a security bug reported in Buster, missing from Stretch, that when a fix is found needs to be backported to all upstream supported releases (say, for example, going all the way back to one released just after Stretch). Other than skimming release notes for the affecting change, what would a diligent upstream do to determine which release streams need patching? Would they do a git checkout of each tag, manually testing, but otherwise merely using git as the tarball distribution mechanism? Or would they do a git log on the fixed file to determine when the change was first introduced, then simply git tag --contains? Even better, if the fix is not even known yet, could they `git bisect run foo` to find the breaking commit, then use that knowledge to work out the fix? On Thu, 25 Jul 2019 at 17:40, Adam Borowski wrote: > On Wed, Jul 24, 2019 at 05:18:28AM +, Scott Kitterman wrote: > > On July 24, 2019 12:34:13 AM UTC, Adam Borowski wrote: > > >By this logic, a pile of .c files with comments removed or preprocessed > > >with cpp would be allowed as well. The VCS is also a means to store > > >human-readable comments. > > I infer from this you think projects without a public VCS (postfix is an > > example) belong in non-free? > > At this moment, not yet. Obviously, old projects didn't even _have_ a VCS, > and I'm not proposing imposing a VCS workflow on the upstream. I'd like to > consider, at some point in the future, hidden private VCSes where the upstream > occassionally releases a tarball of to be non-free, just like the same PNG Yes, yes, yes - if upstream would prefer to modify their source with the support that their private git repo provides, then publishing just the make dist tarball does not make sense. The repo doesn't have to publicly-writable or accept pull requests, perhaps even doesn't need to have the entire project history (shallow clone since last release?). On Fri, Jul 26, 2019 at 04:00:04AM +0900, Norbert Preining wrote: > On Wed, 24 Jul 2019, Yao Wei wrote: > > I believe that "flat" tarball in Adam's question means tarball stripping > > out VCS information, not tarball as a format. > > Just one hint, if this comes in I will upload texlive with about a > 70Gb tarball as source ... we have 15 years of history of "flat tarball > of 4Gb". > > I don't think that *this* is the preferred form of changes. Then why do *you* use it to make changes? This would also be a good opportunity to improve Debian's 9G+ support (also for game assets). For the record, the texlive .git is 28G and as mentioned, we could consider the replacement for .orig. to be a shallow bare clone since last upload (git-debpush wishlist?). signature.asc Description: PGP signature
Re: Challenge from Julia's non-standard vendored openblas"64_"
On Sun, Jul 28, 2019 at 02:30:15AM -0700, Mo Zhou wrote: > problem is that the 64-bit indexing variant doesn't > have a standard SONAME. Without knowing anything more than what you've written here (which I didn't find too long), it sounds like maintenance burden is the concern. Am I right in thinking that there still exists non-Julia software for which your solution is cleaner than symbol mangling? Is that LAPACK? > long time ago, we (mainly BLAS/LAPACK maintainers) > decided to use the "SONAME=libXXX64.so" convention > without mangling symbol names. Mangling is not > considered because only openblas supports it. What you would do today if you were packaging it from scratch? If you would pick the Julia approach for ease of maintenance then a SONAME transition seems "simple" enough. If you would implement the cleaner no-mangling approach, then a libopenblas-julia compatibility dependency (option 2) would isolate the problem to the julia ecosystem. > their vendored OpenBLAS to "libopenblas64_.so.*", Ugh, vendoring "compiles for me, so it's your problem". > I have no confidence at all to convince > upstream to change their widely-spread practice. Even when that's the case, it's usually still worth reporting the issue upstream, so they know the pain they're introducing to potential users. All the best from an outsider, and thank you for tackling difficult interoperability decisions in Debian. -- Phil Morrell (emorrp1) signature.asc Description: PGP signature
Re: duprkit User Repository
On Mon, Apr 08, 2019 at 05:00:21AM +, Mo Zhou wrote:
> Plus, it's super important to write every packaging bit into a single
> file. That would enable simple copy&pasting from github or any other
> resources. If you provide a directory, things will become more
> complicated. More impotantly, the proposed single file specification
> virtually adds NO overhead.
Obviously working implementation > perfect theoretical, but I'm confused
by your insistence on a single file without abstraction. Even an
uncompressed tarball can be cat'ed to read the contents, without
requiring a custom format. With a custom format, why not hide
implementation details like source format in "unfold"?
For the DefaultCollection example, don't we have a standardised download
tool in debian/watch? Similarly, the build script is essentially a
debian/rules in its construction. Could you get by with a `cat
debian/{watch,control,rules}`?
--
Phil Morrell
signature.asc
Description: PGP signature
Re: [Idea] Debian User Repository? (Not simply mimicing AUR)
On Sun, Apr 07, 2019 at 07:01:28PM +0200, Alf Gaida wrote: > For debian it could work the same way - just host the debian dir and be done > with. Iirc the kde team work this way, they have only the debian dir in > salsa. With a modified watch file it should be possible to get any source > one want to. So the "only" thing needed is the infrastructure to host and > maintain these repos. The rest is up to the user and a fundamental different > approach as launchpad and ppa's. I like it, and just wanted to share this related idea from the Gentoo world about bootstrapping some automated trust without increasing contribution friction too much: https://dev.gentoo.org/~mgorny/articles/guru-a-new-model-of-contributing-to-gentoo.html#user-access-and-workflow -- Phil Morrell signature.asc Description: PGP signature
Re: Bug#926076: goxkcdpwgen -- xkcd style password generator library and cli tool
On Sun, Mar 31, 2019 at 05:27:03PM +0530, Dhanya Thailappan wrote: > * Package name: goxkcdpwgen > Version : 0.0~git20181107.de898c7-1 > Upstream Author : Martin Hoefling > * URL : https://github.com/martinhoefling/goxkcdpwgen > * License : MIT > Programming Lang: Go > Description : xkcd style password generator library and cli tool Hello, How does this compare to the diceware package? Even the available parameters are very similar. Perhaps you could consider submitting the de_wordlist.txt to the diceware project? https://tracker.debian.org/pkg/diceware https://github.com/ulif/diceware#usage -- Phil Morrell signature.asc Description: PGP signature
Re: salsa.debian.org: merge requests and such
On Sat, Nov 10, 2018 at 10:36:53AM -0200, Herbert Fortes wrote: > On 09/11/2018 20:26, Colin Watson wrote: > > I guessed that the particular commit was > > https://salsa.debian.org/debian/pcre2/commit/6c14b51ddfc45604fd805bcadc810d437f09a30f. > > (The same developer has also been doing a number of other minor cleanups > > in many other packages along the same lines.) > > The fix is good. > > But why the new debian/changelog? It is a honest question. It's just an alternative personal style. Some people like to hand curate the changelog in a standalone commit, especially if not every commit is worth mentioning, or the version number needs changing. Other people want there to be some record of work in progress, showing up on e.g. tracker.debian.org or qa. signature.asc Description: PGP signature
Bug#909798: ITP: ryzomcore -- science-fantasy MMORPG engine
Package: wnpp Severity: wishlist Owner: Phil Morrell * Package name: ryzomcore Version : 3.4.0 Upstream Author : Winch Gate Property Ltd. * URL : http://www.ryzomcore.com/ * License : AGPL3+, CC-BY-SA, GPL-2 Programming Lang: C++, Lua Description : science-fantasy MMORPG engine Ryzom Core is a software platform for creating and running massively multi-user entertainment in a 3D environment over the Internet. Ryzom Core provides the base technologies and a set of development methodologies for the development of both client and server code. The library contains independently reusable network, ai and 3d modules. --- I'm not actually sure yet if the software is suitable for debian, but I'm filing the ITP to avoid duplication of effort and to document any relevant considerations. It will be packaged as part of the Games Team. https://salsa.debian.org/emorrp1-guest/ryzomcore https://ryzom.com/ is almost fully free software: client, server, tools, and graphics. The audio assets are currently proprietary "as Ryzom has not determined the copyright nature of those assets" and so is the official world configuration and data. Assets are c. 8GB uncompressed. A fully libre world server is in development https://khaganat.net The NeL library was previously packaged in Debian up to Wheezy. signature.asc Description: PGP signature
Bug#900867: ITP: firefox-syncserver -- Firefox Sync storage and token server
Package: wnpp Severity: wishlist Owner: Phil Morrell * Package name: firefox-syncserver Version : 1.8.0 Upstream Author : Mozilla Corporation * URL : https://github.com/mozilla-services/syncserver * License : MPL-2.0 Programming Lang: Python 2 Description : Firefox Sync storage and token server This is an all-in-one package for running a self-hosted Firefox Sync server. It bundles the "tokenserver" project for authentication and the "syncstorage" project for storage, to produce a single stand-alone webapp. This server defers authentication to the Mozilla-hosted accounts server at https://accounts.firefox.com, but stores the user sync data such as bookmarks, preferences and add-ons. --- It is useful for using the multiple-device features of Firefox Sync without storing your sensitive data in the cloud. It would also be a prerequisite for someone packaging the Firefox Accounts server. I would love to maintain it as part of pkg-mozilla-maintainers, but since the alioth list is defunct I've not yet got in touch. https://salsa.debian.org/emorrp1-guest/firefox-syncserver signature.asc Description: PGP signature
Re: path to gitlab upstream
On Wed, May 30, 2018 at 03:10:57PM +0200, Geert Stappers wrote:
> On Tue, May 29, 2018 at 01:04:33PM +0100, Ian Jackson wrote:
> > Ansgar Burchardt writes ("Re: Want to make salsa advertise contact and
> > source code details [and 1 more messages]"):
> > > That seems like an horrible maintenance nightmare just to avoid even
> > > talking to upstream...
> >
> > OK, so does someone in Debian, maybe from the Salsa team, have any
> > contacts I could use ? (I promise to be reasonable and polite.)
> > Or should I just try to go in through the "front door" and create an
> > issue in Gitlab CE's gitlab ?
> >
> > ISTM that the former approach is more likely to work if we know anyone
> > at Gitlab already.
>
> There is https://gitlab.com/gitlab-org/gitlab-ce/
>
> It has currently 10,712 issues and 595 merge requests.
>
> About the issues: Open: 10,712 Closed: 25,941 All: 36,653
> MR: Open: 595 Merged: 15,906 Closed 2,696 All: 19,198
In the spirit of Debian (not necessarily Salsa team) communication with
GitLab development, I note that Gnome have coordinated under "GNOME List
of Issues & Priorities" [43566]. Perhaps Debian should also have an open
issue for requests from DDs, at the moment I can only find relevant
issues by searching for "salsa".
--
Phil Morrell (emorrp1)
[43566]: https://gitlab.com/gitlab-org/gitlab-ce/issues/43566
signature.asc
Description: PGP signature
