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
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
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
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
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
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
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
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
-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
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
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
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
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
>
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
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
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
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
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
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
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
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
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.)
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
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
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 ?
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
>
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
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.
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":
> > >
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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"
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
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
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
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
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
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
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.
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
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
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.
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.
Hi,
Rebecca N. Palmer wrote:
> xul-ext-noscript
I will check this out.
Have a nice day :)
Thomas
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
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.
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
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
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;
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
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
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
c 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! Abor
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
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
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
70 matches
Mail list logo
