Re: Announcing Debian Social
On Sun, 22 Mar 2020 22:21:01 +0100, Enrico Zini wrote: >For the records, I consider sso.debian.org as it is now, past its "best >before" date, and starting to smell quite bad. While we're at thiss, what is the tracker.d.o authenticating against? Since Firefox has removed the point-and-drool interface to client certificates, one needs to manually meddle around with OpenSSL to be able to log in. Is this going to stay this way? Greetings Marc, who thankfully has still one single machine where the client cert has not expired yet -- -- !! 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: MBF? ftbs
Quoting Lucas Nussbaum (2020-03-23 07:44:50) > However, in several cases, it seems that the problem is that sbuild does not > install packages in Build-Depends-Indep when doing a source-only build, and > then fails when doing 'debian/rules clean'. I wonder if that should be fixed > in sbuild. That is not a bug in sbuild. See Debian policy §7.7 [1]: > clean > Only the Build-Depends and Build-Conflicts fields must be satisfied when > this target is invoked Thanks! cheers, josch [1] https://www.debian.org/doc/debian-policy/ch-relationships.html#relationships-between-source-and-binary-packages-build-depends-build-depends-indep-build-depends-arch-build-conflicts-build-conflicts-indep-build-conflicts-arch signature.asc Description: signature
Re: Announcing Debian Social
On Mon, Mar 23, 2020 at 08:10:18AM +0100, Marc Haber wrote: > While we're at thiss, what is the tracker.d.o authenticating against? > Since Firefox has removed the point-and-drool interface to client > certificates, one needs to manually meddle around with OpenSSL to be > able to log in. You can find extensive and up to date documentation on how to make it work here: https://wiki.debian.org/DebianSingleSignOn This said, I would prefer not to see this kind of attitude in any of the places I use to work with others. Enrico -- GPG key: 4096R/634F4BD1E7AD5568 2009-05-08 Enrico Zini signature.asc Description: PGP signature
Re: MBF? ftbs
On Mon, Mar 23, 2020 at 08:15:47AM +0100, Johannes Schauer wrote: > Quoting Lucas Nussbaum (2020-03-23 07:44:50) > > However, in several cases, it seems that the problem is that sbuild does not > > install packages in Build-Depends-Indep when doing a source-only build, and > > then fails when doing 'debian/rules clean'. I wonder if that should be > > fixed > > in sbuild. > > That is not a bug in sbuild. See Debian policy §7.7 [1]: > > > clean > > Only the Build-Depends and Build-Conflicts fields must be satisfied when > > this target is invoked so it seems to me that these bugs should be filed with severity 'important' just like 'packages leave files after purge on the system' bugs (which piuparts detects and which we have been filing with severity 'important' since many years: - these are a clear policy violations, so 'normal' is not really appropriate. - the practical impact however is low, so filing them with severity 'serious' does more harm than good. -- cheers, Holger --- holger@(debian|reproducible-builds|layer-acht).org PGP fingerprint: B8BF 5413 7B09 D35C F026 FE9D 091A B856 069A AA1C There are no jobs on a dead planet. (Also many other things but people mostly seem to care about jobs.) signature.asc Description: PGP signature
Re: ratt as a service?
Hi, Il 23/03/20 01:33, Sandro Tosi ha scritto: > So i'm wondering if Debian should offer a service where: > > * a developer (as someone with a gpg key in the debian keyring, at > least at first) uploads a binary .changes file (so source + binary > packages, built locally) to a new dput upload queue > * ratt is executed against that package reverse dependencies > * when the run is completed, a recap email is sent to the Changed-By > address with the list of fail/success > * also a web interface to track the progress of the rebuild & read the > build logs. As a maintainer of Boost (hundreds of rev deps, including pretty large stuff), I would not dislike something like that. For the moment I am managing to use some scripts of my own to distribute the build on a few computers, some of which are kindly offered by friends of mine. It is not an ideal situation. Giovanni. -- Giovanni Mascellani Postdoc researcher - Université Libre de Bruxelles signature.asc Description: OpenPGP digital signature
Bug#954793: ITP: golang-github-caddyserver-certmagic -- Automatic HTTPS using Let's Encrypt
Package: wnpp Severity: wishlist Owner: Jérémy Lal * Package name: golang-github-caddyserver-certmagic Version : 0.10.4-1 Upstream Author : Caddy * URL : https://github.com/caddyserver/certmagic * License : Apache-2.0 Programming Lang: Go Description : Automatic HTTPS using Let's Encrypt Mature and reliable ACME client integration for Go. Provides a simple interface for a go HTTP server: - handles redirection to HTTPS automatically - obtain and renew TLS certificates - staples OCSP responses CertMagic supports the full suite of ACME features. It's a dependency of acme-dns package, and looks quite nice on its own.
Bug#954797: ITP: thom2 -- Thomson TO7 Emulator
Package: wnpp Severity: wishlist Owner: Jean Philippe EIMER * Package name: thom2 Version : 2.3.0 Upstream Author : Jean Philippe EIMER * URL : https://sourceforge.net/projects/thom2/ * License : GPL Programming Lang: C Description : Thomson TO7 Emulator GTK2/GTK3 Thomson TO7 Emulator for Linux. The Thomson TO7 is a French personal computer popular in the 1980s. It's based on the 6809 processor, and runs a 1982 Microsoft Basic. This emulator needs binary/ROM files to be copied in /usr/share/thom. They are not provided in the package for copyright reasons, but can be downloaded from: http://dcmoto.free.fr * to770.rom : mandatory, main ROM * cd90-640.rom : optional, for floppy disk * memo7/basic.m7 or memo7/basic128.m7 : mandatory, interface and for programs written in Basic Thom2 is a fork of Thom, an old and unmaintained version from Sylvain Huet and Eric Botcazou. It provides several updates, enhancements and improvements.
Re: Next attempt to add Blends to Debian installer
On Mon, Jan 06, 2020 at 04:23:08PM +, Steve McIntyre wrote: >Hey Andreas! > >On Wed, Dec 18, 2019 at 08:23:39AM +0100, Andreas Tille wrote: >> >>the first alpha of the installer of Debian 11 is out. As we talked at >>DebConf about better Blends support: Is there anything we can test >>regarding tasksel? > >Not yet, I'm afraid. A little too swamped so far, but you're near the >top of my TODO list. I'm hoping to get some time for development on >this in the next couple of months. (Overdue!) update: I've been hacking on this for a while, and I hope to have a prototype for testing up shortly. It works fine on my local system, but in a test d-i build it fails totally so I've clearly missed something! Debugging that now... -- Steve McIntyre, Cambridge, UK.st...@einval.com Getting a SCSI chain working is perfectly simple if you remember that there must be exactly three terminations: one on one end of the cable, one on the far end, and the goat, terminated over the SCSI chain with a silver-handled knife whilst burning *black* candles. --- Anthony DeBoer
Re: [Pkg-puppet-devel] Dependencies on obsolete puppet-common transitional package (potential mass bug filing).
On 3/23/20 1:55 AM, peter green wrote: > The puppet source package, recently recently dropped the puppet-common > binary package. This package has been a transitional dummy package since > stretch. > > Unfortunately there are still a substantial number of packages depending > on it. They are listed by maintainer at the end of this mail (the list > is based on packages that currently have the issue in bullseye). > > I filed bugs for the first couple I spotted, but then started to wonder > if, given that nearly all of the packages involved are maintained by the > openstack team, a more centralised approach is better. If I get no > response however I will go ahead with a mass bug filing so the testing > autoremoval system can do it's thing. > > Debian Ruby Extras Maintainers > > ruby-rspec-puppet > > Debian OpenStack > puppet-module-aboe-chrony > puppet-module-antonlindstrom-powerdns > puppet-module-aodh > puppet-module-arioch-redis > puppet-module-barbican > puppet-module-ceilometer > puppet-module-ceph > puppet-module-cinder > puppet-module-cloudkitty > puppet-module-congress > puppet-module-debian-archvsync > puppet-module-deric-zookeeper > puppet-module-designate > puppet-module-glance > puppet-module-gnocchi > puppet-module-heat > puppet-module-heini-wait-for > puppet-module-horizon > puppet-module-icann-quagga > puppet-module-icann-tea > puppet-module-ironic > puppet-module-joshuabaird-ipaclient > puppet-module-keystone > puppet-module-magnum > puppet-module-manila > puppet-module-michaeltchapman-galera > puppet-module-murano > puppet-module-neutron > puppet-module-nova > puppet-module-octavia > puppet-module-openstack-extras > puppet-module-openstacklib > puppet-module-oslo > puppet-module-ovn > puppet-module-panko > puppet-module-placement > puppet-module-puppetlabs-haproxy > puppet-module-puppetlabs-rabbitmq > puppet-module-puppetlabs-rsync > puppet-module-rodjek-logrotate > puppet-module-sahara > puppet-module-swift > puppet-module-theforeman-dns > puppet-module-voxpupuli-alternatives > puppet-module-voxpupuli-collectd > puppet-module-voxpupuli-corosync > puppet-module-voxpupuli-ssh-keygen > puppet-module-vswitch > > PKG OpenStack > puppet-module-adrienthebo-filemapper > puppet-module-camptocamp-kmod > puppet-module-camptocamp-openssl > puppet-module-duritong-sysctl > puppet-module-nanliu-staging > puppet-module-puppetlabs-mongodb > puppet-module-puppetlabs-tftp > puppet-module-puppetlabs-vcsrepo > puppet-module-richardc-datacat > puppet-module-saz-rsyslog > puppet-module-saz-ssh > puppet-module-sbitio-monit > > Debian OpenStack > puppet-module-puppet-community-mcollective Gosh, these are all mine... Don't worry, no need to bother filling bugs, I'll take care of it. However, what package should it depends on now? Cheers, Thomas Goirand (zigo)
Re: [Pkg-puppet-devel] Dependencies on obsolete puppet-common transitional package (potential mass bug filing).
Thomas Goirand wrote: > Gosh, these are all mine... Don't worry, no need to bother filling bugs, > I'll take care of it. However, what package should it depends on now? On "puppet". Cheers, Moritz
What to do when DD considers policy to be optional? [kubernetes]
Something interesting just happened. An inexperienced DD adopted a very complicated package (kubernetes) and uploaded it with changes that would have never been accepted by ftp-masters. What would be best to do in such situation? The problem is not with DD's qualification (although this certainly plays a role) but with intentional non-compliance with policies and packaging practices. As a person who originally introduced Kubernetes to Debian I can say that it is indeed a lot of work to maintain this package and to reuse packaged libraries. But I've demonstrated that it is possible at least to some extent. New maintainer of kubernetes do not even make an attempt to build it properly and blatantly states the following in README which demonstrates profound lack of understanding of problems that were impairing maintenance of the package: "I kindly ask purist aspirations that effectively halted Kubernetes' release and updates in Debian for YEARS to be kept at bay." I don't consider myself to be a purist. I have pragmatic approach to packaging but I feel concerned when policies and packaging practices are circumvented. I don't recall a situation when policing of how a package is maintained would be necessary long after package is accepted... What do we do to ensure quality work in situation of technological hijack when maintainer is unwilling to follow the practice or comply with policy? This is not a technical disagreement so I think that involving technical committee may not be the right way to handle the problem... Or is it? -- Cheers, Dmitry Smirnov. --- We do our friends no favors by pretending not to notice flaws in their work, especially when those who are not their friends are bound to notice these same flaws. -- Sam Harris signature.asc Description: This is a digitally signed message part.
Re: Repeated Debian WiFi problem
On 22.03.20 10:47, Marc Haber wrote: > On Sun, 22 Mar 2020 02:20:18 -0700, Peter Pynchon > wrote: > >> *In future Debian versions, could you please include the ASUS driver in the >> standard package?* *The model number is the ASUS N53 USB WiFi adapter with >> the rt3572 chip.* I see on your website that ASUS N53 USB adapters with >> different chips have similar problems. > > Does the driver need non-free firmware? If yes, the card will probably > never work out of the box in Debian proper, and you might need to > install the firmware manually. Doing this will most probably solve > your issue with current Debian as well. There is install media that include non-free Wifi/Network card drivers AFAIK (you'll need to search around). Also if you include the non-free section in your /etc/apt/sources.list then you'll get a non-free firmware package that you can install. Again please search packages.debian.org for a corresponding firmware package. This belongs to a Debian support channel though and not to debian-devel. *t
Re: ratt as a service?
I've made some progress on a service for this during a GSOC project: - https://salsa.debian.org/autodeb-team/autodeb-packaging - https://auto.debian.net/ (expired ssl cert - sorry) Managing a service like this takes a lot of energy and time. GSOC would allow me to work on it full time, but I could never find the time to manage it outside of that. I'd be willing to give tips to anyone who would want to pick it up, or give ideas if you decide to start fresh. I'd even be willing to mentor a GSOC project on it. Cheers, -- Alexandre Viau av...@debian.org
Re: email backend for fedmsg
The email backend might be quite a heavy-weight idea ... although I think it would do the job if properly setup and _very_ reliably. I was thinking about something similar to google pub/sub. Another approach how to add reliability to the current fedmsg would be to add an optional sqlite persistence to each application publishing the fedmsg messages. Basically, the messages would be stored in a circular buffer of configurable size so that when some service drops off, we could still keep messages for it for some time until it recovers. This is a very rough idea and there is this whole problem how subscribes should get information about providers and so on...some analysis is here http://fedmsg.com/federated-message-bus/ I would like to continue the fedmsg project that was mainly started by Ralph Bean some years ago because I like the idea of a federated distribution-independent message bus that was triggered by Debian/Fedora cooperation. There might be some technical challenges on the way but solvable in the end and the solution might be interesting. On the other hand, I am only one guy with limited time so if anyone wants to cooperate on this, it would be most welcome. clime
Re: What to do when DD considers policy to be optional? [kubernetes]
Hello Dmitry, Janos, others, On Mon 23 Mar 2020 at 05:32PM +11, Dmitry Smirnov wrote: > Something interesting just happened. An inexperienced DD adopted a very > complicated package (kubernetes) and uploaded it with changes that would have > never been accepted by ftp-masters. Specifically, as README.Debian states, the vendor/ subdirectory of the source package contains more than two hundred Go libraries. I can't speak for the whole FTP Team here, but if this had ended up in NEW and I had been the FTP Team member to review it, I would indeed have rejected it, on the grounds that accepting the upload renders Debian less maintaintable in various ways. > What would be best to do in such situation? I think that I would start by filing an RC bug. > The problem is not with DD's qualification (although this certainly plays a > role) but with intentional non-compliance with policies and packaging > practices. > > As a person who originally introduced Kubernetes to Debian I can say that it > is indeed a lot of work to maintain this package and to reuse packaged > libraries. But I've demonstrated that it is possible at least to some extent. > > New maintainer of kubernetes do not even make an attempt to build it properly > and blatantly states the following in README which demonstrates profound lack > of understanding of problems that were impairing maintenance of the package: > >"I kindly ask purist aspirations that effectively halted Kubernetes' > release and updates in Debian for YEARS to be kept at bay." The new maintainer presumably thinks that Policy should have an exception for this sort of case -- let's assume good faith. > I don't consider myself to be a purist. I have pragmatic approach to > packaging but I feel concerned when policies and packaging practices are > circumvented. > > I don't recall a situation when policing of how a package is maintained would > be necessary long after package is accepted... > What do we do to ensure quality work in situation of technological hijack > when maintainer is unwilling to follow the practice or comply with policy? > > This is not a technical disagreement so I think that involving technical > committee may not be the right way to handle the problem... Or is it? I think it counts as a technical disagreement but surely there is room for discussion in a bug report before involving the T.C. -- Sean Whitton signature.asc Description: PGP signature
Re: What to do when DD considers policy to be optional? [kubernetes]
On Tue, Mar 24, 2020 at 1:47 AM Sean Whitton wrote: > Specifically, as README.Debian states, the vendor/ subdirectory of the > source package contains more than two hundred Go libraries. There are a *lot* of embedded code/data copies in Debian already. While it would be nice to remove them, sometimes it isn't possible. Often the copies are forked, or upstream refuses to remove them, sometimes even though they forgot why they were added in the first place. In addition the developer culture in various communities encourages embedded copies. I think the best action we can do is send patches to upstream projects to switch from vendoring to using the native dependency system of the package manager for the related language community. ISTR reading that Go has one of those now. Where language communities don't have a native package manager, we need to invent one for them. Then we can use things like dh-make-perl to package the dependencies for Debian. I have no data but I think this approach is more likely to have success than ranting about embedded copies, tempting though that is. Apart from trying to discourage their use, unfortunately embedded copies are here and they will never go away and we need to accept that fact and to deal with the consequences; for example to ensure that all copies get fixed for security issues, try to get them updated upstream after important bug/performance fixes and so on. https://wiki.debian.org/EmbeddedCodeCopies https://salsa.debian.org/security-tracker-team/security-tracker/raw/master/data/embedded-code-copies https://wiki.debian.org/AutomaticPackagingTools -- bye, pabs https://wiki.debian.org/PaulWise
Re: What to do when DD considers policy to be optional? [kubernetes]
❦ 24 mars 2020 03:11 +00, Paul Wise: >> Specifically, as README.Debian states, the vendor/ subdirectory of the >> source package contains more than two hundred Go libraries. > > There are a *lot* of embedded code/data copies in Debian already. > While it would be nice to remove them, sometimes it isn't possible. > Often the copies are forked, or upstream refuses to remove them, > sometimes even though they forgot why they were added in the first > place. In addition the developer culture in various communities > encourages embedded copies. I think the best action we can do is send > patches to upstream projects to switch from vendoring to using the > native dependency system of the package manager for the related > language community. ISTR reading that Go has one of those now. Kubernetes is already using Go modules. They happen to have decided to keep shipping a `vendor/` directory but this is not uncommon. It is often considered as a protection against disappearing modules. So, there is nothing to be done upstream. And BTW, there are currently 616 dependencies, pinned to a specific version. -- Don't just echo the code with comments - make every comment count. - The Elements of Programming Style (Kernighan & Plauger) signature.asc Description: PGP signature
Re: Next attempt to add Blends to Debian installer
Hi Steve, On Mon, Mar 23, 2020 at 07:16:11PM +, Steve McIntyre wrote: > >Not yet, I'm afraid. A little too swamped so far, but you're near the > >top of my TODO list. I'm hoping to get some time for development on > >this in the next couple of months. > > (Overdue!) update: I've been hacking on this for a while, and I hope > to have a prototype for testing up shortly. It works fine on my local > system, but in a test d-i build it fails totally so I've clearly > missed something! Debugging that now... Thanks a lot. Its really appreciated. I hope that other Blends step in with testing since I guess the next monthes I'm busy with COVID-19 issues. Thank you for the update Andreas. -- http://fam-tille.de
