Bug#931841: ITP: python-dateutils -- complex operations on dates/times
Package: wnpp Severity: wishlist Owner: Steffen Moeller * Package name: python-dateutils Version : 0.6.5 * URL : https://github.com/plytophogy/python-dateutils * License : BSD Programming Lang: Python Description : complex operations on dates/times To be team-maintained on https://salsa.debian.org/python-team/DPMT/python-dateutils
Re: Apt-secure and upgrading to bullseye
As I have noted in my previous reply there are VARIOUS bugreports dealing with different aspects of this, so rehashing it all lumped together on d-d@ is not very productive and I would like to advice anyone seriously interested in this to contribute to the relevant one instead. And the rest can be happy as they were asking for "testing" and they got to test something and the gathered test results are now being worked on… On Wed, Jul 10, 2019 at 11:47:28PM -0400, The Wanderer wrote: > For myself, no, a shorter/simplified version of the release notes > probably wouldn't have made me more likely to read them. Clients producing these errors can optionally also print a pointer to the release notes btw, just in case that would nudge anyone to give them a read, it was just not used for now for buster. N: More information about this can be found online in the Release notes at: https://example.org/future > it using apt-get - since that's my preferred client, and the idea of > switching clients just for a single task like this strikes me as > intuitively wrong somehow. In fact, it's possible that I *did* do that; JFTR: apt and apt-get use the very same code for "update" via libapt. In fact all package managers in Debian do, be it aptitude, synaptics or your preferred software center [okay, there are exceptions, but if you happen to use one you will know that]. As such you can mix and match apt clients as much as you like. The difference is in the presentation: "apt" tries to be a little friendlier in interactive usage while "apt-get" sticks to 'what it always did' as much as it can without negative effects [= big bugs and security tend to be the only reason for it changing drastically]. As it is usual for apt clients there is an option for basically everything though. Setting the options listed by the following command for apt-get as well will make it behave as if it were apt: apt-config dump --no-empty Binary::apt Binary::apt::APT::Get::Update::InteractiveReleaseInfoChanges "1"; being responsible for the interactive question in update btw. APT is really not as much magic as people believe… (but I might be biased 😉) > different clients, earlier in this thread. IMO, if the release notes > need to document any of them, they should document all - or, if it's As an example, the current plan is to make the switch over for Suite changes automatic – if some preconditions are satisfied. The discussion about that isn't hard to find, but here you go: #931566. You are welcome to add any good ideas not already present (that hopefully shows also that this is a tiny bit more complex than it looks at first). Best regards David Kalnischkies signature.asc Description: PGP signature
Comparing/Using Conda with Debian
Hello, On an project-internal mailing list the thread "Conda vs Debian" evolved. Sam kindly reminded us to discuss this publicly. So, here you go, issues raised were * interaction with industry-standard non-free software + Intel compilers and libraries + NVidia drivers and libraries * multi-version installations + upstream defines what is stable to them + drive of users to use the very latest versions vs more conservative adoption of library versions by developers * QA and CI and ... * perpetual vs backporting Please don't hold back. The topic of the initial thread asked why Debian packaging is fun. Conda may not be the best possible answer, but let this thread nonetheless enlight ourselves. Steffen
Reklama Twojej firmy na Facebooku
Dzień dobry, skuteczne administrowanie *FanPage na Facebook’u* to nasza specjalność. W związku z tym, chcemy zaproponować Państwu przesłanie więcej informacji w tym zakresie by zwiększyć zysk Państwa firmy oraz ilość fanów. Przesłanie odpowiedzi o treści *TAK*, umożliwi nam kontakt z Państwem. Ponieważ sami prowadzimy biznes, jesteśmy świadomi, że podstawą każdej firmy są klienci. Zadbamy o przypływ nowych klientów dla Państwa firmy. _ Pozdrawiamy Serdecznie, Administrowanie Facebook’iem.
Re: Comparing/Using Conda with Debian
Hi Steffen, Thanks for moving the thread out. Please allow me to repeat some of my points here: On 2019-07-11 10:53, Steffen Möller wrote: > On an project-internal mailing list the thread "Conda vs Debian" > evolved. Sam kindly reminded us to discuss this publicly. So, here you > go, issues raised were > > * interaction with industry-standard non-free software > > + Intel compilers and libraries > > + NVidia drivers and libraries To some extent this overlaps with some of the "difficulties in deep learning framework packaging". Many serious users need the performance improvement brought by the non-free blobs, but we Debian always have trouble dealing with these blobs. We don't have control over them, we became passive once something goes wrong with them. So my personal opinion is not to touch these legally problematic stuff anymore. We do keep providing a solid base system to the world, on top of which business groups can do whatever they want with non-free blobs. If some software upstream doesn't have the intention to be well integrated into distributions, why do we bother packaging them? Why not just leave the work to the business groups such as conda. Apart from the non-free & performance stuff, as a conda user I still have some reasons to use conda instead of python packages provided by Debian: 1. conda doesn't require root permission. This helps non-privileged users alot. 2. conda's python environment management 3. conda is distribution-agnostic. I can retain the same python environment with conda across different machines with different systems. The question is, what can we do to improve Debian, if we see it appropriate?
Debian and our frenemies of containers and userland repos
Hi, Following to Mo Zhou's thread of Conda and Debian, it reminds me that, could Debian reduced into a "proof of concept" as an operating system with collection of apps and things composed of completely free software, as more and more software repositories are moving away from the free software repositories like Debian, and userland repositories and app containers becomes more prominent and easier to access. I feel the fear when I was in a flatpak session in DebConf17. It can be a "solid base" of container images and barebone systems, but the days are numbered as operating systems as free and focused on its mission (like Google COOS, Yocto, Alpine etc.) is evolving steady. Could it be a disaster for us? And more importantly, do users care? Best regards, Yao Wei signature.asc Description: PGP signature
Re: Debian and our frenemies of containers and userland repos
On Thu, 2019-07-11 at 23:25 +0800, Yao Wei wrote: > Hi, > > Following to Mo Zhou's thread of Conda and Debian, it reminds me > that, > could Debian reduced into a "proof of concept" as an operating system > with collection of apps and things composed of completely free > software, > as more and more software repositories are moving away from the free > software repositories like Debian, and userland repositories and app > containers becomes more prominent and easier to access. I feel the > fear > when I was in a flatpak session in DebConf17. > > It can be a "solid base" of container images and barebone systems, > but > the days are numbered as operating systems as free and focused on its > mission (like Google COOS, Yocto, Alpine etc.) is evolving steady. > > Could it be a disaster for us? And more importantly, do users care? > > Best regards, > Yao Wei I think that there will always be some demand for APT-style packages as opposed to containers. I know that I personally am a lot more likely to use software if I can get it from apt-get than if I have to download a Docker image. I have also seen this first-hand from other people. Since we launched our Ubuntu CMake APT repository earlier this year, it has become massively popular. It is regularly getting hundreds of downloads per week, both from people inside our company and from external users. I suspect it is only going to get bigger over time, especially with our next release cycle. I get emails about it almost every day. The demand is there. APT-style repositories aren't going away any time soon. Kyle
Re: git & Debian packaging sprint report
On Wed, 10 Jul 2019 09:10:40 +0100, Sean Whitton wrote: > Main achievement > > > We designed and implemented a system to make it possible for DDs to > upload new versions of packages by simply pushing a specially formatted > git tag to salsa. > > Please see this blog post to learn about how it works: > https://spwhitton.name/blog/entry/tag2upload/ This sounds very exciting, I'm really looking forward to typing `git debpush'! Thank you very much for this work. Cheers, gregor -- .''`. https://info.comodo.priv.at -- Debian Developer https://www.debian.org : :' : OpenPGP fingerprint D1E1 316E 93A7 60A8 104D 85FA BB3A 6801 8649 AA06 `. `' Member VIBE!AT & SPI Inc. -- Supporter Free Software Foundation Europe `- NP: Beatles signature.asc Description: Digital Signature
Re: Bits from the Release Team: ride like the wind, Bullseye!
On Sun, 07 Jul 2019 02:47:00 +0100, Jonathan Wiltshire wrote: > There are too many people who should be thanked for their work on getting us > to > this point to list them all individually, and we would be sure to miss some. > Nevertheless, we would like to particularly thank the installer team, the > buildd and ftp teams, the CD team, the publicity team, the webmasters, the > Release Notes editors, porters and all the bug squashers, NMUers, package > maintainers and translators who have contributed to making buster a great > release of which we should all be proud. You indeed missed someone (for obvious reasons): I'd like to thank the release team for their excellent work! > The release of buster also means the bullseye release cycle is about to begin. > From now on, we will no longer allow binaries uploaded by maintainers to > migrate to testing. This means that you will need to do source-only uploads if > you want them to reach bullseye. That's great news. > Q: I needed to do a binary upload because my upload went to the NEW queue, > do I need to do a new (source-only) upload for it to reach bullseye? > A: Yes. We also suggest going through NEW in experimental instead of > unstable > where possible, to avoid disruption in unstable. But this part not so much. Forcing hundreds of maintainers to do two uploads for a new package seems to me like the wrong solution for the conflicting interests of the ftp team (wants to see binary packages for review in NEW) and the release team (doesn't want to see binary packages in testing not built by buildds). I hope that there will be a better solution for this dilemma in the not too distant future. If throwing away binaries is too problematic, as Niels mentioned, maybe SomeThing™ could build a binary package for the ftp-masters for source-only uploads to NEW. Or people knowing the whole infrastructure better than me have smarter ideas :) Cheers, gregor -- .''`. https://info.comodo.priv.at -- Debian Developer https://www.debian.org : :' : OpenPGP fingerprint D1E1 316E 93A7 60A8 104D 85FA BB3A 6801 8649 AA06 `. `' Member VIBE!AT & SPI Inc. -- Supporter Free Software Foundation Europe `- NP: Beatles signature.asc Description: Digital Signature
Bug#931882: ITP: kopano-webapp-plugin-desktopnotifications -- Kopano WebApp desktopnotifications plugin
Package: wnpp Severity: wishlist Owner: Roel van Meer * Package name: kopano-webapp-plugin-desktopnotifications Version : 2.0.2 Upstream Author : Kopano * URL : https://kopano.com/ https://stash.kopano.io/projects/KWA/repos/desktopnotifications/browse * License : AGPL-3 Programming Lang: PHP, JS Description : Kopano WebApp desktopnotifications plugin This package is a plugin for kopano-webapp, a web interface for the Kopano Collaboration Platform. . This plugin shows notifications of new emails and reminders on the desktop. This package is an additional plugin for kopano-webapp. It will be maintained by Giraffe Maintainers . Kind regards, Roel
Re: Bits from the Release Team: ride like the wind, Bullseye!
On Thu, Jul 11, 2019 at 09:34:07PM +0200, gregor herrmann wrote: > You indeed missed someone (for obvious reasons): I'd like to thank > the release team for their excellent work! +1 > On Sun, 07 Jul 2019 02:47:00 +0100, Jonathan Wiltshire wrote: > > The release of buster also means the bullseye release cycle is about to > > begin. > > From now on, we will no longer allow binaries uploaded by maintainers to > > migrate to testing. This means that you will need to do source-only uploads > > if > > you want them to reach bullseye. > But this part not so much. > > Forcing hundreds of maintainers to do two uploads for a new package > seems to me like the wrong solution for the conflicting interests of > the ftp team (wants to see binary packages for review in NEW) and the > release team (doesn't want to see binary packages in testing not > built by buildds). There's also a third concern: we need a way to bootstrap B-Depend cycles. Such as a self-hosting compiler, cyclical dependencies within an ecosystem, importing a whole new architecture, etc. > I hope that there will be a better solution for this dilemma in the > not too distant future. If throwing away binaries is too problematic, > as Niels mentioned, maybe SomeThing™ could build a binary package for > the ftp-masters for source-only uploads to NEW. Or people knowing the > whole infrastructure better than me have smarter ideas :) The -ports team has an "unreleased" suite that buildds can use both for Deps and B-Deps, and people can use before patches are upstreamed. Something of this kind could be done for binary uploads. Some dude named Ken Thompson had an insightful comment here, but that's the easiest solution for now. Meow! -- ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ According to recent spams, "all my email accounts are owned ⢿⡄⠘⠷⠚⠋ by a hacker". So what's the problem? ⠈⠳⣄
Re: git & Debian packaging sprint report
Hi, Thanks for the report. On Wed, Jul 10, 2019 at 09:10:40AM +0100, Sean Whitton wrote: > Hello, > > Over the weekend, Ian Jackson and I met in Cambridge, U.K. to work on > the design and implementation of tools and processes relating to git & > Debian packaging. > > Main achievement > > > We designed and implemented a system to make it possible for DDs to > upload new versions of packages by simply pushing a specially formatted > git tag to salsa. > > Please see this blog post to learn about how it works: > https://spwhitton.name/blog/entry/tag2upload/ > > While the cloud service part of this system has not yet been deployed, > and so you can't just tag to upload yet, the blog post explains how you > can run the cloud service in an ad-hoc mode on your laptop, and thereby > get a feel for how it works. > > You can also read git-debpush(1) in sid.[1] If the uploads will be done by a service, this means that all of them will be signed by a single key and not by the DD key. Is ftp-master ok with that? signature.asc Description: PGP signature
Detecting (upcoming) problems using automatic tests
Dear fellow developers, I was just thinking that adding deprecation warnings and stuff to software is "nice", but the problem with warnings is that they tend to not break tests. I feel like it would be nice to come up with a standard environment variable to turn warnings into errors, so we can ensure issues are fixed and the warnings are actually useful. For example, we could set such a variable for autopkgtests on unstable, and then see deprecation errors there without breaking testing migration because a thing was deprecated. What do you think? (I'm not subscribed to devel, so you probably want to CC me as I read devel only occasionally via nntp otherwise) -- debian developer - deb.li/jak | jak-linux.org - free software dev ubuntu core developer i speak de, en
Bug#931893: ITP: sphinx-autodoc-typehints -- Type hints support for the Sphinx autodoc extension
Package: wnpp Severity: wishlist Owner: William Grzybowski * Package name: sphinx-autodoc-typehints Version : 1.6.0 Upstream Author : Alex Grönholm * URL : https://github.com/agronholm/sphinx-autodoc-typehints * License : MIT Programming Lang: Python Description : Type hints support for the Sphinx autodoc extension This extension allows you to use Python 3 annotations for documenting acceptable argument types and return value types of functions. This is relevant to build documentation of some python modules. Its currently a dependency for sentry-python. I plan to maintain it myself, or within DPMT team if they allow me.
Work-needing packages report for Jul 12, 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: 1428 (new: 5) Total number of packages offered up for adoption: 156 (new: 0) Total number of packages requested help for: 55 (new: 0) Please refer to https://www.debian.org/devel/wnpp/ for more information. The following packages have been orphaned: blackbox-themes (#931569), orphaned 4 days ago Description: Themes for the Blackbox Windowmanager Installations reported by Popcon: 145 Bug Report URL: https://bugs.debian.org/931569 citadel (#931862), orphaned today Reverse Depends: citadel-suite Installations reported by Popcon: 21 Bug Report URL: https://bugs.debian.org/931862 citadel-client (#931865), orphaned today Description: complete and feature-rich groupware server (command line client) Reverse Depends: citadel-suite Installations reported by Popcon: 17 Bug Report URL: https://bugs.debian.org/931865 libcitadel (#931868), orphaned today Description: Development files for libcitadel4 Reverse Depends: citadel-client citadel-server citadel-webcit libcitadel-dev Installations reported by Popcon: 30 Bug Report URL: https://bugs.debian.org/931868 webcit (#931864), orphaned today Reverse Depends: citadel-suite Installations reported by Popcon: 12 Bug Report URL: https://bugs.debian.org/931864 1423 older packages have been omitted from this listing, see https://www.debian.org/devel/wnpp/orphaned for a complete list. No new packages have been given up for adoption, but a total of 156 packages are awaiting adoption. See https://www.debian.org/devel/wnpp/rfa_bypackage for a complete list. For the following packages help is requested: autopkgtest (#846328), requested 953 days ago Description: automatic as-installed testing for Debian packages Reverse Depends: autodeb-worker debci-worker Installations reported by Popcon: 1197 Bug Report URL: https://bugs.debian.org/846328 balsa (#642906), requested 2846 days ago Description: An e-mail client for GNOME Installations reported by Popcon: 697 Bug Report URL: https://bugs.debian.org/642906 broadcom-sta (#886599), requested 549 days ago (non-free) Description: Broadcom STA Wireless driver (non-free) Installations reported by Popcon: 1809 Bug Report URL: https://bugs.debian.org/886599 cargo (#860116), requested 821 days ago Description: Rust package manager Reverse Depends: cargo-vendor dh-cargo Installations reported by Popcon: 1067 Bug Report URL: https://bugs.debian.org/860116 cyrus-sasl2 (#799864), requested 1387 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 (113 more omitted) Installations reported by Popcon: 196420 Bug Report URL: https://bugs.debian.org/799864 dee (#831388), requested 1091 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: 53589 Bug Report URL: https://bugs.debian.org/831388 developers-reference (#759995), requested 1776 days ago Description: guidelines and information for Debian developers Installations reported by Popcon: 8880 Bug Report URL: https://bugs.debian.org/759995 devscripts (#800413), requested 1381 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 (32 more omitted) Installations reported by Popcon: 12320 Bug Report URL: https://bugs.debian.org/800413 docker.io (#908868), requested 299 days ago Description: Linux container runtime Reverse Depends: golang-docker-dev golang-github-fsouza-go-dockerclient-dev golang-github-google-cadvisor-dev golang-github-samalba-dockerclient-dev kubernetes-node subuser whalebuilder Installations reported by Popcon: 1766 Bug Report URL: https://bugs.debian.org/908868 ed (#886643), requested 549 days ago Description: classic UNIX line editor Reverse Depends: apt-cacher libdebbugs-perl opensmtpd sn Installations reported by Popcon: 17051 Bug Report URL: https://bugs.debian.org/886643 ejabberd (#7
Re: git & Debian packaging sprint report
> "Andrej" == Andrej Shadura writes: Andrej> Hi, Andrej> On Wed, 10 Jul 2019 at 10:10, Sean Whitton wrote: >> Over the weekend, Ian Jackson and I met in Cambridge, U.K. to >> work on the design and implementation of tools and processes >> relating to git & Debian packaging. Andrej> Sean, are you coming to Curitiba? If yes, how about Andrej> organising a BoF on Git packaging workflows? He's not, but if you read the entire report you'd see a link to https://debconf19.debconf.org/talks/68-one-git-to-package-them-all-and-on-the-salsa-find-them/ We'll be starting off early in the week trying to understand and catalog requirements, and I'm sure the fun won't end there!
Re: Detecting (upcoming) problems using automatic tests
[adding jak@ to CC as requested; no need to CC me, however...] Hi Julian, > I was just thinking that adding deprecation warnings and stuff > to software is "nice", but the problem with warnings is that they > tend to not break tests. I'm guessing you have a particular package or use-case in mind that sparked this idea — could you share? That might help make this abstract concept a little more concrete. I'm also assuming that you meant for this to be wider than just GCC so, for example, making -Werror global wouldn't be sufficient as it wouldn't catch, say, warnings from pure-Python packages. > I feel like it would be nice to come up with a standard environment > variable to turn warnings into errors, so we can ensure issues are > fixed and the warnings are actually useful. Hm, although perhaps DEB_BUILD_OPTIONS is the prefered place for this kind of toggle rather than an environment variable? Regards, -- ,''`. : :' : Chris Lamb `. `'` la...@debian.org 🍥 chris-lamb.co.uk `-
Re: Bits from the Release Team: ride like the wind, Bullseye!
On Fri, 12 Jul 2019 at 08:17, Adam Borowski wrote: > On Thu, Jul 11, 2019 at 09:34:07PM +0200, gregor herrmann wrote: > > You indeed missed someone (for obvious reasons): I'd like to thank > > the release team for their excellent work! > > +1 > +lots > > On Sun, 07 Jul 2019 02:47:00 +0100, Jonathan Wiltshire wrote: > > > The release of buster also means the bullseye release cycle is about > to begin. > > > From now on, we will no longer allow binaries uploaded by maintainers > to > > > migrate to testing. This means that you will need to do source-only > uploads if > > > you want them to reach bullseye. > > > But this part not so much. > > > > Forcing hundreds of maintainers to do two uploads for a new package > > seems to me like the wrong solution for the conflicting interests of > > the ftp team (wants to see binary packages for review in NEW) and the > > release team (doesn't want to see binary packages in testing not > > built by buildds). > FWIW in Ubuntu, packages go through NEW as source and then as soon as they build they go back through as binaries. It seems to work OK. > There's also a third concern: we need a way to bootstrap B-Depend cycles. > Such as a self-hosting compiler, cyclical dependencies within an ecosystem, > importing a whole new architecture, etc. > But the ban is only on developer-built binaries in testing. So you can upload with binaries to unstable, then once they are published make a source-only upload, the binaries from which will migrate. Sure it's an extra upload or two but it's not that complicated really. > I hope that there will be a better solution for this dilemma in the > > not too distant future. If throwing away binaries is too problematic, > > as Niels mentioned, maybe SomeThing™ could build a binary package for > > the ftp-masters for source-only uploads to NEW. Or people knowing the > > whole infrastructure better than me have smarter ideas :) > > The -ports team has an "unreleased" suite that buildds can use both for > Deps and B-Deps, and people can use before patches are upstreamed. > Something of this kind could be done for binary uploads. > > Some dude named Ken Thompson had an insightful comment here, but that's > the easiest solution for now. > Well there's no getting away from that. Cheers, mwh
Re: git & Debian packaging sprint report
On July 10, 2019 8:10:40 AM UTC, Sean Whitton wrote: >Hello, > >Over the weekend, Ian Jackson and I met in Cambridge, U.K. to work on >the design and implementation of tools and processes relating to git & >Debian packaging. > >Main achievement > > >We designed and implemented a system to make it possible for DDs to >upload new versions of packages by simply pushing a specially formatted >git tag to salsa. > >Please see this blog post to learn about how it works: >https://spwhitton.name/blog/entry/tag2upload/ > >While the cloud service part of this system has not yet been deployed, >and so you can't just tag to upload yet, the blog post explains how you >can run the cloud service in an ad-hoc mode on your laptop, and thereby >get a feel for how it works. ... Thanks for the detailed explanation. Has there been any analysis of the security implications of this proposed service? If I am understanding the description correctly, the transformation from git tag (which is signed and can be verified) to a source package (which can be signed and verified) will happen on an internet facing server (typically this would happen on a local developer machine) and, unless there is additional magic around key management that isn't described in the blog post, the private key for a key the archive trusts would also be there. It seems to me that there is potential for a significant new attack surface that ought to be carefully assessed before this gets anywhere near wired up to feed into the archive from any kind of 'cloud' service. Scott K
