Re: Bug#1011666: need help with groff 1.23.0 (1.23.0~rc3-1 package prepared)
On Mon, Feb 27, 2023 at 03:26:52PM +0100, Alejandro Colomar wrote:
> On 2/27/23 13:56, G. Branden Robinson wrote:
> > At 2023-02-26T13:30:58+, Colin Watson wrote:
> >> First, move your current branch somewhere for reference, then make a new
> >> one. Then, my routine for pulling in new upstreams looks roughly like
> >> this:
> >>
> >> git-dpm import-new-upstream -p $UPSTREAMTAG^{} --rebase-patched
> >> ../foo.orig.tar.gz
> >> # this imports the unpacked upstream tarball onto an upstream branch
> >> # based on $UPSTREAMTAG, then drops you into a rebase session
> >>
> >> ... continue with rebase as needed, then once you're finished ...
> >>
> >> git-dpm update-patches --amend
> >> # the --amend is just because the import-new-upstream step will
> >> # already have recorded the new upstream on the branch you started
> >> # from, but the history looks clearer if you bundle the rebase with
> >> # that in a single merge commit, which this does
>
> May I ask something from you, Colin? Could you please embed that
> info in the commit messages in salsa? That would help those who
> want to learn Debian packaging from actual practice rather than
> tutorials (I've read and watched many of those, and my confusion
> only grows; I mean, just look at
> :p).
>
> In the Linux man pages I write the scripts or commands run to produce
> a scripted or semi-scripted patch, or when some important information
> needed to write a patch was gotten from some script. See for example:
This isn't really analogous to your situation, though. git-dpm is more
like a workflow tool (such as stgit) than it is like a program you use
to generate one-off scripted patches. I don't think it would be
appropriate or reasonable to try to embed this sort of thing in every
commit generated by git-dpm, which is quite a lot of the commits that
end up in my packaging branches.
I'd be happy to write a debian/README.source file, which would be a
better place for this sort of thing. I'm not sure exactly when I'll get
round to it, but I've added it to my to-do list.
> > Please find attached my much more modest proposal. Let's make sure the
> > groff in Debian bookworm will not throw confusing undefined register
> > warnings or drop text from man pages that begin to embrace groff 1.23's
> > new features.
I'm fine with this, modulo sorting out minor commit formatting details.
--
Colin Watson (he/him) [cjwat...@debian.org]
Re: DEB_BUILD_OPTIONS=nowerror
Hi Steve, On Mon, Feb 27, 2023 at 04:39:29PM -0800, Steve Langasek wrote: > Well, I'm not seeking to stand in the way of the work, so much as trying to > make sure this is the most useful work to be doing to meet the actual use > cases. Thank you. I see that you are seeking a better solution and looking at the problem from an angle that I didn't have. In general, I don't see much consensus on my proposed option nor other people explaining that it'd be useful to them. > I can see that for bootstrapping a new architecture, it will sometimes be > useful to use a toolchain newer than the one that is currently default in > Debian, and as a result it is useful to also be able to bypass new stricter > -Werror behavior from gcc upstream that breaks compatibility with existing > code. Good. > It isn't clear to me from the discussion history that this is the actual use > case at issue. But supposing it is, that's one use case; and it's a use > case that can be addressed without having to make any per-package changes > and without having to make any changes to dpkg-buildflags interfaces by > exporting > > DEB_CFLAGS_APPEND=-Wno-error > DEB_CXXFLAGS_APPEND=-Wno-error > > as part of the bootstrap build environment, for all packages. Thank you for proposing this solution that I did not see. It certainly has beauty in that it really solves the problem at hand in a simple way without expanding existing interfaces. I'm not sure whether it works in practice, but I think that patches for making it work would probably be accepted in the relevant packages if it doesn't. To me, this looks like a better solution of my original problem. Your persistence on this matter is welcome. Helmut
Re: icc-profiles_2.2_source.changes REJECTED
Le lundi 27 février 2023, 12:11:27 UTC Jonas Smedegaard a écrit : Hi jonas, I have just checked the source code of lintian. Could you double check your package and create a simple test case ? According to: https://salsa.debian.org/lintian/lintian/-/blob/master/lib/Lintian/Check/Files/NonFree.pm#L91 The test should not raise Bastien > Quoting Simon McVittie (2023-02-27 13:04:25) > > On Mon, 27 Feb 2023 at 12:22:34 +0100, Jonas Smedegaard wrote: > > > I am not convinced, however, that this issue is a bug in lintian: > > > The testcase you ask for is the actual files in the icc-profiles source > > > package which already is already correctly identified by lintian. I.e. > > > issue is not that some different files get misdetected but instead that > > > lintian _correctly_ identifies the files in this non-free package and > > > _correctly_ classifies those as unsuitable in main > > > > That's correct to a point, but it seems wrong for lintian to be emitting a > > tag that means "this package is unsuitable for main and that's a problem" > > for a package in non-free. Yes, we know it's unsuitable for main, and > > the maintainer has acknowledged that by uploading it to non-free... it > > doesn't seem like there is any benefit to having an unfixable Lintian > > error as well. > > > > Or if the interpretation of the tag is "you should use the copy of this > > file from icc-profiles instead of shipping your own copy", then the lintian > > check should have a special case to silence that tag when the package being > > checked *is* icc-profiles. > > > > There are similar special cases in other parts of Lintian. For example, > > it looks for embedded code copies of zlib, but that check has a special > > case to avoid it being triggered by zlib itself, because obviously zlib > > should be allowed to ship zlib code; and similarly checks for a bundled > > font like Deja Vu shouldn't trigger for fonts-dejavu itself. > > Ah, I was unaware that lintian at other places includes exceptions like > that, an that lintian is expected to do reliable assessments in this > kind of tests. > > When that's the case, then please, Bastien (or others skilled with > internals of lintian) please refine the tests for icc-profiles contents > to exclude icc-profiles package itself. > > (I'll file a bugreport against lintian if I notice no actions from this) > > Kind regards, > > - Jonas > > signature.asc Description: This is a digitally signed message part.
Re: Yearless copyrights: what do people think?
On 2023-02-26 at 18:43 +0200, Adrian Bunk wrote: > On Wed, Feb 22, 2023 at 07:39:09AM -0700, Sam Hartman wrote: > > As Jonas mentions, including the years allows people to know when > > works > > enter the public domain and the license becomes more liberal. > > I think our users are better served by knowing when the Debian > > packaging > > would enter the public domain. > > If this is the intention, then including the years is pointless. > > Article 7 of the Berne Convention says: > (1) The term of protection granted by this Convention shall be the > life > of the author and fifty years after his death. > > (6) The countries of the Union may grant a term of protection in > excess > of those provided by the preceding paragraphs. This. The Copyright year for determining when the work enters public domain can be useful for US works published before 1978, but little more. Now most countries have settled on 70 years post mortem auctoris (and while there are countries with shorter terms, with the US not following the rule of the shorter term, you would probably still need to wait those 70 years if doing some business there) It could be useful when the author is unknown or there is corporate authorship, in which case the US copyright term is 95 years from first *publication* (which _may_ be different from the copyright year) or 120 years after creation. Another can of worms is that the copyright year is often not well- maintained. There may be program changes with no bump of the copyright year, and you find as well projects that updating the number yearly, regardless if there are actually changes or not (so the stated year doesn't actually give the real information).
Re: icc-profiles_2.2_source.changes REJECTED
Quoting Bastien Roucariès (2023-03-03 22:21:49) > Le lundi 27 février 2023, 12:11:27 UTC Jonas Smedegaard a écrit : > Hi jonas, > > I have just checked the source code of lintian. Could you double check your > package and create a simple test case ? > > According to: > https://salsa.debian.org/lintian/lintian/-/blob/master/lib/Lintian/Check/Files/NonFree.pm#L91 > The test should not raise Sorry, I don't understand what you ask me to do. In case it was unclear from my previous posts: The rejection messages I shared was not from a lintian check done locally by me, but a rejection message I received from ftpmaster. Locally I did not experience the same messages. Are you asking me to test again that I (again) do not experience the kind of messages that ftpmasters for some reason unknown to me trigger? - Jonas -- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ * Sponsorship: https://ko-fi.com/drjones [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: signature
Re: icc-profiles_2.2_source.changes REJECTED
Le vendredi 3 mars 2023, 22:35:24 UTC Jonas Smedegaard a écrit : > Quoting Bastien Roucariès (2023-03-03 22:21:49) > > Le lundi 27 février 2023, 12:11:27 UTC Jonas Smedegaard a écrit : > > Hi jonas, > > > > I have just checked the source code of lintian. Could you double check your > > package and create a simple test case ? > > > > According to: > > https://salsa.debian.org/lintian/lintian/-/blob/master/lib/Lintian/Check/Files/NonFree.pm#L91 > > The test should not raise > > Sorry, I don't understand what you ask me to do. > > In case it was unclear from my previous posts: The rejection messages I > shared was not from a lintian check done locally by me, but a rejection > message I received from ftpmaster. > > Locally I did not experience the same messages. Are you asking me to > test again that I (again) do not experience the kind of messages that > ftpmasters for some reason unknown to me trigger? Yes could you double check ? If you do not experience the kind of messages with locally installed lintian, it means that lintian need to be backported and that ftpmaster should install a backport version. Bastien > > - Jonas > > signature.asc Description: This is a digitally signed message part.
Bug#1032323: ITP: moulin -- A meta build system capable of building multiple images at once.
Package: wnpp Severity: wishlist Owner: Sudip Mukherjee X-Debbugs-Cc: debian-devel@lists.debian.org, sudipm.mukher...@gmail.com * Package name: moulin Version : 0.0~git20230227.1630f49 Upstream Author : many * URL : https://github.com/xen-troops/moulin * License : Apache Programming Lang: Python Description : A meta build system capable of building multiple images at once. Main purpose of moulin is to build complex images for embedded devices. Imagine that you are running hypervisor (like Xen or KVM) on your device and you want to build multiple VM images with one simple command. moulin is made exactly for this task. As part of my role in Elisa (https://elisa.tech/) I had to use moulin, but being a Debian user I did not like installing moulin from their git. So, this ITP. I can maintain it under the umbrella of Debian Python team. -- Regards Sudip
Bug#1032328: ITP: python-ctranslate2 -- Optimized inference engine for OpenNMT-py and OpenNMT-tf models
Package: wnpp Severity: wishlist Owner: Kartik Mistry X-Debbugs-Cc: debian-devel@lists.debian.org, kar...@debian.org * Package name: python-ctranslate2 Version : 3.7.0 Upstream Contact: guillaume.kl...@systrangroup.com * URL : https://github.com/OpenNMT/CTranslate2 * License : MIT Programming Lang: Python Description : Optimized inference engine for OpenNMT-py and OpenNMT-tf models CTranslate2 is an optimized inference engine for OpenNMT-py and OpenNMT-tf models supporting both CPU and GPU execution. It also aims to be a place for experimentation around model compression and inference acceleration.
