not repacked to
remove non-dfsg-free stuff.
For other reasons I think "ds" is sometimes chosen. (Though there
are not really that many other legitimate reasons).
Bernhard R. Link
--
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of "u
git-dpm. That stores patches as permanent git commits.
That's not the work-flow you described, but perhaps nearer to what you
want.
http://wiki.debian.org/PackagingWithGit/GitDpm
http://git-dpm.alioth.debian.org/
Bernhard R. Link
--
To UNSUBSCRIBE, email to debian-mentors-requ
heir dependencies. (So for Debian packages
they can be removed without any problems. The simple solution of
unconditionally removing them might not be feasible for upstream, though).
Bernhard R. Link
--
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject
en got so far as to looking at the actual
package).
Bernhard R. Link
--
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive:
http://lists.debian.org/20101109174420.ga18...@pcpool00.mathematik.uni-freiburg.de
lly the mixing of namespaces for
filenames), there are sadly enough libraries already doing it this way
and there is technically no problem with it.
Bernhard R. Link
--
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact
* Muammar El Khatib [110104 22:43]:
> Hi Bernhard,
>
> On Tue, Jan 04, 2011 at 05:36:37PM +0100, Bernhard R. Link wrote:
> > * Muammar El Khatib [110104 16:52]:
> > > I'm maintaining a library which new upstream version is creating at build
> > > time
Copyright (C) 1997 Rick Huebner
Some of which seems to even be compiled and explicitly have BSD like licenses
requiring to include their copyright statement (which your binary packages do
not).
I've not looked at the actual packaging or the build process.
Bernhard R. Link
--
To
variable a normal user may have
set for normal development, so a package should not look at them.
Using dpkg-buildflags should be done from debian/rules,
dpkg-buildpackage setting those flags is just a workaround so that
broken packages get some sane defaults of flags.
Bernhard R. Link
--
tc are:
- every user understands how to change them (no need to find out where
to copy a script so it overrides the distribution suplied one).
- if there are changes the usual conffile handling make sure one notes
if the original file changes
Bernhard R. Link
--
To UNSUBSCRIB
* Michael Lustfield [110227 22:12]:
> It builds these binary packages:
> tdc- Tiny Dockable Clock (tdc) is a simple and tiny dockable clock.
> tdc-dbg- Tiny Dockable Clock (tdc) Debugging Symbols.
Does this really justify a debug package? I'd rather guess not.
uot;,
-"B c #00",
+"B c None",
"C c #C80000",
"D c #E4",
"E c #85",
Bernhard R. Link
--
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble?
LC_CTYPE, which is even more likely to cause
problems than LC_MESSAGES).
I'd say a proper test-suite already sets LC_ALL=C itself unless
it's locale independent, so if you have a test-suite not doing
this please also report this upstream.
Bernhard R. Link
--
To UNSUBSCRI
the past. (I always assumed for that
to have an effect it would need something like the -v to
dpkg-buildpackage needed on Debian's side for a Closes in a
previous version not uploaded to have an effect.).
Bernhard R. Link
--
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.
gt;
> Ok, I can add this flags.
Please do not add -Wl,--as-needed unless you are sure you understand
what it does. --as-needed can change the runtime behaviour of programs.
Unless you are confident there can be no such problems or you will be
able to detect bugs introduced by it, please think
er why you did something
> in this particular fashion, when it actually could just as well be done
> in a more common way.
In my experience with modifying packages locally cdbs and dh are quite
a pain, as too many things are done automatically so that small changes
can require quite a big d
n.org/package/xbuffy/3.3.bl.3.dfsg-8
with
http://anonscm.debian.org/gitweb/?p=users/brlink/xbuffy.git;a=shortlog;h=refs/tags/patched-3.3.bl.3.dfsg-8
)
Bernhard R. Link
--
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of "unsubscribe". T
removed,
not if anything behind them changed.
Bernhard R. Link
--
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive:
http://lists.debian.org/20110801144142.ga...@pcpool00.mathematik.uni-freiburg.de
ify
and state this grant in the file that would be enough).
And the files are GPL-2, how do you get to the GPL 3 in
seem to be debian/copyright?
Bernhard R. Link
--
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of "unsubscribe". Troub
* Benoît Knecht [110804 23:03]:
> Bernhard R. Link wrote:
> > * Benoît Knecht [110804 20:54]:
> > > I've seen that, but they need to make that perfectly clear in the
> > > license header of each file in the tarball. An email sent to you and
> > > repro
t
> include standard C headers.) But there's no obvious reason why that
> shouldn't be required given the current Policy wording.
Which wording are you talking about?
Bernhard R. Link
--
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of &
So not being able to express what you need and missing a realistic use
case where only using this -dev package introduces the requirement, I
think it is rather clear that this dependency is not needed.
Bernhard R. Link
--
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debi
documents?
And so on and so forth...
> (My inclination would be to write an explicit exception into
> Policy saying that C -dev packages do not have to declare dependencies on
> any package that's part of build-essential.)
build-essential is quite big. I'd really hate to se
rtran-compiler, which I
consider to be definitely a bug).
> Note that I explicitly said, and meant, "part of build-essential," not "in
> the transitive closure of build-essential's dependencies."
If you want to say this, please say "things in the Depends: field o
compiled with the new version, it gives a value the old version cannot
handle.
But again dpkg-symbols can see no difference, so if just applying the
patches dpkg-symbols generates means the symbols file will still think
libb 1.0.0 is enough when only calling "do".
Bernhard R. L
* Paul Wise [110924 12:42]:
> On Sat, Sep 24, 2011 at 6:04 PM, Bernhard R. Link wrote:
> > The real problem with using symbol files without understandin them is
> > something like the following examples:
>
> Do you know if the abi-compliance-checker program/package copes
* Boris Pek [111003 02:00]:
> It builds those binary packages:
> leechcraft - Core executable of LeechCraft
> leechcraft-aggregator - RSS/Atom feed reader for LeechCraft
[]
None of the short descriptions make any sense to me without knowing
what leechcraft is.
Bernhar
dicate that one should look for active upstreams
or otherwise might likely end up with some work in the future. But nothing
else yet.
Please let me know if anything of the above is not correct.
Bernhard R. Link
--
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
wit
by default when
> building the package would generate a lot of noise that might hide more
> critical warnings.
Without -Wall you won't get some of the most "critical" warnings.
A package should really not be built without at least -Wall.
Bernhard R. Link
--
To UNSUB
* Nicolas Bourdaud [14 15:25]:
> On 14/11/2011 14:32, Bernhard R. Link wrote:
> > Without -Wall you won't get some of the most "critical" warnings.
> > A package should really not be built without at least -Wall.
>
> I understand, and I think it is a pity
ht want to explicitly ask for
git-buildpackage help. (Your mail read like you have some building
problem, so people knowing git-buildpackage might not have read far
enough.) I don't know how this works with git-buildpackage, with git-dpm
you just git rm those files in the debian branch.
able to build two times in a row is also a not uncommon bug.
Bernhard R. Link
--
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20111213112159.ga2...@server.brlink.eu
avoid me repeating too much, see also
http://lists.debian.org/debian-devel/2011/09/msg00484.html
Bernhard R. Link
[1] If you have a set of disjoint modifications or of modifications that
do not need some additional magic merging is trivially translateable to
a quilt series.
[2] I once
re it is in the environment
of the dpkg-buildflags actually called (usually you need a
export there).
Bernhard R. Link
--
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive
If a symbol extends it behaviour, you need to manually increase the
minimum version of that symbol. So in this case you need to set the
minimum version of all those symbols to the current version that
get new additional functionality. (Otherwise you will get wrong
dependencies for a program depending o
a debian-specific number. (The thing after -)
Hochachtungsvoll,
Bernhard R. Link
--
Sendmail is like emacs: A nice operating system, but missing
an editor and a MTA.
I tried to use it, but it didn't work.
The easiest way it to just hardcode the path. That is sufficent for the
maintainer tasks. If it is within some efford to get the code more
cleaned up and get upstream to accept some patch to clean up, some easy
way is to add something like -DPKGDATADIR=\"
nly hope are nowhere used as they do not fit the actual
number. dirs contains usr/bin and usr/sbin which do not look very used.
Hochachtungsvoll,
Bernhard R. Link
--
Sendmail is like emacs: A nice operating system, but missing
an editor and a MTA.
mall
root-partition.
I'd also suggest
(3) Make it only a suggest. As your description
describes there are very reasonable ways to
no need it (and using 2.6 should be not handled
as obscure corner case) and using locally compiled
kernels should also be documente
At least some time ago mount was able to deal with /etc/mtab
beeing a link to /proc/mounts. (As long as no loop-devices
where involved). This should at least make this work.
(lvm could be tougher, I never looked at it but the idea
looks a bit suspicous in the whole...)
Hochachtungsvoll,
on use any more, though I often found them very helpfull
when debugging things.
Having to recompile whole libraries just to locate some of those
ugly pointer-address relatated bugs makes those assembler near
languages like C and friends much more a pain than it has to be.
Hochachtungsvoll,
B
* Stephen Frost <[EMAIL PROTECTED]> [040323 00:29]:
> * Bernhard R. Link ([EMAIL PROTECTED]) wrote:
> > * Stephen Frost <[EMAIL PROTECTED]> [040322 21:14]:
> > > Pffft. Honestly, I think that claim of end-users and local
> > > administrators using static l
compiling it using static libraries. This
made it in my experience much easier to find some obscure forms of
pointers going wrong and the program crashing on total unrelated places,
as it removes all variability by a dynamic linker...
Hochachtungsvoll,
Bernhard R. Link
--
Sendmail is like emacs: A n
and -examples (or only those
> required, you may want to leave out -examples from the
> dependency list).
I suggest recommends or suggests here. If it is really a depend, then
they should be in the same package. Even recommend sounds a bit strong
for things like that.
H
efore that is so much
less readable than a bad C-code.
But I don't like perl at all. If I had any time in world I would start
with rewriting anything perlish in base, but I just do not have it.
Hochachtungsvoll,
Bernhard R. Link
extremly often for example. But with interpreted parts in the base of an
OS I just have un ungood feeling.
Hochachtungsvoll,
Bernhard R. Link
chroot jail concept, but in this case gimp1.1 would
> need to build-depend on lpr to get a proper build.
Isn't it possible to change gimp so that it will always support them?
Hochachtungsvoll,
Bernhard R. Link
nly hope are nowhere used as they do not fit the actual
number. dirs contains usr/bin and usr/sbin which do not look very used.
Hochachtungsvoll,
Bernhard R. Link
--
Sendmail is like emacs: A nice operating system, but missing
an editor and a MTA.
--
To UNSUBSCRIBE, email to [EMAIL PROTE
eir checksums. Also
the md5sum files would no longer have a canonical look.[1]
In my eyes each package not having a .md5sums file, especially those
important packages missing them, is a shame.
Hochachtungsvoll,
Bernhard R. Link
[1] Though the program combining cruft, debsums, checking the author
* martin f krafft <[EMAIL PROTECTED]> [050102 15:32]:
> also sprach Bernhard R. Link <[EMAIL PROTECTED]> [2004.12.31.1254 +0100]:
> > When they are generated at install time, there could be bit-switchers
> > arising between unpacking them and calculating their checksums
* martin f krafft <[EMAIL PROTECTED]> [050112 12:45]:
> also sprach Bernhard R. Link <[EMAIL PROTECTED]> [2005.01.03.1055 +0100]:
> > Are you trying to say "You even get an alarm if the malfunction has
> > only hit metadata and no important data yet".
>
&
from a cgi with the
arguments coming from the net [I hope nothing does so stupid things,
as it is hard to do so without additional holes] in a way to trigger
this and so on -> critical and tag in security
Hochachtungsvoll,
Bernhard R. Link
--
To UNSUBSCRIBE, email to [EMAIL
efore that is so much
less readable than a bad C-code.
But I don't like perl at all. If I had any time in world I would start
with rewriting anything perlish in base, but I just do not have it.
Hochachtungsvoll,
Bernhard R. Link
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with
extremly often for example. But with interpreted parts in the base of an
OS I just have un ungood feeling.
Hochachtungsvoll,
Bernhard R. Link
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
chroot jail concept, but in this case gimp1.1 would
> need to build-depend on lpr to get a proper build.
Isn't it possible to change gimp so that it will always support them?
Hochachtungsvoll,
Bernhard R. Link
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of &qu
ances to find Cuyo on his
| screen.
| WARNING: It is known to successfully get many people away from
| more important things to do.
|-------
Thanks in advance,
Bernhard R. Link
--
The man who trades freedom for security does no
Hochachtungsvoll,
Bernhard R. Link
--
The man who trades freedom for security does not deserve nor will he ever receive
either. (Benjamin Franklin)
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
buildepends are caused by
incompatibility with the potato versions or due to naming
only the versions the maintainer tested it under, but hey -
where would the fun to backport packages then?)
Hochachtungsvoll,
Bernhard R. Link
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject
might consider placing the source-packages there, too.
Only the binary .debs are quite limited information...
Hochachtungsvoll,
Bernhard R. Link
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
er packaged something with kernel-patches,
better collect other opinions to this.
Hochachtungsvoll,
Bernhard R. Link
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
a debian-specific number. (The thing after -)
Hochachtungsvoll,
Bernhard R. Link
--
Sendmail is like emacs: A nice operating system, but missing
an editor and a MTA.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
I tried to use it, but it didn't work.
The easiest way it to just hardcode the path. That is sufficent for the
maintainer tasks. If it is within some efford to get the code more
cleaned up and get upstream to accept some patch to clean up, some easy
way is to add something like -DPKGDATADIR=\"
mall
root-partition.
I'd also suggest
(3) Make it only a suggest. As your description
describes there are very reasonable ways to
no need it (and using 2.6 should be not handled
as obscure corner case) and using locally compiled
kernels should also be documente
At least some time ago mount was able to deal with /etc/mtab
beeing a link to /proc/mounts. (As long as no loop-devices
where involved). This should at least make this work.
(lvm could be tougher, I never looked at it but the idea
looks a bit suspicous in the whole...)
Hochachtungsvoll,
on use any more, though I often found them very helpfull
when debugging things.
Having to recompile whole libraries just to locate some of those
ugly pointer-address relatated bugs makes those assembler near
languages like C and friends much more a pain than it has to be.
Hochachtungsvoll,
B
* Stephen Frost <[EMAIL PROTECTED]> [040323 00:29]:
> * Bernhard R. Link ([EMAIL PROTECTED]) wrote:
> > * Stephen Frost <[EMAIL PROTECTED]> [040322 21:14]:
> > > Pffft. Honestly, I think that claim of end-users and local
> > > administrators using static l
compiling it using static libraries. This
made it in my experience much easier to find some obscure forms of
pointers going wrong and the program crashing on total unrelated places,
as it removes all variability by a dynamic linker...
Hochachtungsvoll,
Bernhard R. Link
--
Sendmail is like emacs: A n
and -examples (or only those
> required, you may want to leave out -examples from the
> dependency list).
I suggest recommends or suggests here. If it is really a depend, then
they should be in the same package. Even recommend sounds a bit strong
for things like that.
H
Hochachtungsvoll,
Bernhard R. Link
--
The man who trades freedom for security does not deserve nor will he ever
receive either. (Benjamin Franklin)
ances to find Cuyo on his
| screen.
| WARNING: It is known to successfully get many people away from
| more important things to do.
|-------
Thanks in advance,
Bernhard R. Link
--
The man who trades freedom for security does not deserve
nor will he ever receive either. (Benjamin Franklin)
buildepends are caused by
incompatibility with the potato versions or due to naming
only the versions the maintainer tested it under, but hey -
where would the fun to backport packages then?)
Hochachtungsvoll,
Bernhard R. Link
might consider placing the source-packages there, too.
Only the binary .debs are quite limited information...
Hochachtungsvoll,
Bernhard R. Link
er packaged something with kernel-patches,
better collect other opinions to this.
Hochachtungsvoll,
Bernhard R. Link
ill most likely make
sure I will never learn it)
Hochachtungsvoll,
Bernhard R. Link
--
Sendmail is like emacs: A nice operating system, but missing
an editor and a MTA.
> Upstream Author : Bernhard R. Link
While I somtimes no longer remember what features I've already added
to some code a long time ago, I think I would at least remember if
I had written a whole program. In other words, please make sure to
look up the correct upstream author.
| ircii (
sage actually
needs a dynamic library of singular).
Bernhard R. Link
--
F8AC 04D5 0B9B 064B 3383 C3DA AFFC 96D1 151D FFDC
--
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: htt
101 - 175 of 175 matches
Mail list logo
