Re: transition to usrmerge to start around 2022-09-15 (next Thursday)
On Sun, 11 Sep 2022 11:08:44 -0400, Marvin Renich wrote: >* Ansgar [220910 09:37]: >> the transition to usrmerge as described in [1] is planned to start >> around 2022-09-15 (next Thursday). >[snip] >> We will send an announcement to debian-devel-announce@ once the upload >> to unstable happens. > >What is the point in waiting until after the upload to send to >debian-devel-announce? I would think that most users running >testing/unstable would want prior notice, and you shouldn't assume that >all users will read their mail before performing a routine >update/upgrade cycle on the morning after the upload. I don't think >everyone running testing/unstable reads debian-devel, so I think it >would be appropriate to send to -announce at least one (two?) day(s) >before the upload. And, is there a solution for the existing conflict with the dpkg maintainer? Greetings Marc -- -- !! No courtesy copies, please !! - Marc Haber | " Questions are the | Mailadresse im Header Mannheim, Germany | Beginning of Wisdom " | Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fon: *49 621 72739834
Re: packages expected to fail on some archs
On Sun, 2022-09-11 at 23:07 +0300, Adrian Bunk wrote: > Architecture lists containing all 64bit ports or all little endian > ports create much extra work for anyone adding support for a new > 64bit little endian architecture. Since dpkg already knows about the bits and endianness of ports, perhaps it could add some sort of architecture wildcard system, which would get resolved to real architectures at .dsc build time? Alternatively the wildcards could be added to the .dsc too but that would require sbuild, wb, dak and other tools to understand them too. Until one of those happens, an unofficial Architecture-Tags field that the Debian Janitor could use to update Architecture fields might work. -- bye, pabs https://wiki.debian.org/PaulWise signature.asc Description: This is a digitally signed message part
Re: packages expected to fail on some archs
Hi, Am 11.09.22 um 22:07 schrieb Adrian Bunk: On Sun, Sep 11, 2022 at 05:08:57PM +0200, Samuel Thibault wrote: ... The issue we see is that some DDs end up setting a hardcoded list in the "Architecture" field, rather than just letting builds keep failing on these archs (and then possibly succeeding after some time whenever somebody contributes a fix upstream that gets propagated to Debian). ... I'd say it is the best solution when a package needs non-trivial architecture-specific porting for every architecture it supports. With "non-trivial" I mean not just adding a new architecture to a few #ifdefs, but serious upstream porting efforts. E.g. valgrind does not support riscv64, and if it would ever gain the support in a new upstream version I'd expect the maintainer to add that to the Architecture field when upstream announces support for a new architecture. As a maintainer of such package I agree. I would not like it to fail when it is known that it won't work. Ever. Unless someone actually writes the matching asm part, knowing the ABI and calling convetions, etc. Regards, Reme
Re: packages expected to fail on some archs
On Sun, Sep 11, 2022 at 05:08:57PM +0200, Samuel Thibault wrote: >... > The issue we see is that some DDs end up setting a hardcoded list in > the "Architecture" field, rather than just letting builds keep failing > on these archs (and then possibly succeeding after some time whenever > somebody contributes a fix upstream that gets propagated to Debian). >... I'd say it is the best solution when a package needs non-trivial architecture-specific porting for every architecture it supports. With "non-trivial" I mean not just adding a new architecture to a few #ifdefs, but serious upstream porting efforts. E.g. valgrind does not support riscv64, and if it would ever gain the support in a new upstream version I'd expect the maintainer to add that to the Architecture field when upstream announces support for a new architecture. But Architecture lists for expressing e.g. "64bit" or "little endian" are a real pain for everyone working on bringup of a new port. Which happens far more often than most people realize. There is not only riscv64 (64bit, little endian). Ports is about to start building for arc (32bit, little endian). There are people working on ports like arm64be (64bit, big endian), loongarch64 (64bit, little endian) and many other ports that might never end up being built in the Debian infrastructure (but some of them might get built by derivatives). Architecture lists containing all 64bit ports or all little endian ports create much extra work for anyone adding support for a new 64bit little endian architecture. > Samuel cu Adrian
Re: packages expected to fail on some archs
On Sun, Sep 11, 2022 at 09:25:40PM +0200, Samuel Thibault wrote: > Paul Gevers, le dim. 11 sept. 2022 21:16:08 +0200, a ecrit: > > > > - color packages that "never" had a successful built on an architecture > > different. That information is already available because that's what marks > > the package as "uncompiled" vs "out-of-date". >... > That doesn't cover the case when a package stopped building on an arch, > though. In practive it does, when Paul wrote "never" that actually means "no older version is in the archive on that architecture". On release architectures people are usually fast with getting stale versions of no longer buildable packages removed since it prevents testing migration. > Samuel cu Adrian
Re: packages expected to fail on some archs
Paul Gevers, le dim. 11 sept. 2022 21:16:08 +0200, a ecrit: > On 11-09-2022 17:08, Samuel Thibault wrote: > > We could for instance: > > - Add an Architecture-FTBFS field to debian/control > > - Add an environment variable to debian/rules so that on these archs dh > >fails with a different exit code that buildds would notice. > > - Add a Architecture-FTBFS field in the wb database that DDs can set > > - color packages that "never" had a successful built on an architecture > different. That information is already available because that's what marks > the package as "uncompiled" vs "out-of-date". Oh, right, that information is already available in wb. Mehdi, do you think you can implement that easily for a start? That doesn't cover the case when a package stopped building on an arch, though. Samuel
Re: packages expected to fail on some archs
Hi Samuel, On 11-09-2022 17:08, Samuel Thibault wrote: We could for instance: - Add an Architecture-FTBFS field to debian/control - Add an environment variable to debian/rules so that on these archs dh fails with a different exit code that buildds would notice. - Add a Architecture-FTBFS field in the wb database that DDs can set - color packages that "never" had a successful built on an architecture different. That information is already available because that's what marks the package as "uncompiled" vs "out-of-date". I think it has added value if both cases (marked by the maintainer vs detected automatically) have value and could have different colors. Comparing it to autopkgtest, we currently color no-regression orange, while "neutral" (because of all kind of reasons, but the result of an actively set property) is blue. Paul OpenPGP_signature Description: OpenPGP digital signature
Bug#1019543: ITP: golang-github-bsm-go-vlq -- variable-length quantity encoding library
Package: wnpp
Severity: wishlist
Owner: ChangZhuo Chen (陳昌倬)
X-Debbugs-Cc: debian-devel@lists.debian.org
* Package name: golang-github-bsm-go-vlq
Version : 0.0~git20150828.ec6e8d4
Upstream Author : Dimitrij Denissenko
* URL : https://github.com/bsm/go-vlq
* License : Expat
Programming Lang: golang
Description : variable-length quantity encoding library
This package will be maintained under Debian Go Packaging Team.
This is dependencies of terraform-switcher (https://bugs.debian.org/1014440).
--
ChangZhuo Chen (陳昌倬) czchen@{czchen,debian}.org
http://czchen.info/
Key fingerprint = BA04 346D C2E1 FE63 C790 8793 CC65 B0CD EC27 5D5B
signature.asc
Description: PGP signature
Re: transition to usrmerge to start around 2022-09-15 (next Thursday)
* Ansgar [220910 09:37]: > the transition to usrmerge as described in [1] is planned to start > around 2022-09-15 (next Thursday). [snip] > We will send an announcement to debian-devel-announce@ once the upload > to unstable happens. What is the point in waiting until after the upload to send to debian-devel-announce? I would think that most users running testing/unstable would want prior notice, and you shouldn't assume that all users will read their mail before performing a routine update/upgrade cycle on the morning after the upload. I don't think everyone running testing/unstable reads debian-devel, so I think it would be appropriate to send to -announce at least one (two?) day(s) before the upload. ...Marvin
packages expected to fail on some archs
Hello, We have been discussing a bit on #debian-ports about packages that fail to build on less-mainstream architectures. The issue we see is that some DDs end up setting a hardcoded list in the "Architecture" field, rather than just letting builds keep failing on these archs (and then possibly succeeding after some time whenever somebody contributes a fix upstream that gets propagated to Debian). First, perhaps it's worth reminding to DDs is that it's fine for a package to show up as FTBFS on the buildd status for some archs: that's not RC if the binary packages for that arch are not in testing (and even then, an RM request can fix that, to just express the unfortunate regression) That said, I guess DDs would still set a manual Arch list so as to get the red flags away from their sight on the buildd page status, e.g. from https://buildd.debian.org/status/package.php?p=sthibault%40debian.org&comaint=yes&compact=compact so that they can easily notice which build failures are actually not expected, to be able to efficiently work on those. So perhaps what is missing is a way to express that an FTBFS is expected, so that the buildd page status represents it differently, e.g. in orange rather than red? The idea would be that it should be really easy to set (as easy as setting an Architecture list) so that we can easily recommend it. We could for instance: - Add an Architecture-FTBFS field to debian/control - Add an environment variable to debian/rules so that on these archs dh fails with a different exit code that buildds would notice. - Add a Architecture-FTBFS field in the wb database that DDs can set The tricky part I see is that AIUI the buildd status page doesn't have direct access to debian/control, only to the wb database, so the first solution is not immediate to implement. The third option would be the most obvious from the buildd point of view, but that's not very convenient for DDs. Possibly such field could be automatically set according to the Packages entry when a newer upload is done? Samuel
Re: Presenting DPKG_ROOT
Hi, Quoting Josh Triplett (2022-09-11 15:26:52) > Johannes Schauer Marin Rodrigues wrote: > > What do you think? Is this the right solution to the problem? A few more > > bits > > about DPKG_ROOT as well as alternative solution proposals (including > > rejected > > ones) can be found on this wiki page: > > > > https://wiki.debian.org/Teams/Dpkg/Spec/InstallBootstrap#Proposal:_chrootless_maintscripts > > > > So lets come back to our question of scope: Right now, our DPKG_ROOT patches > > are limited to Essential:yes, build-essential, apt and systemd. We also > > restrict the mechanism to initial installations only and upgrades are not > > supported. We also currently require that the system (and its tools) on the > > outside must be the same as the chroot that is being created with > > DPKG_ROOT. As > > far as enabling very early architecture bootstrap goes, this solves the > > problem. > > > > So what do you think? Is this okay? Is there a better solution? > > So, first of all, I'm thrilled to see work on improving bootstrapping > and cross-bootstrapping. I'm also thrilled to see DPKG_ROOT being > discussed more broadly. > > Regarding the specific solution: the DPKG_ROOT approach has concerned me > since it was introduced, because maintainer scripts run as root, so a > bug in one package's DPKG_ROOT support (let alone the absence of > DPKG_ROOT support) would result in modifying the host system rather than the > target chroot. That is correct. > I would love to see the DPKG_ROOT support augmented with `unshare`, a mount > namespace, a UID namespace, and a chroot, such that: > > - The host filesystem is bind-mounted read-only. > - Host devices are not available (only a minimal /dev); this will also > help ensure bootstraps don't depend on any aspect of the host system. > - The maintainer scripts run as container-root, but not as host-root, so > that they can't accidentally change any aspect of the host. > > This could still make use of the existing DPKG_ROOT support; this would > be completely transparent to the maintainer scripts and tools ported > thus far. > > This would also allow bootstrapping as non-root, on systems that allow > creating UID namespaces as non-root. > > As a bonus, testsuites could use an overlayfs instead of a read-only > bind mount, and then check afterwards if *any* changes occurred in the > overlay, which would be a test failure. > > Does that seem like a reasonable addition to the DPKG_ROOT support? Bind-mounting the host system read-only is an interesting idea that we haven't tried out yet. To avoid unintended modifications of the host system we are currently testing two different approaches in our CI system: 1. we run the whole chroot creation inside fakeroot. That way, the maintainer scripts think they are run as root but they actually cannot modify anything important. 2. we run the chroot creation as root but inside mmdebstrap in unshare mode. We create a tarball of the outer system before and after running the DPKG_ROOT method and then compare these two tarballs to make sure that no changes were done in the outer system. I think making the outer system read-only via bind-mounts is another valuable test that we should implement. Thanks! cheers, josch signature.asc Description: signature
Re: Presenting DPKG_ROOT
Johannes Schauer Marin Rodrigues wrote: > What do you think? Is this the right solution to the problem? A few more bits > about DPKG_ROOT as well as alternative solution proposals (including rejected > ones) can be found on this wiki page: > > https://wiki.debian.org/Teams/Dpkg/Spec/InstallBootstrap#Proposal:_chrootless_maintscripts > > So lets come back to our question of scope: Right now, our DPKG_ROOT patches > are limited to Essential:yes, build-essential, apt and systemd. We also > restrict the mechanism to initial installations only and upgrades are not > supported. We also currently require that the system (and its tools) on the > outside must be the same as the chroot that is being created with DPKG_ROOT. > As > far as enabling very early architecture bootstrap goes, this solves the > problem. > > So what do you think? Is this okay? Is there a better solution? So, first of all, I'm thrilled to see work on improving bootstrapping and cross-bootstrapping. I'm also thrilled to see DPKG_ROOT being discussed more broadly. Regarding the specific solution: the DPKG_ROOT approach has concerned me since it was introduced, because maintainer scripts run as root, so a bug in one package's DPKG_ROOT support (let alone the absence of DPKG_ROOT support) would result in modifying the host system rather than the target chroot. I would love to see the DPKG_ROOT support augmented with `unshare`, a mount namespace, a UID namespace, and a chroot, such that: - The host filesystem is bind-mounted read-only. - Host devices are not available (only a minimal /dev); this will also help ensure bootstraps don't depend on any aspect of the host system. - The maintainer scripts run as container-root, but not as host-root, so that they can't accidentally change any aspect of the host. This could still make use of the existing DPKG_ROOT support; this would be completely transparent to the maintainer scripts and tools ported thus far. This would also allow bootstrapping as non-root, on systems that allow creating UID namespaces as non-root. As a bonus, testsuites could use an overlayfs instead of a read-only bind mount, and then check afterwards if *any* changes occurred in the overlay, which would be a test failure. Does that seem like a reasonable addition to the DPKG_ROOT support? - Josh Triplett
Re: Automatic trimming of changelogs in binary packages
On Sun, Sep 11, 2022 at 03:09:07PM +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. > >> > >> Again, I may have misread, then. Because what I understood is > >> > >> Trim changelogs: > >> 1. Convert them to metadata > >> 2. Ship untrimmed part in package DB > >> 3. Get remaining part from network > >> > >> Effectively eliminating /usr/share/doc/*changelog* files. > > Even this isn't "making them online only". > > Yes, you’re right. However, my reservation is whether dpkg is more prone to > breaking in disaster recovery scenarios. Reading a gzipped file is always > simpler than querying a DB via more abstraction. I assume that cases when your dpkg database is broken and cases when you need to read changelogs of updated packages shouldn't intersect. -- WBR, wRAR signature.asc Description: PGP signature
Re: Automatic trimming of changelogs in binary packages
> On 11 Sep 2022, at 14:59, Andrey Rahmatullin wrote: > > On Sun, Sep 11, 2022 at 02:41:24PM +0300, Hakan Bayındır wrote: >>> On Tue, Sep 06, 2022 at 12:11:38PM +0300, Hakan Bayındır wrote: While all looks good and feels sound from many aspects, I have some reservations against treating changelogs as metadata. Current changelogs as files have a well known place, can be used by anything and everything, and they are local. >>> Assuming you are talking about making changelogs available at a dpkg >>> command, as in the RPM world, it's actually making the way to get a >>> package changelog more well-known, not less. >> >> If this created the opposite effect in RPM world w.r.t. my theory, then I >> stand corrected. > It didn't create anything because that was how it worked from the > beginning. > But yes, it's easier to run -q --changelog than write a full file path. While I manage RPM based systems too, I’m not that familiar with depths of RPM. > 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. >> >> Again, I may have misread, then. Because what I understood is >> >> Trim changelogs: >> 1. Convert them to metadata >> 2. Ship untrimmed part in package DB >> 3. Get remaining part from network >> >> Effectively eliminating /usr/share/doc/*changelog* files. > Even this isn't "making them online only". Yes, you’re right. However, my reservation is whether dpkg is more prone to breaking in disaster recovery scenarios. Reading a gzipped file is always simpler than querying a DB via more abstraction. Cheers, H. > -- > WBR, wRAR
Re: Automatic trimming of changelogs in binary packages
On Sun, Sep 11, 2022 at 02:41:24PM +0300, Hakan Bayındır wrote: > > On Tue, Sep 06, 2022 at 12:11:38PM +0300, Hakan Bayındır wrote: > >> While all looks good and feels sound from many aspects, I have some > >> reservations against treating changelogs as metadata. > >> > >> Current changelogs as files have a well known place, can be used by > >> anything > >> and everything, and they are local. > > Assuming you are talking about making changelogs available at a dpkg > > command, as in the RPM world, it's actually making the way to get a > > package changelog more well-known, not less. > > If this created the opposite effect in RPM world w.r.t. my theory, then I > stand corrected. It didn't create anything because that was how it worked from the beginning. But yes, it's easier to run -q --changelog than write a full file path. > >> 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. > > Again, I may have misread, then. Because what I understood is > > Trim changelogs: > 1. Convert them to metadata > 2. Ship untrimmed part in package DB > 3. Get remaining part from network > > Effectively eliminating /usr/share/doc/*changelog* files. Even this isn't "making them online only". -- WBR, wRAR signature.asc Description: PGP signature
Presenting DPKG_ROOT
Hi, in 2016 we filed our first DPKG_ROOT patch #824594 against base-files. The dpkg version at the time just had included support for the DPKG_ROOT variable being set for maintainer scripts and we were excited to try out this new feature for creating foreign architecture chroots. At the time we thought that no discussion on d-devel was necessary before filing the bug because we knew only 10 source packages had to add DPKG_ROOT to their maintainer scripts and because doing so would not affect any normal installation. In hindsight, this was a mistake. We should've brought it up on d-devel and explained our idea first before starting to file our bugs with patches. Luckily in this very first bug, Santiago pushed back and requested to first see that our concept really works before applying anything. This was excellent advice and resulted in a CI job on salsa that regularly checks that Debian unstable with our patches produces bit-by-bit identical chroots created with DPKG_ROOT compared to chroots created the normal way. This proof of our method working exactly as intended convinced Santiago and probably many other maintainers that applied our patches to their source packages. Today, six years later, all but two of our patches have been applied. The transition is nearly complete. So why are we (Helmut and me) writing you now that things are already done? Firstly to apologize for having misjudged the situation in the past years. We should've communicated DPKG_ROOT to all of d-devel at the very beginning to allow for project wide discussion but decided not to do so. For that mistake we are sorry. Secondly, while we of course are hoping for a blessing of our contributions in hindsight, we wanted to ask whether we maybe missed anything that makes our DPKG_ROOT approach inferior to other ways to solve this problem. We also wanted to ask about the scope of DPKG_ROOT. So what exactly is the problem we are trying to solve? In the very early days of a new architecture, emulation support is either not available at all or too buggy to be useful for any practical purposes. After having cross-built the initial package set, these packages need to be installed to create a chroot that can then be used to continue building packages natively on the new architecture, completing the early bootstrap process. But creating that chroot requires package maintainer scripts to be run but we cannot emulate the new architecture to run any of its binaries. So how was this done in the past? By performing the tasks that are usually carried out by package maintainer scripts manually. We wanted to find a way that would allow for an automatic creation of a foreign architecture chroot without being able to run any of the binaries in it. To solve this problem, since dpkg 1.18.10 (old-old-stable) the variable `DPKG_ROOT` is set to the empty string in all maintainer script invocations. All, except when dpkg is run with `--force-script-chrootless` and `--root` set to a chroot directory path which will be stored in the `DPKG_ROOT` environment variable. This is a “force” option because if set, dpkg will not do a chroot call into the new chroot before calling the maintainer script, thus causing undesired changes in the outer system instead. By installing packages in a way that avoids the chroot call, maintainer scripts will run the tools from outside the chroot instead of the foreign architecture tools inside the chroot. These tools need to know where they need to operate on and they use the value of the `DPKG_ROOT` variable to get this information. As of today, tools like dpkg-divert, dpkg-maintscript-helper, deb-systemd-helper, or update-shells understand the `DPKG_ROOT` variable and will do the right thing. Maintainer script snippets as they are generated by debhelper also already respect `DPKG_ROOT`. Where we need package-specific patches is when maintainer scripts call general purpose tools like mv, cp, chown or chmod, where it doesn’t make sense to let them support `DPKG_ROOT` because those tools are not limited to be used in maintainer scripts. Source packages in the Essential:yes and build-essential set that require changes involving the `DPKG_ROOT` variable in their maintainer scripts are: base-files, base-passwd, coreutils, dash, debianutils, dpkg, gcc-defaults, glibc, pam, shadow Usually, patches look like this: https://bugs.debian.org/cgi-bin/bugreport.cgi?att=1;bug=983565;filename=coreutils_8.32-4.1.debdiff;msg=5 So if before the maintainer script ran `rm /usr/bin/touch` then it now runs `rm "$DPKG_ROOT/usr/bin/touch"`. Since the `DPKG_ROOT` variable is usually empty, this change will be a NO-OP in normal installations and only affects setups that explicitly called dpkg in the way described above. Another way to support `DPKG_ROOT` is to remove maintainer scripts altogether and replace them by declarative methods, which was done in case of the transition from add-shell and remove-shell to update-shells: https://lists.debian.o
Re: Automatic trimming of changelogs in binary packages
Hi Andrey, > On 6 Sep 2022, at 12:42, Andrey Rahmatullin wrote: > > On Tue, Sep 06, 2022 at 12:11:38PM +0300, Hakan Bayındır wrote: >> While all looks good and feels sound from many aspects, I have some >> reservations against treating changelogs as metadata. >> >> Current changelogs as files have a well known place, can be used by anything >> and everything, and they are local. > Assuming you are talking about making changelogs available at a dpkg > command, as in the RPM world, it's actually making the way to get a > package changelog more well-known, not less. If this created the opposite effect in RPM world w.r.t. my theory, then I stand corrected. > >> 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. Again, I may have misread, then. Because what I understood is Trim changelogs: 1. Convert them to metadata 2. Ship untrimmed part in package DB 3. Get remaining part from network Effectively eliminating /usr/share/doc/*changelog* files. Thanks for clarifying both, Cheers, H. > -- > WBR, wRAR
please coordinate using ITP bugreports
Hi all fellow Debian developers, Duplicated work is silly and learning you've done it feels frustrating, so let's try avoid that by a) communicating when initiating a work and b) checking first if others have already begun same work. For Debian packages, we have since long established a method to coordinate this called "intent-to-package" bugreports, or ITPs. Please file an ITP when you prepare a new package, and before you do please check first that there is not already an ITP for that same package. Purpose of ITPs is not to "claim ownership", but an invitation to coordinate efforts. It is only an invitation, however, and requires followup to work as intended: Please be respectful to your peers by checking for ITPs before (initiating and) uploading new packages into Debian. You might work in a team that does things differently - maybe hint about new efforts in our wiki or on salsa or on a team-specific mailinglist. Please have in mind, however, that Debian is larger than your team, and whatever you choose to do internally within a team is in *addition* to how we generally collaborate in Debian as a whole. Debian uses Debbugs as bugtracker, and within that uses ITPs to coordinate new packages. Concretely this post was triggered by stumbling upon "rust-rmp" package in NEW queue last night, after working on that package myself as announced in bug#1014339. My point here is the general usefulness of ITPs, however. This affects Rust team internal procedures but concerns Debian as a whole, so please reply to debian-devel@l.d.o (headers added accordingly). Kind regards, - Jonas -- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: signature
