Re: How to contribute ?
Hi Maxime,
On Tue, Dec 21, 2021 at 07:47:47PM +0100, Maxime Lombard wrote:
>Hello,
>
>I'm an user of Debian since 10 years ago and it's only now that i decide
>to help to packaging.
>I send this email about wine and wine-development package which are not
>updated since a very long time.
>The last wine stable version on Sid is the 5.0 and development version is
>6.0+repack. Currently, the wine source code is frozen and the new stable
>version 7.0 will release next month.
>--> I sent email to Michael Gilbert (without answer from him) and open a
>bug report recently to update package.
>Same thing with vkd3d package 1.2 which is still in "experimental" since a
>long time too.
>I think it's not in Unstable because the test fail with mesa-vulkan-driver
>>= 21 (see changelog)
>--> I open a bug report upstream about this failure (see
>https://bugs.winehq.org/show_bug.cgi?id=52248). Is it possible to build
>the package without to do test (set --disable-tests to configure) ?
>Nowadays, the last package of wine-development was uploaded ~6 months ago.
>More bugs report opened the last months have no answer from Maintainer
>(999753, 995580), same thing with vkd3d bug (994186, 993570)
>I packaged myself vkd3d 1.2-7 and wine-development 7.0~rc2 and all works
>correctly.
>I updated debian folder for wine to prepare the next Stable version.
>My question is, how to contribute and hope to have updated version of this
>package in Debian since I am a novice ?
https://www.debian.org/devel/join/ should help as a general introduction
on how to contribute.
Assuming you built your updated wine package by getting the existing
wine packages and updating them for the new upstream version (your mail
suggests that, but I'm not sure), you have a few options.
First, you can send a patch to the Debian BTS. The easiest way to
accomplish this is by way of the "debdiff" program in the "devscripts"
package; see its man page for details. Alternatively, you can publish
your build directory in a git repository somewhere, possibly on
salsa.debian.org, and let the wine developers (who gather on the
debian-w...@lists.debian.org mailinglist) know.
If you don't get any feedback from the wine maintainers, you should
probably contact the debian mentors mailinglist (link on the join page
above) to request more help.
Hope this helps,
--
w@uter.{be,co.za}
wouter@{grep.be,fosdem.org,debian.org}
Bug#1002858: ITP: golang-github-lestrrat-go-strftime -- fast strftime implementation for Go
Package: wnpp Severity: wishlist Owner: Stephen Kitt X-Debbugs-Cc: debian-devel@lists.debian.org * Package name: golang-github-lestrrat-go-strftime Version : 1.0.5 Upstream Author : Daisuke Maki * URL : https://github.com/lestrrat-go/strftime * License : MIT Programming Lang: Go Description : fast strftime implementation for Go This is a Go implementation of strftime, optimised for pattern re-use, and with support for as many conversion specifications as possible. It aims for POSIX compliance while still including widely-used non-POSIX format specifications such as "%f" or "%L" for milliseconds. This is required for the new Go version of Miller. I’ll be asking to join the Go packaging team to maintain this there.
Bug#1002859: ITP: golang-github-lestrrat-go-envload -- environment variable manipulation library
Package: wnpp Severity: wishlist Owner: Stephen Kitt X-Debbugs-Cc: debian-devel@lists.debian.org * Package name: golang-github-lestrrat-go-envload Version : 0.0~20180221 Upstream Author : Daisuke Maki * URL : https://github.com/lestrrat-go/envload * License : MIT Programming Lang: Go Description : environment variable manipulation library This library provides functions to store, modify, and restore environment variables. This is useful for example to temporarily change values of environment variables for tests, as doable for example with Perl 5’s local variables. This is required for lestrrat-go-strftime. I’m planning on maintaining this within the Go packaging team.
Re: Porter roll call for Debian Bookworm
Hello, 2021-10-02 11:57 Graham Inggs: Hi We are doing a roll call for porters of all prospective release architectures. If you are an active porter behind one of these architectures [1] and intend to continue for the development cycle of Debian Bookworm (est. release mid-2023), please respond with a signed email containing the following before Saturday, January 1, 2022: * Which architectures are you committing to be an active porter for? * Please describe recent relevant porter contributions. * Are you running/using Debian testing or sid on said port(s)? * Are you testing/patching d-i for the port(s)? Please note that no response is required for amd64 because our toolchain maintainers are happy to support amd64 as-is. Feel free to use the following template as your reply: [...] I have been working on the riscv64 port since 2015 or so, even if the successful and definitive initial bootstrap only happened in 2018. Some people joined from the start and more people joined lately, but I have a keen interest in pushing this port further :) Thus, I am an active porter for riscv64 and I intend to continue for the development cycle of Debian Bookworm (est. release mid-2023). In the last year or two the contributions were a bit diminished for a variety of issues (especially in the realm of attending bugs and looking at specific issues of packages and submitting patches), and will continue to be this way for a while, but I hope to pick-up pace again during this development cycle. For riscv64, I plan to: - maintain buildds --- I have set-up or was involved in getting hardware and necessary resources and setting up most of the buildds of the architecture so far, and I plan to continue doing this in the foreseeable future - maintain/provide hardware for (or assist with) automated tests on ci.d.n, jenkins.d.n (etc.) --- I though about doing do this in the past, I think that it's a good idea to do this if new suitable hardware becomes available, but there's been scarcity until now. - run a Debian testing or unstable system on port that I use regularly - test (most|all) packages on this architecture --- not sure if saying (most|all) is realistic with the current size of the archive, but I hope to use regularly the most important packages by using them on real systems. The following I will try to do as more time becomes available, and paying more attention if this port is considered to be supported for bookworm and becoming a more official architecture (but other people with interest in riscv64 are also working on these areas): - fix toolchain issues - triage arch-specific bugs - fix arch-related bugs - triage d-i bugs - test d-i regularly - fix d-i bugs/issues I am a DD. -- Manuel A. Fernandez Montecelo signature.asc Description: PGP signature
Re: etc/resolvconf/update-libc.d/ equivalent for systemd-resolved
On Thursday, December 30, 2021 2:35:56 AM EST Bastian Blank wrote: > On Wed, Dec 29, 2021 at 04:35:22PM -0500, Scott Kitterman wrote: > > The postfix package ships a script in /etc/resolvconf/update-libc.d/ to > > restart postfix when resolv.conf is updated. As far as I know, that > > still works if the resolvconf package is installed, but if not (i.e. > > Debian default), what's the equivalent? Does systemd-resolved have an > > equivalent? Should users that want this functionality install > > resolvconf? > > Why do you need to restart services on resolv.conf changes? The libc > resolver takes care of it by re-reading the file after it changed. Because postfix doesn't. Also, the copy of the file in the chroot needs to be updated. Scott K signature.asc Description: This is a digitally signed message part.
Re: etc/resolvconf/update-libc.d/ equivalent for systemd-resolved
On Thursday, December 30, 2021 2:36:45 AM EST Bastian Blank wrote: > On Thu, Dec 30, 2021 at 01:48:49AM +, Scott Kitterman wrote: > > It does. My question is on the other end of the problem. Once > > resolv.conf is updated, how do I trigger an action for another package? > > In this case it's copy the updated resolv.conf into the chroot and > > restart postfix. I know how to do everything except for the trigger. > Maybe you should stop supporting the non-standard chroot configuration? What do you mean by non-standard? It's true that the upstream default is now not in the chroot, but it's totally a configuration supported by upstream. How would you suggest handling upgrades? I've no idea how to determine if an installation is chrooted because the administrator wanted it chrooted or if it's merely because that's been the default in Debian for over 20 years. I believe I can solve this problem by adding Recommends: resolvconf if that's the only way. I had hoped there would be some "modern" way to do it from within Debian's default package set. Scott K signature.asc Description: This is a digitally signed message part.
Re: etc/resolvconf/update-libc.d/ equivalent for systemd-resolved
Scott Kitterman writes: > I believe I can solve this problem by adding Recommends: resolvconf if that's > the only way. I had hoped there would be some "modern" way to do it from > within Debian's default package set. Funny. That seems to have been the solution to this bug almost 20 years ago too: https://bugs.debian.org/154669 Bjørn
Re: etc/resolvconf/update-libc.d/ equivalent for systemd-resolved
Scott Kitterman writes: > I believe I can solve this problem by adding Recommends: resolvconf if that's > the only way. I had hoped there would be some "modern" way to do it from > within Debian's default package set. I hope that wouldn't interfere with an enabled systemd-resolved, otherwise that seems likely to cause some breakage. d
Re: etc/resolvconf/update-libc.d/ equivalent for systemd-resolved
On Thursday, December 30, 2021 8:50:48 AM EST Bjørn Mork wrote: > Scott Kitterman writes: > > I believe I can solve this problem by adding Recommends: resolvconf if > > that's the only way. I had hoped there would be some "modern" way to do > > it from within Debian's default package set. > > Funny. That seems to have been the solution to this bug almost 20 years > ago too: https://bugs.debian.org/154669 Yes. Exactly. I'm not sure where we lost it and I'll put it back if that's the most correct solution, but it seems suboptimal since another package is now managing resolv.conf in our default install. Scott K signature.asc Description: This is a digitally signed message part.
Re: etc/resolvconf/update-libc.d/ equivalent for systemd-resolved
On Thursday, December 30, 2021 9:01:07 AM EST David Bremner wrote: > Scott Kitterman writes: > > I believe I can solve this problem by adding Recommends: resolvconf if > > that's the only way. I had hoped there would be some "modern" way to do > > it from within Debian's default package set. > > I hope that wouldn't interfere with an enabled systemd-resolved, > otherwise that seems likely to cause some breakage. I would too. It would be nice if systemd-resolved had some mechanism to support this kind of functionality. If you're going to replace resolvconf, then you ought to actually replace it. Scott K signature.asc Description: This is a digitally signed message part.
Re: etc/resolvconf/update-libc.d/ equivalent for systemd-resolved
On Thu, Dec 30, 2021 at 08:26:07AM -0500, Scott Kitterman wrote: > > Maybe you should stop supporting the non-standard chroot configuration? > What do you mean by non-standard? It's true that the upstream default is now > not in the chroot, but it's totally a configuration supported by upstream. chroot is non-standard configuration in Postfix and was discuoraged for a lot of years before that. Exactly because of problems like that. > How would you suggest handling upgrades? I've no idea how to determine if an > installation is chrooted because the administrator wanted it chrooted or if > it's merely because that's been the default in Debian for over 20 years. You error out if postconf -M show chroot enabled. > I believe I can solve this problem by adding Recommends: resolvconf if that's > the only way. I had hoped there would be some "modern" way to do it from > within Debian's default package set. No, it can't be solved this way, as resolvconf and systemd-resolved do not communicate. Bastian -- The more complex the mind, the greater the need for the simplicity of play. -- Kirk, "Shore Leave", stardate 3025.8
Re: etc/resolvconf/update-libc.d/ equivalent for systemd-resolved
On 29.12.21 22:35, Scott Kitterman wrote: The postfix package ships a script in /etc/resolvconf/update-libc.d/ to restart postfix when resolv.conf is updated. Why copy the file? Couldn't you bind mount it into the chroot so you don't need to update it everytime the host /etc/resolv.conf changes? OpenPGP_signature Description: OpenPGP digital signature
Re: etc/resolvconf/update-libc.d/ equivalent for systemd-resolved
On Dec 30, Scott Kitterman wrote: > I would too. It would be nice if systemd-resolved had some mechanism to > support this kind of functionality. If you're going to replace resolvconf, > then you ought to actually replace it. systemd-resolved is supposed to forward queries to the upstream resolver and always be available on 127.0.0.53, so what does actually change in resolve.conf when using it? -- ciao, Marco signature.asc Description: PGP signature
Re: etc/resolvconf/update-libc.d/ equivalent for systemd-resolved
On Thu, Dec 30, 2021 at 09:19:35PM +0100, Marco d'Itri wrote: > systemd-resolved is supposed to forward queries to the upstream resolver > and always be available on 127.0.0.53, so what does actually change in > resolve.conf when using it? Only if you are using the stub resolver. systemd-resolved can also update a resolv.conf with the real resolver. Okay, you loose a lot of flexibility then, because resolv.conf can't redirect domains to different name servers, but you can do that. Bastian -- ... bacteriological warfare ... hard to believe we were once foolish enough to play around with that. -- McCoy, "The Omega Glory", stardate unknown
Re: WNPP/ITP/... for Amazon SDK for C++ ?
On 2021-12-26 18:08 -0600, Dirk Eddelbuettel wrote: > > Does anybody know where we are with respect to the WNPPs / ITPs / ... on the > Amazon SDK for C++? > > I have a package that could take advantage of this if it were packaged, and I > am sure a number of other packages are in a similar situation given how > pervasive AWS use is. I don't know anything about the state of this, but am in the same place, in that I am packaging something that uses awsSDK pieces, specifically tensorflow which wants aws-cpp-sdk-core. > FWIW I have packaged _subsets_ of the C++ SDK informally for my own use (also > at Launchpad) but I don't think I have the time and energy to take this on as > another package. Which bits have you done? They may or may not be sufficient to satisfy tensorflow. I too, am not bursting to add large packages that I don't use (or even properly know what they are) to my collection of responsibilities, but I can spend work time on helping get this going so I don't mind mucking in on some packaging work. Wookey -- Principal hats: Linaro, Debian, Wookware, ARM http://wookware.org/ signature.asc Description: PGP signature
Work-needing packages report for Dec 31, 2021
The following is a listing of packages for which help has been requested through the WNPP (Work-Needing and Prospective Packages) system in the last week. Total number of orphaned packages: 1242 (new: 2) Total number of packages offered up for adoption: 184 (new: 0) Total number of packages requested help for: 60 (new: 0) Please refer to https://www.debian.org/devel/wnpp/ for more information. The following packages have been orphaned: bino (#1002720), orphaned 2 days ago Description: 3D video player Installations reported by Popcon: 112 Bug Report URL: https://bugs.debian.org/1002720 pymongo (#1002583), orphaned 6 days ago Reverse Depends: changeme lava-dev python3-aodh python3-biomaj3 python3-biomaj3-user python3-bson-ext python3-ceilometer python3-django-horizon python3-freezer python3-gridfs (8 more omitted) Installations reported by Popcon: 1295 Bug Report URL: https://bugs.debian.org/1002583 1240 older packages have been omitted from this listing, see https://www.debian.org/devel/wnpp/orphaned for a complete list. No new packages have been given up for adoption, but a total of 184 packages are awaiting adoption. See https://www.debian.org/devel/wnpp/rfa_bypackage for a complete list. For the following packages help is requested: apache2 (#910917), requested 1174 days ago Description: Apache HTTP Server Reverse Depends: apache2 apache2-ssl-dev apache2-suexec-custom apache2-suexec-pristine backuppc bfh-container-server courier-webadmin cvsweb debbugs-web doc-central (137 more omitted) Installations reported by Popcon: 97241 Bug Report URL: https://bugs.debian.org/910917 aufs (#963191), requested 558 days ago Description: driver for a union mount for Linux filesystems Reverse Depends: fsprotect Installations reported by Popcon: 9614 Bug Report URL: https://bugs.debian.org/963191 autopkgtest (#846328), requested 1856 days ago Description: automatic as-installed testing for Debian packages Reverse Depends: debci-worker sbuild-qemu Installations reported by Popcon: 1243 Bug Report URL: https://bugs.debian.org/846328 balsa (#642906), requested 3749 days ago Description: An e-mail client for GNOME Reverse Depends: balsa Installations reported by Popcon: 653 Bug Report URL: https://bugs.debian.org/642906 cargo (#860116), requested 1724 days ago Description: Rust package manager Reverse Depends: dh-cargo rust-all Installations reported by Popcon: 2730 Bug Report URL: https://bugs.debian.org/860116 courier (#978755), requested 364 days ago Description: Courier mail server Reverse Depends: courier-faxmail courier-filter-perl courier-imap courier-ldap courier-mlm courier-mta courier-pcp courier-pop courier-webadmin couriergrey (3 more omitted) Installations reported by Popcon: 900 Bug Report URL: https://bugs.debian.org/978755 cron (#984736), requested 298 days ago Description: new maintainer need Reverse Depends: apticron autolog backintime-common btrfsmaintenance buildd checksecurity clamtk cricket email-reminder exim4-base (20 more omitted) Installations reported by Popcon: 205711 Bug Report URL: https://bugs.debian.org/984736 cyrus-imapd (#921717), requested 1056 days ago Description: Cyrus mail system - IMAP support Reverse Depends: cyrus-admin cyrus-caldav cyrus-clients cyrus-dev cyrus-imapd cyrus-murder cyrus-nntpd cyrus-pop3d cyrus-replication Installations reported by Popcon: 413 Bug Report URL: https://bugs.debian.org/921717 debtags (#962579), requested 568 days ago Description: Debian Package Tags support tools Reverse Depends: packagesearch Installations reported by Popcon: 1474 Bug Report URL: https://bugs.debian.org/962579 dee (#831388), requested 1994 days ago Description: model to synchronize mutiple instances over DBus Reverse Depends: dee-tools gir1.2-dee-1.0 gir1.2-unity-7.0 libdee-dev libunity-dev libunity-protocol-private0 libunity-tools libunity9 zeitgeist-core Installations reported by Popcon: 40349 Bug Report URL: https://bugs.debian.org/831388 developers-reference (#759995), requested 2679 days ago Description: guidelines and information for Debian developers Installations reported by Popcon: 3721 Bug Report URL: https://bugs.debian.org/759995 devscripts (#800413), requested 2284 days ago Description: scripts to make the life of a Debian Package maintainer easier Reverse Depends: apt-build apt-listdifferences aptfs arriero brz-debian buildd debci debian-builder d
Re: WNPP/ITP/... for Amazon SDK for C++ ?
Hi Dirk, On Mon, Dec 27, 2021 at 08:10:50AM -0600, Dirk Eddelbuettel wrote: > My (very informal) packaging has always been in the open (but on GitHub). A > possible first step might be to review the added files in debian/ and in a > first pass edit out all references to 'informal' or 'unofficial' packaging > and making them more official in the cloud team repo -- which I presume is on > salsa? If you or others want to look, I have this currently at github.com in > > eddelbuettel/pkg-aws-c-common common C layer > eddelbuettel/pkg-aws-checksumschecksum for transport > eddelbuettel/pkg-aws-c-event-stream another C layer > eddelbuettel/pkg-aws-sdk-cpp-only-s3 C++ SDK subset for S3 I did some work on aws-c-common & aws-c-event-stream from a PoC of packaging for awscli v2. Details are in #966573, message 43 [1]. So far, I haven't uploaded any of this. The AWS SDK now requires their own crypto & tls implementations. The cloud team discussed this a while back, no one found that responsibility very attractive. Still, we'll want awscli v2 eventually. > The last repo is the one that is 'incomplete' as I skipped everything not > need by my use case of accessing s3 programmatically from other C++ code. > >From a casual look at another C++ project I noticed that it had the same > subset so this may make sense. It would allow us to proceed and start with > the subset and add as needed (as opposed to be overwhelmed by 'all of it'). I'd be worried about confusing users who expect to have the whole SDK available. But as long as the packages only ship static libraries, I don't see how it would cause actual issues. Ross [1] - https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=966573#43
