Re: Bits from DPL

Le Tue, Jan 07, 2025 at 10:46:25AM +1100, Stuart Prescott a écrit : > It's great to see more packages being maintained on salsa. I've certainly > noticed that it is making working on packages much simpler. > > > > In my campaign, I stated [os1] that I aimed to reduce the number of > > > packages m

Re: Remove ancient uploads from experimental (and later unstable)

Le Sun, Dec 29, 2024 at 01:08:49PM +0100, Ansgar 🐱 a écrit : > Hi, > > I'm wondering how we can clean up suites like experimental and > unstable. They tend to slowly accumulate cruft that nobody cleans up, > including no longer installable packages. > > As a very simple start, I would like to rem

Re: criteria for acceptable languages for central QA tools in Debian (was: Re: coordination between lintian/piuparts/adequate)

Le Thu, Dec 12, 2024 at 02:36:51PM +, Jonathan Dowland a écrit : > The "Perl Problem" is a wider issue we should explore in much more depth. > I'm personally a little surprised if it's true that younger people are > unprepared to take a stab at hacking Perl. But since that's the case, we > have

Re: The advantages of splitting /bin and /usr/bin, and /sbin and /usr/sbin outweigh the disadvantages

Le Sun, Dec 01, 2024 at 08:40:15PM -0600, G. Branden Robinson a écrit : > https://css.csail.mit.edu/6.824/2014/papers/plan9.pdf > > > Of course, these advantages have become impossible now with the > > merging of directories > > No. Not impossible. One simply has to overcome inertia and the > n

consolation 0.0.10 released

Dear developers, I have released consolation 0.0.10 to be in sync with libinput 1.26. consolation is a program to use the mouse under the linux console that relies on the libinput library. (It is an alternative to GPM) So if you still use the linux console, you might be interested. Cheers, -- B

Re: [Summary]: Supporting alternative zlib implementations

Le Fri, Nov 22, 2024 at 12:56:17PM +, Simon McVittie a écrit : > Switching from IJG > libjpeg to libjpeg-turbo, both went through similar processes. Independently of the merit of your proposal, this is not historically correct. Cheers, -- Bill.

Re: RFC: "Recommended bloat", and how to possibly fix ito

Le Tue, Nov 05, 2024 at 05:35:59PM -0600, Aaron Rainbolt a écrit : > Hello, and thanks for your time. > > I've been a Debian user and contributor for a while, and have noticed a > rather frustrating issue that I'm interested in potentially > contributing code to fix. The issue is what I call "Reco

Re: lintian.debian.org off ?

Le Wed, Sep 04, 2024 at 08:21:04AM +0200, Lucas Nussbaum a écrit : > After lintian.debian.org went unmaintained (beginning of 2022) and it > was clear noone was going to adopt it, I worked on a UDD-backed > replacement (in July 2022, see > https://lists.debian.org/debian-qa/2022/07/msg1.html an

universal zcat ?

Dear Debian developpers, I ma looking for a wrapper around the various compressions programs (gzip, bzip2, xz, zstd, etc.) that would provide the same interface as zcat but would automatically pick the right decompressor. I could easily write one but it probably already exists. Cheers, -- Bill.

Re: changing existing entries in debian/changelog

Le Fri, May 24, 2024 at 09:30:44AM +0200, Bastian Venthur a écrit : > Hi, > > I'm having troubles finding the relevant parts in the developers reference. > I've uploaded a version to experimental and later found out that this > version fixes several bugs. > > Can I rewrite existing changelog entr

Re: finally end single-person maintainership

On Tue, May 21, 2024 at 12:59:52AM +0200, Bernd Zeimetz wrote: > On Thu, 2024-04-11 at 22:52 +0000, Bill Allombert wrote: > > > > When a change leads to a RC bug a month or three after having be > > part of a package, fixing the problem falls on the maintainer and not >

Re: Salsa - best thing in Debian in recent years? (Re: finally end single-person maintainership)

On Sun, May 19, 2024 at 08:38:58PM -0700, Don Armstrong wrote: > On Sun, 19 May 2024, Bill Allombert wrote: > > Also debbugs is a special case: > > The debbugs Debian package (as opposed to the debbugs software) have never > > been > > really maintained. I am actually o

Re: Salsa - best thing in Debian in recent years? (Re: finally end single-person maintainership)

> in-depth arguments. This is my attempt to have you think about Salsa > in a new light: > > On Tue, 9 Apr 2024 at 11:41, Bill Allombert wrote: > > Having a repository on salsa or even "packaging team" does not prevent > > a lack of maintainer, so this is not rele

Re: Re: Make /tmp/ a tmpfs and cleanup /var/tmp/ on a timer by default [was: Re: systemd: tmpfiles.d not cleaning /var/tmp by default]

Le Mon, May 06, 2024 at 11:15:35AM +0100, Barak A. Pearlmutter a écrit : > > We have two separate issues here: > > > a/ /tmp-on-tmpfs Note that /tmp-on-tmpfs and cleanup-tmp-at-boot are not equivalent. With cleanup-tmp-at-boot, if your system crashes, you can still backup /tmp before rebooting.

Re: Any volunteers for lintian co-maintenance?

Le Fri, May 10, 2024 at 10:47:29PM +0500, Andrey Rakhmatullin a écrit : > - The most paradoxical thing is the recently "discovered" combination of > "old lintian falsely reports a problem in certain packages", "lintian > runs as a part of the package acceptance process and some problems are >

Re: Solving a file conflict between package "nq" / "fq"

Le Mon, May 06, 2024 at 11:09:14PM +0200, Preuße, Hilmar a écrit : > Hi all, > > during the preparation of a new version of package "nq" (via NMU) it was > found that there exists a file conflict with package "fq" (#1005961), which > was incorrectly solved in the past. For now I unarchived and reo

Re: new upstream version fails older tests of rdepends packages

Le Wed, May 08, 2024 at 08:41:47PM +0200, Paul Gevers a écrit : > Hi, > > On 08-05-2024 6:06 p.m., Bill Allombert wrote: > > Agreed, but gap does not actually breaks anything, it is just the tests > > in testing that are broken. So I can do that but that seems a bit >

Re: new upstream version fails older tests of rdepends packages

On Wed, May 08, 2024 at 03:21:12PM +, Graham Inggs wrote: > Hi Bill > > On Wed, 8 May 2024 at 13:58, Bill Allombert wrote: > > The problem is that all the debs in testing and sid are correct, it is the > > autopkgtest in > > testing which are wrong (they

Re: new upstream version fails older tests of rdepends packages

Le Sat, May 04, 2024 at 02:32:22PM +0200, Paul Gevers a écrit : > Hi, > > On 04-05-2024 11:39 a.m., Jerome BENOIT wrote: > > What would be the best way to unblock the migration of gap and gap-io ? > > If gap isn't going to change (which might be the easiest solution), then > file bugs and fix tho

Re: finally end single-person maintainership

Le Tue, Apr 09, 2024 at 12:18:02AM +0200, Johannes Schauer Marin Rodrigues a écrit : > we need both. Domain specific knowledge is clearly very important and I'm not > trying to argue against it. But doing packaging in a way such that it becomes > easy for others to contribute is *also* every impor

Re: finally end single-person maintainership

On Mon, Apr 08, 2024 at 11:00:52PM +0100, Luca Boccassi wrote: > ...right up until the point where that "bus factor of 1" moves > on/changes priorities/changes job/etc and the package is abandoned. > Fortunately that never happens, though! Having a repository on salsa or even "packaging team" does

Re: finally end single-person maintainership

Le Sun, Apr 07, 2024 at 11:37:47PM +0200, Gioele Barabucci a écrit : > On 07/04/24 23:11, Bill Allombert wrote: > > > What is your opinion about pushing logtool to Salsa? > > > > Not speaking for logtool obviously, but maintaining simple packages on > > salsa i

Re: finally end single-person maintainership

On Sun, Apr 07, 2024 at 04:04:18PM +0200, Andreas Tille wrote: > Hi Wouter, > > Am Sun, Apr 07, 2024 at 03:31:43PM +0200 schrieb Wouter Verhelst: > > [Feel free to quote any part of this email which I wrote outside of this > > mailinglist] > > OK, moving the discussion to debian-devel where it sh

Re: Another take on package relationship substvars

Le Thu, Feb 22, 2024 at 08:52:36PM +0100, IOhannes m zmölnig a écrit : > Am 22. Februar 2024 20:25:32 MEZ schrieb Boyuan Yang : > >在 2024-02-22星期四的 19:32 +0100，Niels Thykier写道： > >> I think our package helper tooling should just automatically aggregate > >> all provided substvars of the format ${*

Re: usrmerge breaks POSIX

Le Thu, Feb 15, 2024 at 05:18:43PM +, Thorsten Glaser a écrit : > Russ Allbery dixit: > > >3. Something else that I don't yet understand happened that caused pkexec > > to detect the shell as /usr/bin/mksh instead of /bin/mksh. I'm not > > What sets $SHELL for the reporter’s case? Fix that

Re: 64-bit time_t transition in progress

On Fri, Feb 02, 2024 at 08:23:44PM +0100, Bill Allombert wrote: > > > Relying on dpkg-buildflags alone cannot be sufficient. > > > > I don't see any practical reason why not. > > Because packages are not required to use dpkg-buildflags. Also currently, there

Re: 64-bit time_t transition in progress

Le Sun, Feb 04, 2024 at 11:05:46PM -0800, Steve Langasek a écrit : > In my view, it's fine then to upload libfoo2 to unstable without the t64 > suffix as ABI compatibility with experimental is not really required. In > fact, none of the t64 binaries currently being uploaded to experimental have >

Re: Changes to abi=+time64 behavior (was Re: 64-bit time_t transition in progress)

On Fri, Feb 09, 2024 at 05:36:53PM +0100, Ansgar wrote: > Hi, > > On Fri, 2024-02-09 at 15:24 +0000, Bill Allombert wrote: > > when introducing a new soname (no just a new package name), then one > > should move to time64 even on i386 ? > > If you know all consumers o

Re: Changes to abi=+time64 behavior (was Re: 64-bit time_t transition in progress)

Le Fri, Feb 09, 2024 at 10:20:40AM +, Simon McVittie a écrit : > On Fri, 09 Feb 2024 at 05:03:23 +0100, Guillem Jover wrote: > > if the maintainer > > has requested it explicitly via DEB_BUILD_OPTIONS=abi=+time64, then > > it should enable it also on i386 (changed behavior). > > > > The reason

Re: 64-bit time_t transition in progress

Le Fri, Feb 02, 2024 at 08:23:42PM +0100, Bill Allombert a écrit : > > I don't see any practical reason why not. > > Because packages are not required to use dpkg-buildflags. And more generally, does this scheme will require to build third-party packages on 32bit Debian sys

Re: Transparency into private keys of Debian

On Mon, Feb 05, 2024 at 08:49:09AM +0100, Simon Josefsson wrote: > Bill Allombert writes: > > > Le Thu, Feb 01, 2024 at 10:38:03AM +0100, Simon Josefsson a écrit : > >> Hi > >> > >> I'm exploring how to defend against an attacker who can create val

Re: 64-bit time_t transition in progress

On Fri, Feb 02, 2024 at 10:58:51AM -0800, Steve Langasek wrote: > Well, if this suggestion had come 6 months ago when this plan was laid out > on debian-devel, I think it would have been worth exploring. > > Though I would have still expected a large number of false-positives, > because there woul

Re: 64-bit time_t transition in progress

On Fri, Feb 02, 2024 at 08:21:57AM -0800, Steve Langasek wrote: > Dear developers, > > As mentioned previously on debian-devel[6], we know that there are a number > of library packages being included in this transition which we have not > proven have an ABI affected by 64-bit time_t. This is beca

Re: Transparency into private keys of Debian

Le Thu, Feb 01, 2024 at 10:38:03AM +0100, Simon Josefsson a écrit : > Hi > > I'm exploring how to defend against an attacker who can create valid > signatures for cryptographic private keys (e.g., PGP) that users need to > trust when using an operating system such as Debian. A signature like > th

Re: Changing supermajority requirements

Le Wed, Nov 22, 2023 at 11:00:57AM +0100, Ansgar a écrit : > Hi, > > the Constitution has several supermajority requirements that seem > excessive to me: > > Constitution changes: > > +--- > | 4.1.2: Amend this constitution, provided they agree with a 3:1 majority. > | [...] > | 5.1.5.3: A Found

Re: Bug#885698: What licenses should be included in /usr/share/common-licenses?

On Tue, Sep 12, 2023 at 10:49:02AM -0700, Russ Allbery wrote: > To take an example that I've been trying to get rid of for over a decade, > many of the /usr/share/common-licenses/BSD references currently in the > archive are incorrect. There are a few cases where the code is literally > copyrighte

Re: Efforts to Improve Virtual Console

Le Fri, Aug 18, 2023 at 12:22:13AM -0700, Aryeh Hillman a écrit : > I am looking to either find or help create a better virtual console > experience on linux, especially in Debian. I am talking about tty1, tty2, > tty3, ... typically mapped via CTRL-ALT-F1. > > *Help with the following would be mu

Re: Bug#885698: What licenses should be included in /usr/share/common-licenses?

On Sun, Sep 10, 2023 at 09:00:22AM -0700, Russ Allbery wrote: > Jonas Smedegaard writes: > > Quoting Hideki Yamane (2023-09-10 11:00:07) > > >> Hmm, how about providing license-common package and that depends on > >> "license-common-list", and ISO image provides both, then? It would be > >> no

Re: Reducing allowed Vcs for packaging?

On Sun, Feb 26, 2023 at 02:24:26PM +0100, Bastian Germann wrote: > Hi! > > During the last weeks I had a look at the Vcs situation in Debian. Currently, > there are eight possible systems allowed and one might specify several of > them for > one package. No package makes use of several Vcs refere

Re: Automatic trimming of changelogs in binary packages

Le Tue, Sep 06, 2022 at 07:13:30AM +0200, Gioele Barabucci a écrit : > On 18/08/22 21:18, Gioele Barabucci wrote: > > Does anybody have objective objections against activating automatic > > changelog trimming in binary packages? > > Hi, > > a couple of weeks since the initial email (thanks everyb

Re: use of Recommends by vlc to force users to use pipewire

On Mon, May 16, 2022 at 12:56:03AM +0200, Sebastian Ramacher wrote: > On 2022-05-16 00:40:25 +0200, Vincent Lefevre wrote: > > The vlc package now uses a Recommends (vlc-plugin-pipewire) to force > > users to use pipewire instead of pulseaudio (which broke the use of > > VLC, but also apparently og

Re: Firmware: Scope of non-free-firmware

On Wed, May 11, 2022 at 07:38:18PM +0200, Adam Borowski wrote: > I'd say that closed encrypted signed firmware that you need to load on > every boot is strictly more free than the same firmware burned into ROM. Not necessarily. Firmware-as-software and firmware-as-hardware are covered by different

Re: popularity-contest: support for XB-Popcon-Reports: no

On Thu, May 05, 2022 at 07:15:06AM +0200, Tollef Fog Heen wrote: > ]] Bill Allombert > > > The rationale is that the only info really leaked is the package name, > > so it only make sense to hide a package if every system that have it > > installed are also hiding it, so

popularity-contest: support for XB-Popcon-Reports: no

Dear Debian developers, I plan to add support for 'XB-Popcon-Reports: no' to popularity-contest. This allows to build packages with private names that will not be reported to popcon, by adding 'XB-Popcon-Reports: no' to debian/control. This must not used by packages in the debian archive, however

Re: duplicate popularity-contest ID

On Tue, Aug 06, 2019 at 02:01:16PM -0400, Sam Hartman wrote: > >>>>> "Bill" == Bill Allombert writes: > > Bill> This is potentially an excellent idea! > > Bill> Does not /etc/machine-id suffer of exactly the same issue as > Bil

Re: do packages depend on lexical order or {daily,weekly,monthly} cron jobs?

On Tue, Aug 06, 2019 at 05:19:14PM +0200, Philipp Kern wrote: > On 2019-08-06 13:43, Bill Allombert wrote: > > On Mon, Aug 05, 2019 at 10:29:41PM +0200, Philipp Kern wrote: > > > And finally, the load spikes: Upthread it was mentioned that > > > RandomizedDelaySec exist

Re: duplicate popularity-contest ID

On Tue, Aug 06, 2019 at 12:08:13AM +0200, Marco d'Itri wrote: > On Aug 05, Bill Allombert wrote: > > > Each Debian popularity-contest submitter is supposed to have > > a different random 128bit popcon ID. > > However, the popularity-constest server <https://popco

Re: do packages depend on lexical order or {daily,weekly,monthly} cron jobs?

On Mon, Aug 05, 2019 at 10:29:41PM +0200, Philipp Kern wrote: > And finally, the load spikes: Upthread it was mentioned that > RandomizedDelaySec exists. Generally this should be sufficient to even out > such effects. I understand that there is a case where you run a lot of > unrelated VMs that you

Re: duplicate popularity-contest ID

On Mon, Aug 05, 2019 at 08:46:15AM -0700, Russ Allbery wrote: > Bill Allombert writes: > > > Each Debian popularity-contest submitter is supposed to have a different > > random 128bit popcon ID. However, the popularity-constest server > > <https://popcon.de

duplicate popularity-contest ID

Dear Debian developers, Each Debian popularity-contest submitter is supposed to have a different random 128bit popcon ID. However, the popularity-constest server receives a lot of submissions with identical popcon ID, which cause them to be treated as a single submissio

Re: Consensus Call: Do We Want to Require or Recommend DH; comments by 2019-06-16

On Sat, May 25, 2019 at 01:26:47PM -0400, Sam Hartman wrote: > > Hi. Almost two weeks ago [1] I started a discussion on whether we > wanted to increase the strength of our recommendation of the dh > sequencer from debhelper. > This message is a consensus call summarizing my reading of the > discu

Re: Debian Policy 4.1.4.0 released

On Tue, Jul 03, 2018 at 01:35:49PM +0200, Andreas Tille wrote: > Not really, I do not want to use README.source or something like this. > I have a *personal* policy: I will not sponsor any package if there is > no code I could run that recreates the source tarball. May be I'm to > strict and the

Re: Bug#515856: Debian Policy 4.1.4.0 released

On Tue, Jul 03, 2018 at 03:43:19PM +0200, Andreas Tille wrote: > On Tue, Jul 03, 2018 at 12:20:28PM +0200, Bill Allombert wrote: > > On Mon, Jul 02, 2018 at 04:40:43PM -0700, Russ Allbery wrote: > > > > > > This is one of the cases that now has a better solution and mor

Re: Bug#515856: Debian Policy 4.1.4.0 released

On Mon, Jul 02, 2018 at 04:40:43PM -0700, Russ Allbery wrote: > Jonathan Nieder writes: > > > Context: I have run into a few packages that used the +dfsg convention > > without documenting what they removed from the tarball and I was not > > able to locally update them. :( > > This is one of the

Re: alioth deprecation - next steps

On Tue, Apr 17, 2018 at 10:31:58PM +0100, James Clarke wrote: > Even the wiki page you linked there states that GitLab "allows extra > files to be attached to the tag". But it does not say how. Research shows that while gitlab has plan to implement the feature, it is not actually implemented yet.

Re: alioth deprecation - next steps

On Tue, Apr 17, 2018 at 11:10:56PM +0200, Alexander Wirt wrote: > On Tue, 17 Apr 2018, Bill Allombert wrote: > > > On Tue, Apr 17, 2018 at 01:00:56PM +0200, Alexander Wirt wrote: > > > Hi, > > > > > > as you should be aware, alioth.debian.org will be deco

Re: alioth deprecation - next steps

On Tue, Apr 17, 2018 at 01:00:56PM +0200, Alexander Wirt wrote: > Hi, > > as you should be aware, alioth.debian.org will be decommissioned with > the EOL of wheezy, which is at the end of May. The replacement for > the main part of alioth, git, is alive and out of beta, you know it > as salsa.debi

Re: Bug#515856: Debian Policy 4.1.4.0 released

On Wed, Apr 11, 2018 at 03:49:17PM +0100, Ian Jackson wrote: > Bill Allombert writes ("Re: Bug#515856: Debian Policy 4.1.4.0 released"): > > I wonder, maybe uscan could support debian/get-orig-source as a last > > resort ? > > Only if you pass --trust-source o

Re: Bug#515856: Debian Policy 4.1.4.0 released

On Wed, Apr 11, 2018 at 03:18:32PM +0200, Andreas Tille wrote: > On Sun, Apr 08, 2018 at 10:58:53AM +0200, Ole Streicher wrote: > > > > > > Imho Sean's last mail sums it up pretty well > > > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=515856#94 > > > > I have read this, but it does not convi

Re: Bug#886219: lintian should be less pedantic about latest policy version

On Wed, Jan 03, 2018 at 02:24:46PM +, Sean Whitton wrote: > control: severity -1 normal > > Thanks for summarising exactly when these tags are triggered, Mattia. > > Let me first say exactly what change I'd recommend: > > - out-of-date-standards-version should be I: or P: instead of W: > - a

Re: Bug#798476: Bug#870788: Extract recent uploaders from d/changelog

On Sat, Aug 05, 2017 at 07:00:16AM -0700, Sean Whitton wrote: > Hello, > > On Sat, Aug 05 2017, Adrian Bunk wrote: > > > I assume you are thinking of parsing the [ name ] syntax used by many > > teams. > > Yes. > > > Note that a prerequisite for such debian/changelog parsing would be > > that p

Re: Bug#798476: Returning to the requirement that Uploaders: contain humans

On Wed, Aug 02, 2017 at 04:22:41PM -0700, Russ Allbery wrote: > Bill Allombert writes: > > On Wed, Aug 02, 2017 at 05:48:15PM -0400, Sean Whitton wrote: > > >> I've also included a purely informative change which emphasises that > >> packages that are tea

Re: Bug#798476: Returning to the requirement that Uploaders: contain humans

On Wed, Aug 02, 2017 at 05:48:15PM -0400, Sean Whitton wrote: > Hello, > > Here is an updated diff for this bug, against the docbook version of > the policy manual. > > I've also included a purely informative change which emphasises that > packages that are team maintained in name only should be

popularity-contest reachs 200000 submitters!

Dear developpers, With the release of stretch, popularity-contest has reached 20 submitters, see . Some stats: Reports by architectures: amd64 submissions: 160428 i386 submissions: 37979 others : 1766 Reports by versions of popcon: 1.46 (l

Bug#833684: ITP: consolation -- consolation linux console pointer support

Package: wnpp Severity: wishlist Owner: Bill Allombert * Package name: consolation Version : 0.0.1 Upstream Author : Bill Allombert * URL : https://alioth.debian.org/projects/consolation/ * License : GPL2+/Expat Programming Lang: C Description

Re: consolation -- an alternative to gpm

On Sun, Aug 07, 2016 at 01:22:16PM +0800, Paul Wise wrote: > On Sun, Aug 7, 2016 at 6:57 AM, Bill Allombert wrote: > > > I like to announce consolation, a gpm replacement. > > Nice :) > > > For the time being, consolation homepage is: > > <https://al

consolation -- an alternative to gpm

Dear developers, I like to announce consolation, a gpm replacement. Consolation is a daemon that provides pointer support to the Linux console for copy/pasting text. Consolation is based on the libinput library and supports all pointer devices (mice, touchpads, touchscreens, etc.) and settings su

Debian Policy 3.9.7.0 released

Dear developers, We have just released Debian Policy 3.9.7.0 to fix a FTBFS. The following is the upgrading checklist. Please read the full Debian Policy document for detail. 10.5 Symbolic links must not traverse above the root directory. 9.2.2 32bit UIDs in the ra

Re: Debian Policy 3.9.6.0 released

On Wed, Sep 17, 2014 at 09:52:31PM +, Thorsten Glaser wrote: > Bill Allombert dixit: > > > 10.1 > > Binaries must not be statically linked with the GNU C library, > > see policy for exceptions. > > It says there that exceptions *may* be

Re: Bug#758231: rsyslog: is priority important, depends on packages with priority extra

On Fri, Aug 15, 2014 at 06:31:39PM +0200, Michael Biebl wrote: > Am 15.08.2014 18:10, schrieb Michael Biebl: > > Am 15.08.2014 17:47, schrieb Gerrit Pape: > >> Severity: serious > >> Justification: Policy 2.5 > > [..] > > > That this rule is violated in hundreds of cases [1] clearly shows that >

Re: [CTTE #717076] Default libjpeg implementation in Debian

On Thu, Jul 31, 2014 at 07:24:29PM -0700, Don Armstrong wrote: > The technical committee was asked in #717076 to decide whether > libjpeg8 or libjpeg-turbo would be the default libjpeg implementation. > The decision is below: Dear CTTE, I am concerned that the rationale for this decision contains

GPM and clickpad devices

Dear developpers, Is there other people still using gpm intensively (the console mouse selection system) ? The Debian package is unmaintained and the upstream project is not very active either. GPM does not support 'clickpads' found in newer laptop (there is no button available for pasting). Th

Re: First autoremovals happen in about 8 days

On Tue, Oct 08, 2013 at 07:58:03AM +0100, Neil Williams wrote: > rc-alert has existed for quite some time and it gets the alert in > *ahead* of package removal. It alerts users to the real problem - the > RC BUG! Did you try to run rc-alert recently ? The output is totally overwhelming for somethi

Re: First autoremovals happen in about 8 days

On Sun, Oct 06, 2013 at 09:52:17AM +0200, Niels Thykier wrote: > Hi, > > This is a friendly reminder. If you are listed below, then the listed > packages of yours will be automatically removed from testing within 15 > days. The "first batch" of automatic removals will happen in about 8 > days. >

ports and multiarch

On Thu, Sep 19, 2013 at 10:38:29AM +0200, Niels Thykier wrote: > We also got a number of people interested in architectures not currently > in unstable. These are: > > alpha: Bill MacAllister (!DD), Kieron Gillespie (!DD) > arm64: Wookey (DD) > parisc/hppa: Helge Deller (!DD) > ppc64: Ste

Re: [Popcon-developers] Encrypted popcon submissions

On Sun, Aug 04, 2013 at 03:54:25PM +0200, Bill Allombert wrote: > Well I have fixed this problem in popcon 1.59 by using a temporary GPGHOME > that I remove afterward. > > If no more problem are found, I will release 1.60 in September with > ENCRYPT=maybe > by default (i.e.

Re: [Popcon-developers] Encrypted popcon submissions

On Wed, Jul 10, 2013 at 04:14:02PM +0200, Bill Allombert wrote: > On Tue, Jul 02, 2013 at 11:27:12PM +0200, Bill Allombert wrote: > > On Fri, Jun 21, 2013 at 05:08:08PM +0200, Bill Allombert wrote: > > > Dear Debian people, > > > > > > I upload popularit

Re: [Popcon-developers] Encrypted popcon submissions

On Fri, Jul 12, 2013 at 10:30:49PM +, brian m. carlson wrote: > On Thu, Jul 11, 2013 at 03:33:21PM +0200, Bill Allombert wrote: > > GPG=/usr/bin/gpg > > if [ "$ENCRYPT" = "yes" ] && [ -x "$GPG" ]; then > > POPCONGPG="$POPC

Re: [Popcon-developers] Encrypted popcon submissions

On Fri, Jul 12, 2013 at 10:30:49PM +, brian m. carlson wrote: > On Thu, Jul 11, 2013 at 03:33:21PM +0200, Bill Allombert wrote: > > GPG=/usr/bin/gpg > > if [ "$ENCRYPT" = "yes" ] && [ -x "$GPG" ]; then > > POPCONGPG="$POPC

Re: [Popcon-developers] Encrypted popcon submissions

On Wed, Jul 10, 2013 at 11:36:02PM +0200, Daniel Leidert wrote: > Am Mittwoch, den 10.07.2013, 16:14 +0200 schrieb Bill Allombert: > > On Tue, Jul 02, 2013 at 11:27:12PM +0200, Bill Allombert wrote: > > > On Fri, Jun 21, 2013 at 05:08:08PM +0200, Bill Allombert wrote: > >

Re: [Popcon-developers] Encrypted popcon submissions

On Tue, Jul 02, 2013 at 11:27:12PM +0200, Bill Allombert wrote: > On Fri, Jun 21, 2013 at 05:08:08PM +0200, Bill Allombert wrote: > > Dear Debian people, > > > > I upload popularity-contest 1.58 which add support for encrypted > > submissions. > > For this relea

Re: [Popcon-developers] Encrypted popcon submissions

On Fri, Jun 21, 2013 at 05:08:08PM +0200, Bill Allombert wrote: > Dear Debian people, > > I upload popularity-contest 1.58 which add support for encrypted submissions. > For this release it is not activated by default. > Please help test this feature by adding > ENCRY

Encrypted popcon submissions

Dear Debian people, I upload popularity-contest 1.58 which add support for encrypted submissions. For this release it is not activated by default. Please help test this feature by adding ENCRYPT="yes" to /etc/popularity-contest.conf to activate it. Once this feature has seen proper testing, we w

Re: [Popcon-developers] encrypted popcon submissions

On Sat, May 11, 2013 at 11:43:25AM +0200, Bill Allombert wrote: > > Why do you think this is too much for popov to handle? > > I did some benchmark. Currently popov CPU has about 20% of a real CPU. > Currently processing the popcon data takes between 6h30 and 8h30. > At this r

Re: [Popcon-developers] encrypted popcon submissions

On Fri, May 10, 2013 at 09:53:25PM +0100, Ian Jackson wrote: > Bill Allombert writes ("encrypted popcon submissions"): > > The drawback is the computing cost on the server. Currently we are > > processing about 25000 report each days, which would require about 2 > &

Re: [Popcon-developers] encrypted popcon submissions

On Fri, May 10, 2013 at 10:44:25PM +0200, Peter Palfrader wrote: > On Fri, 10 May 2013, Bill Allombert wrote: > > > I am considering activating encryption of popularity-contest submissions > > using public key cryptography to protect popcon submission while in transit. >

encrypted popcon submissions

Dear developers, I am considering activating encryption of popularity-contest submissions using public key cryptography to protect popcon submission while in transit. This means - The popularity-contest package will include a public key that will be used to encrypt report. - The popcon.debian.

Re: jpeg8 vs jpeg-turbo

On Sat, Apr 27, 2013 at 08:55:28AM +0200, Ondřej Surý wrote: > On Fri, Apr 26, 2013 at 11:50 PM, Bill Allombert > wrote: > > > > I think there are some misunderstanding about what offer libjpeg8: > > > > 1) by default, libjpeg8 creates JFIF files which are

Re: jpeg8 vs jpeg-turbo

On Wed, Apr 24, 2013 at 10:10:42PM +0800, Aron Xu wrote: > On Wed, Apr 24, 2013 at 9:19 PM, Bill Allombert > wrote: > > > > As IJG libjpeg maintainer, my plan is to move to libjpeg9 which has more > > feature. > > > > From a user's prospective, I don&#x

Re: jpeg8 vs jpeg-turbo

On Wed, Apr 24, 2013 at 11:23:04AM +0200, Ondřej Surý wrote: > Hi Bill and Debian Developers, > > My proposal is: > A. Add libjpeg-turbo to Debian archive (that's easy) > B. Add required provides/alternatives for libjpeg62-dev and > libjpeg8-dev (where API/ABI match) > C. Decide which package shou

Status of circular dependencies in Sid

Hello Debian developers, Today circular dependencies in unstable reached an all-time low, with only 36 circular dependencies. Here the lists of circular dependencies followed by the list of packages listed by maintainers. This list is also available at

amd64 most popular architecture according to popcon (all submissions)

Dear Debian developers, Today, amd64 is the architecture with the greatest number of popcon submissions by a narrow margin: When restricted to submissions from squeeze users, amd64 has 51% of all submissions and i386 47%. Cheers, -- Bill. Imagine a large

amd64 most popular architecture for squeeze today according to popcon

Dear Debian developers, Today, amd64 is the architecture with the greatest number of popcon submissions from squeeze users by a narrow margin: Over all submissions, amd64 has 45% of all submissions, and i386 53%, but we see that the number of i386 ins

Re: Increasing minimum 'i386' processor

On Wed, Nov 23, 2011 at 07:20:11PM +, Ben Hutchings wrote: > The i386 architecture was the first in Linux and in Debian, but we have > long since dropped support for the original i386-compatible processors > and now require a minimum of a 486-class processor. > > I think it is time to increase

popcon.debian.org improvement

Dear developers, I have updated popcon.debian.org to publish two dataset instead of one: 1) the statistics for all reports 2) the statistics for reports generated with the version of popcon in stable. See . Suggestions for the site layout are welcome. Cheers, -- Bill.

Re: Possible mass bug filling for package depending on "menu".

On Sun, Oct 30, 2011 at 01:14:59PM +0100, Frank lin Piat wrote: > > On Sun 30/10/11 11:31 , Daniel Baumann wrote:: > > > On 10/29/2011 08:49 PM, Frank lin Piat wrote: > >> I intend to submit a mass bug filling to ask packages maintainer to drop or > >> downgrade their dependency on "menu": > > > >

Re: alternative dependency ordering - with respect of packages in main

On Tue, Sep 20, 2011 at 01:12:37PM +0200, Gerfried Fuchs wrote: > Hi! > > Policy is clear on packages in main aren't allowed to depend on > packages outside of main. Now in a fair amount of cases this has been > worked around by having the package outside of main as alternative > depende

Re: Status of circulars dependencies in unstable

> Le samedi 03 septembre 2011 à 11:54 +0200, Bill Allombert a écrit : > > Today circular dependencies in unstable reached an all-time low, with > > only 40 circular dependencies. > > I think it should now be clear that there aren’t any such issues that > cannot be

Status of circulars dependencies in unstable

Dear developers, Today circular dependencies in unstable reached an all-time low, with only 40 circular dependencies. Here the current list: * acheck acheck-rules * aide aide-common * autodocktools mgltools-pmv * bochs bochs-wx * bootcd bootcd-i386 bootcd-ia64 (1 pre-depends) * ca-certificates-j

Re: Bug#621833: System users: removing them

On Tue, Apr 12, 2011 at 06:41:10PM +0100, Lars Wirzenius wrote: > (Cc to the relevant bug added.) > > On ma, 2011-04-11 at 14:05 +0100, Ian Jackson wrote: > > Lars Wirzenius writes ("Re: System users: removing them"): > > > Thus, I propose to change 9.2.2 "UID and GID classes", the paragraph on >

  1   2   3   4   5   >