Re: trimming changelogs
Hi, Le vendredi 20 mars 2020 à 07:44 +0100, Ansgar a écrit : > > We should probably also not ship the same changelog in multiple > packages, especially when one depends on the other. > Switching to per src:package changelogs would cover that. But that will probably mean making dpkg smarter. J.Puydt
Re: trimming changelogs
Hello, Boyuan Yang, le jeu. 19 mars 2020 20:58:57 -0400, a ecrit: > Maybe we can keep changelog of up to 10 entries or till the time of 5 years > ago As a user, I would like to see changelog until at least the previous Debian release, to be able to grep through it for changes when I happend to find that some package has changed some behavior since the upgrade from one release to another, and want to know more about it. Samuel
Re: trimming changelogs
Hi, Adam Borowski writes: > Of files named changelog.*, top offenders are: [ Trimmed list to duplicates ] > 223009 ncurses-bin:changelog.gz > 223009 ncurses-base:changelog.gz > 223009 libtinfo6:changelog.gz > 210621 libc6:changelog.Debian.gz > 210621 libc-bin:changelog.Debian.gz > 145889 libapt-pkg6.0:changelog.gz > 145889 apt:changelog.gz > 145271 passwd:changelog.gz > 145271 login:changelog.gz > 93638 libudev1:changelog.Debian.gz > 93638 libsystemd0:changelog.Debian.gz > 63670 logsave:changelog.Debian.gz > 63670 libss2:changelog.Debian.gz > 63670 libext2fs2:changelog.Debian.gz > 63670 libcom-err2:changelog.Debian.gz > 63670 e2fsprogs:changelog.Debian.gz We should probably also not ship the same changelog in multiple packages, especially when one depends on the other. > Seems like a tempting area to trim... I agree it would be fine to trim changelogs a bit; no real opinion on how much to keep (maybe at most three years or so?). We certainly don't need 20 years of changelog in any binary package by default in my opinion. > On the other hand, changelogs are valuable. Unlike some folks on IRC > I wouldn't want to tightly trim all packages. Unlike minbase or > prio:important, your average 5GB install doesn't care about a few megs > here and there. Thus: do we want to trim manually or globally? Special cases for packages are annoying, so I would just apply the same policy for all packages (by default). Ansgar
Re: trimming changelogs
On Thu, Mar 19, 2020 at 08:58:57PM -0400, Boyuan Yang wrote: > 在 2020-03-20星期五的 00:50 +0100，Adam Borowski写道： > > [trimming changelogs] > > > > On the other hand, changelogs are valuable. Unlike some folks on IRC > > I wouldn't want to tightly trim all packages. Unlike minbase or > > prio:important, your average 5GB install doesn't care about a few megs > > here and there. Thus: do we want to trim manually or globally? > > > > A global trim would require a lot less work. A manual trim would allow > > managing packages: dpkg is everywhere, dpkg-dev is not. libsystemd0 is > > essential, systemd doesn't belong in containers. gcc-9-base is included > > on tiny installs, gcc-9 on dev boxes and buildds with plenty of space. > > Plus, manual trimming would also allow axing old upstream cruft. > > My 2 cents: no matter whether we are trimming for all packages or some key > packages, I'd expect such trimming to be _fully_ automatic, e.g., performed by > a tool of dh_*. Of course, doing this by handcrafted code would be bad. mbiebl just filed #954313 asking for a dh_installchangelogs option. > Manual trimming would be another extra burden for package maintainers. > I'm not sure how Ubuntu implemented this but probably we should be > implementing it at the same location. By "manual trimming" I mean manually enabling it / selecting what to trim. Ubuntu instead does "global trimming", which affects all packages, not just base. I find that somewhat wrong: today, even small ARM boards use a SD card of 16+GB -- and embedded systems are handcrafted anyway. You don't care about minor savings on an the primary (host) system. Reducing minbase matters for containers and similar cases that cram hundreds of Debian installs onto the same box. > Also I'd assume that the source package always contains the full changelog. Aye. > Maybe we can keep changelog of up to 10 entries or till the time of 5 years > ago (I'm just providing a random number; it can be adjusted), whichever is > greater. The exact entries to keep is determined by using SOURCE_DATE_EPOCH as > the current time to maintain package reproducibility. Right -- and if we'd be able to adjust packages to choose how aggressive the trim should be per-binary (dpkg vs dpkg-dev), I'd be happy. Meow! -- ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ in the beginning was the boot and root floppies and they were good. ⢿⡄⠘⠷⠚⠋⠀ -- on #linux-sunxi ⠈⠳⣄
Re: trimming changelogs
Hi,
在 2020-03-20星期五的 00:50 +0100，Adam Borowski写道：
> Hi!
> In the rush for cutting away small bits of minbase, it looks like we forgot
> a big pile of junk: /usr/share/doc/
> [...]
> Seems like a tempting area to trim...
> [...]
> Ubuntu keep only 10 last entries, for _all_ packages.
>
> I consider 10 entries to be too little for a fast moving package ("upload
> early, upload often"), but a release-based ("since oldstable"), time-based
> ("3 years ago") or size-based ("X 4096 filesystem pages after gzipping")
> cut-off would work well.
>
> On the other hand, changelogs are valuable. Unlike some folks on IRC
> I wouldn't want to tightly trim all packages. Unlike minbase or
> prio:important, your average 5GB install doesn't care about a few megs
> here and there. Thus: do we want to trim manually or globally?
>
> A global trim would require a lot less work. A manual trim would allow
> managing packages: dpkg is everywhere, dpkg-dev is not. libsystemd0 is
> essential, systemd doesn't belong in containers. gcc-9-base is included
> on tiny installs, gcc-9 on dev boxes and buildds with plenty of space.
> Plus, manual trimming would also allow axing old upstream cruft.
My 2 cents: no matter whether we are trimming for all packages or some key
packages, I'd expect such trimming to be _fully_ automatic, e.g., performed by
a tool of dh_*. Manual trimming would be another extra burden for package
maintainers. I'm not sure how Ubuntu implemented this but probably we should
be implementing it at the same location.
Also I'd assume that the source package always contains the full changelog.
Maybe we can keep changelog of up to 10 entries or till the time of 5 years
ago (I'm just providing a random number; it can be adjusted), whichever is
greater. The exact entries to keep is determined by using SOURCE_DATE_EPOCH as
the current time to maintain package reproducibility.
--
Thanks,
Boyuan Yang
signature.asc
Description: This is a digitally signed message part
Work-needing packages report for Mar 20, 2020
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: 1226 (new: 0) Total number of packages offered up for adoption: 238 (new: 1) Total number of packages requested help for: 63 (new: 0) Please refer to https://www.debian.org/devel/wnpp/ for more information. No new packages have been orphaned, but a total of 1226 packages are orphaned. See https://www.debian.org/devel/wnpp/orphaned for a complete list. The following packages have been given up for adoption: pixz (#954254), offered today Description: parallel, indexing XZ compressor/decompressor Reverse Depends: pristine-tar Installations reported by Popcon: 1488 Bug Report URL: https://bugs.debian.org/954254 237 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: apache2 (#910917), requested 523 days ago Description: Apache HTTP Server Reverse Depends: apache2 apache2-ssl-dev apache2-suexec-custom apache2-suexec-pristine backuppc courier-webadmin cvsweb debbugs-web dms-wsgi doc-central (138 more omitted) Installations reported by Popcon: 98077 Bug Report URL: https://bugs.debian.org/910917 autopkgtest (#846328), requested 1205 days ago Description: automatic as-installed testing for Debian packages Reverse Depends: debci-worker Installations reported by Popcon: 1170 Bug Report URL: https://bugs.debian.org/846328 balsa (#642906), requested 3098 days ago Description: An e-mail client for GNOME Installations reported by Popcon: 698 Bug Report URL: https://bugs.debian.org/642906 broadcom-sta (#886599), requested 801 days ago (non-free) Description: Broadcom STA Wireless driver (non-free) Installations reported by Popcon: 1752 Bug Report URL: https://bugs.debian.org/886599 cargo (#860116), requested 1073 days ago Description: Rust package manager Reverse Depends: dh-cargo Installations reported by Popcon: 1657 Bug Report URL: https://bugs.debian.org/860116 cyrus-imapd (#921717), requested 405 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: 432 Bug Report URL: https://bugs.debian.org/921717 cyrus-sasl2 (#799864), requested 1639 days ago Description: authentication abstraction library Reverse Depends: 389-ds-base adcli autofs-ldap cyrus-caldav cyrus-clients cyrus-common cyrus-dev cyrus-imapd cyrus-imspd cyrus-murder (78 more omitted) Installations reported by Popcon: 203205 Bug Report URL: https://bugs.debian.org/799864 dee (#831388), requested 1343 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: 35183 Bug Report URL: https://bugs.debian.org/831388 developers-reference (#759995), requested 2028 days ago Description: guidelines and information for Debian developers Installations reported by Popcon: 7115 Bug Report URL: https://bugs.debian.org/759995 devscripts (#800413), requested 1633 days ago Description: scripts to make the life of a Debian Package maintainer easier Reverse Depends: apt-build apt-listdifferences aptfs arriero brz-debian buildd customdeb debci debian-builder debmake (32 more omitted) Installations reported by Popcon: 11913 Bug Report URL: https://bugs.debian.org/800413 docker.io (#908868), requested 551 days ago Description: Linux container runtime Reverse Depends: docker-clean golang-github-containers-buildah-dev golang-github-containers-image-dev golang-github-fsouza-go-dockerclient-dev golang-github-openshift-imagebuilder-dev golang-github-samalba-dockerclient-dev kubernetes-node subuser whalebuilder Installations reported by Popcon: 3209 Bug Report URL: https://bugs.debian.org/908868 ebib (#952810), requested 19 days ago Description: BibTeX database manager for Emacs Installations reported by Popcon: 37 Bug Report URL: https://bugs.debian.org/952810 ejabberd (#767874), requested 1963 days ago Description: distributed, fault-tolerant Jabber/XMPP server written in Erlang Reverse Depends: ejabberd-contrib ejabberd-mod-cron ejabberd-mod-default-contacts ejabberd-mod-defaul
trimming changelogs
Hi!
In the rush for cutting away small bits of minbase, it looks like we forgot
a big pile of junk: /usr/share/doc/
On strict minbase (rather than prio:important which really matters), the
docs take 11MB. And of that, 8MB are files named changelog.* -- which
fails to include eg. bash's:
112K -rw-r--r-- 1 root root 111K Jan 2 2019 CHANGES.gz
8.0K -rw-r--r-- 1 root root 8.0K May 29 2018 COMPAT.gz
4.0K -rw-r--r-- 1 root root 2.9K Feb 17 1999 INTRO.gz
32K -rw-r--r-- 1 root root 30K Nov 13 2018 NEWS.gz
(INTRO.gz is small, but 1999 advertising is of little use)
Of files named changelog.*, top offenders are:
880997 dpkg:changelog.gz
381250 gpgv:changelog.gz
289255 libgnutls30:changelog.gz
223009 ncurses-bin:changelog.gz
223009 ncurses-base:changelog.gz
223009 libtinfo6:changelog.gz
210621 libc6:changelog.Debian.gz
210621 libc-bin:changelog.Debian.gz
202841 dpkg:changelog.Debian.gz
193825 coreutils:changelog.gz
177117 gcc-9-base:changelog.Debian.gz
176608 gcc-10-base:changelog.Debian.gz
164010 findutils:changelog.gz
147656 tar:changelog.gz
145889 libapt-pkg6.0:changelog.gz
145889 apt:changelog.gz
145271 passwd:changelog.gz
145271 login:changelog.gz
142058 grep:changelog.gz
131424 libp11-kit0:changelog.gz
123812 libgcrypt20:changelog.gz
113533 bash:changelog.gz
103492 libnettle7:changelog.gz
100216 libpcre3:changelog.gz
93638 libudev1:changelog.Debian.gz
93638 libsystemd0:changelog.Debian.gz
63709 perl-base:changelog.Debian.gz
63670 logsave:changelog.Debian.gz
63670 libss2:changelog.Debian.gz
63670 libext2fs2:changelog.Debian.gz
63670 libcom-err2:changelog.Debian.gz
63670 e2fsprogs:changelog.Debian.gz
63284 tar:changelog.1.gz
Seems like a tempting area to trim...
Prior art:
sysvinit does:
sed -i -ne '/sysvinit (2.93-8)/q' -e p \
$(rctmp)$(doc)/sysv-rc/changelog.Debian
(I've just bumped the cut-off from 2.86.ds1-47, in 2007)
which also differs per binary package.
Ubuntu keep only 10 last entries, for _all_ packages.
I consider 10 entries to be too little for a fast moving package ("upload
early, upload often"), but a release-based ("since oldstable"), time-based
("3 years ago") or size-based ("X 4096 filesystem pages after gzipping")
cut-off would work well.
On the other hand, changelogs are valuable. Unlike some folks on IRC
I wouldn't want to tightly trim all packages. Unlike minbase or
prio:important, your average 5GB install doesn't care about a few megs
here and there. Thus: do we want to trim manually or globally?
A global trim would require a lot less work. A manual trim would allow
managing packages: dpkg is everywhere, dpkg-dev is not. libsystemd0 is
essential, systemd doesn't belong in containers. gcc-9-base is included
on tiny installs, gcc-9 on dev boxes and buildds with plenty of space.
Plus, manual trimming would also allow axing old upstream cruft.
Thoughts, folks?
Meow!
--
⢀⣴⠾⠻⢶⣦⠀
⣾⠁⢠⠒⠀⣿⡁ in the beginning was the boot and root floppies and they were good.
⢿⡄⠘⠷⠚⠋⠀ -- on #linux-sunxi
⠈⠳⣄
Re: RFC: Replacing vim-tiny with nano in essential packages
"Theodore Y. Ts'o" writes: > I've always considered /bin/ed the most basic system administration > tool, since it doesn't require a working terminal or termcap entry. > It works even if you are using an ASR-33 teletype. :-) > > And at least for me, I find /bin/ed much more user friendly than vi, > since it doesn't have as modal of a UI as vi. (Vi has 3 modes, ed has > only 2.) > > /bin/ed is also *much* smaller than even busybox. And of course, it *is* the standard text editor. https://www.gnu.org/fun/jokes/ed-msg.en.html Bjørn
Bug#954301: ITP: python-rich -- library for rendering rich text and beautiful formatting to the terminal
Package: wnpp Severity: wishlist Owner: Sandro Tosi * Package name: python-rich Version : 0.8.0 Upstream Author : Will McGugan * URL : https://github.com/willmcgugan/rich * License : MIT Programming Lang: Python Description : library for rendering rich text and beautiful formatting to the terminal The Rich API makes it easy to add colorful text (up to 16.7 million colors) with styles (bold, italic, underline etc.) to your script or application. Rich can also render pretty tables, progress bars, markdown, syntax highlighted source code, and tracebacks -- out of the box.
Re: RFC: Replacing vim-tiny with nano in essential packages
try ssh into a windows machine.
the termcaps are all manner of fun.
On Thu, Mar 19, 2020 at 7:23 AM Adam Borowski wrote:
> On Thu, Mar 19, 2020 at 11:34:10AM +0500, Lev Lamberov wrote:
> > Ср 18 мар 2020 @ 18:52 Adam Borowski :
> >
> > > Alas, our ed is basically:
> > > #!/bin/sh
> > > while read x;do echo '?';done
> >
> > That's not true. The ed package in the Debian archive is full GNU ed.
>
> I'm not talking about functionality under the hood, I'm bad-mouthing the
> user-friendliness.
>
> I used to be an ed user for a decade (I've coded on a game that offered
> only
> a line-based interface), but that was Beattie ed which was _massively_ more
> comfortable to use interactively than GNU ed (and probably way less
> powerful). It was enough to bother with file transfers only for big edits.
>
> But that was a special case. Today, even on a bad serial link, all you
> need
> is a visual editor that does _not_ obey termcap/terminfo. In my
> experience,
> the 99% cause of breakage is:
> * weird ancient Unices: bad termcappage
> * Linux/BSD: wrong terminal size ("setterm --resize")
> (ignoring termcap works because last non-vt100ish terminals were made ~40
> years ago)
>
> Thus, I can't think of a scenario where ed would be preferred over a visual
> editor. If such scenario exists, it's too obscure for the default small
> system.
>
>
> Meow!
> --
> ⢀⣴⠾⠻⢶⣦⠀
> ⣾⠁⢠⠒⠀⣿⡁ in the beginning was the boot and root floppies and they were good.
> ⢿⡄⠘⠷⠚⠋⠀ -- on #linux-sunxi
> ⠈⠳⣄
>
>
Bug#954286: RFP: prometheus-redis-exporter -- Prometheus exporter for Redis metrics
Package: wnpp Severity: wishlist Tags: patch * Package name: prometheus-redis-exporter Version : 1.4.0 Upstream Author : Oliver * URL : https://github.com/oliver006/redis_exporter * License : MIT Programming Lang: Go Description : Prometheus exporter for Redis metrics Prometheus exporter for Redis metrics. Supports Redis 2.x, 3.x, 4.x, and 5.x. Attached a tested and working packaging (based on the one from the prometheus-node-exporter, where Tina agreed to the relicensing to match upstream), where only the Uploaders, and ITP bug need to be filled, and the packaging imported into git. Thanks, Guillem prometheus-redis-exporter_1.4.0-1.debian.tar.xz Description: application/xz
Re: FTP Team -- call for volunteers
On Thursday, March 19, 2020 10:31:55 AM EDT Luca Filipozzi wrote: > On Thu, Mar 19, 2020 at 11:42:39AM +, Neil McGovern wrote: > > On Wed, Mar 18, 2020 at 12:25:24PM -0400, Theodore Y. Ts'o wrote: > > > > 2) We would be very limited in what checks we could actually do on new > > > > packages. If we look too closely at packages, we stop being a > > > > distributor, and start being a publisher. I'm not sure that we want to > > > > move towards just being a distribution platform, rather than actually > > > > doing QA checks. > > > > > > I'm confused. As near as I can tell, we already are looking super > > > closely at new packages. > > > > Yes, and there's the problem. To move from a situation where we try and > > say "we're a distributor, not a publisher", then we would need to stop > > doing some of those checks, or at least work out a way of automating > > them. > > [snip very useful explanation - thanks for that, Neil!] > > > So, to ease the burden on ftp-masters by trying to say that > > > > > the responsibility of the right to redistribute of the uploaded > > > software be moved on the uploader instead > > > > as suggested by Alexis, means we need to be very careful about /not/ > > looking too closely at what we put out. > > Isn't part of Debian's charm the quality that we attempt to bring to the > packages that we publish? > > How does our coorindation for things like py2->py3 impact our position > as publisher vs distributor? I think it's an essential element of the value proposition that Debian brings to the table. We're an integrator that is working to deliver a coherent set of capabilities in a release. If we aren't going to do that, we may as well dump all the (for example) Python packages and tell people to use pypi (CPAN, pick your language specific publishing mechanism). Scott K signature.asc Description: This is a digitally signed message part.
Re: FTP Team -- call for volunteers
On Thu, Mar 19, 2020 at 11:42:39AM +, Neil McGovern wrote: > On Wed, Mar 18, 2020 at 12:25:24PM -0400, Theodore Y. Ts'o wrote: > > > 2) We would be very limited in what checks we could actually do on new > > > packages. If we look too closely at packages, we stop being a > > > distributor, and start being a publisher. I'm not sure that we want to > > > move towards just being a distribution platform, rather than actually > > > doing QA checks. > > > > I'm confused. As near as I can tell, we already are looking super > > closely at new packages. > > > > Yes, and there's the problem. To move from a situation where we try and > say "we're a distributor, not a publisher", then we would need to stop > doing some of those checks, or at least work out a way of automating > them. [snip very useful explanation - thanks for that, Neil!] > So, to ease the burden on ftp-masters by trying to say that > > the responsibility of the right to redistribute of the uploaded > > software be moved on the uploader instead > as suggested by Alexis, means we need to be very careful about /not/ > looking too closely at what we put out. Isn't part of Debian's charm the quality that we attempt to bring to the packages that we publish? How does our coorindation for things like py2->py3 impact our position as publisher vs distributor? -- Luca Filipozzi
Re: Python related autopkgtest anti-pattern
On Thu, 19 Mar 2020 at 09:27:35 -0400, Scott Kitterman wrote: > The fact that these tests are failing right now makes them relatively easy to > find, but even if they weren't failing, I still think testing against > installed > versions is wrong. Tests should have an intentional scope, not act of > whatever happens to be present. Yes, I don't disagree with that. > I think this is true even for applications that will only ever actually be > used with the default python3. As an example, in xml2rfc I use the pattern > I'm suggesting here so that when a new python3 version is added as supported, > it gets tested right away and I know if there's a problem long before it > becomes the default. That does seem like a good thing to test, at least in the cases where it's straightforward. One down side of having a test-dependency on python3-all is that if you (or your packaging toolchain) forgot to add the required python3 dependency for a python3 script, your autopkgtest won't catch that. (But Lintian hopefully will.) smcv
Re: Python related autopkgtest anti-pattern
On Thursday, March 19, 2020 6:40:00 AM EDT Simon McVittie wrote:
> On Wed, 18 Mar 2020 at 18:32:22 -0400, Scott Kitterman wrote:
> > We want the tests to run against all versions, but the way to do that is
> > to
> > have your test depend on python3-all (to make sure that all supported
> > versions are installed) and then use the -s flag for py3versions vice -i.
> > So (in one common pattern) this:
> >
> > for py in $(py3versions -i); do
> >
> > changes to:
> >
> > for py in $(py3versions -s); do
>
> I think part of the problem here is that py3versions -i treats
> python3.*-minimal as being "installed". Could it perhaps not do
> that? It is true that they are installed in the sense that there is a
> /usr/bin/python3.*, but it isn't a complete, functional version of Python
> (most of the standard library is missing), so many tests are going to
> fail in it.
That's been the behavior since I ported pyversions to python3 about a decade
ago and it is the way pyversions worked long before that. I agree it's not
extraordinarily useful for the reasons you point out, but I don't think there
is a lot of benefit in changing it at this point. Personally, I'm not
convinced the minimal binaries have a lot of value. I think that's a better
place to look (not that I expect that to change either).
> Normally, python3.*-minimal would be installed if and only if python3.*
> is, but the qemu backend for the autopkgtest framework requires either
> python3-minimal or python-minimal installed in the VM (to run a small
> Python program to transfer data between the container and the host), so
> the autopkgtest setup script installs python3-minimal, and autopkgtest
> containers will typically have python3-minimal installed (even those
> that are nothing to do with the qemu backend). When testing has an older
> default version of python than unstable, for example 3.7 and 3.8 right
> now, that will result in python3.7-minimal remaining installed after
> python3{,-minimal} gets upgraded to 3.8.
>
> Perhaps autopkgtest should be using python3 instead of python3-minimal,
> although that would make it impossible for an autopkgtest to detect a
> missing dependency on python3.
I think that's solving the wrong problem in any case.
The fact that these tests are failing right now makes them relatively easy to
find, but even if they weren't failing, I still think testing against installed
versions is wrong. Tests should have an intentional scope, not act of
whatever happens to be present. For python related packages that means
testing against all supported interpreter versions.
This is easily and reliably achieved by using py3versions -s with python3-all.
I think this is true even for applications that will only ever actually be
used with the default python3. As an example, in xml2rfc I use the pattern
I'm suggesting here so that when a new python3 version is added as supported,
it gets tested right away and I know if there's a problem long before it
becomes the default.
Scott K
signature.asc
Description: This is a digitally signed message part.
Bug#9542654: ITP: grok-jpeg2000 -- Grok is an implementation of Part 1 of the JPEG 2000 standard. It aims for speed and stability.
Package: wnpp Severity: wishlist Owner: Aaron Boxer * Package name: grok-jpeg2000 Version : 5.0.0 Upstream Author : Aaron Boxer * URL : https://github.com/GrokImageCompression/grok * License : AGPL Programming Lang: C++ Description : Grok is an implementation of Part 1 of the JPEG 2000 standard. It aims for speed and stability. Grok is one of only two actively developed open source implementations of the JPEG 2000 standard, the other being OpenJPEG. Grok performance is equal to or greater than OpenJPEG, and it also provides more features such as: 1. end to end support of ICC colour profiles 2. support for meta-data such as IPTC, XML and XMP 3. support for new Part 15 of the standard, which promises 5 to 10 times decoding speedup I have been maintaining this library since 2016, and I will maintain the debian package. I am looing for a sponsor to submit the package. Thanks! Aaron
ITP: grok-jpeg2000 -- Grok is an implementation of Part 1 of the JPEG 2000 standard. It aims for speed and stability.
Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: Aaron Boxer To: Debian Bug Tracking System Subject: ITP: grok-jpeg2000 -- Grok is an implementation of Part 1 of the JPEG 2000 standard. It aims for speed and stability. The code is licensed under the AGPL, and the project can be found at https://github.com/GrokImageCompression/grok. Maintainer: boxe...@gmail.com Message-ID: <158462242335.10948.12413586303176443468.reportbug@prospero> X-Mailer: reportbug 7.5.2ubuntu1 Date: Thu, 19 Mar 2020 08:53:43 -0400 X-Debbugs-Cc: debian-devel@lists.debian.org Package: wnpp Severity: wishlist Owner: Aaron Boxer * Package name: grok-jpeg2000 Version : 5.0.0 Upstream Author : Aaron Boxer * URL : https://github.com/GrokImageCompression/grok * License : AGPL Programming Lang: C++ Description : Grok is an implementation of Part 1 of the JPEG 2000 standard. It aims for speed and stability. Grok is one of only two actively developed open source implementations of the JPEG 2000 standard, the other being OpenJPEG. Grok performance is equal to or greater than OpenJPEG, and it also provides more features such as: 1. end to end support of ICC colour profiles 2. support for meta-data such as IPTC, XML and XMP 3. support for new Part 15 of the standard, which promises 5 to 10 times decoding speedup I have been maintaining this library since 2016, and I will maintain the debian package. I am looing for a sponsor to submit the package. Thanks! Aaron
Re: FTP Team -- call for volunteers
On Wed, Mar 18, 2020 at 12:25:24PM -0400, Theodore Y. Ts'o wrote: > > 2) We would be very limited in what checks we could actually do on new > > packages. If we look too closely at packages, we stop being a > > distributor, and start being a publisher. I'm not sure that we want to > > move towards just being a distribution platform, rather than actually > > doing QA checks. > > I'm confused. As near as I can tell, we already are looking super > closely at new packages. > Yes, and there's the problem. To move from a situation where we try and say "we're a distributor, not a publisher", then we would need to stop doing some of those checks, or at least work out a way of automating them. Apologies if the below is stuff you already know, but it may be useful for others. Please also note, this is an oversimplification of the way that this all works. There are two models of getting software from third parties into the hands of users - one is to be a "publisher", and one is to be a "distributor". Both are ways of trying to reduce the risk of putting on the web some bad software (as in, trademark infringing, copyright infringing etc). In the "publishing" model, you accept some software from a third party. You then run various checks on it, making sure it has a good licence, it complies with trademark and copyright law, and then we publish it. This is the way that Debian works at the moment. In the "distribution" model, you accept some software from a third party, and put it on the web. You don't look at it closely, but rely on your terms of service which says that the initial uploader is responsible for everything they upload, and making sure it is distributable etc. This is the way that sals/github/google play store etc work. To relieve the work on ftpmasters, some people are suggesting we move from the former to the latter. Now, imagine you have a law suit where Debian has shipped some proprietary code to millions of users. The upstream for this isn't happy. They come to Debian and complain. Debian says "oh, but we're just a distributor. The liability lies with the person who uploaded it". Unfortunately, we're doing checks on the package. Upstream can then claim that becasue we're looking at and approving packages, we're not just a platform who distributes software, we're actively publishing it by having editorial control over what gets published or not. So, to ease the burden on ftp-masters by trying to say that > the responsibility of the right to redistribute of the uploaded > software be moved on the uploader instead as suggested by Alexis, means we need to be very careful about /not/ looking too closely at what we put out. Sorry for the long mail, but hoepfully this clarifies. Neil -- signature.asc Description: PGP signature
Re: RFC: Replacing vim-tiny with nano in essential packages
On Thu, Mar 19, 2020 at 11:34:10AM +0500, Lev Lamberov wrote:
> Ср 18 мар 2020 @ 18:52 Adam Borowski :
>
> > Alas, our ed is basically:
> > #!/bin/sh
> > while read x;do echo '?';done
>
> That's not true. The ed package in the Debian archive is full GNU ed.
I'm not talking about functionality under the hood, I'm bad-mouthing the
user-friendliness.
I used to be an ed user for a decade (I've coded on a game that offered only
a line-based interface), but that was Beattie ed which was _massively_ more
comfortable to use interactively than GNU ed (and probably way less
powerful). It was enough to bother with file transfers only for big edits.
But that was a special case. Today, even on a bad serial link, all you need
is a visual editor that does _not_ obey termcap/terminfo. In my experience,
the 99% cause of breakage is:
* weird ancient Unices: bad termcappage
* Linux/BSD: wrong terminal size ("setterm --resize")
(ignoring termcap works because last non-vt100ish terminals were made ~40
years ago)
Thus, I can't think of a scenario where ed would be preferred over a visual
editor. If such scenario exists, it's too obscure for the default small
system.
Meow!
--
⢀⣴⠾⠻⢶⣦⠀
⣾⠁⢠⠒⠀⣿⡁ in the beginning was the boot and root floppies and they were good.
⢿⡄⠘⠷⠚⠋⠀ -- on #linux-sunxi
⠈⠳⣄
Re: Python related autopkgtest anti-pattern
On Wed, 18 Mar 2020 at 18:32:22 -0400, Scott Kitterman wrote:
> We want the tests to run against all versions, but the way to do that is to
> have your test depend on python3-all (to make sure that all supported
> versions
> are installed) and then use the -s flag for py3versions vice -i. So (in one
> common pattern) this:
>
> for py in $(py3versions -i); do
>
> changes to:
>
> for py in $(py3versions -s); do
I think part of the problem here is that py3versions -i treats
python3.*-minimal as being "installed". Could it perhaps not do
that? It is true that they are installed in the sense that there is a
/usr/bin/python3.*, but it isn't a complete, functional version of Python
(most of the standard library is missing), so many tests are going to
fail in it.
Normally, python3.*-minimal would be installed if and only if python3.*
is, but the qemu backend for the autopkgtest framework requires either
python3-minimal or python-minimal installed in the VM (to run a small
Python program to transfer data between the container and the host), so
the autopkgtest setup script installs python3-minimal, and autopkgtest
containers will typically have python3-minimal installed (even those
that are nothing to do with the qemu backend). When testing has an older
default version of python than unstable, for example 3.7 and 3.8 right
now, that will result in python3.7-minimal remaining installed after
python3{,-minimal} gets upgraded to 3.8.
Perhaps autopkgtest should be using python3 instead of python3-minimal,
although that would make it impossible for an autopkgtest to detect a
missing dependency on python3.
smcv
Bug#954251: ITP: node-rollup-plugin-terser -- Rollup plugin to minify generated es bundle
Package: wnpp Severity: wishlist Owner: Pirate Praveen X-Debbugs-CC: debian-devel@lists.debian.org * Package name : node-rollup-plugin-terser Version : 5.3.0 Upstream Author : Bogdan Chadkin * URL : https://github.com/TrySound/rollup-plugin-terser * License : Expat Programming Lang: JavaScript Description : Rollup plugin to minify generated es bundle This plugin for rollup uses terser to minify generated bundle and supports ES6. . Node.js is an event-based server-side JavaScript engine. Many d3 sub-modules need this as build dependency. It was waiting for babel 7 and jest.
Re: Python related autopkgtest anti-pattern
Hi all On 18-03-2020 23:32, Scott Kitterman wrote: > I'm currently reviewing some of the autopkgtest regressions that are > currently > blocking python3-defaults with python3.8 as the default python3 from > migrating. Thanks Scott for helping here (all help is welcome). I thought it might be useful to share the link to the current set: https://qa.debian.org/excuses.php?package=python3-defaults Paul signature.asc Description: OpenPGP digital signature
