Re: dh_install by file suffix
On Sat, Jul 15, 2023 at 09:01:19PM +0200, Ole Streicher wrote: > Hi, > > I am upgrading one of my packages (iraf) to a new version. The new version > comes with a "make install", which installs everything under /usr/lib/iraf/ > (and some other places). > > The "iraf" source package needs to divide these files into user related > files (for the "iraf" and "iraf-noao" packages) and development related > files (for "iraf-dev" and "iraf-noao-dev"). The problem is now, that the > division is (mainly) by extension: > > - *.cl, *.hd, *.men, *.par (... and some other extensions) should go to > the user packages > > - *.a, *.h should go to the development packages > > (the "iraf" and "iraf-noao" package differ mainly by that "iraf" collects > them in the pkg/ subdir, and "iraf-noao" in the noao subdir). > > The main question here is: how can I do a dh_install selective by file > suffix? Otherwise, I would need to list the (~1000) files in the "install" > files, which is not very robust. You can always skip dh_install and do manual cp/mv/install/whatever commands in override_dh_install. Or you could probably use dh-exec.
Re: dh_install by file suffix
Hi again,
I think youe way could be to put the file list into a variable in
d/rules, and expand the list the .install, like:
-- debian/iraf.install -
etc/iraf/
usr/lib/iraf/bin/ecl.e
[... other fixed content]
${env:IRAF_FILES}
8<--
--- debian/rules ---
override_dh_install:
IRAF_FILES=$$(cd debian/tmp; \
find usr/lib/iraf/pkg usr/lib/iraf/unix/hlib \
-name \*.hlp \
-o -name \*.hd \
[...] \
-o -name \*.fits) \
dh_install
8<--
where the same procedure however would required for all four binary
packages. This does not look very nice, and also according to the
debhelper manpage, one can only expand to 4096 chars (I'd need ~40,000).
Any better idea?
Best
Ole
On 15.07.23 21:01, Ole Streicher wrote:
Hi,
I am upgrading one of my packages (iraf) to a new version. The new
version comes with a "make install", which installs everything under
/usr/lib/iraf/ (and some other places).
The "iraf" source package needs to divide these files into user related
files (for the "iraf" and "iraf-noao" packages) and development related
files (for "iraf-dev" and "iraf-noao-dev"). The problem is now, that the
division is (mainly) by extension:
- *.cl, *.hd, *.men, *.par (... and some other extensions) should go to
the user packages
- *.a, *.h should go to the development packages
(the "iraf" and "iraf-noao" package differ mainly by that "iraf"
collects them in the pkg/ subdir, and "iraf-noao" in the noao subdir).
The main question here is: how can I do a dh_install selective by file
suffix? Otherwise, I would need to list the (~1000) files in the
"install" files, which is not very robust.
Cheers
Ole
Bug#1036751: RFS: mini-httpd/1.30-4 [ITA] -- Small HTTP server
Hi Alexandru, Alexandru Mihail writes: > After a bit more research into how other projects treat NCSA bits I'd > propose something along the lines of: > > debian/copyright: > Files: htpasswd.c Yes, and htpasswd.1. > Copyright: 1993-1994 Rob McCool > Copyright: 1997 Jef Poskanzer ? Yes, and you would know the years better than I! Also, you'll need to say a few words about how you established copyright--a very short too long didn't read version of this thread. Find out how to do this at §5.1 of the following (read the short list of fields, and you'll see which one it is): https://www.debian.org/doc/packaging-manuals/copyright-format/1.0/#file-syntax > License: NCSA > > > License: NCSA > This code is in the public domain. Specifically, we give to the public > domain all rights for future licensing of the source code, all resale > rights, and all publishing rights. > > We ask, but do not require, that the following message be included in > all derived works: > > Portions developed at the National Center for Supercomputing > Applications at the University of Illinois at Urbana-Champaign. > > THE UNIVERSITY OF ILLINOIS GIVES NO WARRANTY, EXPRESSED OR IMPLIED, > FOR THE SOFTWARE AND/OR DOCUMENTATION PROVIDED, INCLUDING, WITHOUT > LIMITATION, WARRANTY OF MERCHANTABILITY AND WARRANTY OF FITNESS FOR A > PARTICULAR PURPOSE. Looks good to me. > Also, looking into your concerns about public domain in other countries > (specifically referring to NCSA's :"This code is in the public > domain"): > > Excerpt from https://wiki.debian.org/DFSGLicenses#Public_Domain : [snip] Thank you for looking into this, and for sharing this information. Regards, Nicholas signature.asc Description: PGP signature
Bug#1041224: RFS: wmbusmeters/1.13.1-3 - read wireless and wired M-Bus (EN13757 OMS) telegrams from utility meters
Package: sponsorship-requests Severity: normal Dear mentors, I am looking for a sponsor for my package "wmbusmeters": * Package name : wmbusmeters Version : 1.13.1-3 Upstream contact : oehrstr...@gmail.com * URL : https://github.com/wmbusmeters/wmbusmeters * License : GPLv3 * Vcs : https://salsa.debian.org/weetmuts/package-wmbusmeters Section : experimental The source builds the following binary packages: wmbusmeters - read wireless and wired M-Bus (EN13757 OMS) telegrams from utility meters To access further information about this package, please visit the following URL: https://mentors.debian.net/package/wmbusmeters/ Alternatively, you can download the package with 'dget' using this command: dget -x https://mentors.debian.net/debian/pool/main/w/wmbusmeters/wmbusmeters_1.13.1-3.dsc Changes since the last upload: * Update build dependencies. (This is done to build on more debian platforms.) Regards, Fredrik Öhrström
Bug#1036751: RFS: mini-httpd/1.30-4 [ITA] -- Small HTTP server
Hellow Alexandru, Alexandru Mihail writes: > Hello Nicholas, >>That's ok, you don't need to find the original version. Remember >>that >>it's a fork and child relationship, > > Yes, I'm terribly sorry, I'm familiar with the fork-child relationship > but I still found your analogy very helpful and concise, I might > present it to my interns (if that's O.K), thanks a lot for the > reminder. I was extremely tired when I wrote the last e-mail. No worries, and yes, go ahead and use that analogy :) If you feel like citing/attributing it to me, I'd appreciate it, but this isn't required. > In short, considering debian-legal's input, should I mention the NCSA > copyright notice in debian/copyright for Files: htpasswd.c, adding a > separate License: NCSA field to clarify the provenance of said source ? Yes, and if I remember correctly, you had figured this out by your next email (once again, sorry for my delays in replying). > I will fix the /patches issues we discussed in a later commit and > would also like to propose a mechanism for integrating PAM (Pluggable > Authentication Modules) into mini-httpd. I am currently in the > negotiation phase with my employer to grant an exception for this > particular patch in order for it to be upstreamed into debian/patches > (since, remember, we're the de-facto upstream here) and for my code to > become GPL licensed). PAM support (which would be toggled via a > Makefile parameter) could provide tangible improvements for the users > of mini-httpd and might even increase the server's popularity. The AUTH > mechanism in mini-httpd is arguably heavily antiquated and prone to > DDos attacks, MitM, scalability issues, etc. PAM would also enable AAA > solutions to interoperate with mini-httpd almost seamlessly (such as > Radius, TACACS+) which is becoming increasingly relevant in today's > SSO/IoT central trust-based use cases. Wow, that's wonderful (and unexpected) news! I hope negotiations go well. >>P.S. Please acknowledge: Have you read the DFSG yet, and do you >>understand why it's important? > Yes I have and yes I do, it is one of the main reasons I decided to > start contributing to DebianWiki (and now mini-httpd) to begin with. :) Thanks, much appreciated, and cool story! >>I confirm receipt of your mail, and I see an attached signature. >>Where >>can I download your public key? > > I'd like to ask you the same question, since I'd like to add your > address to my keyring. I've read a bit of documentation which suggests > using Ubuntu's HKP which seems a bit off-axis. I understand that the > Debian Public Key Server is for DDs and DMs only (I am not yet a DM). > I could perhaps use my DebianWiki personal page to link to my public > key, but I do not know if that solution would be accepted or would > sound absurd. I should find a better solution after some research. My key is on both the Debian keyring and public servers https://wiki.debian.org/DebianKeyring https://keys.openpgp.org/ and maybe also here http://pgp.mit.edu/ I haven't checked if pgp.mit.edu auto-updated from keys.openpgp.org how it used to work with the old SKS network. P.S. Please make create key revocation certificates for the cases: no-longer-used, superceded, and compromised, and store them someplace safe. Cheers, Nicholas signature.asc Description: PGP signature
dh_install by file suffix
Hi, I am upgrading one of my packages (iraf) to a new version. The new version comes with a "make install", which installs everything under /usr/lib/iraf/ (and some other places). The "iraf" source package needs to divide these files into user related files (for the "iraf" and "iraf-noao" packages) and development related files (for "iraf-dev" and "iraf-noao-dev"). The problem is now, that the division is (mainly) by extension: - *.cl, *.hd, *.men, *.par (... and some other extensions) should go to the user packages - *.a, *.h should go to the development packages (the "iraf" and "iraf-noao" package differ mainly by that "iraf" collects them in the pkg/ subdir, and "iraf-noao" in the noao subdir). The main question here is: how can I do a dh_install selective by file suffix? Otherwise, I would need to list the (~1000) files in the "install" files, which is not very robust. Cheers Ole
Bug#1041153: RFS: libhx/4.14-1 -- Documentation files for libhx
Package: sponsorship-requests Severity: normal Dear mentors, I am looking for a sponsor for my package "libhx": Package name : libhx Version : 4.14-1 Upstream contact : Jan Engelhardt URL : https://inai.de/projects/libhx/ License : LGPL-2.1+, WTFPL-2+, GPL-2+ Vcs : https://git.jff.email/cgit/libhx.git Section : libs The source builds the following binary packages: libhx32 - C library providing queue, tree, I/O and utility functions libhx-dev - Development files for libhx libhx-doc - Documentation files for libhx To access further information about this package, please visit the following URL: https://mentors.debian.net/package/libhx/ Alternatively, you can download the package with 'dget' using this command: dget -x https://mentors.debian.net/debian/pool/main/libh/libhx/libhx_4.14-1.dsc or from git https://git.jff.email/cgit/libhx.git/?h=release%2Fdebian%2F4.14-1 git https://jff.email/cgit/libhx.git/?h=release%2Fdebian%2F4.14-1 Changes since the last upload: libhx (4.14-1) unstable; urgency=medium . * New upstream release. - Refresh symbols files. * debian/control: - Change Vcs-* to new URL. CU Jörg -- New: GPG Fingerprint: 63E0 075F C8D4 3ABB 35AB 30EE 09F8 9F3C 8CA1 D25D GPG key (long) : 09F89F3C8CA1D25D GPG Key: 8CA1D25D CAcert Key S/N : 0E:D4:56 Jörg Frings-Fürst D-54470 Lieser git: https://git.jff.email/cgit/ Skype:jff-skype@jff.email Jami: joergfringsfuerst Telegram: @joergfringsfuerst Matrix: @joergff:matrix.snct-gmbh.de My wish list: - Please send me a picture from the nature at your home. signature.asc Description: This is a digitally signed message part
