Re: users not reading manpages annoyance [was: apt annoyance]

2021-10-30 Thread Paul Wise
On Sat, 2021-10-30 at 12:52 +0100, Tim Woodall wrote: > I bootstrap exclusively using apt and dpkg, with a few minor tweaks so > that apt can reliably generate a successful install plan when installing > the initial essential packages after dpkg has unpacked them. Sounds like you should take a

Re: Question about source tarballs for packaging

2021-10-18 Thread Paul Wise
On Sun, 2021-10-10 at 21:40 +, Joshua Peisach wrote: > I'm packaging the V programming language for Debian. However, V is  bit > weird at the moment. It's not really ready for stable production/use. > so for a while it will live in experimental. Currently the way building > it works is that

Re: OpenSSL 3.0 - Apache 2.0 vs GPL 2 (Re: Bug#995636: transition: openssl)

2021-10-06 Thread Paul Wise
On Wed, Oct 6, 2021 at 11:30 AM Luca Boccassi wrote: > On Tue, 2021-10-05 at 21:04 +0200, Sebastian Andrzej Siewior wrote: > > Additionally OpenSSL is considered system library, see > > https://bugs.debian.org/951780 > > https://bugs.debian.org/972181 > > Even if that interpretation holds, and

Re: How to build circular dependant packages in debian

2021-09-19 Thread Paul Wise
On Sun, Sep 19, 2021 at 12:57 PM Jeremy Stanley wrote: > According to meeting minutes from last week, it looks like that is > either already happening or at least planned/intended: > > http://lists.starlingx.io/pipermail/starlingx-discuss/2021-September/012048.html Excellent, that is good to

Re: How to build circular dependant packages in debian

2021-09-19 Thread Paul Wise
On Sun, Sep 19, 2021 at 12:40 PM Jeremy Stanley wrote: > On 2021-09-19 01:24:32 + (+), Paul Wise wrote: > > On Sat, Sep 18, 2021 at 2:35 PM Jeremy Stanley wrote: > > > http://lists.starlingx.io/pipermail/starlingx-discuss/2021-September/012058.html > > > >

Re: How to build circular dependant packages in debian

2021-09-18 Thread Paul Wise
On Sat, Sep 18, 2021 at 2:35 PM Jeremy Stanley wrote: > As I understand it, the context here is bootstrapping a new "edge > networking" focused Debian derivative with a number of third-party > patches to existing source packages: Thanks for pointing this out, asked them to contribute back to

Re: How to build circular dependant packages in debian

2021-09-18 Thread Paul Wise
On Sat, Sep 18, 2021 at 8:48 AM open infra wrote: > How build a package A where it has a circular dependent package B (where > package B is depend on package A). Jeremy Stanley pointed out that this is for the StarlingX project, please consider merging StarlingX changes back to Debian and our

Re: ps in cloud images

2021-09-14 Thread Paul Wise
On Mon, Sep 13, 2021 at 8:15 PM mooff wrote: > I might have been imprecise in saying 'cloud' images, but I mean: > $ docker run -it --rm debian:bullseye bash ... > > I think that `reportbug cloud.debian.org` would be the > place to > discuss this I don't think the docker images are produced by

Re: ps in cloud images

2021-09-12 Thread Paul Wise
On Sun, Sep 12, 2021 at 9:00 PM mooff wrote: > IMO, many human hours will be lost by the decision not to include > procps in the default cloud images. I think that `reportbug cloud.debian.org` would be the place to discuss this. I note that procps is Priority: important and debootstrap installs

Re: Bug#992692: general: Use https for {deb,security}.debian.org by default

2021-09-11 Thread Paul Wise
On Fri, Sep 10, 2021 at 6:03 PM David Kalnischkies wrote: > Because this thread started with the idea to switch the default of d-i > and co to another URI. If you target only apt then you still need > a solution for d-i and a way to convert whatever d-i had into what apt > gets in the end (of the

Re: Wine MinGW system libraries

2021-09-11 Thread Paul Wise
Disclaimer: I know precisely zero of the details here nor if the PE loader can support any of the below features. On Fri, 2021-09-10 at 09:23 +, Bastien ROUCARIES wrote: > The problem is that windows apps particularly games try to check if > mapped ram exec pages are from dll from disk and

Bug#992692: general: Use https for {deb,security}.debian.org by default

2021-09-09 Thread Paul Wise
On Thu, Sep 9, 2021 at 6:03 PM Simon Richter wrote: > Another important argument is that it creates a dependency on > third-party commercial CDNs, and their *continued* sponsorship. This dependency on external providers is unavoidable, Debian definitely cannot afford to run our own CDN at the

Re: Wine MinGW system libraries

2021-09-09 Thread Paul Wise
On Thu, 2021-09-09 at 00:59 -0500, Zebediah Figura wrote: > Unfortunately, no. We have no way of knowing the caller. Can the PE loading mechanism do something like inject a fake dlopen function available only in the Wine namespace that just passes the Wine namespace to the dlmopen function? Or

Re: Wine MinGW system libraries

2021-09-08 Thread Paul Wise
On Thu, 2021-09-09 at 00:39 -0500, Zebediah Figura wrote: > Right, but we don't have any guarantee that library A will load library > B in its constructor routines. In fact, if it's loading library B > dynamically, it's probably not doing that. Can the loader tell which library asked it to

Re: Wine MinGW system libraries

2021-09-08 Thread Paul Wise
On Wed, 2021-09-08 at 23:47 -0500, Zebediah Figura wrote: > Unfortunately, while thinking about the answer to this question, I > realized another snag, which I think really does make using > identically-named dynamic libraries impossible: if system library A > loads system library B

Re: Require packages to build without any configured DNS

2021-09-08 Thread Paul Wise
On Wed, Sep 8, 2021 at 9:51 PM Pirate Praveen wrote: > I don't think the default autopkgtest environment should be as > restrictive as the build environment. So adding this to default > autopkgtest enviroment is not the same as adding it to default build > environment. It is already the case

Re: Require packages to build without any configured DNS

2021-09-08 Thread Paul Wise
On Wed, Sep 8, 2021 at 8:23 PM Thomas Goirand wrote: > Later on, the class calls the method read_resolv_conf that has: It also fails if the file exists but has no nameservers: if len(self.nameservers) == 0: raise NoResolverConfiguration > So, any test case that does that

Re: Wine MinGW system libraries

2021-09-08 Thread Paul Wise
On 9/8/21 3:13 AM, Simon McVittie wrote: > As far as I understand it, the PE loader used for Wine is part of Wine, > so it has total control over the libraries that it loads and how it loads > them. This means that if Wine developers (the experts on this codebase) > have decided a libcapsule-like

Re: Wine MinGW system libraries

2021-09-07 Thread Paul Wise
On Tue, 2021-09-07 at 10:48 -0500, Zebediah Figura wrote: > The outstanding problem seems to be more about potentially breaking > applications because they see two identically named DLLs loaded in the > same process. Applications can and do trawl the internal loader state, > although the Win32

Re: Wine MinGW system libraries

2021-09-06 Thread Paul Wise
On Mon, Sep 6, 2021 at 9:54 PM Zebediah Figura wrote: > The basic problem is that applications can and often do ship with PE > builds of cross-platform libraries. These libraries can be ahead of > Wine's system libraries, behind them, or even built with custom patches. > Accordingly we really

Re: Finding rough consensus on level of vendoring for large upstreams

2021-09-02 Thread Paul Wise
On Thu, Sep 2, 2021 at 10:39 PM Phil Morrell wrote: > Over this last year there seems to have been a noticeable divergence of > maintainer opinion, on what has become known as vendoring Embedded copies of code/etc have downsides ... https://wiki.debian.org/EmbeddedCopies > It is my reading of

Bug#992692: general: Use https for {deb,security}.debian.org by default

2021-09-02 Thread Paul Wise
On Thu, Sep 2, 2021 at 9:06 PM Ansgar wrote: > Accessing www.debian.org will also not work on such systems (and unlike > deb.d.o that does not even offer non-https). It's not Debian's problem. The Tor onion services offer alternatives to the https PKI: https://onion.debian.org/ > Is replacing

Re: Ideas for a dh-privacy-helper

2021-09-02 Thread Paul Wise
On Thu, 2021-09-02 at 15:53 +, Bastien Roucariès wrote: > A few year ago I have created the privacy-breach lintian checks in > order to detect trackers in our doc > > I think we are losing the battle here. These lintian checks are a good start, but they are just heuristics that cannot

Re: Request to Join

2021-08-31 Thread Paul Wise
On Tue, Aug 31, 2021 at 9:29 AM Andrew M.A. Cater wrote: > If you're developers and new to Debian, you might want the Debian mentors > list to find out how Debian packages things. In addition to packaging, there are many other ways to help Debian, both technical and non-technical, most of them

Re: Shall we serve scripts as application or as text?

2021-08-29 Thread Paul Wise
On Sun, Aug 29, 2021 at 2:13 PM Simon McVittie wrote: > For scripting languages like sh and Python, I'm not sure: either way > could be appropriate. Which is more common: sharing scripts as source > code to read and edit, or sharing scripts as executables to download > and run as-is? If the

Re: Shall we serve scripts as application or as text?

2021-08-29 Thread Paul Wise
On Sun, Aug 29, 2021 at 5:17 AM Charles Plessy wrote: > Before I remove text/x-sh and the like so that shell and tcl scripts > files are served as 'application' like others, I would like to hear if > some of you see a potential problem with that. Do the new MIME types cause different behavior in

Re: Debian choice of upstream tarballs for packaging

2021-08-27 Thread Paul Wise
On Wed, Aug 25, 2021 at 2:36 PM Simon Richter wrote: > "git archive" is reproducible I'm told by the Bootstrappable Builds folks that `git archive` isn't deterministic in some cases to do with filtering, I lost the details though. -- bye, pabs https://wiki.debian.org/PaulWise

Re: Debian choice of upstream tarballs for packaging

2021-08-27 Thread Paul Wise
On Wed, Aug 25, 2021 at 10:01 AM Simon Richter wrote: > FWIW, I'd love to see git bundles as a source archive format -- this > would allow shipping a (signed) tag, its commit, and the tree and blob > objects for that commit as a single file that can be built in a > reproducible way and allows

Re: Raising the epoch of the 'prboom-plus' package, turning it into a transitional package

2021-08-23 Thread Paul Wise
On Mon, Aug 23, 2021 at 9:29 AM Simon McVittie wrote: > override_dh_gencontrol: > dh_gencontrol -pprboom-plus -- > -v3:$(DEB_VERSION_UPSTREAM_REVISION) Using this technique you can even do entirely without bumping the epoch, using

Re: Looking for Estonian DD-s

2021-08-22 Thread Paul Wise
On Sun, Aug 22, 2021 at 2:31 PM Aivar Annamaa wrote: > Is here someone, who can meet me in Tartu, Estonia or is willing to > arrange this over the internet? Perhaps I could sign a statement about > my identity with Estonian ID card? I checked the list of lists of Debian locations and there are

Re: Debian 11 Bullseye Setup Problems Error Report

2021-08-20 Thread Paul Wise
On Fri, Aug 20, 2021 at 10:15 PM Timothy M Butterworth wrote: > I give the installer a 5 star rating although I would like to see some > improvements made to the disk configuration utility. Currently the > disk configuration utility is non-intuitive and appears to be designed > for keyboard only

Re: Future of /usr/bin/which in Debian?

2021-08-19 Thread Paul Wise
On Thu, Aug 19, 2021 at 9:17 PM Boyuan Yang wrote: > So we will have https://salsa.debian.org/debian/which-gnu providing a binary > package with name "which". I will upload it to the NEW queue soon. Some folks on IRC wanted to package the FreeBSD which too, so I suggest using which-gnu as the

Re: Use files created during CI to seed trust and attract new users?

2021-08-18 Thread Paul Wise
On Wed, Aug 18, 2021 at 10:36 AM Steffen Möller wrote: > When CI fails, I get an email and can chase things up with a look at the > output files. This is something I like a lot. As a user, though, > especially for scientific packages I would want to see the files that > have been created. These

Re: Debian 11 Bullseye Setup Problems Error Report

2021-08-18 Thread Paul Wise
On Wed, Aug 18, 2021 at 10:42 AM admin4 wrote: > is there a Debian "testing" team? That is composed of everyone who uses Debian and especially those who decide to report an issue they found. > that does test setups of Debian ISOs on a bunch of different hardware with > priority on the most

Re: Debian 11 Bullseye Setup Problems Error Report

2021-08-18 Thread Paul Wise
On Wed, Aug 18, 2021 at 9:12 AM admin4 wrote: > cat feed.xml |nano # wohooo it works > > Too many errors from stdin You need to tell nano to load stdin: cat feed.xml | nano - > here we go admin4 into the spam database... for trying to report a problem > and improve a GNU Linux distribution.

Re: Debian choice of upstream tarballs for packaging

2021-08-18 Thread Paul Wise
On Wed, Aug 18, 2021 at 8:10 AM Simon Josefsson wrote: > 1) Trust paths. Agreed, this is the main exception I mentioned when starting this thread. > 2a) Gnulib. Presumably upstream could be convinced to encode this information into the VCS, perhaps into the standard autogen script that is

Re: Q: How to avoid blhc failure

2021-08-17 Thread Paul Wise
On Wed, Aug 18, 2021 at 2:08 AM Hideki Yamane wrote: > blhc test on salsa-ci fails as below but it seems that blhc's fault > to me. How can I avoid this failure? It looks correct to me, -D_FORTIFY_SOURCE=2 is indeed missing from the c++ command-line. The standard build command for C++

Re: Debian choice of upstream tarballs for packaging

2021-08-17 Thread Paul Wise
On Tue, Aug 17, 2021 at 12:17 PM Simon Richter wrote: > This is also an additional burden on package maintainers: explaining how > they arrived at that particular "upstream" package in a reproducible way Debian explaining how we arrived at a particular orig.tar.gz is well established; use a

Re: Debian 11 Bullseye Setup Problems Error Report

2021-08-17 Thread Paul Wise
On Tue, Aug 17, 2021 at 10:39 AM admin4 wrote: > today was the day trying out the new Debian 11 with LTS (LTS is a reason for > users consider switching to Ubuntu, so good choice there) Debian 11/bullseye is not in LTS mode yet. Debian 10/buster will be in LTS mode in a year's time when regular

Re: Debian security repository canonical URI?

2021-08-17 Thread Paul Wise
On Tue, Aug 17, 2021 at 4:05 AM Daniel Lewart wrote: > That leaves two candidates for the canonical URI: > * http://deb.debian.org/debian-security > * http://security.debian.org/debian-security > > Is there consensus as to which one is preferred? Both of these URLs point at the Fastly CDN,

Re: Debian choice of upstream tarballs for packaging

2021-08-17 Thread Paul Wise
On Mon, Aug 16, 2021 at 1:19 AM Paul Wise wrote: > 1. the ecosystems I'm talking about include cargo, npm, browser > extensions, rubygems, pypi, CPAN etc. Examples of what current Debian practices are for these ecosystems: (Amost?) all rust-* packages come from crates.io. Many/most b

Re: Debian choice of upstream tarballs for packaging

2021-08-17 Thread Paul Wise
On Mon, Aug 16, 2021 at 8:25 PM Pirate Praveen wrote: > Many node modules don't tag their releases so its really hard to get > exact source code corresponding to an npmjs.com release. It is probably worth filing upstream issues when you discover that. > Also with mono repos becoming more

Re: Question Re: Advertising in Packages

2021-08-15 Thread Paul Wise
On Mon, Aug 16, 2021 at 2:22 AM Antonio Russo wrote: >"Can one advertise non-free services in a Debian package? > Is doing so a violation of some Debian policy? There is no specific rule against this, but I feel that culturally Debian generally doesn't like this. > The details are filed

Debian choice of upstream tarballs for packaging

2021-08-15 Thread Paul Wise
Hi all, I noticed that sometimes Debian's choice of upstream source for packaging can be suboptimal. This is especially apparent for the different per-language upstream packaging ecosystems[1], where the upstream packaging differs from the upstream VCS in some significant ways, including missing

Re: Steam Deck: good news for Linux gaming, bad news for Debian :(

2021-08-11 Thread Paul Wise
On Thu, Aug 12, 2021 at 3:22 AM Timothy M Butterworth wrote: > Debian is missing KDE's Amarok music manager. Amarok was removed as it required the obsolete Qt 4 library. Now that upstream has finally ported it to Qt5, it could be reintroduced to Debian. https://tracker.debian.org/pkg/amarok

Re: Code

2021-08-11 Thread Paul Wise
On Wed, Aug 11, 2021 at 12:24 PM Xavier wrote: > Second: a lot of package have also their public source repo. See > https://tracker.debian.org and follow "VCS" links to access to > git/svn/... repo. Aside from the VCS links on packages that use a VCS, the package tracker also links to

Re: Steam Deck: good news for Linux gaming, bad news for Debian :(

2021-08-10 Thread Paul Wise
On Tue, Aug 10, 2021 at 5:38 PM Andrey Rahmatullin wrote: > "So, Arch Linux, one of the main reasons, there's a couple, but the main > reason is the rolling updates of Arch allows us to have more rapid > development for SteamOS 3.0," says Yang. "We were making a bunch of > updates and changes to

Re: Steam Deck: good news for Linux gaming, bad news for Debian :(

2021-07-18 Thread Paul Wise
On Sun, Jul 18, 2021 at 8:30 AM Hanno 'Rince' Wagner wrote: > On Sun, 18 Jul 2021, Paul Wise wrote: > > > Valve have said that this will be an open device that any OS can be > > installed on, just like on PCs, they even mentioned Windows so > > presumably it will be able

Re: Steam Deck: good news for Linux gaming, bad news for Debian :(

2021-07-17 Thread Paul Wise
On Sat, Jul 17, 2021 at 12:49 PM Samuel Henrique wrote: > The Steam Deck is a portable gaming device, running SteamOS, to be > released later this year. ... > SteamOS used to be based on Debian, and Valve seems to have decided to > go with Arch instead (great news for Arch, don't get me wrong).

Re: Recalling Key Points of the Previous Attempt (was: Re: Regarding the new "Debian User Repository"

2021-07-05 Thread Paul Wise
On Mon, 2021-07-05 at 11:02 +, M. Zhou wrote: > Supporting multiple ISA variants based on ld.so means a > multiple of the current package size. Apart from the -cc2-dbgsym package those seem fine to multiply, especially since the intended users probably have lots of disk space. There is also

Re: Recalling Key Points of the Previous Attempt (was: Re: Regarding the new "Debian User Repository"

2021-07-04 Thread Paul Wise
On Sun, Jul 4, 2021 at 11:20 AM Mo Zhou wrote: > There are a few methods to bump the ISA baseline for a debian package > for the official archive: (1) patch the code with gcc's fmv feature; > (2) use the "hardware capabilities" feature of ld.so(8); (3) let the > user modify debian/rules and

Re: Bug#990521: I wonder whether bug #990521 "apt-secure points to apt-key which is deprecated" should get a higher severity

2021-07-01 Thread Paul Wise
On Thu, Jul 1, 2021 at 1:27 PM Jeremy Stanley wrote: > There's nothing especially wrong about using signed-by, but > it's not the security fix some people seem to believe. In short, > *any* package you install can run arbitrary commands as the root > user on your system during installation. Only

Re: vecchio asus eeepc 4g

2021-06-15 Thread Paul Wise
On Tue, Jun 15, 2021 at 1:51 PM giovanni esposito wrote: > B. Giorno, cosa mettere nell' Asus eeepc con 4 G di HD? [Traduzione automatica] Per favore chiedi aiuto per usare Debian sui nostri canali di supporto: Please ask for help using Debian on our support channels:

Re: Unique kernel with my own backup of all Debian repositories

2021-06-12 Thread Paul Wise
On Sat, Jun 12, 2021 at 8:15 PM John E Petersen wrote: > If I find it is possible to simply download the entire collection, without > having to host a mirror, I may very well go that route. That is definitely possible, there are two sides to every Debian mirror: 1) downloading Debian 2) making

Re: Debian mirror / developer machine

2021-06-12 Thread Paul Wise
On Sat, Jun 12, 2021 at 10:51 PM Polyna-Maude Racicot-Summerside wrote: > I'd like to setup a Debian repository for the community If you are talking about a Debian mirror, there are some resources here: https://www.debian.org/mirror/ If you are talking about a separate repository to the

Re: ARM architectures

2021-06-05 Thread Paul Wise
On Sat, Jun 5, 2021 at 4:28 PM Marc Haber wrote: > I haven't advanced to package cross-building yet. Some resources related to that: http://crossqa.debian.net/ https://wiki.debian.org/CrossCompiling -- bye, pabs https://wiki.debian.org/PaulWise

Re: ARM architectures

2021-06-05 Thread Paul Wise
On Sat, Jun 5, 2021 at 8:08 AM Marc Haber wrote: > I'd still consider the Raspberry Pi. It's unfortunate that the binary > non-free blob is already needed to boot the box There is a free replacement for the binary non-free blob here: https://github.com/librerpi/rpi-open-firmware/ Unfortunately

Re: How to commit a new architecture like RISC-V

2021-06-04 Thread Paul Wise
On Sat, May 22, 2021 at 3:24 AM Paul Wise wrote: > The steps are essentially documented in the port template wiki page, > but I have rewritten the page into some clearer text here. The instructions I provided are now available on this wiki page, but much improved with input from other

Re: color Telemetry URL points to Second Hand Domain

2021-06-04 Thread Paul Wise
On Fri, Jun 4, 2021 at 4:02 AM wrote: > As seen in > [contrib/session-helper/org.freedesktop.ColorHelper.gschema.xml](https://salsa.debian.org/debian/colord/-/blob/master/contrib/session-helper/org.freedesktop.ColorHelper.gschema.xml#L31) > The telemetry URL was set to

Re: Seeking feedback on a meta package builder

2021-05-31 Thread Paul Wise
On Mon, May 31, 2021 at 6:26 AM Helmut Grohne wrote: > Here are a number of lock-ins I happen to know: This was mentioned on IRC: cowpoke (from devscripts) -> remote cowbuilder -- bye, pabs https://wiki.debian.org/PaulWise

Re: Seeking feedback on a meta package builder

2021-05-31 Thread Paul Wise
On Mon, May 31, 2021 at 6:26 AM Helmut Grohne wrote: > When someone writes a tool, that happens to build packages as part of > its job (the earlier list), typically one of the build tools (the second > list) is chosen and fixed. It's not like you can mix and match them. > Here are a number of

Re: How to commit a new architecture like RISC-V

2021-05-21 Thread Paul Wise
On Sat, May 22, 2021 at 3:24 AM Paul Wise wrote: > The steps are essentially documented in the port template wiki page, > but I have rewritten the page into some clearer text here: Woops, I sent the mail before I had finished it, I continue from where I stopped. Setup communication ch

Re: How to commit a new architecture like RISC-V

2021-05-21 Thread Paul Wise
On Sat, May 22, 2021 at 2:57 AM zhangjialing wrote: > 1. is it necessary to adapt rebootstrap ? Yes, it is fairly essential to have an automatic bootstrap, so you can continually fix problems that arise with the bootstrap process as Debian evolves. > 2. after adapt rebootstrap,what is the next.

Re: How to commit a new architecture like RISC-V

2021-05-19 Thread Paul Wise
Could you also include these details and the other ones that Helmut requested in the wiki page you created? Please also rename the wiki page to the chosen architecture name (loongarch64) instead of the current name (la64). -- bye, pabs https://wiki.debian.org/PaulWise

Re: Bug#988406: notifying users on EOL of a debian release

2021-05-13 Thread Paul Wise
On Wed, May 12, 2021 at 9:03 AM Holger Levsen wrote: > Yesterday I was helping a friend who's computer since some time > didn't receive updates anymore, the reason was easily found, it > was running wheezy :) > > That friend had no idea that the release they were running was > not supported

Re: How to commit a new architecture like RISC-V

2021-05-11 Thread Paul Wise
On Tue, May 11, 2021 at 9:47 AM zhangjialing wrote: > We have a new architecture , We have compiled a lot of packages.Now the > system can work normally . I think you are talking about LoongArch? I read that CPUs supporting it can also run MIPS, ARM, RISC-V and x86 binaries. Are there any

Bug#987923: ITP: esprima-python -- ECMAScript parsing infrastructure for multipurpose analysis

2021-05-02 Thread Paul Wise
Package: wnpp Severity: wishlist Owner: Paul Wise X-Debbugs-Cc: debian-devel@lists.debian.org * Package name: esprima-python Version : 4.0.1 Upstream Author : Germán Méndez Bravo * URL : https://github.com/Kronuz/esprima-python * License : BSD Programming

Bug#987809: ITP: sptag -- distributed approximate nearest neighborhood search (ANN) library

2021-04-29 Thread Paul Wise
Package: wnpp Severity: wishlist Owner: Paul Wise X-Debbugs-Cc: debian-devel@lists.debian.org * Package name    : sptag   Upstream Author : Qi Chen, Ben Karsin * URL : https://github.com/microsoft/SPTAG/ * License : MIT   Programming Lang: C++   Description : distributed

Re: Changed Github download URLs are affecting lots of existing watch files

2021-03-31 Thread Paul Wise
On Wed, Mar 31, 2021 at 3:50 PM Andreas Tille wrote: > My favourite solution would be to rather use the idea to base this > on the VCSwatch result and automatically change VCS. VCSwatch only looks at repositories linked from Debian Vcs-* headers, not the upstream VCS repositories. -- bye, pabs

Re: Changed Github download URLs are affecting lots of existing watch files

2021-03-31 Thread Paul Wise
On Wed, Mar 31, 2021 at 3:46 PM Andreas Tille wrote: > But I do not want an uscan warning for every single commit. Is git mode > able to distinguish random commits from official releases (tags)? The manual page lists an option for that so it seems likely. -- bye, pabs

Re: Changed Github download URLs are affecting lots of existing watch files

2021-03-30 Thread Paul Wise
On Mon, Mar 29, 2021 at 6:33 PM Olek Wojnar wrote: > Thanks for sharing that, the automated test build is a great feature! It > would be useful if maintainers could opt-in to using something like that for > specific packages. The Janitor is doing something like that:

Re: Changed Github download URLs are affecting lots of existing watch files

2021-03-28 Thread Paul Wise
On Sat, Mar 27, 2021 at 10:18 AM Gard Spreemann wrote: > Phil Morrell writes: > > > Sounds like you're asking for a new github redirector on qa.debian.org > > as there is for sf.net, which could use the official api for stability. FTR there is one of those here:

Re: Questioning debian/upstream/signing-key.asc

2021-03-28 Thread Paul Wise
On Fri, Mar 26, 2021 at 9:15 PM Timo Röhling wrote: > It's the same for me: the only package I maintain where upstream signs their > releases is the package where I am also the author. And I really don't think > that it provides any additional value for Debian in this particular > constellation;

Re: New service: https://debuginfod.debian.net

2021-02-27 Thread Paul Wise
On Sat, Feb 27, 2021 at 10:31 PM Sergio Durigan Junior wrote: > Anyway, as I said before, I don't intend to work on this specific idea > right away, and I don't know if I understand the pushback I'm seeing > against using a debconf question for this. It seems to me that this is > exactly why

Bug#983523: general: some WWW sites no longer work neither in Firefox nor in Chrome

2021-02-25 Thread Paul Wise
On Thu, Feb 25, 2021 at 6:45 PM Janusz S. Bień wrote: > Anyway a clue should be provided by the fact the both (perhaps all?) > browsers are affected. The things broke several weeks ago, perhaps after > the upgrade to 10.8. Please try some of the following things to narrow down where the problem

Re: Proposal: plocate as standard for bookworm

2021-02-09 Thread Paul Wise
On Tue, Feb 9, 2021 at 9:12 PM Ansgar wrote: > Admittedly Debian's other defaults like making every file in $HOME > world-readable by default are very unfriendly too on both multi-user > systems (obviously) and single-user systems where suddenly even the > "nobody" user has access to lots of

Re: Fixed release dates are hurting quality

2021-02-07 Thread Paul Wise
On Sun, Feb 7, 2021 at 4:45 PM Andrey Rahmatullin wrote: > "make sure everything we ship in testing was checked manually before > migrating"?). The Debian CD team has an in-progress tool called ditto that is aimed at manual testing, currently for CD images. Potentially it or something like it

Re: Fixed release dates are hurting quality

2021-02-07 Thread Paul Wise
On Sun, Feb 7, 2021 at 4:20 PM Gard Spreemann wrote: > Wouldn't it be quite the massive paradigm shift to give up on the notion > of tracking problems (= bugs), and instead try to track positive > attributes like fitness for release, though? This is something that is already happening a bit in

Re: Proposal: plocate as standard for bookworm

2021-02-07 Thread Paul Wise
On Sun, Feb 7, 2021 at 9:58 AM Steinar H. Gunderson wrote: > On my server, with ~12M files on rotating media, updatedb.plocate finishes in > ~40 seconds, IIRC. (I'd re-check to be sure, but today is RAID Sunday... :-) ) > On my laptop with 875k files and a regular SSD, it's less than three. It

Re: Proposal: plocate as standard for bookworm

2021-02-06 Thread Paul Wise
On Sat, Feb 6, 2021 at 5:29 PM Steinar H. Gunderson wrote: > I believe a good, fast locate is something that we should have in our base > install; it is fine to keep it out of the cloud image (as today), but it is > genuinely useful for both desktops and servers, and with a low cost. I support

Re: Proposal: plocate as standard for bookworm

2021-02-06 Thread Paul Wise
On Sun, Feb 7, 2021 at 12:05 AM Steinar H. Gunderson wrote: > It's a pretty thin use-case, but someone could have scripts that call mlocate > explicitly (not through the locate symlink). Or have something that is > capable of reading mlocate's database. Or wish to have both to benchmark > against

Re: strange BD-Uninstallable

2021-01-26 Thread Paul Wise
On Tue, Jan 26, 2021 at 2:50 PM Russell Coker wrote: > libselinux isn't being built on ia64 Sounds like a question for the debian-ia64 list rather than debian-devel. > it says "BD-Uninstallable (Extra-Depends: python3-all-dev (>= 3.8.6-1))". IIRC this means the buildd admin or wanna-build

Re: Making Debian available

2021-01-18 Thread Paul Wise
On Mon, Jan 18, 2021 at 6:27 PM Marc Haber wrote: > Imagine the catastrophal message we're sending by "here is our > official image, but that one is unlikely to work on your laptop, > better use this here." As this thread shows the current situation wrt hardware and software freedom is pretty

Re: Making Debian available

2021-01-16 Thread Paul Wise
On Sat, Jan 16, 2021 at 11:52 PM Russell Stuart wrote: > Testing doesn't produce netinst with non-free firmware There are both daily and weekly testing netinsts with firmware: https://cdimage.debian.org/cdimage/unofficial/non-free/cd-including-firmware/daily-builds/sid_d-i/current/amd64/iso-cd/

Re: Disabling automatic upgrades on Sid by default?

2020-12-29 Thread Paul Wise
On Tue, 2020-12-29 at 21:27 +0100, Bálint Réczey wrote: > Also please note that unattended-upgrades does not perform upgrades > which include removals. It does do autoremovals when things no longer depend on packages though. -- bye, pabs https://wiki.debian.org/PaulWise signature.asc

Re: Disabling automatic upgrades on Sid by default?

2020-12-27 Thread Paul Wise
On Sun, Dec 27, 2020 at 10:58 PM Lyndon Brown wrote: > The problem with using testing as a rolling distro Your mail reminded me about Constantly Usable Testing: https://cut.debian.net/ > Using testing and manually pulling in select upgrades from unstable in > such situations addresses that

Re: Disabling automatic upgrades on Sid by default?

2020-12-27 Thread Paul Wise
On Sun, Dec 27, 2020 at 11:04 AM Devops PK Carlisle LLC wrote: > If I know that, for instance, a kernel update will break a wifi dongle > driver or NVIDIA driver, either I must not use automatic updates at all > and I must remember which packages I don't want to update and manually > exclude

Re: Disabling automatic upgrades on Sid by default?

2020-12-27 Thread Paul Wise
On Sun, 2020-12-27 at 16:04 -0700, Sean Whitton wrote: > I'm pretty sure it's not default because the security team do not > consider unattended-upgrades sufficiently robust.  I'm sorry for not > going ahead and verifying but I thought it should be mentioned. Looks like you are correct, it is

Re: Disabling automatic upgrades on Sid by default?

2020-12-27 Thread Paul Wise
M. Zhou wrote: > I don't quite understand the meaning of automatic upgrades on a rolling > system such as Debian/Sid. According to my own experience, such > automatic upgrades could be dangerous. I have been automatically upgrading Debian testing 4 times daily using the unattended-upgrades

Re: Package dependency versions and consistency

2020-12-24 Thread Paul Wise
On Tue, Dec 22, 2020 at 10:24 PM Adrian Bunk wrote: > To me it always feels as if these ecosystems are not interested in > providing any support for that. NPM at least provides security advisories. I used to try syncing those to the Debian sectracker but don't bother now as it is too much work

Re: Do I need a sponsor to submit a new package?

2020-12-24 Thread Paul Wise
On Tue, Dec 22, 2020 at 6:04 PM Devops PK Carlisle LLC wrote: > Is there a next step that I need to take? Thanks! Next up you should create the packaging and once that is done, submit a request for sponsor bug. Then keep maintaining the package both before and after the package gets sponsored.

Re: NHXHide Package Development and Publishing

2020-12-24 Thread Paul Wise
On Tue, Dec 22, 2020 at 10:04 AM wrote: > I would like to get help from any of the professional members here to develop > a package for a tool I developed, NHXHide, and publish it to the Debian > repository. If you would like to do the work yourself, please read through this page and the

Re: glibc 2.32 before bullseye?

2020-12-18 Thread Paul Wise
On Fri, Dec 18, 2020 at 4:46 AM Nick Black wrote: > I was wondering whether glibc ... These seem like questions for the glibc maintainers, probably via a bug report. -- bye, pabs https://wiki.debian.org/PaulWise

Re: apt ignoring check-valid-until flag

2020-12-17 Thread Paul Wise
On Thu, Dec 17, 2020 at 10:03 AM Ansgar wrote: > (Bonus points if this keeps the original signature if possible.) Two separate signatures is possible for Release+Release.gpg, just rename the latter to .old, but what can you do for InRelease? Is it possible to have multiple signatures in one

Re: apt ignoring check-valid-until flag

2020-12-16 Thread Paul Wise
On Thu, 2020-12-17 at 00:03 +0100, Samuel Thibault wrote: > Indeed, but one can use trusted=yes That disables the OpenPGP checks completely rather than just ignoring that the OpenPGP key is expired, so it is fairly unsafe and definitely should be at minimum combined with TLS, which snapshot

Re: apt ignoring check-valid-until flag

2020-12-16 Thread Paul Wise
On Wed, Dec 16, 2020 at 6:06 PM John Paul Adrian Glaubitz wrote: > Does anyone have any idea what I'm missing? It seems to be saying that the 2019 ports archive signing key used for signing the snapshot URLs is expired, I don't think check-valid-until ignores key expiry. I'm not sure if there is

Re: Release status of i386 for Bullseye and long term support for 3 years?

2020-12-14 Thread Paul Wise
On Mon, Dec 14, 2020 at 11:36 PM Adrian Bunk wrote: > A bigger worry for i386 would be the availability of microcode updates This is also a big problem for amd64, since only the newest generations of Intel processors get BIOS/UEFI and or microcode updates, so lots of amd64 users (including

Re: CentOS and Debian/Ubuntu release cycles

2020-12-10 Thread Paul Wise
On Thu, Dec 10, 2020 at 8:22 AM Adrien CLERC wrote: > Le 10/12/2020 à 08:05, Marco d'Itri a écrit : > > Cool narrative, but the reality is a bit more complex than that. > > Fibre Channel users need very specific kernels or else the hardware > > vendors will refuse support (and their vendor drivers

Re: CentOS and Debian/Ubuntu release cycles

2020-12-09 Thread Paul Wise
On Wed, Dec 9, 2020 at 7:17 PM Marc Haber wrote: > Ubuntu never cared about Debian. That is probably not entirely correct, there are parts of the Ubuntu community, including Canonical employees, that definitely care about Debian, to the point that they are Debian members and fairly core

Re: [External] Re: Intel SOF audio firmware packaging

2020-12-08 Thread Paul Wise
On Tue, Dec 8, 2020 at 3:04 PM Mark Pearson wrote: > From my point of view (admittedly limited) there is limited benefit to > building your own unsigned firmware as it won't load on our systems. According the discussion I had with Lenovo and Intel folks, Intel Baytrail/Cherrytrail/Broadwell

<    1   2   3   4   5   6   7   8   9   10   >