Question about license
Hi, before pushing a broken package to the NEW queue: I started again working on #698886 and have a here a package, which is quite lintian clean. What causes headache is the license "Modified MIT license". The following paragraph has been added by the author: If you copy or distribute a modified version of this Software, the entire resulting derived work must be given a different name and distributed under the terms of a permission notice identical to this one. Except that it is a pure MIT license. Could that cause issues? Hilmar -- sigfault OpenPGP_signature.asc Description: OpenPGP digital signature
Re: Custom decompressor for mk-origtargz
Am 09.09.2024 um 08:17 schrieb Niels Thykier:
Hello,
```perl
push @cmd, ("-o${tempdir}", $upstream_tar);
```
Should do.
>
Works fine! Thank you.
hille@rasppi2:~/devel/wp2latex/wp2latex.git $ uscan
Newest version of wp2latex on remote site is 4.10b, local version is 4.10
(mangled local version is 4.10)
=> Newer package available from:
=> http://ftsoft.com.cz/wp2latex/wp2latex-4.10b.zip
uscan warn: No files matched excluded pattern as the last matching glob:
doc/iconv.txt
uscan warn: No files matched excluded pattern as the last matching glob:
doc/xgettext_err.txt
Successfully repacked ../wp2latex-4.10b.zip as
../wp2latex_4.10b~ds.orig.tar.xz, deleting 40 files from it.
uupdate: debian/source/format is "3.0 (quilt)".
uupdate: Auto-generating wp2latex_4.10~ds-1.debian.tar.xz
uupdate: -> Copy to wp2latex_4.10b~ds-1.debian.tar.xz
--
sigfault
OpenPGP_signature.asc
Description: OpenPGP digital signature
Re: Custom decompressor for mk-origtargz
Am 07.09.2024 um 23:49 schrieb Preuße, Hilmar:
Hi,
Can I tell mk-origtargz to use 7z instead of unzip to uncompress the zip
file?
The unzip binary is hard coded in MkOrigtargz.pm, I tried to replace, by
7z, but failed until now:
@cmd = ('7z','x');
push @cmd, split ' ', $self->config->unzipopt
if defined $self->config->unzipopt;
#push @cmd, ('-o', $tempdir, $upstream_tar);
push @cmd, ($upstream_tar);
unless (ds_exec_no_fail(@cmd) >> 8 == 0) {
ds_die("Repacking from zip or jar failed (could not
unzip)\n");
return $self->status(1);
}
in line 91 ff. The output directory for 7z needs to be specified
"-ooutputdir", w/o a space. I don't speak perl, can anybody help?
Hilmar
--
sigfault
OpenPGP_signature.asc
Description: OpenPGP digital signature
Custom decompressor for mk-origtargz
Hi all, before opening a bogus bug. My upstream provides zip files, which needs to be repacked, but can't be uncompressed using UNIX unzip: hille@rasppi2:~/devel/wp2latex $ unzip wp2latex-4.10.zip Archive: wp2latex-4.10.zip skipping: wp2latex-4.10/bin/win/wp2latex.exe need PK compat. v6.3 (can do v4.6) skipping: wp2latex-4.10/bin/win64/wp2latex.exe need PK compat. v6.3 (can do v4.6) skipping: wp2latex-4.10/doc/formats/wp_4x.doc/wp42ff.txt need PK compat. v6.3 (can do v4.6) skipping: wp2latex-4.10/doc/formats/wp_7x.doc/a_frntff.htm need PK compat. v6.3 (can do v4.6) skipping: wp2latex-4.10/doc/formats/wp_7x.doc/b_1docin.htm need PK compat. v6.3 (can do v4.6) I could open a bug for unzip, but I guess this would be rather useless. I'm able unpack the zip file using 7z. Can I tell mk-origtargz to use 7z instead of unzip to uncompress the zip file? Hilmar -- sigfault OpenPGP_signature.asc Description: OpenPGP digital signature
Running Debian CI/CD on github
Hi all, for some historic reasons some of our (Debian TeX task force) repositories are sitting on github. I'd like to use the Debian provided CI/CD even on these repos. Here [1] is description how this could be done, but I'm failing to implement it, b/c some steps can't be executed as described. Was anybody successful to run Debian CI/CD on external repos and if yes, how? Hilmar [1] https://docs.gitlab.com/ee/ci/ci_cd_for_external_repos/github_integration.html -- sigfault OpenPGP_signature.asc Description: OpenPGP digital signature
Re: Package does not migrate to testing
On 23.07.2024 23:33, Soren Stoutner wrote: Hi, Alternately, you could mark it as fixed in the current version of fq. Actually I solved the issue by marking as notfound in fq. This ist not 100% correct, as it was package fq, which introduced the file conflict. Anyway; nq has now migrated to testing. Hilmar -- sigfault OpenPGP_signature.asc Description: OpenPGP digital signature
Re: Package does not migrate to testing
On 23.07.2024 23:07, Soren Stoutner wrote: Hello, Somehow the system didn’t pick up on the closure in the 1.0-0.1 changelog. I would suggest you manually mark it as fixed in 1.0-0.1 using: The bug page itself [1] looks good and states: Found in versions fq/0.9.0-2, nq/0.3.1-4, fq/0.0.4-2 Fixed in version nq/1.0-0.1 Done: Hilmar Preuße I can try again to close it, but I guess that won't help. [1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1005961 -- -- sigfault OpenPGP_signature.asc Description: OpenPGP digital signature
Package does not migrate to testing
Hi, for nq the excuse [1] currently reads Migration status for nq (- to 1.0-0.2): BLOCKED: Rejected/violates migration policy/introduces a regression Issues preventing migration: Updating nq would introduce bugs in testing: #1005961 The bug has been closed in latest upload. What needs to be done? Hilmar https://qa.debian.org/excuses.php?package=nq -- sigfault OpenPGP_signature.asc Description: OpenPGP digital signature
Re: Hinting a package into testing?
On 05.07.2024 11:04, Håvard F. Aasen wrote: On 05.07.2024 00:25, Preuße, Hilmar wrote: Hi, I'm trying to bring TeX Live 2024 into Debian testing. The excuse pages for texlive-base/texlive-extra/texlive-lang say "Migration status for texlive-... (2023.20240207-x to 2024.20240401-x): Will attempt migration (Any information below is purely informational)" Unfortunately these package are bound to biber >= 2.20, which needs to migrate at the same time. Here the excuse page says [1]: It this really the case? In BD, there isn't any version restrictions on biber. Neither is it listed as a blocking issue. I would have expected that biber test suite needs texlive packages... In the end biber 2.20 breaks texlive-bibtex-extra (<< 2024.20240401) and root@rasppi2:~# apt-cache show texlive-bibtex-extra|grep Breaks Breaks: biber (<< 2.20), texlive-base (<< 2022.20220405) So, both packages need to migrate at the same time. The problem here is that the reference test succeeded, while the new test failed, this blocks the migration. The proper way to handle this is to request a new reference test, which in this case we hope will fail. When both tests fails, it is no longer a regression and therefore, no longer blocking the migration. For any reason the reference test now failed (thanks for requesting) and TL2024 is now in testing. Many thanks for help! Hilmar -- sigfault OpenPGP_signature.asc Description: OpenPGP digital signature
Hinting a package into testing?
Hi, I'm trying to bring TeX Live 2024 into Debian testing. The excuse pages for texlive-base/texlive-extra/texlive-lang say "Migration status for texlive-... (2023.20240207-x to 2024.20240401-x): Will attempt migration (Any information below is purely informational)" Unfortunately these package are bound to biber >= 2.20, which needs to migrate at the same time. Here the excuse page says [1]: autopkgtest for biber/2.20-2: amd64: Failed (not a regression), arm64: Failed (not a regression), armel: Regression or new test ♻ (reference ♻), armhf: Failed (not a regression), i386: Failed (not a regression), ppc64el: Failed (not a regression), riscv64: Failed (not a regression), s390x: Failed (not a regression) The armel test fails, b/c it tries to load TL packages, which are only in unstable. The autopkg test runs fine, when these package (from unstable) are used. How do I override the failing test? I could upload a biber w/ autopkgtest disabled, but I guess there are better methods to solve the issue. Thanks, Hilmar [1] https://qa.debian.org/excuses.php?package=biber -- sigfault OpenPGP_signature.asc Description: OpenPGP digital signature
Re: Remove package from unstable?
On 04.03.2024 02:09, Loren M. Lang wrote: Hi, Have you just tried passing through -S from gbp? As in "gbp buildpackage -S"? It might not work if you have set a different builder like schroot, but you can just pass --git-builder=debuild or similar in that case. Yes, I tried that option "-S", but it did not give me a source package. However I found the suitable command line later in gbp-buildpackage(1): gbp buildpackage --git-upstream-tree=upstream_2.10.08+ds --git-no-create-orig --git-export-dir=/tmp --git-builder=/bin/true --git-no-pbuilder --git-no-purge , which gives me a source tree in /tmp, which I can feed to "dpkg-buildpackage ... -S" to get a source package. I still fiddling with the versioning scheme I have to use, but I guess I'll figure that out myself. Hilmar -- sigfault OpenPGP_signature.asc Description: OpenPGP digital signature
Remove package from unstable?
Hello, dumb question: in an error I uploaded luametatex 2.11.01+ds-2 to Debian unstable. This was a mistake, it should have been uploaded to experimental, as it is part of the upcoming TL 2024. Is it possible to downgrade the Debian archive (unstable) to 2.10.08+ds-1 and upload the 2.11.01+ds-3 to experimental? Thanks, Hilmar -- sigfault OpenPGP_signature.asc Description: OpenPGP digital signature
Drop i386 architecture in texworks
Hi all, sorry to bother again. I was requested to stop building package on i386 (#1057407) so libqt6 can drop the i386 support too. So, how do do I do that? Do I have to specify (and maintain) the list of all supported arches in the debian/control file or can I specify something like "any [!i386]"? Another idea was to remove the i386 package using an ROM bug, then let libqt6 fix their list of arches. texworks stops automatically building on i386, b/c the BD's can be fulfilled any more. No need to change the source package. Would that work? Thanks! Hilmar -- sigfault OpenPGP_signature.asc Description: OpenPGP digital signature
Package scripts and environment vars
Moin, dumb question, I did not find anything in the policy. We got #1056587: in the postinst stage of a package a broken TeX format file is generated. The root cause is that the user placed a customized TeX input file anywhere and changed the TEXINPUTS variable in the environment of user root to make sure the file is read. Question: is the postinst expected to do the right thing even in this situation, i.e. do we have to reset TEXINPUT or can we rely on a clean environment of user root, which contains only minimal customization? Thanks, Hilmar -- sigfault OpenPGP_signature.asc Description: OpenPGP digital signature
Re: Debian versioning question
On 10.11.2023 00:37, Mattia Rizzolo wrote: On Thu, Nov 09, 2023 at 11:06:32PM +0100, Hilmar Preuße wrote: Hello Mattia, Can we override that anyhow? Even if it was possible, how would that be of any help? You do realize that versioning order matters for much more than whatever is shown on a web page, right? Like, apt policy. Or what dpkg does. Not sure, why I did not recognize the severity of that issue earlier. Until yesterday it was just a display issue. I can open an issue at upstream trying to remove the RfC files, but I guess he's not really interested in these Debian internals. Further it does not solve the issue for this particular upload. You seem to have skipped the last paragraph of my last email. What about that? Sorry. I'll talk to my co-workers about that. I got another suggestion, so let's see what we do. Hilmra -- sigfault OpenPGP_signature.asc Description: OpenPGP digital signature
Re: Debian versioning question
On 10.11.2023 03:10, Wookey wrote: Hi Wookey, I think your options are 1) add an epoch (which exists to deal with this sort of problem) Well, would like to avoid it, if possible. 2) wait till the next (numerical) release 1.3.9 and upload that. Do releases happen often? This approach only really makes sense if you/your users can put up with the old version until a higher-versioned one appears About every two years, so not uploading is not really in option. 3) upload a 'nobbled' version number, which is often done to deal with this sort of temporary issue: 1.3.8a+really1.3.8+dfsg-1 dpkg --compare-versions 1.3.8a+dfsg lt 1.3.8a+really1.3.8+dfsg; echo $? You mean upload the 1.3.8a as 1.3.8+really1.3.8a, 1.3.8+really1.3.8b, 1.3.8+really1.3.8c etc. until we are at 1.3.9 und we can return to normal versioning? I'd probably go with option 3 in this case. Ugly but temporary. Sounds like an option for now. Thanks! Hilmar -- sigfault OpenPGP_signature.asc Description: OpenPGP digital signature
Re: Upload for Debian QA
On 07.11.2023 01:07, Santiago Vila wrote: Hi, Hi. I see that the previous change was also requested by you (and uploaded by someone else) due to its interaction with Texinfo. If you feel attachment to an orphaned package, you can also adopt it. I'm aware of that, but currently I'm not interested in maintaining more packages. Thanks for the offer. I was just interested in getting TeXInfo into testing. H. -- sigfault OpenPGP_signature.asc Description: OpenPGP digital signature
Re: Upload for Debian QA
On 07.11.2023 00:25, Santiago Vila wrote: El 6/11/23 a las 23:42, Hilmar Preuße escribió: Hi, TeXinfo 7.1 does not migrate to testing b/c the test suite of autoproject returns with exit code > 0. I've filed a bug report and created a patch for the issue. The package is maintained by the Debian QA group. What else can be done from my side? Packages maintained by "QA Group" are like packages maintained by a team, except that the team is Debian as a whole. You could make the upload yourself (just say "QA upload" at the beginning). Please be aware, that I'm not a DD and currently I don't intend to change that. So I guess I can't upload, unless I got upload permits. H. -- sigfault OpenPGP_signature.asc Description: OpenPGP digital signature
Re: Access to porter boxes?
On 21.10.2023 00:32, Judit Foglszinger wrote: Hi, That should be opening an rt ticket with DSA, as access on those guest accounts expires after a while. One only needs to go through the NM page the first time. Yes, that worked. I had to open a ticket at rt.debian.org to reactivate the account. After some communication I now have access to the boxes I need. Thanks for help! Hilmar -- sigfault OpenPGP_signature.asc Description: OpenPGP digital signature
Debian versioning question
Hello, dumb question. Currently the vcswatch for proftpd-dfsg [1] reports: "OLD: VCS is behind the version in the archive: 1.3.8a+dfsg-1 < 1.3.8+dfsg-8." According to deb-version(7) this is absolutely correct: First the initial part of each string consisting entirely of non-digit characters is determined. These two parts (one of which may be empty) are compared lexically. If a difference is found it is returned. The lexical comparison is a comparison of ASCII values modified so that all the letters sort earlier than all the non-letters and so that a tilde sorts before anything, even the end of a part. The upstream minor versions are always determined by letters, so I'm unsure how to make clear that 1.3.8a+ is later than 1.3.8+. Any hints? Hilmar [1] https://qa.debian.org/cgi-bin/vcswatch?package=proftpd-dfsg -- sigfault OpenPGP_signature.asc Description: OpenPGP digital signature
Re: Package remains in status "Uploaded"
On 27.09.2023 19:07, Niels Thykier wrote: Hi, In your case, I would start with a give back and then if this attempt fails, contact the buildd admins. AFAICT that option is limited to Debian Developers. So if anybody would be so kind Hilmar -- sigfault OpenPGP_signature Description: OpenPGP digital signature
Package remains in status "Uploaded"
Hi all, the package texinfo has been built successfully for architecture loong64 and is in status "Uploaded" for about a month now. I'm pretty sure there are a lot of packages in status "BD-Uninstallable" b/c it does not get installed. What can be done here? Hilmar -- sigfault OpenPGP_signature Description: OpenPGP digital signature
Re: Upload to NEW rejected
On 13.09.2023 00:00, gregor herrmann wrote: On Tue, 12 Sep 2023 23:51:26 +0200, Preuße, Hilmar wrote: Hi, My guess is different lintian versions, aka ftp-master running an older lintian version which had a different formatting of the output. Compare the strings: texlive-binaries: lintian output: 'embedded-library usr/bin/pdftex: poppler', automatically rejected package. embedded-library usr/bin/pdftex: poppler vs. texlive-binaries: embedded-library poppler [usr/bin/pdftex] embedded-library poppler [usr/bin/pdftex] Yes, that solved my issue. Thanks! I would have liked to avoid the duplication, but well. Hilmar -- sigfault OpenPGP_signature Description: OpenPGP digital signature
Upload to NEW rejected
Hello, again a dumb question. I tried to upload texlive-bin into the NEW queue. The upload was rejected: texlive-binaries: lintian output: 'embedded-library usr/bin/pdftex: poppler', automatically rejected package. texlive-binaries: If you have a good reason, you may override this lintian tag. texlive-binaries: lintian output: 'embedded-library usr/bin/pdftosrc: poppler', automatically rejected package. texlive-binaries: If you have a good reason, you may override this lintian tag. We have some kind of override for this lintian error in the package: # poppler >= 0.62 is necessary for building TeX Live texlive-binaries: embedded-library poppler [usr/bin/pdftex] texlive-binaries: embedded-library poppler [usr/bin/pdftosrc] When running lintian --tag-display-limit 0 -I --pedantic *2023.20230311.66589-5*dsc *2023.20230311.66589-5*deb the error is not visible, as it was overridden. How do we go from here, how do I push the package through the NEW queue? I do a package split, hence this is needed. I tried to investigate if it is possible to link dynamically with poppler, but it seems the TL people stopped support for dynamic poppler a while ago. H. -- sigfault OpenPGP_signature Description: OpenPGP digital signature
Re: Question about upload
On 04.09.2023 13:30, Preuße, Hilmar wrote: Hi, I signed the package now correctly, the processing E-Mail said: dvisvgm_3.1.1+ds-1.debian.tar.xz has incorrect size; deleting it Do I have to re-upload or remove the "associated files" in any way? The ACCEPTED mail just rolled in. Many thanks! Hilmar -- sigfault OpenPGP_signature Description: OpenPGP digital signature
Re: Question about upload
On 04.09.2023 12:42, Andrey Rakhmatullin wrote: On Mon, Sep 04, 2023 at 12:28:01PM +0200, Preuße, Hilmar wrote: Hi all, I'm trying to upload a new package for dvisvgm[1]. Unfortunately this does not work: the dput command runs fine, but I did not even got the E-Mail that the upload was successful and the package is processed. In the meantime I could upload a new revision of texlive-bin, so there is no general issue with my account. I'm using the upload server "ftp.eu.upload.debian.org". From usper:/srv/upload.debian.org/queued/run/log: Sep 3 22:22:33 processing /dvisvgm_3.1.1+ds-1_source.changes Sep 3 22:22:33 GnuPG signature check failed on dvisvgm_3.1.1+ds-1_source.changes Sep 3 22:22:33 (Exit status 2) Sep 3 22:22:33 /dvisvgm_3.1.1+ds-1_source.changes has bad PGP/GnuPG signature! Sep 3 22:22:33 Removing /dvisvgm_3.1.1+ds-1_source.changes, but keeping its associated files for now. Which is indeed the most frequent cause of "I did not even got the E-Mail". Umm, ooh. I just typed dput, which in turn called debsign to sign the package. Unfortunately it used the wrong key. Not sure why; DEBSIGN_KEYID in ~/.devscripts has the correct value. I signed the package now correctly, the processing E-Mail said: dvisvgm_3.1.1+ds-1.debian.tar.xz has incorrect size; deleting it Do I have to re-upload or remove the "associated files" in any way? Hilmar -- sigfault OpenPGP_signature Description: OpenPGP digital signature
Question about upload
Hi all, I'm trying to upload a new package for dvisvgm[1]. Unfortunately this does not work: the dput command runs fine, but I did not even got the E-Mail that the upload was successful and the package is processed. In the meantime I could upload a new revision of texlive-bin, so there is no general issue with my account. I'm using the upload server "ftp.eu.upload.debian.org". How should I proceed? Thanks! Hilmar [1] https://tracker.debian.org/pkg/dvisvgm -- sigfault OpenPGP_signature Description: OpenPGP digital signature
Re: Lost sponsor & autoremoval
On 17.07.2023 09:31, Gábor Németh wrote: Hi, So basically I think I'm now looking for a new sponsor. I don't think I can file a new RFS so that my package is in the repos already. You can file an RFS file, in case you need help with uploading to Debian. This does not depend on if the package is in Debian or not. Of course it is more easy to become a DM and get the upload permits for your package. H. -- sigfault OpenPGP_signature Description: OpenPGP digital signature
Re: New package: ITP or RFP ?
On 20.06.2023 13:34, Ramūnas Keliuotis wrote: Hi, We just opensourced our NordVPN Linux application and want to make it available from the public Debian repository. As we are planning to do packaging and support by ourselves, it is still not clear how to properly go through the Debian packaging process and we would like to get help and initial guidance. So, question: which request to submit ITP or RFP ? ITP: Intend to package (open that if you want to maintain the package yourself). RFP: Request for package (if you need the package, but don't want to maintain yourself). H. -- sigfault OpenPGP_0x0C871C4C653C1F59.asc Description: OpenPGP public key OpenPGP_signature Description: OpenPGP digital signature
Re: Not install files in Debian package
On 06.05.2023 00:25, Dominik George wrote: Hi, Now I need to move some files to another package. Is there an easy method the exclude some files from this package or do I have to compile a positive list (which might vary between versions)? In debian/rules: Well, errrm. I should have looked into my rules file before. Now I use the dirty solution to remove there files before the packages are built: rm -f debian/texlive-binaries/usr/bin/*luajit* rm -f debian/texlive-binaries/usr/share/man/man*/*luajit* Thanks for help anyway! Hilmar -- sigfault
Not install files in Debian package
Hi all, sorry, dumb question: currently a Debian package contains all files it find below usr/bin and usr/share. hille@sid-amd64:~/t2/texlive-bin/debian$ cat texlive-binaries.install usr/bin usr/share Now I need to move some files to another package. Is there an easy method the exclude some files from this package or do I have to compile a positive list (which might vary between versions)? Thanks, Hilmar -- sigfault
Re: Uploading patch to unstable
On 20.03.2023 16:38, Aaron Boxer wrote: Hi Aaron, are you subscribed to debian-devel-annou...@lists.debian.org ? Thanks, Santiago. How do I contact the release team to ask about unblock ? "According to schedule, we have frozen bookworm a bit more (2023-03-12). This means that we are one step closer to the release of bookworm. Like mentioned before we expect everyone to follow the freeze policy [1]. This means that from now on key packages [2] and packages without significant autopkgtest coverage need to be unblocked by the release team to be able to migrate from unstable to testing. If you need to request an unblock, check that your request is in line with the freeze policy and use $(reportbug release.debian.org) in order to get the meta data correct and get the template that helps us get the right information." Hilmar [1] https://release.debian.org/bookworm/freeze_policy.html#hard [2] https://release.debian.org/key-packages.html
