Re: Lottery NEW queue (Re: Are libraries with bumped SONAME subject of inspection of ftpmaster or not

On Mon, Jan 24, 2022 at 08:48:28PM +0100, Paul Gevers wrote: > Hi Ted, > > I think this is the second time you write something like this, but for > dynamically linked libraries, the rebuild happens (by the Release Team, > (please use transition trackers for that) because we automatically track > t

Re: Back to the topic of changed binary named (Was: Lottery NEW queue (Re: Are libraries with bumped SONAME subject of inspection of ftpmaster or not))

On Mon, Jan 24, 2022 at 08:15:30AM +0100, Andreas Tille wrote: > Hi Paul and others, > > its surely an interesting topic how to avoid binary name changes and its > also interesting to discuss ABI changes and workarounds. > > However, my point was that I want to know what policy ftpmaster applies

Re: Lottery NEW queue (Re: Are libraries with bumped SONAME subject of inspection of ftpmaster or not

On Mon, Jan 24, 2022 at 10:20:48AM +0800, Paul Wise wrote: > On Sun, 2022-01-23 at 17:43 -0500, Theodore Y. Ts'o wrote: > > > That only works if there are no other packages depending on those > > shared libraries which are coming from other source packages. > >

Re: Lottery NEW queue (Re: Are libraries with bumped SONAME subject of inspection of ftpmaster or not

On Sat, Jan 22, 2022 at 08:58:37AM +0800, Paul Wise wrote: > > The other thing that's perhaps considering here is that unfortunately, > > there are some upstreams that are extremely irresponsible with library > > ABI backwards compatibility, where they bump the SONAME essentially at > > every relea

Re: /usr/bin/ld.so as a symbolic link for the dynamic loader

On Fri, Dec 03, 2021 at 05:59:17PM +0100, Florian Weimer wrote: > * Theodore Y. Ts'o: > > > * How does ld.so --preload *work*? > > The dynamic loader has an array of preloaded sonames, and it processes > them before loading the dependencies of the main program. This

Re: /usr/bin/ld.so as a symbolic link for the dynamic loader

On Fri, Dec 03, 2021 at 02:46:27PM +0100, Bastian Blank wrote: > On Fri, Dec 03, 2021 at 01:57:08PM +0100, Florian Weimer wrote: > > Right, thanks for providing a concrete example. A (somewhat) portable > > version would look like this: > > ld.so --preload '/usr/$LIB/libeatmydata.so.1.3.0' /bin/

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

On Sat, Dec 12, 2020 at 08:27:16PM +, Steve McIntyre wrote: > Stephan wrote: > >Am Sa, Dez 12, 2020 at 18:09:02 +0200 schrieb Adrian Bunk: > >>4. People who wrongly installed i386 on amd64-capable hardware. > > > >Well, some releases ago befor multi-arch I used to install i386 even on > >am64-

Re: CentOS and Debian/Ubuntu release cycles

On Fri, Dec 11, 2020 at 08:28:33AM +0100, pvane...@debian.org wrote: > > Working at a vendor supporting FC, for a time in the FC support > group, I can only agree with Marco. > > It's a whole different world. The compatibility matrix is king, > anything on there is tested to work, anything not 'i

Re: Lintian is complaining about udebs?

On Sat, Mar 21, 2020 at 09:09:41AM +0100, Sven Joachim wrote: > On 2020-03-21 00:39 -0400, Theodore Y. Ts'o wrote: > > > Just checking --- this looks like a Really Bad regression in Lintian > > 2.57.0, correct? > > Seems so, I can can confirm it with Lintian 2.5

Lintian is complaining about udebs?

Just checking --- this looks like a Really Bad regression in Lintian 2.57.0, correct? E: e2fsprogs-udeb udeb: debian-changelog-file-missing E: e2fsprogs buildinfo: field-too-long Installed-Build-Depends (5090 chars > 5000) E: e2fsprogs-udeb udeb: file-in-etc-not-marked-as-conffile etc/mke2fs.conf

Re: RFC: Replacing vim-tiny with nano in essential packages

On Mon, Mar 16, 2020 at 12:45:35PM +0100, Marco d'Itri wrote: > On Mar 16, Tomas Pospisek wrote: > > > > Agreed: this is a very good idea since I really think that every default > > > install must provide something enough vi-compatible. > > I'd disagree. vi is very newbie unfriendly. OTOH I expe

Re: FTP Team -- call for volunteers

On Sun, Mar 15, 2020 at 07:52:06PM +, Neil McGovern wrote: > > In theory, yes - this would move the liability to the uploader. However, > there are two issues with this: > 1) The liability now rests with the uploader. This isn't something that > has really been done before, and we'd need to ma

Re: FTP Team -- call for volunteers

On Sun, Mar 15, 2020 at 01:53:44PM +0100, Simon Richter wrote: > > > Personally, I was shocked when I found out we do review on the same server > > that > > hosts the archive. I would have expected a separate server for review. > > However, > > my expectation comes from younger environments, whe

Re: [PATCH reproducible-notes] Remove non-sense wireguard note

On Tue, Jan 21, 2020 at 05:15:16PM +0100, Jason A. Donenfeld wrote: > The comment itself doesn't indicate to me (upstream) much at all, and > a pretty ordinary attempt to figure out what it means didn't yield > much Hi Jason, At least in my experience, most of the time when there are reproduc

Re: NEW processing time (Was: https://tracker.debian.org/pkg/dballe)

On Sun, Dec 29, 2019 at 10:51:36PM +0100, Sebastiaan Couwenberg wrote: > > Wow, two weeks? I uploaded a new version of f2fs-tools back in July, > > with the same issue (SONAME bump), and it's still not gotten through > > NEW. > > > > I had assumed everyone was waiting 5-6+ months to get through N

Re: https://tracker.debian.org/pkg/dballe

On Sun, Dec 29, 2019 at 09:52:44AM +0100, Enrico Zini wrote: > Hello, > > some time ago I uploaded a new version of dballe, which went through NEW > because of a change in binary package names (SONAME bump, IIRC). It took > two weeks to go through NEW and I turned my energy towards other things >

Re: please avoid writing useless/annoying stuff in debian/gbp.conf (was: source only upload with git-buildpackage)

On Mon, Nov 11, 2019 at 08:58:42AM +0100, Thomas Goirand wrote: > >> Please, *never* do that. It's generally a very bad idea to write > >> anything to debian/gbp.conf. It's as if you were adding your text editor > >> preferences in the package. Instead, please prefer writing in ~/.gbp.conf. > > >

Re: please avoid writing useless/annoying stuff in debian/gbp.conf (was: source only upload with git-buildpackage)

On Sun, Nov 10, 2019 at 11:20:45PM +0100, Thomas Goirand wrote: > > Please, *never* do that. It's generally a very bad idea to write > anything to debian/gbp.conf. It's as if you were adding your text editor > preferences in the package. Instead, please prefer writing in ~/.gbp.conf. I keep most

Re: Perhaps we're rehashed enough of the systemd discussions?

On Mon, Nov 04, 2019 at 11:16:15AM +, Holger Levsen wrote: > > I'm wrong, but even before it's been published, I feel like it's already > > caused people to become more firmly entrenched in their existing positions. > > I was sceptical whether a GR on systemd at this point in time was > usefu

Re: Integration with systemd

On Thu, Oct 31, 2019 at 01:44:58PM +, Ian Jackson wrote: > Martin Steigerwald writes ("Re: Integration with systemd"): > > As to this, I did not yet see that the migration of elogind to testing > > has been accepted. > > Yes. > > I find these conversations draining, exhausting, awful. I am

Re: Integration with systemd

On Thu, Oct 31, 2019 at 01:19:56PM +0100, Martin Steigerwald wrote: > alienate me away from Debian. This laptop, for the sake of packaging > flexible I/O tester, is the last of my machines still running on Debian. > All the others are running Devuan. I am not looking back. I have no > intention

Re: Integration with systemd

On Wed, Oct 30, 2019 at 01:51:07PM -0700, Josh Triplett wrote: > > So mostly, this isn't going to be up to us. It's going to be up to > > the upstream. Eventually, for each package where upstream has chosen > > to use these technologies, our choice will be (a) to drop the package > > from Debian,

Re: Integration with systemd

On Wed, Oct 30, 2019 at 05:14:02AM -0700, Josh Triplett wrote: > > Today, people can't use systemd persistent timers in place of cron (and > in place of anacron's "wake up periodically" approach). You have to have > a cron job as well, and there's no good mechanism to automatically > prevent a cro

Re: Building Debian source packages reproducibly (was: Re: [RFC] Proposal for new source format)

On Mon, Oct 28, 2019 at 10:05:11AM +0100, Didier 'OdyX' Raboud wrote: > Where I'm coming from is that we were discussing the tag2upload problem at > miniDebConf Vaumarcus. The heart of the problem is that FTP-Master are > (currently) not going to accept .dscs built reproducibly by a (even trusted

Re: [RFC] Proposal for new source format

On Wed, Oct 23, 2019 at 11:40:06AM -0700, Russ Allbery wrote: > Marvin Renich writes: > > > The source package has historically (prior to the widespread use of VCS) > > also provided the basis for future development. Since most development > > these days is done using VCS, it's natural to try to

Re: [RFC] Proposal for new source format

On Wed, Oct 23, 2019 at 11:18:24AM +1000, Russell Stuart wrote: > On Tue, 2019-10-22 at 16:52 -0700, Russ Allbery wrote: > > That seems excessively pessimistic. What about Git makes you think > > it's impossible to create a reproducible source package? > > Has it been done? Given this point has

Re: Summary: Git Packaging Round 2 [comments by 11/05/2019]

One thing that is been left unclear is what does it mean to "use salsa"? For example, the e2fsprogs git repository is hosted at multiple locations: * https://git.kernel.org/pub/scm/fs/ext2/e2fsprogs.git * https://github.com/tytso/e2fsprogs.git * https://git.code.sf.net/p/e2fsprogs/code *

Re: Git Packaging: Native source formats

On Thu, Aug 29, 2019 at 11:23:01AM +0100, Ian Jackson wrote: > Theodore Y. Ts'o writes ("Re: Git Packaging: Native source formats"): > > Or if we end up moving to dgit for everything, and we don't want to > > use pristine-tar (which I like, but I realize

Re: Git Packaging: Native source formats

On Fri, Aug 30, 2019 at 12:29:45AM +0200, Thomas Goirand wrote: > > Pristine-tar forces you to have multiple branches when you may only need > a single one. It's also not reliable and may easily generate different > tarballs for the same tag, which defeats its purpose (and no, the > workaround to

Re: Git Packaging: Native source formats

On Wed, Aug 28, 2019 at 04:00:10PM -0400, Sam Hartman wrote: > > But if we're thinking that people will be working in Git, another way > to do this is to merge in a signed upstream git tag. Then you can > perform a diff against that git tag. One of the things to consider is how we should h

Re: Bypassing the 2/3/4GB virtual memory space on 32-bit ports

On Wed, Aug 21, 2019 at 10:03:01AM +0100, Luke Kenneth Casson Leighton wrote: > > so i hope that list gives a bit more context as to how serious the > consequences of dropping 32 bit support really is. I very much doubt we are any where near "dropping 32-bit support". There's a lot of "all or not

Re: Generating new IDs for cloning (was Re: duplicate popularity-contest ID)

On Tue, Aug 13, 2019 at 06:30:51PM +0100, Simon McVittie wrote: > > >> >Maybe /etc/machine-id should be part of the "API" of a Debian system in > > >> >general (systemd or not)? > > > > So /etc/machine-id should be in Policy? > > Probably yes, if that proposal has consensus, although a prerequisi

Re: And in 2019? Re: -flto to become more of a routine - any change in opinion since 2011?

On Wed, Jul 24, 2019 at 06:03:21PM +0200, Steffen Möller wrote: > Hello, > > We just had SuSE embracing LTO > (https://www.linuxtoday.com/infrastructure/opensuse-enables-lto-by-default-for-tumbleweed-smaller-faster-binaries.html). > I am not sure about the progress on issues summarised in > http:/

Re: Handling of entropy during boot

On Tue, Jan 08, 2019 at 10:41:55AM +0100, Stefan Fritsch wrote: > > If the security issue only affects a small percentage of the installations > and fixing it means breaking many other installations, then there has to > be a discussion if we really want fix the issue or if a "don't do that" > d

Re: Handling of entropy during boot

On Wed, Jan 09, 2019 at 09:58:22AM +0100, Stefan Fritsch wrote: > > There have been a number of bug reports and blog posts about this, despite > buster not being release yet. So it's not that uncommon. Pointers, please? Let's see them and investigate. The primary issue I've been aware of to da

Re: fuse -> fuse3

On Fri, Dec 21, 2018 at 11:03:34PM +0100, Oibaf wrote: > The package fuse3 is available since awhile in sid/buster. > Their users however are still using old fuse (v2), e.g. sshfs-fuse. > According to this: > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=912528 > fuse3 is not co-installable wit

Re: Handling of entropy during boot

On Sun, Dec 23, 2018 at 05:52:31PM +0100, Stefan Fritsch wrote: > I think some other questions should be considered first. Did Debian protect > from these attacks in the past? The answer is clearly no. Now, should we > break > the systems of those people who keep their random-seed file secret an

Re: Handling of entropy during boot

On Mon, Dec 17, 2018 at 09:46:42PM +0100, Stefan Fritsch wrote: > > There is a random seed file stored by systemd-random-seed.service that saves > entropy from one boot and loads it again after the next reboot. The random > seed file is re-written immediately after the file is read, so the syste

Re: usrmerge -- plan B?

On Thu, Nov 22, 2018 at 11:27:46AM -0800, Russ Allbery wrote: > > My position as a usrmerge sceptic, of letting them get on with doing > > their thing, now seems to have been unwise. The idea that it would be > > optional mutated, without proper discussion, and without a transition > > plan, into

Re: Q: Best practice for maintainer address with "alioth"

On Mon, Oct 01, 2018 at 09:59:59AM +0200, Alex Muntada wrote: > Hi Paul, > > > As I understand it, alioth-lists.d.n is an interim location > > This is correct, when asked what to do we're encouraging people > to keep the former lists.alioth.d.o addresses. > > > and folks should migrate to either

Re: Questions about packaging systemd unit files

On Sun, Aug 05, 2018 at 10:20:38PM +0100, Simon McVittie wrote: > On Sun, 05 Aug 2018 at 16:52:46 -0400, Theodore Y. Ts'o wrote: > > 1) Am I right in understanding that after modifying or adding any > >systemd unit or timer files, I must run "systemctl daemon-reload&q

Questions about packaging systemd unit files

One of my packages is about to have some systemd unit and timer files added to it. Some questions: 1) Am I right in understanding that after modifying or adding any systemd unit or timer files, I must run "systemctl daemon-reload"? 2) How is this supposed to be done as part of a debian packag

Re: Concerns to software freedom when packaging deep-learning based appications.

On Fri, Jul 13, 2018 at 06:44:39PM +0200, Jonas Smedegaard wrote: > I therefore believe there is no license violation, as long as the code > is _possible_ to compile without non-free code (e.g. blobs to activate > GPUs) - even if ridiculously expensive in either time or hardware. > > We have a p

Bug#691890: general: sudoers problem

Package: general Severity: grave Tags: d-i Justification: renders package unusable -- System Information: Debian Release: 6.0.6 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 2.6.32-5-amd64 (SMP w/2 CPU cores) Local

EXPO Postgrados y MBA - Inscripción gratuita

Este e-mail es solo para recordarte que el último evento exclusivo de Postgrados y MBA en el exterior del año, será el próximo 4 de Mayo. Inscríbete ahora. Inscripción gratuita: http://www.expo-postgrados.com/feria2011 Este evento solo es una vez por año, y es la mejor oportunidad que tienes

Re: Libreadline6 is GPLv3: incompatible with GPLv2-only software

On Apr 28, 2010, at 11:32 AM, James Y Knight wrote: After checking a scattering of random packages, I happened across one example of this already in Debian testing: socat. It is GPLv2- only, and is linked against GPLv3 libreadline6 in testing. (filed bug 579494). One further note: Fedora

Libreadline6 is GPLv3: incompatible with GPLv2-only software

I noticed that there's a bunch of bugs filed to transition packages depending on libreadline5-dev to libreadline-dev so that they can transition to using libreadline6. [1]. One of those (#553741) was filed against CLisp, which is licensed under GPLv2-only. Unfortunately, readline is under t

Re: Possible mass bug filing: non-doc packages recommending doc packages

On 09/05/07 17:55 +0530, Y Giridhar Appaji Nag said ... > I filed a lintian wishlist bug (#527363) requesting a I/W tag when non > documentation packages recommend documentation packages. > > With Install-Recommends being the default, many packages pull in a lot of > associate

Possible mass bug filing: non-doc packages recommending doc packages

debian-edu (U) Taisuke Yamada gputils Marco van Zwetselaar qtstalker Giridhar -- Y Giridhar Appaji Nag | http://appaji.net/ signature.asc Description: Digital signature

Re: people.debian.org to move to ravel

nstead of gluck? Can you > make sure that change makes it into lenny? I will take care of this. Giridhar -- Y Giridhar Appaji Nag | http://appaji.net/ signature.asc Description: Digital signature

Bug#473189: ITP: bsdelftoolchain -- collection of tools for manipulating ELF objects

Package: wnpp Severity: wishlist Owner: Y Giridhar Appaji Nag <[EMAIL PROTECTED]> -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 * Package name: bsdelftoolchain Version : unreleased Upstream Author : Joseph Koshy <[EMAIL PROTECTED]>, Kai Wang <[EMAIL PROTECTE

Fwd: Re: [mentors-ops] New mentors site as a Google SoC 2008 Debian project?

gle SoC 2008 Debian project? User-Agent: Mutt/1.5.17+20080114 (2008-01-14) X-Spam-Status: No, score=-2.6 required=3.0 tests=BAYES_00,SPF_PASS autolearn=ham version=3.1.4 Giridhar, On Wed, Mar 26, 2008 at 04:54:29PM +0530, Y Giridhar Appaji Nag wrote: > On 08/03/26 10:00 +0100, Chri

Bug#473188: ITP: libbsdelf -- library for the SVR4 ELF(3) API

Package: wnpp Severity: wishlist Owner: Y Giridhar Appaji Nag <[EMAIL PROTECTED]> -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 * Package name: libbsdelf Version : 20080125 Upstream Author : Joseph Koshy <[EMAIL PROTECTED]> * URL : http://wiki.freebs

Please test ELinks from experimental

n bug reports flow in and when fixes are made by upstream for the same. Cheers, Giridhar -- Y Giridhar Appaji Nag | http://www.appaji.net/ signature.asc Description: Digital signature

Re: elinks[-lite] doesn't provide links anymore

On 08/01/23 20:59 +1100, Hamish Moffatt said ... > On Wed, Jan 23, 2008 at 02:07:57PM +0530, Y Giridhar Appaji Nag wrote: > > Beginning elinks 0.11.3-2, the elinks and elinks-lite binary packages > > don't "Provides: links" anymore (See bug #154859 an

elinks[-lite] doesn't provide links anymore

surfraw (U) Christian Surchi <[EMAIL PROTECTED]> surfraw (U) Esteban Manchado Velázquez <[EMAIL PROTECTED]> dhelp Colin Watson <[EMAIL PROTECTED]> debbugs (U) I should've sent this mail before the upload, but better late than never. Apologies if this caused some

Bug#461404: ITP: leds-alix -- Source for the LEDs driver of PCEngines ALIX 2/3 boards

Package: wnpp Severity: wishlist Owner: Adam Cécile (Le_Vert) <[EMAIL PROTECTED]> * Package name: leds-alix Version : 0.0.1 Upstream Author : Petr Leibman <[EMAIL PROTECTED]> * URL : https://dev.openwrt.org/ticket/2771 * License : GPL-2 Programming Lang: C

Bug#459325: ITP: clang -- A C language family frontend for LLVM

Package: wnpp Severity: wishlist Owner: Y Giridhar Appaji Nag <[EMAIL PROTECTED]> -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 * Package name: clang Version : 2.2svn Upstream Author : Chris Lattner <[EMAIL PROTECTED]> * URL : http://clang.llvm.or

Le interesa ganar $ 500, $ 1000.- o $2000.- extras por mes?????

Excelentes ganancias, mìnima inversiòn... y sin horarios fijos!!! Un negocio ideal! No importa su experiencia o nivel de educación, usted recibirá apoyo personal mientras edifica su negocio.Sea usted una ama de casa, empleado/a o empresario/a, nosotros le entregamos las herramientas que

Bug#438382: ITP: dkimproxy -- SMTP-proxy that signs and/or verifies DomainKeys and/or DKIM e-mails

Package: wnpp Severity: wishlist Owner: Adam Cécile (Le_Vert) <[EMAIL PROTECTED]> * Package name: dkimproxy Version : 0.16 Upstream Author : Jason Long <[EMAIL PROTECTED]> * URL : http://jason.long.name/dkimproxy/ * License : GPL Programming Lang: Perl Desc

Bug#418745: ITP: python-yenc -- yEnc encoding/decoding extension for Python

Package: wnpp Severity: wishlist Owner: Adam Cécile (Le_Vert) <[EMAIL PROTECTED]> * Package name: python-yenc Version : 0.3~debian Upstream Author : Hellanzb Team Alessandro Duca <[EMAIL PROTECTED]> * URL : http://www.hell

Bug#361797: ITP: clewn -- A program to implement full gdb support in the vim editor.

Package: wnpp Severity: wishlist Owner: Y Giridhar Appaji Nag <[EMAIL PROTECTED]> * Package name: clewn Version : 1.7 Upstream Author : Xavier de Gaye <[EMAIL PROTECTED]> * URL : http://clewn.sourceforge.net/ * License : GPL Description :

Bug#297637: ITP: html2latex -- HTML to LaTeX conversor

Package: wnpp Severity: wishlist Owner: y <[EMAIL PROTECTED]> * Package name: html2latex Version : 1.1 Upstream Author : Peter Thatcher <[EMAIL PROTECTED]> * URL : http://html2latex.sourceforge.net/ * License : GPL Description : HTML to LaT

Using tftp

Hi all, I am trying to install Debian through TFTP because I can't afford the IBM docking station. I set all the things up. But my computer tell me "TFTP too many packages". I guess the TFTP image has problem. I tried to use program "bc" to translate the tftp image to "client-ip-in-hexcient-archit

Re: [Maxima] Future of maxima

--- Paulo Ney de Souza <[EMAIL PROTECTED]> wrote: > > I would like to volunteer to maintain the > documentation. As to the documentation, I believe all we have right now are a few examples, man pages and a manual describing the functions. A more friendly, complete manual (using docbook maybe?)

Re: Resolutions to comments on LSB-FHS-TS_SPEC_V1.0

From: Florian La Roche <[EMAIL PROTECTED]> Date: Tue, 26 Jan 1999 10:44:20 +0100 How can changing from /var/spool/mail to /var/mail be a "full solution" for the next years to come? Many people think that the mail-dir solution that e.g. qmail and mutt support is the real solution

Re: Resolutions to comments on LSB-FHS-TS_SPEC_V1.0

From: Alan Cox <[EMAIL PROTECTED]> Date: Tue, 26 Jan 1999 00:15:37 + (GMT) > but I haven't heard any technical reasons besides, "Moving spool > directories is hard". When I and others have pointed out that moving > the spool directory isn't required; just a symlink, I have hear

Re: Resolutions to comments on LSB-FHS-TS_SPEC_V1.0

I keep hearing people claim that distribution folks are saying "ick", but I haven't heard any technical reasons besides, "Moving spool directories is hard". When I and others have pointed out that moving the spool directory isn't required; just a symlink, I have heard dead silence. So the lack o

Re: Resolutions to comments on LSB-FHS-TS_SPEC_V1.0

From: "H. Peter Anvin" <[EMAIL PROTECTED]> Date: Wed, 20 Jan 1999 00:19:26 -0800 (PST) I believe the FHS 2.0 change was right on target. Just about every UNIX implementation today has moved away from /var/spool/mail to /var/mail, and it has technical advantages. If anything, sp

Re: VI reasons (was Re: Base Set: Suggested additions & removals.)

greet all, I am no guru. But let's stop this war! To me, choice of editor depends on your experience, skill and task on hand. I use vi and my boss at work uses emacs. We both like our own choice very much and enjoy the way our choice works for us. But we never try to "convert" each other, fortunat