On Mon, 21 Nov 2022 at 21:30, Helmut Grohne wrote:
> It is known to build and run on some architectures.
Excellent point! I already mitigate this risk by building most of my
(upstream) packages on macOS and Windows as well as GNU/Linux, but still.
And if you decide to vendor gnulib anyway, do
On Wed, 16 Nov 2022 at 09:47, Helmut Grohne wrote:
>
> I think bug fixes is something you'd want. API changes less so.
>
My point was that there are frequently bug fixes and API changes since
whatever version of gnulib is packaged in Debian.
> Also note that gnulib is a piece that regularly fa
Thanks very much to all those who have given advice, offered help, and
spelt out some of the background of gnulib use in Debian.
The summary seems to be that using gnulib in its usual way to embed files
used by APIs a package uses is acceptable.
--
https://rrt.sc3d.org
I am the upstream maintainer of libpaper (which used to be a pure-Debian
project), and also a Debian Maintainer trying to get a new version of
libpaper into Debian. (It involves an API/ABI transition, from the current
libpaper1 to libpaper2.)
Bastian Germann (b...@debian.org) is kindly helping wit
On Fri, 4 Feb 2022 at 14:30, Reuben Thomas wrote:
>
> Having just now got the new Debian packaging building without error, I
> shall now follow the ITS procedure and see what happens!
>
I have waited 8 days since posting debdiffs, and had no response, so I've
now filed an
On Sat, 1 Jan 2022 at 22:34, Reuben Thomas wrote:
> On Sat, 1 Jan 2022 at 20:43, Pierre-Elliott Bécue wrote:
> >
> > I suggest this path:
> >
> > Send bug reports with your debdiff proposals for each package. If 8 days
> > after you get no reply from the ma
On Sat, 1 Jan 2022 at 20:55, Wookey wrote:
>
> Hi Rebuen. I helped you with the last libpaper refurbishment in
> 2012-2014. Happy to do that again, although as people have pointed out
> complete rewrites are not really NMU material and we should follow the
> salvage process.
>
> Well done for gett
On Sat, 1 Jan 2022 at 20:43, Pierre-Elliott Bécue wrote:
>
> I suggest this path:
>
> Send bug reports with your debdiff proposals for each package. If 8 days
> after you get no reply from the maintainer, file an ITS against the
> packages for which you got no reply.
>
> If at the end of the proce
On Sat, 1 Jan 2022 at 19:48, Boyuan Yang wrote:
>
> That being said, while providing a list onto debian-devel is not a bad idea,
> https://www.debian.org/doc/manuals/developers-reference/pkgs.en.html#package-salvaging
> should be the correct choice. For a specific example, I just spotted
> https:/
I'm a long-term Debian user and upstream maintainer, and a DM.
I'm working to package updates to mature packages. All of them have
maintainers who are at best sporadically responsive—I do not blame them! I'm
sure they're all hugely overworked. (I'm also upstream for several packages
with responsiv
2014-10-17 19:10 GMT+01:00 Sylvestre Ledru :
> The English version is at the end of the email.
>
> Next November, 14 to 16th, a Bug Squashing Party (BSP) is organized in
> Mozilla offices [1] in Paris.
>
That should be "This November".
--
http://rrt.sc3d.org
Package: wnpp
Severity: wishlist
Owner: Reuben Thomas
* Package name: python-pyewmh
Version : 0.2
Upstream Author : Julien Pages
* URL : https://github.com/parkouss/pyewmh
* License : GPL
Programming Lang: Python
Description : Python3 implementation
On 3 March 2014 20:01, Steve Langasek wrote:
>
> Done. The page is user editable, provided that you're logged in to the
> wiki.
>
Thanks. I'm sorry, I was confused: I think the real reason I didn't edit
the page was because at the time I didn't know whether it or the other
material I had read w
On 3 March 2014 18:13, Gunnar Wolf wrote:
>
> As keyring maintainers, we no longer consider 1024D keys to be
> trustable. We are not yet mass-removing them, because we don't want to
> hamper the project's work, but we definitively will start being more
> aggressively deprecating their use. 1024D
I thought it might be worth pointing out that this has already been done
on a large scale, in Mac OS X. That is precisely why PPC and i386 gcc
are now largely fixed. Also, that the Mac OS team did considerable
testing, and now build almost everything with -Os.
I heard this at a presentation fr
15 matches
Mail list logo
