Without this patch The C function pkg_name_is_illegal still allows
upper case characters und underscores in packages names.
This especially causes dpkg-deb to still be able to create packages
with upper case characters in them. (underscores are already impossible
because check_control_file checks
x27;
time behaviour).
Bernhard R. Link
--
F8AC 04D5 0B9B 064B 3383 C3DA AFFC 96D1 151D FFDC
ring
.gitignore as dpkg-source does by default is the only sane thing to do.
(I only wished it would by default also ignore debian/.git* and thus
include the debian/.git-dpm in the default ignore list).
I might be wrong, but having issues with .gitignore in the generated
source package is a dgit-onl
ulprits now.
This also effects the normal dpkg-source --build run:
It silently ignores unrecorded changes and just creates a source package
without them.
Bernhard R. Link
--
F8AC 04D5 0B9B 064B 3383 C3DA AFFC 96D1 151D FFDC
--
To UNSUBSCRIBE, email to debian-dpkg-requ...@lis
out-of-archive packaging and
> infrastructure, etc. So I'm not sure this seems appealing… but I'll
> make a note of at least checking it.
At least I'd suggest to not allow it in the Debian archive yet. Not
everything dpkg supports must be allowed by policy. (Like upper case
hat already knows those architectures.).
Something like a "any-FOO" matching any debian architecture "*-FOO" and
"FOO" would be something simple.
Having magic like any-arm also matching armhf means it cannot be
processed without having special knowledge of the architect
Really? This is far too complicated for most programs to implement
properly. I'd suggest to rather fix dpkg (and also fix policy. The footnote
describes absolutely nothing currently, and having such important fields
a meaning that you cannot calculate without knowing what architectures
the system fi
on.pm| 14 +-
2 files changed, 10 insertions(+), 10 deletions(-)
* Guillem Jover [130209 18:43]:
> On Sat, 2013-02-09 at 15:18:04 +0100, Guillem Jover wrote:
> > On Sat, 2013-02-09 at 15:03:31 +0100, Bernhard R. Link wrote:
> > > Instead of doing the magic
Instead of doing the magic of generating a version string without epoch
and revision and a version string without epoch in
Dpkg::Source::Package, extend Dpkg::Version's as_string function to
support generating that string.
---
scripts/Dpkg/Source/Package.pm |6 +-
scripts/Dpkg/Version.pm
ses.
Only stylistics: How about not using "flawed"? Something like
"Also the way library SONAMEs are represented in shlibs
files makes it difficult to use them in some unusual corner cases."?
Bernhard R. Link
--
To UNSUBSCRIBE, email to debian-dpkg-requ...@l
cause not the distribution field is different.
Bernhard R. Link
--
To UNSUBSCRIBE, email to debian-dpkg-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20110922150745.ga26...@server.brlink.eu
r again joining in late in the distribution, but what is the use
case of this field exactly?
Currently I can only see possible abuses but no proper uses for it, so
unless there is something I miss, I'd rather request that variable to
be removed, as it can only harm.
Bernhard R. Link
--
* Raphael Hertzog [110801 08:58]:
> On Sun, 31 Jul 2011, Bernhard R. Link wrote:
> > While I wholeheartly welcome adding such a script, I am surprised why
> > it is made so complicated and hard to read.
> >
> > Is there a reason for dpkg_late_eval?
>
> Performan
mply
CFLAGS := $(shell dpkg-buildflags --get CFLAGS)
and so on in buildflags.mk and
DEB_HOST_ARCH := $(shell dpkg-architecture -qDEB_HOST_ARCH)
and so on in architecture.mk?
Bernhard R. Link
--
To UNSUBSCRIBE, email to debian-dpkg-requ...@lists.debian.org
with a subject of "unsu
t at hand. I personally would prefer to at
least have an option to error out when getting something without
symbols)
Hochachtungsvoll,
Bernhard R. Link
--
To UNSUBSCRIBE, email to debian-dpkg-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact lis
h information, as it is not hard to see what belongs
together and what changes there are.
Once those collects more than 1 or 2 different modifications that may
also be in the same files I do not think that scales very well. (Just as
having only a single .diff.gz would not scale that well).
Hochachtun
e cannot tell upstream
or some other project to just cherry-pick a specific commit to get the
fix.
Hochachtungsvoll,
Bernhard R. Link
--
To UNSUBSCRIBE, email to debian-dpkg-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive:
http://lists.debian.org/20100329115521.ga...@pcpool00.mathematik.uni-freiburg.de
* Raphael Hertzog [100328 11:44]:
> On Sat, 27 Mar 2010, Bernhard R. Link wrote:
> > I'm guess this discussiong is slowly leaving debian-dpkg@ topic,
> > though...
>
> Definitely not. I plan to integrate VCS knowledge in dpkg-dev at some
> point and I like those disc
ed
stuff usually is, while something merged and merged again is usually
nothing upstream will want to pull.
My solution against the "rebasing published branches" is thus to not
publish it as branch, but only as tag and as part of the history of the
debian branch (and of course as t
m is just a rebase
of a patched branch to a new upstream. That means if the patches are
stored as commits those commits can be rebased and one has the changes
and information to create the updated patches from created by the same
resolution. Perhaps something like that is possible with bzr, too.
Ho
at the same time, causing 27 processes running simultanously.
That's why submakes do not get -j3, but instead get told to interact
with the parent make, so that all possible submakes together process 3
things at the same time, but still being able to do so in multiple
subdirectories (if th
yed), do not make me too afraid of using MD5.
Actually I think that might even rather be a job for something like crc32,
md5 already looks like overhead, and sha256 feels like being longer than
the description itself.
Hochachtungsvoll,
Bernhard R. Link
--
To UNSUBSCRIBE, e
ncilliary data.
I think the idempotency is not that much of a trouble (if a package
cannot guarantee to have it idempotent if only stuff in the specified
packages changed, it can just ignore the information). The storage of
the information might be a bit more of a hassle. (Especially as it
ing all information.
To avoid being something like that impossible by design, having a way
to specify a trigger happened and the names of the packages (or other
free-form data given to a explicit trigger call) handed to the trigger
processor.
Hochachtungsvoll,
Bernhard R. Link
--
&qu
pto.so.0.9.7
| usr/lib/v8/libssl.so.0.9.7
| usr/lib/v9/libcrypto.so.0.9.7
| usr/lib/v9/libssl.so.0.9.7
| usr/share/doc/libssl0.9.7/changelog.Debian.gz
| usr/share/doc/libssl0.9.7/changelog.gz
| usr/share/doc/libssl0.9.7/copyright
In other words: Problem solved since sarge.
Hochachtungsvoll,
aware application is already able to install a .deb when
executing it. (Like many do when you double click on them).
Hochachtungsvoll,
Bernhard R. Link
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
aps you need to also get
initscripts 2.86.ds1-1 from woody before that. (Or installing both
at once).
Hochachtungsvoll,
Bernhard R. Link
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
tc/alternatives name.
> How do maintainers keep coordinated on this sort of thing?
I think image-viewers are preferably handled by the mime database,
i.e. registering there and calling it by see(1).
Hochachtungsvoll,
Bernhard R. Link
--
The man who trades freedom for security does not deserve
* Adam Heath <[EMAIL PROTECTED]> [030912 17:50]:
> > wrong. The following patch resolves the problem for me:
>
> Please regenerate this patch, using -u, and attach it to the email, instead of
> including it inline.
Hmpf, I guess there has to be something I forget with anything...
diff -r -u dpkg-
following patch resolves the problem for me:
diff -r dpkg-1.10.10.old/debian/changelog dpkg-1.10.10/debian/changelog
0a1,6
> dpkg (1.10.10-0.1) local; urgency=low
>
> * Fix setjmp bug in standard_startup
>
> -- Bernhard R. Link <[EMAIL PROTECTED]> Fry, 12 Sep 2003 14:09:00 +0
I never looked into set/longjmp and am not able to read
mips-assembler, but I guess the following means that
set/longjmp is broken. Branden, could you test the program
on necrotic to verify this might be the cause there, too?
The following is what I think dpkg is doing there without
anything unrel
s problem is most likely caused by an invalid program counter or
stack pointer.
However, if you think GDB should simply search farther back
from 0x2ad09570 for code which looks like the beginning of a
function, you can increase the range of the search using the `set
heuristic-fence-post' command.
32 matches
Mail list logo
