apt-get source linux behaves weird
Hi folks, when I do 'apt-get source linux' with jessie+sid enabled in sources.list, there's no way to select jessie's ksrc version by target release. Neither of these work: - apt-get source linux - apt-get -t jessie source linux - apt-get source linux/jessie Everytime the result is: ---8<--- $ apt-get source linux/jessie Reading package lists... Done Building dependency tree Reading state information... Done Selected version '4.1.3-1' (jessie) for linux NOTICE: 'linux' packaging is maintained in the 'Svn' version control system at: svn://anonscm.debian.org/svn/kernel/dists/trunk/linux/ Need to get 85.2 MB of source archives. Get:1 http://ftp.de.debian.org/debian/ sid/main linux 4.1.3-1 (dsc) [139 kB] Get:2 http://ftp.de.debian.org/debian/ sid/main linux 4.1.3-1 (tar) [84.3 MB] Get:3 http://ftp.de.debian.org/debian/ sid/main linux 4.1.3-1 (diff) [743 kB] Fetched 85.2 MB in 1s (76.5 MB/s) dpkg-source: info: extracting linux in linux-4.1.3 dpkg-source: info: unpacking linux_4.1.3.orig.tar.xz [...] ---8<--- Doing an 'apt-get source linux=3.16.7-ckt11-1+deb8u3' works as expected. My sources.list at this point is --8<- deb http://ftp.de.debian.org/debian jessie main contrib non-free deb-src http://ftp.de.debian.org/debian jessie main contrib non-free deb http://security.debian.org jessie/updates main contrib non-free deb-src http://security.debian.org jessie/updates main contrib non-free deb http://ftp.de.debian.org/debian jessie-updates main contrib non-free deb-src http://ftp.de.debian.org/debian jessie-updates main contrib non-free deb http://ftp.de.debian.org/debian jessie-proposed-updates main contrib non-free deb-src http://ftp.de.debian.org/debian jessie-proposed-updates main contrib non-free deb http://ftp.de.debian.org/debian jessie-backports main contrib non-free deb-src http://ftp.de.debian.org/debian jessie-backports main contrib non-free deb http://ftp.de.debian.org/debian sid main contrib non-free deb-src http://ftp.de.debian.org/debian sid main contrib non-free --8<- Am I missing something or is this a bug in apt? Any hints are greatly appreciated. Daniel PS: Please CC me, I'm not subscribed to the list
Deployment of buildd machines [was: Re: usrmerge -- plan B?]
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. Thanks! Daniel signature.asc Description: OpenPGP digital signature
Depends of libnss3
Hi, why does libnss3/buster depend on libc6 >= 2.28 for i386 but for amd64, >= 2.14 suffices? I'm running stretch/amd64 with libnss3 pinned to buster, using stretch's libc6. On that machine, live-build'ing an i386 stretch image no longer works since the current libnss3 migrated to buster a few days ago. As a consequence, stretch's libc6/i386 is too old to be able to accomodate libnss3/buster. Is there a technical rationale for this or is it maybe a problem with the i386 buildd on which libnss3/i386 was built? Thanks! Daniel signature.asc Description: OpenPGP digital signature
Re: Please drop anacron from task-desktop
> Shouldn't that be the other way around? Having .timer but not a cronjob is > a nasty bug, having a cronjob but not .timer is fine (at least unless you > have no cron implementation at all). +1! signature.asc Description: OpenPGP digital signature
Re: Please drop anacron from task-desktop
> And surely we support other, strange and not so strange, choices, > sometimes more and sometimes less, but yawn. And yet Debian claims to support - pardon - offer init systems other than systemd for usage. Either: make a clean cut, kick out everything that has been obsoleted™ by pötterd, thereby putting off (an unqualified number of) users Or: quit yawning and stick to offering different init systems - with all the shenannigans that follow. Sorry for flaming. Then again, yawning is not quite not-flaming as well. Thx Daniel signature.asc Description: OpenPGP digital signature
nvidia-smi:i386/stretch-bpo
Hi Axel, I'm wondering why there's no nvidia-smi:i386=410.104-1~bpo9+1 but only 390.87-8~bpo9+1. Has the binary package just not been built yet for i386/stretch-bpo or is nvidia-smi no longer supported for i386 by upstream? Thanks! Daniel signature.asc Description: OpenPGP digital signature
Re: nvidia-smi:i386/stretch-bpo
Thanks for your detailed explanation! > PS: today I uploaded src:nvidia-graphics-drivers with transitional > packages nvidia-driver, xserver-xorg-video-nvidia added on i386,armhf > that depend on the corresponding legacy driver packages. > I could do that for nvidia-smi as well. Any other (non-lib) packages? That would by *very* helpful - at least until some dependent requires a new feature not provided by -legacy-390xx or the latter gets from the archives for good. I'll let you know when I stumble over any other dependencies breaking my current live-build/i386… signature.asc Description: OpenPGP digital signature
Fwd: nvidia-driver meta package missing from stretch bpo
I haven't received a reply so far, so forwarding to -devel. Thanks Daniel Forwarded Message Subject: nvidia-driver meta package missing from stretch bpo Date: Sat, 13 Apr 2019 20:32:20 + From: Daniel Reichelt To: Andreas Beckmann , Debian NVIDIA Maintainers Hi *, a couple of days ago I did an apt upgrade and nvidia-driver:amd64=410.104-1~bpo9+1 got installed, everything fine. Just now I did an apt-get upgrade and it wanted to install nvidia-driver/buster. It seems like nvidia-driver is missing again from strech-bpo: [1] Is this a bug or a problem with the archive? If the removal was intentional, I'm curious as to why… Thanks! Daniel [1] https://packages.debian.org/search?suite=stretch-backports&searchon=names&keywords=nvidia-driver signature.asc Description: OpenPGP digital signature
Expired InRelease files
Hi, not sure against which package to file a bug so I'm posting here. Since today on apt update I get: E: Release file for http://ftp.de.debian.org/debian-debug/dists/bullseye-debug/InRelease is expired (invalid since 4h 32min 12s). Updates for this repository will not be applied. E: Release file for http://ftp.de.debian.org/debian-debug/dists/sid-debug/InRelease is expired (invalid since 4h 32min 13s). Updates for this repository will not be applied. Cheers Daniel signature.asc Description: OpenPGP digital signature
packages.d.o and listed suites
Hi *, since yesterday (roughly, probably earlier) some of my live-build images fail due to a new and faulty version of shim-signed. After a quick look on packages.d.o, I was pretty confused: nothing new listeded there for stable. Only 'apt-cache policy shim-signed' revealed to me that a new version was being dropped by buster-proposed-updates. Why is this suite not listed on packages.d.o? Thanks! Daniel signature.asc Description: OpenPGP digital signature
Re: kernel nvidia dkms rebuild after upgrade?
On 01/07/2018 07:47 PM, Boyan Penkov wrote: > and a backport (4.14.0-bpo2) -- in light of meltdown -- To avoid a false sense of security: according to [1], [2], [3], the current stretch-bpo kernel (linux-image-4.14.0-0.bpo.2-$arch) does *NOT* yet include any mitigations against meltdown. Daniel [1] https://security-tracker.debian.org/tracker/CVE-2017-5753 [2] https://security-tracker.debian.org/tracker/CVE-2017-5754 [3] https://security-tracker.debian.org/tracker/CVE-2017-5715 signature.asc Description: OpenPGP digital signature
Re: Maintaining a custom out-of-tree patched Debian kernel for specific hardware
Hi, what about ripping out the affected kernel modules and provide the patched sources in a separate package and have them built at install time via DKMS? In order to not interfere with the modules provided by the linux-image-* packages, you could - rename the kernel modules provided by your module package - add the original module names to a blacklist in /etc/modprobe.d - add your modules to /etc/modules-load.d/something - and finally add the blacklist and load list to your package as well. (An alternative to changing module names might be to use update-alternatives or dpkg-divert and just provide/integrate the renamed .ko files) The initial setup of the packaging/build script will require a bit of fiddling around but in the long run you'll be able to provide your users with updates much faster and without havingt to go through the time-consuming kernel build process. Moreover, the required storage and bandwith for the infrastructure holding your repository will be tiny compared to those for holding a full-blown kernel package. Cheers Daniel On 01/22/2018 03:08 PM, Kumar Appaiah wrote: > Dear Debian Developers, > > I am part of a team working on getting Debian on low cost laptops (see > http://www.rdp.in for details) so that they can be sold with Debian > preinstalled. While vanilla Debian largely works, unfortunately, > making Bluetooth and sound work require kernel rebuilding. The patches > and config changes are not likely to be upstreamed any time soon, so > we would have to ship the laptop with a patched (non-Debian > kernel). Our team is, thus, taking up the responsibility of ensuring > that up-to-date kernel (with security fixes) are made available to the > users of our laptop. The patches and configs are adapted from here: > https://github.com/sundarnagarajan/kernel_build > > The unfortunate situation is that I am forced to issue this patched > kernel. Since I'd like to be a good citizen of the ecosystem, I'd like > to outline the solution I have in mind. I'd like your opinion and > suggestion on this. All code being developed for this purpose will be > released under a DFSG compliant license, and all packages I refer to > that aren't in Debian will lie in our custom (outside of Debian) > repository. If there are any things I can do to make things better, > please do let me know. > > 1. The laptop will ship with stretch preinstalled, but with a custom > kernel built using the linux-source-x.xx.xx package with a custom > version number, such as linux-image-4.14.13-iitb-amd64. > > 2. The installation will contain a package called > linux-image-iitb-amd64 that conflicts with linux-image-amd64, and this > package will depend on the latest patched kernel built in the previous > step. > > 3. The sources.list on the installation will have an entry pointing to > my custom repository in addition to the regular http://deb.debian.org, > and will be pinned so that the kernel and kernel related packages are > obtained from my custom repository. Needless to say, the custom > repository's public key will also be pre-shipped with the laptop. > > 4. Users will be made aware of the fact that this is Debian with a > custom kernel without ambiguity. > > Now, whenever there is a kernel update in Debian, our team will fetch > the source of the updated kernel, patch, rebuild and make it available > in our repository. > > Please let me know if the proposed solution is good, else I am open to > suggestions. > > Thanks. > > Kumar > signature.asc Description: OpenPGP digital signature
Re: Maintaining a custom out-of-tree patched Debian kernel for specific hardware
On 01/23/2018 10:56 AM, Philipp Kern wrote: > On 01/23/2018 01:34 AM, Daniel Reichelt wrote: >> In order to not interfere with the modules provided by the linux-image-* >> packages, [...] >> (An alternative to changing module names might be to use >> update-alternatives or dpkg-divert and just provide/integrate the >> renamed .ko files) > FWIW, this technically isn't required. You can simply overwrite existing > modules and dkms will handle that fine. It will shadow the stock ones > when putting the new versions into updates/dkms. > > Kind regards > Philipp Kern Thanks for pointing that out! signature.asc Description: OpenPGP digital signature
Re: OpenSSL disables TLS 1.0 and 1.1
On 08/12/2017 02:16 PM, Tollef Fog Heen wrote: > While I think we might want to ship buster with TLS 1.0 available, I > think running with it disabled for parts of the development cycle is > very useful, since it exposes bugs we have in packages that will use > that version out of the box (isync being referred to elsethread). > Finding and fixing those bugs is good. > This got me thinking... how about a split of the generated binary packages to generate a (default) set with only TLS 1.2 available and a fallback set with the current configuration? One would have to work out a convention for whether 1) the fallback set would have both Provides and Conflicts set or 2) both sets should cooperate with each other and how 2.1) via alternatives 2.2) a more fine-grained approach to select an appropriately configured library on a per-application basis (e.g. LD_PRELOAD?) Cheers Daniel signature.asc Description: OpenPGP digital signature
Switching to sysvinit-core fails miserably in buster/sid
Hi *, for development purposes I frequently create xen-vms via xen-create-image (jessie, stretch, buster, sid - each in 32 and 64bit) on a stretch Dom0. In a custom role script for xen-tools, I install sysvinit-core. (For non-users of xen-tools: this happens after debootstrap has completed.) Until a few weeks ago, this used to be enough and everything worked just fine. Now, after sysvinit-core is installed, init scripts don't get enabled (i.e. S* symlinks are missing in /etc/rc?.d), which leaves a big mess of things as not even networking or ssh are enabled. It seems to me, this happens to init scripts of packages which were installed prior to sysvinit-core. I have yet to work out the details of this time-dependency, i.e. - whether it's sufficient that sysvinit-core gets processed prior to a init-script-carrying package - or if the entire run of dpkg installing sysvinit-core has to finish, and init scripts get processed correctly only if they're installed during a subsequent invocation of dpkg. As a workaround, after sysvinit-core is installed from the role script, I therein run cd /etc/init.d for script in * do update-rc.d "$script" enable done as well, which I suspect is quite crude and shouldn't be necessary in the first place. I don't have the first clue which package I should file a bug report against. Any hints appreciated! Thanks Daniel signature.asc Description: OpenPGP digital signature
Re: Switching to sysvinit-core fails miserably in buster/sid
Thanks a lot, Adam, for your detailed answer! With your information I could hunt this down and just filed #879771. Cheers Daniel signature.asc Description: OpenPGP digital signature
Re: Switching to sysvinit-core fails miserably in buster/sid
On 10/25/2017 08:03 PM, Felipe Sateler wrote: > Mea Culpa. This was a bug in the "defaults-disabled" implementation. I > have just uploaded a fixed version. > > Thanks for reporting. Don't sweat it, big thanks for your quick response from me, too. signature.asc Description: OpenPGP digital signature
