Bug#925530: cloud.debian.org: Debian docker images pointing to github for bug tracking
On 28/06/20 at 23:38 +0200, Bernd Zeimetz wrote: > > > On 6/28/20 10:58 PM, Lucas Nussbaum wrote: > > Well, I think that it would a good thing for Debian to enforce some > > consistency on Debian images for clouds and software that require > > VM images, at least about where to find information about such images, > > and where to report problems. > > > > And I don't think that pointing to github for our tooling, and for bug > > reporting, is really an acceptable solution for something that is > > officially endorsed by Debian. > > Official *Docker* images come from > https://github.com/docker-library/official-images > > It might be possible to pull git repositories from the outside of git > hub in there, though, but I doubt it is. At least you'll have to use > github pull requests. > > Of course you are free to run your own registry even under a debian.org > domain and provide official Debian images for docker there, but as long > as you want to have them in the docker hub, I think the current practice > is just fine. And: its an image from DOCKER, maintained by Debian > developers - its not an image from DEBIAN. It says 'Docker official > images', not 'Debian official images'. > > To be honest, I fail to understand why this needs discussion at all. I don't see what would be the problem with: - tracking problems using a BTS pseudo-package - maintaining the tooling (debuerreotype) on salsa - mirroring the tooling to github, if that's a requirement - maintaining the metadata in https://github.com/docker-library/official-images/blob/master/library/debian using github (which means that only the "release" process involves github) Lucas
Re: Bug#963191: RFH: aufs
Hallo, 20.06.20 13:26 Bastian Blank: > On Sat, Jun 20, 2020 at 12:14:17PM +0200, Jan Luca Naumann wrote: > > At the moment aufs is nearly unmaintained since I do not have time due to > > personal issues. Therefore, I would be happy if there is somebody to > > co-maintain the package. > Since the kernel supports overlayfs since some time now, what blocks > it's removal? There are Debian installations on filesystems that are incompatible with overlayfs, for example xfs without d_type. I ran into this while trying to get rid of aufs. Grüße Timo -- ITscope GmbH Ludwig-Erhard-Allee 20 D-76131 Karlsruhe Tel: +49 721 627376-0 Fax: +49 721 66499175 https://www.itscope.com Handelsregister: AG Mannheim, HRB 232782 Sitz der Gesellschaft: Karlsruhe Geschäftsführer: Alexander Münkel, Benjamin Mund, Stefan Reger signature.asc Description: This is a digitally signed message part.
Re: NMU for Imagemagick?
Hello! > > Imagemagick in Debian is extremely outdated (6.9.10.23 vs 7.0.10-21), > > causing some FTBFS on packages that depend on it. .. > It doesn't need a one time NMU, but an additional 1-3 active maintainers. > Failing that, we should rather drop it for bullseye. Personally I prefer the drop-in replacement GraphicsMagick, which is also more recent in Debian. Maybe you should migrate your ImageMagick needs to GraphicsMagic? - https://tracker.debian.org/pkg/graphicsmagick - https://tracker.debian.org/pkg/imagemagick
Re: Bug#963191: RFH: aufs
Hi Timo On Mon, Jun 29, 2020 at 09:32:09AM +0200, Timo Weingärtner wrote: > 20.06.20 13:26 Bastian Blank: > > Since the kernel supports overlayfs since some time now, what blocks > > it's removal? > There are Debian installations on filesystems that are incompatible with > overlayfs, for example xfs without d_type. > I ran into this while trying to get rid of aufs. So we need to document this problem in the release notes. That's an easy task. Regards, Bastian -- Earth -- mother of the most beautiful women in the universe. -- Apollo, "Who Mourns for Adonais?" stardate 3468.1
Bug#963964: release-notes: document aufs removal for bullseye
package: release-notes x-debbugs-cc: Timo Weingärtner , Jan Luca Naumann , 963...@bugs.debian.org, debian-devel@lists.debian.org in #963191 on Mon, Jun 29, 2020 at 10:06:33AM +0200, Bastian Blank wrote: > On Mon, Jun 29, 2020 at 09:32:09AM +0200, Timo Weingärtner wrote: > > 20.06.20 13:26 Bastian Blank: > > > Since the kernel supports overlayfs since some time now, what blocks > > > it's removal? > > There are Debian installations on filesystems that are incompatible with > > overlayfs, for example xfs without d_type. > > I ran into this while trying to get rid of aufs. > So we need to document this problem in the release notes. That's an > easy task. filing a bug to make it a bit easier. -- cheers, Holger --- holger@(debian|reproducible-builds|layer-acht).org PGP fingerprint: B8BF 5413 7B09 D35C F026 FE9D 091A B856 069A AA1C signature.asc Description: PGP signature
Re: Bug#963191: RFH: aufs
On 6/29/20 9:32 AM, Timo Weingärtner wrote: > Hallo, > > 20.06.20 13:26 Bastian Blank: >> On Sat, Jun 20, 2020 at 12:14:17PM +0200, Jan Luca Naumann wrote: >>> At the moment aufs is nearly unmaintained since I do not have time due to >>> personal issues. Therefore, I would be happy if there is somebody to >>> co-maintain the package. >> Since the kernel supports overlayfs since some time now, what blocks >> it's removal? > > There are Debian installations on filesystems that are incompatible with > overlayfs, for example xfs without d_type. Is it still truth that one can't add d_type to an existing xfs of ftype=0, or is there nowadays some kind of conversion utilities I never heard of (yet) to migrate from ftype=0 to ftype=1? Cheers, Thomas Goirand (zigo)
Re: isc-dhcp-client sends DHCPDISCOVER *before* wpa_supplicant authenticates/associates/connects.
Hi Jaime, On Sun, Jun 28, 2020 at 12:06:02PM +0100, Jaime wrote: > I noticed that my debian wireless clients never get a DHCPOFFER from > their first DHCPDISCOVER, and looking at the log shows why: Yes, that's a long-standing issue. The difficulty is that the ISC client is written to be very portable, and there is no common interface for a program to be notified of interface status changes, so implementing this properly would require larger changes in both the client and the underlying support libraries that are shared with the ISC DHCP server, the ISC DHCP relay and the ISC bind nameserver. A less portable or featureful client has a greater chance of supporting this directly. Simon
Bug#963984: ITP: ruby-sys-proctable -- Ruby interface for gathering process informatio
Package: wnpp Severity: wishlist Owner: Valentin Vidic * Package name: ruby-sys-proctable Version : 1.2.5 Upstream Author : Daniel J. Berger * URL : https://github.com/djberg96/sys-proctable * License : Apache-2.0 Programming Lang: Ruby Description : Ruby interface for gathering process informatio The sys-proctable library provides an interface for gathering information about processes on your system, i.e. the process table. Most major platforms are supported and, while different platforms may return different information, the external interface is identical across platforms. This library is required as a dependency for the new version of the sonic-pi package. The package will be maintained in the ruby-team group on Salsa.
Re: Bug#963964: release-notes: document aufs removal for bullseye
Control: tags -1 moreinfo On Lu, 29 iun 20, 10:31:02, Holger Levsen wrote: > package: release-notes > x-debbugs-cc: Timo Weingärtner , Jan Luca > Naumann , 963...@bugs.debian.org, > debian-devel@lists.debian.org > > in #963191 on Mon, Jun 29, 2020 at 10:06:33AM +0200, Bastian Blank wrote: > > On Mon, Jun 29, 2020 at 09:32:09AM +0200, Timo Weingärtner wrote: > > > 20.06.20 13:26 Bastian Blank: > > > > Since the kernel supports overlayfs since some time now, what blocks > > > > it's removal? > > > There are Debian installations on filesystems that are incompatible with > > > overlayfs, for example xfs without d_type. > > > I ran into this while trying to get rid of aufs. > > So we need to document this problem in the release notes. That's an > > easy task. Some more details (or even better, suggested wording) would be much appreciated, just in case none of the Release Notes editors are familiar with XFS and 'd_type'. Kind regards, Andrei -- http://wiki.debian.org/FAQsFromDebianUser signature.asc Description: PGP signature
Bug#961337: ITP: A secure runtime for JavaScript and TypeScript.
Package: wnpp Followup-For: Bug #961337 Owner: Akshat Agarwal * Package name: deno Version : 1.1.2 Upstream Author : Deno authors * URL : https://github.com/denoland/deno * License : MIT Programming Lang: Rust, TypeScript, JavaScript Description : A secure runtime for JavaScript and TypeScript. I intend to package Deno and maintain it. If anybody is willing to can co-maintain with me. Thanks, Akshat Agarwal (humancalico)
Re: debdocker - A Debian docker-based personal builder
On Sun, 28 Jun 2020 17:55:26 -0400, ghostbar wrote: > > Hi Samo, > > Long time ago I wrote something similar from a very simple bash script. Maybe > it would be worth it to check it out. > > > Is really simple and short. Let me know if you have any question. I'm happy to > help. > > > https://github.com/resnullius/deb-build-pkg I was only able to take a a quick look at your tool and description and it certainly expanded my todo list. thanks p.s. It seems to me that there are two major views of package building, which do not necessary result in two compatible lists of requirements: 1. Repetitive build/develop/test of a single package for all potential distros (i.e. requires interaction with sources and build environment for comfortable debugging, ...). 2. Massive build/test of all relevant packages of a single distro (i.e. prohibits any external access - maximal isolation required).
Re: DEP-14: renaming master to main?
Hi, Le 22/06/2020 à 05:50, Michael Biebl a écrit : […] > If we deem that [whatever] is a better term, should we change the defaults > in salsa/gitlab and maybe update DEP-14? FWIW, I’d welcome such change, (almost) whatever name end up being used instead of “master”. If we agree on such change and decide to address it on our repositories before the rest of the community, and then later, another name become the de facto standard, I don’t care that we end up having to change another way around in the following years. One or two changes in a few years laps of time is what we’ve been used to in the last ten years anyway (be it internal Alioth changes, or the recent salsa move). For once, I’d be happy to address such change for “human” reasons, rather than being forced to for technical ones. Regards David
Re: debdocker - A Debian docker-based personal builder
On Mon, Jun 29, 2020 at 8:30 PM Samo Pogačnik wrote: > 2. Massive build/test of all relevant packages of a single distro (i.e. > prohibits any external access - maximal isolation required). This sounds like rebuild-all-the-things: https://github.com/debian/ratt -- bye, pabs https://wiki.debian.org/PaulWise
Re: Bug#961337: ITP: A secure runtime for JavaScript and TypeScript.
On 6/29/20 9:27 PM, Akshat Agarwal wrote: > Package: wnpp > Followup-For: Bug #961337 > Owner: Akshat Agarwal > > > * Package name: deno > Version : 1.1.2 > Upstream Author : Deno authors > * URL : https://github.com/denoland/deno > * License : MIT > Programming Lang: Rust, TypeScript, JavaScript > Description : A secure runtime for JavaScript and TypeScript. > > I intend to package Deno and maintain it. If anybody is willing to can > co-maintain with me. > > Thanks, > Akshat Agarwal (humancalico) I took a quick look at deno and it's dependency tree. It looks like a huge number of dependencies have been packaged by the Debian Rust team already, with many more to go. Due to deno being released on crates.io, thus making it easy to use debcargo tooling and integrate with our debcargo-conf repo, I would like to invite you to coordinate with the Rust team. We're happy to support you regarding packaging. We're active in #debian-rust on irc.freenode.net, and have a less active mailing list at pkg-rust-maintain...@alioth-lists.debian.net. Feel free to join us there. Best regards, Wolfgang.
