Re: Firmware GR result - what happens next?
On Thu, Oct 13, 2022 at 05:17:59PM +0200, Tobias Frost wrote: > On Thu, Oct 13, 2022 at 05:08:57PM +0200, Julien Cristau wrote: > > On Thu, Oct 06, 2022 at 05:13:22PM +0200, Tobias Frost wrote: > > > Maybe and idea would to do something like isa-support does for e.g > > > sseX-support > > > on CPUs that does not have that feature: It fails on installation with an > > > debconf message, IIRC. > > > So that would allow something like "new package" | > > > "you-need-to-enable-nonfree-firmware-reminder-package" > > > > > Failing on installation is a terrible user experience, let's not, pretty > > please. > > I'd prefer failing loudly to failing silently. > I'd prefer if we could make things work vs making things fail, however loudly. Cheers, Julien
Re: Firmware GR result - what happens next?
On Thu, Oct 06, 2022 at 05:13:22PM +0200, Tobias Frost wrote: > Maybe and idea would to do something like isa-support does for e.g > sseX-support > on CPUs that does not have that feature: It fails on installation with an > debconf message, IIRC. > So that would allow something like "new package" | > "you-need-to-enable-nonfree-firmware-reminder-package" > Failing on installation is a terrible user experience, let's not, pretty please. Cheers, Julien
Re: Firmware GR result - what happens next?
On Thu, Oct 6, 2022 at 15:45:25 +0100, Steve McIntyre wrote: > On Wed, Oct 05, 2022 at 10:11:27PM +0200, Julien Cristau wrote: > >On Sun, Oct 02, 2022 at 08:21:31PM +0100, Steve McIntyre wrote: > >> On Sun, Oct 02, 2022 at 11:08:47AM -0400, Michael Stone wrote: > >> >On Sun, Oct 02, 2022 at 03:53:00PM +0100, Steve McIntyre wrote: > >> >> On Sun, Oct 02, 2022 at 04:43:47PM +0200, Michael Biebl wrote: > >> >> > What's the plan for upgraded systems with an existing > >> >> > /etc/apt/sources.list. > >> >> > Will the new n-f-f section added on upgrades automatically(if > >> >> > non-free was > >> >> > enabled before)? > >> >> > >> >> So this is the one bit that I don't think we currently have a good > >> >> answer for. We've never had a specific script to run on upgrades (like > >> >> Ubuntu do), so this kind of potentially breaking change doesn't really > >> >> have an obvious place to be fixed. > >> > > >> >Is there a reason to not continue to make the packages available in > >> >non-free? > >> >I don't see a reason to force any change on existing systems. > >> > >> Two things: > >> > >> 1. I'm worried what bugs we might expose by having packages be in two > >> components at once. > >> 2. I really don't like the idea of leaving two different > >> configurations in the wild; it'll confuse people and is more > >> likely to cause issues in the future IMHO. > >> > >> Plus, as Shengjing Zhu points out: we already expect people to manage > >> the sources.list anyway on upgrades. > >> > >I think in the absence of a release upgrade script (which I very much > >doubt will happen, and be tested, and we can rely will be used, for > >bookworm), Michael's suggestion seems like a reasonable way forward. I > >imagine we'll need to patch dak to allow that, but it seems like it > >should be tractable? > > I'm also worried what effect this will have on other tools that have > to grok the archive (mirror tools, debian-cd, etc.). I'm not going to > try and veto having things in more than one component, but (ugh!) I > really think it's ugly. Actually, I think I'd much prefer Santiago's > idea: > > > Couldn't we handle this via transitional firware* non-free packages, > > that depend on bookworm non-free-firmware packages? > > We'd need to add some transitional binary packages for the small > number of n-f-f source packages. That way people would get errors from > apt if they don't read our warnings and update. Maybe this is a way > forward? > I don't think that will work well, the packages will likely just be held at the old version if the new ones are uninstallable because the new component isn't enabled. Cheers, Julien
Re: Firmware GR result - what happens next?
On Sun, Oct 02, 2022 at 08:21:31PM +0100, Steve McIntyre wrote: > On Sun, Oct 02, 2022 at 11:08:47AM -0400, Michael Stone wrote: > >On Sun, Oct 02, 2022 at 03:53:00PM +0100, Steve McIntyre wrote: > >> On Sun, Oct 02, 2022 at 04:43:47PM +0200, Michael Biebl wrote: > >> > What's the plan for upgraded systems with an existing > >> > /etc/apt/sources.list. > >> > Will the new n-f-f section added on upgrades automatically(if non-free > >> > was > >> > enabled before)? > >> > >> So this is the one bit that I don't think we currently have a good > >> answer for. We've never had a specific script to run on upgrades (like > >> Ubuntu do), so this kind of potentially breaking change doesn't really > >> have an obvious place to be fixed. > > > >Is there a reason to not continue to make the packages available in non-free? > >I don't see a reason to force any change on existing systems. > > Two things: > > 1. I'm worried what bugs we might expose by having packages be in two > components at once. > 2. I really don't like the idea of leaving two different > configurations in the wild; it'll confuse people and is more > likely to cause issues in the future IMHO. > > Plus, as Shengjing Zhu points out: we already expect people to manage > the sources.list anyway on upgrades. > I think in the absence of a release upgrade script (which I very much doubt will happen, and be tested, and we can rely will be used, for bookworm), Michael's suggestion seems like a reasonable way forward. I imagine we'll need to patch dak to allow that, but it seems like it should be tractable? Cheers, Julien
Re: proposed MBF: packages still using source format 1.0
On Sun, Mar 13, 2022 at 02:58:31PM -0700, Sean Whitton wrote: > Hello, > > On Wed 09 Mar 2022 at 05:15PM +01, Lucas Nussbaum wrote: > > > On 09/03/22 at 08:52 -0700, Sean Whitton wrote: > >> On Wed 09 Mar 2022 at 01:08pm +01, Lucas Nussbaum wrote: > >> > Also, how would that work with packages that combine direct changes to > >> > upstream, and quilt for Debian-created patches? > >> > >> Could you expand? I didn't think this category was one of the ones Russ > >> and I were talking about. > > > > My limited understanding of the landscape of git workflows is that a > > workflow that is quite popular among packages still using the 1.0 format > > is the one used by the Debian X strike force. Julien Cristau described > > it as follows when I asked about it on IRC: > > > > < jcristau> [...] basically, for upstream patches we cherry-pick > > commits directly, and we use quilt for changes that aren't upstream > > Ah right, thank you. I wasn't really thinking of this case as being > about git workflows. Are the repos patches-applied or > patches-unapplied? > The patches that we keep in quilt are not applied in the repo. (Obviously the cherry-picked patches are.) Cheers, Julien
Re: Cloud team plans for cloud-hosted mirrors
On Wed, Jan 26, 2022 at 09:43:16PM -0800, Ross Vandegrift wrote: > On Wed, Jan 26, 2022 at 07:58:23PM +0100, Julien Cristau wrote: > > I think we (DSA) have been reluctant to add new third-party-run services > > under debian.org, and it's not clear to me if that infrastructure would > > be run by the cloud team on behalf of debian, or if the cloud team would > > control the names but point them at mirrors run by the cloud providers > > themselves. > > It depends on the provider, and what you mean by "infrastructure". Many cases > fall into a grey area between your options: > > - AWS: the mirror will be a CloudFront distribution. SPI will own the > account, > the cloud team will create the CDN, but the infrastructure will be AWS. > - Azure, Infomaniak: they contract or employ folks to run mirrors for them. > Cloud team folks are responsible in both cases. > > Speaking for myself only, I'd be be open to providing a name for a provider > that doesn't work with us, and runs their own mirror. This would definitely > not meet your requirement. > Sorry for being unclear. For these purposes the first case would count as debian-run, the second probably not. Either way a couple of things to think about and maybe document is what are the criteria for providing a name for a vendor, and what happens when the criteria are no longer met. Cheers, Julien
Re: Cloud team plans for cloud-hosted mirrors
On Tue, Jan 25, 2022 at 09:47:49PM -0800, Ross Vandegrift wrote: > Hello, > > The cloud team wants to make folks aware of a possible change to the cloud > images. The team plans to register a new domain, debian.cloud, for mirrors > inside of cloud provider infrastructure. For such mirrors, sources.list will > look like: > deb http://.debian.cloud/debian/ bullseye main > > Hosting mirrors inside the cloud infrastructure provides users with faster, > cheaper access to the archive. And since it saves the providers money, > they're > often willing to provide the hosting infrastructure for free. Our image build > process allows customizing sources.list with these mirrors when possible. All > of this is great! > > But some of the hostnames are controlled by the cloud providers. Mostly, this > has happened when the name is assigned by a CDN. This isn't optimal: if that > name ever changes, users with the old hostname will be unable to install > packages. > > These names have been very stable. But in some providers, they're tied to > cloud accounts. This makes it impossible to move the mirror to another > account > without losing the name. And of course, for reasons [1], we need to move some > of these mirrors. > > Since a migration is required, we'd like to adopt debian-controlled hostnames > in sources.list. This way, we can never lose the hostnames that appear in > sources.list. > > Our first choice would be a subzone of debian.org. But we are not in DSA, and > haven't been able to get help with this request. So in the interest of making > progress, a new domain is the simplest alternative. > > I don't know when this work will be complete - hopefully, all of the new > infrastructure will be ready to go for the next stable release. > Hi, I think we (DSA) have been reluctant to add new third-party-run services under debian.org, and it's not clear to me if that infrastructure would be run by the cloud team on behalf of debian, or if the cloud team would control the names but point them at mirrors run by the cloud providers themselves. Either way as Stefano said if you go for a new domain name it should be possible to use the same setup as our other domains if you want. Cheers, Julien
Re: Deps of -dev packages with pkg-config .pc file: Policy Change?
This is all pretty straightforward. If foo.pc in libfoo-dev references bar.pc that lives in libbar-dev, then libfoo-dev needs a dependency on libbar-dev, and the missing dependency is a serious bug. That has been the case for as long as I remember, and doesn't require more long discussions or policy changes IMO. Libs.private is a bit different because static linking is not typically used for Debian packages, but Requires and Requires.private are quite clear cut. Cheers, Julien On Thu, Dec 09, 2021 at 03:24:27PM +0100, Alexander Traud wrote: > Linux distributions, which have separate packages for developers, like > Debian, are not really supported [1] by the developer tool pkg-config > [2]. The problems are C/C++ libraries which depend on other libraries at > runtime. Let us pick one, a security library for utilizing DNSSEC: > > $ sudo apt install libunbound-dev > $ pkg-config --print-errors --short-errors --cflags libunbound > $ pkg-config --print-errors --short-errors --exists libunbound > Package 'hogweed', required by 'libunbound', not found > > 1) The error message is misleading because pkg-config talks about the > *runtime* package 'hogweed', although (in Debian) a *-dev* package is > required to get the .pc file. Should I report that, where? > > 2) In this case, the package name is not simply an added '-dev' like > 'hogweed-dev'. Instead, the developer has to search the contents of all > packages [3] for the file 'hogweed.pc'. That is part of the package > 'nettle-dev'. > > 3) Are 'nettle-dev' (and 'libevent-dev', by the way) missing > dependencies of 'libunbound-dev'? > > The latter seems to be an ongoing question on debian-devel [4] if the > package includes a static library '.a' as libunbound-dev still does. At > least I found no conclusive answer. Position No: It is not a missing > dependency because I can use that package perfectly (as a shared > library) without pkg-config. Position Yes: pkg-config has to be > required, recommended, suggested - for each level of dependency, you > find an argument on debian-devel, see [5][6][7][8]. > > 16 years. This topic has come up for 16 years now, again and again on > the mailing list debian-devel, documenting the uncertainty of package > maintainers. Furthermore, bug reports come in, again and again for that > topic. Again, libunbound-dev as example for the Debian bug report [9]: > Upstream, in the pkg-config .pc file, the maintainer moved the libraries > from 'Requires' to 'Requires.private'. That was the correct approach. > However, the maintainer closed the Debian bug report because he falsely > believed to have fixed the issue that way. > > Requires -> -I/subfolder -lfuu, avoid if possible, see [10] > Requires.private -> -I/subfolder , a header includes that header > Libs -> -lfoo, lib itself > Libs.private -> -lfuu, exclusively for static linking > Cflags -> -I/subfolder , lib headers itself and/or > header includes that header > > Any idea how to approach this? > a) Leave as is. Do not depend on 'Require.private' automatically because > the package can be used without pkg-config. Only depend on other -devs > if one of those headers is included in a header. > b) Fix/convert. Upstream, move everything into 'Requires.private'. > Downstream, in the Debian package, remove 'Requires.private' and convert > to 'Libs.private'; again, except if one of those headers is included in > a header. > > These uncertainties create repeated frustration, even for core Debian > members. Proposal: Why not decide, or at least give a recommendation on > these questions: > > i) pkg-config tool itself: When is it a depend (which dep level?), and > when not? My suggestions: Because I can use a '-dev' package without any > tool, because of the FHS, just -lfoo should be needed [11]. > > ii) .pc file and its 'Require': Leave it or change it? My suggestion: > Report upstream that those libs have to be moved to 'Requires.private'. > > iii) .pc file and its 'Require[.private]': Depend on each lib? My > suggestion: Only if the headers include it. For Debian, convert all > others to 'Libs.private' because the built '.a' file (for static > linking) has a known dependency tree. This gets a Debian patch in that > source package. > > iv) Cflags: If I got it correctly, back in the year 2005, the cause of > this drama were -I flags [12]; if the header included another header, > and that header included further headers but was not in the root but in > a subfolder, an -I flag *might* be required. For example, the package > 'libopusfile-dev' has its header file in '/usr/include/opus/opusfile.h' > with #include which is part of the package > 'libopus-dev' and is not within '/usr/include/' but within > '/usr/include/opus/'. Therefore, > $ pkg-config --cflags opusfile > -I/usr/include/opus > > After reading, understanding, and
Re: Q: Use https for {deb,security}.debian.org by default
On Sat, Aug 21, 2021 at 10:28:04AM +0200, Wouter Verhelst wrote: > On Thu, Aug 19, 2021 at 10:11:33PM +, Jeremy Stanley wrote: > > On 2021-08-19 16:37:13 -0400 (-0400), Kyle Edwards wrote: > > > On 8/19/21 3:46 PM, Simon Richter wrote: > > > > For the most part, users would configure https if they are behind a > > > > corporate firewall that disallows http, or modifies data in-flight so > > > > signature verification fails, everyone else is better off using plain > > > > http. > > > > > > Or they might configure https on the sheer principle of not wanting to > > > have > > > their traffic hoovered up by their ISP or anyone else who might be > > > listening. > > > > While this does complicate it, a snooping party can still know the > > site they're connecting to via SNI happening unencrypted, > > SNI is not unencrypted if you do TLS1.3... > It is, though... ECH (née ESNI) https://datatracker.ietf.org/doc/draft-ietf-tls-esni/ is still WIP. Cheers, Julien
Re: Proposed mass-bug filing: missing support for build-arch or build-indep
On Mon, Apr 19, 2021 at 03:11:21PM +0200, Lucas Nussbaum wrote: > Hi, > > I would like to propose a mass bug filing on source packages that miss > support for build-arch or build-indep targets in debian/rules. > > Those targets were made mandatory in Debian Policy 3.9.4 (released in > August 2012). From the changelog: > * build-arch and build-indep are now mandatory targets in debian/rules, > implementing the Technical Committee ruling in #629385. Wording > review by Jonathan Nieder, Jakub Wilk, and Roger Leigh. > (Closes: #374029) > > There are currently 411 packages in testing that do not include those > targets, according to lintian's debian-rules-missing-recommended-target > tag. (I will also file a bug against lintian to reflect that those > targets are now required). > I think you should start with a lower severity and consider bumping it to serious once you're down to a manageable number (and possibly a couple of NMU campaigns). Cheers, Julien
Re: Missing samba DSA-4513 changelog in https://metadata.ftp-master.debian.org/changelogs/
On Wed, Apr 07, 2021 at 02:49:49PM +0200, Ben Hutchings wrote: > On Wed, 2021-04-07 at 20:07 +0900, Hideki Yamane wrote: > > Hi, > > > > I cannot find appropriate pseudo package in reportbug, so ask this > > in -devel. > > > > Fumiyasu (CCed) found a issue with samba package changelog in > > packages.d.o. > > https://packages.debian.org/buster/samba has "Debian Changelog" link > > but its > > https://metadata.ftp-master.debian.org/changelogs//main/s/samba/samba_4.9.5+dfsg-5+deb10u1_changelog > > link is 404. > > The latter site is part of the main archive and does not have > information about package versions that are only in the security > archive. > > Packages uploaded to the security archive are normally copied to the > (old)stable-proposed-update suite of the main archive, so long as that > is open, i.e. until the last point release. So it looks as if the copy > to the main archive failed for some reason. > The samba package is held in stable-new by bug#939419, see https://release.debian.org/proposed-updates/stable.html Cheers, Julien > > Something wrong with > > https://metadata.ftp-master.debian.org/changelogs/ , > > that doesn't have the changelog were introduced with DSA 4513-1 as > > > > https://tracker.debian.org/news/1061236/accepted-samba-2495dfsg-5deb10u1-source-into-stable-embargoed-stable/ > > > > Also, why DSA 4513-1 is not included in Debian10.2 ? > > See https://www.debian.org/News/2019/20191116 > > Because the package didn't get copied to the main archive. > > The common reason why this may fail is that a maintainer uploads a > different orig tarball to the security archive. However, the two > versions agree on the checksums of the orig tarball. I would take this > up with the FTP team. >
Re: Bug#984811: ITP: openbgpd -- Free, functional, and secure implementation of the BGP-4 protocol.
On Mon, Mar 08, 2021 at 05:13:35PM +0100, Job Snijders wrote: > Dear Julien, > > > > Description : Free, functional, and secure implementation of the > BGP-4 protocol. > > the above short description has 3 useless words in it, I suggest you drop > them. > > If it wasn't free it wouldn't be in Debian; if it wasn't functional why > would anyone release or package it; same with "secure", plus it's a > rather meaningless descriptor that'll be wrong the day somebody finds a > bug (especially combined with "implemented in C"...). > > > Thank you for your feedback. > > I'll change the short description to "OpenBSD BGP-4 daemon" > Sounds good, thanks! Cheers, Julien
Re: Bug#984811: ITP: openbgpd -- Free, functional, and secure implementation of the BGP-4 protocol.
On Mon, Mar 08, 2021 at 04:51:14PM +0100, Job Snijders wrote: > Package: wnpp > Severity: wishlist > Owner: Job Snijders > X-Debbugs-Cc: debian-devel@lists.debian.org > > * Package name: openbgpd > Version : 6.8p1 > Upstream Author : OpenBSD tech mailing list > * URL : http://www.openbgpd.org/ > * License : ISC > Programming Lang: C > Description : Free, functional, and secure implementation of the BGP-4 > protocol. > Hi, the above short description has 3 useless words in it, I suggest you drop them. If it wasn't free it wouldn't be in Debian; if it wasn't functional why would anyone release or package it; same with "secure", plus it's a rather meaningless descriptor that'll be wrong the day somebody finds a bug (especially combined with "implemented in C"...). Cheers, Julien
Bug#982562: general: Storing upstream signatures next to upstream tarballs is problematic
On Thu, Feb 11, 2021 at 09:59:42PM +0100, Raphaël Hertzog wrote: > Those files are not really meant to be immutable: > - signing keys can expire and be revoked, upstream might want to update > signatures of already released tarballs > - the set of "upstream release managers" might evolve over time and the > official signature to use might change... > As far as we're concerned they are immutable, they are the signature of the tarball at the time that tarball was uploaded to debian. There's no reason for that to change without the tarball itself changing, at which point both filenames change. Cheers, Julien
Re: Bug#981994: ITP: xserver-xorg-input-aiptek -- X.Org X server -- Aiptek input driver
On Fri, Feb 05, 2021 at 06:03:57PM +0200, Adrian Bunk wrote: > Package: wnpp > Severity: wishlist > Owner: Adrian Bunk > > Package name: xserver-xorg-input-aiptek > Description : X.Org X server -- Aiptek input driver > > Adopting X drivers that were removed in #955603 despite many objects. > These hardware drivers belong in the kernel. Do aiptek USB devices not show up as regular input devices that generic userspace drivers can handle? Cheers, Julien
Re: Bug#981113: ITP: root -- open-source data analysis framework
On Tue, Jan 26, 2021 at 04:34:14PM +0100, Stephan Lachnit wrote: > Package: wnpp > Severity: wishlist > Owner: Stephan Lachnit > X-Debbugs-Cc: debian-devel@lists.debian.org, stephanlach...@protonmail.com, > debian-scie...@lists.debian.org > > * Package name: root [...] > > I want to maintain ROOT in the science team. ROOT was already in Debian as > `root-system` [1], but hasn't been updated since 2015. > I will probably go with a more easy maintainable route like I did with Geant4 > for the start and do package splitting later. > > [1] https://tracker.debian.org/pkg/root-system > Please re-use the old name. "root" is a terrible choice of package name. Thanks, Julien
Re: RFC: raising ca-certificates package Priority to standard or important
Hi Antonio, On Thu, Jan 21, 2021 at 02:47:25PM -0300, Antonio Terceiro wrote: > On Thu, Jan 21, 2021 at 03:10:47PM +0100, Julien Cristau wrote: > > And which of standard or important made most sense (AIUI, standard > > means "installed by default in d-i" and important means "installed by > > default in debootstrap"). > > wget is already Priority: standard and recommends ca-certificates, so it > seems to me that making it standard would be a noop in practice for most > of the systems installed by d-i. > > On the other hand, all cases that I remember seeing a problem caused by > missing ca-certificates was in systems not installed by d-i, such as > containers, vm images, etc. Based on that, I would make it important. Here's my thinking on this: I would expect "standard" to get installed on "general purpose" VM images, and "important" *not* to get installed on "minimal" container or VM images. Looking at the docker debian image build script just now[1], it seems to pull in required packages + iproute2 and ping, so it has its own selection that doesn't include "important" priority. So changing the severity, by itself, won't change anything unless we go all the way to "required" which feels like it'd be going too far (but then I also don't think apt should be "required"). If there are specific examples where you think "important" would help I'd be interested; right now I'm sort of favouring "standard" as good enough. [1] https://github.com/debuerreotype/debuerreotype/blob/master/examples/debian.sh Cheers, Julien
RFC: raising ca-certificates package Priority to standard or important
[bcc: {openssl,ca-certificates}@packages.d.o]
Hi,
the ca-certificates package is currently "Priority: optional", like most
of the archive. It's Recommended by a bunch of packages, Depended on by
an equivalent number, but I'm not sure if this is optimal. I suspect
most packages can be configured to use a different trust store; and that
in many deployments you may want to use a private PKI, or limit trust to
a specific subset of the global public CAs, so in that sense `Depends'
on ca-certificates is not quite correct. On the other hand it's less
likely to run into "user disabled Recommends, and run into unexpected TLS
server auth failures" kind of situations.
So I'd like to raise the priority of ca-certificates from optional to
at least standard, as a signal that it should be installed on
non-minimal Debian systems. I'll note that ca-certificates depends on
the openssl binary package which would thus effectively also become
standard (or important, if we go that route), if it isn't already.
Before asking ftpmasters to make that change I wanted to ask this group
if there were downsides to it that I haven't considered. And which of
standard or important made most sense (AIUI, standard means "installed
by default in d-i" and important means "installed by default in
debootstrap").
Thanks,
Julien
Re: Architecture: all binNMUs (was: deduplicating jquery/)
On Tue, Dec 01, 2020 at 10:56:28AM +, Simon McVittie wrote:
> Possible solutions:
>
> - Change at least 622 packages so they have something more like
> Depends: foo-data (>= ${source:Version}), foo-data (<< ${source:Version}+c)
> (also hope that all of their maintainers can get those runes right, taking
> into account what the binNMU suffix is, and hope that it won't break
> derivatives like Ubuntu that use a source-upload suffix like ubuntu1 that
> compares less than +b1)
>
> - Change at least 622 packages so that when foo-data is binNMU'd, it
> automatically gets Provides: foo-data (= 1.2-3)
>
> - Change some more central component so that the dependencies are edited
> or the Provides is added globally
>
> - Something clever that I haven't thought of
>
Make no-change-other-than-version-bump source uploads easier?
Cheers,
Julien
Re: Question for alioth-lists.debian.net status
On Sat, Apr 25, 2020 at 00:51:34 +0800, Shengjing Zhu wrote: > And another question for DSA is, whether the lists.alioth.debian.org > address is expected to work, as long as the alioth-lists.debian.net > exists? > I don't see a reason to break it. Cheers, Julien
Re: RFC: Replacing vim-tiny with nano in essential packages
On Mon, Mar 16, 2020 at 11:06:11AM +0100, John Paul Adrian Glaubitz wrote: > Debian Ports is affected by this problem in particular because we don't have > the cruft feature in mini-DAK [3], so every time I build a debian-installer > image and forget checking whether vim build successfully on every > architecture, > the particular debian-installer image becomes unusable because debootstrap > cannot install vim-tiny as its version mismatches the version of vim-common. > The debian-ports archive maintainers could decide to change vim-tiny's priority on their side, without imposing that decision on the debian archive. Cheers, Julien
Re: Migration to testing blocked by broken piuparts?
On Thu, Jan 2, 2020 at 12:03:43 +0100, W. Martin Borgert wrote: > Hi, > > two packages[¹, ²] I uploaded are "Rejected due to piuparts > regression". I learned, that this is due to a bug in piuparts. > Any solution on its way? Would I need to re-upload later? > No, it'll eventually get retried and (assuming it passes) the migration block will lift. Cheers, Julien
Re: Mozilla Firefox DoH to CloudFlare by default (for US users)?
On Tue, Sep 10, 2019 at 08:24:03 +0200, Ondřej Surý wrote: > > On 9 Sep 2019, at 15:31, Bjørn Mork wrote: > > > > I for one, do trust my ISPs a lot more than I trust Cloudflare or > > Google, simply based on the jurisdiction. > > While I still strongly agree with you on this one (even though I think all > major ISPs here are scumbags, especially the incumbent), I still strongly > think we should not have this debate here, and we should turn this around > the usual Debian policy - to not send data to 3rd party without explicit user > content and defaulting to not doing so. > How is this worse than what we're already doing by default, namely sending the same data to whoever happens to be on the network, in addition to whoever happened to be listed in an unauthenticated dhcp response? (Which, if you're lucky, is your ISP, aka a 3rd party.) Cheers, Julien
Re: buster backports question/status
On Wed, Jul 10, 2019 at 11:29:01 +0200, olivier sallou wrote: > Le mer. 10 juil. 2019 à 11:08, Andrey Rahmatullin a > écrit : > > > 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. > > > > 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. > > Is the problem linked to buster-backports not existing yet ? Is backports > repo not created automatically on new releases? > buster-backports exists. AIUI this is an apt bug when dealing with empty repos. (Although why are you setting default-release to buster-backports?) Cheers, Julien
Re: Bug#824495: Use of the Build-Conflicts field
On 2/16/19 7:08 AM, Scott Kitterman wrote: > On Friday, February 15, 2019 08:59:41 PM Sean Whitton wrote: >> Hello, >> >> Use of the Build-Conflicts field is currently mostly optional, but Ian >> Jackson and I have been working on text for Debian Policy that would >> require its use in certain cases. See #824495 for the discussion. >> >> There are two cases which we think that everyone would agree that there >> is a bug, but we are not sure that the bug would be considered to be RC. >> We are posting to -devel to see if, in fact, we do have a consensus that >> these bugs would be RC, or not. >> >> (1) a package FTBFSs when: another package that is part of a "reasonable >> standard development workstation install" is present, but the first >> package does not declare a Build-Conflicts against the second >> >> (2) a package FTBFSs when: a package that is NOT part of a "reasonable >> standard development workstation install" is present, but the first >> package does not declare a Build-Conflicts against the second >> >> Is (1) an RC-severity bug in the package that FTBFSs? Is (2)? >> >> It is worth noting that in both cases, the fix is highly non-disruptive >> to maintainer workflows: you just add the build-conflicts metadata. But >> how easy it is to fix the bug does not determine whether or not that bug >> is RC. >> >> For the purposes of this e-mail, let's assume that we have a good grasp >> on what a "reasonable standard development workstation install" means. > > I'll bite. > > I think "reasonable standard development workstation install" is the wrong > class of standard (whether I have a grasp on it or not). If it's not going > to > cause an FTBFS on a buildd, I think it's not RC. That would limit it to > packages that are build-depends (direct or indirect) of other packages, i.e. > no leaf packages. > > So my answer to both your questions is no. > +1 I'd say (1) and (2) range somewhere from minor to normal severity. Cheers, Julien
Re: Reusing source package name of long-removed, unrelated package
On 2/6/19 4:31 PM, Gard Spreemann wrote:
>
> Ian Jackson writes:
>
>> Gard Spreemann writes ("Reusing source package name of long-removed,
>> unrelated package"):
>>> I understand that 3.3.2 of the policy mandates that I at least bump the
>>> epoch, but I wanted to ask the list to make sure: is reusing the source
>>> package name of an unrelated, long-removed package like this OK, or
>>> should I consider using a different name?
>>
>> I would recommend using a different source package name.
>
> Thanks for your input. I'll wait a bit and see if there are other
> opinions before renaming the source.
>
> By the way, is it OK if the (renamed) source package produces a binary
> package with the same name as one of those produced by the old source?
>
I would say reusing binary package names is usually worse than reusing
source package names, in that it's a lot more likely to affect users.
Sometimes it happens anyway, but IMO it's best avoided.
Cheers,
Julien
Re: Bug#913976: ITP: python-hgapi -- module providing a pure-Python API to Mercurial
On 11/17/18 9:23 PM, Nick Morrott wrote: > Package: wnpp > Owner: Nick Morrott > Severity: wishlist > X-Debbugs-CC: debian-devel@lists.debian.org > > * Package name: python-hgapi > Version : 1.7.3 > Upstream Author : Fredrik Håård > * URL : https://github.com/haard/hgapi > * License : Expat > Programming Lang: Python > Description : module providing a pure-Python API to Mercurial > > hgapi is a pure-Python API to the Mercurial command-line, instead of the > internal Mercurial API. > > hgapi works for all versions of Mercurial, and will instantly reflect any > changes to the repository (including hgrc). > > hgapi is a dependency of yotta [1] > > [1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=908781 > Is there a particular reason yotta needs to use this instead of hglib, which: - is already in debian - is maintained by mercurial upstream - has pretty much the exact same package description as the above ? This seems like useless duplication. Thanks, Julien
Re: Perl 5.28 transition underway
On 12/7/18 4:34 PM, Cyrille Bollu wrote: > The URL https://release.debian.org/transitions/html/perl5.28.html is > 404 :-( > With Perl 5.28 in testing, the transition is over. Cheers, Julien
Re: Deployment of buildd machines [was: Re: usrmerge -- plan B?]
On 11/28/18 2:26 PM, Daniel Reichelt wrote: > On 11/22/18 1:56 PM, Ian Jackson wrote: >> (Bear in mind of course that happily our build machines >> *can* be reverted because they are frequently re-imaged.[…]) > > Using code from a debian package? Some script being hand-knitted using > hot needles? Anyways, I'm interested in how this is done…"this" meaning > the imaging/deployment part. Not the setup/configuration of a buildd itself. > The machines are not re-imaged. The build chroots are regenerated, with something more or less equivalent to sbuild-createchroot(8). https://salsa.debian.org/dsa-team/mirror/dsa-puppet/tree/master/modules/schroot/ Cheers, Julien
Re: Upcoming Qt switch to OpenGL ES on arm64
On 11/23/18 12:18 PM, Dmitry Shachnev wrote: > On Thu, Nov 22, 2018 at 11:05:27PM +0100, Julien Cristau wrote: >> At least mesa drivers can be used for desktop GL or GLESv2 just fine, >> AFAIK. Maybe the answer for Qt is to switch to GLESv2 for all >> architectures, to stop the special-casing madness, instead of making it >> spread? :) > > According to config_help.txt [1], Qt uses ES2 by default on Windows. > It probably means that it will work fine with most desktop video cards. > > But as Lisandro says, such a change in Debian will break many packages > (which are currently broken on ARM only), so we are definitely not > considering it at this point. > Why is it OK to break them on arm64 if it's not OK to break them on amd64? Do you have a list of those packages? Cheers, Julien
Re: Upcoming Qt switch to OpenGL ES on arm64
On 11/22/18 10:30 PM, Marcin Juszkiewicz wrote: > W dniu 22.11.2018 o 19:37, Dmitry Shachnev pisze: > >> The Qt framework can be built either with “desktop” OpenGL, or with OpenGL ES >> support. At the moment we are building it with OpenGL ES on armel and armhf, >> and with desktop OpenGL on all other architectures. >> >> However we have received a request [1] from two different persons to add >> arm64 >> to the list of architectures where OpenGL ES is used. >> >> We want your feedback! If you are using an arm64 device or board with Qt, >> please let us know your opinion about this change, by replying to this mail >> or to [1], and describe your use case. > > Does it mean that arm64 box with PCI Express graphics card will be not > able to use Qt based software? I can put Radeon or NVidia card into my > box and use it as a normal OpenGL accelerated desktop (did that already > few years ago). > At least mesa drivers can be used for desktop GL or GLESv2 just fine, AFAIK. Maybe the answer for Qt is to switch to GLESv2 for all architectures, to stop the special-casing madness, instead of making it spread? :) Cheers, Julien
Re: Updating the policy for conflicting binaries names ? [was: Re: Re: New package netgen-lvs with binary /usr/bin/netgen - already taken]
On 09/09/2018 03:46 AM, Guillem Jover wrote: > Hi! > > On Sat, 2018-09-08 at 20:18:10 +0200, Sylvestre Ledru wrote: >> Le 08/09/2018 à 18:39, Sean Whitton a écrit : >>> On Fri 07 Sep 2018 at 10:10PM +0200, Ruben Undheim wrote: However, I think the policy gives us a lot of freedom to choose (it is not very strict in this case). >>> >>> I don't understand. This seems pretty strict: >>> >>> Two different packages must not install programs with different >>> functionality but with the same filenames. > >> I think the policy should be changed. > > I'd very very strongly oppose any such change. > Ditto. Cheers, Julien
Re: Browserified copy and DFSG
On 09/05/2018 04:38 PM, Bastien ROUCARIES wrote: >>> Browserify (or webpack) is a static compiler for javascript. I believe >>> that we must use built-using field in order to be policy compliant. >>> [...] > But I was thinking Built-Using may be used by security team in order > to trigger rebuild. > That should not be necessary. If we really needed that information (which seems unlikely to me), buildinfo files can provide it. Otherwise we'd set built-using to "everything in the build chroot" for every single package, and that doesn't seem like something we want or need to do. browserify doesn't seem to be that special, IMO. Cheers, Julien
Re: HELP WANTED: security review / pam experts for su transition
On 08/12/2018 04:58 PM, Andreas Henriksson wrote: > Hello again, > > My previous mail didn't result in any feedback, so let me try again > with some more detailed questions that might be easier to discuss > related to the PAM configuration of su (and su-l). > FWIW I'm not sure -devel is very likely to be read by the people who'd have useful input for you, you may want to reach out to a more narrow list or group of people instead. For what it's worth, I don't think pam_xauth is a good idea in the su pam config. (I don't think copying DISPLAY and XAUTHORITY was, either.) Cheers, Julien
Re: Debian 9.5 Installer
On 08/11/2018 07:52 PM, Russ Allbery wrote: > Carl-Valentin Schmitt writes: > >> Apparently the installer compels each time before Installation to delete >> hard disk too slowly. > >> It should be optional to delete (slowly) the harddisk or to format >> harddisk quickly. > >> In 9.5 installer there is no option for formatting without deleting. > > You can just cancel that step and move on. (But I am also dubious of its > utility in most situations, and wish it weren't the default or that at > least one was given a prompt first.) > > I think a better place to file this issue is as a bug report against > debian-installer (and I suspect there may already be one). > A previous iteration on this was https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=722898 Cheers, Julien
Re: Is Access to Salsa restricted to a certain number of queries per time and host?
On 07/11/2018 04:51 PM, Andreas Tille wrote: > On Wed, Jul 11, 2018 at 01:34:29PM +0200, Julien Cristau wrote: >> >> You could probably save yourself some trouble by not polling repos that >> have had no activity since you last looked at them. > > Is there any smart way to obtain the latest activity time stamp? I don't know about smart, but each project has a last_activity_at attribute which I'm assuming is an overapproximation of repository activity. >> You're also right that salsa support issues don't really belong on this >> list. > > I'm happy that I explicitly mentioned this since it seems to help > avoiding misinterpretations of my mails. > Does it? I still don't get why this is here. Cheers, Julien
Re: Is Access to Salsa restricted to a certain number of queries per time and host?
On 07/11/2018 10:18 AM, Andreas Tille wrote: > Hi, > > I'm running a daily cron job on host blends.debian.net to gather machine > readable data from all blends packages. The cron job fetches only the > following files > > debian/changelog > debian/control > debian/copyright > debian/README.Debian > debian/upstream/edam > debian/upstream/metadata > > (if the latter two exist) from about 2000 repositories. These data are > consumed in UDD from where they are used in the Blends web sentinel. The > script which is running can be found in Git[1]. > > Unfortunately the cron job seems to stop with > > Traceback (most recent call last): > File "/usr/lib/python3/dist-packages/gitlab/exceptions.py", line 251, in > wrapped_f > return f(*args, **kwargs) > File "/usr/lib/python3/dist-packages/gitlab/mixins.py", line 48, in get > server_data = self.gitlab.http_get(path, **kwargs) > File "/usr/lib/python3/dist-packages/gitlab/__init__.py", line 728, in > http_get > streamed=streamed, **kwargs) > File "/usr/lib/python3/dist-packages/gitlab/__init__.py", line 706, in > http_request > response_body=result.content) > gitlab.exceptions.GitlabHttpError: 429: b'Retry later\n' > > During handling of the above exception, another exception occurred: > > Traceback (most recent call last): > File > "/srv/blends.debian.org/misc/machine_readable/fetch-machine-readable_salsa.py", > line 106, in > project = gl.projects.get(pr.attributes['id']) # without this extra get > repository_tree() fails > File "/usr/lib/python3/dist-packages/gitlab/exceptions.py", line 253, in > wrapped_f > raise error(e.error_message, e.response_code, e.response_body) > gitlab.exceptions.GitlabGetError: 429: b'Retry later\n' > You could probably save yourself some trouble by not polling repos that have had no activity since you last looked at them. You're also right that salsa support issues don't really belong on this list. Cheers, Julien
Re: Mass filing on Python 3.7 async module import?
On 07/10/2018 03:50 PM, Thomas Goirand wrote: > On 07/09/2018 11:03 PM, Adrian Bunk wrote: >> On Mon, Jul 09, 2018 at 02:33:18PM +0200, Thomas Goirand wrote: >>> On 07/08/2018 12:36 PM, Emilio Pozuelo Monfort wrote: List of affected packages: openscap-daemon: /usr/lib/python3/dist-packages/openscap_daemon/async.py pylint3: /usr/lib/python3/dist-packages/pylint/checkers/async.py python3-astroquery: /usr/lib/python3/dist-packages/astroquery/vo_conesearch/async.py python3-celery: /usr/lib/python3/dist-packages/celery/backends/async.py python3-dropbox: /usr/lib/python3/dist-packages/dropbox/async.py python3-exabgp: /usr/lib/python3/dist-packages/exabgp/reactor/async.py python3-gunicorn: /usr/lib/python3/dist-packages/gunicorn/workers/async.py python3-ldap: /usr/lib/python3/dist-packages/ldap/async.py python3-mapproxy: /usr/lib/python3/dist-packages/mapproxy/util/async.py python3-opengl: /usr/lib/python3/dist-packages/OpenGL/GL/SGIX/async.py python3-opengl: /usr/lib/python3/dist-packages/OpenGL/raw/GL/SGIX/async.py python3-pexpect: /usr/lib/python3/dist-packages/pexpect/async.py python3-pylama: /usr/lib/python3/dist-packages/pylama/async.py python3-pymodbus: /usr/lib/python3/dist-packages/pymodbus/client/async.py python3-pymodbus: /usr/lib/python3/dist-packages/pymodbus/server/async.py python3-raven: /usr/lib/python3/dist-packages/raven/contrib/async.py python3-rpyc: /usr/lib/python3/dist-packages/rpyc/core/async.py python3-tenacity: /usr/lib/python3/dist-packages/tenacity/async.py salt-common: /usr/lib/python3/dist-packages/salt/utils/async.py visidata: /usr/lib/python3/dist-packages/visidata/async.py >>> >>> There's more than this. What you're reporting doesn't seem to include >>> packages defining the async function, for example gevent. I also saw >>> more than this list, just by trying to rebuild neutron-fwaas: >>> python3-oslo.db (we just fixed that one), python3-kafka, python3-pika, >>> python3-dogpile.cache (bug with fix already filled, we'll fix soon). >>> >>> I would anyway very much welcome a mass bug filling, but best would be >>> to try not to forget any package. Note that tenacity is already fixed. >> >> Note that "already fixed in unstable" is only part of the story. >> >> Most important will be Breaks for all affected packages in *stretch*, >> since there might otherwise be nasty problems in stretch->buster >> upgrades depending on the undefined order of package upgrades. > > Do you mean that the interpreter will have to declare Breaks: for the > affected packages? > Yes. Cheers, Julien
Re: Firefox 60esr on Stretch ?
On 05/03/2018 02:09 PM, Julien Aubin wrote: Hi Firefox 60esr is due for next week. As of now Debian Stretch is bound to Firefox ESR 52 which reaches EOL soon. The problem is that it becomes less and less usable as more and more extensions are becoming incompatible with it. On the other hand team mozilla.debian.net clearly states that Firefox 52 is not available on Stretch and all the xul-ext-* packages will have to be upgraded. So what's the future of Firefox in stable ? Can we expect to have the 60esr release and if so, when, or will we stick w/ 52esr ? If needed I can test it alongside upgraded xul-ext packages if you put it in proposed-updates or on mozilla.debian.net. debian-devel is the wrong place for your questions. I expect nothing much different from previous ESR cycles: stretch will move to 60 after 52 goes EOL in September. Cheers, Julien
Re: How to enable testing migration for packages Architecture: all but depending from Architecture: any packages
On 03/29/2018 10:19 AM, Andreas Tille wrote: > Hi, > > its not the first time that I'm running into that problem: A package > that is Architecture: all depends from packages Architecture: any. > These dependencies are not available on all architectures and thus the > package does not migrate to testing. The package paleomix is an example > for this[1]. I had a similar situation with metaphlan2 which was solved > by manual intervention of ftpmaster. I'm just wondering whether we > could find a better clue than forcing people to do manual intervention. > > While simply setting the Architecture: all package to any that > intervention would not be necessary but that's simply wrong. > Unfortunately I currently see no better solution and wanted to bring > this topic up here. > Make sure your arch:any package builds on at least amd64 and i386, which is where we check for arch:all packages installability. That should be pretty easy in all but the most exceptional cases. Cheers, Julien
Re: Extended Long Term Support for Wheezy
On Tue, Feb 20, 2018 at 22:42:46 +0100, Moritz Mühlenhoff wrote: > Raphael Hertzog wrote: > > some of the LTS sponsors are looking to extend the support period of > > Debian 7 Wheezy (from a few months up to a full year). > > > > Our question is whether this can be done on debian.org infrastructure. > > LTS has a clearly defined scope, while this is essentially contracting > work to extend the life time of some packages for some customers. > > I don't see a compelling reason for it to run on Debian infrastructure. > +1, FWIW. Cheers, Julien
Re: alpha porterbox ?
On Sat, Nov 18, 2017 at 15:01:25 +0400, Jerome BENOIT wrote: > Hello, > > one of my package, normaliz not to mention it, fails a test on the alpha > architecture: > I would like to dig the issue on a porterbox. Is there any porterbox for > alpha architecture ? > debian-alpha is the mailing list for the alpha port. Cheers, Julien
Re: Anyone using stretch/buster/sid on ARMv4t ?
On 11/05/2017 10:32 PM, Adrian Bunk wrote: > Hi, > > for the armel port in buster the question of raising the baseline came up. > > 20 years ago you could go into a shop and buy a mobile phone > with a CPU supported by the armel port in stretch. > > Roger Shimizu is doing a great job on ARMv5 hardware and I've seen bug > reports from users on ARMv5 hardware in stretch, so it is clear that > ARMv5 should stay supported (and of course also ARMv6 and ARMv7). > That's not clear to me at all. Keeping armel on life support for 2 more years is a significant drain on DSA and our hosters, for questionable benefit. Cheers, Julien
Re: New package, name recycling
On Fri, Oct 20, 2017 at 16:59:58 +0200, W. Martin Borgert wrote: > Hi, > > just to be sure, that this is not a problem: > > There used to be a package "dino" in Debian until jessie. Upstream > development dried up years ago and dino became extinct. > > Recently, a new "dino" appeared on the surface of earth, which is a > completely different program. Like git vs git or node vs node, but > with only one contender. > > I would package the new dino under this name, because I don't think > there is a conflict. > > Any objections? > I think reusing package names for a different purpose is very bad, in almost all cases. Pretty sure including this one. Cheers, Julien
Re: Mandates explicit -std=c++XY for c++ projects
On Tue, Oct 10, 2017 at 08:45:49 +0200, Mathieu Malaterre wrote: > Dear all, > > Since the GCC 6 release [1], the default mode for C++ is now > -std=gnu++14 instead of -std=gnu++98. What this means is that upon > (re)compilation a library written for c++98 will be recompiled using a > different c++ standard (c++14 in this case), unless of course the > upstream package explicitly set the -std= flags with the appropriate > c++ version. > > The ISO committee generally describe the change in between different > standards [2] and in some case, one can find examples of subtle change > in behaviors [3] and [4]. > > With this mind I'd like to make mandatory the -std=c++XY flags when > compiling either a c++ library or a stand-alone c++ program: > > 1. Either upstream define the explicit -std=c++XY flags by mean of its > build system, > 2. Or the package maintainers needs to explicit change the CXXFLAGS to > pass the appropriate version of the c++ standard. In which case this > should be documented in the README.Debian file. > 3. As a fallback, dh should initialize the CXXFLAGS with -std=gnu++98 > It might be useful to explain what problem you think that would fix. The above sounds to me like a step backwards. > If there is a consensus on the following change, I'll go ahead and > also file a bug for lintian to scan the compilation logs in search for > missing -std=c++ expression when g++ command line are issued. > lintian doesn't scan build logs, it scans source and binary packages. Cheers, Julien
Re: ftp master uploads disappearing?
On 09/25/2017 09:01 AM, Norbert Preining wrote: > Hi Dominique, > > (please Cc) > >> There was an outage on Debian server that happened Friday and Saturday. This >> isssue was announced on debian-infrastruture-announce. > > Ah, ok, thanks. Dropped, all of them. > >> I guess that your packages were either silently processed (check the PTS) or >> dropped. > > The same happened today, I uploaded calibre 3.8.0 and didn't get any > response whatsoever from the upload server. $ ssh usper.debian.org grep calibre_3.8.0 /srv/upload.debian.org/queued/run/log Sep 25 01:28:21 processing /calibre_3.8.0+dfsg-1_amd64.changes Sep 25 01:28:21 calibre_3.8.0+dfsg-1_all.deb is too small (ignored for now) Sep 25 01:33:22 processing /calibre_3.8.0+dfsg-1_amd64.changes Sep 25 01:33:22 calibre_3.8.0+dfsg-1_all.deb is too small (ignored for now) Sep 25 01:38:22 processing /calibre_3.8.0+dfsg-1_amd64.changes Sep 25 01:38:22 calibre_3.8.0+dfsg-1_all.deb is too small (ignored for now) Sep 25 01:43:23 processing /calibre_3.8.0+dfsg-1_amd64.changes Sep 25 01:43:24 calibre_3.8.0+dfsg-1_all.deb is too small (ignored for now) Sep 25 01:48:25 processing /calibre_3.8.0+dfsg-1_amd64.changes Sep 25 01:48:25 calibre_3.8.0+dfsg-1_all.deb has incorrect size; deleting it Sep 25 01:53:26 processing /calibre_3.8.0+dfsg-1_amd64.changes Sep 25 01:53:26 calibre_3.8.0+dfsg-1_all.deb doesn't exist (ignored for now) Sep 25 01:58:26 processing /calibre_3.8.0+dfsg-1_amd64.changes Sep 25 01:58:26 calibre_3.8.0+dfsg-1_all.deb doesn't exist (ignored for now) Sep 25 02:03:26 processing /calibre_3.8.0+dfsg-1_amd64.changes Sep 25 02:03:26 calibre_3.8.0+dfsg-1_all.deb doesn't exist (ignored for now) Sep 25 02:08:27 processing /calibre_3.8.0+dfsg-1_amd64.changes Sep 25 02:08:27 calibre_3.8.0+dfsg-1_all.deb doesn't exist (ignored for now) Sep 25 02:13:27 processing /calibre_3.8.0+dfsg-1_amd64.changes Sep 25 02:13:27 calibre_3.8.0+dfsg-1_all.deb doesn't exist (ignored for now) Sep 25 02:18:27 processing /calibre_3.8.0+dfsg-1_amd64.changes Sep 25 02:18:27 calibre_3.8.0+dfsg-1_all.deb doesn't exist (ignored for now) Sep 25 02:23:27 processing /calibre_3.8.0+dfsg-1_amd64.changes Sep 25 02:23:28 calibre_3.8.0+dfsg-1_all.deb doesn't exist (ignored for now) Sep 25 02:28:28 processing /calibre_3.8.0+dfsg-1_amd64.changes Sep 25 02:28:28 calibre_3.8.0+dfsg-1_all.deb doesn't exist (ignored for now) Sep 25 02:33:29 processing /calibre_3.8.0+dfsg-1_amd64.changes Sep 25 02:33:29 calibre_3.8.0+dfsg-1_all.deb doesn't exist (ignored for now) Sep 25 02:38:29 processing /calibre_3.8.0+dfsg-1_amd64.changes Sep 25 02:38:29 calibre_3.8.0+dfsg-1_all.deb doesn't exist (ignored for now) Sep 25 02:43:30 processing /calibre_3.8.0+dfsg-1_amd64.changes Sep 25 02:43:30 calibre_3.8.0+dfsg-1_all.deb doesn't exist (ignored for now) [skip more of the same] Cheers, Julien
Re: Running tests with xvfb
On Fri, Jul 28, 2017 at 22:46:57 +0200, Jeff wrote: > Running the test outside the chroot with xvfb still crashes X, because > xvfb seems to grab the "real" X if it is there. > > Is there a way of getting xvfb to ignore the system X? > Xvfb doesn't do anything with your regular X server so that can't be right. Cheers, Julien
Re: Bug#863605: ITP: python-pyserial -- serial port access library in Python
On 05/29/2017 10:22 AM, Ghislain Antony Vaillant wrote: > Package: wnpp > Severity: wishlist > Owner: Ghislain Antony Vaillant > > * Package name: python-pyserial > Version : 3.3 > Upstream Author : Chris Liechti > * URL : https://github.com/pyserial/pyserial > * License : BSD > Programming Lang: Python > Description : serial port access library in Python > > Long-Description: > This module encapsulates the access for the serial port. It provides > backends for Python running on Windows, OSX, Linux, BSD (possibly any > POSIX compliant system) and IronPython. The module named "serial" > automatically selects the appropriate backend. > > This package is a dependency to src:python-pymeasure. It will be > co-maintained by the Debian Science Team. > Sounds like this duplicates the existing python-serial package. Cheers, Julien
Re: 132 packages with several sources for stretch in the archive… (Re: Bug#860608: [pkg-golang-devel] Bug#860608: golang: FTBFS: Go version is "go1.6.1", ignoring -next /<>/api/next.txt)
On Fri, Apr 21, 2017 at 11:29:30 +, Holger Levsen wrote: > On Fri, Apr 21, 2017 at 01:00:20PM +0200, Lucas Nussbaum wrote: > > FYI, that's the number of additional copies of source packages in > > stretch, per source package: > > > > udd=> select source, count(*) from sources where release='stretch' and > > component='main' and extra_source_only group by source order by count > > desc; > [...] > > (132 rows) > > that's quite astounding (to me) and IMHO also quite bad… can we do something > to fix this for Buster at least? > It's actually quite good, for those that aren't false positive, that we're tracking them. Cheers, Julien
Re: vlc caused upgrade failure
On Fri, Apr 14, 2017 at 12:54:49 +0200, Rainer Dorsch wrote: > Hello, > > I had to uninstall vlc to get jessie upgraded to stretch, this was the key > for the upgrade > Please follow instructions at https://www.debian.org/releases/stretch/amd64/release-notes/ch-about.en.html#upgrade-reports to report issues with upgrades to stretch. Thanks, Julien
Re: Bug#861455: ITP: xf86-input-tslib -- X.org input driver for tslib
On Sat, Apr 29, 2017 at 12:47:29 +0200, Martin Kepplinger wrote: > Package: wnpp > Severity: wishlist > Owner: Martin Kepplinger > > * Package name: xf86-input-tslib > Version : 0.0.7 > Upstream Author : Martin Kepplinger > * URL : https://github.com/merge/xf86-input-tslib > * License : MIT > Programming Lang: C > Description : X.org input driver for tslib > > xf86-input-tslib had been in Debian before, see > https://tracker.debian.org/pkg/xf86-input-tslib and I'm rewriting the > packaging completely due to it's age. I only intend to build upon the > old changelog file. > > Former upstream site: > http://public.pengutronix.de/software/xf86-input-tslib/ > > Packaging is done here now: > https://github.com/merge/xf86-input-tslib-debian > > - why is this package useful/relevant? > > tslib is still quite widely used in embedded at least. It saw much > improvements recently and this package would make tslib available to > X servers. xf86-input-tslib 0.0.7 was recently released and makes it > usable on recent systems. There are plans for multitouch too. > > - how do you plan to maintain it? > > I reached out to the people from the old packaging repo at > http://git.debian.org/?p=collab-maint/xf86-input-tslib.git;a=summary > but haven't heard anything. It shouldn't be an issue though, to just > maintain this little packaging code on github. > I don't think we should revive this package in Debian. There has been much effort upstream in the last years to reduce the amount of device-specific code in userspace drivers, with things stabilizing around the evdev and now libinput drivers. Why does libinput not satisfy your needs, and why can't it be made to? Cheers, Julien
Re: segfault trying to install at netcfg[1996]
On 03/30/2017 01:10 AM, Felix Miata wrote: > Using: > http://mirrors.us.kernel.org/debian/dists/stretch/main/installer-i386/current/images/netboot/mini.iso > 27-Jan-2017 22:23 35M > burned to CDRW. Hi Felix, debian-devel is not the right place to report issues with the debian installer, please see https://www.debian.org/releases/stretch/i386/ch05s04.html.en#submit-bug for instructions to submit installation reports. Cheers, Julien
Re: Help requested: Packages which FTBFS randomly
On 02/20/2017 07:57 AM, Niels Thykier wrote: > Vincent Bernat: >> [...] >> >> [...] The policy doesn't state that a package >> must build when there is not enough disk space or memory. Maybe it would >> be far simpler to allow packages to fail to build if there is not enough >> CPUs. >> > > On a related note: Having some way to declare minimum requirements for > e.g. disk space and memory (a la "base GB usage + GB usage/core") used > would be great. > Especially if it is available in metadata, so wanna-build can see > whether it makes sense to assign a given package to a given build-node. > > That way we could presumably fix most of the "resource > exhausted"-failures by not over-committing resources on the buildds. > I think most of the "resource exhausted" failures are either "buildd has lots of old build trees that need to be cleaned up" or "build exhausted virtual address space". Neither of which would be fixed by the above. Cheers, Julien
Re: code quality
On 12/22/2016 11:40 AM, Ritesh Raj Sarraf wrote: > https://lists.freedesktop.org/archives/dri-devel/2016-December/126684.html > > Some have praised BSD code to be better than Linux's. And this link says that > Linux is trying to be too perfect in terms of code. > > Given that BSDs are also a supported platform for these vendors, wonder what > the > BSD fans have to say about the given code. > debian-devel seems entirely the wrong list for that discussion. Cheers, Julien
Re: [RFC] Enabling bindnow by default in dpkg-buildflags?
On 12/19/2016 11:37 AM, Bálint Réczey wrote: > Thanks. If I could perform the autopkgtest run with bindnow this year would it > be convincing enough given only a small amount of breakages to enable > bindnow early in January? > I thought I was clear earlier. No, enabling bindnow globally is something which, if it's going to happen (it's not clear to me that's a good idea), can only happen at the beginning of the release cycle, not when we're getting close to freeze, let alone during freeze. Cheers, Julien
Re: [RFC] Enabling bindnow by default in dpkg-buildflags?
On Sat, Dec 17, 2016 at 09:20:40 +0100, Bálint Réczey wrote: > >> >> Considering that we are already in the transition freeze I suggest > >> >> going with enabling bindnow for all architectures in dpkg and > >> >> for Stretch+1 the responsibility of setting some hardening flags > >> >> could be transferred to gcc. > >> >> IMO this is not a transition because the change does not affect > >> >> package interdependencies. > >> > > >> > Is there any update on this? > > > > I've not seen any reply from the release team, no. And as explicitly > > mentioned before multiple times now, this has the potential to impact > > the release by introducing subtle and possibly hard to spot errors at > > *run-time*, which might be triggered by simple a upload or a binNMU w/o > > the maintainer being in the loop and knowing they have enabled bindnow. > > So I want the release team to be involved in ACKing this potentially > > release breaking change. > > I would like to kindly ask the Release Team to share its position on the > bindnow question since Guillem don't seem to let this move forward > without that. > That is very much not happening for stretch. Cheers, Julien
Re: armel after Stretch
On 12/09/2016 05:22 PM, Wookey wrote: > We can do poor-mans partial arch by just being fairly agressive about > disabling armel for packages that are broken or not suitable. Not very > clever or efficient, but it is easy to do and requires no infra or > tooling changes at all. So long as someone is volunteering for that > (easy but unexciting) work that could work. > We wouldn't necessarily want to call the result a Debian release, though. Cheers, Julien
Re: Bits from the Stable Release Managers
On 11/29/2016 12:07 AM, Iustin Pop wrote: > On 2016-11-27 20:42:26, Adam D. Barratt wrote: >>* The bug should be of severity "important" or higher > > Quick question: assuming all the other conditions are met (minimal patch, > clean debdiff, etc.), this seems to discourage normal bugs fixing. Is > that intentional (i.e. there must be significant breakage), or more > about "we don't want random bugs fixed"? > There is for all intents and purposes no QA on proposed-updates, so there has to be significant impact for the risk of changing anything to be worth taking: we ship changes directly to our stable users so any regression carries a pretty high cost. Sometimes we can take lower-severity fixes along with an update, but on their own normal-severity bug fixes are just not worth it. Cheers, Julien
Re: Bits from the Stable Release Managers
On 11/28/2016 05:18 PM, Mattia Rizzolo wrote: > On Mon, Nov 28, 2016 at 03:47:09PM +0100, Julien Cristau wrote: >> source only uploads work for stretch and up. There are no arch:all >> autobuilders for wheezy and jessie. > > Well, it doesn't even work for stretch, actually. > There are no autobuilders for stretch, and dak is rejecting such > uploads. > stretch isn't stable yet, as far as I know. Cheers, Julien
Re: Bits from the Stable Release Managers
On 11/28/2016 02:38 PM, Holger Levsen wrote: > Hi Adam, > > thanks for this update! > > On Sun, Nov 27, 2016 at 08:42:26PM +, Adam D. Barratt wrote: >>* The update must be built in an (old)stable environment or chroot > > afaik source only uploads work as well, dont they? (and technically the > above obviously includes this, but I think it would be nice to > explicitly mention source uploads work too.) > > source only uploads work for stretch and up. There are no arch:all autobuilders for wheezy and jessie. Cheers, Julien
Re: Multi-Arch: allowed
On Tue, Nov 1, 2016 at 18:11:27 +0100, Thibaut Paumard wrote: > The -dbg package is Multi-Arch same. It Depends on the packages for > which it provides debugging symbols, some of which are Multi-Arch: > allowed. That Depends seems wrong, there's no reason a -dbg package needs a dependency on anything, AFAICT. Cheers, Julien
Re: Autogenerated -dbgsym packages made my package by REJECTed
On Sat, Oct 29, 2016 at 22:54:57 +0200, Magnus Holmgren wrote:
> lördag 29 oktober 2016 kl. 21:35:14 CEST skrev Ian Jackson:
> > Debian FTP Masters writes ("xen_4.8.0~rc3-0exp1_multi.changes REJECTED"):
> > > libxenstore3.0-dbgsym: lintian output: 'extended-description-is-empty ',
> > > automatically rejected package. libxen-4.8-dbgsym: lintian output:
> > > 'extended-description-is-empty ', automatically rejected package.
> > > xenstore-utils-dbgsym: lintian output: 'extended-description-is-empty ',
> > > automatically rejected package. xen-utils-4.8-dbgsym: lintian output:
> > > 'extended-description-is-empty ', automatically rejected package.
> > >
> > > ===
> > >
> > > Please feel free to respond to this email if you don't understand why
> > > your files were rejected, or if you upload new files which address our
> > > concerns.
> >
> > These .debs were generated automatically by debhelper. It is true
> > that they don't have extended descriptions, but I think that's
> > correct. None of the docs I could find on this new feature [1] seem
> > to cover this aspect.
>
> I was going to ask the same. Is the new ftp-master server running an old
> lintian? The changelog of lintian 2.5.31 says "Allow debug packages without
> an
> extended description.", and since they're generated automatically by
> debhelper
> without entries in debian/control, we are not supposed to be required to add
> such entries, are we?
>
Right, fasolo had jessie's lintian. Upgraded to jessie-backports now,
sorry for the inconvenience.
Cheers,
Julien
Re: when should we esmtps our mxes?
On Mon, Oct 24, 2016 at 11:45:33 +, Ivan Shmakov wrote: > > Kristian Erik Hermansen writes: > > On Mon, Oct 24, 2016 at 1:59 AM, Adrian Bunk wrote: > > […] > > >> For the kind of attacks you are describing, https is just snake oil. > > > Profusely disagree and so do other members of this list. I'll leave > > it at that, but also I should point out that your email is being > > routed insecurely via welho.com and lacks TLS in transit, so I also > > probably shouldn't consider your TLS knowledge very highly… > > Speaking of which. Does the gnutls-cli transcript MIMEd signify > of an ongoing MitM attack, or is it just a misconfiguration? > Neither. _25._tcp.bendel.debian.org. 3600 IN RRSIG TLSA 8 5 3600 20161202211237 20161023203831 7866 debian.org. uCQU3vi1LA/bhjW51xETwZn3wWsLPFUvvW4BU1uUE8uJqzsQTdzNBWgW +aIE9gOphLZ+zMdni/16QvAV8FWqJ77RZm5RoZFBZ9NbvF/OBgYqlKx/ NpR79goHcI6NHMezAh6BF3PEE3gQjogAXlA9pLhf8hVyQh117sLHyVPt sc/d+mJv9CTCiwSUqiG/e3V0je2dt7SpIcI+uxDL/pe/6dt3qSOE5hpH xtvG1xaoYcF1UWGMP12j8LIK2V+sNRbq _25._tcp.bendel.debian.org. 3600 IN TLSA3 1 1 7D8AC6B95A22EFBE727768523798BC914AFA9F22A10F7847023E2D8A B982D234 Cheers, Julien
Re: When should we https our mirrors?
On Mon, Oct 17, 2016 at 15:24:42 +, Peter Palfrader wrote: > On Mon, 17 Oct 2016, Ian Campbell wrote: > > > Have we gotten to the point where we consider deb.d.o suitable for > > production use? The web page still says Experimental (so I would assume > > "not production yet") and I'm not really sure if there will be a > > distinction between >=Stretch and <=Jessie in this regards. It looks > > like Jessie and earlier get a fallback mode of operation, but is that > > mode of operation suitable to be recommended for production? > > The fallback is not only needed for old apt versions but also for > clients behind webproxies that don't do SRV record lookups. (Which, at > a guess, would be all of them). > Also, the fallback is "just" a http redirect, so it's the same cost you'd pay when using httpredir.d.o. Cheers, Julien
Re: removal instead of orphaning?
On Fri, Aug 26, 2016 at 19:01:52 +0200, Guus Sliepen wrote: > On Fri, Aug 26, 2016 at 04:12:46PM +0200, Paul Gevers wrote: > > > Today I was, once again, surprised to see how many (low popcon) orphaned > > packages we have. I believe that orphanage is a burden to our community > > in the sense that not all packages are picked up by a new maintainer and > > these packages need some QA once in a while and often don't get enough > > of that (at least most packages that I touched). > > Who is this a burden for? As long as there are no RC bugs filed for the > orphaned packages, I don't see any a direct reason to remove them. > If no-one used the package, then sure, the package is really useless. > But if at least some people are using it, it has value. > off the top of my head: - it's wasting time of anyone doing QA work - it's wasting time of any user who looks for a piece of software to do $stuff and gets to eliminate all the noise from unmaintained probably-broken cruft Cheers, Julien
Re: How to specify files not in source package in d/copyright (Was: liblemon_1.3.1+dfsg-1_amd64.changes REJECTED)
On Sat, Aug 6, 2016 at 23:37:03 +0200, Andreas Tille wrote: > Hi, > > On Sat, Aug 06, 2016 at 05:00:09PM +, Thorsten Alteholz wrote: > > as you somehow add jquery.js to your doc-package, please add its license > > to your debian/copyright. > > The jquery.js is installed by doxygen in the documentation process. It > does not belong to the source package (the full autogenerated > documentation provided by upstream was intentionally removed to avoid > compressed JS files). I wonder why I should add licenses of files that > are not part of the source package and do not even have an idea how I > could do this syntactically correctly - lintian would claim an unused > copyright paragraph and IMHO lintian is correct here. > I don't think you should. I believe Thorsten is overreaching in asking you to do that. Cheers, Julien
Re: liblemon_1.3.1+dfsg-1_amd64.changes REJECTED
On Sun, Aug 7, 2016 at 09:46:04 +0200, Christian Kastner wrote: > On 2016-08-06 23:37, Andreas Tille wrote: > > Hi, > > > > On Sat, Aug 06, 2016 at 05:00:09PM +, Thorsten Alteholz wrote: > >> as you somehow add jquery.js to your doc-package, please add its license > >> to your debian/copyright. > > > > The jquery.js is installed by doxygen in the documentation process. It > > does not belong to the source package (the full autogenerated > > documentation provided by upstream was intentionally removed to avoid > > compressed JS files). I wonder why I should add licenses of files that > > are not part of the source package and do not even have an idea how I > > could do this syntactically correctly - lintian would claim an unused > > copyright paragraph and IMHO lintian is correct here. > > A bug has been filed against lintian about this, see #736360. > > This does seem like one of the intended use cases of the "Built-Using" > field, as Helmut and Jakub discuss. > > Policy § 7.8: > | Some binary packages incorporate parts of other packages when built > | but do not have to depend on those packages. Examples include > | linking with static libraries or incorporating source code from > | another package during the build. In this case, the source packages > | of those other packages are a required part of the complete source > | (the binary package is not reproducible without them). > The policy text is way too broad, Built-Using is really about GPL compliance, and jquery isn't GPL. See #688251. Cheers, Julien
Re: Git Service for Debian (was Re: Next steps for gitlab.debian)
On Fri, Jul 29, 2016 at 20:53:48 +0530, Balasankar C wrote: > On വ്യാഴം 28 ജൂലൈ 2016 12:10 വൈകു, Pirate Praveen wrote: > > > Hi all, > > > > At this point, I'm dropping work on gitlab for debian and moving to less > > controversial alternative pagure. > > When did we (i.e Debian) finalize on using Pagure? I think, we should first > fix > a solution and then start working on that. Or, we would be going the same way > as of GitLab. > That seems like a pretty failsafe way of never actually doing anything. Cheers, Julien
Re: Genesis of the git.d.o/gitlab.d.o confusion (Was: Next steps for gitlab.debian)
On Wed, Jun 8, 2016 at 15:56:31 +0200, Joachim Breitner wrote: > We’ll have to allow for some diversity, if only to try new paths (and > then, eventually, cut off old ones). Especially as long as there is > motivation. > I haven't seen much motivation to maintain alioth (especially the fusionforge bits) for a few years now. Alex is doing a great job of preventing things from collapsing under their own weight entirely, but there's a difference. Cheers, Julien
Re: replacing alioth is more than git (Re: Next steps for gitlab.debian (Re: GitLab B.V. to host free-software GitLab for Debian project)
On Wed, Jun 8, 2016 at 09:41:11 +, Holger Levsen wrote: > Hi, > > setting up this gitlab thing is one thing, but moving away from alioth > has this problem that we'll need to keep (svn|cvs|bzr|hg|...).debian.org > as not only some packages workflows depend on it, but also parts of our > own infrastructure. > > Does anyone has any idea how to do this in practice, without keeping > alioth running? (or is the only idea to keep it running and phase it out > in 5-10 years?) > I think the most realistic way is to phase it out gradually. Starting with git makes a lot of sense. Cheers, Julien
Re: Debian i386 architecture now requires a 686-class processor
On Wed, May 18, 2016 at 02:41:51 +0200, Guillem Jover wrote: > Hi! > > On Tue, 2016-05-10 at 19:17:15 -0300, Lisandro Damián Nicanor Pérez Meyer > wrote: > > On Saturday 07 May 2016 13:23:30 Ben Hutchings wrote: > > > Last year it was decided to increase the minimum CPU features for the > > > i386 architecture to 686-class in the stretch release cycle. This > > > means dropping support for 586-class and hybrid 586/686 > > > processors[1].(Support for 486-class processors was dropped, somewhat > > > accidentally, in squeeze.) > > > > > > This was implemented in the Linux kernel packages starting with Linux > > > 4.3, which was uploaded to unstable in December last year. > > > > I guess the answer is "no", but just to be sure: does this means that i386 > > supported processors need to implement SSE2? > > I suppose this is related to unconditional SSE2 requirement in new Qt > libraries, (bugs #792594, #794739), for which I thought I had clarified > the conditions and for which I've provided patches already, but also for > which I'm not willing to sign the CLA. > > This means that Qt and any application using those specific bits, will > not run at all (silently) in Stretch on any AMD-based i386 CPUs, nor on > older Intel ones, which I'd assume is a pretty big percent of the i386 > park. > Why aren't those bugs RC? Cheers, Julien
Re: CVE-2016-0800 status for openssl 0.9.8o
On Wed, Mar 23, 2016 at 15:09:19 +, Mike LI wrote: > Dear Debian developers: > We still use 0.9.8 with Debian squeeze (lts) dist in production systems. > > As shown below, > https://security-tracker.debian.org/tracker/CVE-2016-0800 > > openssl (PTS)squeeze, squeeze (security)0.9.8o-4squeeze14vulnerable > squeeze (lts)0.9.8o-4squeeze23 vulnerable > Do you have plan/schedule when it will be fixed? > squeeze-lts reached end of life last month. No new fixes will be released for it. You should upgrade to a supported release ASAP. https://www.debian.org/News/2016/20160212 Cheers, Julien
Re: mkdocs locale error building djangorestframework
On Mon, Jan 25, 2016 at 23:13:49 -0500, Barry Warsaw wrote: > On Jan 26, 2016, at 01:12 AM, Ben Hutchings wrote: > > >That's not the problem at all. Read the error message again. Read the > >source line it points to. Now look at where rv comes from: > > > import subprocess > rv = subprocess.Popen(['locale', '-a'], stdout=subprocess.PIPE, > >... stderr=subprocess.PIPE).communicate()[0] > type(rv) > > > > For Python 3, try adding `universal_newlines=True` to any subprocess call. > You'll get back a str. > Or a UnicodeDecodeError. Cheers, Julien
Re: Bug#807019: tracking bin-num - broken unison due to binnmu upload
On Wed, Dec 9, 2015 at 14:02:41 +, Wookey wrote: > +++ Jakub Wilk [2015-12-09 14:47 +0100]: > > Looks like a fallout after #620112. > > This change in sbuild should be reverted. It didn't fix binNMU > > co-installability, and made binMNU changelog entries less helpful. > > It may not have fixed binNMU co-installability on its own, but it > looks to me as if it was a necessary part of solving that issue? Has > it been superceded by changes in changelog handling for binNMUs (I > vaguely recall some changes in this area but am not sure what the > current state is)? > > i.e it's not clear to me that this should simply be reverted because > it is 'misleading'. Not-breaking MA:same co-installability with > binNMUs is an important goal IMHO. > It's entirely unnecessary, because a binNMU's changelog now ends up in /usr/share/doc/$package/changelog.$arch.gz, which doesn't clash with other architectures since it's arch-qualified. So yes, the change in sbuild should be reverted. Cheers, Julien signature.asc Description: PGP signature
Re: Mass bug filing: dpkg-buildpackage -A
On Tue, Nov 24, 2015 at 00:41:35 +0100, Santiago Vila wrote: > On Mon, Nov 23, 2015 at 08:42:14PM +0100, Julien Cristau wrote: > > On Tue, Nov 24, 2015 at 06:14:43 +1100, Ben Finney wrote: > > > > > If it's a “severe violation of Debian policy”, the bug is at least > > > “serious” severity. > > > > > The release team's RC policy decides which policy violations we consider > > "severe" in the sense of "gets a serious severity bug". > > Indeed, this is how I thought the severities were being used. Not in > theory but in practice. > > Please don't worry about severities. I will try to be "nice" and will > report them as "important", as there are a lot of affected packages. > > But will use some kind of usertags so that release managers are able > to change severities easily. I would love to see this as a release > goal for stretch, but I think it's soon to decide about that. > Sounds great, thanks! Cheers, Julien signature.asc Description: PGP signature
Re: Mass bug filing: dpkg-buildpackage -A
On Tue, Nov 24, 2015 at 06:14:43 +1100, Ben Finney wrote: > If it's a “severe violation of Debian policy”, the bug is at least > “serious” severity. > The release team's RC policy decides which policy violations we consider "severe" in the sense of "gets a serious severity bug". Cheers, Julien signature.asc Description: PGP signature
Re: DAK Commands for Bikesheds
On Tue, Sep 22, 2015 at 10:58:15 +0200, Tzafrir Cohen wrote: > On Fri, Sep 18, 2015 at 06:41:53PM +0200, Jakub Wilk wrote: > > * Joerg Jaspert , 2015-09-17, 13:42: > > >I defined the possible commands for the upcoming bikeshed feature, > > > > It's the first time I hear about the "bikeshed feature". Perhaps you should > > explain the term first. > > > > (Believe it or not, most debian-devel readers were not at DebConf.) > > The name was used in the following talk: > > https://summit.debconf.org/debconf15/meeting/231/ppas-whats-next/ > > It has a link to the video of the talk. > The name was also used on this list a while ago, https://lists.debian.org/518b7cf6.3080...@debian.org Cheers, Julien signature.asc Description: Digital signature
Re: promoting virtualbox-dkms to virtualbox pre-depends
On Tue, Sep 22, 2015 at 15:00:35 +, Gianfranco Costamagna wrote: > As shown in policy 7.2 > > "You should not specify a Pre-Depends entry for a package before this has > been discussed on the debian-devel mailing > list and a consensus about doing that has been reached. See Dependencies, > Section 3.5." > > the problem actually is that virtualbox-dkms should be configured *before* > configuring virtualbox, otherwise > without a built kernel module, restarting VMs > will fail and lead to an half-configured package. > > Please see bugs #798527 and #798979 as examples. > > (this is a subpackage depending on another subpackage that belongs to the > same src, I don't get why I should discuss such internal > changes, but well, policy is policy) > A pre-depends is very much the wrong hammer here, userspace can't usefully rely on a kernel package or module through package dependencies. Cheers, Julien signature.asc Description: Digital signature
Re: binNMU or reproducible builds (choose only one)
On Thu, Sep 17, 2015 at 22:53:15 +0200, Santiago Vila wrote: > Well, from the point of view of build-reproducibility, what is broken is the > whole binNMU idea. > Well, not at all... Cheers, Julien signature.asc Description: Digital signature
Re: libstdc++ follow-up transitions
On Tue, Aug 25, 2015 at 08:48:54 +0100, Simon McVittie wrote: > Release team, here are some suggestions for binNMUs and other > wanna-build interactions: > > Fixes for some earlier failures, and version skews caused by > maintainer-built binaries not being discarded: > > # retry failed build with binNMU'd imagemagick > gb pfstools_1.8.5-2.1 . amd64 Done a couple of days ago. > # for opencv transition; maintainer upload had the old opencv > nmu ffmpeg_7:2.7.2-2 . amd64 . -m "rebuild with libopencv-core2.4v5" > $ wb nmu ffmpeg . amd64 mips mipsel . -m 'Build against renamed opencv for g++5 transition' --extra-depends 'libopencv-dev (>= 2.4.9.1+dfsg-1.2)' > Looking at the build-dependencies of the "bad" packages, the following > transitions (mostly small ones) don't appear to be entangled with > anything that hasn't already started or involve rebuilding any libraries > that are thought to need transitions, so they might be a good way to > reduce the problem space and make it easier to reason about larger > transitions: > > * https://release.debian.org/transitions/html/auto-adplug.html done > * https://release.debian.org/transitions/html/auto-assimp.html blocked by #794990 > * https://release.debian.org/transitions/html/auto-gflags.html essentially done > * https://release.debian.org/transitions/html/auto-givaro.html need to check linbox I guess. I thought I'd done that, but I guess not. > * https://release.debian.org/transitions/html/auto-gstreamermm-1.0.html Looks all done > * https://release.debian.org/transitions/html/auto-libassa.html $ wb gb granule . ANY Will go through the rest after lunch. signature.asc Description: Digital signature
Re: libstdc++ follow-up transitions
On Mon, Aug 17, 2015 at 13:46:16 +0100, Simon McVittie wrote: > I notice that Ubuntu has gone ahead with a lot of library renames. Did > the Ubuntu developers doing these uploads test the results, or did you > just "upload and hope"? One reason I have held back from doing more NMUs > is that for the majority of transitioning packages, I have no idea how > to smoke-test the results, and I'm not happy with putting my signature > on a package that I haven't tested. However, if we're going for a lower > standard of "successfully rebuilding the package and some random rdeps > is enough testing", then there are quite a lot of NMUs that can be done. > I'm planning on doing that. I don't think there's a way we can get this transition done in finite time without being aggressive about NMUs. Cheers, Julien signature.asc Description: Digital signature
Re: Bug#793057: ITP: godot -- open source MIT licensed game engine
On Mon, Jul 20, 2015 at 23:29:14 +0200, Bruno Ramos wrote: > Description : open source MIT licensed game engine > That's not a terribly useful short description. Only the last two words belong there, IMO. The "open source" bit is kind of implied by it being in Debian, and the exact license is what debian/copyright is for. Cheers, Julien signature.asc Description: Digital signature
Re: BD-Uninstallable due to circullar dependency
On Mon, Jul 20, 2015 at 11:46:30 +0900, Hideki Yamane wrote: > Hi, > > While investigating libspiro build, I found BD-Uninstallable on powerpcspe. > http://buildd.debian-ports.org/status/package.php?p=libspiro&suite=sid > > > Dependency installability problem for libspiro on powerpcspe: > > > > sysvinit-utils depends on missing: > > - util-linux (>= 2.26.2-3) > > and util-linux on powerpcspe is also BD-Uninstallable due to same reason. > http://buildd.debian-ports.org/status/package.php?p=util-linux&suite=sid > > > sysvinit-utils depends on missing: > > - util-linux (>= 2.26.2-3) > > How do we fix it? > If there's any more appropriate address for it, please let me know. It should just be forced despite the bd-uninstallable. sysvinit-utils and util-linux are essential, so they're already in the build chroot, so whether a newer version is available and uninstallable doesn't matter. Cheers, Julien signature.asc Description: Digital signature
Re: Bits from the Stable Release Managers
On Mon, May 25, 2015 at 19:42:48 +0100, Simon McVittie wrote: > On 25/05/15 18:24, Lisandro Damián Nicanor Pérez Meyer wrote: > > On Sunday 24 May 2015 21:27:47 Adam D. Barratt wrote: > > [snip] > >> Due to the way that the archive manages uploads to proposed-updates, if > >> you upload a .changes file which only includes source and > >> architecture:all packages, please ensure that you rename it to something > >> other than "_$arch.changes". > > Does this only apply to source packages that produce at least one binary > package on $arch, or does it also apply to source packages that solely > produce architecture-independent binaries? > No, the issue is when the maintainer-uploaded .changes file name clashes with the one from a binary (buildd) upload, so if there aren't any architecture-dependent binaries, then this doesn't matter. Cheers, Julien signature.asc Description: Digital signature
Re: Heads up: Upcoming dpkg-buildpackage -j precedence change
On Sun, May 10, 2015 at 18:49:25 +0100, Wookey wrote: > I'm happy if you change this - it seems like fixing a bug to me, but I > will just throw in this observation from recent arm64 archive-rebuilds, that > -j and DEB_BUILD_OPTIONS=parallel= are not exactly the same. Is that > expected? If not then it should perhaps be considered/investigated in > case other builds are sensitive to the difference? > > here is a message from Ed Grimley-Evans, checking the FTBFS: > --- > freecdb illustrates the problem repeatably: > > works: >DEB_BUILD_OPTIONS=parallel=4 dpkg-buildpackage -b > > fails: >dpkg-buildpackage -b -j4 > > I haven't worked out precisely what goes wrong, but it seems to have > something to do with a version of "debian/implicit" from 2005/2006, > which was perhaps written with the assumption that dependencies are > built one at a time in order. The whole package is that old, in fact. > > Anyway, what's the bug? Are packages that won't build with > "dpkg-buildpackage -j4" buggy, or is it a bug that man pages suggest > using "dpkg-buildpackage -j4" rather than > "DEB_BUILD_OPTIONS=parallel=4 dpkg-buildpackage -b"? > > > This seems to be reproducible even on a dual-core amd64 machine. > dpkg-buildpackage -j is buggy. It sets MAKEFLAGS whether the package supports parallel builds or not. Whereas setting DEB_BUILD_OPTIONS lets the package know it's allowed to use more processes if it wants to / can, but doesn't have to. Cheers, Julien signature.asc Description: Digital signature
Bug#784114: ITP: xserver-xorg-input-libinput -- X.Org X server -- libinput input driver
Package: wnpp Severity: wishlist Owner: Debian X Strike Force X-Debbugs-Cc: libin...@package.debian.org * Package name: xserver-xorg-input-libinput Version : 0.9.0 Upstream Author : Peter Hutterer * URL : http://www.x.org/ * License : MIT/X Programming Lang: C Description : X.Org X server -- libinput input driver This package provides the driver for input devices using libinput library. . More information about X.Org can be found at: http://www.X.org> . This package is built from the X.org xf86-input-libinput driver module. This driver will combine the functionality of the evdev, synaptics and wacom X drivers. We'll need libinput 0.11 before we can upload this. Cheers, Julien signature.asc Description: Digital signature
Re: MBF for python-support removal
On Fri, May 1, 2015 at 15:26:11 +0200, Luca Falavigna wrote: > Hi, > Hi Luca, > as discussed on a thread on debian-python mailing list [0], I'd like > to start a MBF against about 420 packages [1] to propose the removal > of the deprecated python-support. > > A couple of lintian tags have been around for about one year and a > half, allowing us to reduce the total number of affected packages, but > from the graphs it seems the curve is no longer decreasing, therefore > this request to speed up the migration to dh_python[23]. > > I'd like to work on this in the coming days if rough consensus is > reached, feel free to raise your objections/suggestions! > It would be nice to see a template of your proposed mass filing. Cheers, Julien signature.asc Description: Digital signature
Re: MBF: build Python 3 modules for packages that support it upstream
On Fri, Apr 17, 2015 at 15:47:16 -0400, Paul Tagliamonte wrote: > On Thu, Apr 16, 2015 at 06:50:11PM -0400, Paul Tagliamonte wrote: > > I'll curate the raw run I did today, since I saw a few false positive > > (python 3 backports to python 3) and file them. I'll run a dd-list at > > some point before the file. > > > > Severity will be wishlist. Target is the next release / sid after Jessie > > release. > > Since I've got no one complaining, I'm going to go ahead and file these > under the usertag patchme-python3, wishlist, and with a note it's for > after jessie releases. I'll compile a dd-list and run through it before > the filing. > You might want to give people more than 24 hours to comment. A week seems like the bare minimum to me. Cheers, Julien signature.asc Description: Digital signature
Re: Bug#765076: general: No way to have a clean chroot for building packages
Control: reassign -1 general Control: retitle -1 init should not be Essential On Tue, Dec 16, 2014 at 12:04:17 +0100, Holger Levsen wrote: > control: reassign -1 debootstrap > control: retitle -1 variant=buildd should not install init systems > > Hi, > > On Montag, 13. Oktober 2014, Joey Hess wrote: > > It seems reasonable for debootstrap --variant=buildd to omit any init > > systems, if it doesn't already. > > seems reasonable indeed, reassigning accordingly. > That means making init non-essential. Which is not debootstrap's responsibility. Cheers, Julien signature.asc Description: Digital signature
Re: Debian Bug Squashing Party in Tilburg, .nl, sat 2014-12-13 - sun 2014-12-14
On Fri, Dec 5, 2014 at 18:06:49 +0100, Geert Stappers wrote: > On Fri, Dec 05, 2014 at 04:37:33PM +0100, Geert Stappers wrote: > > Original only on d-event-eu@ldo, now updating > > and cross-posting to d-d-a@ldo and d-e-nl@ldo > > Now only to d-d-a@ldo because previous posting didn't return > and not yet shown up at > https://lists.debian.org/debian-devel-announce/2014/12/threads.html > > This attempt is with my @debian.org e-mail address. > d-d-a drops mails with References/In-Reply-To to -devel@. Cheers, Julien signature.asc Description: Digital signature
Bug#771718: general: Screen blanks and does not come back up unless system is suspended
On Mon, Dec 1, 2014 at 22:02:50 +0100, Rik Theys wrote: > Package: general > Severity: normal > > Hi, > > I was thus far unable to pinpoint which component causes this behaviour as I > can > not find anything in my logs (and/or journal). I have therefore assigned it > to general. Feel free to change to a more appropriate package. > > I'm using KDE on Jessie with gdm3 as the login manager. The system has > systemd installed. When the system is idle for few minutes (but before the > limit set in the KDE screensaver settings), the screen will blank and will not > come back on keypress or mouse movements. I have to close the lid of the > laptop > to let the system suspend. After resume I will get the unlock window > of the screensaver and can continue working. > > I can login using SSH when this happens but couldn't find anything in the logs > that could explain this. > > Any ideas on how to further debug this issue is appreciated. Are there any > other reports about similar behaviour? > The debian bug tracking system is not a user support forum. The 'general' pseudo package even less so. There are other places for this, such as the debian-user list. Cheers, Julien signature.asc Description: Digital signature
Re: New pre-depends: python pre-depends python-minimal
On Tue, Nov 18, 2014 at 02:46:24 -0500, Scott Kitterman wrote: > As part of python2.7-minimal's configuration, > /usr/share/python/runtime.d/public_modules.rtinstall gets executed. It's > part > of the python package. Since the dependency chain was texlive-music -> > python > -> python2.7-minimal, python is already unpacked, so the script is available. > > The tricky part is that /usr/share/python/runtime.d/public_modules.rtinstall > needs /usr/bin/pycompile in order to work. That's in (you guessed it) python- > minimal. It's not available (and there's nothing in policy that says it has > to be). > That sounds broken. Why does python2.7-minimal run stuff from the python package? Cheers, Julien signature.asc Description: Digital signature
Re: New pre-depends: python pre-depends python-minimal
On Mon, Nov 17, 2014 at 18:24:00 -0500, Scott Kitterman wrote: > It appears that the appropriate resolution of #769106 [1] is to add a new > pre-depends on python-minimal in python. > > This issue at hand is that at the time python2.7-minimal is configured, > python > is unpacked, but python-minimal is not. Since python-2.7-minimal doesn't > have > a direct depends on python-minimal, this is allowable (policy 7.2, Depends). > > In order for python2.7-minimal to configure, python-minimal needs to be at > least unpacked to provide /usr/bin/pycompile. The only way for python to > ensure this is the case is to declare a pre-depends relation (also policy > 7.2). > Can you explain why/how the python package enters into the picture here at all? Cheers, Julien signature.asc Description: Digital signature
Re: Packages using old dpkg tools paths
On Wed, Nov 5, 2014 at 21:21:05 +0100, Guillem Jover wrote: > So, yes, given the above, I'll reinstate the compat symlinks for dpkg > 1.17.22. It would be nice though, if as many of the fixes for the > remaining callers could be accepted for jessie, if possible? > The cost of keeping symlinks around for one more release doesn't seem all that big? Cheers, Julien signature.asc Description: Digital signature
Bug#768156: general: dpkg frontend inconsistent
On Wed, Nov 5, 2014 at 17:53:50 +0100, Holger Levsen wrote: > Hi Michal, > > On Mittwoch, 5. November 2014, Michal Suchanek wrote: > > I was upgrading my system and several times I was asked for installing a > > new configuration file. Sometimes the question is posed in teletype > > style frontend sometimes in colour character terminal TUI style > > frontend. > > which tool did you use (how) to upgrade? > Pretty sure this is ucf vs dpkg's conffile prompt. Cheers, Julien signature.asc Description: Digital signature
Re: inconsistent versions of M-A: same packages
On Sat, Nov 1, 2014 at 13:17:11 +0100, Guillem Jover wrote: > [ Fixed CC and M-F-T addresses, and bounced to debian-release. ] > > Hi! > > On Sat, 2014-11-01 at 11:45:56 +0100, Marc Glisse wrote: > > sorry for the naive question, but is there a plan for massively rebuilding > > all "Multi-Arch: same" packages that have inconsistent version numbers > > across architectures before releasing Jessie? > > That's something for the release-team and build admins. > As far as I'm concerned I'm happy to schedule rebuilds if i386 and amd64 aren't in sync. Any other archs I'm not going to touch. Cheers, Julien signature.asc Description: Digital signature
Re: Tests running as (real) root?
On Sun, Oct 12, 2014 at 15:45:50 +0200, Svante Signell wrote: > On Sun, 2014-10-12 at 11:11 +0800, Paul Wise wrote: > > On Sun, Oct 12, 2014 at 12:27 AM, Svante Signell wrote: > > > > > I have a question about how to run tests for a package needing root to > > > run properly, fakeroot is not sufficient. I've made one of the packages > > > to build properly with: sudo run_test and fixed the sudoers file. But > > > how to fix that so the package can be built on a buildd? > > > > Which package is this, why do the tests require root and why is > > fakeroot not sufficient? > > The package is libgnome-keyring 3.12.0-1 on GNU/Hurd. Hurd is more > restrictive than GNU/Linux on mlock()/munlock(), so you have to be root > for the tests: (This is the same problem as for kFreeBSD in #628383) > egg/tests/test-secmem > library/tests/test-memory > > The tests pass and the package builds fine with the two tests above run > as root. Currently it is flagged as FTBFS due to this issue. > If that means you need to run your gnome session as root in order to get mlocked secrets, maybe the tests failing is a good thing, and somebody should fix Hurd instead. Cheers, Julien signature.asc Description: Digital signature
Re: MBF: libjpeg-turbo transition started (if you depend on libjpeg8-dev please read)
On Mon, Sep 29, 2014 at 20:21:09 +0200, Andreas Metzler wrote: > BTW: What is the correct package to build-depend on - libjpeg62-dev or > libjpeg-dev? > libjpeg-dev, please. Cheers, Julien signature.asc Description: Digital signature
Re: schroot, apt-get and experimental
On Sun, Sep 21, 2014 at 10:11:50 -0500, Adam Majer wrote: > On Sun, Sep 21, 2014 at 11:14:41AM +0200, Peter Palfrader wrote: > > (If you don't like that, we can probably consider your patches to > > dd-schroot-cmd :) > > Is the source code only in /usr/local/bin on the schroot machines? Or > is there a better repository? > There's http://anonscm.debian.org/cgit/mirror/dsa-puppet.git/tree/modules/porterbox/files/dd-schroot-cmd Cheers, Julien signature.asc Description: Digital signature
Re: python-openssl unavailable in sid
On Mon, Sep 8, 2014 at 09:57:36 +1000, Brian May wrote: > As far as I can tell, this problem has been fixed. ftp-master didn't > respond, maybe it come good by itself? No, they fixed it last week. Cheers, Julien -- Julien Cristau Logilab http://www.logilab.fr/ Informatique scientifique & gestion de connaissances -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140908082836.ga24...@crater2.logilab.fr
