Re: Removal of linux-base from jessie-backports broke Xen upstream CI
On February 13, 2019 4:07:45 PM UTC, Ansgar wrote: >More importantly Jessie has reached end-of-life[1]. Please do not >expect related suites (such as -security, -backports, -proposed- >updates, -updates) to continue working after this. -security and -updates are part of the LTS sources.list on https://wiki.debian.org/LTS/Using so ought to stick around until 2020, at least for some architectures (not arm64, though).
Re: Removal of linux-base from jessie-backports broke Xen upstream CI
Hi, On 2/13/19 1:09 PM, Ian Jackson wrote: > I would like to recount a situation. I'm not sure where, if anywhere, > the root bug(s) lie, but I am inclined to say that a big part of the > problem was a change to the contents of jessie-backports. I would be > interested to hear what the backports team and ftpmaster have to say; > in particular, if anyone knows the answers to my questions below. > > My tentative conclusions are that: > > 1. Packages should not be removed from foo-backports just because a > similar package is in foo-security, because there are situations where > a host may have been relying on the package being in foo-backports and > a similar (even, newer) package being in foo-security is not > sufficient. I very much disagree with that. That situation obsoleted the one in -backports, and thus it made no sense to continue to carry it. > 2. Cruft removal in stable releases, including in -backports, should > perhaps be done with care/caution/announcement or something. -backports accompanies stable. There was no package removed from the complete suite of stable + -backports. Also, we also remove packages from -backports when they become unavailable in testing/unstable and thus can't be considered a backport anymore. That includes packages that weren't even in stable - which isn't an easy decision, but it doesn't make sense to carry packages solely in -backports (which isn't the case here - just as a help for understanding the background). > Using the jessie-backports kernel with the jessie installer involves > using the preseed hook mechanism to add jessie-backports to the > target's apt sources, and an in-target apt-get install rune to install > the kernel package. > > (Using the jessie-backports kernel also involves editing the installer > image to have the jessie-backports kernel and modules, but that is not > relevant to this tale.) I don't really follow - you now can get rid of that special casing (which had to be added specifically) and reduce complexity. I actually see this even as a win situation for your setup. > However, after that change to the archive, the dependency resolver > from jessie's apt, in our CI, is no longer willing to update to > linux-base from jessie-security. (I have not yet investigated in > detail but I suspect that the apt-get -t jessie-backports rune above > is part of that causal chain.) Please simply remove the special casing and move on? I really don't understand why this needs to be made a big fuzz about. > The reason I say that I am not sure is that the CI commit which added > that rune had, according to its commit message, an additional effect > of putting backports in the apt sources; perhaps that latter would > have been sufficient. (After I have sent this mail I am going to mess > about with the system to find a way to get it working properly again.) > > Q: Was `apt-get install -t backports linux-base' >unnecessary (and wrong) ? If you needed the newer package that would be the sensible approach. But things changed, it is _now_ unecessary (and was even before removal of the package from backports). So that special casing can get dropped. > It is unfortunate that something which worked for a period of over 2 > years was broken by an archive change. Sometimes things change. The package wouldn't be maintained in backports anymore and thus even had put you in a bad spot if you wouldn't have pulled in the package from stable directly, even if we kept it around (and dangling and unsupported and ...) > Q. Why was linux-base removed from jessie-backports ? Because it was pointed out to me and it was the sensible thing to do. While I now see that it causes issues for specifically crafted setups like you have, technically it was the proper thing to do - and now knowing that it caused issues for your setup I very likely would still do it because having unsupported packages lying around makes very little sense because it sends the wrong message. Thanks for bringing this to our attention. I think what we can do is announce removal of packages to make people aware of the whys. Cheers, Rhonda
Bug#922292: ITP: social-app-webpy -- Web.py component of the python-social-auth ecosystem
Package: wnpp Severity: wishlist Owner: "W. Martin Borgert" * Package name: social-app-webpy Version : 1.0.0 Upstream Author : Matías Aguirre * URL : https://pypi.python.org/pypi/social-auth-app-django * License : BSD-3 Programming Lang: Python Description : Web.py component of the python-social-auth ecosystem This is the web.py component of the python-social-auth ecosystem, it implements the needed functionality to integrate social-auth-core in a web.py based project.
Bug#922294: ITP: social-examples -- collection of examples implementations of the python-social-auth ecosystem
Package: wnpp Severity: wishlist Owner: "W. Martin Borgert" * Package name: social-examples Version : n/a Upstream Author : Matías Aguirre * URL : https://github.com/python-social-auth/social-examples * License : BSD-3 Programming Lang: Python Description : collection of examples implementations of the python-social-auth ecosystem Python Social Auth is an easy to setup social authentication/ registration mechanism with support for several frameworks and auth providers. This is a collection of examples implementations of the python-social-auth ecosystem functionality.
Re: Removal of linux-base from jessie-backports broke Xen upstream CI
> "Rhonda" == Rhonda D'Vine writes: >> installer image to have the jessie-backports kernel and modules, >> but that is not relevant to this tale.) Rhonda> I don't really follow - you now can get rid of that special Rhonda> casing (which had to be added specifically) and reduce Rhonda> complexity. I actually see this even as a win situation for Rhonda> your setup. It's not always a win when I have to make changes to my software on your schedule even if the changes make things better in the long run. Much of the appeal to a large class of people of stable distributions is that they expect not to have to make changes to their software on other people's schedules. I agree with Ian that it's generally bad when we force people using stable to change their stuff that was working, even when those changes make things better. There are tradeoffs to balance. You've given some good arguments why you balance the tradeoffs differently than Ian. However, I do hope that you'll be able to think about things from his standpoint and understand why it is frustrating when things based on something stable used to work and now do not. It doesn't mean you're wrong or he's right. If I haven't been sufficiently clear and you're interested in working to gain that understanding I'm happy to spend more time. Thanks, --Sam
Re: Removal of linux-base from jessie-backports broke Xen upstream CI
Firstly, thanks for taking the time to read what I wrote. (Thanks
also for Sam for his helpful perspective.)
Stepping back a bit, and firmly putting my `user' hat on:
My aim was to share my experience, because I guess the point of
jessie-backports (and of much of what we do in Debian) is to help
Debian's users. In this case I was a user who had something go wrong,
but I was in the unusually fortunate situation of being able (due to
my personal skills, my support network, and my available time) to
diagnose the problem and write up a report.
I did this because I thought it would be worthwhile seeing if Debian
thought there was anything here to be learned, about how to better
support some of its users. If those responsible for these services
don't think so, then, well, as users we get what we pay for.
If those responsible for -backports don't value this kind of feedback
then of course next time I can not write it up as a learning
opportunity for Debian. I can just work around it instead.
Rhonda D'Vine writes ("Re: Removal of linux-base from jessie-backports broke
Xen upstream CI"):
> On 2/13/19 1:09 PM, Ian Jackson wrote:
> > 1. Packages should not be removed from foo-backports just because a
> > similar package is in foo-security, because there are situations where
> > a host may have been relying on the package being in foo-backports and
> > a similar (even, newer) package being in foo-security is not
> > sufficient.
>
> I very much disagree with that. That situation obsoleted the one in
> -backports, and thus it made no sense to continue to carry it.
>
> > 2. Cruft removal in stable releases, including in -backports, should
> > perhaps be done with care/caution/announcement or something.
>
> -backports accompanies stable. There was no package removed from the
> complete suite of stable + -backports. Also, we also remove packages
> >from -backports when they become unavailable in testing/unstable and
> thus can't be considered a backport anymore. That includes packages
> that weren't even in stable - which isn't an easy decision, but it
> doesn't make sense to carry packages solely in -backports (which isn't
> the case here - just as a help for understanding the background).
[and later:]
> > Q. Why was linux-base removed from jessie-backports ?
...
> I very likely would still
> do it because having unsupported packages lying around makes very little
> sense because it sends the wrong message.
I get the impression that your mind is made up that I was doing
something wrong. That's fair enough (even though I don't understand
what it is I am supposed to have done wrong except maybe not having
managed to get this thing onto stable yet - after all, it's not your
responsibility to explain that to me).
I will say one thing though: your response seems primarily to be based
on general rules which I guess are agreed amongst the backports team.
I had hoped that it might be possible to examine whether those rules
are always right, or should perhaps be changed.
(Also I am in general extremely sceptical about arguments along the
lines of `this is to send the right message'.)
You also gave some suggestions for how I should proceed on a technical
level. Thanks for trying to help. Of course how I proceed is up to
me and I don't need to convince you. And as I say I have worked
around the problem now.
But for the benefit of others reading, at least, it seems like I
should at least mention a couple of things where I don't agree with
what you have said.
> > Using the jessie-backports kernel with the jessie installer involves
> > using the preseed hook mechanism to add jessie-backports to the
> > target's apt sources, and an in-target apt-get install rune to install
> > the kernel package.
> >
> > (Using the jessie-backports kernel also involves editing the installer
> > image to have the jessie-backports kernel and modules, but that is not
> > relevant to this tale.)
>
> I don't really follow - you now can get rid of that special casing
> (which had to be added specifically) and reduce complexity. I actually
> see this even as a win situation for your setup.
In fact, that's not right. It definitely adds an additional special
case.
When one is using a kernel from foo-backports, it is generally
necessary to have an updated linux-base. Previously I thought that
the way to ask for an updated linux-base is
apt-get -t foo-backports install linux-base
alongside
apt-get -t foo-backports install linux-image-riscv64
or whatever. AIUI you have told me that is usually right.
But you are telling me that whether I need the first rune depends not
only on whether I need a newer kernel. It also depends on whether a
newer linux-base exists in foo-security: if it does, I *must* omit the
first rune; if it does not, I *must* include it.
So whether my automation needs this rune varies, (i) according to the
value of `foo', and (ii) with time. Of course it is not OK for my
system to randomly rot in an u
Bug#922335: ITP: convertdate -- Converts between Gregorian dates and other calendar
Package: wnpp Severity: wishlist Owner: Antoine Beaupre * Package name: convertdate Version : 2.1.3 Upstream Author : Neil Freeman * URL : https://github.com/fitnr/convertdate/ * License : MIT/Expat? Programming Lang: Python Description : Converts between Gregorian dates and other calendar Convertdate allows you to generate calendars according to different historical or modern systems: Available calendars: Bahai Coptic (Alexandrian) French Republican Gregorian Hebrew Indian Civil Islamic Julian Mayan Persian Positivist Mayan ISO Ordinal (day of year) Dublin day count Julian day count The holidays module also provides some useful holiday-calculation, with a focus on North American and Jewish holidays. This is a dependency of dateparser, which was overlooked when packaging. I can co-maintain with the DPMT.
Bug#922353: ITP: socket-activate -- Run a socket-activated daemon with minimal dependencies
Package: wnpp Severity: wishlist Owner: Daniel Kahn Gillmor * Package name: socket-activate Version : 0.1 Upstream Author : Daniel Kahn Gillmor * URL : https://gitlab.com/dkg/socket-activate * License : GPL Programming Lang: Python Description : Run a socket-activated daemon with minimal dependencies socket-activate makes it possible to use socket-activated services on Unix-based systems that don't have systemd installed at all. It implements the environment variable and file descriptor convention described in sd_listen_fds(3) without using any external code or dependencies from systemd. The only thing it depends on is python3 itself. See https://bugs.debian.org/922082 for more discussion of the motivation for this project. Future versions might be in C, so that even python isn't required, but the initial python implementation is intended to validate the interface. Note that while i'm the responsible upstream on socket-activate, i'd welcome any other contributions to it.
Re: Removal of linux-base from jessie-backports broke Xen upstream CI
Hi,
Here's a few extra of my cents (buy yourself some ice cream from it).
I'm not going to touch the subject of why packages should or should not
be removed in particular cases, but I'd like to add some feedback from a
point of view of another user who wants to end up with the same result,
Jessie with 4.9 kernel.
On 2/14/19 5:09 PM, Ian Jackson wrote:
> Firstly, thanks for taking the time to read what I wrote. (Thanks
> also for Sam for his helpful perspective.)
>
> Stepping back a bit, and firmly putting my `user' hat on
For the user it is recommended to use meta packages to install kernels,
so that they keep getting updated when ABI level is bumped, and to
resolve dependencies.
> My aim was to share my experience, because I guess the point of
> jessie-backports (and of much of what we do in Debian) is to help
> Debian's users. In this case I was a user who had something go wrong,
> but I was in the unusually fortunate situation of being able (due to
> my personal skills, my support network, and my available time) to
> diagnose the problem and write up a report.
As user, I also still have some jessie systems with 4.9 kernel.
At first I did...
apt-get install -t jessie-backports linux-image-amd64
...which automatically drags in linux-base from backports.
After reading these messages...
https://lists.debian.org/debian-backports-announce/2018/07/msg0.html
https://lists.debian.org/debian-lts-announce/2018/07/msg00020.html
https://lists.debian.org/debian-lts-announce/2018/07/msg00021.html
...I switched to linux-image-4.9-amd64 in Jessie, and I haven't even
been thinking about what happened to linux-base in that process until today.
> Rhonda D'Vine writes ("Re: Removal of linux-base from jessie-backports broke
> Xen upstream CI"):
>> On 2/13/19 1:09 PM, Ian Jackson wrote:
>>> 1. Packages should not be removed from foo-backports just because a
>>> similar package is in foo-security, because there are situations where
>>> a host may have been relying on the package being in foo-backports and
>>> a similar (even, newer) package being in foo-security is not
>>> sufficient.
This kernel stuff is quite a snowflake, since kernel team wanted to keep
updating the 4.9 kernel in Jessie, while that would be impossible after
discontinuing jessie-backports.
Renaming the meta-package and forcing all users to do $something to keep
getting updates was bad, but at least within the limits and rules that
Debian sets itself, something was made possible, by using a hack via
-security to get updates to users.
> I get the impression that your mind is made up that I was doing
> something wrong.
Stepping on thin ice here. :) .. Yeah, just install the meta-package,
they're invented to handle dependencies for you!
> When one is using a kernel from foo-backports, it is generally
> necessary to have an updated linux-base. Previously I thought that
> the way to ask for an updated linux-base is
> apt-get -t foo-backports install linux-base
> alongside
> apt-get -t foo-backports install linux-image-riscv64
> or whatever. AIUI you have told me that is usually right.
When using -t on the command line, it will also allow getting
dependencies from that target release. There's no need to do anything
with linux-base explicitly.
> Increased communication would certainly be welcome.
The communication in the linked messages above was very clear to me. It
explained me why this choice had to be made, and what I had to change to
keep getting updates.
Being on debian-lts-announce is the least that can be expected from LTS
users.
Now, for your particular use case, the whole new package stuff doesn't
seem to add value, because there's no arm64 support in the packages that
are getting in via -security now. But, at least you would get
inux-image-4.9.0-0.bpo.6-arm64 with 4.9.88 instead of ancient 4.9.18.
\o/
Knorrie
Work-needing packages report for Feb 15, 2019
The following is a listing of packages for which help has been requested through the WNPP (Work-Needing and Prospective Packages) system in the last week. Total number of orphaned packages: 1392 (new: 5) Total number of packages offered up for adoption: 158 (new: 2) Total number of packages requested help for: 58 (new: 0) Please refer to https://www.debian.org/devel/wnpp/ for more information. The following packages have been orphaned: gnulib (#921954), orphaned 4 days ago Description: GNU Portability Library Installations reported by Popcon: 297 Bug Report URL: https://bugs.debian.org/921954 posixtestsuite (#921980), orphaned 4 days ago Description: POSIX conformance test suite report log Installations reported by Popcon: 6 Bug Report URL: https://bugs.debian.org/921980 pygdchart2 (#921957), orphaned 4 days ago Description: Python OO interface to GDChart Installations reported by Popcon: 43 Bug Report URL: https://bugs.debian.org/921957 python-visual (#921955), orphaned 4 days ago Description: VPython 3D scientific visualization library Reverse Depends: epigrass Installations reported by Popcon: 208 Bug Report URL: https://bugs.debian.org/921955 x11vnc (#921960), orphaned 4 days ago Description: VNC server to allow remote access to an existing X session Reverse Depends: epoptes epoptes-client gitso veyon-service x11vnc Installations reported by Popcon: 6332 Bug Report URL: https://bugs.debian.org/921960 1387 older packages have been omitted from this listing, see https://www.debian.org/devel/wnpp/orphaned for a complete list. The following packages have been given up for adoption: cyrus-imapd (#921717), offered 6 days ago Description: Cyrus mail system - IMAP support Reverse Depends: cyrus-admin cyrus-caldav cyrus-clients cyrus-dev cyrus-imapd cyrus-murder cyrus-nntpd cyrus-pop3d cyrus-replication Installations reported by Popcon: 368 Bug Report URL: https://bugs.debian.org/921717 xen-tools (#922126), offered 2 days ago Description: Tools to manage Xen virtual servers Installations reported by Popcon: 1142 Bug Report URL: https://bugs.debian.org/922126 156 older packages have been omitted from this listing, see https://www.debian.org/devel/wnpp/rfa_bypackage for a complete list. For the following packages help is requested: autopkgtest (#846328), requested 806 days ago Description: automatic as-installed testing for Debian packages Reverse Depends: autodeb-worker debci-worker Installations reported by Popcon: 1167 Bug Report URL: https://bugs.debian.org/846328 balsa (#642906), requested 2699 days ago Description: An e-mail client for GNOME Installations reported by Popcon: 695 Bug Report URL: https://bugs.debian.org/642906 broadcom-sta (#886599), requested 402 days ago (non-free) Description: Broadcom STA Wireless driver (non-free) Installations reported by Popcon: 1881 Bug Report URL: https://bugs.debian.org/886599 cargo (#860116), requested 674 days ago Description: Rust package manager Reverse Depends: cargo-vendor dh-cargo Installations reported by Popcon: 880 Bug Report URL: https://bugs.debian.org/860116 cyrus-sasl2 (#799864), requested 1240 days ago Description: authentication abstraction library Reverse Depends: 389-ds-base 389-ds-base-legacy-tools 389-ds-base-libs adcli autofs-ldap cairo-dock-mail-plug-in claws-mail claws-mail-acpi-notifier claws-mail-address-keeper claws-mail-archiver-plugin (114 more omitted) Installations reported by Popcon: 199022 Bug Report URL: https://bugs.debian.org/799864 dee (#831388), requested 944 days ago Description: model to synchronize mutiple instances over DBus Reverse Depends: dee-tools gir1.2-dee-1.0 libdee-dev zeitgeist-core Installations reported by Popcon: 59599 Bug Report URL: https://bugs.debian.org/831388 developers-reference (#759995), requested 1629 days ago Description: guidelines and information for Debian developers Installations reported by Popcon: 10864 Bug Report URL: https://bugs.debian.org/759995 devscripts (#800413), requested 1234 days ago Description: scripts to make the life of a Debian Package maintainer easier Reverse Depends: apt-build apt-listdifferences aptfs arriero autodeb-worker brz-debian bzr-builddeb customdeb debci debian-builder (29 more omitted) Installations reported by Popcon: 12585 Bug Report URL: https://bugs.debian.org/800413 docker.io (#908868), requested 152 days ago Description: Linux container runtime Rever
Bug#922366: ITP: blur-network-gui -- A graphical frontend to the Blur Network wallet. BLUR is an experimental, privacy-focused cryptocurrency.
Package: wnpp Severity: wishlist Owner: who-biz Package name: Blur Network GUI Wallet Version : 0.1.8.3 Upstream Author : The Blur Network URL : https://www.blur.cash License : BSD Programming Lang: Qt, C++ Description : A graphical frontend to the Blur Network wallet. BLUR is an experimental, privacy-focused cryptocurrency. This package is a graphical frontend to the Blur Network wallet. BLUR is an experimental private cryptocurrency that allows users to transact in a way that is secure and verifiable to only the parties they choose. Transaction amounts and participants are obfuscated to protect your privacy. BLUR features the new Cryptonight-Dynamic algorithm, which adjusts once every second. Join the Fight for Financial Freedom. This package allows debian users to send/receive BLUR (the private cryptocurrency). Blur is a fork of Monero, but designed to be mined by only CPUs on a network that strives to separate itself from pooled mining. The Blur Network views the pooled mining practice as the single largest threat to decentralization in any cryptocurrency's network. I plan on maintaining this package myself, and I am in the process of packaging the graphical wallet for Monero as well. I am willing to maintain that package as well, but would be grateful to have help from other maintainers in both endeavors. I do not currently have a sponsor for maintaining debian packages, so I am in need of a sponsor. I would be happy to set up a team for maintaining this package, as well as the one I will be submitting for Monero.
Re: Bug#922353: ITP: socket-activate -- Run a socket-activated daemon with minimal dependencies
Hi! On Thu, 2019-02-14 at 17:36:31 -0500, Daniel Kahn Gillmor wrote: > Package: wnpp > Severity: wishlist > Owner: Daniel Kahn Gillmor > > * Package name: socket-activate > Version : 0.1 > Upstream Author : Daniel Kahn Gillmor > * URL : https://gitlab.com/dkg/socket-activate > * License : GPL > Programming Lang: Python > Description : Run a socket-activated daemon with minimal dependencies > socket-activate makes it possible to use socket-activated services on > Unix-based systems that don't have systemd installed at all. > > It implements the environment variable and file descriptor convention > described in sd_listen_fds(3) without using any external code or > dependencies from systemd. The only thing it depends on is python3 > itself. > > See https://bugs.debian.org/922082 for more discussion of the > motivation for this project. Future versions might be in C, so that > even python isn't required, but the initial python implementation is > intended to validate the interface. Another option would be to implement this in start-stop-daemon, like the similar support for the systemd readiness protocol was recently implemented there too. Thanks, Guillem
Re: Removal of linux-base from jessie-backports broke Xen upstream CI
On Thu, 14 Feb 2019, Ian Jackson wrote: > Firstly, thanks for taking the time to read what I wrote. (Thanks > also for Sam for his helpful perspective.) > > > Stepping back a bit, and firmly putting my `user' hat on: > > My aim was to share my experience, because I guess the point of > jessie-backports (and of much of what we do in Debian) is to help > Debian's users. In this case I was a user who had something go wrong, > but I was in the unusually fortunate situation of being able (due to > my personal skills, my support network, and my available time) to > diagnose the problem and write up a report. > > I did this because I thought it would be worthwhile seeing if Debian > thought there was anything here to be learned, about how to better > support some of its users. If those responsible for these services > don't think so, then, well, as users we get what we pay for. > > If those responsible for -backports don't value this kind of feedback > then of course next time I can not write it up as a learning > opportunity for Debian. I can just work around it instead. So let me rephrase as an admin. You - the user - ignored three announcements about the deprecation and the change of the metapackage handling of the linux-image package, but you want us to send more even more announcements to get you better informed? I don't get it, what distinguishes those explicit removal announcements from the other announcements you ignored? Alex - backports ftpmaster signature.asc Description: PGP signature
