Bug#1077569: ITP: golang-github-containerd-platforms -- Go package for handling platform type
Package: wnpp Severity: wishlist Owner: Shengjing Zhu X-Debbugs-CC: debian-devel@lists.debian.org, debian...@lists.debian.org * Package name: golang-github-containerd-platforms Version : 0.2.1-1 Upstream Author : containerd * URL : https://github.com/containerd/platforms * License : Apache-2.0 Programming Lang: Go Description : Go package for handling platform type Dependency for containerd. -- Shengjing Zhu
Re: Request for feedback on draft: DEP-18: Enable true open collaboration on all Debian packages
On Sat, Aug 3, 2024 at 2:26 PM Jonas Smedegaard wrote: > > My problem with DEP-18 is that people who have zero problem with using > git and are also not fundamentally against using salsa, but have > reservations surrounding *which parts* of salsa to use and the > consequences for related already used tooling. > > I am also not against being welcoming to newcomers, but I am concerned > if the focus on tose unreasonably reshapes the tooling for all of us. > > Essentially, my concern is that DEP-18 reduces a spectrum of options to > "either you are for or against true collaboration". > > Leaning more on Gitlab is not the "true" choice, but the pragmatic one, > because yes, we have invested in it, and some parts of it might be made > to better use for use. > > I imagine that some in the silent crowd hesitate to chime in due to that > lumping together the use of git and the use of Gitlab into an > all-or-nothing choice. I think you intended that reduction, for the > purpose of simplifying the conversation. I don't think that > simplification is helpfull, however. +1 I also feel uncomfortable with this proposal that pushes the use of Gitlab in the name of true collaboration. -- Shengjing Zhu
Bug#924095: ITP: golang-github-containernetworking-cni -- Container Network Interface - networking for Linux containers
Package: wnpp Severity: wishlist Owner: Shengjing Zhu * Package name: golang-github-containernetworking-cni Version : 0.6.0-1 Upstream Author : CNI * URL : https://github.com/containernetworking/cni * License : Apache-2.0 Programming Lang: Go Description : Container Network Interface - networking for Linux containers CNI consists of a specification and libraries for writing plugins to configure network interfaces in Linux containers, along with a number of supported plugins. CNI concerns itself only with network connectivity of containers and removing allocated resources when the container is deleted. Because of this focus, CNI has a wide range of support and the specification is simple to implement. This is a dependency of golang-github-containerd-go-cni signature.asc Description: PGP signature
Bug#924098: ITP: golang-github-containerd-go-cni -- generic CNI library to provide APIs for CNI plugin interactions
Package: wnpp Severity: wishlist Owner: Shengjing Zhu * Package name: golang-github-containerd-go-cni Version : 0.0~git20190226.0683513-1 Upstream Author : containerd * URL : https://github.com/containerd/go-cni * License : Apache-2.0 Programming Lang: Go Description : generic CNI library to provide APIs for CNI plugin interactions The library provides APIs to: . * Load CNI network config from different sources * Setup networks for container namespace * Remove networks from container namespace * Query status of CNI network plugin initialization . go-cni aims to support plugins that implement Container Network Interface This is a dependency of containerd. signature.asc Description: PGP signature
Re: Bug#924270: O: keepassx -- Cross Platform Password Manager
Hi, On Mon, Mar 11, 2019 at 3:15 AM Reinhard Tartler wrote: > > Package: wnpp > Severity: normal > > Keepassx is a graphical password manager, using the Qt4 toolkit. I'm no > longer using this package and have personally switched to > 'password-store'. Unfortunately, I've also failed to get a response > from upstream from > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=920616 - which > recommends to replace keepassx with keepassxc, a community fork, > possibly because of unresponsive upstream. > > I am undecided whether or not this package should be included in Debian > 10 (aka buster). It clearly is useful to many people, but its long-term > maintenance is unclear. > > I'd encourage people interested in picking up this package to coordinate > with Julian Klode (CC'ed), the Debian keepassxc maintainer. > I'm also long-time user of keepassx. I checked the upstream. In surprise, I found the master version has switched to Qt-5. And the upstream author is Felix Geyer, who is DD as well. Felix, could you have some inputs here? In person, I hope keepassx is in buster. I can help uploading the master version(with Qt-5) if Qt-4 is really needed to be removed from buster. However I'm unsure if RT is fine with this big change(I assume it's not ok). -- Shengjing Zhu
Re: Debian vs Linux namespaces
Hi, On Sat, Mar 23, 2019 at 8:41 PM Harald Dunkel wrote: > > Hi folks, > > AFAICS there are several packages that appear to be unaware of / > do not care about containers, e.g. opensmtpd, bind9, apt-cacher-ng, > probably everything using pidof or pidofproc from /lib/lsb/init-\ > functions). > > I noticed that containerization and Linux namespaces are not number > one priority for Debian, but do you think this could be addressed > for Buster? Its pretty annoying if you try to maintain the Debian host > system, and a LXC container is affected instead. > > > Thanx in advance > > Harri > > https://bugs.debian.org/888569 > https://bugs.debian.org/888743 > https://bugs.debian.org/858837 > https://bugs.debian.org/924551 > If I read these bugs correctly, all are the same thing and it's the bug in lsb. And the straightforward fix mentioned in #888743 and #858837 is to use `pidof -c` instead of `pidof` in pidofproc function provided by lsb-base package. I think there's no harm for this patch. -- Shengjing Zhu
Re: Debian vs Linux namespaces, NMU lsb-base
On Sun, Mar 24, 2019 at 4:42 PM Geert Stappers wrote:
>
> On Sat, Mar 23, 2019 at 09:49:09PM +0800, Shengjing Zhu wrote:
> > On Sat, Mar 23, 2019 at 8:41 PM Harald Dunkel wrote:
> > >
> > > Hi folks,
> > >
> > > AFAICS there are several packages that appear to be unaware of /
> > > do not care about containers, e.g. opensmtpd, bind9, apt-cacher-ng,
> > > probably everything using pidof or pidofproc from /lib/lsb/init-\
> > > functions).
> > >
> > > I noticed that containerization and Linux namespaces are not number
> > > one priority for Debian, but do you think this could be addressed
> > > for Buster? Its pretty annoying if you try to maintain the Debian host
> > > system, and a LXC container is affected instead.
> > >
> > >
> > > Thanx in advance
> > >
> > > Harri
> > >
> > > https://bugs.debian.org/888569
> sysv startup script stumbles over smtpd running in a LXC container
>
> > > https://bugs.debian.org/888743
> pidofproc returns PIDs in foreign chroots and containers
>
> > > https://bugs.debian.org/858837
> lsb-base: pidofproc should limit itself to processes in host system if
> running on an LXC host
>
> > > https://bugs.debian.org/924551
> startup script affects bind running inside a container
>
>
> > If I read these bugs correctly, all are the same thing and it's the bug in
> > lsb.
> > And the straightforward fix mentioned in #888743 and #858837 is to use
> > `pidof -c` instead of `pidof` in pidofproc function provided by
> > lsb-base package.
> >
> > I think there's no harm for this patch.
>
> Quoting manual page `pidof`
>
> | -c Only return process PIDs that are running with the same
> | root directory. This option is ignored for non-root
> | users, as they will be unable to check the current
> | root directory of processes they do not own.
>
>
> What would be the harm to the Buster release
> if lsb-base got NMU
> with
> https://bugs.debian.org/cgi-bin/bugreport.cgi?att=1;bug=888743;filename=init-functions.diff;msg=37
> ?
>
Just checked the contents in initscripts-9.49.46-1.el7.x86_64.rpm
```
# Output PIDs of matching processes, found using pidof
__pids_pidof() {
pidof -c -m -o $$ -o $PPID -o %PPID -x "$1" || \
pidof -c -m -o $$ -o $PPID -o %PPID -x "${1##*/}"
}
```
They use -c since 2005,
https://github.com/fedora-sysv/initscripts/commit/2b4f68e
--
Shengjing Zhu
Bug#926499: ITP: ccls -- C/C++/ObjC language server
Package: wnpp Severity: wishlist Owner: Shengjing Zhu -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 * Package name: ccls Version : 0.20190314 Upstream Author : Fangrui Song * URL : https://github.com/MaskRay/ccls/ * License : Apache-2.0 Programming Lang: C++ Description : C/C++/ObjC language server This originates from cquery, and supports: . * code completion (with both signature help and snippets) * definition/references, and other cross references * cross reference extensions: $ccls/call $ccls/inheritance $ccls/member $ccls/vars ... * formatting * hierarchies: call (caller/callee) hierarchy, inheritance (base/derived) hierarchy, member hierarchy * symbol rename * document symbols and approximate search of workspace symbol * hover information * diagnostics and code actions (clang FixIts) * semantic highlighting and preprocessor skipped regions * semantic navigation: $ccls/navigate -BEGIN PGP SIGNATURE- iQFEBAEBCgAuFiEE85F2DZP0aJKsSKyHONAPABi+PjUFAlyoPOQQHHpoc2pAZGVi aWFuLm9yZwAKCRA40A8AGL4+Na3JB/9CAzBG28G3VWH3maO7tJaizrZfz5+p1uzc yzflrp+iEDHymp2z4PhNGSnAXPMY1QkYG5+TrKbSHmisFhbfs3REpDTX3e1cJU9+ kCt1WysG4GMf4lN/6mHlfi4FuHnjj9BVOSmNbOEcxnPf9B5U2wYBo6xV/wFjzL6K /OCV4z37rPzfZrKw5SKOjHUBDqoY8WRBzZx971D2Dj1zSwPM6PxJb5TdrgZII/Oa sfuSeIsC64pXOotUIPUifmtSpmn0n4g6WpyGMuapkDlFe+eIUKzNivALi77WsdPG mcPp0/FaHarADV7sS6HIpB2BbNV8AbhdSDt976tBic/do5g8fq3b =ROSq -END PGP SIGNATURE-
Re: is Wayland/Weston mature enough to be the default desktop choice in Buster?
As a KDE user, I don't have much knowledge about GNOME. But I remember at the Chinese user support channel, many people have problems with the default input method (fcitx) and GNOME. The answer is usually to ask them to switch to GNOME on Xorg. Someone may argue that ibus(another input method) is ready for Wayland, but fcitx is far better than ibus (for Simplified Chinese), except it's not ready for Wayland. This user case may be not enough to change the default choice of GNOME, but I think this should at least be in release notes. // send from my mobile device Jonathan Dowland 于 2019年4月5日周五 23:12写道： > I was surprised to learn — by way of synaptic being autoremoved — that > the default desktop in Buster will be GNOME/Wayland. I personally do not > think that Wayland is a sensible choice for the default *yet*; and if > the consequence is that bugs for software that do not work properly with > Wayland have their severity inflated such that they are autoremoved (and > thus potentially removed entirely from Buster), a decision that — in > isolation — makes sense to me; although Synaptic is quite a high profile > package within Debian for this to happen. > > I think the default should be reconsidered. > > -- > > ⢀⣴⠾⠻⢶⣦⠀ > ⣾⠁⢠⠒⠀⣿⡁ Jonathan Dowland > ⢿⡄⠘⠷⠚⠋⠀ https://jmtd.net > ⠈⠳⣄ Please do not CC me, I am subscribed to the list. > >
Re: [Idea] Debian User Repository? (Not simply mimicing AUR)
On Sun, Apr 7, 2019 at 9:26 PM Mo Zhou wrote: > > Hi folks, > > The absense of a centralized, informal Debian package repository where > trusted users could upload their own packaging scripts has been > long-forgotten. As an inevitable result, many user packaging scripts > exist in the wild, scattered like stars in the sky, with varied > packaging quality. Their existence reflects our users' demand, > especially the experienced ones', that has not been satisfied by the > Debian archive. Such idea about informal packaging repository has been > demonstrated successful by the Archlinux User Repository (AUR). Hence, > it should be valuable to think about it for Debian. > > Assume that Debian has an informal packaging repository similar to AUR, > which distrbutes packaging scripts only and requires to be built > locally. According to my observation and experience, such a repository: > > 1. Allows packaging in some compromised manner to exist, which means > they dont fully comply with DFSG or Policy. This makes great sense for > several kinds of packages: > > (1) Packages that are extremely hard to made compliant to Policy. For > example, bazel the build system of TensorFlow and other Google products > - No Debian Developer can make it meet the Policy's requirement without > great sacrifice. The outcome doesn't worth the waste in time and energy. > > (2) Dirty but useful non-free blobs, such as nvidia's cuDNN (CUDA Deep > Neural Network) library, which dominates the field of high performance > neural network training and inference. I really hate reading NVIDIA's > non-free legal texts, and in such repository we can avoid reading the > license and just get the scutwork done and make users happy. > > (3) Data with obscure licensing. In this repository we can feel free to > package pre-trained neural networks or training data without carefully > examing the licensing. > > (4) Packages with dirty hacks, or targeted on testing the water. This > makes sense for packages that doesn't worth the effort to make it fully > compliant with Debian's quality requirement and some user just wants it. > > (5) Packages that utilizes SIMD instructions heavily. Such package is > very easy to package in such repo. (So this Proposal actually suppresses > and replaces my SIMDebian project). > > 2. Allows us to offload some low-popcon, or QA-questionable packages > from the archive. Debian's archive size is continuously increasing, but > the number of Debian Developers has been staying around 1000 for many > many years. Saturation will definitely happen in the future if we do > nothing to change - or saturation has already happended. An Archlinux > Developer's saturation point may be several thousand (See Felix Yan, an > Arch Dev), but a Debian Developer often saturate at, maybe 30~100? > Handing over some workload to the user community is not a bad thing, > especially for the cold packages. > > 3. Allows us to accept potential contributors friendly, and possibly > form a new user community. The high quality standard of Debian may scare > some potential contributors away. In the informal packaging area, it's > easier for people to contribute. Look at AUR and Archlinux Trusted Users > as example. Of course, we can promote high quality creations from users > into debian archive. > > Just a few of my naive thoughts. If this idea came true, I'll > denfinitely be able to continue with TensorFlow and PyTorch packaging, > at an significantly lower cost. I'm also happy to throw some of my > low-popcon packages to this area, so I can focus on more valuable ones. > This idea really excites me. Can we implement it? > Why not just start this as a personal project? And prove it works. -- Shengjing Zhu
Re: PPAs (Re: [Idea] Debian User Repository? (Not simply mimicing AUR))
> from PPA (source+binary-based). If people just want a PPA which supports Debian, please just take a look at OBS[1]. I've seen many upstreams provide packages with OBS, and most distributions are supported. Not only deb, but also rpm, from Debian/Ubuntu to OpenSuse/Fedora, and even Archlinux, in a uniform way. [1] https://build.opensuse.org/ -- Shengjing Zhu
Re: Introducting Debian Trends: historical graphs about Debian packaging practices, and "packages smells"
On Sat, Apr 13, 2019 at 4:21 PM Lucas Nussbaum wrote: > > TL;DR: see https://trends.debian.net and > https://trends.debian.net/#smells > These graphs look ambiguous... Shouldn't the x-axis be year? -- Shengjing Zhu
Re: Golang >= 1.12 in Buster?
On Sat, Apr 13, 2019 at 8:12 PM Toni Mueller wrote:
>
>
> Hello,
>
> I just figured that Buster is, from the current POV, going to ship with
> Golang 1.11. While I am new to Go, I figured that we should probably
> have a newer version of Golang in Buster, as they are now doing
> versioned dependencies, but only starting with 1.12 or 1.13 (not quite
> sure about the difference here). This seems to be rapidly adopted by
> projects out there, so having only older versions of Golang is becoming
> useless quite soon. One project which I am trying to work on, coredns,
> already does not compile with anything older than 1.12.
>
> I know we are in freeze already, but I still need to ask, whether there
> might be a freeze exception, or how we are going to remedy this
> situation?
>
>
FWIW, golang-1.12 was removed from buster, because the RT think
there're too many golang for buster[1].
At first we have golang-1.{10,11,12} in testing.
[1] https://tracker.debian.org/news/1024215/golang-112-removed-from-testing/
--
Shengjing Zhu
Re: PPAs (Re: [Idea] Debian User Repository? (Not simply mimicing AUR))
On Sun, Apr 14, 2019 at 4:02 AM Thomas Goirand wrote:
>
> On 4/8/19 7:16 PM, Shengjing Zhu wrote:
> >> from PPA (source+binary-based).
> >
> > If people just want a PPA which supports Debian, please just take a
> > look at OBS[1].
> >
> > I've seen many upstreams provide packages with OBS, and most
> > distributions are supported.
> > Not only deb, but also rpm, from Debian/Ubuntu to OpenSuse/Fedora, and
> > even Archlinux, in a uniform way.
> >
> > [1] https://build.opensuse.org/
>
> I don't see how OBS may help us. The proposal from Ganneff about
> bikesheds was much nicer (ie: using our already existing buildd and FTP
> infrastructure, and keeping our quality standard), than then path this
> thread is taking.
>
> If we are to propose sub-standard PPA like repositories, I would myself
> try to avoid them.
Who is "us"? If they are Debian {Developer, Maintainer, Contributor},
why they ever want to use PPA and its alternatives?
And I don't think OBS is much different from PPA, except one supports
build against Debian archive, another just Ubuntu.
PS, OBS here refers to the free service, not the OBS software.
--
Shengjing Zhu
Re: Bug#928657: ITP: golang-github-naegelejd-go-acl -- Golang POSIX 1e ACL bindings
Hi On Fri, May 10, 2019 at 4:06 PM Felixoid wrote: > > + submit, debian-devel, debian-go sub...@bugs.debian.org is meant for creating a new bug.. > > пт, 10 мая 2019 г. в 09:31, Felixoid : >> >> Hello. Did I miss something here? What would be the next step to submit the >> repo https://github.com/Felixoid/golang-github-naegelejd-go-acl to the >> created salsa >> https://salsa.debian.org/go-team/packages/golang-github-naegelejd-go-acl as >> well? >> >> I've created a guest user felixoid-guest and couldn't push into repo because >> of lack of permissions: >> > GitLab: You are not allowed to push code to this project. You could do it with dh-make-golang, you can get more info at https://go-team.pages.debian.net/packaging.html#_using_dh_make_golang -- Shengjing Zhu
Re: Sorce only uploads with sbuild (was: Bits from the Release Team)
On Tue, Jul 23, 2019 at 11:18 PM Sean Whitton wrote: > Just `git clean -xdff && dpkg-buildpackage -S` and dput the result, or > (easier) `dgit push-source`. > Maybe I miss something, sbuild just calls `dpkg-buildpackage -S`. If sbuild doesn't include orig tarball in -2 source.changes, then `dpkg-buildpackage -S` doesn't either. Is there any option of dpkg-buildpackage to include orig tarball in -2 changes? -- Shengjing Zhu
Re: Sorce only uploads with sbuild (was: Bits from the Release Team)
On Wed, Jul 24, 2019 at 12:46 AM Shengjing Zhu wrote:
>
> On Tue, Jul 23, 2019 at 11:18 PM Sean Whitton
> wrote:
> > Just `git clean -xdff && dpkg-buildpackage -S` and dput the result, or
> > (easier) `dgit push-source`.
> >
>
> Maybe I miss something, sbuild just calls `dpkg-buildpackage -S`. If
> sbuild doesn't include orig tarball in -2 source.changes, then
> `dpkg-buildpackage -S` doesn't either.
>
> Is there any option of dpkg-buildpackage to include orig tarball in -2
> changes?
>
Find it myself, it's in dpkg-genchanges(1) and -s{i,a,d} options.
--
Shengjing Zhu
Re: B-D on src package? (was: Re: Challenge from Julia's non-standard vendored openblas"64_"
Mo Zhou 于 2019年7月28日周日 16:03写道： > On 2019-07-28 13:13, Ian Jackson wrote: > > This is maybe not directly helpful to you right now, but: > > > > If we could build-depend on source packages, you could combine these > > two ideas into something that might be less awful. > > More than once have I thought of "what if I can B-D on a source > package". > Is such demand common enough among developers? > Yes, for those static linked languages, at least for Go. // send from my mobile device
Re: Mozilla Firefox DoH to CloudFlare by default (for US users)?
// send from my mobile device Jeremy Stanley 于 2019年9月13日周五 06:51写道： > On 2019-09-12 22:27:39 +0200 (+0200), Simon Richter wrote: > [...] > > The idea for resilience is "too big to block". > > > > When Domain Fronting still worked with Google, people used this to > > circumvent censorship because blocking it would have required > > blocking Google, so cooperation from Google was necessary to > > implement effective censorship. > [...] > > I'd be in favour of installing it by default (keep in mind: we are > > also "too big to block", so we're in the position to give software > > that is useful for activists an install base that makes it hard to > > identify activists by having the software installed). > > Note that by way of counterargument, Google and its services have > been blocked in mainland China by the Great Firewall for nearly a > decade now, so I question whether there is really such a thing as > "too big to block." > -- > Jeremy Stanley > I share the same concern. And please note that cloudflare doesn't have pop in China mainland, and in some ISP from China, the latency can be more than 200ms(http://mping.chinaz.com/?host=1.0.0.1). >
Re: Mozilla Firefox DoH to CloudFlare by default (for US users)?
On Fri, Sep 13, 2019 at 7:05 PM Simon Richter wrote: > > Hi, > > On Fri, Sep 13, 2019 at 12:28:23PM +0200, Marco d'Itri wrote: > > > > Note that by way of counterargument, Google and its services have > > > been blocked in mainland China by the Great Firewall for nearly a > > > decade now, so I question whether there is really such a thing as > > > "too big to block." > > > This is a false dichotomy: not all nation states are willing to go to > > the extreme lengths as China. > > Also, China cannot block Github, because they have no equivalent, and even > if they did, it wouldn't have the same content. Google is too easily > replicated, because they have no immediate contributors. > > I expect that China will set up a proxy service with clones of all relevant > Github repositories soon to keep read-only access to free software around > but inhibit organizing through shared documents. > > CloudFlare has too many services behind them that are important for the > economy and not replicable, so they are in a better position than Github > here. > Really? It's too native have such thoughts. It's never "too big to block". It's "not worth to block" if it's not too big. If you are in the "real" censorship environment, you would know how meaningless it is to rely on some "big" third-partys. Please don't in name of censorship-resistant. -- Shengjing Zhu
Re: Mozilla Firefox DoH to CloudFlare by default (for US users)?
On Sat, Sep 14, 2019 at 12:25 PM Shengjing Zhu wrote: > It's too native have such thoughts. It's never "too big to block". s/native/naive/ -- Shengjing Zhu
Re: Bug#1037927: ITP: fuse -- bazil.org/fuse - With macOS support and its own import path so replace directives aren't necessary
On Thu, Jun 15, 2023 at 3:29 AM Félix Sipma wrote: > > Sorry about this, the message was auto-generated by dh-make-golang and I > forgot to edit the package name in the ITP. I intend to use the usual > golang naming "golang-github-anacrolix-fuse". FWIW, You could use the `dh-make-golang -type library` option. -- Shengjing Zhu
Re: syslog-ng: identified for time_t transition but no ABI in shlibs
On Mon, Apr 8, 2024 at 9:15 PM Attila Szalay wrote:
>
> Ok. I re-checked the patch and realized that I checked the only wrong
> module (the only one which is arch all and not any).
>
> So my apologies for the fuzz and will apply the patch with the
> appropriate changes.
>
> But here my original reply too:
>
> I admit that I joined late to this conversation. But my complain is not
> about the time_t change.
>
> My complain is the contradiction between two thing:
> 1. https://wiki.debian.org/binNMU says that I should declar[e]
> dependency between an arch: all to an arch: any package: Depends: foo
> (>= ${source:Version}), foo (<< ${source:Version}.1~)
>
This is for arch: all -> arch: any. However I see most syslog-ng-mod-*
packages are arch: any. So it should just use strict equal on
syslog-ng-core.
What I'm confused about is some syslog-ng-mod-* packages are arch:
all, which don't have .so in it. Then why do they need to depend on
syslog-ng-core?
> 2. The bug report ask to depend on 'syslog-ng-core (=
> $${binary:Version})'
>
> This two is contradict and because syslog-ng complies with the binNMU
> request, I really reluctant to change that. Especially because in that
> case another ticket will be created in no-time to revert it.
>
> This is from the proposed changelog:
> + * Adjust shlibs for syslog-ng-core to use a strict versioned depends;
> +previously, modules used >=, << dependencies which did not account for
> +the possibility of ABI skew in a binNMU, which is exactly what happens
> +with the 64-bit time_t transition.
>
> And my question is again, is the rules really changed or we bend the
> rules just because of one transition?
--
Shengjing Zhu
Re: pandoc-filter-diagram_0.2.1-1_amd64.changes REJECTED
On Thu, May 16, 2024 at 4:35 PM Jonas Smedegaard wrote:
>
> Hi FTP-masters (cc d-devel list),
>
> A package, that I had initially introduced to Debian some months ago and
> had been pending in NEW queue since, was rejected few days ago, like
> this:
>
> Quoting Debian FTP Masters (2024-05-14 12:00:12)
> >
> > An exception was raised while processing the package:
> > Traceback (most recent call last):
> > File "/srv/ftp-master.debian.org/dak/dak/process_policy.py", line 121, in
> > wrapper
> > function(upload, srcqueue, comments, transaction)
> > File "/srv/ftp-master.debian.org/dak/dak/process_policy.py", line 248, in
> > comment_accept
> > transaction.copy_binary(
> > File "/srv/ftp-master.debian.org/dak/daklib/archive.py", line 390, in
> > copy_binary
> > self._ensure_extra_source_exists(filename, db_source, archive,
> > extra_archives=extra_archives)
> > File "/srv/ftp-master.debian.org/dak/daklib/archive.py", line 214, in
> > _ensure_extra_source_exists
> > raise ArchiveException('{0}: Built-Using refers to package {1} (= {2})
> > not in target archive {3}.'.format(filename, source.source, source.version,
> > archive.archive_name))
> > daklib.archive.ArchiveException:
> > p/pandoc-filter-diagram/pandoc-filter-diagram_0.2.1-1_amd64.deb:
> > Built-Using refers to package rust-ahash (= 0.8.9-2) not in target archive
> > ftp-master.
>
> I it correct to derive from the above, that packages in NEW queue must
> be freshly built, and that I (and we, generally) therefore should
> routinely rebuild packages pending in NEW queue to ensure that they are
> acceptably?
Not a ftp-master, but if you see such a message, it means that your
package has already been accepted, and you can continue uploading
without going through the NEW queue again.
--
Shengjing Zhu
Bug#974929: ITP: golang-mvdan-xurls -- Extract urls from text
Package: wnpp Severity: wishlist Owner: Shengjing Zhu X-Debbugs-Cc: debian-devel@lists.debian.org, debian...@lists.debian.org * Package name: golang-mvdan-xurls Version : 2.2.0-1 Upstream Author : Daniel Martí * URL : https://github.com/mvdan/xurls * License : BSD-3-clause Programming Lang: Go Description : Extract urls from text Extract urls from text using regular expressions. Dependency of gopls.
Bug#974930: ITP: golang-mvdan-gofumpt -- A stricter gofmt
Package: wnpp Severity: wishlist Owner: Shengjing Zhu X-Debbugs-Cc: debian-devel@lists.debian.org, debian...@lists.debian.org * Package name: golang-mvdan-gofumpt Version : 0.0~git20201107.a024667-1 Upstream Author : Daniel Martí * URL : https://github.com/mvdan/gofumpt * License : BSD-3-clause Programming Lang: Go Description : A stricter gofmt Enforce a stricter format than gofmt, while being backwards compatible. That is, gofumpt is happy with a subset of the formats that gofmt is happy with. The tool is a modified fork of gofmt, so it can be used as a drop-in replacement. Dependency of gopls.
Bug#977274: ITP: cpu-features -- cross-platform C library to retrieve CPU features at runtime
Package: wnpp Severity: wishlist Owner: Shengjing Zhu X-Debbugs-Cc: debian-devel@lists.debian.org, z...@debian.org * Package name: cpu-features Version : 0.6.0 Upstream Author : Guillaume Chatelet * URL : https://github.com/google/cpu_features * License : Apache-2.0 Programming Lang: C Description : cross-platform C library to retrieve CPU features at runtime A cross-platform C library to retrieve CPU features (such as available instructions) at runtime. It was embedded in various packages: volk, spoa, anbox. https://codesearch.debian.net/search?q=cpuinfo_x86.h&literal=1 As new version of anbox doesn't include it in source tarabll anymore, I'm going to package it as a standalone package.
Re: Package broke in stable due to old API. Fix in stable or backports?
On Sun, Jan 10, 2021 at 12:15 AM Yao Wei wrote: > > Hi, > > I have a package `meteo-qt` which is broke due to the use of old API, > which is reported here: > https://bugs.debian.org/960451 > > There should be many existing cases, that external service the stable > package is using deprecates the old API, which in turn breaks the > package. Do we have documented conventions that where the fixed package > should be uploaded to: stable-proposed-updates or backports? > Usually you need to backport the relevant patch, instead of uploading a new upstream version to stable. -- Shengjing Zhu
Re: Split Packages files based on new section "buildlibs"
On Wed, Feb 17, 2021 at 9:33 PM Johannes Schauer Marin Rodrigues wrote: [...] > And then I run "cargo build". Every time I get a message like: > > error: no matching package named `foo` found > > I install librust-foo-dev until finally: > > Parent pid 535147, child pid 535148 > Child process initialized in 30.93 ms >Compiling proc-macro2 v1.0.18 >Compiling unicode-xid v0.2.0 >Compiling syn v1.0.12 >Compiling dotenv v0.15.0 (/tmp/dotenv/dotenv) >Compiling quote v1.0.7 >Compiling proc-macro-hack v0.5.9 >Compiling dotenv_codegen_implementation v0.15.0 > (/tmp/dotenv/dotenv_codegen_implementation) >Compiling dotenv_codegen v0.15.0 (/tmp/dotenv/dotenv_codegen) > Finished dev [unoptimized + debuginfo] target(s) in 9.93s > > Parent is shutting down, bye... > > So how is this "very difficult"? The steps are the same as when I clone a > Python upstream git repo and I get the message "ModuleNotFoundError: No module > named 'foo'" -- I just install python3-foo and it will work. Same here with > rust and the librust-foo-dev packages. I do think it's "very difficult". You end up calculating dependency trees by hand, instead of an automatic program, like cargo, pip. How does it come for version satisfaction? For example a library version installed in system path conflicts the software you are developing. -- Shengjing Zhu
Re: New service: https://debuginfod.debian.net
On Tue, Feb 23, 2021 at 10:53:14PM -0500, Sergio Durigan Junior wrote: > Hello there, > > I would like to announce a new service that I have just configured for > Debian: https://debuginfod.debian.net. > Thanks a lot for this great service. I have two questions. 1. Do you want to include contrib and nonfree as well? 2. Is this site mirror-able, or is the deploy scripts available somewhere? I tried this instance, but I got problems like: Download failed: Timer expired. Continuing without debug info for ... So I think it's benefit to setup an instance in my network area too. For those like me, that don't have good quality network to European datacenter.
i386 baseline issue for Go packages in Bookworm
Hi, As the release of Go 1.16, upstream no longer supports x87-only floating-point. https://golang.org/doc/go1.16#386 > require at least SSE2 support on 386, raising Go's minimum GOARCH=386 > requirement to the Intel Pentium 4 (released in 2000) or > AMD Opteron/Athlon 64 (released in 2003). So we have 3 options for Go packages on i386 in Bookwarm. 1. Raise the i386 baseline to SSE2. 2. Downgrade the Go packages to softfloat. 3. Build all Go packages with GCCGO on i386. As for the option 3, I don't how best is supported by upstream. But most packages may work, if some specific packages FTBFS after switching to GCCGO, they need to be removed on i386 unfortunately. What people prefer for the 3 options?
Re: i386 baseline issue for Go packages in Bookworm
On Sun, Apr 18, 2021 at 1:32 AM Andrey Rahmatullin wrote: > 2) decide "the i386 architecture is for the legacy software" and raise the > baseline to match the amd64 one, > 2a) also don't build non-library packages there. Just FTR, it does't apply to Go packages, as all Go packages are written after SSE2. Go was publicly announced in November 2009. -- Shengjing Zhu
Re: i386 baseline issue for Go packages in Bookworm
On Sun, Apr 18, 2021 at 5:18 AM Tianon Gravi wrote: > > On Sat, 17 Apr 2021 at 10:10, Shengjing Zhu wrote: > > 1. Raise the i386 baseline to SSE2. > > 2. Downgrade the Go packages to softfloat. > > 3. Build all Go packages with GCCGO on i386. > > We've been setting "GO386=387" since src:golang was introduced, so 2. > is already the reality. :D > > What makes Go 1.16 complicated in this regard is that they've renamed > the value to "softfloat" but the bootstrap compiler still needs it set > to "387"... > Hmm, I thought GO386=softfloat is still different to GO386=387. It's still some performance downgrade. I find you have turned all golang docker images to GO386=softfloat, I think we can follow it in Debian. -- Shengjing Zhu
Re: i386 baseline issue for Go packages in Bookworm
On Sun, Apr 18, 2021 at 1:09 AM Shengjing Zhu wrote: > > Hi, > > As the release of Go 1.16, upstream no longer supports x87-only > floating-point. > > https://golang.org/doc/go1.16#386 > > > require at least SSE2 support on 386, raising Go's minimum GOARCH=386 > > requirement to the Intel Pentium 4 (released in 2000) or > > AMD Opteron/Athlon 64 (released in 2003). > > So we have 3 options for Go packages on i386 in Bookwarm. > > 1. Raise the i386 baseline to SSE2. > 2. Downgrade the Go packages to softfloat. > 3. Build all Go packages with GCCGO on i386. > > As for the option 3, I don't how best is supported by upstream. > But most packages may work, if some specific packages FTBFS after switching > to GCCGO, they need to be removed on i386 unfortunately. > An update on this issue. golang-1.16/1.16.3-4 has been uploaded to unstable. It's built with GO386=softfloat on i386 arch only. Which means any Go packages built with it on i386 will default to softfloat. But people try to cross build Go packages for i386, defaults to sse2. The settings can be checked by running `GOARCH=386 go env GO386`. And can be changed by setting GO386 env manually. -- Shengjing Zhu
Bug#988599: ITP: kata-containers -- secure container runtime with lightweight virtual machines
Package: wnpp Severity: wishlist Owner: Shengjing Zhu X-Debbugs-Cc: debian-devel@lists.debian.org, z...@debian.org * Package name: kata-containers Version : 2.1.0 Upstream Author : Kata Containers * URL : https://katacontainers.io/ * License : Apache-2.0 Programming Lang: Go, Rust Description : secure container runtime with lightweight virtual machines Kata Containers is an open source project and community working to build a standard implementation of lightweight Virtual Machines (VMs) that feel and perform like containers, but provide the workload isolation and security advantages of VMs.
Re: debian:stable docker image points wrong path for security updates
On Sun, Aug 15, 2021 at 3:48 PM Hideki Yamane wrote: > > Hi, > > I've commited release notes translation update to repo but CI failed. > > It is because debian:stable docker image's setting: it is still > old style "stable/updates", instead of "stable-security" for security > updates(*). > > >> Err:5 http://security.debian.org/debian-security stable/updates Release > >> 404 Not Found [IP: 151.101.130.132 80] > > > > $ docker run -it debian:stable /bin/bash > > root@467cd5226ed1:/# sed -i -e 's/stable\/updates/stable-security/' > > /etc/apt/sources.list > > root@467cd5226ed1:/# apt update > > Get:1 http://deb.debian.org/debian stable InRelease [113 kB] > > Get:2 http://security.debian.org/debian-security stable-security InRelease > > [44.1 kB] > > Get:3 http://security.debian.org/debian-security stable-security/main amd64 > > Packages [19.0 kB] > > Get:4 http://deb.debian.org/debian stable-updates InRelease [40.1 kB] > > Get:5 http://deb.debian.org/debian stable/main amd64 Packages [8178 kB] > > Fetched 8393 kB in 4s (2044 kB/s) > > Reading package lists... Done > > Do you know When it will update to bullseye? > Instead of waiting for docker:stable tag to be updated to bullseye, you can use debian:bullseye tag. -- Shengjing Zhu
Bug#996267: ITP: golang-github-mdlayher-vsock -- Vsock provides access to Linux VM sockets (AF_VSOCK)
Package: wnpp Severity: wishlist Owner: Shengjing Zhu * Package name: golang-github-mdlayher-vsock Version : 0.0~git20210303.10d5918-1 Upstream Author : Matt Layher * URL : https://github.com/mdlayher/vsock * License : Expat Programming Lang: Go Description : Vsock provides access to Linux VM sockets (AF_VSOCK) Package vsock provides access to Linux VM sockets (AF_VSOCK) for communication between a hypervisor and its virtual machines.
Re: deb822 sources by default for bookworm
On Wed, Nov 3, 2021 at 11:45 PM Julian Andres Klode wrote: > > Hi all, > > I'd like us to move from > > /etc/apt/sources.list > > to > /etc/apt/sources.list.d/debian.sources > While it's really a nice feature for the third-party repository, I don't see the benefits to change the default one, especially the path. I had to admit that I have countless scripts which run `sed /etc/apt/souces.list`, to change the default mirror, as well as in the Dockerfile. > in bookworm. > > # deb822 intro > > The deb822 format can be shorter and easier to read, to quote the > sources.list manual page: > >As an example, the sources for your distribution could look like this > in one-line-style format: > >deb http://deb.debian.org/debian bullseye main contrib non-free >deb http://security.debian.org bullseye-security main contrib > non-free > >or like this in deb822 style format: > >Types: deb >URIs: http://deb.debian.org/debian >Suites: bullseye >Components: main contrib non-free > >Types: deb >URIs: http://security.debian.org >Suites: bullseye-security >Components: main contrib non-free > > > Now if you mix unstable and testing, you could just have that it one > paragraph. > > The big advantage of deb822 sources is that you can embed larger data: > >Types: deb >URIs: https://deb.debian.org >Suites: stable >Components: main contrib non-free >Signed-By: > -BEGIN PGP PUBLIC KEY BLOCK- > . > > mDMEYCQjIxYJKwYBBAHaRw8BAQdAD/P5Nvvnvk66SxBBHDbhRml9ORg1WV5CvzKY > > CuMfoIS0BmFiY2RlZoiQBBMWCgA4FiEErCIG1VhKWMWo2yfAREZd5NfO31cFAmAk > > IyMCGyMFCwkIBwMFFQoJCAsFFgIDAQACHgECF4AACgkQREZd5NfO31fbOwD6ArzS > > dM0Dkd5h2Ujy1b6KcAaVW9FOa5UNfJ9FFBtjLQEBAJ7UyWD3dZzhvlaAwunsk7DG > 3bHcln8DMpIJVXht78sL > =IE0r > -END PGP PUBLIC KEY BLOCK- > > Oh yeah, a standalone sources file with embedded key - making third-party > repository management substantially more convenient. > > # issues > > several software does not support deb822 currently. I plan to work on > adding deb822 support to python-apt in the upcoming months, I don't know > what else is affected. > > There is some software "parsing" sources.list on its own, most of that > is better served by `apt-get indextargets` (and for downloading stuff > based on the urls, `apt-helper download-file`, such that it respects > proxies and supports all transports users may use in sources.list) > > In terms of setting up system, I guess debootstrap and d-i's apt-setup > module need changes? I admit I do not have a total overview. > > # timeline > > I do not know the total outcome of this. My hope would be that > we can switch the default in Summer 2022 and see what breaks, > although I don't know who's going to install from testing > d-i :D > > docker images probably can move earlier as they don't have > as much interactive users that use tools that might be broken > (e.g. software-properties). Possibly others, there's no need > to roll out in multiple places at the same time, as long as > we converge by freeze time. > > I invite people to test this out already on their own systems, > I know several people do; and extrepo also builds deb822 sources > files, but several people I guess do not know about it yet. Please > test and report bugs. > -- > debian developer - deb.li/jak | jak-linux.org - free software dev > ubuntu core developer i speak de, en > -- Shengjing Zhu
Bug#999478: ITP: golang-opentelemetry-otel -- OpenTelemetry Go API and SDK
Package: wnpp Severity: wishlist Owner: Shengjing Zhu * Package name: golang-opentelemetry-otel Version : 1.1.0-1 Upstream Author : OpenTelemetry * URL : https://github.com/open-telemetry/opentelemetry-go * License : Apache-2.0 Programming Lang: Go Description : OpenTelemetry Go API and SDK OpenTelemetry-Go is the Go implementation of OpenTelemetry. It provides a set of APIs to directly measure performance and behavior of your software and send this data to observability platforms.
Re: funding salsa runners for planning transitions with lots of reverse build deps
On Wed, Mar 23, 2022 at 4:09 AM Jérémy Lal wrote: > > Hi, > > I think Salsa CI is a great tool for rebuilding all the reverse build > dependencies > of a given package (here nodejs, but it applies to all others). > Unfortunately, the current salsa gitlab runners available are not scaled to be > able to handle that use case. Are the runners, or Salsa, or the GitLab(software) itself not scaled to handle such cases? I have the impression that Google Cloud has funded the shared runners, and the budget is not the problem. -- Shengjing Zhu
Bug#1011149: ITP: mogan -- structured editor for science and technology
Package: wnpp Severity: wishlist Owner: Shengjing Zhu X-Debbugs-Cc: debian-devel@lists.debian.org, z...@debian.org * Package name: mogan Version : 1.0.3 Upstream Author : Darcy Shen * URL : https://github.com/XmacsLabs/mogan * License : GPL-3+ Programming Lang: Tcl, Scheme, C++ Description : structured editor for science and technology Mogan Editor is a fork of GNU TeXmacs using S7 Scheme and Qt 5 with massive online TeXmacs documents provided by Xmacs Planet and TMML wiki. . The software includes a text editor with support for mathematical formulas, a small technical picture editor and a tool for making presentations from a laptop. Moreover, Mogan can be used as an interface for many external systems for computer algebra, numerical analysis, statistics, etc. . New presentation styles can be written by the user and new features can be added to the editor using the Scheme extension language. A native spreadsheet and tools for collaborative authoring are planned for later. . Mogan runs on all major Unix platforms and Windows. Documents can be saved in TeXmacs, Xml or Scheme format and printed as Postscript or Pdf files. Converters exist for TeX/LaTeX and Html/Mathml.
Re: Error when running dh_dwz (actually an error when running dwz(1))
Hi, On Wed, Jul 10, 2019 at 3:28 PM Matthias Klose wrote: > > On 09.07.19 21:54, Boyuan Yang wrote: > > Dear -devel list, > > > > Looks like dh_dwz was recently added into debhelper and it is causing some > > FTBFS on one of my packages. It could be a bug of dwz itself but I'm looking > > for some help inside Debian first. > > > > Please try to build package marisa from its git packaging repo > > ( > > https://salsa.debian.org/input-method-team/marisa/commit/f5ff598466266b230d68c9db9f8e31281604b7a6 > > ). The following error will pop up when dwz is called: > > > > = > > [...] > >dh_dwz > > dwz: debian/ruby-marisa/usr/lib/x86_64-linux-gnu/ruby/2.5.0/marisa.so: Found > > compressed .debug_aranges section, not attempting dwz compression > > dh_dwz: dwz -q -- debian/ruby-marisa/usr/lib/x86_64-linux- > > gnu/ruby/2.5.0/marisa.so returned exit code 1 > > make: *** [debian/rules:30: binary] Error 1 > > dpkg-buildpackage: error: fakeroot debian/rules binary subprocess returned > > exit status 2 > > = > > > > I don't have much experience of dealing with debugging symbols so any hints > > would be appreciated. > > dwz currently doesn't handle compressed debug sections. There is some > discussion, if dwz should decompress, do it's work and compress it again. > However until then, don't use compressed debug sections. Apparently these are > turned on by the upstream build system. debhelper maybe could warn about > compressed debug sections in general. Would would you want to have those > anyway? > The packages are compressed, and you shouldn't care about the on-disk space > when debugging. > > There's also discussion, about errors: > https://sourceware.org/bugzilla/show_bug.cgi?id=24766 > Apparently the RPM based helpers ignore the return value of dwz, and leave the > debug symbols unhandled. Again, debhelper could warn about such packages when > built in compat12 mode. Now with golang-1.19, all Go packages ftbfs with dwz: Found compressed .debug_aranges section, not attempting dwz compression Could the debhelper ignore the dwz error? Or can a debhelper addon (e.g. dh-golang) be allowed to override dh_dwz globally? -- Shengjing Zhu
Re: Error when running dh_dwz (actually an error when running dwz(1))
On Sun, Aug 7, 2022 at 7:53 PM Shengjing Zhu wrote:
>
> Hi,
>
> On Wed, Jul 10, 2019 at 3:28 PM Matthias Klose wrote:
> >
> > On 09.07.19 21:54, Boyuan Yang wrote:
> > > Dear -devel list,
> > >
> > > Looks like dh_dwz was recently added into debhelper and it is causing some
> > > FTBFS on one of my packages. It could be a bug of dwz itself but I'm
> > > looking
> > > for some help inside Debian first.
> > >
> > > Please try to build package marisa from its git packaging repo
> > > (
> > > https://salsa.debian.org/input-method-team/marisa/commit/f5ff598466266b230d68c9db9f8e31281604b7a6
> > > ). The following error will pop up when dwz is called:
> > >
> > > =
> > > [...]
> > >dh_dwz
> > > dwz: debian/ruby-marisa/usr/lib/x86_64-linux-gnu/ruby/2.5.0/marisa.so:
> > > Found
> > > compressed .debug_aranges section, not attempting dwz compression
> > > dh_dwz: dwz -q -- debian/ruby-marisa/usr/lib/x86_64-linux-
> > > gnu/ruby/2.5.0/marisa.so returned exit code 1
> > > make: *** [debian/rules:30: binary] Error 1
> > > dpkg-buildpackage: error: fakeroot debian/rules binary subprocess returned
> > > exit status 2
> > > =
> > >
> > > I don't have much experience of dealing with debugging symbols so any
> > > hints
> > > would be appreciated.
> >
> > dwz currently doesn't handle compressed debug sections. There is some
> > discussion, if dwz should decompress, do it's work and compress it again.
> > However until then, don't use compressed debug sections. Apparently these
> > are
> > turned on by the upstream build system. debhelper maybe could warn about
> > compressed debug sections in general. Would would you want to have those
> > anyway?
> > The packages are compressed, and you shouldn't care about the on-disk space
> > when debugging.
> >
> > There's also discussion, about errors:
> > https://sourceware.org/bugzilla/show_bug.cgi?id=24766
> > Apparently the RPM based helpers ignore the return value of dwz, and leave
> > the
> > debug symbols unhandled. Again, debhelper could warn about such packages
> > when
> > built in compat12 mode.
>
> Now with golang-1.19, all Go packages ftbfs with
>
> dwz: Found compressed .debug_aranges section, not attempting dwz compression
>
> Could the debhelper ignore the dwz error? Or can a debhelper addon
> (e.g. dh-golang) be allowed to override dh_dwz globally?
>
It turns out there is a `remove_command` API in debhelper, so
dh-golang/1.58 now calls `remove_command('dh_dwz')`.
--
Shengjing Zhu
Re: FTBS bugs -- MBF?
Package: dh-golang Severity: wishlist Control: retitle -1 dh-golang unnecessary call for go command in clean target > Apparently there's not a single package that needs B-D-Arch. I've just > looked in case if sbuild installs those by default, but it's not the case. > A sample package (acmetool) for example says: > > dh clean --buildsystem=golang --with=golang,apache2 >dh_auto_clean -O--buildsystem=golang > Can't exec "go": No such file or directory at > /usr/share/perl5/Debian/Debhelper/Buildsystem/golang.pm line 443. > Use of uninitialized value in pattern match (m//) at > /usr/share/perl5/Debian/Debhelper/Buildsystem/golang.pm line 443. > Can't exec "go": No such file or directory at > /usr/share/perl5/Debian/Debhelper/Buildsystem/golang.pm line 449. > Use of uninitialized value in pattern match (m//) at > /usr/share/perl5/Debian/Debhelper/Buildsystem/golang.pm line 449. > Use of uninitialized value $_gcc_major in multiplication (*) at > /usr/share/perl5/Debian/Debhelper/Buildsystem/golang.pm line 450. >dh_autoreconf_clean -O--buildsystem=golang >dh_clean -O--buildsystem=golang > dpkg-source -b . Looks like a bug in dh-golang, it shouldn't need to use the compiler to clean. -- Shengjing Zhu
Re: Firmware GR result - what happens next?
On Sun, Oct 2, 2022 at 10:53 PM Steve McIntyre wrote: > > On Sun, Oct 02, 2022 at 04:43:47PM +0200, Michael Biebl wrote: > > > >Hi Steve, > > > >thanks for the update! > > > >Am 02.10.22 um 16:27 schrieb Steve McIntyre: > > > >> * Tweaks to add the non-free-firmware section in the apt-setup module > >>if desired/needed. > > > >... > > > >> If you think I've missed anything here, please let me and Cyril know - > >> the best place would be the mailing list > >> (debian-b...@lists.debian.org). > > > >What's the plan for upgraded systems with an existing /etc/apt/sources.list. > >Will the new n-f-f section added on upgrades automatically(if non-free was > >enabled before)? > > So this is the one bit that I don't think we currently have a good > answer for. We've never had a specific script to run on upgrades (like > Ubuntu do), so this kind of potentially breaking change doesn't really > have an obvious place to be fixed. > > Obviously we'll need to mention this in the release notes for > bookworm. Should we maybe talk about adding an upgrade helper tool? For upgrading, people already need to edit their source list to change the suite name, why would it hurt to add one more manual step to change the section name? -- Shengjing Zhu
Re: transitional packages? (was: Firmware GR result - what happens next?)
On Mon, Oct 3, 2022 at 7:31 PM Didier 'OdyX' Raboud wrote: > > 3 octobre 2022 11:11 "Santiago Ruano Rincón" a écrit: > > El 02/10/22 a las 20:42, Michael Biebl escribió: > >> Am 02.10.22 um 20:14 schrieb Luca Boccassi: > >> On Sun, 2022-10-02 at 10:52 -0700, Russ Allbery wrote: > >> In Bullseye we changed the name/syntax for the security repository, and > >> for that a mention in the release notes was enough, no? Isn't this a > >> very similar situation? > >> > >> The main difference is, that the renaming caused an error message by apt, > >> so > >> you knew something needed to be fixed. > >> > >> For this particular change, there will be no error. So yes, I have the same > >> fear as Russ that this particular change might go unnoticed. > > > > Couldn't we handle this via transitional firware* non-free packages, > > that depend on bookworm non-free-firmware packages? > > That would only work if we renamed all concerned binary packages, or if apt > grew a "section/packagename" syntax (which would be bizarre). > Can we have different versions in each section? + non-free/pkgA version~1 + non-free-firmware/pkgA version~2 And let non-free/pkgA version~1 just fail during upgrade and produce a migration guide. -- Shengjing Zhu
Re: transitional packages? (was: Firmware GR result - what happens next?)
On Mon, Oct 3, 2022 at 11:32 PM Santiago Ruano Rincón wrote: > > Can we have different versions in each section? > > > > + non-free/pkgA version~1 > > + non-free-firmware/pkgA version~2 > > that wouldn't comply with the current policy: > https://www.debian.org/doc/debian-policy/ch-binary.html#the-package-name > I don't think it's related to name policy. It's whether dak will remove old versions in different sections. -- Shengjing Zhu
Re: Should singularity-container make it to next release?
On Thu, Oct 13, 2022 at 12:20 AM olivier sallou wrote: > Last resort is to keep CVEs open this is the case for different tools :-( > This shouldn't apply to singularity which is a sandbox/container tool... -- Shengjing Zhu
Bug#1022798: ITP: golang-github-golang-protobuf -- Go support for Google's protocol buffers
Package: wnpp Severity: wishlist Owner: Shengjing Zhu * Package name: golang-github-golang-protobuf-1-5 Version : 1.5.2-1 Upstream Author : Go * URL : https://github.com/golang/protobuf * License : BSD-3-clause Programming Lang: Go Description : Go support for protocol buffers (version v1.5.x) This module (github.com/golang/protobuf) contains Go bindings for protocol buffers. . It has been superseded by golang-google-protobuf-dev package. . It is incompatible with golang-github-gogo-protobuf-dev package. . Version v1.3.x is provided in golang-goprotobuf-dev package. Reason for packaging: github.com/golang/protobuf 1.3 -> 1.4 is a great breaking change that is incompatible with github.com/gogo/protobuf. Many packages have been staled due to this. So we need to duplicate the source. The development of github.com/golang/protobuf is frozen. v1.5.2 is expected to be the final version.
Re: Should singularity-container make it to next release?
Hi Nilesh, On Mon, Jan 9, 2023 at 6:21 PM Nilesh Patra wrote: > I started this thread a while back, and decided to simply ask upstream about > what their > opinion is[9] > It looks like the situation still not fully certain on whether to let > singularity make it to stable > or not. > > I'd appreciate if someone on the list could chime in and give an opinion on > if they > consider it do-able or not for upcoming bookworm release. > Could you list the concerns that you have? + Security support? I see upstream comments that they will disclose the relevant fix/commit for CVE, then it should be enough. I think most packages in Debian rely on the Debian maintainer to backport the fix. + Lacking tests? (as per upstream concerns in the Github issue) Do you plan to enable all the tests? I see you have disabled many tests[1] Or even better, could you run the integration/e2e tests with autopkgtest? For example, you can take a look at the containerd package that I've maintained[2]. [1] https://salsa.debian.org/hpc-team/singularity-container/-/blob/debian/3.10.3+ds1-1/debian/rules#L68 [2] https://salsa.debian.org/go-team/packages/containerd/-/blob/debian/sid/debian/tests/cri-integration https://salsa.debian.org/go-team/packages/containerd/-/blob/debian/sid/debian/tests/integration -- Shengjing Zhu
Re: Please, minimize your build chroots
On Sat, Jan 28, 2023 at 9:29 PM Johannes Schauer Marin Rodrigues wrote: > To me it seems that we nearly are already at (2). The debootstrap bug #837060 > has a working patch and mmdebstrap exists that can do what is needed today. > Santiago did an archive rebuild to make sure our source package compile in a > chroot without Priority:required. > > Why do people call just accepting that Priority:required packages have to be > part of the buildd chroot the easier solution? We just need to fix debootstrap > bug #837060 and we are done, no? > Yes, please fix debootstrap or anything else first, and ensure buildd uses the fixed version. If you can't convince the buildd to follow the policy, why should the individual package maintainers? -- Shengjing Zhu
Re: rust-*/librust-* arch:any vs. arch:all and cross-compilation support
Sam Hartman 于 2023年2月16日周四 06:37写道： > However, adding a question to the mix, why does arch all work for go > packages? > Do they not care about cross compilation, or are concerns somehow > different there? Go doesn't work. I guess we started from the common sense that arch-indepent files should be arch:all. Or at that time Multi-Arch is not widely recognized. (There is also a cross compile related patch in golang-defaults that haven't been merged yet for some years.) (Sent from my mobile device)
Re: rust-*/librust-* arch:any vs. arch:all and cross-compilation support
Shengjing Zhu 于 2023年2月16日周四 09:16写道： > Sam Hartman 于 2023年2月16日周四 06:37写道： > >> However, adding a question to the mix, why does arch all work for go >> packages? >> Do they not care about cross compilation, or are concerns somehow >> different there? > > > Go doesn't work. I guess we started from the common sense that > arch-indepent files should be arch:all. Or at that time Multi-Arch is not > widely recognized. > I should say Go doesn't work when an arch:any (usually a C library) is involved. But well most Go programs are pure Go which are not affected by this all-any trap. (Sent from my mobile device)
Re: icc-profiles_2.2_source.changes REJECTED
Hi, On Fri, Feb 24, 2023 at 7:38 AM Jonas Smedegaard wrote: > > What to do when a package is blocked from getting updated due to it > being itself? > > I have tried replying to FTPmasters as invited in the rejection message, > but have been met with silence. > > I have tried filing bug#1030961 but have so far seen no response on that > either. > > Will it make sense to reassing that bugreport to the technical > committee? Or to the release team? Or should I request removal of the > package, because security bugfixes (however unlikely for a package > containing purely static data files) is impossible? > > > - Jonas > > Quoting Debian FTP Masters (2023-02-09 04:19:39) > > > > icc-profiles source: lintian output: 'license-problem-md5sum-non-free-file > > ECI-RGB.V1.0.icc usual name is ECI-RGB.V1.0.icc. Does not allow > > modification See also https://packages.debian.org/sid/icc-profiles.', > > automatically rejected package. [snip] > > icc-profiles source: lintian output: > > 'source-only-upload-to-non-free-without-autobuild ', automatically rejected > > package. > > icc-profiles source: If you have a good reason, you may override this > > lintian tag. It's auto rejected. So I think it can be technically solved. For license-problem-md5sum-non-free-file, it's obviously a false positive from lintian. It should not emit such if the source is the non-free section. It should be reported as a bug for the lintian package. And you can submit patches as well, backport to the version that ftp-master server uses. For source-only-upload-to-non-free-without-autobuild, it's really a bug in your upload. You should fix it. -- Shengjing Zhu
Re: DEB_BUILD_OPTIONS=nowerror
On Fri, Feb 24, 2023 at 2:26 PM Helmut Grohne wrote: > > Hi, > > I observe a pattern repeated at least twice and probably more often in > packages. > > * A package adds -Werror to the build. When a new toolchain version is >uploaded, it triggers a new warning and that makes the package FTBFS. > * A package runs shellcheck during build. When a new shellcheck is >uploaded, it triggers a new warning and makes the package FTBFS. > IMO, these are just linters. And shouldn't not run after the source is released. I'd like to propose the option name `nolint`. -- Shengjing Zhu
Re: Updating python3-xlrd for pandas 1.5 compatibility
On Sat, Feb 25, 2023 at 2:33 AM Paul Gevers wrote: > pandas has a quite extensive autopkgtest, doesn't it > cover this use case? Apparently you knew this earlier, why do you bring > this up now? Seems a bit unfortunate when pandas updates the version. https://salsa.debian.org/science-team/pandas/-/blob/debian/1.5.3+dfsg-2/pandas/tests/io/excel/test_xlrd.py#L13 https://salsa.debian.org/science-team/pandas/-/blob/debian/1.5.3+dfsg-2/debian/tests/control#L51 A RC bug for python3-xlrd was missing when pandas updated to 1.4.3+dfsg-1. -- Shengjing Zhu
Re: Updating python3-xlrd for pandas 1.5 compatibility
On Sat, Feb 25, 2023 at 2:51 AM Shengjing Zhu wrote: > > On Sat, Feb 25, 2023 at 2:33 AM Paul Gevers wrote: > > pandas has a quite extensive autopkgtest, doesn't it > > cover this use case? Apparently you knew this earlier, why do you bring > > this up now? > > Seems a bit unfortunate when pandas updates the version. > > https://salsa.debian.org/science-team/pandas/-/blob/debian/1.5.3+dfsg-2/pandas/tests/io/excel/test_xlrd.py#L13 > https://salsa.debian.org/science-team/pandas/-/blob/debian/1.5.3+dfsg-2/debian/tests/control#L51 > Reading the comments in test/control, seems python3-blosc and python3-snappy are also not compatible with the version of pandas. -- Shengjing Zhu
Re: Debian and our frenemies of containers and userland repos
On Mon, Oct 7, 2019 at 1:23 PM Johannes Schauer wrote: > > Quoting Paul Wise (2019-10-07 03:38:55) > > On Sun, Oct 6, 2019 at 7:23 PM Simon McVittie wrote: > > > FYI, this is because autopkgtest has an abstraction for multiple > > > container/virtualization mechanisms (lxc, lxd, qemu, schroot) > > It seems like this abstraction should be split out of the autopkgtest > > source and then depended on by autopkgtest. Do any other such > > abstraction layers exist? > > I do not know of any other such abstraction layers but would warmly welcome > them not only for the purpose of including them in sbuild. > Not sure if containerd[1] and cri[2] are such abstraction layers. They are widely used in cloud/container area. For containerd, it supports both container and virtualization[3] backends. [1] https://containerd.io/ [2] https://github.com/kubernetes/community/blob/master/contributors/devel/sig-node/container-runtime-interface.md [3] https://katacontainers.io/ -- Shengjing Zhu
Re: Debian and our frenemies of containers and userland repos
On Mon, Oct 7, 2019 at 6:29 PM Simon McVittie wrote:
>
> On Mon, 07 Oct 2019 at 07:22:53 +0200, Johannes Schauer wrote:
> > Specifically, currently autopkgtest is limited to providing a read-only
> > layer
> > for certain backends and its upstream has no intention of widening the
> > scope of
> > the software [1]. This means that to upgrade an autopkgtest backend, the
> > user
> > has to apply backend-specific actions
>
> I think "re-bootstrap, don't upgrade" is an equally good principle
Why not have a repository for it, like dockerhub. So this becomes
"pull latest build env", which saves lots of time("re-bootstrap" is
still slow nowadays).
--
Shengjing Zhu
Re: Debian and our frenemies of containers and userland repos
On Mon, Oct 7, 2019 at 7:21 PM Philipp Kern wrote: > In that case it'd probably be better to make bootstrapping faster rather > than trusting random binaries on the internet. (Unless we grow an > "assemble an image from debs" service on, say, ftp-master.) > We already have such, the cloud image service.(I think these images only include minbase variant, not buildd variant). https://cloud.debian.org/images/cloud/ -- Shengjing Zhu
Re: difficulty in understanding options in init-system-GR
On Sat, Dec 7, 2019 at 3:45 PM Mo Zhou wrote: > > Hi folks, > > I went through the options in the init-system-GR[1] but I feel difficult > to tell the subtle differences between the options. I'd like to ask for > some hints here. > I asked on IRC this morning too. Someone pointed me the LWN article[1], I think it has a good summary. [1] https://lwn.net/Articles/806332/ -- Shengjing Zhu
Re: opentmpfiles & opensysusers, and its use in the Debian policy
On Thu, Jan 2, 2020 at 9:22 PM Thomas Goirand wrote: [...] > My proposal is for Debian to standardize on: > /bin/tmpfiles > > and: > /usr/bin/sysusers > I don't understand why we need these. The advantages of sysusers.d and tmpfiles.d are that you don't need to call some magic scripts. You only need to write declarative configuration files. On systemd system, they are handled by systemd-sysusers.service and systemd-tmpfiles-*.service. You really don't need to care where the binaries are located. On openrc system, I think they are handled by corresponding init services too. https://github.com/OpenRC/opentmpfiles/tree/master/openrc [...] > opensysusers if a package is using /usr/bin/sysusers. I'm not sure why > there's both /bin/systemd-sysusers and /usr/bin/systemd-sysusers, and > which one should be used. Maybe Michael, you know? Where is /usr/bin/systemd-sysusers? at least not in testing. -- Shengjing Zhu
Re: ratt as a service?
On Mon, Mar 23, 2020 at 8:34 AM Sandro Tosi wrote: > > Hello, > ratt (rebuild all the things, https://packages.debian.org/sid/ratt) is > really interesting but it's sometimes hard to use effectively on > personal resources: some packages have tens, if not hundreds of > reverse dependencies, and running ratt for them on your laptop is just > not feasible. > > So i'm wondering if Debian should offer a service where: > > * a developer (as someone with a gpg key in the debian keyring, at > least at first) uploads a binary .changes file (so source + binary > packages, built locally) to a new dput upload queue > * ratt is executed against that package reverse dependencies > * when the run is completed, a recap email is sent to the Changed-By > address with the list of fail/success > * also a web interface to track the progress of the rebuild & read the > build logs. > > this could be scaled pretty easily with multiple backend "builders" > (and we can put limits in place to reduce concurrency, like one > package per developer only etc etc) This is especially useful for some teams, like pkg-go team. Most ftbfs can't be found except rebuilding all the reverse dependecies. This is probably why stapelberg implemented this. If there's a such service, I hope it can be integrated with salsa, and be triggered when you push. However if it's been widely used, I would concern how to build more efficiently and cache friendly. -- Shengjing Zhu
Re: new kubernetes packaging
Another question for the current kubernetes maintainer. What's your plan for the k8s.io/* libraries, eg k8s.io/api k8s.io/client-go. They are supposed to be built from src:kubernetes, but it currently doesn't. Some existing packages already embed them, like https://codesearch.debian.net/search?q=filetype%3Ago+k8s.io%2Fapi&literal=1 Because we thought it's hard to maintain kubernetes package in Debian, meanwhile follow the common practice in pkg-go team. Some new packages are blocked by not having kubernetes libraries. I haven't checked the wnpp list. But recently there's a thread in debian-go@. If you provide k8s.io/* libraries, what about the libraries that k8s.io/* depends? -- Shengjing Zhu
Re: Overinterpretation of DFSG? QR code for receiving donation is non-free???
On Mon, Mar 30, 2020 at 1:54 PM Mo Zhou wrote: >lumin: An image of a QR code wouldn't be the preferred form of > modification. They are usually generated from something. If the file it > was > generated from isn't present and the tool to generate it isn't in Debian, > then > it can't be shipped. Requiring preferred form of modification is one area > where Debian is often stricter than licenses due to DFSG. IMO, the QR picture is preferred form of modification as well as the origin text. 1. There's no info loss if you convert from one to another. 2. I consider a base64 string of a non-readable ascii character a preferred format than the origin character. 3. In this case, the origin url(especially the wechat url is non-readable) is not supporsed to modify. If I want to modify, I just replace the whole image. Then, the question is that the picture is generated by a program not in Debian. But, these pictures are in the documents, not in the program, thus not affect the program's functions. And, I consider this situation just like I use an MS word to produce a .docx file and place it in my source tree. And I don't think I need to strip this docx file if I want to package it in Debian. -- Shengjing Zhu
Re: Overinterpretation of DFSG? QR code for receiving donation is non-free???
On Mon, Mar 30, 2020 at 4:20 PM Paul Wise wrote: > > On Mon, Mar 30, 2020 at 7:53 AM Shengjing Zhu wrote: > > > 1. There's no info loss if you convert from one to another. > > You definitely lose the (presumably non-free) television/game > characters when converting from the original QR codes to plain text. > It's my intention that not cover this part. If the picture in the middle is the reason that makes this QR picture non-free, then I agree. But if the reason is the form of picture or not, then I don't agree. -- Shengjing Zhu
Bug#956909: ITP: golang-github-cilium-ebpf -- eBPF Library for Go
Package: wnpp Severity: wishlist Owner: Shengjing Zhu * Package name: golang-github-cilium-ebpf Version : 0.0~git20200413.48fb86d-1 Upstream Author : Cilium * URL : https://github.com/cilium/ebpf * License : Expat Programming Lang: Go Description : eBPF Library for Go eBPF is a pure Go library that provides utilities for loading, compiling, and debugging eBPF programs. It has minimal external dependencies and is intended to be used in long running processes.
Re: lintian: please downgrade mailing-list-obsolete-in-debian-infrastructure warning
On Fri, Apr 24, 2020 at 5:47 PM gregor herrmann wrote: [...] > > In my personal opinion, this lintian warning/info is not actionable, > also the referred to wiki page at > https://wiki.debian.org/Alioth/MailingListContinuation doesn't say > anything about not using @lists.alioth.debian.org or what to replace > it with, and unless the maintainers of the replacement system tell us > otherwise, I assume this will all keep working fine. > Could this wiki page be more useful? https://wiki.debian.org/Salsa/AliothMigration#Import_mailing_list -- Shengjing Zhu
Re: lintian: please downgrade mailing-list-obsolete-in-debian-infrastructure warning
On Fri, Apr 24, 2020 at 11:44 PM gregor herrmann wrote: [...] > > Could this wiki page be more useful? > > https://wiki.debian.org/Salsa/AliothMigration#Import_mailing_list > > Not really; the lists we are talking about _are_ migrated to > alioth-lists.debian.net which will continue to accept mail for > @lists.alioth.debian.org. > And like Andreas, I see no point in changing the mail addresses in > thousands of packages and various tools and parts of infrastructure. > So your expectation is alioth-lists.d.n will become a long term service. However I read the announcement[1] 2 years ago differently. [1] https://lists.debian.org/debian-devel-announce/2018/01/msg3.html > This is not intended to supercede the advice to make use of other services where appropriate, such as lists.debian.org for eligible lists, tracker.debian.org or salsa, but does enable other lists such as package team maintenance lists, to have a home in _the short term_ Also it writes, > The service will be reviewed for viability and usefulness after one release cycle I'm not sure how the one release cycle is counted. We have released buster since then. And we are close to bullseye now. Probably it's time to start thinking about this. -- Shengjing Zhu
Question for alioth-lists.debian.net status
Hi, (please don't reply to this thread about the lintian issue). Instead of the lintian issue, the real issue which is underneath is, what's the status of alioth-lists.debian.net? Is it still a short term service[1], or the admin plans to make it long term? The difference is whether people should look for a new home. It has been 2 years but there are still many active users on it. And some teams haven't planned to migrate. And another question for DSA is, whether the lists.alioth.debian.org address is expected to work, as long as the alioth-lists.debian.net exists? Thanks. [1] https://lists.debian.org/debian-devel-announce/2018/01/msg00003.html -- Shengjing Zhu
Bug#959012: ITP: golang-github-moby-sys -- Library to parse mount info and mount filesystems
Package: wnpp Severity: wishlist Owner: Shengjing Zhu * Package name: golang-github-moby-sys Version : 0.0~git20200320.6154f11-1 Upstream Author : Kir Kolyshkin * URL : https://github.com/moby/sys * License : Apache-2.0 Programming Lang: Go Description : Library to parse mount info and mount filesystems It provides following Go libraries: . * github.com/moby/sys/mount * github.com/moby/sys/mountinfo Package is prepared at https://salsa.debian.org/go-team/packages/golang-github-moby-sys
Bug#959204: ITP: rootlesskit -- Linux-native "fake root" for rootless containers
Package: wnpp Severity: wishlist Owner: Shengjing Zhu * Package name: rootlesskit Version : 0.9.4-1 Upstream Author : Akihiro Suda * URL : https://github.com/rootless-containers/rootlesskit * License : Apache-2.0 Programming Lang: Go Description : Linux-native "fake root" for rootless containers The purpose of RootlessKit is to run Docker and Kubernetes as an unprivileged user (known as "Rootless mode"), so as to protect the real root on the host from potential container-breakout attacks. . RootlessKit creates user_namespaces(7) and mount_namespaces(7), and executes newuidmap(1)/newgidmap(1) along with subuid(5) and subgid(5). Package will be prepared at http://salsa.debian.org/go-team/packages/rootlesskit
Bug#960798: ITP: golang-google-protobuf -- Go support for Protocol Buffers (second major revision)
Package: wnpp Severity: wishlist Owner: Shengjing Zhu * Package name: golang-google-protobuf Version : 1.23.0 Upstream Author : The Go Authors * URL : https://github.com/protocolbuffers/protobuf-go * License : BSD-3-clause Programming Lang: Go Description : Go support for Protocol Buffers (second major revision) This project hosts the Go implementation for protocol buffers, which is a language-neutral, platform-neutral, extensible mechanism for serializing structured data. The protocol buffer language is a language for specifying the schema for structured data. . This schema is compiled into language specific bindings. . This project provides both a tool to generate Go code for the protocol buffer language, and also the runtime implementation to handle serialization of messages in Go.
Bug#963113: ITP: golang-github-insomniacslk-dhcp -- DHCPv6 and DHCPv4 packet library, client and server written in Go
Package: wnpp Severity: wishlist Owner: Shengjing Zhu * Package name: golang-github-insomniacslk-dhcp Version : 0.0~git20200420.ed3125c-1 Upstream Author : insomniac * URL : https://github.com/insomniacslk/dhcp * License : BSD-3-clause Programming Lang: Go Description : DHCPv6 and DHCPv4 packet library, client and server written in Go DHCPv4 and DHCPv6 decoding/encoding library with client and server code, written in Go. . The library is split into several parts: . * dhcpv6: implementation of DHCPv6 packet, client and server * dhcpv4: implementation of DHCPv4 packet, client and server * netboot: network booting wrappers on top of dhcpv6 and dhcpv4 * iana: several IANA constants, and helpers used by dhcpv6 and dhcpv4 * rfc1035label: simple implementation of RFC1035 labels, used by dhcpv6 and dhcpv4 * interfaces, a thin layer of wrappers around network interfaces
Re: Mass bugs filing: autopkgtest should be marked superficial
On Thu, Sep 17, 2020 at 7:47 PM Paul Gevers wrote: > > Hi all, > > On 17-09-2020 13:38, Raphael Hertzog wrote: > > And consider the case where the bug has been fixed in git but the package > > has not been uploaded because that small change didn't warrant an upload > > of its own. When the FTBFS bug pops up, the fix for the autopkgtest will > > be uploaded. > > For all maintainers that have done so, or something similar, by all > means, you can lower the severity to avoid the autoremoval while marking > the bug as pending. > > > And if it's really something that release managers wants to enforce for > > buster, the severities can be raised say 2 months before the freeze. > > s/buster/bullseye/ ;) Ideally we (the release team) would have a way of > saying "this is severity important as long as testing and unstable are > in sync, but it's not OK to upload a new version without fixing this". > Unfortunately we don't have such an option at this moment. Please adjust > your bugs in accordance with this idea. > It could be one, if someone from RT has time to implement. For example, tag all these bugs with an usertag, then britney to check that. -- Shengjing Zhu
Re: testing excuses: autopkgtest for debian-edu/2.11.2 failed
On Mon, Oct 12, 2020 at 10:53 PM Romain Porte wrote: > > Hello all, > > I recently uploaded a new release of tftp-hpa [1] in order to fix > serveral IPv6-related bugs. However, after 5 days this version is > blocked from going to testing. Checking the testing excuses page [2], I > can see that there is a regression concerning autopkgtest related with > debian-edu. > > As I am not a DD nor DM, it seems that I cannot retrigger the CI. From > the regression logs [3] this error seems to be related to Python version > used in Debian Edu (dependency errors), but this package has nothing to > do with Python. This is the reason why I think a retrigger could help. > > What is the agreed workflow to retrigger such QA jobs for non-DD/DM > contributors? It seems it's automatically re-triggered once a day. https://ci.debian.net/user/britney/jobs?package=debian-edu&trigger=tftp-hpa%2F5.2%2B20150808-1.2&suite%5B%5D=testing Though I don't understand why the change in tftp-hpa causes the consistent failures of debian-edu. -- Shengjing Zhu
Bug#901130: ITP: anbox-modules -- Android kernel driver (binder, ashmem) in DKMS format
Package: wnpp Severity: wishlist Owner: Shengjing Zhu * Package name: anbox-modules-dkms Version : 0.0~git20180608 Upstream Author : Simon Fels * URL : https://github.com/anbox/anbox-modules/ * License : GPL-2 Programming Lang: C Description : Android kernel driver (binder, ashmem) in DKMS format This package contains a out-of-tree version of the core Android kernel functionalities binder and ashmem. . Anbox is a container-based approach to boot a full Android system on a regular GNU/Linux system. . To run Android system in a container, you must have these modules.
Bug#902400: ITP: backward-cpp -- Beautiful stack trace pretty printer for C++
Package: wnpp Severity: wishlist Owner: Shengjing Zhu * Package name: backward-cpp Version : 1.4(upcoming) Upstream Author : François-Xavier Bourlet bomb...@gmail.com * URL : https://github.com/bombela/backward-cpp * License : MIT Programming Lang: C++ Description : Beautiful stack trace pretty printer for C++ Backward spices the stack trace up when C++ programs run into fault. . It can also display code snippets with colored lines when the source files are accessible. . Backward is a header only library. signature.asc Description: PGP signature
Bug#906200: ITP: skalibs -- development files used for building software at skarnet.org
Package: wnpp Severity: wishlist Owner: Shengjing Zhu Control: block 733915 by -1 * Package name: skalibs Version : 2.7.0.0 Upstream Author : Laurent Bercot * URL : https://skarnet.org/software/skalibs/ * License : ISC Programming Lang: C Description : development files used for building software at skarnet.org skalibs is a package centralizing the free software / open source C development files used for building all software at skarnet.org: it contains essentially general-purpose libraries. You will need to install skalibs if you plan to build skarnet.org software. The point is that you won't have to download and compile big libraries, and care about portability issues, every time you need to build a package: do it only once. . skalibs can also be used as a sound basic start for C development. There are a lot of general-purpose libraries out there; but if your main goal is to produce small and secure C code with a focus on system programming, skalibs might be for you. This is used for packaging s6. signature.asc Description: PGP signature
Bug#906250: ITP: execline -- small and non-interactive scripting language
Package: wnpp Severity: wishlist Owner: Shengjing Zhu Control: block 733915 by -1 Control: block -1 by 906200 * Package name: execline Version : 2.5.0.1 Upstream Author : Laurent Bercot * URL : https://skarnet.org/software/execline/ * License : ISC Programming Lang: C Description : small and non-interactive scripting language execline is a (non-interactive) scripting language, like sh; but its syntax is quite different from a traditional shell syntax. The execlineb program is meant to be used as an interpreter for a text file; the other commands are essentially useful inside an execlineb script. . execline is as powerful as a shell: it features conditional loops, getopt-style option handling, filename globbing, and more. Meanwhile, its syntax is far more logic and predictable than the shell's syntax, and has no security issues. This is used for packaging s6. signature.asc Description: PGP signature
Re: Bug#906250: ITP: execline -- small and non-interactive scripting language
Dear -devel, When I try to package execline(a non-interactive shell script)[1], it installs following binaries in default PATH, cd, if, exec, wait, Some facts: * These names are other shells built-in, but in execline these are binaries. * There's no conflict binary name in archive currently. * If I install them in path like /usr/lib/execline/bin, then I need to ensure this path are in everyone's PATH. I find this package has option like `--enable-absolute-paths`, but as a result it doesn't work as I expect. When I contact upstream[2], upstream thinks these binaries should be in default PATH. Any advice with packaging, can I install these binaries in default PATH(like /usr/bin)? [1] https://skarnet.org/software/execline/ [2] https://www.mail-archive.com/skaware@list.skarnet.org/msg01225.html -- Shengjing Zhu
Re: Bug#906250: ITP: execline -- small and non-interactive scripting language
On Mon, Sep 3, 2018 at 4:17 PM Jakub Wilk wrote: > > * Shengjing Zhu , 2018-09-02, 14:42: > >When I try to package execline(a non-interactive shell script)[1], it > >installs following binaries in default PATH, > > > >cd, if, exec, wait, > > Three of them (cd, umask, wait) clash with shell's regular built-in > utilities. POSIX requires them to be exec(2)able[0][1]. Debian doesn't > currently provide standalone executables for them (which is a bug), but > some other distros do. The execline's implementation are of course not > compatible with POSIX, and therefore must not be included within PATH. > Sorry, I can't get your point. Doesn't this mean execline _follows_ POSIX, which makes cd/umask/wait execable? -- Shengjing Zhu GPG Key: 0xCF0E265B7DFBB2F2 Homepage: https://zhsj.me
Re: Bug#906250: ITP: execline -- small and non-interactive scripting language
On Mon, Sep 3, 2018 at 4:43 PM Shengjing Zhu wrote: > > Three of them (cd, umask, wait) clash with shell's regular built-in > > utilities. POSIX requires them to be exec(2)able[0][1]. Debian doesn't > > currently provide standalone executables for them (which is a bug), but > > some other distros do. The execline's implementation are of course not > > compatible with POSIX, and therefore must not be included within PATH. > > > > Sorry, I can't get your point. Doesn't this mean execline _follows_ > POSIX, which makes cd/umask/wait execable? > Oh, you mean the behaviours of execline's cd/umask/wait are not compatible with POSIX. -- Shengjing Zhu GPG Key: 0xCF0E265B7DFBB2F2 Homepage: https://zhsj.me
Re: Browserified copy and DFSG
(drop pkg-javascript-devel) On Sun, Sep 9, 2018 at 12:52 AM Sean Whitton wrote: > > Hello, > > On Sat 08 Sep 2018 at 10:02AM +0800, Paul Wise wrote: > > > On Fri, Sep 7, 2018 at 7:22 PM, Bastien ROUCARIES wrote: > > > >> Ok adding cc @security > >> > >> How will you handle security problem in static > >> (browserified/webpacked) javascript library ? > > > > Same goes for the other languages that do static linking. It would be > > great to have this wiki page updated with some realistic strategies: > > > > https://wiki.debian.org/StaticLinking > > > > IIRC the security team recently flagged Go packages as being > > problematic for security support in the Debian buster release. I guess > > the same will apply to Rust now that Firefox switched to it? > > Hmm, Go looks to be using Built-Using in a way that is not > Policy-compliant. > I just sent this Go team few days ago, https://lists.debian.org/debian-go/2018/09/msg00010.html What I see as a replacement is using X-Go-Built-Using, like the Rust team(which uses X-Cargo-Built-Using). But this needs release-team (and maybe security team) to confirm as mentioned by stapelberg For the security concern about Go in buster, more background is at https://alioth-lists.debian.net/pipermail/pkg-go-maintainers/Week-of-Mon-20180903/023312.html The main issue seems that we can't simply schedule binNMU on security-master. Whatever field is using to record the library statically embedded, the script to filter the outdated binary is simple. -- Shengjing Zhu GPG Key: 0xCF0E265B7DFBB2F2 Homepage: https://zhsj.me
Re: Updating the policy for conflicting binaries names ? [was: Re: Re: New package netgen-lvs with binary /usr/bin/netgen - already taken]
On Sun, Sep 9, 2018 at 2:29 AM Sylvestre Ledru wrote: > > Hello, > > Le 08/09/2018 à 18:39, Sean Whitton a écrit : > > Hello, > > > > On Fri 07 Sep 2018 at 10:10PM +0200, Ruben Undheim wrote: > > > >> However, I think the policy gives us a lot of freedom to choose (it is not > >> very > >> strict in this case). > > > > I don't understand. This seems pretty strict: > > > > Two different packages must not install programs with different > > functionality but with the same filenames. > > > I think the policy should be changed. > It was possible to accommodate that when the archive was a few thousand > packages. > Now that it is much bigger, that floss are everywhere, packages are being > forked, This is indeed annoy nowadays. And on the other hand, many software authors don't take serious on naming, just picking some common words. But I see it's problem in FHS, which has one namespace for binary. > we might want to update the policy to give more flexibility. > For example, in the Rust team, we have been discussing about packaging fd (a > find alternative developed using rust [1]). > We are planning to install it in /usr/bin/fd .. but this conflicts with > something completely different, fdclone a clone > of fd, a MS-DOS file browser... > While this is probably fun, with a declining popcon (104 today), and no > upstream release since 2013, It's not true, at least I find the latest release is last month[1] [1] http://www.unixusers.net/ml/FDclone-users/201808/msg0.html (in Japanese) -- Shengjing Zhu
Re: gbp import-orig has defeated me
On Tue, Oct 2, 2018 at 10:51 AM Steve Robbins wrote: > > Hi, > > I would like to update the googletest salsa repo [1] with upstream 1.8.1. So > I downloaded the tarball and ran "gbp import-orig" on it. That appeared to > work, but "gbp buildpackage" fails with > > dpkg-source: error: aborting due to unexpected upstream changes ... > > from the diffs, my guess is there is some line ending issue. I've pushed > everything to salsa repo. Hoping someone here can take a look and point me in > the right direction. > I think you have configured your git to auto convert the line ending when commit. In the pristine-tar tarball, $ file googletest-release-1.8.1/googlemock/msvc/2005/gmock.sln googletest-release-1.8.1/googlemock/msvc/2005/gmock.sln: UTF-8 Unicode (with BOM) text, with CRLF line terminators In your master and upstream branch $ file googletest-1.8.1/googlemock/msvc/2005/gmock.sln googletest-1.8.1/googlemock/msvc/2005/gmock.sln: UTF-8 Unicode (with BOM) tex I import the orig tarball in my env, these files are CRLF in my git tree. I'm not sure what git config influences this, but maybe core.eol, core.autocrlf, core.safecrlf. I'm just using the default values, at least my `git config --list` output didn't show anything related. -- Shengjing Zhu
Re: Problem sending my key to keyring.debian.org
On Wed, Oct 3, 2018 at 9:28 AM Joseph Herlant wrote: > > Hi, > > On Tue, Oct 2, 2018 at 6:10 PM Seth Arnold wrote: > > Two thoughts: first, give it another try. I was able to refresh my > > keyring using the debian keyserver a few seconds ago: > > > > $ gpg --refresh-keys --keyserver keyring.debian.org > > gpg: refreshing 229 keys from hkp://keyring.debian.org > > ... > > gpg: new signatures: 160 > > ... > > Ok, so that's really a problem on my end. I've been having this issue > since I started trying to update it yesterday and still have now. > Tried 4 or 5 times during the day, same issue. > Same error while trying to refresh. > Have you succeed? You may debug with, add following line to ~/.gnupg/dirmngr.conf log-file /tmp/dirmngr.log debug-level advanced debug-all then run `gpgconf --kill dirmngr`, send/recv it again, you will see the log in /tmp/tmp/dirmngr.log This method applies to other gpg components. -- Shengjing Zhu
Bug#864300: ITP: fcitx-autoeng-ng -- Fcitx autoeng module for Sogou pinyin
Package: wnpp Severity: wishlist Owner: Shengjing Zhu * Package name: fcitx-autoeng-ng Version : 0.1.1~git20150311 Upstream Author : Gao Qunkai * URL : https://github.com/sogoupinyin/fcitx-punc-ng/ * License : GPL-2 Programming Lang: C Description : Fcitx autoeng module for Sogou pinyin fcitx-module-autoeng-ng is a module for Sogou pinyin This package will be inside pkg-ime team, and Aron Xu agreed to sponsor. signature.asc Description: PGP signature
Bug#864303: ITP: fcitx-fullwidthchar-enhance -- Fcitx fullwidthchar enhance module for Sogou pinyin
Package: wnpp Severity: wishlist Owner: Shengjing Zhu * Package name: fcitx-fullwidthchar-enhance Version : 0.0~git20150311 Upstream Author : Gao Qunkai * URL : https://github.com/sogoupinyin/fcitx-fullwidthchar-enhance * License : GPL-2 Programming Lang: C Description : Fcitx fullwidthchar enhance module for Sogou pinyin fcitx-module-fullwidthchar is a module for Sogou pinyin This package will be inside pkg-ime team, and Aron Xu agreed to sponsor. signature.asc Description: PGP signature
Bug#864304: ITP: fcitx-punc-ng -- Fcitx punc module for Sogou pinyin
Package: wnpp Severity: wishlist Owner: Shengjing Zhu * Package name: fcitx-punc-ng Version : 0.1.1~git20161101 Upstream Author : Gao Qunkai * URL : https://github.com/sogoupinyin/fcitx-punc-ng/ * License : GPL-2 Programming Lang: C Description : Fcitx punc module for Sogou pinyin fcitx-module-punc-ng is a module for Sogou pinyin This package will be inside pkg-ime team, and Aron Xu agreed to sponsor. signature.asc Description: PGP signature
Bug#864828: ITP: sogoupinyin-installer -- Sogou Pinyin Input Method installer
Package: wnpp Severity: wishlist Owner: Shengjing Zhu * Package name: sogoupinyin-installer Version : 2.1.0.0086~1 Upstream Author : Shengjing Zhu * URL : https://pinyin.sogou.com/linux/ * License : GPL-3 Programming Lang: Shell Description : Sogou Pinyin Input Method installer Based on web search engine technology, Sogou Pinyin input method is the next-generation input method designed for Internet users. As it is backed with search engine technology, user input method can be extremely fast, and it is much more advanced than other input method engines in terms of the volume of the vocabulary database and its accuracy. Sogou input method is the most popular input methods in China, and Sogou promises it will always be free of charge. . Note: this package does not contain any software from Sogou Inc. This package does however contain a script to download and install Sogou Pinyin. Please also include as much relevant information as possible. For example, consider answering the following questions: - why is this package useful/relevant? is it a dependency for another package? do you use it? if there are other packages providing similar functionality, how does it compare? Sogou Pinyin is popular among Chinese users. This package will help people install it. - how do you plan to maintain it? inside a packaging team (check list at https://wiki.debian.org/Teams)? are you looking for co-maintainers? do you need a sponsor? This package will be maintained in pkg-ime team. signature.asc Description: PGP signature
Bug#867524: ITP: elvish -- Friendly and expressive Unix shell
Package: wnpp Severity: wishlist Owner: Shengjing Zhu * Package name: elvish Version : 0.9 Upstream Author : Qi Xiao * URL : https://elvish.io/ * License : BSD-2-Clause Programming Lang: Go Description : Friendly and expressive Unix shell Elvish is a cross-platform shell suitable for both interactive use and scripting. It features a full-fledged, non-POSIX-shell programming language with advanced features like namespacing and anonymous functions, and a powerful, fully programmable user interface that works well out of the box. This package will be inside pkg-go team. I will need sponsor to upload. signature.asc Description: PGP signature
Bug#867525: ITP: golang-github-xiaq-persistent -- Persistent data structure in Go
Package: wnpp Severity: wishlist Owner: Shengjing Zhu * Package name: golang-github-xiaq-persistent Version : 0.0~git20170614.0.06adb7b-1 Upstream Author : Qi Xiao * URL : https://github.com/xiaq/persistent * License : Eclipse Public License 1.0 Programming Lang: Go Description : Persistent data structure in Go This is a Go clone of Clojure's persistent data structures. This a dependency of elvish which I intend to package, #867524. It will be inside pkg-go team. I will need sponsor to upload. signature.asc Description: PGP signature
Bug#869368: ITP: golang-github-gin-contrib-sse -- Server-Sent Events implementation in Go
Package: wnpp Severity: wishlist Owner: Shengjing Zhu Control: block 865134 by -1 * Package name: golang-github-gin-contrib-sse Version : 0.0~git20170109.0.22d885f-1 Upstream Author : Manuel Martínez-Almeida * URL : https://github.com/gin-contrib/sse * License : Expat Programming Lang: Go Description : Server-Sent Events implementation in Go Server-sent events (SSE) is a technology where a browser receives automatic updates from a server via HTTP connection. The Server-Sent Events EventSource API is standardized as part of HTML5 by the W3C. Please also include as much relevant information as possible. For example, consider answering the following questions: - why is this package useful/relevant? is it a dependency for another package? do you use it? if there are other packages providing similar functionality, how does it compare? This a dependency of golang-github-gin-gonic-gin #865134 - how do you plan to maintain it? inside a packaging team (check list at https://wiki.debian.org/Teams)? are you looking for co-maintainers? do you need a sponsor? I will package this inside pkg-go team and I need sponsor to upload. signature.asc Description: PGP signature
Bug#869369: ITP: golang-gopkg-go-playground-validator.v8 -- Go Struct and Field validation (version 8.x)
Package: wnpp Severity: wishlist Owner: Shengjing Zhu Control: block 865134 by -1 X-Debbugs-CC: pkg-go-maintain...@lists.alioth.debian.org * Package name: golang-gopkg-go-playground-validator.v8 Version : 8.18.1-1 Upstream Author : Dean Karn * URL : https://github.com/go-playground/validator * License : Expat Programming Lang: Go Description : Go Struct and Field validation (version 8.x) Package validator implements value validations for structs and individual fields based on tags. . It has the following unique features: * Cross Field and Cross Struct validations by using validation tags or custom validators. * Slice, Array and Map diving, which allows any or all levels of a multidimensional field to be validated. * Handles type interface by determining it's underlying type prior to validation. * Handles custom field types such as sql driver Valuer see Valuer * Alias validation tags, which allows for mapping of several validations to a single tag for easier defining of validations on structs * Extraction of custom defined Field Name e.g. can specify to extract the JSON name while validating and have it available in the resulting FieldError Please also include as much relevant information as possible. For example, consider answering the following questions: - why is this package useful/relevant? is it a dependency for another package? do you use it? if there are other packages providing similar functionality, how does it compare? This a dependency of golang-github-gin-gonic-gin #865134 - how do you plan to maintain it? inside a packaging team (check list at https://wiki.debian.org/Teams)? are you looking for co-maintainers? do you need a sponsor? I will package this inside pkg-go team and I need sponsor to upload. signature.asc Description: PGP signature
Bug#869370: ITP: golang-gopkg-go-playground-assert.v1 -- Basic Assertion Library used along side native go testing
Package: wnpp Severity: wishlist Owner: Shengjing Zhu Control: block 869369 by -1 X-Debbugs-CC: pkg-go-maintain...@lists.alioth.debian.org * Package name: golang-gopkg-go-playground-assert.v1 Version : 1.2.1-1 Upstream Author : Dean Karn * URL : https://github.com/go-playground/assert * License : Expat Programming Lang: Go Description : Basic Assertion Library used along side native go testing Package assert is a Basic Assertion library used along side native go testing, with building blocks for custom assertions. Please also include as much relevant information as possible. For example, consider answering the following questions: - why is this package useful/relevant? is it a dependency for another package? do you use it? if there are other packages providing similar functionality, how does it compare? This a dependency of golang-gopkg-go-playground-validator.v8 - how do you plan to maintain it? inside a packaging team (check list at https://wiki.debian.org/Teams)? are you looking for co-maintainers? do you need a sponsor? I will package this inside pkg-go team and I need sponsor to upload. signature.asc Description: PGP signature
Bug#869650: ITP: golang-github-hashicorp-go-rootcerts -- Functions for loading root certificates for TLS connections.
Package: wnpp Severity: wishlist Owner: Shengjing Zhu * Package name: golang-github-hashicorp-go-rootcerts Version : 0.0~git20160503.0.6bb64b3-1 Upstream Author : HashiCorp * URL : https://github.com/hashicorp/go-rootcerts * License : MPL-2.0 Programming Lang: Go Description : Functions for loading root certificates for TLS connections. Go's standard library crypto/tls provides a common mechanism for configuring TLS connections in tls.Config. The RootCAs field on this struct is a pool of certificates for the client to use as a trust store when verifying server certificates. . This library contains utility functions for loading certificates destined for that field, as well as one other important thing: . When the RootCAs field is nil, the standard library attempts to load the host's root CA set. This behavior is OS-specific, and the Darwin implementation contains a bug that prevents trusted certificates from the System and Login keychains from being loaded This library contains Darwin-specific behavior that works around that bug. I'm intend to package this inside pkg-go team, and I need sponsor to upload. This library is a new dependency of golang-github-hashicorp-atlas-go-dev, which is needed for new packer(https://bugs.debian.org/865337). signature.asc Description: PGP signature
Bug#869757: ITP: golang-github-biogo-hts -- biogo high throughput sequencing repository
Package: wnpp Severity: wishlist Owner: Shengjing Zhu * Package name: golang-github-biogo-hts Version : 1.0.1+git20170705.18.8bf89f2-1 Upstream Author : bíogo * URL : https://github.com/biogo/hts * License : BSD-3-clause Programming Lang: Go Description : biogo high throughput sequencing repository SAM and BAM handling for the Go language. . bíogo/hts provides a Go native implementation of the SAM specification for SAM and BAM alignment formats commonly used for representation of high throughput genomic data, the BAI, CSI and tabix indexing formats, and the BGZF blocked compression format. The bíogo/hts packages perform parallelized read and write operations and are able to cache recent reads according to user-specified caching methods. The bíogo/hts APIs have been constructed to provide a consistent interface to sequence alignment data and the underlying compression system in order to aid ease of use and tool development. I intend to package this inside pkg-go team. This library is a dependency of packer. I need sponsor to upload. Regards, Shengjing Zhu signature.asc Description: PGP signature
Bug#869819: ITP: golang-github-denverdino-aliyungo -- Go SDK for Aliyun (Alibaba Cloud)
Package: wnpp Severity: wishlist Owner: Shengjing Zhu * Package name: golang-github-denverdino-aliyungo Version : 0.0~git20170721.0.80ceb80-1 Upstream Author : Li Yi * URL : https://github.com/denverdino/aliyungo * License : Apache-2.0 Programming Lang: Go Description : Go SDK for Aliyun (Alibaba Cloud) This is an unofficial Go SDK for Aliyun Services. . Following services are supported: * ecs: Elastic Compute Service * oss: Open Storage Service * slb: Server Load Balancer * dns: DNS * sls: Logging Service * ram: Resource Access Management * rds: Relational Database Service * cms: Cloud Monitor Service * cs: Container Service * sts: Security Token Service * dm: Direct Mail * sms: Short Message Service * push: Cloud Mobile Push * opensearch: OpenSearch * mq: Message Queue * nas: Network Attached Storage * common: Common libary of Aliyun Go SDK * util: Utility helpers It's the new dependency for packer. I will package this inside pkg-go team and need sponsor as well. Regards, Shengjing Zhu signature.asc Description: PGP signature
Bug#869863: ITP: golang-github-aliyun-aliyun-oss-go-sdk -- Alibaba Cloud OSS SDK for Go
Package: wnpp Severity: wishlist Owner: Shengjing Zhu * Package name: golang-github-aliyun-aliyun-oss-go-sdk Version : 1.5.0 Upstream Author : Yubin Bai and Hǎiliàng Wáng * URL : https://github.com/aliyun/aliyun-oss-go-sdk * License : Apache-2.0 Programming Lang: Go Description : Alibaba Cloud OSS SDK for Go This Go SDK is based on the official APIs of Alibaba Cloud OSS. . Alibaba Cloud Object Storage Service (OSS) is a cloud storage service provided by Alibaba Cloud, featuring massive capacity, security, a low cost, and high reliability. . The OSS can store any type of files and therefore applies to various websites, development enterprises and developers. . With this SDK, you can upload, download and manage data on any app anytime and anywhere conveniently. It's the new dependency for packer. I will package this inside pkg-go team and need sponsor as well. Regards, Shengjing Zhu signature.asc Description: PGP signature
