time64 ABI fix coming to upstream glibc

The and headers had a bug that the on-disk structures defined there could change size on some targets when _TIME_BITS was set to 64. This is obviously wrong because the files are not going to magically change their layout because the application accessing them was built in a specific way.

Re: Linking coreutils against OpenSSL

* Theodore Ts'o: > If you can get upstream a patch so that coreutils could try to dlopen > OpenSSL and use it if it is available, but skip it if it is not, that > might be one way to avoid OpenSSL going into essential. The challenge > is that OpenSSL is not known for its ability to maintain a

Re: RFC: More C errors by default in GCC 14 (no more implicit function declarations etc.)

* G. Branden Robinson: > Perhaps the thing to do here is have, , yet another command-line > option for GCC. The Ada language did something similar a couple of > decades ago to tighten up the language for hard real-time demands, with > what it called the "Ravenscar profile".[1] That proved

RFC: More C errors by default in GCC 14 (no more implicit function declarations etc.)

TL;DR: I want to propose a GCC 14 change which will impact distributions, so I'd like to gather some feedback from Debian. Clang has disabled support for a few historic C features by default over the last few releases. This mirrors a process that Apple has begun in Xcode even earlier (perhaps

Re: Intel CET Support?

* Felix Potthast: > i just stumbled upon the fact that debian doesn't yet make use of the > Intel CET security feature, while many other distributions > (Ubuntu, Fedora, Suse, Arch Linux) do. There's no kernel support for userspace CET, and it's been missing for many years now. The userspace

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

* Aurelien Jarno: > Hi, > > On 2021-12-02 19:51, Florian Weimer wrote: >> I'd like to provide an ld.so command as part of glibc. Today, ld.so can >> be used to activate preloading, for example. Compared to LD_PRELOAD, >> the difference is that it's specifi

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

* Helmut Grohne: > Hi Florian, > > On Fri, Dec 03, 2021 at 06:29:33PM +0100, Florian Weimer wrote: >> We can add a generic ELF parser to that ld.so and use PT_INTERP, as I >> mentioned below. I think this is the way to go. Some care will be >> needed to avoid end

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

* Simon McVittie: > On Thu, 02 Dec 2021 at 19:51:16 +0100, Florian Weimer wrote: >> Having ld.so as a real command makes the name architecture-agnostic. >> This discourages from hard-coding non-portable paths such as >> /lib64/ld-linux-x86-64.so.2 or even (the non-ABI-comp

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

* Theodore Y. Ts'o: > * How does ld.so --preload *work*? The dynamic loader has an array of preloaded sonames, and it processes them before loading the dependencies of the main program. This way, definitions in the preloaded objects preempt definitions in the shared objects. > * Does it modify

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

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

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

* Paul Wise: > Florian Weimer wrote: > >> I'd like to provide an ld.so command as part of glibc. > > Will this happen in glibc upstream or just in Debian? Upstream, and then Debian. The symbolic link would likely and up in libc-bin in Debian. >> Today, ld.so can be use

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

I'd like to provide an ld.so command as part of glibc. Today, ld.so can be used to activate preloading, for example. Compared to LD_PRELOAD, the difference is that it's specific to one process, and won't be inherited by subprocesses—something is that exactly what is needed. There is also some

Figuring how to work with team-maintained packages on salsa

I want to add a few patches to this repository: Surely there must be some tool support to help with that? I know how to do it manually (perhaps even involving quilt). Has every Debian developer their own script for that? (It's like this in RPM

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

* zhangjialing: > 在 2021/5/11 下午6:36, Helmut Grohne 写道: >>   * What is the state of glibc support > 2.28-10,patch can provide There's been any port submission posted to libc-alpha. By default, new ports use the current glibc ABI baseline (which would now be glibc 2.34, which is still evolving

Re: CentOS and Debian/Ubuntu release cycles

* Stephan Lachnit: > The more I started thinking about it, the more I wondered about why > Debian Stable and Ubuntu LTS are *not* binary-compatible. They have different branching points from Debian unstable/upstream, so they end up with different versions of the toolchain and core libraries.

Re: Proposal: Allowing access to dmesg for users in group adm

* Nicholas D. Steeves: > Given that our default sudoers (and afaik Ubuntu's) provides the > following rule > > %sudo ALL=(ALL:ALL) ALL > > would it be reasonable to modify this proposal to use the "sudo" rather > than "adm" group, given that we don't yet have a default mechanism to > enforce

Re: Bug#958710: ITP: nss-tls -- encrypted glibc name resolving library which uses DNS-over-HTTPS (DoH)

* Scott Kitterman: > On Friday, April 24, 2020 11:54:17 AM EDT Kan-Ru Chen wrote: >> Hi, >> >> On Sat, Apr 25, 2020, at 12:34 AM, Scott Kitterman wrote: >> > On Friday, April 24, 2020 11:11:49 AM EDT Kan-Ru Chen wrote: >> > > * Package name: nss-tls Description : encrypted glibc name >>

Re: Source of shared runners containers used in salsa CI system

* Markus Frosch: > On Wed, 2020-04-15 at 10:03 +0200, Emmanuel Kasper wrote: >> I see salsagitlab ci is using docker containers for its shared runners >> >> like for instance in >> >> https://salsa.debian.org/cloud-team/debian-cloud-images/-/blob/master/.gitlab-ci.yml#L23 >> >> How are these

Re: What to do when DD considers policy to be optional? [kubernetes]

* Andrey Rahmatullin: > Or you can look at the Redhat approach as a minimal working one. > You know it can be done much easier and still work: in Redhat. I think you are referring to a Fedora process, not a Red Hat process. The Red Hat process does not seem much simpler than what ftpmaster are

Re: new kubernetes packaging

* Vincent Bernat: > ❦ 24 mars 2020 16:30 -07, Russ Allbery: > >> On the other hand (and I don't follow this community closely, so apologies >> if I have the details wrong here), my impression is that the Go community >> is not planning to support shared libraries, loves its staticly-linked >>

Re: What to do when DD considers policy to be optional? [kubernetes]

* Paul Wise: > On Tue, Mar 24, 2020 at 6:17 AM Vincent Bernat wrote: > >> Kubernetes is already using Go modules. They happen to have decided to >> keep shipping a `vendor/` directory but this is not uncommon. It is >> often considered as a protection against disappearing modules. So, there >> is

Re: apt 2.0 release notes

* David Bremner: > Julian Andres Klode writes: > >> >> apt install _toremove +toinstall >> > > A common convention is to do something like > > apt install -- -toremove +toinstall > > I would prefer that to rolling our own syntax, unless there's some good > reason (other than the small amount of

Re: Y2038 - best way forward in Debian?

* Eduard Bloch: > I vaguelly remember that glibc keeps collecting workarounds for replaced > APIs all the time, adjusting binary compatibility with manually > redirected symbols. Glibc folks might correct me, though. > > So, wouldn't a restart of the i386 architecture under a different name >

Re: Is there still a point in installing libgcrypt to /lib instead of /usr/lib

* Ansgar: > On Wed, 2020-02-19 at 09:39 +, Simon McVittie wrote: >> On Wed, 19 Feb 2020 at 09:31:51 +, Simon McVittie wrote: >> > I agree that what Guillem is proposing also does not have the property, >> > which I think is one that is important to you?, that the contents of the >> > root

Re: Can Debian packaging changes require a CLA?

* Wouter Verhelst: > On Fri, Feb 14, 2020 at 06:38:00PM +0100, Florian Weimer wrote: >> It would also make the package unmaintainable if the original packer >> loses interest, so the package would not be suitable for inclusion in >> a stable release. > > Eh, it do

Re: Can Debian packaging changes require a CLA?

* Andrey Rahmatullin: > On Fri, Feb 14, 2020 at 06:38:00PM +0100, Florian Weimer wrote: >> It would also make the package unmaintainable if the >> original packer loses interest, so the package would not be suitable >> for inclusion in a stable release. > Can you exp

Re: Can Debian packaging changes require a CLA?

* Scott Kitterman: > On February 14, 2020 3:46:18 PM UTC, Dimitri John Ledkov > wrote: >>Can a Debian Package Maintainer require CLA for accepting packaging >>changes and distro patches to be uploaded into Debian itself? >> >>(case in point, debian maintainer & upstream wear the same hat, and

Re: Y2038 - best way forward in Debian?

* Steve McIntyre: >>In addition if we are using a new multiarch triplet, and need to >>rebuild the world, are going to be ABI incompatible anyway, we might >>as well use a proper multiarch-qualified ld.so pathname that does >>not collide with anything. > > Hmmm. Moving ld.so is *hard* - we were

Re: Y2038 - best way forward in Debian?

* Ansgar: > Arnd Bergmann writes: >> On Mon, Feb 10, 2020 at 11:16 PM Florian Weimer wrote: >>> There's going to be a _TIME_BITS selector, similar to >>> _FILE_OFFSET_BITS. >>> >>> There was a proposal to have only one API before, but I think the

Re: Y2038 - best way forward in Debian?

* Ben Hutchings: > On Sun, 2020-02-09 at 11:57 +0100, Florian Weimer wrote: >> * Ben Hutchings: >> >> > If I recall correctly, glibc *will* provide both entry points, so there >> > is no ABI break. But the size of time_t (etc.) exposed through libc- >

Re: Best practices for Debian developers who are also upstreams?

* Otto Kekäläinen: > Is somebody else already doing something similar like this? We are doing this with glibc in Fedora, which is not Debian, but kind of similar. We try to push all backportable fixes to the upstream release branches (and master) and synthesize new pseudo-release tarballs from

Re: Y2038 - best way forward in Debian?

* Ben Hutchings: > If I recall correctly, glibc *will* provide both entry points, so there > is no ABI break. But the size of time_t (etc.) exposed through libc- > dev is fixed at glibc build time. Is this a Debian-specific decision? There has been a proposal upstream not to support 32-bit

Re: Y2038 - best way forward in Debian?

* Michael Stone: > On Fri, Feb 07, 2020 at 02:46:19PM +0200, Wouter Verhelst wrote: >>On Fri, Feb 07, 2020 at 10:31:16AM +, Simon McVittie wrote: >>> On Fri, 07 Feb 2020 at 09:28:24 +0200, Wouter Verhelst wrote: >>> > Why not? This seems like the type of problem that SONAMEs are made for. >>>

Re: Y2038 - best way forward in Debian?

* Sam Hartman: > Steve, you're presuming that we would not create a new soname for libc6 > on architectures where we want a new time ABI. That seems to be a reasonable assumption because Debian would have to use a different soname from upstream. glibc upstream does not seem likely to change

Re: Y2038 - best way forward in Debian?

* Steve McIntyre: > The kernel is *basically* fixed now. Internally, data structures > should now be safe. There are a small number places where 32-bit time > is still a thing, but it's in hand. A number of syscalls, ioctls, > etc. have needed updates for the user-kernel interface level. XFS is

Accepted debsecan 0.4.20.1 (source) into unstable

-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Format: 1.8 Date: Tue, 21 Jan 2020 21:13:26 +0100 Source: debsecan Architecture: source Version: 0.4.20.1 Distribution: unstable Urgency: low Maintainer: Florian Weimer Changed-By: Florian Weimer Changes: debsecan (0.4.20.1) unstable; urgency=low

Re: Secureboot: how to use MOK

* Steve Langasek: >> and this is the reason we have to require all modules to be signed by >> default. > > Enforcement of kernel module signatures is part of what's called the > "lockdown" featureset. It is optional, and not a requirement from > the UEFI spec, The requirement is in the

Accepted debsecan 0.4.20 (source all) into unstable

-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Format: 1.8 Date: Sun, 27 Oct 2019 21:31:32 +0100 Source: debsecan Binary: debsecan Architecture: source all Version: 0.4.20 Distribution: unstable Urgency: low Maintainer: Florian Weimer Changed-By: Florian Weimer Description: debsecan

Re: Secureboot: how to use MOK

* Thomas Goirand: > I've setup my new laptop with secureboot, and now, I can't use the DKMS > modules from Virtualbox, as they aren't signed. I've been told by Sledge > that I should use MOK to do that, and that DKMS packages are supposed to > have all in them to support MOK. I don't think

Re: Mozilla Firefox DoH to CloudFlare by default (for US users)?

* Philipp Kern: > It is probably worth pointing out that Firefox's use of Cloudflare's DoH > endpoint is governed by a different policy outlined here: > > https://developers.cloudflare.com/1.1.1.1/commitment-to-privacy/privacy-policy/firefox/ Thanks. > Per that policy, other third parties can

Re: Mozilla Firefox DoH to CloudFlare by default (for US users)?

* Robert Edmonds: > The entire DNS root zone is only 1 MB compressed and is updated about > once a day. It would be even better for privacy if the whole root zone > were distributed via HTTPS, as the initiator would not reveal to the > server any information about what TLD is being looked up. > >

Re: Mozilla Firefox DoH to CloudFlare by default (for US users)?

* Adam Borowski: > Let's compare; by "ISP" I mean every hop on the network path. > > With local DNS: > * the target server knows about you (duh!) > * the ISP can read the destination of every connection > [reading the DNS packets, reading the IP header, reading SNI header] > * the ISP can block

Re: Options for 64-bit time_t support on 32-bit architectures

* Simon McVittie: > On Fri, 19 Jul 2019 at 15:13:00 +0300, Adrian Bunk wrote: >> Remaining usecases of i386 will be old binaries, some old Linux binaries >> but especially old software (including many games) running in Wine. >> Old Linux binaries will still need the old 32bit time_t. > > Based

Re: Options for 64-bit time_t support on 32-bit architectures

* Adrian Bunk: > On Fri, Jul 19, 2019 at 07:13:28PM +0200, Florian Weimer wrote: >> * Adrian Bunk: >>... >> For comparison, the original plan was to provide a macro, perhaps >> -D_TIME_BITS=32 and -D_TIME_BITS=64, to select at build time which ABI >> set is used (

Re: Options for 64-bit time_t support on 32-bit architectures

* Adrian Bunk: > [ only speaking for myself ] > > On Thu, Jul 18, 2019 at 11:05:53PM +0200, Florian Weimer wrote: >>... >> The consequence is that in order to build 32-bit-time_t libraries >> (Gtk, for example), an old glibc needs to be kept around. In >>

Options for 64-bit time_t support on 32-bit architectures

There is an effort under way to enhance glibc so that it can use the Y2038 support in the kernel. The result will be that more 32-bit architectures can use a 64-bit time_t. (Currently, it's x86-64 x32 only.) Originally, the plan was to support both ABIs in glibc for building new applications,

Re: Bug#932103: RFP: fuidshift -- remap a filesystem tree to shift one set of UID/GID ranges to another

* Nicholas D. Steeves: > Package name: fuidshift > Version : 3.0 > Upstream Author : Name > URL : https://github.com/lxc/lxd/tree/master/fuidshift > License : Apache 2.0 > Programming Lang: Go > Description : remap a filesystem tree to shift one set of UID/GID >

Re: How to deal with meaningless SOVERSION bumps from upstream?

* Mo Zhou: > I realized that it's too late to ask the upstream to revert the > SONAME bump. If upstream is okay in principle with changing soname, it's not really too late, ever.

Re: How to deal with meaningless SOVERSION bumps from upstream?

* Sam Hartman: > There's fairly significant advantages to keeping ABI consistent with > upstream when possible. > So, unless the Debian ABI has diverged from upstream already, I'd > recommend that you track the soname change and accept the rebuilds > post-buster. It's possible to support both

Re: How to deal with meaningless SOVERSION bumps from upstream?

* Mo Zhou: > Should I bump the SOVERSION and trigger a transition after the Buster > release? (I think it's pointless, as it triggers pointless rebuild for > many packages including Qt) Or ignore the upstream SOVERSION bump and > track the changes by myself? I've been able to convince libidn2 to

Re: Mass bugfiling potential: bundled implementation of md5

* Adrian Bunk: > On Thu, Oct 25, 2018 at 02:56:23PM +0800, Yangfl wrote: >> Hi, >> >> Many of packages include bundled Aladdin Enterprises independent >> implementation of md5. Full list can be seen at >> https://codesearch.debian.net/search?q=typedef+unsigned+char+md5_byte_t=1 >> (100 packages)

Re: RFC: Naming convention for ILP64 variant of BLAS/LAPACK

* Mo Zhou: > Proposal: > > * The "-ilp64" postfix should be appended to the SONAME of all the new > shared objects that provide ILP64 interface. For example: > > libblas.so.3 (LP64) -> libblas-ilp64.so.3 (ILP64) > > As a result, the same postfix should be added to the binary

Re: "debian.pool.ntp.org" for Debian derivatives?

* Ian Jackson: >> PS: Paying that extra money to ntp.org would certainly not kill use, but >> adding that money instead to our currently already existing support of >> Debian-LTS / DebConf sponsoring / ... would probably benefit a lot more >> Debian (downstream) users and developers. > > I wasn't

Re: Asciidoc transition to the python3 implementation or just EOL

* Joseph Herlant: > Hi guys, > > As announces a while ago in #895462, the asciidoc package which only > support python2 is officially EOL. > > Notes: > * The python 2 implementation of asciidoc which, for now, lives at > https://github.com/asciidoc/asciidoc won't receive any new updates > * The

Re: Limiting the power of packages

* Simon McVittie: > On Thu, 04 Oct 2018 at 08:34:15 +0200, Florian Weimer wrote: >> * Paul Wise: >> > To fully solve the problem you need a whitelist based approach that >> > ends up something completely different like Flatpak. >> >> Flatpaks don't work t

Re: Limiting the power of packages

* Paul Wise: > To fully solve the problem you need a whitelist based approach that > ends up something completely different like Flatpak. Flatpaks don't work this way. Try installing gedit and open a file like ~/.ssh/id_rsa with it. There are no security prompts whatsoever, yet the software in

salsa.debian.net

I received some key SSH import notices from salsa.debian.net, but I didn't request anything. Is this harmless, or is something fishy going on?

Re: User-installable Debian packages?

* Steffen Möller: > The HPC community does not want to need root privileges to get their > software installed/used on the HPC setup. This excludes regular > Debian packages, traditional containers like Docker and chroot > environments. So they would rather give the user full file system access

Re: User-installable Debian packages?

* Simon McVittie: > On Sat, 22 Jul 2017 at 12:28:04 +0200, Steffen Möller wrote: >> And quite some packages in our >> distribution do not really need to be installed as root if they were >> installed where the user has write permissions. There would hence be >> little overhead over what we have

Re: Clearing the conffile status of a file

* Sven Joachim: > On 2017-07-12 09:56 +0200, Florian Weimer wrote: > >> I've got a request to remove the conffile status of a file after it is >> no longer a conffile. dpkg-maintscript-helper rm_conffile does not >> seem to do this, based on the documenta

Clearing the conffile status of a file

I've got a request to remove the conffile status of a file after it is no longer a conffile. dpkg-maintscript-helper rm_conffile does not seem to do this, based on the documentation and the source code. Is there a clean way to implement this (i.e., by not patching /var/lib/dpkg/status directly)?

Accepted debsecan 0.4.19 (source all) into unstable

-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Format: 1.8 Date: Sun, 02 Jul 2017 12:31:29 +0200 Source: debsecan Binary: debsecan Architecture: source all Version: 0.4.19 Distribution: unstable Urgency: medium Maintainer: Florian Weimer <f...@deneb.enyo.de> Changed-By: Florian Wei

Re: [WARNING] Intel Skylake/Kaby Lake processors: broken hyper-threading

* Ben Hutchings: > On Mon, 2017-06-26 at 08:34 +, Holger Levsen wrote: >> On Sun, Jun 25, 2017 at 09:19:36AM -0300, Henrique de Moraes Holschuh wrote: >> [...] >> > Apparently, Intel had indeed found the issue, *documented it* (see >> > below) and *fixed it*.  There was no direct feedback to

Re: System libraries and the GPLv2

* Philip Hands: > P.P.S. Does anyone really expect a consensus to emerge where we decide > to ignore the exception to the exception across the board without > consulting lawyers? I think there are several people in this thread > (myself included) that have demonstrated that they're going to

Re: System libraries and the GPLv2

* Lars Wirzenius: > A compication in this is that even though the developers of a program > would be happy with linking to OpenSSL, people who've written other > libraries the program uses, or other code included in the program, may > not be. I'm such a person. If some code I've released some

Re: System libraries and the GPLv2

* Richard Fontana: > On Thu, Mar 30, 2017 at 05:08:24AM +0200, Carlos Alberto Lopez Perez wrote: > >> Do you (or anyone else) _really_ think the copyright holders of the GPL >> program in question had any intention ever of not allowing their program >> to be used along with OpenSSL, when they

Re: System libraries and the GPLv2

* Adam Borowski: > The approach of commercial companies to both code and law is "it compiles? > Ship it!". They have sizeable legal departments, so the question they ask > themselves is not "is this legal?" but "are costs of possible litigation > smaller or greater than the cost of doing it

Re: System libraries and the GPLv2

* Josh Triplett: > The intention of the system library exception is to allow third > parties to ship Free Software on proprietary platforms, while > pointedly *disallowing* the vendor of the proprietary platform from > doing so. As historical precedent, note that some vendors explicitly >

Re: dlopen()ing shared libraries considered harmful (was Re: Depends/Recommends from libraries)

* Guillem Jover: >> dlopen()ing dependencies in the way that is most commonly implemented, >> with dlopen("libimobiledevice.so.6") and dlsym(handle, "idevice_new") >> or similar, has some practical problems for Debian: >> >> * The libraries used aren't visible to dpkg-shlibdeps. The maintainer

System libraries and the GPLv2 (was: Re: GnuTLS in Debian)

* Andreas Metzler: > Problems: > - > GnuTLS 2.12.x is dated. It is upstream's old-old-old stable release > (followed by 3.[012].x). The latest bugfix release happened in > February 2012, later security fixes have not been solved by releases but > by patches in GIT. GnuTLS 2.12.x does not

Re: Graphical package installers & debconf

* Sean Whitton: > On Thu, Mar 23, 2017 at 07:14:35AM -0400, Jeremy Bicha wrote: >> It is also useless for someone who will install Chromium from the >> Software app (gnome-software) included in 'gnome-core' since the >> Software app does not display debconf prompts. > > Do you know if this is a

Accepted quagga 1.0.20160315-3 (source amd64 all) into unstable

org> Changed-By: Florian Weimer <f...@deneb.enyo.de> Description: quagga - BGP/OSPF/RIP routing daemon quagga-dbg - BGP/OSPF/RIP routing daemon (debug symbols) quagga-doc - documentation files for quagga Closes: 841162 Changes: quagga (1.0.20160315-3) unstable; urgency=high . * Apply

Re: New project goal: Get rid of Berkeley DB (post jessie)

* Adrien CLERC: > Le 19/06/2014 11:38, Ondřej Surý a écrit : >> List of affected maintainers follows: >> >> Loic Minier >>evolution-data-server (U) >>rpm (U) > I am just a simple user of rpm. Yes, I use rpm for inspecting, > debugging, and so on. I don't use it for

Re: PIE and static libraries

* Jiri Jaburek: > On 09/12/16 13:42, Jakub Wilk wrote: >> * Bálint Réczey , 2016-09-12, 13:21: Reading up on the subject so far, I got the impression that most static libraries should be built with PIE, but not necessarily PIC (to allow building

Re: Debian is not welcome on Microsoft Azure

* Hideki Yamane: > So I thinks we should care such situations, and try to improve it > by adding hyperv-daemons package to stable (it means for production > system). Sure. The first step is to determine if we want to build this from the kernel source package (as a new binary package), or if

Re: Minutes from the 32bit architectures in Debian-bof

* Andreas Barth: * Florian Weimer (f...@deneb.enyo.de) [150823 17:02]: * Andreas Barth: Specific issues: - for i386, there is still sold new hardware with 32bit-only. Are there open issues for i386 (apart from the 32bit-generic ones)? FWIW, for x32, the security team would prefer

Re: Minutes from the 32bit architectures in Debian-bof

* Andreas Barth: Specific issues: - for i386, there is still sold new hardware with 32bit-only. Are there open issues for i386 (apart from the 32bit-generic ones)? FWIW, for x32, the security team would prefer if support in the Debian amd64 kernel would remain guarded by a boot-time option.

Re: GitHub “pull request” is useful and can be easily integrated'’

* Ondřej Surý: Also it still doesn't solve the issue the quarrel here is about - you still need some account - in this case a local GitLab instance account (well, Alioth could be used if that's in LDAP) to contribute. I don't quite understand this criticism. Surely direct write access to the

Re: debian github organization ?

* Jérémy Lal: i was wondering if debian had a github account as an organization, where maintainers could be added. Github has a single-account-per-person policy (unless you pay, I think), so for those of us with multiple affiliations, it is difficult to join a Debian organization on Github.

Re: Is the Debian dependency system broken? (wget vs libgnutls-deb0-28)

* Andreas Metzler: It is just that an application may not link at the same time against libnettle4 and libgnutls-deb0-28 3.3.15-5. Neither Debian nor afaik any other major distribution supports this kind of complexity in its dependency system (conditional dependencies). And package

Re: GitHub “pull request” is useful and can be easily integrated'’

* Paul Wise: On Sun, Jul 19, 2015 at 5:49 PM, Florian Weimer wrote: I don't quite understand this criticism. Surely direct write access to the repository always needs some sort of authentication step? Not sure about for http/https/ssh but the git protocol allows for anonymous push access

Re: debian github organization ?

* Andrew Shadura: On 19 July 2015 at 11:52, Florian Weimer f...@deneb.enyo.de wrote: i was wondering if debian had a github account as an organization, where maintainers could be added. Github has a single-account-per-person policy (unless you pay, I think), so for those of us with multiple

Re: Adding support for LZIP to dpkg, using that instead of xz, archive wide

* Thomas Goirand: As a friend puts it: This is a fundamental problem/defect with xz. This (and a lot of other such defects, e.g. non-robustness of xz archives that easily lead to file corruption etc) Corruption breaks signatures, making the file unusable, so that's not really an issue for

Re: The Spirit of Free Software, or The Reality

* Bas Wijnen: I disagree that the safebrowsing part is not serious, especially considering that it continues to send a message there on every new page you visit. That's not what should happen. Google can essentially make Iceweasel do that by serving appropriate static data instructing the

Re: The Spirit of Free Software, or The Reality

* Paul Wise: [Safe Browsing] Why doesn't it just download the full list and do checks client-side? The contents of this list is proprietary. Google might not even own it (or parts of it). There may also be a need for operational secrecy for such technology. Publishing the list would also

Re: The Spirit of Free Software, or The Reality

* Bas Wijnen: I have some experience with safe browsing, but indeed I have not looked up how it works. I do know that it continuously sends data to Google, and I have quite a bit of confidence in their capability and willingness to use that data for tracking. From your description it

Re: The Spirit of Free Software, or The Reality

* Nikolaus Rath: On Jul 15 2015, Bas Wijnen wij...@debian.org wrote: As Jakub was saying: just starting it up without even visiting a site yet will do a POST and a *few dozen* GET requests. Shouldn't it be waiting with its checks until it actually knows what to check? What is it sending

Re: debian github organization ?

* Ben Caradoc-Davies: On 19/07/15 21:52, Florian Weimer wrote: * Jérémy Lal: i was wondering if debian had a github account as an organization, where maintainers could be added. Github has a single-account-per-person policy (unless you pay, I think), so for those of us with multiple

Re: Replacement Default Icons for Iceweasel [was Re: The Spirit of Free Software, or The Reality]

* Don Armstrong: On Thu, 16 Jul 2015, Don Armstrong wrote: This is why I said if they're necessary, then they're necessary. Here's a set of default icons which can trivially be expanded to avoid shipping those icons and downloading them: for icon in ebay google wikipedia bing; do

Re: linking perl statically against libperl

* Niko Tyni: If there are several /usr/bin/perl processes and /usr/bin/perl is statically linked against libperl, every process has its own copy of the libperl code in memory. In the case of dynamic linking, there's just one copy. No, there is still only one copy in memory (or two if

Re: Debian PHP upgrade

* Andile Ntebe: On 2015/03/28, 10:42 PM, Florian Weimer f...@deneb.enyo.de wrote: * Andile Ntebe: Im not sure why Gareth said PHP, I’m referring to Apache 2.2.22. The below vulnerabilities seem to affect this version: Hi Andile, Where did you get this list? Here you go: http

Re: Debian PHP upgrade

* Andile Ntebe: Im not sure why Gareth said PHP, I’m referring to Apache 2.2.22. The below vulnerabilities seem to affect this version: Hi Andile, Where did you get this list? Thanks, Florian -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe.

Accepted debsecan 0.4.18 (source all) into unstable

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.8 Date: Sun, 22 Feb 2015 20:09:52 +0100 Source: debsecan Binary: debsecan Architecture: source all Version: 0.4.18 Distribution: unstable Urgency: low Maintainer: Florian Weimer f...@deneb.enyo.de Changed-By: Florian Weimer f

Re: Architectures where unaligned access is (not) OK?

* Simon McVittie: - OK: any-i386, any-amd64 SSE2 is part of amd64 and i386, and has strict alignment requirements. This is why stack alignment bugs in the toolchain are usually fatal. (We still support SSE2-less i386 installations, I think, but some libraries will use SSE2 when available.)

Accepted doscan 0.3.3-1 (source amd64) into unstable

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.8 Date: Sat, 25 Oct 2014 15:52:02 +0200 Source: doscan Binary: doscan Architecture: source amd64 Version: 0.3.3-1 Distribution: unstable Urgency: low Maintainer: Florian Weimer f...@deneb.enyo.de Changed-By: Florian Weimer f...@deneb.enyo.de

Re: GPL-3 openssl: provide a -nossl variant for a library

* Henrique de Moraes Holschuh: The problem is that Debian is the operating system distributing the system libraries, and that all packages Debian distributes are *also* part of that same operating system. https://lists.debian.org/debian-legal/2002/10/msg00113.html

Accepted doscan 0.3.2-1 (source amd64) into unstable

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.8 Date: Thu, 23 Oct 2014 07:34:22 +0200 Source: doscan Binary: doscan Architecture: source amd64 Version: 0.3.2-1 Distribution: unstable Urgency: low Maintainer: Florian Weimer f...@deneb.enyo.de Changed-By: Florian Weimer f...@deneb.enyo.de

Re: GPL-3 openssl: provide a -nossl variant for a library

* Michael Fladischer: Considering this, is it a good idea to provide a librabbitmq1-nossl binary package that was built without OpenSSL while still having librabbitmq1 with OpenSSL-support? We do not do this for Python, which links against OpenSSL, and which is used from software under the

Automating snapshot.debian.org downloads

I'm reconstructing the history of a package in Debian (with the eventual goal of putting it into a Git repository). Are there any existing clients that help with automated downloads of multiple .dsc/source package bundles from snapshot.debian.org? I don't want to reinvent this particular wheel.

Re: Automating snapshot.debian.org downloads

* ChangZhuo Chen (陳昌倬): On Wed, Oct 22, 2014 at 02:59:00PM +0200, Florian Weimer wrote: Are there any existing clients that help with automated downloads of multiple .dsc/source package bundles from snapshot.debian.org? I don't want to reinvent this particular wheel. Try the following

  1   2   3   4   5   6   7   8   9   >