Re: Mandatory LC_ALL=C.UTF-8 during package building
On 07/06/24 14:32, Guillem Jover wrote: Related to this, dpkg-buildpackage 1.20.0 gained a --sanitize-env, which for now on Debian and derivatives sets LC_COLLATE=C.UTF-8 and umask=0022. That's great news! But _iff_ we end up with dpkg-buildpackage being declared the only supported entry point, [...] Personally, I really appreciate how dpkg-buildpackage more and more provides a standardized API to/for building Debian packages. However I would prefer to have this API explicitly described in Policy rather than hidden and implicitly defined by the code of a specific program. What I propose is a new section in Policy [1] that explicitly lists all these environment requirements (umask, LC_*, SOURCE_DATE_EPOCH, TMPDIR, /bin/sh = POSIX shell + -n, etc). Each builder would then be changed to be conformant by default, with the option to steer away if desired (for example `dpkg-buildpackage --with-env-var LC_ALL=fr_FR.UTF-8`). This would create an uniform environment while preserving the ability to run d/rules with user-specific settings. [1] Or any other similarly "binding" document. Regards, -- Gioele Barabucci
Mandatory LC_ALL=C.UTF-8 during package building
Hi, setting LC_ALL=C.UTF-8 in d/rules is a common way to fix many reproducibility problems. It is also, in general, a more sane way to build packages, in comparison to using whatever locale settings happen to be set during a build. However, sprinkling a variant of `export LC_ALL=C.UTF-8` in every d/rules is error-prone and a waste of maintainers' time. Would it be possible to set in stone that packages are supposed to always be built in an environment where LC_ALL=C.UTF-8, or, in other words, that builders must set LC_ALL=C.UTF-8? In which document should this rule be stated? Policy? Regards, -- Gioele Barabucci
Re: finally end single-person maintainership
On 12/04/24 15:00, Marc Haber wrote: On Fri, 12 Apr 2024 09:26:10 +, Mike Gabriel wrote: Also regarding gbp, my packaging workflow does not require it (debian/-folder-only in Git). Being enforced to use some other pkg'ing style would reduce my fun and end up with less productivity, I fear. The gbp workflow has its pros, but for me it is a too complex overhead without much gain to the end result (the uploaded package). The debian/-only layout was quite common in the svn days and back then we had adequate tooling to support that but those tools have rotted away, it feels unnatural to me, and, frankly, exim's debian/-only layout (that I introduced myself fifteen^wtwenty years ago) is the main reason why I am a mostly inactive member on the exim team since I still don't know any more how to properly build the package. This is not an endorsement of debian/-only repos, but building debian/-only packages using gbp is not hard: $ git clone https://salsa.debian.org/exim-team/exim4.git $ cd exim4 $ cat < debian/gbp.conf [DEFAULT] export-dir = ../ overlay = True debian_branch = master EOF $ origtargz $ gbp buildpackage --git-ignore-new --git-no-create-orig (This is more a praise of gbp rather than a defense of debian/-only repos.) -- Gioele Barabucci
Re: finally end single-person maintainership
On 09/04/24 18:52, Wookey wrote: So why mandate salsa rather than make dgit more official? Independently from whether salsa should be mandated, "git", "salsa" and "dgit" are three different things and should not be used as replacement of one another. Asking maintainers "to use git" means: please push your changes, even those unreleased to a public git repository (salsa, github, codeberg, your own domain...), so other people can contribute 1) knowing that they are working against the same sources the maintainer has on their hard drive, and 2) using git-based workflows. dgit is both a Web interface to browse git repositories as wells as a system to access the Debian archive as if it were a git repository, so you can "dgit push" a branch and have the resulting binary uploaded to the archive. (Yes, I'm simplifying here, but that's the gist.) Salsa is a forge, i.e. a combination of a Web interface, a git server, and a set of integrated features. In comparison to dgit, salsa has, like most forges: * Merge requests: where people can suggest changes and discuss them with line-based comments (accessible via email, no need to use the Web interface) * Continuous integration pipelines: as soon as you push a commit, Salsa-CI will try to build a package, cross build it, test it against piuparts, lintian a bunch of other QA tools (kudos to the Salsa-CI developers). * Integrations with two dozen tools (irc, jenkins, mattermost, bugzilla, but funnily enough not BTS). * Project specific wikis, snippets, Docker images. * And with tag2upload salsa fulfills 50% of dgit functionality. Regards, -- Gioele Barabucci
Re: About Package Maintenance
On 09/04/24 08:52, Simon Richter wrote: Otoh, I am fully aware of the "you can't force a volunteer to do things", knowing that I myself would be the first one to violently oppose a decision that I don't like while - at the same time - being mad at some core package maintainers who have forced the project to jump through even more burning hoops to finally get the usrmerge migration The project has always had, and continues to have the two options "submit a patch" and "replace the maintainer." We have processes for that. No one, especially not the people driving the usrmerge migration, wants to do that, because that would require taking on a long-term commitment and the responsibility that comes with it, when they would prefer to do a drive-by contribution. Hence we are having a debate again whether there should be a mechanism to force maintainers to accept any patch thrown at them by someone "authorized" to perform a global change. No result can be reached from this debate, because there is no difference between force-accepting a contribution and replacing a maintainer. Between forcing maintainers to accept drive-by patches as-is and replacing them, there is also the option of asking maintainers to respond to patches in a "timely"* fashion instead of letting them rot in the BTS or forcing the requester to do an NMU. "A timely response" could be two weeks for packages in (build-)essential, one month for top-10% popcon packages, three months for all other packages. Tagging as "wontfix" would also be an OK response, at least the project will have a clear and explicit view of what is blocking distro-wide changes. Regards, -- Gioele Barabucci
Re: finally end single-person maintainership
On 07/04/24 23:11, Bill Allombert wrote: What is your opinion about pushing logtool to Salsa? Not speaking for logtool obviously, but maintaining simple packages on salsa is just useless bureaucracy. As a contributor, having a package on salsa is extremely useful, far from "useless". By clicking on "fork" (or running the equivalent CLI command) I get a copy of the package, with all its history, a Debian-specific CI, the ability to work on different features or bug fixes at the same time and independently from one another, the possibility to send a merge request, that can be annotate line-by-line by all other Debian contributors. A package with a repo on salsa is sending a clean message: go away, I don't want your contribution. Most of the actual packager work is not reflected in the source package. Testing that the package integrates well with the rest of Debian, That time is better invested writing autopkgtests and letting Salsa-CI and debci run the tests. Having autopkgtests also lowers the barrier to contribute because the contributors can now be more confident of the fact that their changes did not cause any issue. replying to bug reports, Not affected by having a repo on salsa. communicating with upstream etc. Upstream that in 99% of the cases uses a git repo. I maintain a number of packages. Some are on Salsa, some are not, some are team maintained, some are not, some use dh, some use debhelper etc. This is a matter of efficiency, one size does not fit all. The lack of a standardized sanctioned workflow is the main reason (together with unresponsive maintainers) why big cross-distro changes are nigh impossible to carry out. I would not classify it as a big advantage. Regards, -- Gioele Barabucci
Re: Validating tarballs against git repositories
On 31/03/24 08:59, Sven Joachim wrote: The coreutils bootstrap script fetches files over the network, so it is not possible to build the Debian package from upstream git tags. At the very least it would lack any translations, and there is also the problem of the gnulib submodule. Aren't these the same kinds of problem that affect go and rust packages? -- Gioele Barabucci
Re: Validating tarballs against git repositories
On 30/03/24 20:43, Iustin Pop wrote: On 2024-03-30 11:47:56, Luca Boccassi wrote: On Sat, 30 Mar 2024 at 09:57, Iustin Pop wrote: Give me good Salsa support for autopkgtest + lintian + piuparts, and easy support (so that I just have to toggle one checkbox), and I'm happy. Or even better, integrate all that testing with Salsa (I don't know if it has "CI tests must pass before merging"), and block tagging on the tagged version having been successfully tested. This is all already implemented by Salsa CI? You just need to include the yml and enable the CI in the settings I will be the first to admit I'm not up to date on latest Salsa news, but see, what you mention - "include the yml" - is exactly what I don't want. Salsa CI is enabled by default for all projects in the debian/ namespace <https://salsa.debian.org/debian/>. Adding a yml file or changing the CI settings to reference the Salsa CI pipeline is needed only for projects in team- or maintainer-specific repositories, or when the dev wants to enable additional tests (or configure/block the default tests). Regard, -- Gioele Barabucci
Git and SHA1 collisions (Was: Re: Validating tarballs against git repositories)
On 30/03/24 23:09, Simon Josefsson wrote:
Russ Allbery writes:
Simon Josefsson writes:
Sean Whitton writes:
We did some analysis on the SHA1 vulnerabilities and determined that
they did not meaningfully affect dgit & tag2upload's design.
Can you share that analysis? As far as I understand, it is possible for
a malicious actor to create a git repository with the same commit id as
HEAD, with different historic commits and tree content. I thought a
signed tag is merely a signed reference to a particular commit id. If
that commit id is a SHA1 reference, that opens up for ambiguity given
recent (well, 2019) results on SHA1. Of course, I may be wrong in any
of the chain, so would appreciate explanation of how this doesn't work.
I believe you're talking about two different things. I think Sean is
talking about preimage resistance, which assumes that the known-good
repository is trusted, and I believe Simon is talking about manufactured
collisions where the attacker controls both the good and the bad
repository.
Right. I think the latter describes the xz scenario: someone could have
pushed a maliciously crafted commit with a SHA1 collision commit id, so
there are two different git repositories with that commit id, and a
signed git tag on that commit id authenticates both trees, opening up
for uncertainty about what was intended to be used. Unless I'm missing
some detail of how git signed tag verification works that would catch
this.
Git contains a couple of countermeasures meant to greatly reduce the
practical feasibility of such manipulations.
The first is the fact that it uses a hardened SHA-1 function that
produces different hashes when it is fed one of the known collision
seeds ("disturbance vectors"). This hardened version of SHA-1 is only
resistant against known attacks, but it substantially raises the bar
from "use one of these files downloaded from the Web" to "set up your
own collision generator that will work only once for this specific
attack and once discovered will no longer work".
From https://lwn.net/Articles/716093/
Git can be configured with the USE_SHA1DC build time configuration
variable to use SHA-1 implementation from shattered.io that detects
attempted collisions
From https://shattered.io/
Is Hardened SHA-1 vulnerable? No, SHA-1 hardened with
counter-cryptanalysis (see ‘how do I detect the attack’) will detect
cryptanalytic collision attacks.
The second countermeasure is the fact that if two objects (e.g.,
commits) happen to have the same hash, then Git will use the one it has
seen first. In the common case in which the original author has pushed a
commit and the attacker subsequently pushed a malicious version of that
commit with the same hash, then all people that fetch that repository
will always see (as in, write to disk during a checkout) the original
version, not the malicious version. The malicious version will still be
in the git pack, but git will ignore it.
From https://marc.info/?l=git=115678778717621=2
Nope. If it has the same SHA1, it means that when we receive the
object from the other end, we will _not_ overwrite the object we
already have. […] if we ever see a collision, the "earlier" object
in any particular repository will always end up overriding
With these countermeasures in places, in order to successfully pull a
collusion attack, the attacker must:
1. Create an unseen collision seed.
2. Have access to the server that hosts the official repo to remove
traces of the original commit.
3. Hope that nobody pulled the repo before they tampered it.
4. Hope that nobody will notice a series of random characters being
shown during operations like git log -p.
Sure, SHA1 is broken, should be avoided and not relied upon. And many
people can easily see how to work around the countermeasures put in
place by SHA1.
But pulling a successful collision attack is not a trivial task. For
instance, the xz attacker did not have all that was required to carry it
out (for example they had no direct access to the git servers... yet).
Regards,
--
Gioele Barabucci
Re: Validating tarballs against git repositories
On 30/03/24 14:08, Jonathan Carter wrote: On 2024/03/30 12:43, Sean Whitton wrote: On 2024-03-30 08:02:04, Gioele Barabucci wrote: Now it is time to take a step forward: 1. new upstream release; 2. the DD/DM merges the upstream release VCS into the Debian VCS; 3. the buildd is notified of the new release; 4. the buildd creates and uploads the non-reviewed-in-practice blobs "source deb" and "binary deb" to unstable. This change would have three advantages: I think everyone fully agrees this is a good thing, no need to list the advantages. > It is also already fully implemented as tag2upload, and is merely as yet undeployed, for social reasons. My understanding is that DSA aren't quite comfortable with it, since it would need to archive GPG signing key (or a keypair trusted by DAK)? Don't the buildd already work like in similar way? The source deb is signed by the DD, the buildd checks the signature of the source deb, then builds and signs the binary debs. In the future the tag is signed by the DD, the buildd checks the signature of the tag, then builds and signs the source deb and the binary debs. -- Gioele Barabucci
Re: Validating tarballs against git repositories
On 30/03/24 13:38, Jonathan Carter wrote:
On 2024/03/30 11:05, Simon Josefsson wrote:
1. Move towards allowing, and then favoring, git-tags over source
tarballs
>
Some people have suggested this before -- and I have considered adopting
that approach myself, but one thing that is often overlooked is that
building from git usually increase the Build-Depends quite a lot
compared to building from tarball
How in the world do you jump to that conclusion?
Usually it's due to thing like precompiled documentation:
{man,info}pages, HTML pages.
To generate these files you usually need texinfo, groff, pandoc, sphinx,
etc. All big packages with plenty of runtime and build-time dependencies.
But as I said, for cases like arch rebootstraps, can remove the
need to bootstrap a long (and often circular) chain of dependencies.
Regards,
--
Gioele Barabucci
Re: Validating tarballs against git repositories
On 30/03/24 10:05, Simon Josefsson wrote: Antonio Russo writes: 1. Move towards allowing, and then favoring, git-tags over source tarballs Some people have suggested this before -- and I have considered adopting that approach myself, but one thing that is often overlooked is that building from git usually increase the Build-Depends quite a lot compared to building from tarball, and that will more likely trigger cyclic dependencies. People that do bootstrapping for new platforms or cross-platform dislike such added dependency. Most of the time such added dependencies could be worked around with build profiles and cross building. More widespread support for , and Multi-Arch annotations can greatly reduce the number of deps needed to bootstrap an architecture. Just as an example, bootstrapping coreutils currently requires bootstrapping at least 68 other packages, including libx11-6 [1]. If coreutils supported [2], the transitive closure of its Build-Depends would be reduced to 20 packages, most of which in build-essential. [1] https://buildd.debian.org/status/fetch.php?pkg=coreutils=amd64=9.4-3.1=1710441056=1 [2] https://bugs.debian.org/1057136 Regards, -- Gioele Barabucci
Re: Validating tarballs against git repositories
On 30/03/24 01:21, Antonio Russo wrote: 3. Have tooling that automatically checks the sanitized sources against the development RCSs. git-buildpackage and pristine-tar can be used for that. 4. Look unfavorably on upstreams without RCS. And look unfavorably on Debian packages without VCS. And, in addition: 5. Require something like tag2upload to create new releases of Debian packages. For too many core packages there is an opaque "something happens on the Debian maintainer laptop" step that has no place in 2024. We have no idea how many Debian DDs/DMs machiens have been compromised because of this attack. (Hopefully zero.) Any future upload of source debs may, in principle, contain malicious code. The workflow for Debian packages has already gone from: 1. new upstream release; 2. something happens on the DD/DM machine; 3. the DD/DM uploads two non-reviewed-in-practice blobs (source deb, binary deb) to unstable. to: 1. new upstream release; 2. something happens on the DD/DM machine; 3. the DD/DM uploads a non-reviewed-in-practice blob (source deb) to the buildd; 4. the buildd compiles the source deb into the binary deb; 5. the buildd uploads a non-reviewed-in-practice blob (binary deb) to unstable. This change moved a lot of trust from the hands (and machines) of a myriad of DDs/DMs into a handful of closely guarded build machines. A compromised gcc on the DD/DM machine is no longer a problem. But a compromised tar/dpkg/debhelper still is. Now it is time to take a step forward: 1. new upstream release; 2. the DD/DM merges the upstream release VCS into the Debian VCS; 3. the buildd is notified of the new release; 4. the buildd creates and uploads the non-reviewed-in-practice blobs "source deb" and "binary deb" to unstable. This change would have three advantages: * Make the whole process happen outside the DD/DM computer, so it becomes more public and easier to review (commits vs debs), removing many chances for compromises. * Close two specific attack vectors (hiding code in upstream release tarballs and in source debs) that have always existed and for one of which we have now proof of exploitation. * Force attackers to do their work under public scrutiny, raising the complexity and the cost of carrying out an attack. Yes, such a workflow will not stop many other attack vectors, but at least _these_ attack vectors will be stopped. Regards, -- Gioele Barabucci
Re: On merging bin and sbin
On 28/02/24 19:08, Peter Pentchev wrote: On Wed, Feb 28, 2024 at 08:47:48AM -0600, r...@neoquasar.org wrote: From: Gioele Barabucci This is a quick'n'dirty list of binaries present in both /bin and /sbin: arping bin net/iputils-arping sbin net/arping (+ Conflicts:) Are any of these (like arping) literally duplicates of the same binary for some reason? Or are they true conflicts (different binaries with the same name)? I don't know about many of the others (although I have my suspicions), but the two programs that just happen to both be called arping are not the same at all: they have different functionality, conflicting command-line options, etc. And that is one of issues. Without looking, could you say which package installs `arping` in /bin and make it available for non-root users? Policy also has a couple of things to say. For example https://www.debian.org/doc/debian-policy/ch-files.html#binaries Two different packages must not install programs with different functionality but with the same filenames That can (should?) be interpreted as "no same basename". Otherwise root will face and ambiguous choice between the one in /bin and the one in /sbin. In any case, many of these clashes are known. This is why some of these packages declare Conflicts: with each other. However... Be aware that adding Conflicts is normally not the best solution when two packages provide the same files. Depending on the reason for that conflict, using alternatives or renaming the files is often a better approach. https://www.debian.org/doc/debian-policy/ch-relationships.html#conflicting-binary-packages-conflicts Regards, -- Gioele Barabucci
Re: On merging bin and sbin
On 28/02/24 14:12, rhys wrote:
Last thing: The idea of detecting cases where multiple binaries have the same name is a
verey good one. It should also be possible to automate this effort in a number of ways.
I would be happy to help with this, if it's just a matter of someone putting in the
effort. A number of "crude by effective" methods have already come to mind,
some of which only require access to the repos to accomplish. (The laziest method
involves having a test machine with EVERY package installed... but I'm not sure if that
is practical.)
Contents-{all,amd64} has most of the info you need. dumat.db has _all_
the info you need (and cacin is using that).
This is a quick'n'dirty list of binaries present in both /bin and /sbin:
arping bin net/iputils-arping sbin net/arping (+ Conflicts:)
bitesize bin devel/ubuntu-dev-tools sbin misc/libbpf-tools
crm bin mail/crm114 sbin admin/crmsh
fai bin python/python3-flask-autoindex sbin admin/fai-client
faxq bin comm/mgetty-fax sbin comm/hylafax-server (+ Conflicts:)
gearmand bin perl/gearman-server sbin misc/gearman-job-server
htpasswd bin httpd/apache2-utils sbin web/merecat (+ Conflicts:)
ipp* bin net/ippsample sbin net/cups-ipp-utils (+ Conflicts:)
newaliases bin mail/esmtp-run sbin
mail/courier-mta,mail/opensmtpd,mail/ssmtp (+ Conflicts: + Provide:)
raddebug bin libs/librad0-tools sbin net/freeradius
sendfax bin comm/hylafax-client sbin comm/mgetty-fax (+ Conflicts:)
sethdlc bin hamradio/ax25-tools sbin comm/dahdi
siggen bin sound/siggen sbin utils/tripwire
sslh bin perl/libnet-proxy-perl sbin net/sslh (+ Conflicts:)
tcpconnect bin net/tcputils sbin misc/libbpf-tools
tcpd bin graphics/tcm sbin net/tcpd
update-locale bin web/gosa-dev sbin localization/locales
Regards,
--
Gioele Barabucci
Re: On merging bin and sbin
On 28/02/24 12:25, Ansgar wrote: This can be good, but it can also be seen as a pollution of your shell completion. I note that Fedora seems to have added /sbin to the user $PATH by default, which is not what Debian has done. I do not think we have consensus on this and would raise an objection of my own. /sbin not in PATH by default makes many more veteran users unhappy. Also non veteran users, given that certain commands in /sbin just work fine when run as non-root (or actually should _not_ be run as root because they trust their input). For example: * fatlabel * findfs * fsck.* * isosize * mkfs.* * route * tarcat But aside from the $PATH question, cacin work on ensuring that there are no conflicts between /sbin and /bin is worth pursuing as these conflicts are just bugs waiting to happen. Regards, -- Gioele Barabucci
Re: Another take on package relationship substvars
On 24/02/24 11:26, Bernd Zeimetz wrote:
On Thu, 2024-02-22 at 20:52 +0100, IOhannes m zmölnig wrote:
I think there are some packages that even demote `${shlibs:Depends}`
to Recommends.
Absolutely. collectd for example - otherwise you would install *all*
plugin dependencies with collectd, which would be a big waste of space.
The other option would be to make one packe per plugin as redhat does,
but do we really want 20 packages with a single file?
Yes, please. So that installing package collectd-foo ensures that all
the required dependencies are installed, instead of having to hunt them
down (a task better left to the package maintainers rather than the end
users).
PS: I volunteer to do the splitting.
Regards,
--
Gioele Barabucci
Re: Proposal for how to deal with Go/Rust/etc security bugs
On 24/01/24 14:01, Luca Boccassi wrote: how does that work for those applications that require rust, go and friends? Are you proposing that everything that needs them should be be distributed by a flatpak or similar mechanism instead? Those applications are not shipped in the distribution. If somebody wants to use them, they'll have to figure it out, just like for everything else that is not shipped in the distribution, which is already a subset of all available software in the world. The risk is that that subset will get even smaller and miss out on new developments: Debian will then be stuck as a "C distribution" and with C & Co becoming more and more legacy, that means that Debian will become a "legacy distribution". It is nice to know that, even if the paradigms are changing, one can still apt install caddy, etcd, acmetool, influxdb, prometheus, sq, firefox... -- Gioele Barabucci
Re: Policy: should libraries depend on services (daemons) that they can speak to?
On 15/01/24 18:58, Russ Allbery wrote: When you have the case of an application that optionally wants to do foo, a shared library that acts as a client, and a daemon that does foo, there are three options: From the point of view a Debian package there are four options: Depends:, Recommends:, Suggests:, Enhances:, [nothing]. Perhaps a fifth category is needed for this shared-library-that-talks-to-a-deamon scenarion. Or the whole D/R/S system could be changed to be more explicit about why a package Depends: or Recommends: another one: * LinksToLibrary (Depends:) * UsesProgram (Depends:) * UsesProgramInMaintscript (Pre-Depends:) * TalksToDaemon (Depends:) * TalksToDaemonIfAvailable (Recommends:/Suggests:) * LoadsAtRuntimeIfAvailable (Recommends:/Suggests:) * IsPluginFor (Enhances:) Regards, -- Gioele Barabucci
Drawbacks of lack of mandated packaging workflow (Was: Re: Bug#1036884: 64-bit time_t: updated archive analysis, proposed transition plan with timeline)
On 05/01/24 21:17, Paul Gevers wrote: Another worry, how will you provide the required changes to the maintainers of the packages? Via BTS? For those working on salsa: MR? Both? Something else? Obviously we should not end in the situation that a new upload goes back to the old name (or are the ftp-masters so keen on this transition that that won't happen? But what about newer versions with the old name already in experimental, conform the former worry?). I've seen NMU's being ignored by subsequent uploads by the maintainer, even when they fixed RC issues which were then reintroduced. Aren't all these problems just inherent in Debian's lack of a mandated packaging tooling and workflow [1,2]? And the fact that maintainers can decide to maintain their packages in idiosyncratic ways (e.g., no VCS) "just because"? [1] https://salsa.debian.org/debian/grow-your-ideas/-/issues/24 [2] https://salsa.debian.org/debian/grow-your-ideas/-/issues/34 Regards, -- Gioele Barabucci
Re: Deprecation of /etc/alternatives? (Re: Reaction to potential PGP schism)
On 24/12/23 08:54, Alastair McKinstry wrote: While we are on the topic of alternatives, I hope to see the maintscript-based /etc/alternatives paradigm deprecated in favor of the package-based X-is-X paradigm introduced by `python-is-python3`. They have different use-cases. alternatives allows for co-installability (and importantly - co-"buildability" with dependencies). the X-is-X guarantees essentially the opposite. I don't see X-is-X as a different use case when it comes to applications: both gnupg and sq-chameleon-gnupg could be installed at the same time. After the installation there would be no /usr/bin/gpg. Once the user installs, say, ggp-is-gnupg then /usr/bin/gpg will point to /usr/bin/gpg-gnupg. Users (and scripts) are still free to install the other package and use /usr/bin/gpg-sq. The only Conflicts: here would be between gpg-is-gnupg and gpg-is-sq-chameleon. Regards, -- Gioele Barabucci
Deprecation of /etc/alternatives? (Re: Reaction to potential PGP schism)
On 22/12/23 00:40, Daniel Kahn Gillmor wrote: If you're asking about using /etc/alternatives or something like that to provide some sort of generic swapping capability, or a dpkg Provides:, such that /usr/bin/gpg on some systems would point toward the "chameleon", i would want to see some significant archive-wide testing done before we even consider inflicting that on our normal users. While we are on the topic of alternatives, I hope to see the maintscript-based /etc/alternatives paradigm deprecated in favor of the package-based X-is-X paradigm introduced by `python-is-python3`. In this scenario gnupg will ship gpg as /usr/bin/gpg-gnupg, while sequoia-chameleon-gnupg will ship its gpg as /usr/bin/gpg-sq. Then the user can decide to install gpg-is-gnupg or gpg-is-sequoia (with the distro-wide preference expressed setting the appropriate Recommends in gnupg or sequoia-chameleon-gnupg). Regards, -- Gioele Barabucci
Re: Reaction to potential PGP schism
On 21/12/23 04:16, Daniel Kahn Gillmor wrote: # What Can Debian Do About This? I've attempted to chart one possible path out of part of this situation by proposing a minimized, simplified interface to some common baseline OpenPGP semantics -- in particular, the "Stateless OpenPGP" interface, or "sop", as documented here: https://datatracker.ietf.org/doc/draft-dkg-openpgp-stateless-cli/ Hi, thanks for the detailed overview. As the Uploader of rust-sequoia-openpgp, what do you think of the related sequoia-chameleon-gnupg project [1] (drop-in replacement for gpg that uses sequoia internally)? Would it work as a stop-gap measure while the Debian infrastructure moves from GnuPG to something else (to `sop`, for instance)? Regards, [1] https://gitlab.com/sequoia-pgp/sequoia-chameleon-gnupg not yet in Debian AFAIK -- Gioele Barabucci
Re: New Essential package procps-base
On 14/11/23 11:11, Helmut Grohne wrote: I welcome the effort in general. Like Andreas, I question whether having pidof remain essential is useful. A quick codesearch https://codesearch.debian.net/search?q=%5Cbpidof%5Cb=0 suggests that we have less than 500 source packages that even mention it. Many uses are in test suites or documentation, so the final number will be lower still. Last year Andreas and I had a quick look at what it would take to remove all pidof instances from maintscripts. In a couple of days we fixed a dozen packages. This is our progress log: <https://salsa.debian.org/-/snippets/621>. In short, there are only 23 packages whose maintscripts assume the presence of pidof and that need to be fixed. Regards, -- Gioele Barabucci
Re: reference Debian package of multiple binaries sharing one man page
On 11/11/23 08:12, Tobias Frost wrote: On Fri, Nov 10, 2023 at 08:20:35PM +0100, Norwid Behrnd wrote: I seek a maintained Debian package which provides multiple binaries sharing one man page in common -- do you know an example? devscripts - it links debchange.1 to dch.1 via debian/links (dh_link) $grep -r dch debian/links /usr/bin/debchange /usr/bin/dch Please note that using d/links for manpages breaks building packages with , unless dh-exec is used and the manpages links are marked with . Regards, -- Gioele Barabucci
Re: Bug#1041731: Hyphens in man pages
On 16/10/23 08:36, Gard Spreemann wrote: I've also found scdoc to be a quite pleasant and very lightweight alternative I've noticed that the bullet points in man pages produced by scdoc are "off" compared to those produced by "pod2man". For example compare https://manpages.debian.org/unstable/scdoc/scdoc.5.en.html#LISTS to https://manpages.debian.org/unstable/debhelper/debhelper.7.en.html#Substitutions_in_debhelper_config_files The scdoc-produced lists are typeset with small dots, and have no spaces between the bullet points and the text. The pod2man lists have instead large dots and contain a space between the bullet points and the text. Perhaps is it just a bug in the man-to-html conversion? Or is scdoc producing wrong roff markup? Regards, -- Gioele Barabucci
Re: Hyphens in man pages
On 15/10/23 19:13, Johannes Schauer Marin Rodrigues wrote: Quoting Gioele Barabucci (2023-10-15 17:59:32) On 15/10/23 17:33, Iustin Pop wrote: At least you're not lazy. I am, so what I did many times is add a build-depends on pandoc, and write the man page in rst or md. I think that's a worse solution (pandoc is really heavy), but at least, I don't have to go back to *roff. Another option for the members of the lazy club is `podlators-perl`. that is a virtual package provided by perl. What mechanism exactly are you referring to when mentioning podlators-perl? I was referring to `pod2man`, provided by the `podlators` Perl module. `podlators-perl` is currently provided by `perl` but once upon a time it was a standalone package. Old habits. :) -- Gioele Barabucci
Re: Hyphens in man pages
On 15/10/23 17:33, Iustin Pop wrote: At least you're not lazy. I am, so what I did many times is add a build-depends on pandoc, and write the man page in rst or md. I think that's a worse solution (pandoc is really heavy), but at least, I don't have to go back to *roff. Another option for the members of the lazy club is `podlators-perl`. The `.pod` syntax is OK, and it is not as heavy a dependency as pandoc. Regards, -- Gioele Barabucci
MR against patched package (Was: Please give a test to cron package, in experimental)
On 10/10/23 10:15, Alex wrote: So I wonder why you don't just provide an additional branch "master-patched" against which merge requests can be opened without the risk of causing conflicts with existing patches. This can be easily done with git-buildpackage's `pq` (patch queue) subcommand. And it could be automated on salsa.d.o with a post-receive hook. ``` $ # turn debian/patches* into a branch $ gbp pq import $ # force push the generated branch to the repo on salsa $ git push -f salsa patch-queue/master:master-patched ``` MRs against master-patched will then be possible, but they will require one extra step from the maintainer (i.e. `gbp pq export`) to turn these MRs into normal standalone patch files stored in debian/patches. Regards, PS: `gbp pq import/export` is a much better interface to debian/patches compared to plain `quilt`. -- Gioele Barabucci
Re: Bug#1053165: ITS: nunit
On 28/09/23 17:22, Bastian Germann wrote: Okay. What do you suggest for "team maintained" packages where there is no active team member? File MIA processes for each of the uploaders? And then? The MIA team's bugs are not RC bugs, An automatic time-based "orphaning + RC" process like the one described in [1] would solve (or greatly reduce) of most of these issues. I think, just letting such packages rot for one or two decades does not help anybody, certainly not our users. I'd say that this whole discussion reinforces the need for a third option between "it's fully maintained" and "it's orphaned" [2]. A third option that recognizes and provides rules for low-commitment QA work on non-actively maintained packages. [1] https://lists.debian.org/debian-devel/2023/09/msg00237.html [2] https://lists.debian.org/debian-devel/2023/09/msg00358.html Regards, -- Gioele Barabucci
Re: Abandonware in testing (Re: lpr/lpd)
On 25/09/23 14:29, Wookey wrote: It's actually quite well-maintained, just not by the maintainer: someone else has uploaded the last 3 upstream versions via debian-mentors. I think this example shows the need for a level of maintainership that sits between "fully maintained" and "orphaned". (Or a rethinking of the concept of "orphan packages".) Right now in Debian there is a distinction between: 1) maintained packages (Maintainer: "foo") and 2) orphaned packages (Maintainer: "Debian QA Group"). State 1 is the desired state of a package: somebody (a single person or a team) looks after this package, packages and tests new releases, and is expected to respond to inquiries (bug reports, MRs, NMUs) within a reasonable time. State 2 is an undesired state that should be addressed. Somebody from the QA team (= theoretically the whole of Debian) may have a look at it in case of transitions or RC bugs. But what Debian really desires is that somebody will adopt this package and put their name in the Maintainer: field. What I think is needed is a state 3 (or 1.5) that formalizes what Wookey described: there is an informal group of people that may take care of a package, but they don't feel like having their names attached to it nor want the responsibility of being the ones in charge for timely fixes or quick replies. The way I picture it, "state 3" packages would have something like "Debian Caretaking Team" in the Maintainer: field (not the usual "QA Group", and have autotests in lieu of a specific person/team that takes care of manually testing the package. Has such a third category already been discussed or explored? -- Gioele Barabucci
Abandonware in testing (Re: lpr/lpd)
On 22/09/23 09:41, Christoph Biedl wrote: I doubt simple rules will really work out, rules like that one I had in mind "Packages are removed from testing once they have been orphaned/last maintainer-uploaded more than five years ago". Maybe something more nuanced may work. For example: packages are removed from testing if: - have been orphaned/last maintainer-uploaded more than 2 releases ago, - have no autopkgtests OR autopkgtests fail OR are not lintian/piuparts-clean. Regards, -- Gioele Barabucci
Re: debian testing daily build: installing GRUB/Bootloader and initramfs failing!!
On 17/09/23 09:46, André Verwijs wrote: debian testing daily build: installing GRUB/Bootloader and initramfs failing!! Probably you stumbled upon this problem: https://bugs.debian.org/1040899 The root cause has (hopefully) been fixed by the Debian Installer team and will be released soon: https://bugs.debian.org/1031183 Regards, -- Gioele Barabucci
Re: /usr/-only image
On 15/09/23 20:44, Luca Boccassi wrote: In fact, Marco yesterday told me the only blocker to boot a minimal Debian image with only /usr is PAM Related: For compat >= 14 dh_installpam will install PAM modules in /usr, not /etc: https://salsa.debian.org/debian/debhelper/-/merge_requests/63 -- Gioele Barabucci
Re: Default font: Transition from DejaVu to Noto
On 12/09/23 08:24, Fabian Greffrath wrote:
Instead, even
the fonts-noto-core package installs a full pack of 268 (!) font files.
This is discussed in detail in #983291 [1].
The issues is not that there are too many files, but that these files
become extra entries in font pickers (1 entry for every ~3 files).
Why not collapse all these font files into a few new font files using
fontforge or a variant of nototools's merge_fonts.py?
For example Noto Serif {Ahom, Bengali, Devanagari, Malayalam, Tamil,
Thai, …} could be merged into "Noto Serif Asia". Then, Noto * {Africa,
America, Asia, Europe, Oceania, Symbols} could be shipped in the
fonts-noto-aggregated package and their entries added to Debian's
fontconfig as default fallbacks. This would greatly alleviate the
problem of having too many entries in the font pickers, yet provide the
same coverage of fonts-noto-core.
Regards,
--
Gioele Barabucci
Re: /usr/-only image
On 10/09/23 22:42, Russ Allbery wrote: Luca Boccassi writes: It is being slowly worked towards, but we are still at the prerequisites at this time. Hopefully we'll have some usable experiments for the Trixie timeline, but nothing definite yet. Just to make this explicit, one of the prerequisites that has not yet happened is for Debian to agree that this is even something that we intend to do. An even bigger prerequisite is that many upstream projects does not yet support working without /etc or (orthogonally) reading their default configuration from /usr. In my personal experience I found that working directly with upstream projects on supporting stateless installs (no /etc, no /var) and factory-resets (the system keeps working after `rm -Rf /etc /var`) has a better return in investment compared to trying to integrate Debian- or distro-specific patches. Perhaps a more approachable goal for Debian towards statelessness is to reach the point where no packages ship files in /var. That is often a matter of passing the right parameters to `dh_auto_configure`. Regards, -- Gioele Barabucci
Re: proposal: dhcpcd-base as standard DHCP client starting with Trixie
On 11/07/23 23:06, Sam Hartman wrote: However, there are some significant disadvantages to netplan: 1) It's an extra layer. [...] 2) It's a layer that you cannot ignore when editing the config. [...] I'd also add 3) It requires Python and various Python libraries. At least the CLI tool does. In some circumstances installing Python and a bunch of libraries is not going to be a big issue (e.g., in desktop installs), but for many server installations that is an unnecessary new burden. (To be fair, Lukas opened his email stating that for minimal installations sd-netwokd is a more fitting alternative. I just wanted to explicitly mention one reason supporting that statement.) Regards, -- Gioele Barabucci
Re: Second take at DEP17 - consensus call on /usr-merge matters
On 08/07/23 09:44, Timo Röhling wrote: Alternatively, we could move all files except for the few critical ones (/bin/sh, dynamic loader) Allow me to add some hard data to this discussion. In essential (proper) there are 153 files that need to be moved, distributed across 15 packages (+ base-files). Packages and number of files to be moved: 1 libc-bin 1 login 1 sed 1 tar 2 bash 3 dash 3 debianutils 3 dpkg 3 grep 5 hostname 7 sysvinit-utils 14 gzip 28 coreutils 36 util-linux 45 ncurses-base Even the most convoluted and lock-stepped procedure can surely be carried out over a single day in an all-hands-on-deck effort. Especially if the files of non-critical packages are moved before the flag day. Regards, -- Gioele Barabucci
Re: FTBFS (reprotest) on all recent uploads
On 20/06/23 10:25, Peter B wrote: On 20/06/2023 05:31, Joachim Zobel wrote: I can see two logs of successful builds and a diff for them. Looks to me like the 2nd build is aborting. .. I: Building the package I: user script /srv/workspace/pbuilder/1086848/tmp/hooks/A99_set_merged_usr starting Re-configuring usrmerge... removed '/etc/unsupported-skip-usrmerge-conversion' dpkg-query: package 'usrmerge' is not installed and no information is available Use dpkg --info (= dpkg-deb --info) to examine archive files. /usr/sbin/dpkg-reconfigure: usrmerge is not installed [...] This is happening for a lot of packages, but reprotest seems fine on Salsa. It looks like this issue has been fixed yesterday: https://salsa.debian.org/qa/jenkins.debian.net/-/commit/9951365b854660b4c3ea770c11414f254c50151a -- Gioele Barabucci
Re: Adding epoch to kworkflow package to correct a wrong upstream version
On 12/03/23 19:13, Peter Wienemann wrote: On 12.03.23 18:48, IOhannes m zmölnig wrote: Could lintian warn when a date based version is used? Lintian already does this - see [0]. [0] https://salsa.debian.org/lintian/lintian/-/blob/f03fc15a45df4965e374b1e3a40c51cf6fe545ed/tags/n/new-package-uses-date-based-version-number.tag Given than epochs are kind of a big deal, maybe that warning could be raised to the level of error (or added to ftp-master's autoreject tags), so that a package will be accepted only if that tag is explicitly overridden. Regards, -- Gioele Barabucci
Re: An email address for drive-by bug reports?
On 01/03/23 16:22, Sam Hartman wrote: Socially and culturally I do want to emphasize the idea that if you aren't willing (any more) to put energy behind your problem report, it's entirely fine if no one is going to put energy behind fixing it. That seems to me like a perfectly fine social agreement. And not much different to what happens with orphaned packages (you don't maintain the package anymore, don't expect others to put in the effort to do it). Regards, -- Gioele Barabucci
An email address for drive-by bug reports?
Should there be a standard email address for "I'm reporting this because I noticed it, but I'm not interested in it"-bug reports? Orphaned packages get their maintainer address set to . Shouldn't something similar be available for bugs? For example I have opened bugs years ago against packages that I do not use anymore. These reports are still valid and sometime others comment on them, but I would no longer be able to, for example, respond to `moreinfo` requests. At the same time these bugs clutter the bugs.d.o page associated to my email address. It would be nice to have a separate email address to which these bugs could be reassigned (maybe after a minimum amount of time?). It could be as simple as a the address of a dedicated mailing list. Regards, -- Gioele Barabucci
Bug#1030668: dinstall could run more often (every hour?)
Package: ftp.debian.org Severity: wishlist X-Debbugs-CC: debian-devel@lists.debian.org Dear FTP masters, could dinstall be run more frequently, for example every hour? Currently dinstall is run only once every 6 hours. This means that many operations are blocked for a long time. For instance uploading a -2 version after a package has cleared the NEW queue. Such long delays tend to ruin the development flow, especially of volunteers that happen to have just a couple of hours at their disposal. This is a well known source of frustration [1]. [1] https://michael.stapelberg.ch/posts/2019-03-10-debian-winding-down/#old-infrastructure-package-uploads Given that a dinstall run generally takes only few minutes, it should be feasible to run dinstall at least hourly. Regards, -- Gioele Barabucci
Bug#1029723: ITP: bats-file -- Helper library providing filesystem-related assertions for Bats
Package: wnpp Severity: wishlist Owner: Gioele Barabucci X-Debbugs-Cc: debian-devel@lists.debian.org * Package name: bats-file Version : 0.3.0 * URL : https://github.com/bats-core/bats-file * License : CC0 Programming Lang: Bash Description : Helper library providing filesystem-related assertions for Bats bats-file provides various assertions and helpers to simplify writing Bats tests that deal with files and filesystems. For example: * assert_file_contains: Check if the file content matches a regex. * assert_file_owner: Check if a specific user owns the file. * assert_symlink_to: Check if the file is a symlink to the target. * temp_make: Create a temp directory for the current test in BATS_TMPDIR. -- Gioele Barabucci
Re: propose: provide "docker" package as docker, not wmdocker
On 05/12/22 18:19, Andreas Metzler wrote: how do you avoid that people who still have got the transitional docker (--> wmdocker) package installed end up being upgraded to real docker (from docker.io)? How was the transition from git-the-file-viewer to git-the-VCS handled in lenny/squeeze? Regards, -- Gioele Barabucci
Bug#1021609: ITP: bats-assert -- Helper library providing common assertions for Bats
Package: wnpp Severity: wishlist Owner: Gioele Barabucci X-Debbugs-Cc: debian-devel@lists.debian.org, gio...@svario.it * Package name: bats-assert Version : 2.0.0 * URL : https://github.com/bats-core/bats-assert * License : CC0 Programming Lang: Bash Description : Helper library providing common assertions for Bats bats-assert provides various ready-made assertions that can be used to make Bats tests simpler to understand and to debug. For example: * assert_success: exit status is 0. * assert_output: output contains given content. * assert_line: a specific line of output contains given content. -- Gioele Barabucci
Bug#1021048: ITP: bats-support -- Supporting library to test bats helper libraries
Package: wnpp Severity: wishlist Owner: Gioele Barabucci X-Debbugs-Cc: debian-devel@lists.debian.org * Package name: bats-support Version : 0.3.0 * URL : https://github.com/bats-core/bats-support * License : CC0-1.0 Programming Lang: bash Description : Supporting library to test bats helper libraries bats-support is a supporting library providing common functions to test helper libraries written for Bats. Features: * error reporting * output formatting * language tools -- Gioele Barabucci
Re: Automatic trimming of changelogs in binary packages
On 06/09/22 11:42, Andrey Rahmatullin wrote: On Tue, Sep 06, 2022 at 12:11:38PM +0300, Hakan Bayındır wrote: Stuffing them behind a command, possibly making them online only in the process will arguably make system troubleshooting and administration harder, esp. if the system has connectivity issues. If something critical breaks, I can boot to recovery and look at the logs and changelogs of recently updated packages. Having recent-ish changelogs on the disk arguably accelerates the fixing process. I don't think removing recent-ish changelogs from the disk is proposed here. Andrey is correct: what is being proposed is just trimming the installed changelogs, not removing them completely. And the full logs will remain in the source packages. Regards, -- Gioele Barabucci
Re: Automatic trimming of changelogs in binary packages
On 06/09/22 10:25, Paul Wise wrote: On Tue, 2022-09-06 at 07:13 +0200, Gioele Barabucci wrote: * Packages not meant to be included in Debian (and without access to a changelog server): Creators that want to preserve the full history can use the `--no-trim` option to disable the trimming. Most derivatives aren't going to have a changelog server so I don't think it makes sense to enable it by default on all derivatives. Perhaps the dpkg vendor could be used as guidance for when the trimming should occur by default? Unless Debian/Ubuntu, disable by default. I have searched the debhelper's source code and its documentation for how it handles derivative distros, and it seems to me that 1) derivative distros are not handled at all, 2) the implicit policy is that vendors will modify the default parameters to suit their needs. In addition (or in alternative) to what Niels suggested in the other reply, derivatives could add to their patchsets a 1-line patch to make `--no-trim` the default. That would be in line with the kind of modifications that derivs to fit Debian to their needs, wouldn't it? Regards, -- Gioele Barabucci
Re: Automatic trimming of changelogs in binary packages
On 18/08/22 21:18, Gioele Barabucci wrote: Does anybody have objective objections against activating automatic changelog trimming in binary packages? Hi, a couple of weeks since the initial email (thanks everybody for the input), my reading is that there is now consensus in going ahead with the proposed automatic trimming of changelogs. ## Addressed contrary objections In particular, I understand that all contrary objections that were raised have been satisfyingly addressed: * Packages not meant to be included in Debian (and without access to a changelog server): Creators that want to preserve the full history can use the `--no-trim` option to disable the trimming. * Third-party repositories: Their administrators can provide access to the full changelogs by setting `Changelogs:` in the `Release` file, or can use `--no-trim` in the packages that they distribute. * Users should be made aware that changelogs have been trimmed: `dh_installchangelogs` has been modified to add a comment at the end of the trimmed changelogs. * Source packages should retain full changelogs: This is, in fact, already the case: only the changelogs included in the binary packages are trimmed. * Reproducible output: Once trimming will be enabled in `dh_installchangelogs`, either the changelogs will be trimmed (default) or not (due to the explicit use of `--no-trim`). This ensures the reproducibility of packages. ## Non-blocking concerns to be addressed in the future In addition, there were concerns and ideas that were raised as non blocking and that will be discussed and addressed in the future: * Perhaps have dpkg treat changelogs as metadata: There are pros (deduplication) and cons (the need to have a new command like `dpkg --show-changelog`). * d-security has no online changelogs: Fixing this has been proposed in 2008 (https://bugs.debian.org/490848) but it did not seem to sparkle enough interest at the time (and users of d-security are unlikely to be interested in changelog entries older than old-old-stable). * apt changelog could be instructed to choose between the local and the remote changelogs, perhaps via options like `Changelogs::PreferOnline` (to complement `AlwaysOnline`) and `--full`. * Maybe the URLs used by the tracker to link to the changelogs and the URLs used by apt to fetch the changelogs could be aligned. Regards, -- Gioele Barabucci
Re: Automatic trimming of changelogs in binary packages
On 19/08/22 11:31, Michael Biebl wrote:
I guess this could be solved by dpkg creating symlinks from the "master
copy" which is per-source to /usr/share/doc/$binpkg/
Maybe the "master copy" could be in `/usr/share/doc/src:$pkg/`?
/usr/share/doc/openssh-{client,server}/X → /usr/share/doc/src:openssh/X
Regards,
--
Gioele Barabucci
Re: Automatic trimming of changelogs in binary packages
On 19/08/22 10:35, Philip Hands wrote: How about making the end of the trimmed file be a standard footer including a hint about how one can get hold of the rest of the changelog, and then have `apt changelog` look out for that footer in the local copies in order to know that they've been trimmed, and that it should therefore try to download the full version. This two-line footer is added to the trimmed changelogs: # Older entries have been removed from this changelog. # To read the complete changelog use `apt changelog foobar`. Regards, -- Gioele Barabucci
Re: Automatic trimming of changelogs in binary packages
On Fri, 19 Aug 2022 00:46:21 +0200, Guillem Jover wrote:
My objections from that time still stand:
<https://lists.debian.org/debian-devel/2020/03/msg00482.html>
I would also like to highlight David Kalnischkies reply:
<https://lists.debian.org/debian-devel/2020/03/msg00309.html>
Dear Guillem,
I believe all factual objections raised in those two email are well
handled by the proposed `dh_installchangelogs` MR.
Here are the factual objections in those emails, reordered and
reformatted for sake of readability:
Doing that trimming globally would also mean that this applies even
to packages that are for local or derived use where something like
«apt changelog» will in most cases not work.
Maintainers of packages _meant_ to be installed locally (i.e.,
distributed outside repos) can use `--no-trim`.
Packages distributed by Debian derivatives can (and should) set the
`Changelogs` field in their Release files [1], or provide an appropriate
`Acquire::Changelogs::URI::Origin::DISTRO` apt.conf.d snippet.
Assuming the repository supports it. I have yet to encounter a
third-party which does, so if Debian would trim e.g. in debhelper by
default some care might need to be applied so that this happens only
to packages which end up in Debians repositories… which could
complicate reproducibility as its clear for a buildd, but my local
sbuild…
Similar to the point above, if the third-party developers are
1) willingly distributing their packages via a repository that does not
set `Changelogs:` and
2) also really want to make the full changelogs available,
then they can pass `--no-trim` to `dh_installchangelogs`.
The explicit use of `--no-trim` will make the packages reproducible.
The benefit of treating all packages the same is that tools working
with changelogs can handle the grunt work: "apt{,-get} changelog pkg"
prefers the changelog on disk if available – except for repositories
which identify as "Ubuntu" for which it will always download the
online changelog for display.
(I read this as a comment _in favor_ of automatic trimming, but maybe
I'm just reading it through rose-tinted glasses.)
Once automatic changelog trimming is the default, then fixing `apt
changelog` is a matter of setting
`Acquire::Changelogs::AlwaysOnline::Origin::Debian` to true in apt.conf.d/
A proposal I've been floating around from time to time has been to
instead make the changelog and copyright files deb/dpkg metadata
(which they really are anyway IMO).
That is indeed a good idea. And, by implementing it in addition to
`dh_installchangelogs` auto-trimming, it will even further reduce the
amount of wasted space and bandwidth.
Regards,
[1]
https://salsa.debian.org/apt-team/apt/-/blob/main/doc/apt.conf.5.xml#L628
--
Gioele Barabucci
Automatic trimming of changelogs in binary packages
Hello, in 2020 there was a brief discussion on debian-devel@ about trimming changelogs [1,2]. Now there is a working implementation of said functionality in `dh_installchangelogs` [3]. This implementation, combined with the evolution of the apt/dpkg ecosystem that happened in the meantime, provides now all the benefits of changelog trimming (less wasted space and bandwidth worldwide, reduced processing time) without the downsides discussed at the time. ## In detail * `dh_installchangelogs` is modified install in binary packages the trimmed changelogs, i.e. changelogs that contain only entries more recent than the release date of oldstable. * The trimming is done automatically in compat >= 14. * The `--no-trim` option allows package maintainers that want to ship the whole changelog a way to do so. * The full changelogs are preserved in the source packages and thus available via `apt changelog` and similar mechanisms. * The trimming process happens at build time and requires no modification to the changelogs stored in the VCS repos, nor changes to the packaging. ## Data on file size reduction On a sample of ~13.000 packages, the median reduction in size of gzip-9'ed changelogs is 56% (mean 50%). Ancient packages or heavily developed packages gain a lot from trimming the changelogs. Some examples (gzipped → trimmed+gzipped): * debian-keyring: 664k → 47k (-92%) * dpkg (essential): 223k → 22k (-90%) * apt (essential): 156k → 14k (-90%) * systemd: 110k → 23k (-78%) * gcc-12: 189k → 18k (-90%) * python3.9: 48k → 4k (-90%) * e2fsprogs: 68k → 7k (-89%) ## Consensus Does anybody have objective objections against activating automatic changelog trimming in binary packages? Regards, [1] https://lists.debian.org/debian-devel/2020/03/msg00299.html [2] https://bugs.debian.org/954313 [3] https://salsa.debian.org/debian/debhelper/-/merge_requests/80 -- Gioele Barabucci
Userscript to manage reports directly from bugs.debian.org
Hello, I made a Greasemonkey userscript to manage bug reports from bugs.debian.org. It allows manipulating the tags list, the severity, the forwarded to address, and so on. It generates clickable mailto: links with all the needed commands for control@bdo. It is available at https://anonscm.debian.org/cgit/users/gioele-guest/bst-userscripts.git/ (direct link <https://anonscm.debian.org/cgit/users/gioele-guest/bts-userscripts.git/plain/manage-debian-bugs-via-web.user.js>) Once the script is installed you can change the existing fields like "severity" and "tags" (they are now editable text fields) and add fields that are not there yet (click on "Additional fields..."). When changes are detected, a list of pending changes will appear. You can submit these changes in various ways: clicking on "submit via control" will generate an email ready to be sent to `cont...@bugs.debian.org`; clicking on "via bts" will show the command line to use to send these commands via the `bts` command line utility; using the "reply" and "close" that will add the necessary "Control" lines to those email. The script is good enough for my needs. It is definitely not finished nor ready to be used by the public at large. The script has been tested only with Firefox 42. Bug reports and patches are welcome. Background. Some weeks ago I came across the bug page for dash and it looked like it could use some triaging. I then discovered how unpleasant it is to manage those bug reports, especially if you did not receive the bug original bug report. I have composed and sent many emails to ###@, ###-done@ and control@, but I thought it would had been much more productive to have a script collect all the needed pieces of information for me and put them in a ready-to-send email. This is that script. I hope this may be useful to other people as well. Cheers, -- Gioele Barabucci <gio...@svario.it>
Accepted fonts-radisnoir 0.9b-3 (source all) into unstable, unstable
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Format: 1.8 Date: Sun, 22 Nov 2015 01:41:13 + Source: fonts-radisnoir Binary: fonts-radisnoir ttf-radisnoir Architecture: source all Version: 0.9b-3 Distribution: unstable Urgency: medium Maintainer: Debian Fonts Task Force <pkg-fonts-de...@lists.alioth.debian.org> Changed-By: Gioele Barabucci <gio...@svario.it> Description: fonts-radisnoir - font inspired by Bayer Universal and Bauhaus ttf-radisnoir - transitional dummy package for fonts-radisnoir Closes: 659725 661459 Changes: fonts-radisnoir (0.9b-3) unstable; urgency=medium . * Prepare for new Debian release * Convert to git-buildpackage * Drop dependency on fontforge * Drop maintscripts, used only for defoma (Closes: #659725) * Update compat to version 9 * Add Multi-Arch field to control * Remove dirs file: it is no longer needed * Install OTF files in /usr/share/fonts/opentype * Make debian/copyright machine-readable * Bump Standards-Version to 3.9.6 (no changes needed) * Remove debian/watch: the source site is gone * Adopt package (Closes: #661459) * Fix description to reference the correct typeface * Rename package to fonts-radisnoir * Add Vcs-* fields * Install only the OpenType version Checksums-Sha1: c587141439af7964b583d2c6985332dd5e506db2 2013 fonts-radisnoir_0.9b-3.dsc 65232e6347fe1bf188e8916b24e29912dc008e75 30537 fonts-radisnoir_0.9b.orig.tar.gz 4acb46c8a454f14310bfaf7a4f30bb1fc360063c 4120 fonts-radisnoir_0.9b-3.debian.tar.xz cc86360bdc9932f09c6a37a08659fcb2d78a2d36 14384 fonts-radisnoir_0.9b-3_all.deb 8668ec5a7a8a192e38c0be9ae5fa82faa223a2ab 4552 ttf-radisnoir_0.9b-3_all.deb Checksums-Sha256: 74172fe8d6c50226a2c41a92c0d0bb7c21dd6af426e09ac6dfbc368b2916a7fc 2013 fonts-radisnoir_0.9b-3.dsc b03f1e51f1bd306190955f7796d55c11e3b69b7a08c477218803828bd6003d93 30537 fonts-radisnoir_0.9b.orig.tar.gz 3d0a7ba882e4c0a2d588e8295c41463f70cb43ef85df7d14272981fd48cf71ca 4120 fonts-radisnoir_0.9b-3.debian.tar.xz b20c5c5b494ac1d8d0c0c2aae30fd35bd7bce7db070cd2a5ffd031626c86e95b 14384 fonts-radisnoir_0.9b-3_all.deb b12dbea1baa3b94900d93e81c1ac1d2cca21c146f2cfb3cef141b71d19d0cdcd 4552 ttf-radisnoir_0.9b-3_all.deb Files: 0d3cae75ef0d932095f3bfd75365b7fa 2013 fonts optional fonts-radisnoir_0.9b-3.dsc a450d4001b8450565acebd55aa6e0752 30537 fonts optional fonts-radisnoir_0.9b.orig.tar.gz 8d673320a81db17be5132bd49c99fd37 4120 fonts optional fonts-radisnoir_0.9b-3.debian.tar.xz 9e0c40341606d51b56a40ce67517aeca 14384 fonts optional fonts-radisnoir_0.9b-3_all.deb ea34a1542976cc3e67ac0d569e19d59c 4552 oldlibs extra ttf-radisnoir_0.9b-3_all.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1 iQIcBAEBCAAGBQJWUbitAAoJEMvqjpcMzVnf1FwP/26k6sdlCIPgE2ytnOTuhf6z zU2Mlw5YaYrsLfW+kDh2Zl259F37sTz05AEh5DNcGww7HZnOeN5ekhsg8jly9BBZ VZpAXsWCl9eld5xzKYFF+k7nXQIZWSLWxVHazTu/4F2hCc6PDRR7+t+Sj0bcD5Xb +vGt6PzkxX/+PDqIkmv1atYJwCzQmSl7wVULdmXxCGemMS1Dc9hvCe0rI1r5u1ix Hph66aUUVXVXvZNGACFK2hzoeMlqZ4u8rZhgG2Pz1H6cAcAia/lh16NFg/GdgKF2 MOOuP9ugri6cvDju9y4ws4ehG5/blrPoD6nuAcDaYO+c+vuftGc1ve+yBYDYp0Jd bLfxaFJEbY+XMsYOCqabCkOPCCyxUvPetqL68EOaXFgh+R5ZUK1NAnZSqhNdtfbF MPRuHgSwAii0zBOb0cfti2Kheq6fx5I+qLGRG98G06Cnb6suUW2wgXHaiFbfwWTH 81oEO5jkh9kxd/8NCjiAj/6WUq3cJbN4fh94twmahIOqSFMktePjf46jvrWXZhdt tO/x/yLBwpprhwxSTA1EpjJj71yIpjRVkwJd881lcHYm5n8ngKOeBDPw3dZKFscT PBuQNycEBBZA4JOppHdLy6aYzDlBddUEZ1IghfdXaIc7C6OB7nMPNIF6mdQoLTNE kdxtiIKFOl+uDi7GI3dQ =fDks -END PGP SIGNATURE-
Accepted fonts-femkeklaver 1.0-2 (source all) into unstable, unstable
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Format: 1.8 Date: Tue, 17 Nov 2015 23:22:18 + Source: fonts-femkeklaver Binary: fonts-femkeklaver ttf-femkeklaver Architecture: source all Version: 1.0-2 Distribution: unstable Urgency: medium Maintainer: Debian Fonts Task Force <pkg-fonts-de...@lists.alioth.debian.org> Changed-By: Gioele Barabucci <gio...@svario.it> Description: fonts-femkeklaver - simple handwriting font ttf-femkeklaver - transitional dummy package for fonts-femkeklaver Closes: 804917 Changes: fonts-femkeklaver (1.0-2) unstable; urgency=medium . * Prepare for new Debian version * Update debian/copyright to follow copyright-format/1.0 * Format the CC-BY-SA-3 licence * Remove package name from install file * Ignore generated files in debian/ * Update compat to version 9 * Update font homepage * Add Multi-Arch field to control * Bump Standards-Version to 3.9.6 (no changes needed) * Drop fontconfig from Recommends * Use standard font path * Adopt package (Closes: #804917) * Update copyright information * Add GPL short text * Add Vcs-* fields * Move details about the relicensing in the copyright file * Extend description of the font style * Rename package to fonts-femkeklaver Checksums-Sha1: 6a537e34c013133c75867162363f4308854bcad0 2057 fonts-femkeklaver_1.0-2.dsc 98b79efc3fd11d31b7068f35c0540078079a0c6d 60003 fonts-femkeklaver_1.0.orig.tar.bz2 74060c5c390835b2a9ee58813b1d1c83e1ab4c2f 10228 fonts-femkeklaver_1.0-2.debian.tar.xz 0997c9ec11e021b0ff16688010454e4f489f56fb 61644 fonts-femkeklaver_1.0-2_all.deb eeb1416d36cfb01181c465a79f0e9fd6b7da8709 10632 ttf-femkeklaver_1.0-2_all.deb Checksums-Sha256: 04cc1a8efb6c0d376745aaea39963b63d978d9e51b6b5d0b22917d4123f8a420 2057 fonts-femkeklaver_1.0-2.dsc 866d5e3101108bca259e1baaf070a8216440f6dab26e7e1a38b81de6d9d6dc77 60003 fonts-femkeklaver_1.0.orig.tar.bz2 0e75b5edce1060606630c636775146c4d26d0c34b42bcbb6c5dc5b529c6da0f4 10228 fonts-femkeklaver_1.0-2.debian.tar.xz a7606a03c1eebf00c2d68fdd1e77b0956a23fe717cb9b032e56e97c189bcc36e 61644 fonts-femkeklaver_1.0-2_all.deb f23e6fe07cdb6082981662e5e62f13c481a8c8c8d24c31ed3eb5e0ef8bc09910 10632 ttf-femkeklaver_1.0-2_all.deb Files: 5d9ddf8dcd71fa31f7a956979b4b608f 2057 x11 optional fonts-femkeklaver_1.0-2.dsc e710544d7fc4652d1a8f73ac5e606242 60003 x11 optional fonts-femkeklaver_1.0.orig.tar.bz2 0e6bf32dcb8f8bb4741a9da34727db6d 10228 x11 optional fonts-femkeklaver_1.0-2.debian.tar.xz d9f2579600b14b1057991c6f721a136f 61644 x11 optional fonts-femkeklaver_1.0-2_all.deb 60679058a5867810a45ea8ae8d4a2cd9 10632 oldlibs extra ttf-femkeklaver_1.0-2_all.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1 iQIcBAEBCAAGBQJWTDj6AAoJEMvqjpcMzVnfT1QP/RxcG6cW44wvefHdvikRbey+ th+aefqWEhO263jihWPZCHMTeBCscaYoarTVzQDp/LN5sjk7JXkt7SyS3fYUUth5 j32F5YSLZ0a8N4XzHLBP1Baji5cp6lN9jXuCy1nVbeuUHnV7Rv/tTn4syptbMOUy WR5cmLUxcsaBtIQW+gb/f4QTkGq3KgcbidDuN3QhEpdypeQkJ0k2rSqd3vE91f1D eXgZSdhTjMCJvxS7S/7fGi4qZO2Mk9UKveturiEo1acMJx51TBSBcqT8YnChsuTf lw4vy+Bb6z0iVRnOqlLcXQX6BI7eHLoejoosmWGC2bgF/sUEq4kv9ca6518WpqGC bqqQWIgAvEP/R2Jp06TQfWeK3N2/sjNOS5iOCYL/hW7GI7aYiHKCrIfqpajsAKPV JbtecR3UweUfw330t84Jv7Q6jaH3tsfOTp1zdoKMWfUnwf91P7KRd1BXLHTG3eY0 BJ7GJNj2zeZB62jKCJcdqasjc9BUXjkuhmiQ0DNyZieZOKgVXMeA1dLT7yOUCPFT 7GUIu+CsLQGJGf+k6VN8Sk+tSil3aOX8xGC1P1NlhV2r16r0QGNvtchrPEzHy+Ft W+WiSSq+ooIzNsk5dtt5i4i+XfXg0CiAnFE8Natdhg+RainpfM2FnOS25MMA+FiC q9a1vCTzNvvV++wSK246 =qkS1 -END PGP SIGNATURE-
Accepted fonts-kristi 20100000-2 (source all) into unstable, unstable
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Format: 1.8 Date: Tue, 20 Oct 2015 22:17:04 + Source: fonts-kristi Binary: fonts-kristi Architecture: source all Version: 2010-2 Distribution: unstable Urgency: medium Maintainer: Debian Fonts Task Force <pkg-fonts-de...@lists.alioth.debian.org> Changed-By: Gioele Barabucci <gio...@svario.it> Description: fonts-kristi - casual cursive script typeface with a "felt-tip pen" feel Changes: fonts-kristi (2010-2) unstable; urgency=medium . * Improve summary and description Checksums-Sha1: 9b676986f14fb7ffe3deb298408618bbcf603a4f 1970 fonts-kristi_2010-2.dsc 839a7c1da52a430dac701ee1bff328075f14abf1 35107 fonts-kristi_2010.orig.tar.gz 5a150aa4c3db8bdcdcc928e5c52afaa6c6541dce 5360 fonts-kristi_2010-2.debian.tar.xz 1032be7b3e21cd4d4880efc052b6cf067577cd3e 35532 fonts-kristi_2010-2_all.deb Checksums-Sha256: abefbd56cfeab938000ab72e0044958eddf4af6504fec9206dc9005a7a0cdd00 1970 fonts-kristi_2010-2.dsc 5f3ace7b270e1b8434024d4d27e3c452d1b7e3e746d2de52fece745a96d62783 35107 fonts-kristi_2010.orig.tar.gz 8258b6e5cdb7b22759f66d1d53f5dbe803e3c69291062aca5e06918e6ff6e034 5360 fonts-kristi_2010-2.debian.tar.xz 5e83d77b76fe24a5c13f928f436a30dfbe231bb2aab2e615405a2133a1c2e4d8 35532 fonts-kristi_2010-2_all.deb Files: 34f8c8f0e30c4cbbb7bb5b96303531c3 1970 fonts optional fonts-kristi_2010-2.dsc 8ed95f43cc7d052778e3d5a199ee10a9 35107 fonts optional fonts-kristi_2010.orig.tar.gz cc0f292254987802e532413b5da7df90 5360 fonts optional fonts-kristi_2010-2.debian.tar.xz 1d48f21cd4fadcbbc81a6b367757723b 35532 fonts optional fonts-kristi_2010-2_all.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1 iQIcBAEBCAAGBQJWMfNjAAoJEMvqjpcMzVnfZg8QANizl0p4UFqVHwCYzeKoPZD6 VjYy29BDpxcUHPDZ3dgXzx8jK1Kw634Lq6DoJVfFBfEeABftafV13s8Al+eX2EaU DS2mC0fWnsDCALmLPLjjal1OSa735OQH0PRgEr0CJUqJ0xkyajtmmjy9r38qP8+a oJzUKf6hVkxst5LsDxJFL70Dm8A6HyRyLgYu5wWDr5Kf6UQ8kacWVsXL+kJTLi/N yE7UQ45LmuSTv+MElXTabeNwjHjI3vlF6Aj3kVJMWvrTEfFuaIryq9iAaWsTo9BH 5LPj8kjlbEyQDuiroLz6qRYeSOBKtbIxuyuGj5dpXdKVrNalSEie3/gguAodWEw+ kikiZrD/KoZSIyUGBmxczv8Kj+xbT/pmMMOTknabillN8RJ9kM5baJMUijosfTU5 OWQBqjGE/EQP2zfWSIgLU+Frge1RZKAxSOHeZD0F+EK2eAoyuYI9LoMO9YU2MJVb EcSbatBPOcQpQeOUs6XF88dIeFnxD79M1TMun7CgRUbNaQMxye5kArKz/+5HlGxi VehZr8fhm/WCPBv5lzSecfOgJ9LfFn2Jhr0kLG/zNAmnopiPsWzf/jGTW0qrSZ0V iTsChE6PVRzA+tbrjEDdVHTOMFJYwpTVW+DyXvRYWeKZT1rNrQmD9bSX6idS41Wt LKtFVzClZ8PxY6nAAQ1s =rsHY -END PGP SIGNATURE-
Bug#803690: ITP: fonts-pompiere -- a playful script font
Package: wnpp Severity: wishlist Owner: Gioele Barabucci <gio...@svario.it> * Package name: fonts-pompiere Version : 20110715 Upstream Author : Karolina Lach for Sorkin Type * URL : https://www.google.com/fonts/specimen/Pompiere * License : OFL-1.1 Programming Lang: TTF Description : a playful script font Pompiere is a low contrast condensed sans serif TrueType font designed by Karolina Lach. However unlike most sans it has very tall ascenders and very small x-height. Pompiere is playful and even a little sweet. This font was inspired by a handmade sign seen outside of NYC firefighters Squad Co. 18 in the West Village of Manhattan. Because of its small x-height and modest weight it will work best at medium to large sizes.
Bug#800815: ITP: fonts-kristi -- Kristi font
Package: wnpp Severity: wishlist Owner: Gioele Barabucci <gio...@svario.it> * Package name: fonts-kristi Version : 2010 Upstream Author : Birgit Pulk * URL : https://www.google.com/fonts/specimen/Kristi * License : OFL-1.1 Description : Kristi font Kristi is a free TrueType font designed by Birgit Pulk. It is a calligraphy font inspired by old chancery typefaces. The font simulates writing with a felt-tip pen.
Accepted fonts-leckerli-one 20110000-1 (source all) into unstable, unstable
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Format: 1.8 Date: Tue, 08 Sep 2015 20:56:49 + Source: fonts-leckerli-one Binary: fonts-leckerli-one Architecture: source all Version: 2011-1 Distribution: unstable Urgency: medium Maintainer: Debian Fonts Task Force <pkg-fonts-de...@lists.alioth.debian.org> Changed-By: Gioele Barabucci <gio...@svario.it> Description: fonts-leckerli-one - Leckerli One font Closes: 798202 Changes: fonts-leckerli-one (2011-1) unstable; urgency=medium . * Initial release. (Closes: #798202) Checksums-Sha1: 0a0f007cdaf4106876d6a2ea57a0e31f24e1c98f 1896 fonts-leckerli-one_2011-1.dsc 1e30ea465bc9fdf27f92d85e4bb4b4aab9f11fa4 26482 fonts-leckerli-one_2011.orig.tar.gz 7f046013e4ff85f5111d7cec8110e088e4254164 5288 fonts-leckerli-one_2011-1.debian.tar.xz 26083cd5a4160b5d9db8acf46f809bceea289d93 26650 fonts-leckerli-one_2011-1_all.deb Checksums-Sha256: 54f2811cf3250d36d8055476c386e1d6413240422975a54be8197aad7c048b95 1896 fonts-leckerli-one_2011-1.dsc ee16bbcedd7f04c427815d7ae5af8ef9369525bb8e5e8864f40bc45b722a6038 26482 fonts-leckerli-one_2011.orig.tar.gz 4949686e9bf1bbb118bfb107d2c1d53c383bae64f6c50cb5ab5ac3a4945c401d 5288 fonts-leckerli-one_2011-1.debian.tar.xz f97fb88259725f188095fe6e976612e63d7329b9a8daa6caa10e1fb1acb33fb9 26650 fonts-leckerli-one_2011-1_all.deb Files: 2c419119160ca8d7f119217dc7d181f7 1896 fonts optional fonts-leckerli-one_2011-1.dsc 741d6076a72c53a85e0409c664ebc3ee 26482 fonts optional fonts-leckerli-one_2011.orig.tar.gz 3298e05a1f343cbf09315a281d57977f 5288 fonts optional fonts-leckerli-one_2011-1.debian.tar.xz 6c2b56ae173c2c8444d8900a25b73b26 26650 fonts optional fonts-leckerli-one_2011-1_all.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1 iQIcBAEBCAAGBQJV79mvAAoJEMvqjpcMzVnficYQANWK9yDkWSMpAXjf6PBY4FJG uUz6dfQl+JDUzjiYBsRfCZtVwxoGh+eRC0pk2cYwFNDeczC56Ucfq7y91vszfyVy UBMddXdJb1YRbkKYIf3YqnvkfQY1cme0wb6n5zotzHOL+zlODHkygG5pFvJTMXmK UPTtKLupw7XP/6Fhgk3NckK2KIYT73T4M9IR11owhto/JPjY3U3adJvB4AKRJUyl 8m6Fkzj7NNoyjzQlDAST2er3wMPLoj0EehycPNpMFxWM2X5YUwkWZrUjVArq7rNi axg6tHJKs8uXLEiPH/Q0xhC214gG09cR8BgoLEkPO8ju8DKd3WIRak9MNG6zCfHP 3AQtEtpJ6gU3mkbubb77yulQXLkHVVkRNpPYAZINx81GHtrQ2A+G2l4TXVFbRpn1 EocixxYhdp/dA2RuHxgTLZTa3bc5t3D6RggST0ZurtQwOYlEvKfWyrR0LlliM2Dl xuGfvl0d2aLhxV0dPhTmKuMeGKfvL2xTeGhRhixhRqhztE14gI1et2HZ87vVTNHa RpVihms6ecqT71EUIwGbbg+T9XYVuzL7JnaBbZWISTJUK+OaGA1ceObKyBNL3abj bOBVA1UkcDWEIwfu0o1vsDogiWE3/xiM+DaObTDRM8LGPf5bpQYfjM6iOx7ULPra nceuSC4g8wikWatIYThG =O5Zp -END PGP SIGNATURE-
Bug#798202: ITP: fonts-leckerli-one -- Leckerli One font
Package: wnpp Severity: wishlist Owner: Gioele Barabucci <gio...@svario.it> * Package name: fonts-leckerli-one Version : 2011 Upstream Author : Gesine Todt * URL : http://www.example.org://www.google.com/fonts/specimen/Leckerli+One * License : OFL-1.1 Description : Leckerli One font Leckerli One is a free Open Type font designed by Gesine Todt. It is a fat display typeface with irregular brush shapes and a handwritten feeling.
Accepted ruby-filepath 0.6-1 (source all)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Format: 1.8 Date: Sun, 15 Sep 2013 14:59:44 + Source: ruby-filepath Binary: ruby-filepath Architecture: source all Version: 0.6-1 Distribution: unstable Urgency: low Maintainer: Debian Ruby Extras Maintainers pkg-ruby-extras-maintain...@lists.alioth.debian.org Changed-By: Gioele Barabucci gio...@svario.it Description: ruby-filepath - small library to manipulate paths Closes: 723905 Changes: ruby-filepath (0.6-1) unstable; urgency=low . * Initial release (Closes: #723905) Checksums-Sha1: 0c239e7dcaf169e4af796ecf7ceb6494167cd487 2054 ruby-filepath_0.6-1.dsc a4ad7c31d028a91b4616804f5c63dc4ddac787c8 19073 ruby-filepath_0.6.orig.tar.gz 69da814a6118f837a043354c4f2617c1a7a37227 5303 ruby-filepath_0.6-1.debian.tar.gz 7952e2bd5fae5524b2645baec2cb017994cd5de7 12330 ruby-filepath_0.6-1_all.deb Checksums-Sha256: 6a246e9a32119e6b25eac260effb30a3c44a16e06fb599d9f4883c92aff63bf4 2054 ruby-filepath_0.6-1.dsc 9160d8f745fa401c951365f4692a5ab3483cd96703f85143f0894b9cc80d5dba 19073 ruby-filepath_0.6.orig.tar.gz b330a9c2af53c3ffa2f19d019698dfff7abda89b426830b898adaa132d68ae5a 5303 ruby-filepath_0.6-1.debian.tar.gz 1f4c07920c2d6696459c9fff9e9fcb64634c386cc4c2e82077986aa99efce5fe 12330 ruby-filepath_0.6-1_all.deb Files: 92a0b2b28aac14c852f01d9c7ac23b2b 2054 ruby optional ruby-filepath_0.6-1.dsc 5edfd1c1e29c7e3b10a9fcb5f7b5c594 19073 ruby optional ruby-filepath_0.6.orig.tar.gz 8a39d8b7d9b9fce35a72d45c8b4f137f 5303 ruby optional ruby-filepath_0.6-1.debian.tar.gz 315e8fb7f160f7c407e95420a702da2a 12330 ruby optional ruby-filepath_0.6-1_all.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.14 (GNU/Linux) iQIcBAEBCAAGBQJSTTKTAAoJEKkHZFuPn48J4uQP+QFuCpNxW4RzY7+UyWXRghGg 4QRDIwkyJ5xdY1NcTojWQwRToyqqxsWl8TFawt2hLf3QGe9PXblRDhngrpX4pfFo G5blCSjath8xhJ8st4K0RXcQzVaHcd0G9u2DzrcEUnTq0SroIVI0kofsz5Yvpma7 hojXd/UXe45E5k7/zBAifOCdVtNmHsUAf+Cs7MfeVKgYim4jYTM1UXUJ4XCdknhR 298iR9ahHRW657SN9PEkN9O45J4LF9HwIQe8Y00CfpFwGz+kNZuvzaWtlEKYYeCB YKSOELiVGci+xsQ5kiagjF6NDIpp15P6CnvSDdBb7D9He3aCgZXxYOF7CpWTbC0v bVtn4xjbZoMz8ZMtFnGb3Y+074uJ3lG/0ApKWFL9HGfR97YUMy7jz0u0+yADu6og rb8ErpR73+EsWt2Eu7QbhjwiH5cz0WUmWuCqtnhAN0YKgzy7tibdDXgYVFhB0vrx zpXY3mryOKo+JmF+Wkj81eOjPNK48ByViBq8FH2hf6YHGeVYQ7g/HtrJpucYBqx3 XRaq4JlGkw9Ia/15Be+LhzlgvLHrfh4R4K+LZ5z5+Pj+7cWd/O8yC/Xf6bXDex5V nQjIHsDEb896eGm9ycmuZjVcKduOniSMfmnsEfxfSQtXZv2IN/maouzRKHZP7iNf TUy+tIkMYVwaVR7o/IhR =dyIu -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to debian-devel-changes-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/e1vajoc-00023g...@franck.debian.org
Bug#725318: ITP: ruby-launchy -- helper class for launching cross-platform applications in a fire and forget manner
Package: wnpp Severity: wishlist Owner: Gioele Barabucci gio...@svario.it * Package name: ruby-launchy Version : 2.3.0 Upstream Author : Jeremy Hinegardner * URL : http://rubygems.org/gems/launchy * License : ISC Programming Lang: Ruby Description : helper class for launching cross-platform applications in a fire and forget manner From the homepage: Launchy is helper class for launching cross-platform applications in a fire and forget manner. There are application concepts (browser, email client, etc) that are common across all platforms, and they may be launched differently on each platform. Launchy is here to make a common approach to launching external application from within ruby programs. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20131004054342.1786.83303.reportbug@nida
Bug#725320: ITP: rumember -- Remember The Milk Ruby API and command line client
Package: wnpp Severity: wishlist Owner: Gioele Barabucci gio...@svario.it * Package name: rumember Version : 1.0.1 Upstream Author : Tim Pope * URL : https://github.com/tpope/rumember * License : MIT Programming Lang: Ruby Description : Remember The Milk Ruby API and command line client From the homepage: The sole motivation for this project was a quick way to capture to-dos from the command line. As such, I've chosen a chosen a very short command name of ru (something I'd normally never allow myself to do). All arguments are joined with spaces and used to invoke Remember The Milk's Smart Add feature. ru buy milk -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20131004054907.1827.51854.reportbug@nida
Bug#723905: ITP: ruby-filepath -- Small gem to manipulate paths
Package: wnpp Severity: wishlist Owner: Gioele Barabucci gio...@svario.it * Package name: ruby-filepath Version : 0.6 Upstream Author : Gioele Barabucci gio...@svario.it * URL : https://rubygems.org/gems/filepath * License : CC0 Programming Lang: Ruby Description : Small gem to manipulate paths From the gemspec: The Filepath class provides immutable objects with dozens of convenience methods for common operations such as calculating relative paths, concatenating paths, finding all the files in a directory or modifying all the extensions of a list of filenames at once. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130921053621.4229.40348.reportbug@nida
