Accepted django-model-utils 3.1.1-2 (source) into unstable

-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Format: 1.8 Date: Wed, 07 Aug 2019 01:05:46 +0500 Source: django-model-utils Architecture: source Version: 3.1.1-2 Distribution: unstable Urgency: medium Maintainer: Debian Python Modules Team Changed-By: Andrey Rahmatullin Changes: django-model

Re: duplicate popularity-contest ID

On Mon, Aug 05, 2019 at 02:29:33PM +0200, Bill Allombert wrote: > 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

Accepted python-scrapy-djangoitem 1.1.1-4 (source) into unstable

-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Format: 1.8 Date: Sun, 04 Aug 2019 21:30:17 +0500 Source: python-scrapy-djangoitem Architecture: source Version: 1.1.1-4 Distribution: unstable Urgency: medium Maintainer: Debian Python Modules Team Changed-By: Andrey Rahmatullin Changes: python

Accepted python-restless 2.1.1-2 (source) into unstable

-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Format: 1.8 Date: Sat, 03 Aug 2019 00:59:55 +0500 Source: python-restless Architecture: source Version: 2.1.1-2 Distribution: unstable Urgency: medium Maintainer: Debian Python Modules Team Changed-By: Andrey Rahmatullin Changes: python-restless

Accepted python-w3lib 1.20.0-2 (source) into unstable

-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Format: 1.8 Date: Fri, 02 Aug 2019 23:53:08 +0500 Source: python-w3lib Architecture: source Version: 1.20.0-2 Distribution: unstable Urgency: medium Maintainer: Debian Python Modules Team Changed-By: Andrey Rahmatullin Changes: python-w3lib

Accepted python-parsel 1.5.0-3 (source) into unstable

-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Format: 1.8 Date: Fri, 02 Aug 2019 23:35:23 +0500 Source: python-parsel Architecture: source Version: 1.5.0-3 Distribution: unstable Urgency: medium Maintainer: Debian Python Modules Team Changed-By: Andrey Rahmatullin Changes: python-parsel

Accepted python-scrapy 1.7.3-1 (source) into unstable

-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Format: 1.8 Date: Fri, 02 Aug 2019 17:57:10 +0500 Source: python-scrapy Architecture: source Version: 1.7.3-1 Distribution: unstable Urgency: medium Maintainer: Debian Python Modules Team Changed-By: Andrey Rahmatullin Changes: python-scrapy

Re: B-D on src package? (was: Re: Challenge from Julia's non-standard vendored openblas"64_"

On Sun, Jul 28, 2019 at 07:03:43AM -0700, Mo Zhou wrote: > > This is maybe not directly helpful to you right now, but: > > > > If we could build-depend on source packages, you could combine these > > two ideas into something that might be less awful. > > More than once have I thought of "what if

Accepted librsync 2.0.2-1 (source) into unstable

-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Format: 1.8 Date: Sun, 28 Jul 2019 18:25:56 +0500 Source: librsync Architecture: source Version: 2.0.2-1 Distribution: unstable Urgency: medium Maintainer: Andrey Rahmatullin Changed-By: Andrey Rahmatullin Changes: librsync (2.0.2-1) unstable

Re: does libmyodbc was removed? ther's will no more mysql odbc packages?

On Fri, Jul 26, 2019 at 01:26:52PM -0400, PICCORO McKAY Lenz wrote: > the https://packages.debian.org/search?keywords=libmyodbc show only > for sid and oldstable.. so what will happened.. users now must > compiled own mysql odbc? It's in sid, so no? Also, if you use

Re: Help needed with a script generating a .deb (Done. Now what?)

On Tue, Jul 23, 2019 at 08:31:34PM +0200, dettus wrote: > Now that I am able to create packages What do I do with them? Read my link again. Also, the packaging help list is debian-mentors@. -- WBR, wRAR signature.asc Description: PGP signature

Re: Help needed with a script generating a .deb

On Tue, Jul 23, 2019 at 07:19:32PM +0200, dettus wrote: > Running it ends with  the following feedback: > > > > > dpkg-buildpackage: info: full upload (original source is included) > Now running lintian... > W: dmagnetic: missing-depends-line > W: dmagnetic:

Re: Sorce only uploads with sbuild (was: Bits from the Release Team)

On Tue, Jul 23, 2019 at 12:22:02PM +0200, Mathias Behrle wrote: > I tried that building as usual with sbuild with additional option > --source-only-changes and uploaded, but now get REJECTS with e.g. > > tryton-server_5.0.6-2.dsc: Refers to non-existing file > 'tryton-server_5.0.6.orig.tar.gz' >

Re: Help needed with a script generating a .deb

We don't use dpkg-deb -b to create packages. If you want to create a package that can be uploaded to Debian, start with https://mentors.debian.net/intro-maintainers -- WBR, wRAR signature.asc Description: PGP signature

Re: How to adopt a dead package?

On Sun, Jul 14, 2019 at 02:05:25PM -0400, Perry E. Metzger wrote: > Howdy! bozohttpd was removed from Debian a while ago because of a > lack of activity by the upstream maintainer and some outstanding > security issues, but said maintainer re-awakened and fixed a bunch of > bugs (including the

Re: buster backports question/status

On Wed, Jul 10, 2019 at 11:29:01AM +0200, olivier sallou wrote: > I tried a package that is not in backports, it was just for test (for an > automation tool I use) > It should fail with a *package not found* , but should not fail about > buster-backports being non available. I don't think the

Re: buster backports question/status

On Wed, Jul 10, 2019 at 10:54:21AM +0200, olivier sallou wrote: > So, am I doing something wrong? You tried to install a package (what package? they don't exist) from a repo that doesn't exist. -- WBR, wRAR signature.asc Description: PGP signature

Re: Seeking advice re: CVE-2019-13179 (insecure permissions for initramfs)

On Wed, Jul 03, 2019 at 08:59:26AM -0400, Sam Hartman wrote: > The rationale is that on systems with full disk encryption the initramfs > probably isn't encrypted > > I personally think sticking your full disk encryption keys onto the > initramfs doesn't have a lot of value. These two things are

Re: Survey: git packaging practices / repository format

On Mon, Jul 01, 2019 at 03:04:26PM +0200, Enrico Weigelt, metux IT consult wrote: > On 29.05.19 17:41, Andrey Rahmatullin wrote: > > >> Perhaps we should update policy to say that the .orig tarball may (or > >> even "should") be generated from an upstream

Re: Let's consider using year based release identifiers [was: Re: getting rid of "testing"]

On Sat, Jun 29, 2019 at 06:17:12PM +0400, Jerome BENOIT wrote: > >>> As others here I am starting to get confused by the release code > >>> names, as are my peers that are not that much into Debian. And > >>> sequential release numbers are devoid of any semantics except for > >>> their

Re: Let's consider using year based release identifiers [was: Re: getting rid of "testing"]

On Sat, Jun 29, 2019 at 01:53:35PM +0200, Tomas Pospisek wrote: > TLDR; year based release identifiers should be prefered since they are > much more intuitive to reason about than codenames and sequentialy > numbered release identifiers. > > If Debian should improve/change release identifiers,

Re: getting rid of "testing"

On Tue, Jun 25, 2019 at 12:40:01PM -0400, Michael Stone wrote: > > and so on - i take the older releases only as reference. > > I just do something like look at https://packages.debian.org/ssh > Or, if I'm really curious about versions, then something like >

Re: getting rid of "testing"

On Tue, Jun 25, 2019 at 06:28:13PM +0200, Alf Gaida wrote: > > oldoldstable has the value of demonstrating some of what's wrong with > > the current system > > Can you please explain, i don't get it That name is stupid. -- WBR, wRAR signature.asc Description: PGP signature

Re: Content Rating System in Debian

On Tue, Jun 25, 2019 at 12:43:56PM +0200, Paride Legovini wrote: > My question is: are we trying to solve an actual problem here? No, and please note that the author is not even a Debian user: https://lists.debian.org/debian-devel/2019/06/msg00376.html -- WBR, wRAR signature.asc Description:

Re: getting rid of "testing"

On Tue, Jun 25, 2019 at 09:46:00AM +0200, Bastian Blank wrote: > > Related to that I would like to be able to write something like > > deb http://deb.debian.org/debian debian11 main > > deb http://security.debian.org/debian-security debian11-security main > > in sources.list as codenames

Re: getting rid of "testing"

On Tue, Jun 25, 2019 at 08:08:22AM +0200, Ansgar wrote: > Hi, > > what do people think about getting rid of current suite names ("stable", > "testing", "unstable") for most purposes? We already recommend using > codenames instead as those don't change their meaning when a new release > happens.

Re: Do we want to Require or Recommend DH

On Tue, Jun 04, 2019 at 02:27:03PM +, Thorsten Glaser wrote: > No. A maintainer normally deals with their own packages, or with > .dsc and debdiff, for NMU. (This is also an answer to the reply > from wrar. Oh, jonas also said so, reloading the list index page.) A maintainer normally deals

Re: Do we want to Require or Recommend DH

On Tue, Jun 04, 2019 at 04:10:38PM +0200, Jonas Smedegaard wrote: > > > I’d also throw in that monocultures are not good, and that people in > > > general are happier when they aren’t forced into anything. > > Yet people in general are also happier when they don't need to learn > > all ways to

Re: Do we want to Require or Recommend DH

On Tue, Jun 04, 2019 at 01:37:46PM +, Thorsten Glaser wrote: > I’d also throw in that monocultures are not good, and that people > in general are happier when they aren’t forced into anything. Yet people in general are also happier when they don't need to learn all ways to do something. >

Re: Survey: git packaging practices / repository format

On Wed, May 29, 2019 at 12:20:23PM -0400, Sam Hartman wrote: > >> Perhaps we should update policy to say that the .orig tarball may > >> (or even "should") be generated from an upstream release tag > >> where applicable. > Andrey> This conflicts with shipping tarball signatures. >

Re: Survey: git packaging practices / repository format

On Wed, May 29, 2019 at 02:14:09PM +0100, Ben Hutchings wrote: > [...] > > My understanding is that this unusual difference between the .orig > > tarball and what's in git is an attempt to "square the circle" between > > two colliding design principles: "the .orig tarball should be upstream's > >

Re: Why do we take so long to realise good ideas (Was: Difficult Packaging Practices)

On Wed, May 29, 2019 at 08:43:55AM +0200, Andreas Tille wrote: > IMHO this touches another burning topic: Its not that we do not want to > provide some PPA equivalent - its just that we do not realise it. I do > not remember how many years ago we talked about bikesheds (and > obviously we even

Re: @debian.org mail

On Tue, May 28, 2019 at 11:19:37PM +0200, Jean-Philippe MENGUAL wrote: > Forwarding mail from @debian.org to my mailbox makes me apply > complicated filters to stay subscribed to ML I wish. Why? -- WBR, wRAR signature.asc Description: PGP signature

Re: Do we want to Require or Recommend DH

On Tue, May 14, 2019 at 09:10:04AM +, Holger Levsen wrote: > On Tue, May 14, 2019 at 02:07:11PM +0500, Andrey Rahmatullin wrote: > > One can go further and say that people uploading broken packages are the > > actual problem. After all, we have several classes of bugs cause

Re: Do we want to Require or Recommend DH

On Tue, May 14, 2019 at 11:11:46AM +0300, Adrian Bunk wrote: > How well are you testing such conversions? > Based on work I've seen from you I'd guess your NMU would be better than > average. Unfortunately this is not generally true. > > Based on what enters the archive, "debdiff between old and

Re: .deb format: let's use 0.939, zstd, drop bzip2

On Thu, May 09, 2019 at 12:02:26AM +0200, Adam Borowski wrote: > > We have various applications that only want to extract single members of > > the package (changelog, NEWS, copyright, ...); tar is a really bad > > format for such an operation. Other formats (zip, 7z, ...) are more > > suited for

Re: Preferred git branch structure when upstream moves from tarballs to git

On Mon, Apr 29, 2019 at 11:18:48AM +0200, Gard Spreemann wrote: > For one of my packages, I maintain two public git branches: one is > upstream/latest, where I've been importing upstream's released tarballs, > and the other is debian/sid that contains the packaging. > > Recently, upstream has

Re: Preferred git branch structure when upstream moves from tarballs to git

On Mon, Apr 29, 2019 at 11:40:39AM +0200, Adam Borowski wrote: > that's a monstrosity -- my personal preference is raw git, where updating to > a new upstream is "git merge v3.14.15" gbp allows this too, of course. -- WBR, wRAR signature.asc Description: PGP signature

Re: native packages? (Re: Introducting Debian Trends: historical graphs about Debian packaging practices, and "packages smells")

On Fri, Apr 26, 2019 at 02:27:58PM +, Holger Levsen wrote: > > > > > > I see no point whatsoever in 3.0 (native). > > > > What's the point/advantage of native packages? > > > No need to make a separate orig tarball. > > the irony here is that native packages also require an upstream tarball,

Re: Bits from the Release Team: buster freeze update

On Wed, Apr 17, 2019 at 08:44:20AM +1000, Hugh McMaster wrote: > > At the time of writing 150 release-critical bugs affect buster. This is the > > number which needs to reach zero before the release can take place. > > > What’s the easiest way to get a list of these RC bugs?

Re: native packages? (Re: Introducting Debian Trends: historical graphs about Debian packaging practices, and "packages smells")

On Sat, Apr 13, 2019 at 12:59:19PM +, Holger Levsen wrote: > > > I see no point whatsoever in 3.0 (native). > > The main advantage of 3.0 (native) is that it makes it explicit that > > the package is deliberately native [...] > > ok, sorry, I ment to say: I see no point whatsoever in native

Re: PPAs (Re: [Idea] Debian User Repository? (Not simply mimicing AUR))

On Thu, Apr 11, 2019 at 09:54:47AM +, Mo Zhou wrote: > Any link please? Both apt-file-search and google found nothing. It's in contrib. https://tracker.debian.org/pkg/game-data-packager -- WBR, wRAR signature.asc Description: PGP signature

Re: is Wayland/Weston mature enough to be the default desktop choice in Buster?

On Sun, Apr 07, 2019 at 05:59:38PM +0200, Adam Borowski wrote: > * nvidia proprietary: doesn't work with new kernels. It does, even nvidia-legacy-304xx-kernel-dkms says "Building the kernel modules has been tested up to Linux 4.20.". -- WBR, wRAR signature.asc Description: PGP signature

Re: is Wayland/Weston mature enough to be the default desktop choice in Buster?

On Sun, Apr 07, 2019 at 01:08:42PM -0400, Peter Silva wrote: > https://www.cnx-software.com/2018/08/27/rockpro64-rk3399-board-linux-review-ubuntu-18-04/ > > 71fps or es2gears? Is es2gears a benchmark, unlike glxgears? -- WBR, wRAR signature.asc Description: PGP signature

Re: duprkit User Repository

On Mon, Apr 08, 2019 at 09:58:26AM +, Mo Zhou wrote: > AUR's PKGBUILD, Fedora/CentOS/RedHat's .spec, Gentoo's .ebuild, > all of them are single-file format. The advantages of single-file > format includes easy distribution, e.g. copying & pasting from > webpages (you cannot copy a directory

Re: [Idea] Debian User Repository? (Not simply mimicing AUR)

On Sun, Apr 07, 2019 at 02:17:00PM +, Mo Zhou wrote: > However, I got a hint from a fellow developer and learned that > "Bikeshed" has its own meaning under Debian's context, according > to some old mailing list fragments[2][3] -- which refers to a > dak feature (This is the first time I heard

Re: [Idea] Debian User Repository? (Not simply mimicing AUR)

Isn't the Bikesheds initiative just this? -- WBR, wRAR signature.asc Description: PGP signature

Re: Seeking hardening flag / blhc expoert

On Fri, Apr 05, 2019 at 09:07:06PM +0200, Sven Hartge wrote: > CMake is a bit "special" in that regard. To get the right hardening > flags to work for some parts of Bacula, we had to include the following > patch to kind-of brute force the flags: >

Re: Seeking hardening flag / blhc expoert

On Fri, Apr 05, 2019 at 10:17:16PM +0300, Otto Kekäläinen wrote: > So apparently the 'D_FORTIFY_SOURCE=2' is in CPPFLAGS (not read by > cmake) but not in CXXFLAGS (read by cmake)[1]. That's what the wiki page says, yes. > So maybe I should define? > CXXFLAGS=$(CXXFLAGS) $(CPPFLAGS) That's the

Re: Seeking hardening flag / blhc expoert

On Fri, Apr 05, 2019 at 09:55:34PM +0300, Otto Kekäläinen wrote: > Hello! > > > > Is there any hardening flag / cmake expert around who could help me > > > get the hardening flags perfect in MariaDB 10.3? > > Start with https://wiki.debian.org/Hardening#Notes_for_packages_using_CMake > > I've

Re: Seeking hardening flag / blhc expoert

On Fri, Apr 05, 2019 at 09:07:01PM +0300, Otto Kekäläinen wrote: > Is there any hardening flag / cmake expert around who could help me > get the hardening flags perfect in MariaDB 10.3? Start with https://wiki.debian.org/Hardening#Notes_for_packages_using_CMake > d/rules: >

Accepted pygnuplot 0.11.16-2 (source) into unstable

-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Format: 1.8 Date: Sun, 17 Mar 2019 14:00:05 +0500 Source: pygnuplot Architecture: source Version: 0.11.16-2 Distribution: unstable Urgency: medium Maintainer: Debian Python Modules Team Changed-By: Andrey Rahmatullin Closes: 924341 Changes

Re: Please drop anacron from task-desktop

On Fri, Mar 08, 2019 at 07:28:11PM +0100, Adam Borowski wrote: > There's a problem with extending the syntax: we have not one but five cron > implementations in the distributions, and all would need to be in sync, Not necessarily. Being in sync isn't required for init scripts. -- WBR, wRAR

Re: Use of the Build-Conflicts field

On Sun, Feb 17, 2019 at 07:44:29AM +0100, Tollef Fog Heen wrote: > I think it boils down to the question of «Are builds outside of a > minimal + build-essential + build-deps» supported?». If they're not, we > can just ignore the problem and deprecate the Build-Conflicts field > (since it has no

Accepted librsync 2.0.2-1~exp1 (source) into experimental

-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Format: 1.8 Date: Sat, 16 Feb 2019 21:08:50 +0500 Source: librsync Architecture: source Version: 2.0.2-1~exp1 Distribution: experimental Urgency: medium Maintainer: Andrey Rahmatullin Changed-By: Andrey Rahmatullin Changes: librsync (2.0.2-1~exp1

Accepted mpdscribble 0.22-6 (source) into unstable

-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Format: 1.8 Date: Tue, 05 Feb 2019 21:35:35 +0500 Source: mpdscribble Architecture: source Version: 0.22-6 Distribution: unstable Urgency: medium Maintainer: mpd maintainers Changed-By: Andrey Rahmatullin Changes: mpdscribble (0.22-6) unstable

Re: package management symlink

On Tue, Feb 05, 2019 at 07:22:21AM +, Jonathan Dowland wrote: > You need to create a Debian package that contains your symlink (or bash > script), and then either find someone to sponsor uploads of your package > into Debian, or become a Debian Maintainer or Developer to do so > yourself. > >

Accepted ipdb 0.11-1 (source) into unstable

-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Format: 1.8 Date: Sat, 26 Jan 2019 16:28:28 +0500 Source: ipdb Architecture: source Version: 0.11-1 Distribution: unstable Urgency: medium Maintainer: Debian Python Modules Team Changed-By: Andrey Rahmatullin Changes: ipdb (0.11-1) unstable

Accepted kvirc 4:5.0.0+dfsg-1 (source all amd64) into unstable, unstable

Changed-By: Andrey Rahmatullin Description: kvirc - KDE-based next generation IRC client with module support kvirc-data - Data files for KVIrc kvirc-modules - KVIrc (IRC client) modules libkvilib5 - KVIrc (IRC client) base library Changes: kvirc (4:5.0.0+dfsg-1) unstable; urgency=medium

Re: Nix and non-standard-toplevel-dir

On Wed, Jan 02, 2019 at 07:10:06PM +0100, Kai Harries wrote: > [4] https://nixos.org/~eelco/pubs/phd-thesis.pdf This is an interesting text. It shows that the author has read the FHS but chose to ignore it. The only ref to FHS is in the following text: """ For instance, storing components in an

Re: [Pkg-julia-devel] julia_1.0.0-1_amd64.changes REJECTED

On Thu, Dec 20, 2018 at 01:49:29PM +, Mo Zhou wrote: > I'm declaring this in advance, so if anyone see something dirty happend > on the Julia binary packages, please don't report any bug against that > dirty solution. I'm afraid it doesn't matter for a broken package if the brokenness is

Re: Conflict over /usr/bin/dune

Even firefox was renamed twice. -- WBR, wRAR signature.asc Description: PGP signature

Re: Depends of libnss3

On Tue, Dec 18, 2018 at 01:19:54PM +, Daniel Reichelt wrote: > why does libnss3/buster depend on libc6 >= 2.28 for i386 but for amd64, > >= 2.14 suffices? Symbols, I'm sure. > Is there a technical rationale for this You can compare the symbol lists to find the differences, I suppose. --

Re: Plugin link options

On Thu, Dec 13, 2018 at 03:39:40PM +0200, Tommi Höynälänmaa wrote: > Should the linker option "-Wl,--as-needed" be used for plugins, e.g. guile > plugins? Debmake suggests using the option for the linker. Are they actually buildable with that option? -- WBR, wRAR signature.asc Description: PGP

Re: Tainted builds (was Re: usrmerge -- plan B?)

On Wed, Nov 28, 2018 at 06:40:46PM +0100, Guillem Jover wrote: > On Wed, 2018-11-28 at 22:13:41 +0500, Andrey Rahmatullin wrote: > > On Wed, Nov 28, 2018 at 02:48:32PM -0200, Antonio Terceiro wrote: > > > (ischroot(1) is from debianutils which is Essential). > > > &quo

Re: Tainted builds (was Re: usrmerge -- plan B?)

On Wed, Nov 28, 2018 at 02:48:32PM -0200, Antonio Terceiro wrote: > Would you be willing to also implement > > Tainted-By: not-built-in-a-chroot That doesn't mean anything. You can build in a bad chroot and you can build in a clean minimal sid system which is not a chroot but a VM. >

Re: Re: usrmerge -- plan B?

On Wed, Nov 28, 2018 at 07:52:08AM +0500, Alexander E. Patrakov wrote: > As long as there is one Debian Developer (or any other person who has the > right to upload binary packages) who has a merged /usr on his system used > for building packages, there is a risk of reintroducing the bug through

Re: Is using experimental distribution for shelter during freeze useful?

On Tue, Nov 27, 2018 at 08:38:46PM +0900, Hideki Yamane wrote: > Cons) > - Harder to get users for test with testing-proposed-updates repository My understanding of the current consensus is that this is the main reason for using the current workflow. Nobody would test anything except sid and

Re: NEW and RC bugs (Re: julia_1.0.0-1_amd64.changes REJECTED)

On Tue, Nov 27, 2018 at 08:38:56AM +0100, Wouter Verhelst wrote: > > > The experimental distribution is a good place for work in > > > progress. Maybe the rules for automatic rejects can be relaxed for > > > experimental so a package can go into the archive (and have e.g. the BTS > > > used for

Re: julia_1.0.0-1_amd64.changes REJECTED

On Sun, Nov 25, 2018 at 10:25:44AM -0700, Sean Whitton wrote: > >> If someone does want to come along and fix the package, having it pass > >> through NEW again is not a good use of ftpteam time. > > Sounds like NEW is the problem, not other parts? > > Not sure what you mean. I mean it seems

Re: julia_1.0.0-1_amd64.changes REJECTED

On Wed, Nov 21, 2018 at 08:37:28PM -0700, Sean Whitton wrote: > >> Before we get there, we should first start autoremoving packages from > >> unstable, if we consider rc-buggy in unstable to be unacceptable. We > >> do have quite a bit of things in unstable, that are neither getting > >> fixed,

Re: Installer: 32 vs. 64 bit

On Fri, Oct 26, 2018 at 02:41:31PM +0200, Juliusz Chroboczek wrote: > I've been encouraging my students to install Debian on their personal > machines, and we've found out that a lot of them get the wrong Debian > installer: > > - some of them attempt to install an AMD64 version of Debian in >

Re: no{thing} build profiles

On Wed, Oct 24, 2018 at 03:40:12PM +, Ivan Shmakov wrote: > What are the values of the crypt_use_gpgme setting in each case? > Could it be that mutt and neomutt actually have different defaults > (one using gpg(1) directly and the other using GPGME) here? According to

Re: no{thing} build profiles

On Tue, Oct 23, 2018 at 05:01:04PM +0200, Wouter Verhelst wrote: > > That would be a bad idea -- we don't want gratuitous dependencies all > > around. Just because I use xfce doesn't mean I want a daemon for some old > > kinds of iApple iJunk > > Why not? What does it cost you, other than a few

Re: no{thing} build profiles

On Sun, Oct 21, 2018 at 05:33:57PM +, Ivan Shmakov wrote: > > "Every package must specify the dependency information about other > > packages that are required for the first to work correctly." Policy 3.5. > > The gnupg package is not required for (neo)mutt to work > correctly,

Re: no{thing} build profiles

On Sun, Oct 21, 2018 at 01:46:48PM -0400, Marvin Renich wrote: > > > The proper fix is to convince upstream to dynamically link at runtime > > > and disable some features if libgpgme is not available. > > dlopening a dependency is bad: for example, it doesn't allow distro > > builders to track the

Re: no{thing} build profiles

On Sun, Oct 21, 2018 at 01:15:21PM +, Ivan Shmakov wrote: > Semantically, Depends: declares that the package has to be > installed to proceed. It doesn’t specify whether the package > has to actually be used. Which kind of invalidates the point. "Every package must specify

Re: no{thing} build profiles

On Sun, Oct 21, 2018 at 12:13:27PM -0400, Marvin Renich wrote: > The proper fix is to convince upstream to dynamically link at runtime > and disable some features if libgpgme is not available. dlopening a dependency is bad: for example, it doesn't allow distro builders to track the deps properly

Re: no{thing} build profiles

On Sat, Oct 20, 2018 at 06:37:20PM +, Ivan Shmakov wrote: > Now, unless I be mistaken, “build profiles,” as suggested in > this subthread, are meant to allow for building packages with > specific changes to their run-time library dependencies? > Frankly, I don’t see

Re: Debian Buster release to partially drop non-systemd support

On Sat, Oct 20, 2018 at 06:54:07PM +0200, Arne Babenhauserheide wrote: > > Should Debian also support "noalsa", "noavahi", "nocups", > > "nopulseaudio", "nosysvinit", "nodbus", "nopam", "nowayland", > > Are alsa, avahi, cups, pulseaudio, sysvinit, dbus, pam and wayland all > similar in scope to

Re: wpa_supplicant cannot authenticate against freeradius 3.0.16+dfsg-4.1+b1

On Wed, Oct 17, 2018 at 04:04:15PM +0200, Kamil Jońca wrote: > (previously sent to debian-devel by mistake) You've repeated that mistake. -- WBR, wRAR signature.asc Description: PGP signature

Re: Debian Buster release to partially drop non-systemd support

On Mon, Oct 15, 2018 at 02:20:03PM +0100, Jonathan Dowland wrote: > Is it worth interested parties reaching out to the Devuan project > regarding person-power for sysvinit maintenance? It's hard to discuss this with a straight face, but in any case even they admit they don't have any

Re: Updating an uploaded package

On Sat, Oct 06, 2018 at 11:00:37AM +0300, Tommi Höynälänmaa wrote: > If I need to update a package uploaded to mentors can I just upload the new > package with dput? Yes. You can even reuse the version. Also, the proper mailing list for such questions is debian-mentors@ -- WBR, wRAR

Re: New software for Debian

On Thu, Sep 27, 2018 at 03:11:58PM +0300, Tommi Höynälänmaa wrote: > Hi > > I would like to include the following software to Debian testing or stable > distribution: You can't add anything to current stable (only to the next stable), but you can add new packages to unstable and they will then

Re: Question regarding patching in 4.9 kernel

On Thu, Sep 27, 2018 at 02:28:35AM +, Harish Venkatraman wrote: > Hi Ben, > > I am trying to manually back port to Linux 4.9 since in the link I don’t see > a patch provided for 4.9 version. The last version that has this patch is > 4.11, wanted to know if back port of this patch is

Re: julia_1.0.0-1_amd64.changes REJECTED

On Wed, Sep 26, 2018 at 12:52:41PM +0200, Graham Inggs wrote: > I thought Lumin had made it clear enough that being able to obtain a > stacktrace from within Julia is actually a feature [1]. One of Julia's > tests checks this, and hence autopkgtests fail if debug symbols are missing > from

Re: Bug#906183: Dependency change and upgrade

On Tue, Sep 25, 2018 at 12:36:30AM +, Devarajulu, Mohanasundaram wrote: > During the upgrade if all the packages are installed then upgrade is > going through well. If only the dev package with the problem and its > dependencies are installed, by default apt keeps the packages back as it >

Re: Bumping epoch and reusing package name "elisa"

On Mon, Sep 24, 2018 at 09:38:24AM -0700, Russ Allbery wrote: > Ideally, we would never reuse the name of a binary package for some > unrelated piece of software Indeed. -- WBR, wRAR signature.asc Description: PGP signature

Re: Bumping epoch and reusing package name "elisa"

On Mon, Sep 24, 2018 at 09:21:14AM -0700, Russ Allbery wrote: > This causes a ton of headaches for the archive software. IIRC, I believe > dak is rather unhappy about version numbers going backwards This is unfortunate. > apt is going to have no idea what to do for a system that already has the

Re: Bumping epoch and reusing package name "elisa"

On Sun, Sep 23, 2018 at 10:53:04PM +0200, Aurélien COUDERC wrote: > FTP masters rejected the upload of the new elisa 0.2.1-1 as the package has a > lower version than the former Elisa project and they proposed bumping the > epoch > and reusing the name. I don't find this reasonable to be honest.

Re: Updating the policy for conflicting binaries names ? [was: Re: Re: New package netgen-lvs with binary /usr/bin/netgen - already taken]

On Sat, Sep 08, 2018 at 06:07:43PM -0300, David Bremner wrote: > Andrey Rahmatullin writes: > > > Last upload of ax25-node was in 2008, in 2009 it was effectively orphaned, > > the TC bug was filed in 2011 and resolved in 2012, in 2015 ax25-node was > > removed with

Re: Updating the policy for conflicting binaries names ? [was: Re: Re: New package netgen-lvs with binary /usr/bin/netgen - already taken]

On Sat, Sep 08, 2018 at 12:03:18PM -0700, Sean Whitton wrote: > My understanding is that there are quite deep social reasons for the > current policy (please note, though, that I was not involved in Debian > when this piece of policy was created; neither was I involved during the > nodejs TC

Re: New package netgen-lvs with binary /usr/bin/netgen - already taken

On Tue, Sep 04, 2018 at 09:39:39PM +0200, Ruben Undheim wrote: > What is the recommendation? Any links to previous discussions / documents > about > this subject? Policy 10.1. -- WBR, wRAR signature.asc Description: PGP signature

Re: headsup - various redis modules now proprietary!

On Wed, Aug 22, 2018 at 01:02:30PM +1200, Robert Collins wrote: > RedisLabs have changed the license of various modules to be > incompatible with DFSG guideline 6: the 'Common Clause' rider. > > https://redislabs.com/community/commons-clause/ "Therefore, the no-sale restriction imposed by

Re: Q: Where is keyring packaging guideline?

On Tue, Aug 21, 2018 at 08:13:24PM +0900, Roger Shimizu wrote: > And emdebian's keyring [3] didn't hit archive, either. Wrong: https://tracker.debian.org/pkg/emdebian-archive-keyring "As of July 2014, updates to the Emdebian distributions ceased." though. -- WBR, wRAR signature.asc

Re: Pretty Easy Privacy

On Mon, Aug 20, 2018 at 10:23:53PM +0200, Geert Stappers wrote: > There is PEP, https://en.wikipedia.org/wiki/Pretty_Easy_privacy > project website is https://www.pep.security/ > > However `apt search pep` doesn't show it? > Neither is a WNPP bugreport at hand. Not everything is packaged. > Is

Re: OpenStack dysfunctionality (was: salsa.debian.org maintenance...)

On Sun, Aug 19, 2018 at 10:02:57PM +, Jeremy Stanley wrote: > I've heard that Debian's just a bunch of pedantic wonks who care more > about licensing technicalities than whether their distribution carries > working software This is correct, at least partially and if you remove "just". --

Re: salsa.debian.org maintenance (GitLab 11.1.4 upgrade, external storage migration)

On Fri, Aug 17, 2018 at 10:12:00AM +, u wrote: > >> While I understand the simplicity of using $company's cloud storage, I'd > >> rather not rely on some external company and in particular not on this > >> one. This company does not exactly represent what I would call ethical, > >>

Re: salsa.debian.org maintenance (GitLab 11.1.4 upgrade, external storage migration)

On Fri, Aug 17, 2018 at 08:27:00AM +, Ulrike Uhlig wrote: > While I understand the simplicity of using $company's cloud storage, I'd > rather not rely on some external company and in particular not on this > one. This company does not exactly represent what I would call ethical, >

Accepted qgit 2.8-1 (source) into unstable

-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Format: 1.8 Date: Mon, 06 Aug 2018 20:09:20 +0500 Source: qgit Binary: qgit Architecture: source Version: 2.8-1 Distribution: unstable Urgency: medium Maintainer: Andrey Rahmatullin Changed-By: Andrey Rahmatullin Description: qgit - Qt

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