Conflicting advise of lintian and Multiarch hinter
Hi, the package tracker page of libburn complains about two lintian errors https://lintian.debian.org/tags/multiarch-foreign-pkgconfig.html https://lintian.debian.org/tags/multiarch-foreign-static-library.html Both are about the line Multi-Arch: foreign which appears in debian/control only for binary package libburn-doc The lintian advise is "Please remove the Multi-Arch: foreign stanza." This directly contradicts a "Multiarch hinter" urge of september 2016 and advise which i got here: https://lists.debian.org/debian-mentors/2016/09/msg00284.html namely to add that line to -doc, where no "Multi-Arch:" was before. (Further i wonder why only libburn gets the lintian errors but not libisofs and libisoburn, which have the same gesture in their control files.) Which of the automats is right ? Have a nice day :) Thomas
Re: debuild finds no secret key after dist-upgrade
Hi, > > - How to bring the original tarball's .sig file into the packaging ? > Convert it to .asc I could try to squeeze something out of https://lists.gnupg.org/pipermail/gnupg-users/2011-November/043252.html or https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=832267 but will probably generate such an .asc file from original data as soon as i found out how it relates to the .asc payload wrapper which i generate by gpg --clearsign. Reading GnuPG manual, i get the suspicion that dpkg-source's .asc is just a gpg --detach-sig with a suffix that the GnuPG manual uses for --clearsign results. I may be wrong. > and read dpkg-source(1). I try hard. But what does it mean when it says "tarball can be accompanied by a detached upstream signature" ? A big problem with Debian packaging is that nearly everything happens automagically but the docs expect the reader to know the entrails and the multi-layer structure. > > Can it [my key] be too old for the new gpg binary ? > Have you read https://www.gnupg.org/faq/whats-new-in-2.1.html#nosecring Yes. But it does not explain how the dist-upgrade of last year left gpg in the state which after another dist-upgrade makes it inoperational. Something must have confused apt-get (or a layer underneath). My own contribution to the mess is mainly my key. So i first look at this. > Check /usr/bin/gpg2 or whatever it was called in the old gnupg2 package? There is one and it does not see keys. Obviously it is not used by debuild of the old Sid. > Surely you understand that installing or removing packages cannot have any > effect on user files? I'm trying to make as few assumptions as possible. > please fix your workflow ASAP. I am thankful for your advise. But your instructions are far too short. It is not easy to navigate between contradicting DD styles and tool chains. And then there is https://www.debian.org/doc/manuals/maint-guide/ ... I don't strive for becoming a Debian Maintainer. The preparation of my packages is done out of the mere need that nobody found it necessary to maintain them for two years, while debian-cd had to switch to my GNU xorriso source package because Debian's xorriso was too old to fulfill the needs of Debian installation ISOs. My aptness for contribution is actually restricted to providing the original source tarball, its .sig file, and the * New upstream release part of the changelog file. The rest is the pain of dealing with an unstable system and the gordian knot of Debian packaging tools. I do this to support debian-cd and because i am thankful for my Jessie with its wellknown kernel bugs which i can work around in userspace. Normally i do not complain. But i cannot achieve results beyond my limits. > Use pbuilder or sbuild. My Sid remembers an encounter with pbuilder. 1.2 GB of cache. I could try to find in my mail archive why i tried it and why i gave up on it. The more different tools and approaches i get urged to use, the more error prone becomes the whole procedure. Isn't any tool in the box which can make a Debian package out of a vanilla autotools based tarball ? ./configure && make && make install GUIX can, Arch can, Fedora can. My upstream releases get packaged faster than i have started my dist-upgrade on the Sid VM. Have a nice day :) Thomas
Re: debuild finds no secret key after dist-upgrade
Hi, thanks and apologies for the second nudge about "-us -uc". I got an installable package of libisofs now. Open questions are: - How to bring the original tarball's .sig file into the packaging ? (dpkg-source(1) did not give me enlightenment yet. Possibly because it acts on a lower level than debuild and the ./debian files which i have learned to maintain.) - What happened to gpg so that it does not see my secret key ? --- Long story: I booted up my backup of Sid before the dist-upgrade and verified that the directory .gnupg/private-keys-v1.d is already empty but that gpg --list-secret-keys lists the GPG key which i also use for signing my upstream tarballs: sec 1024D/ABC0A854 2010-03-30 Can it be too old for the new gpg binary ? Andrey Rahmatullin wrote: > So I suppose the gpg2 migration ran before you added the key to gpg1? It is more confusing. The old Sid has file ~/.gnupg/.gpg-v21-migrated but its gpg --version says gpg (GnuPG) 1.4.20 It was probably upgraded a year ago: $ ls -lc /usr/bin/gpg -rwxr-xr-x 1 root root 1008632 Jul 3 2016 /usr/bin/gpg I surely did not install or copy gpg manually. My Jessie has 1.4.18. Other origins of a copy would not be plausible. The fact that it is not really >=2.1 but already has the marker file would be a good explanation why the upgrade today did not change the key storage method to the new one. > > Now i have no idea at all why my secret key is suddenly gone. > WHy are you saying they are gone if secring.gpg still exists? "Unaccessible" then. Well, new ideas pop up already. > I guess you'll need to do the > migration again (try deleting .gpg-v21-migrated?) And then apt-get remove gpg apt-get install gpg ? (With a backup of the .gnupg directory on the shelf ?) > So you don't even use a clean chroot? I use a dedicated Sid VM, as was advised to me two years ago. The advice included to run apt-get "update" and "dist-upgrade" before running the debian-specific commands for packaging. In general, my libraries have few dependencies. So the risk to have unreproducible success by local modifications is low. The Sid is a vanilla Debian, even with Gnome and other things which i got by asking for a default installation. The size of the upgrade gives hope that everything of interest got replaced by new versions. > debuild -S -us -uc (I already told you that). Duh. "run all build commands with -us -uc" was indeed clear enough. This still says E: libisofs changes: orig-tarball-missing-upstream-signature libisofs_1.4.8.orig.tar.gz but debuild now finishes with exit value 0. The lintian error message is new to me. Where would i register or put my .sig file on the level of debian/control or debian/rules ? Next step: $ debuild -b -us -uc ... W: libisofs-dbg: debug-package-should-be-priority-extra libisofs-dbg I just changed that because of policy 2.5. I assume this overrules lintian. (I really try to obey. Even when the orders contradict.) gcc warns about -Wimplicit-fallthrough . Something for me with my upstream hat on. I will investigate whether it needs a patch or even a new release. $ cme check dpkg has no complaints to report. > > lintian -I -E --color never --show-overrides | less > You forget --pedantic. $ lintian -I -E --color never --show-overrides --pedantic ... I: libisofs6: spelling-error-in-binary usr/lib/x86_64-linux-gnu/libisofs.so.6.84.0 consequtive consecutive The typo is old. So lintian learned new words. Now checking whether the library links at run time: # dpkg -i libisofs6_1.4.8-1_amd64.deb $ xorriso -version xorriso 1.4.6 : RockRidge filesystem manipulator, libburnia project. ... libisofs in use : 1.4.8 (min. 1.4.6) That's a success. I already began to doubt ... Have a nice day :) Thomas
Re: debuild finds no secret key after dist-upgrade
Hi, correction: I forgot to use ls option -a when looking. There is a .gpg-v21-migrated. With an astounding ctime/mtime date: -rw-r--r-- 1 thomas thomas 0 Aug 21 2015 .gpg-v21-migrated So this seems already to have happened 2 years ago, when i set up that system and gave it the key from my workstation. Now i have no idea at all why my secret key is suddenly gone. Have a nice day :) Thomas
Re: debuild finds no secret key after dist-upgrade
Hi, Andrey Rahmatullin wrote: > Note that making a package and signing it are two separate operations (and > you are supposed to run all build commands with -us -uc and run debsign > explicitly). I understand that my signature as sponsored preparer is not of interest but rather the signature of the sponsor who uploads my files. Currently my cheat sheet has as commands for packing up and checking after preparing the ./debian files: debuild -S debuild -b cme check dpkg lintian -I -E --color never --show-overrides | less debclean As superuser to make the binaries accessible for tests: dpkg -i libisofs6_1.4.8-1_amd64.deb Can you give me a command sequence as replacement for debuild -S, which omits the gpg part ? > > The only file with new timestamp is the empty directory > > .gnupg/private-keys-v1.d > > which according to > > https://www.gnupg.org/faq/whats-new-in-2.1.html#nosecring > > is supposed to contain automatically converted secret keys. > Then something went wrong? Possibly. The dist-upgrade lasted longer than an hour and produced a zillion of message lines. Unpacked software grew by 1.2 GB, plus another 1.2 GB in /var/cache/apt. Hopefully i could roll back by a gzipped plain copy of the virtual disk. > Do you have .gnupg/.gpg-v21-migrated? No. > Are .gnupg/private-keys-v1.d perms correct? $ ls -ld .gnupg/private-keys-v1.d drwx-- 2 thomas thomas 4096 Aug 21 2015 .gnupg/private-keys-v1.d $ ls -lcd .gnupg/private-keys-v1.d drwx-- 2 thomas thomas 4096 Sep 15 17:30 .gnupg/private-keys-v1.d $ ls -alc .gnupg/private-keys-v1.d total 8 drwx-- 2 thomas thomas 4096 Sep 15 17:30 . drwx-- 3 thomas thomas 4096 Sep 5 2015 .. > Are .gnupg perms correct? $ ls -ld .gnupg drwx-- 3 thomas thomas 4096 Sep 5 2015 .gnupg $ ls -lcd .gnupg drwx-- 3 thomas thomas 4096 Sep 5 2015 .gnupg It all worked a year ago. So good that i cannot tell currently which GPG key i used. (Would have to boot the old Sid to get gpg --list-secret-keys working again.) > > Policy 5.5 says that ".changes" stems from control, changelog, or rules. > > Do i have to edit one of them ? > No, you need to read dpkg-source(1) about including the orig tarball sig > into the source package. I read about .asc there, but not about .sig. And the instructions for .asc just say: "Optionally each original tarball can be accompanied by a detached upstream signature" No clarification is to see what "accompanied" means in particular. Is the requirement for a .sig or .asc new since september 2016 ? Back then i did not have an orig.tar.gz.sig on Sid while i ran debuild -S. (Since today have orig.tar.gz.sig stored as neighbor of orig.tar.gz. But that did not help.) I take instructions. They must just be tangible enough. Have a nice day :) Thomas
debuild finds no secret key after dist-upgrade
Hi, after dist-upgrading my Sid VM, gpg forgot my secret key. This keeps "debuild -S" from working successfully. No text is put out by gpg --list-secret-keys I read on https://www.gnupg.org/documentation/manuals/gnupg/GPG-Configuration.html that since GnuPG 2.1 the file ~/.gnupg/secring.gpg is not used any more. It still exists, but gpg --version now says "2.2.0". I am not an expert for gpg. Can anybody help with the transition ? Alternatively: Would it be ok to make my packages with a backup of my Sid which is still in the state before today's dist-upgrade ? Further problem: lintian says Standards-Version: is 4.0.0, upgrading-checklist.txt says it is 4.1.0. -- Long story: I prepared debian/control and debian/changelog of libisofs. But debuild -S fails with messages which i never saw before: - Now running lintian... E: libisofs changes: orig-tarball-missing-upstream-signature libisofs_1.4.8.orig.tar.gz W: libisofs source: newer-standards-version 4.1.0 (current is 4.0.0) Finished running lintian. Now signing changes and any dsc files... signfile dsc libisofs_1.4.8-1.dsc Thomas Schmitt <scdbac...@gmx.net> gpg: skipped "Thomas Schmitt <scdbac...@gmx.net>": No secret key gpg: /tmp/debsign.dxm4g8HA/libisofs_1.4.8-1.dsc: clear-sign failed: No secret key debsign: gpg error occurred! Aborting debuild: fatal error at line 1053: --- My last successful packaging was in September 2016. My $HOME on Sid has a .gnupg directory with files which, except one, are unchanged since two years, when i began to prepare Debian packages. Last year they did suffice. The only file with new timestamp is the empty directory .gnupg/private-keys-v1.d which according to https://www.gnupg.org/faq/whats-new-in-2.1.html#nosecring is supposed to contain automatically converted secret keys. The lintian error is documented as The packaging includes an upstream signing key but the corresponding .asc signature for one or more source tarballs are not included in your .changes file. Policy 5.5 says that ".changes" stems from control, changelog, or rules. Do i have to edit one of them ? The lintian warning about Standards-Version is strange. https://www.debian.org/doc/packaging-manuals/upgrading-checklist.txt says we are at 4.1.0. -- Have a nice day :) Thomas
Riddled by debian-policy 8.1.1 about ldconfig
Hi, i am planning to offer my sponsor new versions of libburn, libisofs, libisoburn. When looking for the needs to change Standards-Version from 3.9.8 to 4.1.0 i stumble over this statement in https://www.debian.org/doc/packaging-manuals/upgrading-checklist.txt 8.1.1 Shared libraries must now invoke "ldconfig" by means of triggers, instead of maintscripts. The packages install libburn.so.4, libisofs.so.6, libisoburn.so.1. But their current ./debian directories do not contain files preinst, postinst, prerm or postrm. Further there is no text "ldconfig" in any file underneath the current ./debian directories. Is this an old omission of the packages ? If so: What shall i read and/or do ? (And why did the old packages work good enough to cause no complaints ?) -- Research difficulties: The term "trigger" riddles me. Is it mentioned in the maintainer's guide ? https://www.debian.org/doc/manuals/maint-guide/ I find https://wiki.debian.org/DpkgTriggers but cannot make a sufficient connection to the prescription in upgrading-checklist.txt or to https://www.debian.org/doc/debian-policy/index.html#ldconfig What is meant by "DEBIAN/triggers" in policy manual and man 5 deb-triggers ? Is there supposed to be a "DEBIAN" directory under ./debian ? -- Have a nice day :) Thomas
Re: C++ help needed with new version of phyml
Hi,
Andreas Tille wrote:
> there is a remaining issue:
> lk.c: In function 'Update_PMat_At_Given_Edge':
> lk.c:2263:31: error: invalid initializer
>int p_matrices[1] = b_fcus->Pij_rr_idx;
Try
int p_matrices[1] = { b_fcus->Pij_rr_idx };
In lk.c there is
void Update_PMat_At_Given_Edge(t_edge *b_fcus, t_tree *tree)
{
...
int p_matrices[1] = b_fcus->Pij_rr_idx;
The definition of type t_edge is in
https://anonscm.debian.org/cgit/debian-med/phyml.git/tree/src/utilities.h
which has
typedef struct __Edge {
...
#ifdef BEAGLE
int Pij_rr_idx;
#endif
...
}t_edge;
So meant is to use scalar value "b_fcus->Pij_rr_idx" as element of the
initializer for the 1-element array "p_matrices".
(I wonder which C compiler lets the programmer get away without using
braces.)
Have a nice day :)
Thomas
Re: C++ help needed with new version of phyml
Hi,
i wrote:
> https://anonscm.debian.org/cgit/debian-med/phyml.git/tree/src/lk.c
> has
> ...
> double branch_lens[1] = { len };
Duh. That's already how i think it should be.
The git code has in line 2264
double branch_lens[1] = len;
Have a nice day :)
Thomas
Re: C++ help needed with new version of phyml
Hi.
Andreas Tille wrote:
> lk.c:2264:31: error: invalid initializer
> double branch_lens[1] = len;
I guess the compiler wants {}-brackets around the scalar value
when it shall initialize a vector.
https://anonscm.debian.org/cgit/debian-med/phyml.git/tree/src/lk.c
has
phydbl len;
...
len = -1.0;
...
double branch_lens[1] = { len };
> lk.c:2263:31: error: invalid initializer
>int p_matrices[1] = b_fcus->Pij_rr_idx;
A thing named Pij_rr_idx could well be a scalar, too, and thus need
brackets.
Have a nice day :)
Thomas
Re: Multiarch hinter on package tracker: Shall i obey ?
Hi, Rebecca N. Palmer wrote: > xul-ext-noscript I will check this out. Have a nice day :) Thomas
Re: Multiarch hinter on package tracker: Shall i obey ?
Hi, Johannes Schauer wrote: > [the need for Javascript] should be reported as a bug against the tracker. Submitted as https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=838178 and subscribed to it. i wrote: > > Doesn't "Architecture: all" imply "Multi-arch: foreign" ? > No. Multi-arch:foreign means that a package of architecture foo is able to > satisfy the dependencies of a package with architecture bar. > [...] > imagine an Architecture:all package doing this: > #!/bin/sh > gcc "$@" > Certainly, what this architecture independent shell script does is > architecture dependent and thus the package containing it cannot be > marked as Multi-Arch:foreign. How can this script be "Architecture:all" if it does not work as expected on some architectures ? https://www.debian.org/doc/debian-policy/ch-controlfields.html#s-f-Architecture says: "all, which indicates an architecture-independent package." So is there a difference between "being architecture independent" and "acting architecture independent" ? (Hopefully i will never have to decide which of both is in effect.) Have a nice day :) Thomas
Re: Multiarch hinter on package tracker: Shall i obey ?
Hi, Johannes Schauer wrote: > Thus, marking it as Multi-Arch:foreign should be correct. Helmut Grohne wrote: > Add "Multi-Arch: foreign" to the binary package section of libisofs-doc. Ok, i will add the line in libisofs, libburn, and libisoburn control files. --- Some more feedback about noob versus documentation: Johannes Schauer wrote: > You have to click at the small downward arrow at the left of the "Multiarch > hinter" text. I saw the mouseover text "Toggle details", but the click only brought me to https://tracker.debian.org/pkg/libisofs# because i have Javascript disabled. Helmut Grohne wrote: > This is a generic tracker.d.o UI aspect and not specific > to the multiarch hinter. Without Javascript the web becomes a much more unexcited place. Regrettably Iceweasel seems not to offer finely granulated enabling. A whitelist would be nice. Johannes Schauer wrote: > The package libisofs-doc is Architecture: all, does not contain any > maintainer scripts and does not have any dependencies on > architecture-dependent packages. Is there a diagram or table which relates Architecture: and Multi-arch: ? > "foreign" is no architecture Architecture: appeared to be nearest to undocumented Multi-arch:. So i had a look there in the hope to find another link. > https://wiki.ubuntu.com/MultiarchSpec Oh. At least the part "Binary package control fields" should be in Debian manuals, too. (Now that i know about it i see the link in the Multiarch/HOWTO. But that is not connected to https://www.debian.org/doc/debian-policy/ and the link is not overly prominent.) Coming back to the diagram question: Doesn't "Architecture: all" imply "Multi-arch: foreign" ? Thanks to Ubuntu, i now know the answer why one year ago i did not mark libisofs-doc by "Multi-arch: same" as the other packages stemming from libisofs. (Possibly lintian kept me from doing it.) Thank you for the explanations. Have a nice day :) Thomas
Multiarch hinter on package tracker: Shall i obey ?
Hi, i am preparing the Debian package for a new upstream release of libisofs and see on its tracker page https://tracker.debian.org/pkg/libisofs a new "action needed": "Multiarch hinter reports 1 issue(s)" The link points to https://wiki.debian.org/MultiArch/Hints But where to see the actual complaint ? Google "multiarch hinter" brings me to https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=833623 where i find in the patch a URL: https://dedup.debian.net/static/multiarch-hints.yaml which says: - binary: libisofs-doc description: 'libisofs-doc could be marked Multi-Arch: foreign' link: https://wiki.debian.org/MultiArch/Hints#ma-foreign severity: low source: libisofs The MultiArch/Hints wiki page says "marking it Multi-Arch: foreign usually is safe." but does not clearly state what it means by "usually". There is no mentioning of "Multi-arch" in https://www.debian.org/doc/debian-policy/ch-controlfields.html nor is there an explanation of "foreign" in https://www.debian.org/doc/debian-policy/ch-controlfields.html#s-f-Architecture More Google brings me to https://wiki.debian.org/Multiarch/HOWTO with the statement: "If a package is marked 'Multi-Arch: foreign', then it can satisfy dependencies of a package of a different architecture." Duh ! I am about as confused as a year ago: "Multi-arch and debian/control" https://lists.debian.org/debian-mentors/2015/09/msg00403.html All packages got "Multi-arch: same" then, except libisofs-doc which got no Multi-arch header at all. I cannot find or remember the reason for that. Could somebody please look into https://tracker.debian.org/media/packages/libi/libisofs/control-1.4.4-1 and tell me what to do ? (And was i really expected to google for a link to the 1.9 MB yaml file ?) Have a nice day :) Thomas
How get overrides into ftp.debian.org/debian/indices/override.sid.main.gz ?
Hi, on the old package tracker https://packages.qa.debian.org/libb/libburn.html i see a problem report libburn-doc: Override says doc - optional, .deb says doc - extra libburn-dev: Override says libdevel - optional, .deb says libdevel - extra Google brought me to https://wiki.debian.org/FtpMaster/Override and http://ftp.debian.org/debian/indices/override.sid.main.gz where i find these lines libburn-doc optionaldoc libburn-dev optionallibdevel The announcement https://lists.debian.org/debian-devel/2011/01/msg00307.html invites me to file a bug if i don't like the override. Well, i don't have a strong opinion myself but rather wonder how it was decided to put the lines into override.sid.main.gz . Are there reverse dependencies which require priority "optional" ? Shall i change the priorities in debian/control ? (Is it a bug or a feature that the new package tracker does not warn ? https://tracker.debian.org/pkg/libburn ) Have a nice day :) Thomas
Secure URI replacement for svn://anonscm.debian.org ?
Hi, lintian.debian.org accuses package libburn of [I] vcs-field-uses-insecure-uri vcs-browser http://anonscm.debian.org/viewvc/pkg-libburnia/trunk/libburn/ vcs-svn svn://anonscm.debian.org/pkg-libburnia/trunk/libburn/ The first URI can simply be changed to https:, but the svn: URI makes me riddle. Simply replacing svn: by https: does not work $ svn co https://anonscm.debian.org/pkg-libburnia/trunk/libburn/ svn: E170013: Unable to connect to a repository at URL 'https://anonscm.debian.org/pkg-libburnia/trunk/libburn' ... I myself address the SVN by svn+ssh://svn.debian.org/svn/pkg-libburnia/trunk because i need commit access. For a test of anonymous checkout i set up a new user by "adduser" with no special permissions and no relation to the SSH software of Debian servers. The insecure URI works just fine for this user: $ svn co svn://anonscm.debian.org/pkg-libburnia/trunk/libburn/ ... Checked out revision 390. But svn+ssh: yields error: $ svn co svn+ssh://svn.debian.org/svn/pkg-libburnia/trunk/ibburn/ ... Are you sure you want to continue connecting (yes/no)? yes svn: E170013: Unable to connect to a repository at URL 'svn+ssh://svn.debian.org/svn/pkg-libburnia/trunk/libburn' ... Same with the anonscm.debian.org hostname: svn: E170013: Unable to connect to a repository at URL 'svn+ssh://anonscm.debian.org/pkg-libburnia/trunk/libburn' Have a nice day :) Thomas
Re: dpkg-checkbuilddeps and apt-get at odds over libacl1-dev
Hi, Christian Seiler wrote: > I would highly recommend you doing an apt-get dist-upgrade again So let's see how a successful end of dist-upgrade looks like: # apt-get dist-upgrade ... 544 upgraded, 44 newly installed, 1 to remove and 0 not upgraded. Need to get 0 B/622 MB of archives. After this operation, 216 MB of additional disk space will be used. ... dpkg: libwebkitgtk-3.0-common: dependency problems, but removing anyway as you requested: libwebkitgtk-3.0-0:amd64 depends on libwebkitgtk-3.0-common (>= 2.4.9). ... dpkg: warning: unable to delete old directory '/etc/iceweasel/searchplugins/common': Directory not empty ... Processing triggers for dbus (1.10.8-1) ... # No fireworks on success ? I reboot the VM and build the libisofs packages ... All looks well. > Btw. why qemu-system? A chroot (see e.g. pbuilder or sbuild) > is perfectly fine for building packages A year ago, it seemed to be the easiest way to get to a Sid environment. The high degree of insulation towards my workstation system increases my courage as sysadmin. Have a nice day :) Thomas
Re: dpkg-checkbuilddeps and apt-get at odds over libacl1-dev
Hi, Christian Seiler wrote: > You are using an older version of lintian (probably the one from Jessie). It is what apt-get "update" and "dist-upgrade" gave me on Sid. It was downloaded during "dist-upgrade": Get:611 http://ftp.de.debian.org/debian unstable/main amd64 lintian all 2.5.45 [1,036 kB] No messages about "Unpacking" or "Setting up" of lintian are to see, though. I meanwhile learned that i discussed this with my sponsor Dominique Dumont in february when i bumped to 3.9.7. Since 3.9.7 was new then, we expected lintian to change its expectations soon after. > https://tracker.debian.org/pkg/debian-policy Yep. That's the address i got from Dominique, together with https://www.debian.org/doc/packaging-manuals/upgrading-checklist.txt which tells me that i can safely claim to comply to 3.9.8. > proper error messages from the lintian version of the release I > am building against. I intend to build for Sid on a Sid qemu-system-x86_64 VM (hosted by Jessie). That's why i wonder why lintian still expects 3.9.6. Trying to apply what i learned today: # dpkg -l lintian Desired=Unknown/Install/Remove/Purge/Hold | Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend |/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad) ||/ Name Version Architecture Description +++-==---= ii lintian2.5.40.2 all Debian package checker But dpkg --configure --pending does not do anything. So i try # apt-get install lintian ... Preparing to unpack .../lintian_2.5.45_all.deb ... Unpacking lintian (2.5.45) over (2.5.40.2) ... Processing triggers for man-db (2.7.5-1) ... Setting up lintian (2.5.45) ... Configuration file '/etc/lintianrc' ... *** lintianrc (Y/I/N/O/D/Z) [default=N] ? n The output of dpkg -l did not change much # dpkg -l lintian Desired=Unknown/Install/Remove/Purge/Hold | Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend |/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad) ||/ Name Version Architecture Description +++-==---= ii lintian2.5.45 all Debian package checker But nevertheless now debuild -S does not complain about the freshly changed "Standards-Version: 3.9.8" as it did before i installed lintian manually. Have a nice day :) Thomas
Re: dpkg-checkbuilddeps and apt-get at odds over libacl1-dev
Hi, the latest proposals by Christian Seiler obviously solved the problem. Many thanks for pulling me out of the swamp. Details: apt-get dist-upgrade wrote: > > Errors were encountered while processing: > >/var/cache/apt/archives/libosinfo-db_0.3.1-1_amd64.deb > > E: Sub-process /usr/bin/dpkg returned an error code (1) Christian Seiler wrote: > First you should check if you have enough disk > space available on all partitions, It is a VM disk image with still lots of free space. The only /dev/sd* partition in use is: Filesystem 1K-blocks Used Available Use% Mounted on /dev/sda1 31864752 16870324 13352752 56% / (Each dist-upgrade eats about 1 GB. Possibly because i have kernel sources installed.) > and then you should probably try to reinstall libosinfo-db ... > And then try again to run apt-get install -f. # apt-get install libosinfo-db Reading package lists... Done Building dependency tree Reading state information... Done You might want to run 'apt-get -f install' to correct these: The following packages have unmet dependencies: ... known list of packages ... # apt-get -f install ... The following packages will be REMOVED: libisoburn-dbg libisoburn-dev libisofs-dbg libisofs-dev Hey, those are mine ! (Installed by dpkg -i.) ... The following NEW packages will be installed: libosinfo-db The following packages will be upgraded: libc-bin libc-l10n libc6 libc6-dbg libpulse-mainloop-glib0 libpulse0 libpython-stdlib locales pulseaudio python python-talloc 11 upgraded, 1 newly installed, 4 to remove and 545 not upgraded. 12 not fully installed or removed. Need to get 0 B/15.3 MB of archives. After this operation, 1,645 kB disk space will be freed. Do you want to continue? [Y/n] y ... Now i am looking at a curses-oid screen "Configuring libc6:amd64" and click "". ... Preparing to unpack .../libc6-dbg_2.22-13_amd64.deb ... Unpacking libc6-dbg:amd64 (2.22-13) over (2.21-7) ... Preparing to unpack .../libc6_2.22-13_amd64.deb ... Checking for services that may need to be restarted... Checking init scripts... Unpacking libc6:amd64 (2.22-13) over (2.21-7) ... Setting up libc6:amd64 (2.22-13) ... Checking for services that may need to be restarted... ... Services restarted successfully. ... Setting up libc6-dbg:amd64 (2.22-13) ... ... Setting up libc-dev-bin (2.22-13) ... Setting up libc6-dev:amd64 (2.22-13) ... ... Setting up libosinfo-db (0.3.1-1) ... Setting up libosinfo-1.0-0:amd64 (0.3.1-1) ... ... Setting up libacl1-dev (2.2.52-3) ... Processing triggers for libc-bin (2.22-13) ... $ debuild -b ... dpkg-deb: building package 'libisofs6' in '../libisofs6_1.4.4-1_amd64.deb'. dpkg-deb: building package 'libisofs-dbg' in '../libisofs-dbg_1.4.4-1_amd64.deb'. dpkg-deb: building package 'libisofs-doc' in '../libisofs-doc_1.4.4-1_all.deb'. dpkg-deb: building package 'libisofs-dev' in '../libisofs-dev_1.4.4-1_amd64.deb'. ... Successfully signed changes file Oh joy ! So i will not yet need my backup of the VM disk image before dist-upgrade. It lasted annoyingly long to copy 32 GB on a real hard disk. But it paid off by soothing my nerves. - Now i can concentrate on the problem why lintian underneath debuild -S says: W: libisofs source: newer-standards-version 3.9.7 (current is 3.9.6) whereas cme says: Warning in 'control source Standards-Version' value '3.9.7': Current standards version is 3.9.8 Have a nice day :) Thomas
Re: dpkg-checkbuilddeps and apt-get at odds over libacl1-dev
Hi, Christian Seiler wrote: > You should be able to fix that via: > dpkg --configure --pending This gives ... dpkg: dependency problems prevent configuration of libacl1-dev: libacl1-dev depends on libc6-dev | libc-dev; however: Package libc6-dev:amd64 is not configured yet. Package libc-dev is not installed. Package libc6-dev:amd64 which provides libc-dev is not configured yet. dpkg: error processing package libacl1-dev (--configure): dependency problems - leaving unconfigured ... Errors were encountered while processing: libosinfo-1.0-0:amd64 samba-libs:amd64 libpulsedsp:amd64 pulseaudio-utils tracker-extract pulseaudio-module-x11 libsmbclient:amd64 libc-dev-bin libc6-dev:amd64 tracker-miner-fs libacl1-dev libncurses5-dev:amd64 As the messages let expect, debuild -b and debclean still complain. > Did you see any messages about "Setting up libacl1-dev"? No. The only "Setting up" about any "libacl" was about libacl1: Unpacking libacl1:amd64 (2.2.52-3) over (2.2.52-2) ... Processing triggers for libc-bin (2.21-7) ... Processing triggers for install-info (6.1.0.dfsg.1-8) ... Setting up libacl1:amd64 (2.2.52-3) ... Processing triggers for libc-bin (2.21-7) ... (Reading database ... 138021 files and directories currently installed.) > Or did apt > stop beforehand because of some other package and it never got to that? Well, now that i know what to look for, it ended suspiciously by Preparing to unpack .../python-minimal_2.7.11-2_amd64.deb ... Unpacking python-minimal (2.7.11-2) over (2.7.11-1) ... Processing triggers for libc-bin (2.21-7) ... Errors were encountered while processing: /var/cache/apt/archives/libosinfo-db_0.3.1-1_amd64.deb E: Sub-process /usr/bin/dpkg returned an error code (1) - apt-get -dist-upgrade reported about libc6-dev: Get:29 http://ftp.de.debian.org/debian unstable/main amd64 libc6-dev amd64 2.22-13 [2,157 kB] ... Preparing to unpack .../libc6-dev_2.22-13_amd64.deb ... Unpacking libc6-dev:amd64 (2.22-13) over (2.21-7) ... ... The subsequent try with apt-get install libacl6-dev reported You might want to run 'apt-get -f install' to correct these: The following packages have unmet dependencies: libc-dev-bin : Depends: libc6 (> 2.22) but 2.21-7 is to be installed libc6-dev : Depends: libc6 (= 2.22-13) but 2.21-7 is to be installed The other packages with unmet dependencies are libosinfo-1.0-0, libpulsedsp, pulseaudio-module-x11, pulseaudio-utils, python, samba-libs. Have a nice day :) Thomas
Re: dpkg-checkbuilddeps and apt-get at odds over libacl1-dev
Hi, Christian Seiler wrote: > What does > dpkg -l libacl1-dev > say? $ dpkg -l libacl1-dev Desired=Unknown/Install/Remove/Purge/Hold | Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend |/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad) ||/ Name Version Architecture Description +++-==---= iU libacl1-dev2.2.52-3 amd64Access control list static librar The apt-get dist-upgrade run reported: Get:396 http://ftp.de.debian.org/debian unstable/main amd64 libacl1-dev amd64 2.2.52-3 [86.5 kB] Get:397 http://ftp.de.debian.org/debian unstable/main amd64 acl amd64 2.2.52-3 [58.7 kB] Get:398 http://ftp.de.debian.org/debian unstable/main amd64 libacl1 amd64 2.2.52-3 [27.8 kB] ... Preparing to unpack .../libacl1-dev_2.2.52-3_amd64.deb ... Unpacking libacl1-dev (2.2.52-3) over (2.2.52-2) ... Preparing to unpack .../acl_2.2.52-3_amd64.deb ... Unpacking acl (2.2.52-3) over (2.2.52-2) ... Preparing to unpack .../libacl1_2.2.52-3_amd64.deb ... Unpacking libacl1:amd64 (2.2.52-3) over (2.2.52-2) ... Processing triggers for libc-bin (2.21-7) ... Processing triggers for install-info (6.1.0.dfsg.1-8) ... Setting up libacl1:amd64 (2.2.52-3) ... Processing triggers for libc-bin (2.21-7) ... ... No error messages to see about "libacl". (I have the complete messages in a file. If you want me to search, just give me an expression.)i Have a nice day :) Thomas
dpkg-checkbuilddeps and apt-get at odds over libacl1-dev
Hi, i am clueless how to untangle the contradicting perceptions of apt-get and dpkg-checkbuilddeps about installation state of libacl1-dev. While running (after debuild -S with normal messages) debuild -b i get dpkg-checkbuilddeps: error: Unmet build dependencies: libacl1-dev dpkg-buildpackage: warning: build dependencies/conflicts unsatisfied; aborting dpkg-buildpackage: warning: (Use -d flag to override.) This is doubly strange, because it worked for libisofs 1.4.2-3 before i did apt-get "update" and "dist-upgrade" today (7 Jul 2016), and because now apt-get install libacl1-dev says libacl1-dev is already the newest version (2.2.52-3). If i use the proposed flag -d debuild -b -d the autotools based detection of libacl headers and .so reports checking sys/acl.h usability... yes checking sys/acl.h presence... yes checking for sys/acl.h... yes checking for acl_to_text in -lacl... yes enabled libacl, local processing of ACL After dpkg -i libisofs6_1.4.4-1_amd64.deb libisofs.so indicates that it is 1.4.4 and willing to operate libacl. But then in the course of the commands on my cheat sheet debclean goes on strike by dpkg-checkbuilddeps: error: Unmet build dependencies: libacl1-dev debuild: fatal error at line 1340: Have a nice day :) Thomas
Package tracker complaint: Problems while searching for a new upstream version
Hi, since a while the package tracker pages of my packages warn "Problems while searching for a new upstream version [high]" See for an example the "action needed" part of: https://tracker.debian.org/pkg/libburn The debian/watch file has this content: version=3 opts="pgpsigurlmangle=s/$/.sig/" \ http://files.libburnia-project.org/releases/libburn-(.*)\.tar\.gz If i run uscan in my local package preparation directory i get: uscan: uscan (version 2.15.10) See uscan(1) for help uscan: Scan watch files in . uscan: ./debian/changelog sets package="libburn" version="1.4.2.pl01" uscan: Newest version on remote site is 1.4.2.pl01, local version is 1.4.2.pl01 uscan:=> Package is up to date uscan: Don't downloading upstream package: libburn-1.4.2.pl01.tar.gz uscan: Downloading OpenPGP signature from http://files.libburnia-project.org/releases/libburn-1.4.2.pl01.tar.gz.sig (pgpsigurlmangled) as libburn-1.4.2.pl01.tar.gz.pgp uscan warn: FAIL Checking OpenPGP signature (no upstream tarball downloaded). Is this the problem which the package tracker complains about ? What am i supposed to do ? Have a nice day :) Thomas
Re: Package libburn-1.4.2.pl01.tar.gz as 1.4.2-2 or as 1.4.2.pl01-1 ?
Hi, Jakub Wilk wrote: > But "pl01" looks weird. What does "pl" stand for? "patchlevel". I carried it as talisman through several software endeavors in memory of the first Linux which i encountered in a dark corner of the office. Installed by our sysadmin from a pile of floppies on an obsolete 80386 from the accounting department. If i remember correctly it was number 13. https://www.kernel.org/pub/linux/kernel/v1.0/CHANGES https://kernel.googlesource.com/pub/scm/linux/kernel/git/nico/archive/+/v0.99-pl13 Have a nice day :) Thomas
Re: Package libburn-1.4.2.pl01.tar.gz as 1.4.2-2 or as 1.4.2.pl01-1 ?
Hi, for the records: The debian/watch rule uversionmangle=s/\.pl\d+$// does not what is needed to let uscan recognize libburn-1.4.2.pl01.tar.gz as newer than libburn-1.4.2.tar.gz I assume it is because both get the same version number "1.4.2" and the older file name is alphabetically sorted after the new one. This rule works better by producing version number "1.4.2.01" uversionmangle=s/\.pl(\d+)$/.$1/ But actually at least the version sequence recognition of uscan works fine without any uversionmangle rule: $ grep opts debian/watch opts="pgpsigurlmangle=s/$/.sig/" \ $ uscan --no-download --report-status --debug ... libburn-1.4.2.pl01.tar.gz (1.4.2.pl01) libburn-1.4.2.tar.gz (1.4.2) Newest version on remote site is 1.4.2.pl01, local version is 1.4.2 => Newer version available from http://files.libburnia-project.org/releases/libburn-1.4.2.pl01.tar.gz -- Scan finished Is there a reason known, why the version used by uscan should not just stay "1.4.2.pl01" ? Have a nice day :) Thomas
Package libburn-1.4.2.pl01.tar.gz as 1.4.2-2 or as 1.4.2.pl01-1 ?
Hi, thanks for the answers to my previous question about Multi-Arch. Incidentially the next packaging of libburn will happen soon, because of an embarrassing bug in its command line frontend cdrskin. This leads me to my next first-time situation: There is now upstream libburn-1.4.2.pl01.tar.gz which replaces libburn-1.4.2.tar.gz Despite the tarball name it unpacks to ./libburn-1.4.2/. The effective difference is a single line of source code (plus some logging and online documentation files). The binary package which actually bears the bug is cdrskin_1.4.2-1. Am i right that in this case all packages from libburn_1.4.2-1.dsc shall be rebuilt ? Shall i keep the name scheme by packaging 1.4.2-2 from the buggy libburn-1.4.2.tar.gz with a debian/patch file ? Or shall i package 1.4.2.pl01-1 without patch ? At the last such occasion, more than 4 years ago, George Danchev packaged 1.1.0.pl01-1. Have a nice day :) Thomas
Re: Package libburn-1.4.2.pl01.tar.gz as 1.4.2-2 or as 1.4.2.pl01-1 ?
Hi, Gianfranco Costamagna wrote: > (well, you might want to ask upstream to call it 1.4.2.1 maybe?) [Changing hats.] I am the upstream myself. .pl01 is tradition. What's wrong with it ? [Changing hats again.] (Upstream is not unteachable. Just would need to be convinced.) i wrote: > > The binary package which actually bears the bug is cdrskin_1.4.2-1. > mmm ok, so a sort of shared library issue. Rather in contrary. Upstream libburn-*.gz contains code for libburn.so and for the executable binary /usr/bin/cdrskin, which offers a CLI roughly compatible to wodim and cdrecord. It uses libburn.so to operate an optical drive. The bug is in the code of cdrskin, outside of libburn.so. So technically, the binary packages libburn4, libburn-dbg, libburn-dev, and libburn-doc do not need to be changed. But they are all derived together with cdrskin from https://tracker.debian.org/pkg/libburn > ABI/API safe, The last (inadverted) wreakage of ABI was in february 2007. I got the SONAME numbering right not before january 2008. Since then i broke many things, but neither API nor ABI. > dpkg --compare-versions You mean this test ? $ dpkg --compare-versions 1.4.2.pl01-1 gt 1.4.2-1 && echo yes yes $ dpkg --compare-versions 1.4.2.pl01-1 lt 1.4.4-1 && echo yes yes $ So it would fit between the current package and the first one of the future upstream release libburn-1.4.4. (1.4.3 is for development between releases.) I am waiting for the new upstream tarball to be recognized by uscan and reported to the package tracker. Hopefully it will be found until tomorrow evening CET. If no objections arise until then, i will go for 1.4.2.pl01-1 from upstream tarball libburn-1.4.2.pl01.tar.gz. Have a nice day :) Thomas
Re: Package libburn-1.4.2.pl01.tar.gz as 1.4.2-2 or as 1.4.2.pl01-1 ?
Hi, i wrote: > >I am waiting for the new upstream tarball to be recognized by > >uscan and reported to the package tracker. > it is reconized as soon as published (uscan locally just does a wget and > looks for versions to parse) It's a local thing too ? I thought it was for the "action needed" frame of tracker.debian.org Normally a day after upstream releases i see a notification there. A link to bug report 813020 of yesterday appeared a few hours ago. debian/watch says: version=3 opts="uversionmangle=s/\.pl\d+$//,pgpsigurlmangle=s/$/.sig/" \ http://files.libburnia-project.org/releases/libburn-(.*)\.tar\.gz Looks like a user named mukidohime-guest refered to my .pl habits in the watch file back in 2008 http://anonscm.debian.org/viewvc/pkg-libburnia/trunk/libburn/debian/watch?r1=11=26 > you are the maintainer and upstream, it is up to you :D Am i not Uploader ? (Despite it is Dominique Dumont who loads up what i commit as maintainer of the Debian package SVN.) Whatever, Debian packaging is about the same kind of riddle to me as is autotools. After a few years of heuristic usage i am now able to write my own feature test macros in acinclude.m4 and wire them through configure.ac and Makefile.am. So not all hope is lost about me and Debian packaging. Have a nice day :) Thomas
Re: Again about Multi-Arch and Pre-Depends
Hi, Gianfranco Costamagna wrote: > Seems you already got your answer :) Is this an encrypted "No" to > > Is there reason not to fulfill his wish ? Have a nice day :) Thomas
Again about Multi-Arch and Pre-Depends
Hi,
i need advise about
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=813020
where Matthias Klose asks me to add
+Multi-Arch: same
+Pre-Depends: ${misc:Pre-Depends}
to debian/control.
I have asked here about this topic a few months ago
https://lists.debian.org/debian-mentors/2015/09/msg00403.html
and understood from the replies that i should not have these
lines in debian/control. See my message links in
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=813020#15
Did i get the answers wrong ?
Does Matthias have a point which was not considered in september ?
Is there reason not to fulfill his wish ?
Have a nice day :)
Thomas
Re: How to find out why debuild -S dislikes dpkg-source --commit ?
Hi,
Dominique Dumont wrote:
> Hmm, you don't detail how you make a change to upstream files.
By editing texts with vim or by copying files from my workstation
into the libisoburn-1.4.2 tree of my Sid VM.
At occasion of release 1.4.0 i afterwards naively applied "debuild -S",
which told me to run "dpkg-source --commit" first. This worked fine
three months ago.
But it seems to be a bad advise if already a patch exists.
Meanwhile i succeeded with production and use of two patches by
operating quilt directly as shown in
https://www.debian.org/doc/manuals/maint-guide/modify.en.html
Current theory about the original problem:
I get the impression that "dpkg-source --commit" yields a good
result only if
- debian/patches contains no patches yet,
- and the directory libisoburn-1.4.2/.pc does not exist.
(It gets created in the course of "dpkg-source --commit" or
"debuild -S". Sometimes it survives the run of "debuild -S".
Sometimes it is gone afterwards. I fail to recognize a pattern.)
This explains why my single patch for 1.4.0-{2,3} worked.
My first patch to 1.4.2-1 would probably have worked if not the .pc
directory had remnants of the previous 1.4.0 patch. (Still unclear
how it sneaked into my new 1.4.2 tree. I dimly remember to have
run "debuild -S" prematurely, when the 1.4.0 patch was still in
the debian/patches directory.)
Whatever, outdated .pc or not:
The second "dpkg-source --commit" patch reproducibly spoils the
subsequent runs of "debuild -S".
The patches apply to disjoint file sets. So i can juggle with them:
If i reduce debian/patches/series to a single line and remove .pc,
then each of the "dpkg-source --commit" patches works.
As soon as i add the second patch name to the series file,
"debuild -S" complains and demands me to revert that second patch.
I added the quilt gestures to my cheat sheet and will not use
"dpkg-source --commit" any more.
Have a nice day :)
Thomas
How to find out why debuild -S dislikes dpkg-source --commit ?
Hi, after a few weeks of other leisures i came back to Debian packaging for a new upstream release of my software. Currently i feel plain stupid because i fail to install a patch which shall silence a few lintian warnings about the man pages. I unpacked the upstream tarball, moved it to the parent of the unpacked upstream tree and renamed it to libisoburn_1.4.2.orig.tar.gz. Then i copied the ./debian subtree from my local packaging svn instance into the unpacked upstream tree. I wrote a new version section into debian/changelog and removed an obsolete patch from debian/patches. All is well as long as i have no debian/patches. I can build and install the .deb files (debuild -S, debuild -b, dpkg -i). But if i make changes to the upstream files and run debclean dpkg-source --commit then afterwards debuild -S fails with dpkg-source: info: local changes detected, the modified files are: ... dpkg-source: error: aborting due to unexpected upstream changes, see /tmp/libisoburn_1.4.2-1.diff.ARfBHF The file /tmp/libisoburn_1.4.2-1.diff.ARfBHF contains the reverse changeset of the patch which was created by dpkg-source --commit. All affected files have new timestamps and show the old content before my changes. I.e. the state as in libisoburn_1.4.2.orig.tar.gz The error abort of debuild -S persists even after a previous failed run restored the old content of the files. The problem vanishes only after i remove the patch. So i appears that my patch does influence the expectations of dpkg-source. But it either does not get applied after unpacking the source, or the result is in some way overridden by a later copying from original tarball. I created the work directory tree by cd ~ wget http://files.libburnia-project.org/releases/libisoburn-1.4.2.tar.gz cd ...path.../debian_dir tar xzf ~/libisoburn-1.4.2.tar.gz mv ~/libisoburn-1.4.2.tar.gz libisoburn_1.4.2.orig.tar.gz cd libisoburn-1.4.2 cp -a ...path.../svn/libisoburn/debian debian The last action copied the ./debian directory of the local SVN instance of svn://anonscm.debian.org/pkg-libburnia/trunk/libisoburn/ (Changes to ./debian will later be copied back and committed to SVN.) As said: Except the patching problem, this setup does what i expect. I deem it quivalent to what is described in https://www.debian.org/doc/manuals/maint-guide/first.en.html Am i wrong ? Have a nice day :) Thomas
Bug#801237: mactel-boot review
Hi, (still being subscribed on debian-mentors to learn customs) Christian Kastner wrote: > That article seems to contain some misinformation. For example: > | So why is the system unbootable? The problem is that the Mac > | bootloader expects the EFI partition to be formatted as HFS+, the > | typical Mac filesystem. > I have a MacBook Air (2013), and the EFI system partition came formatted > as FAT. Because my program xorriso serves as producer of bootable ISOs, i can tell that GRUB2 program grub-mkrescue under some configuration circumstances wants HFS+ tree and metadata, marked by an Apple Partition Map and blessed by whatever makes holy. It gets this from xorriso mainly by HFS+ code contributed by Vladimir Serbinenko. The Fedora LiveCD ISO has a small HFS+ image file, also marked by APM. The HFS+ image gets made as disk data file by some tools. The ISO is made by genisoimage. MBR, GPT, and APM are patched in by program "isohybrid" from SYSLINUX. Debian amd64 and i386 installation ISOs still have a (useless) APM left over from the setup described in http://mjg59.dreamwidth.org/11285.html "Anatomy of a Fedora 17 ISO Image". That APM marks no HFS+ but only a FAT. (Made by xorriso.) So Matthew Garrett and Vladimir Serbinenko know Macs which need HFS+ and some which do not. Steve McIntyre seems not to have had contact with owners of the HFS+ addicts. (Me neither. I just write bytes on amd64 hardware.) Debian powerpc ISOs have HFS metadata without "+" and are made by genisoimage. I am not aware whether these boot on some other, probably even older Macs. I understand that older Macs make few difference between HDD and CD when it comes to booting. APM or nothing. Newer UEFI compliant machines have to look for El Torito on CD, and for MBR partitions or GPT on HDD. But the partition content is in both cases the same. Have a nice day :) Thomas
Re: Modifying the environment variables of a parent process
Hi,
Gianfranco Costamagna wrote:
> first I guess this isn't the right place, but well, the damage is done :)
Maybe we should move to debian-u...@lists.debian.org
if we discuss on. :))
Markhazy wrote:
> > the desired effect
> > user@user:-$ cdiv -1 5 6 0
> >-0.16667 + j0.8333
> > user@user:-$ echo $AC
> > -0.16667
> > user@user:-$ echo $ACIM
> > 0.8333
Parent environment is out of reach. At least by tradition.
Shell functions can set their caller's variables.
How about this one decoding the output line of cdiv:
my_cdiv () {
read AC plus_dummy ACIM <
Re: Suspicious file changes in -dbg between old and new packages
Hi, Gianfranco Costamagna wrote: > So how did it work for Thomas with the previous version installed? The /usr/bin/cdrskin files of 1.4.0-2 and 1.4.0-3 are identical (at least their MD5s are). Curse or blessing of reproducible building. Niels Thykier wrote: > * The path where the binaries were compiled > * The options given to gcc when compiled These were identical. > * Time and day, if such are included in the code (__DATE__ macros and such). If i set such a thing at compile time then i don't get commended by the ReproducibleBuilds project. :)) (That's why i dropped my plan to add argument "buildstamped" to the debuild "make" run. One todo point less.) So it is explainable that symbol loading works between fewly different package versions. I would still like to know how i managed to break it. Just to be able to avoid this in future. Will watch this when i make packages of the future upstream releases. Have a nice day :) Thomas
Re: Suspicious file changes in -dbg between old and new packages
Hi, i wrote: > > And why does it still work when i install back 1.4.0-2 ? Gianfranco Costamagna wrote: > well, if -2 and -3 didn't change symbols (e.g. you didn't patch the source > code), why shouldn't it work? I still wonder why it did not work on the first try. I had installed cdrskin and libburn-dbg multiple times since the change from debhelper 8 (.so in -dbg) to debhelper 9 (.build-id files in -dbg). Then Andrey reports success, i re-install cdrskin without a good reason, and suddenly the debugging symbols are found by gdb. The web tells me that there is gdb option -symbols=file and a startup file .gdbinit. But i did not use the option and the whole Sid disk does not have a file .gdbinit. The name of the symbol file is in the binary: $ strings /usr/bin/cdrskin | grep 66fcd4b56be0f2cc505c54b4ab566e582c8b1e 66fcd4b56be0f2cc505c54b4ab566e582c8b1e.debug So the feature seems to be based on a compile time trick. I was not able to break it by further installations. The initial riddle stays unsolved. Have a nice day :) Thomas
Multi-Arch and debian/control
Hi,
while preparing the correction for a buildd failure on Debian
GNU/kFreeBSD i got a lintian complaint from kfreebsd-i386 7.9
(the current "stable"):
E: libburn4: missing-pre-dependency-on-multiarch-support
I found
https://wiki.debian.org/Multiarch/Implementation#dh.281.29_and_autotools
This page seems to be recent, as it talks of "debhelper (>= 9)".
It prescribes to add to multi-arch dynamic library packages
Pre-Depends: ${misc:Pre-Depends}
Multi-Arch: same
Is this still a valid prescription ?
(Why then is amd64 Sid lintian silent about it ?)
--
I came to debian-policy, "8.2 Shared library support files":
"If your package contains files whose names do not change with
each change in the library shared object version, you must not
put them in the shared library package."
But inherited from my many predecessors i have some doc stuff
in the runtime library package:
$ apt-file list libburn4
libburn4: /usr/lib/x86_64-linux-gnu/libburn.so.4
libburn4: /usr/lib/x86_64-linux-gnu/libburn.so.4.93.0
libburn4: /usr/share/doc/libburn4/AUTHORS
libburn4: /usr/share/doc/libburn4/NEWS.gz
libburn4: /usr/share/doc/libburn4/README.gz
libburn4: /usr/share/doc/libburn4/changelog.Debian.gz
libburn4: /usr/share/doc/libburn4/changelog.gz
libburn4: /usr/share/doc/libburn4/copyright
Do i have to remove the /usr/share/doc files from libburn4 ?
(Actually the prescription says that i'd even have to remove
libburn.so.4, as it says "names" and not "content".
Somehow not very realistic.)
-
What to do with the other packages from libburn ?
The Multiarch page prescribes to add the Pre-Depends line
to each package which provides a shared library.
libburn-dbg seems to modify libburn.so.4.X.0 .
libburn-dev installs a link libburn.so to libburn.so.4.X.0 .
Do they need multi-arch headers in debian/control ?
-
Project details: https://tracker.debian.org/pkg/libburn
Have a nice day :)
Thomas
Re: Multi-Arch and debian/control
Hi,
> > E: libburn4: missing-pre-dependency-on-multiarch-support
Niels Thykier wrote:
> What version of Lintian are you using?
On the kfreebsd-i386 it is Lintian v2.5.10.4.
On amd64 Sid, where i did not get the error, it is v2.5.36.1.
I am aware that the lintian on kfreebsd is outdated.
But is this true for
https://wiki.debian.org/Multiarch/Implementation
too ?
> the multiarch-support Pre-Depends is no longer required.
So no headers
Pre-Depends: ${misc:Pre-Depends}
Multi-Arch: same
in debian/control ?
Sorry for stupidly asking back, but the documentation situation
is confusing, especially since the tag i got is not in the list
https://lintian.debian.org/tags-all.html
and the description of the similar tag
https://lintian.debian.org/tags/pre-depends-directly-on-multiarch-support.html
says
"multiarch-support is inserted into Pre-Depends via ${misc:Pre-Depends}
by dh_makeshlibs. In order to be able to remove the multiarch-supporti
package from glibc without updating every package,
Pre-Depends: ${misc:Pre-Depends} should be used instead."
(I cannot spot a difference between the one and the other.)
Have a nice day :)
Thomas
Re: Multi-Arch and debian/control
Hi,
Jakub Wilk wrote
> "Pre-Depends: ${misc:Pre-Depends}" was necessary to squeeze->wheezy
> upgrades; it is no longer required.
Ok. No such headers. Despite online docs.
(Were to complain about outdated wiki.debian.org articles ?)
> > > debian-policy, "8.2 Shared library support files":
> > > "If your package contains files whose names do not change with each change
> > > in the library shared object version, ..."
> > libburn4: /usr/share/doc/libburn4/NEWS.gz
> Each of these pathnames contains the shared object version ("4"), so
> everything is in order here.
Ahum. I would consider "93.0" a part of the version "4.93.0".
But if "library shared object version" actually means SONAME ...
i wrote:
> > libburn-dbg seems to modify libburn.so.4.X.0 .
Jakub Wilk wrote:
> Um, "modify"?
My mistake. I interpreted the difference between "dpkg -c"
/usr/lib/debug/.build-id/25/3fbbcf11829f90ddc91f8cf5194ac5278f804a.debug
/usr/lib/debug/.build-id/8b/12591e70f8814691eb7ae38612fe396d63fd67.debug
versus "apt-file list"
libburn-dbg: /usr/lib/debug/usr/bin/cdrskin
libburn-dbg: /usr/lib/debug/usr/lib/libburn.so.4.85.0
in a way that the salad name files lead to a new libburn.so.4.85.0
and a new cdrskin binary.
But since i upgraded apt-file's data base, it also reports
libburn-dbg:
/usr/lib/debug/.build-id/25/3fbbcf11829f90ddc91f8cf5194ac5278f804a.debug
libburn-dbg:
/usr/lib/debug/.build-id/8b/12591e70f8814691eb7ae38612fe396d63fd67.debug
and no cdrskin or libburn.so.4.85.0 any more.
Also i tried whether dpkg -i libburn-dbg_1.4.0-3_amd64.deb
changes the date or size of the libburn.so.4.93.0 file.
It does not.
The production process of libburn-dbg is still a riddle to me.
It has no .install file, just a libburn-dbg.docs.
Have a nice day :)
Thomas
Re: Multi-Arch and debian/control
Hi, i wrote: > > (Were to complain about outdated wiki.debian.org articles ?) Wookey wrote: > It's a wiki - just fix it :-) Shouldn't i have a clue of the topic first ? Have a nice day :) Thomas
Suspicious file changes in -dbg between old and new packages
Hi, as mentioned in my other thread of today, my lib*-dbg*.deb packages do not contain the same files as their 2 year old predecessors. apt-file list from old libburn-dbg (1.3.2-1.1): libburn-dbg: /usr/lib/debug/usr/bin/cdrskin libburn-dbg: /usr/lib/debug/usr/lib/libburn.so.4.85.0 libburn-dbg: /usr/share/doc/libburn-dbg/AUTHORS libburn-dbg: /usr/share/doc/libburn-dbg/NEWS.gz libburn-dbg: /usr/share/doc/libburn-dbg/README.gz libburn-dbg: /usr/share/doc/libburn-dbg/changelog.Debian.gz libburn-dbg: /usr/share/doc/libburn-dbg/changelog.gz libburn-dbg: /usr/share/doc/libburn-dbg/copyright New libburn-dbg (1.4.0-2): libburn-dbg: /usr/lib/debug/.build-id/25/3fbbcf11829f90ddc91f8cf5194ac5278f804a.debug libburn-dbg: /usr/lib/debug/.build-id/8b/12591e70f8814691eb7ae38612fe396d63fd67.debug libburn-dbg: /usr/share/doc/libburn-dbg/AUTHORS libburn-dbg: /usr/share/doc/libburn-dbg/NEWS.gz libburn-dbg: /usr/share/doc/libburn-dbg/README.gz libburn-dbg: /usr/share/doc/libburn-dbg/changelog.Debian.gz libburn-dbg: /usr/share/doc/libburn-dbg/changelog.gz libburn-dbg: /usr/share/doc/libburn-dbg/copyright The new ones get installed in /usr/lib/debug/.build-id/. Is the new package content wrong ? If so, how to fix it ? I am not aware to have changed the content lists of libburn4 or the debian/rules file, except: "Removed dependency on doxygen" http://anonscm.debian.org/viewvc/pkg-libburnia/trunk/libburn/debian/rules?r1=296=295=296 "Switched from debhelper 8 to 9" http://anonscm.debian.org/viewvc/pkg-libburnia/trunk/libburn/debian/libburn4.install?r1=297=296=297 libburn-dbg has no own .install file and afaiks never had one. Where to learn more about -dbg packages and their production process ? Have a nice day :) Thomas
Re: Multi-Arch and debian/control
Hi, Gianfranco Costamagna wrote: > can you please close 679249, 796147, 796146, 679265and so on? I am waiting for decisions about the future maintainer team structure. Currently there is a high-latency DD in the team and a sponsor outside of it. I would like to lure the sponsor into the team and/or to reactivate my old friend and DD George. Therefore i did not ITA the other two bug pairs after my sponsor showed me what i did wrong with the first attempt. Is it appropriate to ITA them while it is not clear whether any adoption will actually happen ? As said, it depends on decisions by old and new friends whom i do not want to push. Have a nice day :) Thomas
Re: Suspicious file changes in -dbg between old and new packages
Hi, Ansgar Burchardt wrote: > This is fine. debhelper installs detached debug symbols in a different > location since compat level 9. Very good. My sponsor will love to hear that no action is needed. This raises the next question: How do i make use of libburn-dbg ? (E.g. for testing whether it works.) I installed it on amd64 Sid and run $ gdb /usr/bin/cdrskin ... Reading symbols from /usr/bin/cdrskin...(no debugging symbols found)...done. (gdb) q There seems to be no other "cdrskin" binary installed: $ find /usr -name cdrskin /usr/share/doc/cdrskin /usr/bin/cdrskin (I would also advise to compile -O1 or -O0 before debugging. Just adding symbols to the -O2 library might not give much opportunity for insight.) > [...] As far as I remember this was done to handle multi-arch better (to avoid > having -dbg packages for different architectures install files to the > same location so that they can be co-installed). I already wondered when i riddled about multi-arch and -dbg. But at that time i always stared at the old package listing. Then i saw the strange files and made a strange theory, which made Jakub say "Um". (Thanks for that.) > There should be a recent thread on -devel@ Still coping with the evolutionary step from "User:" to "Uploader:", i think that i'm not yet ready for -devel@. Have a nice day :) Thomas
Re: Multi-Arch and debian/control
Hi,
> leving them open is just "wrong" I'd say :)
I take this as a clear instruction and send mails to
79614{5,6,7}-d...@bugs.debian.org.
Have a nice day :)
Thomas
Re: Multi-Arch and debian/control
Hi, > When a person Orphan a package, he loses the right to complain when somebody > steps up and maintains it :) Well understood. But George is one of my first users, my first packager (although others were the DDs then), and a good friend. So as long as there is hope to lure him out of his real life ... > BTW if you loose interested in them, please just open an Orphan package > by yourself I would still appreciate an active DD in the team. (I do the ./debian/* SVN, the mailing list and the bugs. But it would help everybody if i'd not make Debian specific decisions in the packages.) As for new packages: I plan to prepare them one or two weeks after each of my upstream releases. About two times per year. Well, after i solved my -dbg riddle. Have a nice day :) Thomas
Re: Suspicious file changes in -dbg between old and new packages
Hi, i wrote: > > $ gdb /usr/bin/cdrskin Andrey Rahmatullin wrote: > I get "Reading symbols from cdrskin...Reading symbols from > /usr/lib/debug/.build-id/25/3fbbcf11829f90ddc91f8cf5194ac5278f804a.debug... > done." A positive test. Thanks ! (Check on todo list) This gave me reason to do again dpkg -i cdrskin_1.4.0-3_amd64.deb from my locally built libburn packages. Suddenly it works: Reading symbols from /usr/bin/cdrskin...Reading symbols from /usr/lib/debug/.build-id/c0/66fcd4b56be0f2cc505c54b4ab566e582c8b1e.debug...done. But i am very sure to already have had installed cdrskin-1.4.0-3_amd64.deb (candidate package) together with libburn-dbg_1.4.0-3_amd64.deb. And why does it still work when i install back 1.4.0-2 ? Have a nice day :) Thomas
Re: What to do with a kernel bug which lets my package work result look bad ?
Hi, Henrique de Moraes Holschuh wrote: > Any name we return can colide, unless we return something that is impossible > for isofs + extensions to return in the first place. Rock Ridge permits any name of any length. Theoretically a NM could contain NUL or '/' characters. (One should catch them.) NM's specified purpose is "to support POSIX-style or other names". It turned out that libisofs has half of the same problem as the kernel. Its constant LIBISOFS_NODE_NAME_MAX is 255 and causes mindless truncation of names at this length. No provisions for uniqueness or UTF-8 correctness to see. And of course no knowledge about the neighbors in the same directory. I will try to develop a solution in libisofs. Maybe it will become suitable for the kernel, too. i wrote: > > the actually needed fix is the protection of the > > innocent. > Yes. It matters little what kind of insanity results from a corrupt/broken > filesystem, as long as we defang it enough for it to not be a viable way to > attack userspace apps. I convinced myself that the two callers of the buggy function can handle returned lengths up to 255 characters. (See #789300, inspection of dir.c and namei.c) Any proposals how to stress test my custom kernel ? I tared up multiple times my /home backup ISO which contains names up to 255 bytes, Mumbay song titles, and similar challenges from working on backup topics. Have a nice day :) Thomas
Re: What to do with a kernel bug which lets my package work result look bad ?
Hi, i built my first kernel the Debian way and filed a kernel bug. To Debian for now: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=798300 I decided not to mention ISO producer programs by "affects". They work fine with the kernel. How long should i wait before trying at upstream ? (Urgency is low. But when it begins to smell ...) Have a nice day :) Thomas
Re: What to do with a kernel bug which lets my package work result look bad ?
Hi, Rebecca N. Palmer wrote: > Package: src:linux There seems to be no such package name. I got the source by apt-get install linux-source so i guess it would be ok to use that package name. > 'affects' means it will appear in your package's bug list but be marked as > linux's bug. It does not keep xorriso (or cdrkit's genisoimage) from working properly. It just fails to work properly with flawless output from those programs. Does that qualify for 'affects' ? Henrique de Moraes Holschuh wrote: > Ugh. Yeah, that code looks broken at first glance. Two sins: It hits the innocent and it defaces its victims. > Maybe it should instead drop the long name, and return the ISOFS name, > instead. This might reduce the probability of a name collision, but can still collide with some short Rock Ridge name. Better would probably be a hash text derived from all available information about the file, which is not very much at that level of code, i fear. E.g. a SHA256 of the full really oversized name, plus some constant salt, should reduce the probability to an acceptable level and still show reproducible names. But the actually needed fix is the protection of the innocent. > However, one has to check the code throughoutly to ensure it can deal with > the 255-bytes size. Will dive into the code and already began to read http://kernel-handbook.alioth.debian.org Maybe i can make experiments with s/254/256/ and/or with truncation to exactly the assumed maximum size. > Opening a bug report on bugzilla.kernel.org for 'isofs' would be the typical > way to go about it, I guess. Shall i do already now or better after i exhausted my code reading skills and/or managed to get a kernel running with s/254/256/ ? > OTOH, it is a >10-year old bug, so there are some kudos and credit to be > proud of for anyone that fixes it :-) Is there a find-the-oldest-bug contest ? And is the list open for mere oddities, too ? (I have some Linux timestamp peculiarities of which i really don't know whether i shall replay them in libisofs.) > The code in fs/isofs/rock.c looks like it has lots of cowebs and some > bitrot, though. The equivalents in FreeBSD, OpenSolaris, and NetBSD are even more dusty. Solaris still calls it "High Sierra". To our luck there are userland tools to read ISO 9660 independently of the kernels. Among them is my xorriso. Have a nice day :) Thomas
Re: What to do with a kernel bug which lets my package work result look bad ?
Hi, Rebecca N. Palmer wrote: > > Package: src:linux i wrote: > There seems to be no such package name. Well, there is one. Only the package search engine does not show it: https://packages.debian.org/search?keywords=linux=names=stable=all But the Debian kernel handbook demands me to install it. It worked. Now i have two Linux source trees linux-4.1.6/ linux-source-4.1/ Shrug. Have a nice day :) Thomas
What to do with a kernel bug which lets my package work result look bad ?
Hi, maybe somewhat off topic, but i don't know where else to ask for advise: While doing regression tests with my readily prepared packages (*), i stumbled over a bug in fs/isofs/rock.c which truncates filenames of length 254 or 255 to quite random lengths and thus can let readdir(3) emit multiple identical names in the same directory. I can reproduce. I see the buggy constant "254" in line 270 of https://github.com/torvalds/linux/blob/master/fs/isofs/rock.c as well as in my Sid's /usr/src/linux-source-4.1/fs/isofs/rock.c. I see a coarse reaction which leads to the really bad behavior in userland. What to do now with this knowledge ? Does Debian have a kernel department ? With round tuits ? (On LKML they will at best urge me to fix it myself. But i have my own alternative ready in userland. And my kernel skills stem from a short adventure in NetBSD's ISO 9660 driver. This constant "254" might have a good reason. Who can tell ?) (*) I found two sponsor candidates. Now i am waiting whether the packages will get de-orphaned or re-parented. Thanks again for this list's support. Have a nice day :) Thomas
Re: How much is lintian an expert in english language ?
Hi,
Russ Allbery wrote:
> (Not 100% sure whether "eventual" is a term of art here, or is intended to
> have the English meaning of something that isn't implemented yet but may
> appear later.
That's one of the bugs of german-english dictionaries.
Our "gegebenenfalls" ("ggf.") means "if the case is given",
"if applicable", but is often translated in dictionaries with
"eventually". This use is widespread in the web, too.
I now try with
In general there are two approaches for writing media:
A permissive mode selected by option -tao which needs
no predicted track size and can use multi-session
capabilities if offered by drive and medium.
A more restrictive mode -sao [...]
(I compensated the loss of words by new ones which shall
clarify the technical situation.)
While waiting for a human or automatic reaction on
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=796145#57
i changed some "allow" without object
http://libburnia-project.org/changeset/5475
> Both native and non-native
> speakers, on first draft, often add far more words than are required.
That's due to the euphoria when a newly programmed feature
passed the first tests and needs to be documented. The
programmer still knows too much about the motivation and
difficulties. I tend to put more emphasis on the novelty than
it actually deserves in comparison to older features.
CD TAO was the reason why i started to learn how to operate
a CD burner. I was really proud when it was achieved. So the
most obvious exaggeratons are likely to occur with this topic.
In general there are technically correct docs, human readable
docs, and no docs. I try to produce the first kind:
After you found the solution of your problem by try-and-error,
you can read in the man page why it works.
Have a nice day :)
Thomas
Re: How much is lintian an expert in english language ?
Hi,
Russ Allbery wrote:
> That intransitive form of allow is almost always used
> in combination with the preposition "for".
But why then isn't the lintian check called
"allows to allows for" or "allow is not the right word here" ?
I get the suspicion that "allows to" is a germanism stemming
from "erlaubt es". This means "is a way to enable something".
In this theory, "allows one to" would be an english allergic
reaction on poorly translated german which then translates
back to really substandard german.
("erlaubt es einem" ... shudder.)
I guess that my correction of man cdrskin kills a few
correct usages of "allow", too:
http://libburnia-project.org/changeset/5474
I got new instructions about cme, copyright files, and
repository URL now. So the upstream work to improve all
docs will have to wait a while.
Have a nice day :)
Thomas
Re: Bug#679265: RFH,O: libisoburn -- command line ISO-9660 and Rock Ridge manipulation tool [ITA]
Hi, In that case, it is important that you set yourself to the owner of the O bugs, and retitle them to ITA, as I outlined here: Sorry for the misformat. It's just that after three years of no interest a potential helper for the obsolete RFH appeared. He was not amused to learn that i already am at the packages. Some preliminary warning sign was needed. I will have to re-read all the hints, advises, and proposals which i had to put aside on my way to gain control over the content of the packages and the packaging project. Especially the rules under which circumstances i am allowed to do what with bugs from other people. Bear with me. I will improve. Promised. Have a nice day :) Thomas
Re: How much is lintian an expert in english language ?
Hi, Jakub Wilk wrote: See bug #795158. It seems all to hang at Justin B Rye's statement Most English transitive verbs are pretty easygoing about being turned into intransitives like this, to allow is one of the exceptions Sez who ? http://www.merriam-webster.com/dictionary/allow has 5 items of transitive verb and 2 of intransitive verb. Justin states further (along with e.g. to merit - you can't say does this merit? - or to recognise - you can't say I recognise). I recognize that i have not enough clue to judge the quality of a given piece of english language. So probably i will follow Justin's advise: my preferred fix is usually to try to eliminate the word allow from the text completely, I burried resp. a few weeks ago, i can as well burry allow. With low priority. Have a nice day :) Thomas
How much is lintian an expert in english language ?
Hi, with my upstream hat on i got the proposal to change in documentation allow to to allow one to. This seems to be inspired by lintian tags like https://lintian.debian.org/tags/spelling-error-in-manpage.html The long list of complaints on this page and the quite inconclusive google results let me riddle why this is considered a minor possible bug or policy violation. It seems a widely used phrase. Is there some deeper explanation of allows to allows one to available ? Something which would convince a teacher of english language ? If i am not convinced as upstream, am i supposed to apply a patch in the Debian package, nevertheless ? Have a nice day :) Thomas
Re: Questions before my first upload attempt
Hi, i am trying to follow the instructions for SSH setup with alioth, after having been accepted as project member of https://alioth.debian.org/projects/pkg-libburnia/ and promoted to admin in one sweep. The project has an SVN and two mailing lists. A ssh-rsa key has been uploaded via https://alioth.debian.org/account/editsshkeys.php https://wiki.debian.org/Alioth/Svn sends me to https://wiki.debian.org/Alioth/SSH which tells me to be mistrusting about the host key fingerprint. It points to https://db.debian.org/machines.cgi?host=moszumanska which says SSH host fingerprint: ssh-rsa d7:0b:26:5c:7a:5d:56:40:a9:e0:5d:f4:e1:70:88:bf But with my first attempt of logging in, i see: $ ssh svn.debian.org The authenticity of host 'svn.debian.org (5.153.231.21)' can't be established. RSA key fingerprint is SHA256:VbwoMdcyFWByMDQrIOcaUL6c16LV6+80G9+Rs2rtA8E. Are you sure you want to continue connecting (yes/no)? traceroute (from Sid VM's host, as VM sees * * *) says: 10 po1.ar1.dc1.yo26.yrk.bytemark.co.uk (91.223.58.29) 50.893 ms 51.077 ms 51.463 ms 11 bm-bl1.debian.org (5.153.231.241) 46.995 ms 47.236 ms 47.558 ms 12 moszumanska.debian.org (5.153.231.21) 48.540 ms * * Shall i trust it ? Where to report the mismatch (if it is not my fault ...) ? Have a nice day :) Thomas
Re: Questions before my first upload attempt
Hi, sorry for the noise. After learning that it is a feature of Sid's ssh client, it was not too hard to find ssh -o FingerprintHash=md5 svn.debian.org which displays RSA key fingerprint is MD5:d7:0b:26:5c:7a:5d:56:40:a9:e0:5d:f4:e1:70:88:bf. Jessie's ssh client says by default: RSA key fingerprint is d7:0b:26:5c:7a:5d:56:40:a9:e0:5d:f4:e1:70:88:bf. Is this a bug of the wiki, of db.debian.org/machines.cgi, or of ssh client ? Do the wiki and the machine database have bug package names ? Have a nice day :) Thomas
Re: Questions before my first upload attempt
Hi, Gianfranco Costamagna: (please open an RFS if you need a sponsor, otherwise it might be difficult to track packages reviews and to actually have an upload) I will do if my direct approach to already interested people yields no success. But currently i seem to have upload problems. [1] ftp://mentors.debian.net/ This is empty, 12:59 CEST. I configured dput for http, as shown in http://mentors.debian.net/intro-maintainers Strangely it said ftp and not http in its messages: - $ dput -f libburn_1.4.0-1.1_source.changes Trying to upload package to ftp-master (ftp.upload.debian.org) Checking signature on .changes gpg: Signature made Mon 24 Aug 2015 08:47:49 AM CEST using DSA key ID ABC0A854 gpg: Good signature from Thomas Schmitt scdbac...@gmx.net Good signature on /home/thomas/projekte/debian_dir/libburn_1.4.0-1.1_source.changes. Checking signature on .dsc gpg: Signature made Mon 24 Aug 2015 08:47:49 AM CEST using DSA key ID ABC0A854 gpg: Good signature from Thomas Schmitt scdbac...@gmx.net Good signature on /home/thomas/projekte/debian_dir/libburn_1.4.0-1.1.dsc. Uploading to ftp-master (via ftp to ftp.upload.debian.org): Uploading libburn_1.4.0-1.1.dsc: done. Uploading libburn_1.4.0.orig.tar.gz: done. Uploading libburn_1.4.0-1.1.debian.tar.xz: done. Uploading libburn_1.4.0-1.1_source.changes: done. Successfully uploaded packages. - So i now switch ~/.dput.cf to ftp and try again. - $ dput -f libburn_1.4.0-1.1_source.changes Trying to upload package to ftp-master (ftp.upload.debian.org) Checking signature on .changes gpg: Signature made Mon 24 Aug 2015 08:47:49 AM CEST using DSA key ID ABC0A854 gpg: Good signature from Thomas Schmitt scdbac...@gmx.net Good signature on /home/thomas/projekte/debian_dir/libburn_1.4.0-1.1_source.changes. Checking signature on .dsc gpg: Signature made Mon 24 Aug 2015 08:47:49 AM CEST using DSA key ID ABC0A854 gpg: Good signature from Thomas Schmitt scdbac...@gmx.net Good signature on /home/thomas/projekte/debian_dir/libburn_1.4.0-1.1.dsc. Uploading to ftp-master (via ftp to ftp.upload.debian.org): Uploading libburn_1.4.0-1.1.dsc: 553 Could not create file. Leaving existing libburn_1.4.0-1.1.dsc on the server and continuing NOTE: This existing file may have been previously uploaded partially. For official Debian upload queues, the dcut(1) utility can be used to remove this file, and after an acknowledgement mail is received in response to dcut, the upload can be re-initiated. Uploading libburn_1.4.0.orig.tar.gz: 553 Could not create file. Leaving existing libburn_1.4.0.orig.tar.gz on the server and continuing NOTE: This existing file may have been previously uploaded partially. For official Debian upload queues, the dcut(1) utility can be used to remove this file, and after an acknowledgement mail is received in response to dcut, the upload can be re-initiated. Uploading libburn_1.4.0-1.1.debian.tar.xz: 553 Could not create file. Leaving existing libburn_1.4.0-1.1.debian.tar.xz on the server and continuing NOTE: This existing file may have been previously uploaded partially. For official Debian upload queues, the dcut(1) utility can be used to remove this file, and after an acknowledgement mail is received in response to dcut, the upload can be re-initiated. Uploading libburn_1.4.0-1.1_source.changes: done. Successfully uploaded packages. - Could not create file and Successfully uploaded packages in one run ? Shall i try to create a Debian archive .commands file for dcut(1) ? Have a nice day :) Thomas
Re: Questions before my first upload attempt
Hi, i wrote: Add myself to Uploaders ? Am i entitled ? Christian Kastner wrote: However: it appears that this package is team-maintained. In that case, you leave the Maintainer as-is, and add yourself to Uploaders. Adding myself to uploaders leads to new local warnings: W: libburn source: changelog-should-not-mention-nmu W: libburn source: maintainer-upload-has-incorrect-version-number 1.4.0-1.1 So for a test, i removed the the surplus .1 and the line * Non-maintainer upload. from changelog. Seems to be ok. I can run dpkg-i although the version number is now lower than the previously installed one. Unpacking libburn4 (1.4.0-1) over (1.4.0-1.1) ... IMHO, taking over this package correctly would mean to also take over the alioth project as admin by 1. Requesting to join the team 2. Having the current admin set your new account as admin 3. Removing the old admin I was already made aware that there is a repo to be taken over. (The project page itself is very sparse.) But currently i am still overwhelmed by packaging. My plan is to get the three packages presentable, approach my potential sponsors for adoption, and then try to understand the rest of the infrastructure. The current admin is very busy in real life. Else i would have used him as sponsor and the packages were already in sid. The task to update the packages to newest upstream was up to now among the easiest ones. Once you have completed the above, add yourself to Uploaders. Not being there yet, i stay with NMU for now and will put my three packages on display. It's time to look for sponsors and to get their opinion about my packaging. Gianfranco Costamagna wrote: that way at the next soname bump you won't need to change the install files too. ($somebody might object that having the 4 makes you sure you don't miss a soname bump) There will be no SONAME change as long as i am the upstream developer. ABI compatibility is one of the most important goals of my development. (Last inadverted breaking of ABI was with 0.3.2 in february 2007, but i got SONAME correct only with version 0.4.2 in february 2008.) not sure why you ship a static library, A former maintainer of libburn has put these files into the libburn-dev.install file. I am not yet apt to judge whether this should be changed. One reason might have been that dbg had versions which did an awful job with dynamic libraries. Did not try yet with my two month old Jessie. I have my own static compilation setup for upstream development purposes. I see Jakub Wilk and Paul Wise discussing the general issue. Of course i would obey an instruction to remove the *.a libraries from *-dev.install, if the discussion comes to such a conclusion. sure, mentors allows to dput, dput and dput again the same package. Other communities put high value on not overwriting the same version of a tarball or package. Glad to see that mentors allows it for development work. if you are talking about the package at #679249 you might directly ask this to the maintainer As said above, George Danchev has no time to sponsor or coach me. He rather orphaned the packages now, to allow me to apply for sponsorship by others: #796145, #796146, #796147. I thought they were orphaned since two years, when George told me he could not longer maintain them. But that last step was made only a few days ago, when he was pointed by a bystander to my questions on debian-user. We do not split in anger or something like that. It's just that real life prevents him from covering my upstream releases. I got an offer of help by Steve McIntyre, who uses xorriso for debian-cd. But before bothering him with technical questions, i preferred to bother people who obviously don't mind noobs and their difficulties. Thanks a lot to this list and to all who answered. Dominique Dumont expressed interest, too. He pointed me to the task of taking care of the repo. (I'm still very clueless with this topic.) I will also inform the neighboring team which maintains dvd+rw-tools. ... still waiting for my new dput -f of libburn to show up on the web site ... it's nearly two hours ago now. Shall i re-dput ? After what waiting time ? Have a nice day :) Thomas
Re: Questions before my first upload attempt
Hi, gregor herrmann wrote: You're uploading to ftp.upload.debian.org and not to mentors.d.n. Duh (once again). This explains a lot. Meanwhile i bothered it with a libisofs upload attempt, too. Need to make me an upload script. I began to write quite a desparate answer to Gianfranco and to think about a version bump. But now it accepts my upload without -f $ dput mentors libburn_1.4.0-1.1_source.changes ... Uploading to mentors (via ftp to mentors.debian.net): ... ... patiently waiting for mail now ... oh joy ! Upload shows effect on package/libburn: All green, except The uploader is not in the package's Maintainer or Uploaders fields. I'm back on tracks, as it seems. Will upload the other two packages, contact my sponsor candidates, and ask them whether i shall file an RFS, additionally. Have a nice day :) Thomas
Re: Questions before my first upload attempt
Hi,
i worked a bit more on my local libburn package.
Shall/can i replace my yesterday upload by help of dput -f ?
Regarding http://mentors.debian.net/package/libburn ,
i have hoepfully solved the complaints under
Package closes bugs in a wrong way
- Bugs #702621 and #746254 got reassigned to libburn4.
- Closes: #751501 was moved from libburn changelog to libisofs
changelog.
(Good catch. Is this check available locally before upload ?)
The failure of debuild -b with compat 9 still riddles me.
With 9 it finally complains
dh_install: libburn4 missing files (debian/tmp/usr/lib/libburn.so.4*),
aborting
It seems to have outsmarted itself by previous
./configure ... --libdir=\${prefix}/lib/x86_64-linux-gnu ...
With 8, the configure option --libdir is not used.
After debuild -b with compat 9 i have:
$ ls debian/tmp/usr/lib
x86_64-linux-gnu
$ ls debian/tmp/usr/lib/x86_64-linux-gnu
libburn.a libburn.la libburn.so libburn.so.4 libburn.so.4.93.0 pkgconfig
The complete ./configure line of 8 is:
./configure --build=x86_64-linux-gnu --prefix=/usr
--includedir=\${prefix}/include --mandir=\${prefix}/share/man
--infodir=\${prefix}/share/info --sysconfdir=/etc --localstatedir=/var
--disable-silent-rules --libexecdir=\${prefix}/lib/libburn
--disable-maintainer-mode --disable-dependency-tracking
Of 9:
./configure --build=x86_64-linux-gnu --prefix=/usr
--includedir=\${prefix}/include --mandir=\${prefix}/share/man
--infodir=\${prefix}/share/info --sysconfdir=/etc --localstatedir=/var
--disable-silent-rules --libdir=\${prefix}/lib/x86_64-linux-gnu
--libexecdir=\${prefix}/lib/x86_64-linux-gnu --disable-maintainer-mode
--disable-dependency-tracking
Do i have to make a kindof cleanup when switching from
compat 8 to 9 ?
Have a nice day :)
Thomas
Re: Questions before my first upload attempt
Hi, i was able to fix debuild -b with compat 9 by changing the content of debian/libburn4.install from debian/tmp/usr/lib/libburn.so.4* usr/lib to debian/tmp/usr/lib/x86_64-linux-gnu/libburn.so.4* usr/lib/x86_64-linux-gnu Next i wanted to ask: Is this remedy a valid solution ? But now i see that Niels Thykier wrote: If your package is simple, you can use: usr/lib/*/file instead of usr/lib/file Duh. Of course there's not only amd64 in the world. (At least i did find the right files on my own.) So this in libburn4.install: debian/tmp/usr/lib/*/libburn.so.4* and in libburn-dev.install: debian/tmp/usr/include/libburn/libburn.h debian/tmp/usr/lib/*/libburn*.a debian/tmp/usr/lib/*/libburn.so debian/tmp/usr/lib/*/pkgconfig/libburn-1.pc Works fine on amd64. = Remaining questions: - Shall i dput -f now ? - What to do about the complaint: The uploader is not in the package's Maintainer or Uploaders fields Add myself to Uploaders ? Am i entitled ? = New question: I would like to add an argument buildstamped to the make run of libisoburn. Where to read about how to achieve this ? - Have a nice day :) Thomas
Re: Questions before my first upload attempt
Hi, i wrote: $ gpg --verify ../libisoburn_1.4.0-1.1_source.changes ... gpg: WARNING: This key is not certified with a trusted signature! Johan Van de Wauw wrote: This indicates that you have not set a trust level for that key. If you run gpg --edit-key ABC0A854 type trust and set to: I trust fully (or whatever you trust yourself :-)) The warning vanished only after i set trust to 5 = I trust ultimately. W: libburn4: hardening-no-relro usr/lib/libburn.so.4.93.0 What debhelper version are you using (check debian/compat). Was 8. Inherited from Debian packages libburn_1.3.2-1.1, libisofs_1.3.2-1.1, libisoburn_1.3.2-1.1. With 9, the warning changes to W: libburn source: package-needs-versioned-debhelper-build-depends 9 I assume because of debian/control line Build-Depends: dh-autoreconf, pkg-config, debhelper (= 8), libcam-dev [kfreebsd-any] Changing to (= 9) silences the warning of debuild -S. But now debuild -b fails until i revert the change in debian/compat. I.e. back to 8. With 9, debuild -b ends by: dh_install: libburn4 missing files (debian/tmp/usr/lib/libburn.so.4*), aborting debian/rules:5: recipe for target 'binary' failed make: *** [binary] Error 2 Further above i see no problem messages which would deviate from those of the successful run with compat 8. We will have to postpone this problem until i succeeded with uploading. --- http://mentors.debian.net/intro-maintainers The proposed line dput mentors your_sourcepackage_1.0.changes does not really match my two candidates libburn_1.4.0-1.1_amd64.changes libburn_1.4.0-1.1_source.changes but i guess it's $ dput mentors libburn_1.4.0-1.1_source.changes ... Good signature on /home/thomas/projekte/debian_dir/libburn_1.4.0-1.1.dsc. Uploading to mentors (via http to mentors.debian.net): Uploading libburn_1.4.0-1.1.dsc: done. Uploading libburn_1.4.0.orig.tar.gz: done. Uploading libburn_1.4.0-1.1.debian.tar.xz: done. Uploading libburn_1.4.0-1.1_source.changes: done. Successfully uploaded packages. Confirmation mail arrived: http://mentors.debian.net/package/libburn http://mentors.debian.net/debian/pool/main/libb/libburn/libburn_1.4.0-1.1.dsc I do not yet flag it as seeking a sponsor. Firstly, because i want to polish it and upload its two mates libisofs and libisoburn. Secondly because i already got two offers on debian-user and will probably approach directly the maintainer team of dvd+rw-tools, which already accepted one of my patches. I am not sure whether any of them will have time to be my mentor, besides the minimum checks needed to authorize my uploads. So please help me to thoroughly polish the packages. I'll apply changes to all three and will upload the other two when libburn is neatly shining. --- Glimpse on http://mentors.debian.net/package/libburn : Looks like i need to re-assign some bugs first. My changelogs close them where they belong, not where they have been reported to. Debhelper compatibility level 9 is not entirely true, i fear. See above. vcs-field-not-canonical looks like the tail tip of the big problem to take care of debian-specific repositories. The uploader is not in the package's Maintainer or Uploaders fields: I do not feel authorized to add me to any of those fields. Have a nice day :) Thomas
Re: Questions before my first upload attempt
Hi, somehow i managed to upload the non-working variant with Build-Depends: dh-autoreconf, pkg-config, debhelper (= 9), libcam-dev [kfreebsd-any] and probably debian/compat content 9. Can i overwrite the upload ? If i have to make a new version, then i first wait for some feedback. Have a nice day :) Thomas
Re: Questions before my first upload attempt
Hi,
thanks for the answers. They helped me to achieve progress.
So i really had to pass the can-he-install-sid-? test.
I already began installing yesterday evening.
It is instructive, but i would have preferred to postpone
the qemu adventures until i explore passthrough of DVD drives.
How about publicly available accounts on a sid machine,
where programmers like me can test building of their packages ?
Don't get me wrong. I am not complaining because i have no
other fun in life.
I report this because i believe to see an important reason
why Debian packages of software like mine are outdated.
Christian Kastner wrote:
$ sudo vmdebootstrap \
A link to an example like this should augment the sportive
statement
[...], built against a current version of sid.
This simple sentence hides a multitude of sins -- it can be
a complex process.
in
https://wiki.debian.org/DebianMentorsFaq#How_do_I_make_my_first_package.3F
I think Debian loses potential packagers after they read it
as it is now. Not every programmer is an enthusiastic sysadmin.
Well, i seem to have achieved it the hard way.
But if i ever have to do it again, i will gladly try your
proposal.
---
I read
https://wiki.debian.org/InstallFAQ
and experienced:
- Any senseful combination of
{i386 mini.iso, amd64 mini.iso}
x {qemu-system-i386 , qemu-system-x86_64}
x {-cdrom , -hda}
is broken currently. xorriso is not to blame. El Torito
boot record and MBR properly lead to isolinux.bin which
gets stuck after its startup message. Famous last words
are ETCD or EHDD, depending on -cdrom or -hda.
- debian-8.1.0-amd64-netinst.iso by default installs a
kind of tablet PC desktop with no visible means to get
a shell prompt. (I made the mistake to accept the pre-
selected package collection.)
I had to boot into rescue mode and zap
/etc/X11/default-display-manager in order to get at least
a kernel console after normal boot. (Thx Google.)
The console goes black after a few minutes so that i cannot
see the user input prompts, but have to watch the host
performance meters to know when it is time to press Enter.
This way i managed to apt-get dist-upgrade to testing.
One upgrade step more needed to get to sid.
When the proposal about vmdebootstrap arrived, i decided
to go on with what i already started.
But that i did via SSH. (Praise Google for showing all the
cries for help and the rescue efforts of brave fellow users.)
Now i have:
# uname -a
Linux ts6-sid 4.1.0-1-amd64 #1 SMP Debian 4.1.3-1 (2015-08-03) x86_64
GNU/Linux
Cannot really tell whether this is sid. I did my best, at least.
/etc/apt/sources.list currently has these two active lines
deb http://ftp.de.debian.org/debian/ unstable main
deb-src http://ftp.de.debian.org/debian/ unstable main
Anything more to add there ?
---
and inside the VM, adapt to your liking.
(Back to stable ? ~:o))
You only want to sign the final result of your packaging efforts;
signing every intermediate result of the development process is
unnecessary and annoying, hence the -us -uc.
So signing in this context means no -us -uc.
Thanks for clarifying this.
By the way, in that case, you should retitle the respective bug reports
from O for orphaned to ITA for intent to adopt.
How to do this ?
(I see few risk that anybody would take care of the packages
in the next days.)
Back to the work of packaging:
Do i get it right that i should do
apt-get dist-upgrade
every time before i begin to package something ?
Have a nice day :)
Thomas
Re: Questions before my first upload attempt
Hi, Danny Edel wrote: Debian actually has ready-made VM scripts for you. https://wiki.debian.org/sbuild They urgently need advertising at the entry points of mentors.debian.net and at the upload instructions. call debuild -S on your host machine first: This will create a .debian.tar.xz and a (signed) .dsc file in .., then you can call sbuild --dist sid your-package_version.dsc. If that goes through, you know your dsc is good and you can upload it to mentors with dupload --to mentors my.changes. I was desparately digging the Debian docs for something like this. Hm. What shall i do with my brand new sid VM now ? I copied the development workshop from the host and installed the needed packages for dpkg-buildpackage. The first round of packages is built as was done on the host machine and installed. Next i plan to test the proposed command debuild. So many branches to explore ... https://wiki.debian.org/sbuild#Setup writes: 5 ... *logout* and *re-login* I'm logged in by my X session and want to keep it running. Line 2 seems newer than the explanation beneath. So line 5 would be covered by: The fourth line is to update the active user group set to include sbuild. logout-relogin or use newgrp sbuild in your current shell. Aha. Enlightenment. A fruitless google search of active user group set already brought me to the suspicion that something around newgroup(1) was meant. so make sure to have 10G space there. 2 TB free. My mass storage still produces an echo when i shout. Well, i need to make some progress with uploading. So i'll go on with the VM for now. I need to learn a bit more about what sbuild does. On the long run it looks cleaner. Which one to install ? dput: /usr/bin/dput dput-ng: /usr/bin/dput My Jessie obviously has dput installed. So many branches ... Have a nice day :) Thomas
Re: Questions before my first upload attempt
Hi,
Danny Edel wrote:
The main advantage of [sbuild] is the ...and throw everything away to get a
clean starting point, so you have a reproducible and minimal build
environment.
Yep. Cleaner and thus more sensible to changes in environment.
As said, i deem the source very portable and thus fewly vulnerable
to environmental changes. Other projects would scream first.
But i cannot be so sure with the Debian aspects of the package.
Especially since my understanding is mostly heuristic. (Like
i began to operate the autotools files when i took over libburn.)
A related advantage of the sbuild concept is that the user
is not exposed to the ever changing desktop weirdness.
Have backups.)
Wanting to have backups caused my mail address and my endeavor
into ISO 9660 and optical burning.
pbuilder. As an alternative to dput{,-ng}, there is also dupload.
This puts up a nice space of combinations.
I wouldn't say there's a definitive better one, but having more than one
tool for the same problem might turn in handy if one has a bug and/or
breaks.
It would be a bit easier for new tools if not the wikis
would only talk about the old ones. Like about mkisofs and
cdrecord, rather than xorriso.
But for new users it is beneficial to have a more narrow guidance.
Take a look at man devscripts
The offspring of a long evolution, as it looks.
Christian Kastner wrote:
The reason I posted the qemu-based approach was that it was, at first
sight, not as complex as the sbuild approach, seeing as it only required
one command.
Funny thing is that i would have followed your proposals
if each had not come just after i managed to find some
solution myself.
The docs cannot be too bad, after all. Half of my
helpful Google hits were inside Debian.
Its terminology could need some standardization and care
towards offering the right keywords for web search.
---
http://mentors.debian.net/intro-maintainers :
dput wants to be configured.
Tonight.
I hope nobody minds that i did not yet try to solve
any old shortcommings of the ./debian files in the
orphaned packages.
Just give me instructions.
Thanks again for the answers and proposals.
Have a nice day :)
Thomas
Re: Questions before my first upload attempt
Hi, after some fight with the keyring i am able to produce signed packages on sid. Will this warning be a problem ? $ gpg --verify ../libisoburn_1.4.0-1.1_source.changes gpg: Signature made Fri 21 Aug 2015 10:44:01 PM CEST using DSA key ID ABC0A854 gpg: Good signature from Thomas Schmitt scdbac...@gmx.net gpg: WARNING: This key is not certified with a trusted signature! gpg: There is no indication that the signature belongs to the owner. Primary key fingerprint: 44BC 9FD0 D688 EB00 7C4D D029 E9CB DFC0 ABC0 A854 --- I need a translator from debian-speak to english (or german). My first runs of debuild showed lintian warnings, which i could silence, except this class from debuild -b: W: libburn4: hardening-no-relro usr/lib/libburn.so.4.93.0 W: cdrskin: hardening-no-relro usr/bin/cdrskin W: libisofs6: hardening-no-relro usr/lib/libisofs.so.6.76.0 W: libisoburn1: hardening-no-relro usr/lib/libisoburn.so.1.97.0 W: xorriso: hardening-no-relro usr/bin/xorriso This package was likely not built with the default Debian compiler flags defined by dpkg-buildflags. What does it want me to do ? Where ? In debian/rules ? In upstream ? Examples available ? -- Riddle: During my work something caused unconditional regeneration of unpacked libisoburn-1.4.0/xorriso/xorrecord.info The versions of makeinfo differ between release machine and sid, which causes different .info result. In subsequent runs of debuild this causes a complaint about uncommitted changes. The makeinfo run is indeed in my upstream autotools empire. But it should only trigger if .info is missing or outdated. In a build run out of the upstream tarball, the makeinfo run is not triggered. On the same sid. Only one of three .info gets regenerated in this way: -rw-r--r-- 1 thomas thomas 41768 Aug 21 22:25 xorriso/xorrecord.info -rw-r--r-- 1 thomas thomas 291521 Aug 21 14:56 xorriso/xorriso.info -rw-r--r-- 1 thomas thomas 108424 Aug 21 14:56 xorriso/xorrisofs.info I restored xorriso/xorrecord.info from .orig.tar.gz, but with the next debuild -b it happened again, despite .info having a new timestamp. So i stored a copy of the original on disk in order to restore the victim after each pbuild run. To my surprise, after i copied this disk file to xorriso/xorrecord.info for the first time, it does not get regenerated any more. What is the magic difference between tar xzf and cp ? Why does it not happen with ./configure make from upstream tarball ? The time on VM is about one minute behind the host. Although this is strange, it cannot explain the riddle. -- dput configuration must wait until tomorrow. Just a quick backup of my sid workshop and then to bed. Have a nice day :) Thomas
Questions before my first upload attempt
Hi, i am the upstream developer of freshly orphaned packages libburn4, libisofs6, libisoburn1, cdrskin, and xorriso. Now preparing to get them in shape for sponsorship and for closing old bug reports. Steve McIntyre offered his help (i hope this means sponsorship). But knowing how busy he is, i ask my pre-upload questions here first. Achieved so far: Package upstream sources are updated. Files in ./debian have been adapted. debian/changelog files got new sections 1.4.0. The packages do build by dpkg-buildpackage -us -uc with not more warnings than the current Debian packages of version 1.3.2. The .deb packages do install by dpkg -i. Installed binaries and Xfburn, a user of the libraries, do start up and look ok. Installed xorriso was tested in my afternoon backup script. I dare to trust it. Currently i am stuck at: - https://wiki.debian.org/DebianMentorsFaq#How_do_I_make_my_first_package.3F Put a package together, built against a current version of sid. I'm on Jessie 8.1. The dependencies of the packages in question are very basic. The package sources are portable to any X/Open compliant system. Tested upstream on very old GNU/Linux, FreeBSD, Solaris, and NetBSD. I understand i have to submit source packages anyway. So is there a way to do my packaging work in Debian 8.1 ? (The PackagingTutorial says i shall write 9 into debian/compat. Is that enough of a sid ?) Else: Is there a shortcut description how to quickly set up Debian package development in a virtual machine and how to keep it up to date ? (Hardware is plenty but my own VM scripts date back to Debian 6.) - I still did not find a hands-on description of fulfilling the demand of http://mentors.debian.net/intro-maintainers: All packages must be signed with the GnuPG key you configured in your control panel. http://mentors.debian.net/my has my public key now. I guess this does the necessary configuration. But how to use gpg or other programs to sign the packages ? As GNU maintainer i use on tarballs gpg -o ...sig -u ... on announcement messages gpg --clearsign ... Suspiciously all newbie tutorials for Debian packaging propose to use options -us -uc, which i understand prevent some kind of signing. Have a nice day :) Thomas
