* Ian Jackson [150227 16:39]:
> Bernhard R. Link writes ("Re: Should .a library contains non-reallocatable
> code?"):
> > Compare that to the straightforward case of just building a dynamic
> > instead of a static library with some simple:
>
> No-one is prop
which what version and being able to do a security update
without recompiling anything but that library).
So I really do not see what advantage in that case PIC code in the .a
file has, while not having it there avoids many possible mistakes.
Bernhard R. Link
--
F8AC 04D5 0B9B 064B 3383
2();
> main.c: printf("%d %d\n", r1, r2);
> main.c: return 0;
> main.c:}
> [...]
> + gcc -Wall main.c -L. -lbar1 -lbar2
You forgot to change that line as I said to change it.
main.c now uses libfoo1 and libbar2, so in my example I build against
those. Now you only
* Russ Allbery [150222 21:51]:
> "Bernhard R. Link" writes:
>
> > This is wrong. If libbar.so needs libfoo.a then libfoo.a does not
> > need to be PIC:
>
> > echo 'int foo(void) {return 17;}' > foo.c
> > echo 'int bar(vo
* Simon Richter [150222 21:19]:
> Am 22.02.2015 um 20:18 schrieb Bernhard R. Link:
>
> > echo 'int foo(void) {return 17;}' > foo.c
>
> This code just happens to not generate any data references, so none of
> the forbidden reloc types are emitted.
You can add
* Ian Jackson [150223 20:09]:
> Bernhard R. Link writes ("Re: Should .a library contains non-reallocatable
> code?"):
> > Jeff Epler [150220 00:19]:
> > > * libbar has a stable API, so it should be shipped as a .so,
> > >but if it links l
dynamic library, this is a very good point
to be made against including anything using it).
Bernhard R. Link
--
F8AC 04D5 0B9B 064B 3383 C3DA AFFC 96D1 151D FFDC
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20150222191833.ga4...@client.brlink.eu
that would totally
legit for a compiler in cases src points to anything else.)
For dest things are a bit more complicated. If the alignment is wrong
gcc might replace the code with anything it wants. Otherwise that memory
might afterwards be regarded as lzo_memops_TU2_struct and accessing it
as a
t;doobar-1.2_3_4".
The current sid version has some combinations (for the different parts
of the version needed for the different older schemata there are currently
%v %u %e %f %V %U %E) but yet none which replaces anything in versions
with "%", which will make it interesting to c
* Raphael Hertzog [141114 12:34]:
> On Thu, 13 Nov 2014, Bernhard R. Link wrote:
> > * Raphael Hertzog [14 22:26]:
> > > Helper tools should usually rely on the output of `dpkg-vendor --query
> > > vendor`
> > > to find out the name of the current
thers edit the file manually
> and use tools like `debcommit` to reuse the changelog entry in the
> Git commit.
>
> Helper tools should however configure the Git repository so that merges
> of the `debian/changelog` file are handled by `dpkg-mergechangelogs` as
> this will make
mits. Try detecting the adding
or removel of an empty file with git diff for example.
Bernhard R. Link
--
F8AC 04D5 0B9B 064B 3383 C3DA AFFC 96D1 151D FFDC
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas.
BTS and changed
debian/rules the way described in debian/changelog.
Why should I look at the debdiff? I know I changed nothing else."?
Bernhard R. Link
--
F8AC 04D5 0B9B 064B 3383 C3DA AFFC 96D1 151D FFDC
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a s
s should make it easier to either have
arguments that persuage people or even better lead to solutions that
improve the situation more generally (I'm quite sure the are aspects
that can be improved, just that lowering Valid-Until times is
detrimental).
Bernhard R. Link
--
F8AC 04D5 0B9B
ymbols" is not enough.
It is either "both must always have had versioned symbols" or
"both must have versioned symbols now and every binary linked against
either must have been built (or rebuilt) after the symbols got
versioned".
Bernhard R. Link
--
F8AC 04D5
t currentl too much
software uses something different to -O2 for no good and too often bad
reasons).
Bernhard R. Link
--
F8AC 04D5 0B9B 064B 3383 C3DA AFFC 96D1 151D FFDC
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble?
ot;3.0 (native)" format to "3.0 (tarball)" or
> anything elese, and we are done.
And brake almost everything? That suggestion is almost equivalent to
just forbidding 3.0 (native) packages completely for the next decade.
Bernhard R. Link
--
F8AC 04D5 0B9B 064B 3383 C
anges.
This answers the question why you want to use a 3.0 (native) package.
But the real question here is: Why do you want to use a version with "-"
for such a package?
Bernhard R. Link
--
F8AC 04D5 0B9B 064B 3383 C3DA AFFC 96D1 151D FFDC
--
To UNSUBSCRIBE, email to debi
ion that can just willy-nilly copy stuff around
without caring for the law and hoping noone will find out or just
pay the authors off if they find out. And our users are not really
helped if the software they depended on suddenly is no longer available
because noone cared for the license before.
* Russ Allbery [131227 18:53]:
> "Bernhard R. Link" writes:
> > * Russ Allbery [131224 01:42]:
>
> >> On the contrary, it's Debian's insistence on following an idiosyncratic
> >> license interpretation that's creating the supposed
ot;idiosyncratic". How about
using "interpretations I do not like".
Thanks in advance,
Bernhard R. Link
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20131225125243.ga4...@client.brlink.eu
am that invokes undefined behaviour is a bug.
And even if the library was fixed, as long as the program has undefined
behaviour, every future gcc version is still free to give it any
behaviour it choses to.
Bernhard R. Link
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with
non-md5sum hashes in
Sources indices.
reprepro for example only tries to support source indices without
"Files" (i.e. md5sum hashes) since 4.12.0 (i.e. since wheezy).
Bernhard R. Link
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "
n constructed to make it easier to
understand how ugly some harmless looking restriction can become.
Bernhard R. Link
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://l
* Stefano Zacchiroli [130710 13:07]:
> On Sat, Jul 06, 2013 at 05:41:16PM +0200, Bernhard R. Link wrote:
> > No, there is a really important difference. With GPL you only have to be
> > careful when you give binaries to anyone, that you also give the source.
> > This is a
at closes a long outstanding bug titled "provide a
> license port for the Software-as-a-Service era".
And adding DRM to the browser is just closing a long outstanding bug
titled "please cripple my system enough so that content providers will
take my money"?
Bernhard R
moving stuff if their license changes can
make sense in many situations.
And doubly so for AGPL. (I'll never understand why people consider it
free software, I'd not even allow the term freeware for it).
Bernhard R. Link
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.d
at uses more words as necessary, while
compiler options are neccessary, without them users of the software
cannot get help in forums or channels when they have problems compiling
the software and with build logs porters can often hardly help if the
old buildd log contains no information.
Bernha
ctually doing. With postfix the config is just black magic, where one
has hardly any chance to understand what it does and how to change it to
do what you want to change.
[1] And those can simply install postfix and be done with it.
Bernhard R. Link
--
To UNSUBSCRIBE, email to deb
to doubt this is possible.
Actually, it is possible to block telnet (and I've seen some ISPs do it).
In unrelated news, using telnet is a bad idea. If you want to connect to some
port and see what you get, use netcat.
Telnet is not a tool to show things coming from a port but a tool to
speak
misleading error messages in this case, I'd not be surprised if there
are some more.
> https://lists.gnu.org/archive/html/grub-devel/2013-01/msg0.html
Those arguments seem to be mostly related to tampolines, which is mostly
an argument against having pointers to nested fun
rder in a language the kitchen clerk cannot read, so the
kitchen clerk will pass it to the person responsible for reading
obliterated orders and this person you can tell it either give the order
to the kitchen doing potatoes or the kitchen doing fries depending on
what is wanted.
Bernhar
om kitchen parts with only the transparent tape for office use.
The only positive thing you can say about Postfix' configuration is that
it might be better than sendmail's.
Bernhard R. Link
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of
re" and "pay for every copy that
was made".
Bernhard R. Link
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20130514212524.ga3...@client.brlink.eu
where we're mounting /usr in the initramfs rather than
> having it on the rootfs, there's no practical difference to the
> current status quo (and this is intentional). The only change is
> that we provide the guarantee that /usr is available before init
> starts.
Or in other
t;I do it differently" or "I do not care" from your side is hardly
anything someone can counter with technical arguments, so you will
not see many.
Bernhard R. Link
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe&quo
s correct while
making the low-quality (or obsolete) stuff the norm. Since C99
there is hardly any reason left to have headers differing with the
architectures.
Bernhard R. Link
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe".
and cowbuilder already.
That's why I think maintainers should not only build in pbuilders and
cowbuilders, but give their packages some actual testing.
Bernhard R. Link
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". T
ion to read the Vcs control fields and make a
> clone for a traditional source package's repo.
sudo apt-get install devscripts
debcheckout source-package-name
Bernhard R. Link
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubsc
e heavily over time and
get more and more specific. In some years we might not be able
to switch to some other builder tools as too many packages depend
on the specifics of the ones we currently have.
Bernhard R. Link
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
* Ben Longbons [130425 18:27]:
> The problems with the way Debian does it are:
> - debian/ is a subdirectory of the extracted source tree.
Why do you think that is a problem?
> - Because of the above, debian/rules tries to know about backwards steps.
What are "backwards steps"?
> - There
e
important argument pushing the scales in the other direction, but at
the end of the day, the normal system administrator wants one package
management tool for all their software (or at least as few as possible)
and as few copies/different versions of common code (aka libraries,
modules, ...) aroun
by faulty memory, faulty busses,
overheated mainboards or CPUs) and not to content on the disc itself).
So while incomplete .md5sums are definitely not nice and worse then
complete files, I do not see how that could be worse than not having
any .md5sum files.
Bernhard R. Link
--
To UNSUB
olchain packages,
while everything providing programs to be in their respective section).
Bernhard R. Link
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20130102090022.ga5...@client.brlink.eu
ave a rule there at all).
Another question: Have you considered asking for a archive Section for
those packages? I guess with no special section yet all those packages
would be section libdevel as they are for static linking only, wouldn't
they?
Bernhard R. Link
--
To
e some default
options to things like --auto-key-locate (and with any new options in
that direction that might still be added to gpg).
Bernhard R. Link
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Conta
initrds on all release architectures?
Squeeze was still released with some kernels without initrd support
if I remember correctly.
Bernhard R. Link
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.
* John Paul Adrian Glaubitz [121129 21:14]:
> On Thu, Nov 29, 2012 at 08:22:41PM +0100, Bernhard R. Link wrote:
> > As our world has not
> > yet seen bug-free software handling every single situation the authors
> > did not think about properly, the expectation of what ha
ess in a short time frame makes sure that there
is a big opposition (which will look for you like it has no arguments,
as no real arguments against systemd are accepted.)
Bernhard R. Link
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe
a loss" makes it quite hard to take
anything else you say seriously.
Bernhard R. Link
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20121128065215.ga14...@client.brlink.eu
an extra permission
for a copy shop you bring your document in to use that font. And stuff
like that.
I.e. most stuff will non be suitable for Debian main. Some stuff might
be suitable for non-free. Many things will not be distributable at all.
Bernhard R. Link
--
To UNSUBSCRIBE, email t
ote for wishlist severity.
Ambiquity about lines starting with from in mboxo format is the same
like storing the value 0007 in an integer and getting 7 back when
asking for the value. Or like storing a filename in a FAT filesystem
and getting it back when asking for a file with the name convert
* Andreas Tille [121031 09:43]:
> On Wed, Oct 31, 2012 at 09:04:23AM +0100, Bernhard R. Link wrote:
> > Who of us never put some unimportant bug that would need some longer
> > investigating in a row to make sure it is actually not a bug and
> > forgot to post a little no
were so clear when a package is neglected and when not, we could
just do without the whole waiting period and giving the maintainer
chance to object and simply hijack the package directly.
Bernhard R. Link
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20121031080420.gb11...@client.brlink.eu
or function argument passed as register) no longer stored anywhere.
Bernhard R. Link
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20121028163707.ga19...@client.brlink.eu
tion you get
by locally rebuilding the needed libraries with
DEB_BUILD_OPTIONS="noopt nostrip" and installing those.
(Sadly not all libraries support noopt, but it's getting much better as a
side effect of the current hardening effords).
Bernhard R. Link
--
To UNSUBSCRI
s a much more logical place, easier
to find, harder to miss. Better collect the data to show them in
some central place also instead.
Bernhard R. Link
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact list
another argument: having the files actually uploaded
means it is easy to add additional checks. (Like starting with making
sure the list of files does not differ between the two versions, or
some check to see only versions of generated dependencies differ but
not the packages depended and so on).
Unless you are arguing that people locally
modifying their packages are supposed to get security problems).
Bernhard R. Link
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive:
and all the
build-conflicted packages not installed is a critical bug.
Recreating binary packages uploaded by maintainers has some merrits,
but this is definitely not one of them...
Bernhard R. Link
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "
* Wouter Verhelst [121013 10:56]:
> On Fri, Oct 12, 2012 at 09:17:32AM +0200, Bernhard R. Link wrote:
> > part at all) will only weaken security. So I think what you say is an
> > argument for keeping md5sum, so that noone think they can use that
> > information for security.
de where it uses DPKG directly.
Everything doing something like that can also create those sha2 sums on
their own and use them. Using the debsums system (which has no security
part at all) will only weaken security. So I think what you say is an
argument for keeping md5sum, so that noone think
l tendency in gtk/gnome world to
consider anything not in their primary picture as obsolete and/or legacy
and thus not worth to support.
So users outside Debian would profit more to push patches to all
programs to properly prefer HOME instead of hoping to persuade upstream
of the library (and Deb
tory which it obviously almost
but not quite does not at all.)
The documentation for g_get_home_dir[1] also documents what a
proper program can do, it's a simple:
const char *homedir = g_getenv ("HOME");
if (!homedir)
homedir = g_get_home_dir ();
instead of using get_get_hom
about hardware usually be kept away from chroots?
Bernhard R. Link
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20120921232531.ga20...@client.brlink.eu
onding architecture is not quite a good solution
( if you want to make it even better, you can set up a regular
private rebuild on that architecture to make sure it still is
buildable all the time... ;-> )
Bernhard R. Link
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.or
t a serious bug in another architecture is just
a case of a serious bug that does not yet show up on the more common
architectures or only very seldom, but lurking in the dark, waiting
till it can also hit your "more users" later if ignored now.
Bernhard R. Link
[1] As a C
oes not take much time. (There is a lot of unmaintained
software out there, but as I said, not much difference to getting
any other patch in).
Bernhard R. Link
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Troubl
e freedom of our users,
perhaps they are not really a loss.
Bernhard R. Link
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20120818174632.ga8...@client.brlink.eu
hat already show a mime type before you open it) is simply
introducing a security bug.
Bernhard R. Link
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lis
an anything I think I could have
written. After you were closing two bug reports by just dismissing the
issue, a "if that gets closed again" is a totally objective way to
describe expectations.
Bernhard R. Link
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
Package: wnpp
Severity: wishlist
Owner: "Bernhard R. Link"
Package name: acpi-support-minimal
License : GPL2+
Description: minimal scripts for handling base ACPI events
This package contains minimal scripts to react to various base
ACPI events such as the power button. I
t more strange
than not using make but some python or shell script to do the actual
compilation or any other of the many strange things found in software
packages.
Bernhard R. Link
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe".
into LDFLAGS or or or.
It's all mostly trivially done but there are quite a number of variants.
Anything not having CPPFLAGS is usually simply so non-standard that
a human has to look at it anyway and no automatic approach will help.
Bernhard R. Link
--
To UNSUBSCRIBE, email to
it was introduced by
> Autoconf. However, it is now embedded into the implicit rules of GNU Make,
> so every Makefile that doesn't override the rule for compiling a .c file
> to a .o file uses CPPFLAGS.
Where "now" means since 1990.
Bernhard R. Link
--
To UNSU
rocess anything, pass CPPFLAGS.
Note that CPPFLAGS and LDFLAGS are in the format as you need to
give them to gcc/g++, i.e. every ld option not understood by
gcc needs a -Wl, and so on...
Bernhard R. Link
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subj
kage is also unlikely to have happened).
Bernhard R. Link
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20120613163535.ga30...@client.brlink.eu
default answer of 'yes' should
> solve the problem, imho - the slightly more experienced user can then
> at least opt for 'no'.
That's called policy.d. (though I feel like repeating others here).
Bernhard R. Link
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20120603115132.ga4...@client.brlink.eu
t run by default (or at last by
default once its configuration is complete) means I have to
tweak another config file, which is uncessary annoying work.
Bernhard R. Link
[1] Exceptions being specific things like unconfigured dhcp servers,
but I never met one that would run by default as it f
o configure /tmp differently, the user is
able to set TMPDIR differently.
my 0.02:
I personally think having tmpdir on /tmp might be a good default for
new systems. If systems get changed to that from something else on
upgrade without asking, I consider that quite an ugly bug.
Bernhard
; format
is: "don't use it, it's an ugly hack".
Bernhard R. Link
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20120519090516.ga5...@client.brlink.eu
.0 (quilt)" source package out of that.
And yes, git is the better quilt for managing a source tree. Which is
why I use it exclusively to work on my "3.0 (quilt)" packages.
Bernhard R. Link
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a su
in itself. Requiring patched being
able to applied without any magic (which might hide mistakes and
result in changes different from the intended ones) is a reasonable
thing to do.
Bernhard R. Link
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of &qu
le that you do not care about their arguments because you they are
not insiders, which this is from some point of view, is the noise that
makes an discussion in my eyes the most unwelcoming and thus a good
reason to only expect noise and no more signal.
Bernhard R. Link
--
To UNSUBSCRIBE, e
* Russ Allbery [120501 18:18]:
> David Bremner writes:
> > "Bernhard R. Link" writes:
>
> >> My suggestion to everyone feeling the need to tell anyone on a public
> >> mailing list that they should shut up because they are no contributors
> >&g
s,
hoping the other side will either give up or will be overruled by the
TC at the end.
Bernhard R. Link
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20120502124909.gb18...@server.brlink.eu
l of technical discussion and have
little chance to come back to it till the discussion will be over, but
once that point is reached there really is no sense it keeping it up.
Bernhard R. Link
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsub
ening build flags via dpkg-buildflags. These flags enable various
protections against security issues such as stack smashing, predictable
locations of values in memory, etc."
It's not
"Every package even if only hardly being of a quality to be included in
a distribution must support harden
#x27;$(CXXFLAGS)' CPPFLAGS='$(CPPFLAGS)' or
CFLAGS='$(CPPFLAGS) $(CFLAGS)' or
CFLAGS='$(CPPFLAGS) $(CXXFLAGS)' or even something like
CFLAGS='$(CPPFLAGS) $(CXXFLAGS) $(LDFLAGS)'.
So what we have is already the most efficient default and also the only
one alw
* Markus Wanner [120414 13:32]:
> On 04/14/2012 11:22 AM, Jakub Wilk wrote:
> > Sure, they are also much more common than GLR. And if you are "just"
> > interested in parsing and not a computer scientists, there's a chance
> > you've never heard about any of them.
>
> Based on two votes for extend
re important part of freedom than just licenses. What good is being
allowed by law to modify your system if the system itself treats you
as a child that should not mess with anything?
Where should future free software writers origin from if there is a
barrier erected between users and 'ex
when compiling c++ code. In the easy case of only having c++ code that
means you might need to give CXXFLAGS into a variable named CFLAGS.
Bernhard R. Link
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact lis
is a nice easy way, especially because packaging
information has a canonic place and is not changed by patches.
Bernhard R. Link
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Arc
* Uoti Urpala [120227 22:02]:
> Bernhard R. Link wrote:
> > While there might be some problems originating from some architecture,
> > but most problems you will see and people claim to be "problems specific
> > to fringe architectures" are actual bugs in the progra
* Uoti Urpala [120226 20:20]:
> If someone complained about a nontrivial s390-specific problem in a
> context where I was upstream, I'd likely ignore him. In the Debian
> context, people other than porters should not be obligated to do
> significant work to resolve problems specific to fringe arch
ur init script, and you now have the benefit of lots of eyes.
So software will ever be without bugs. The question is not: Will it have
bugs? The question is: What effects will bugs have?
Bernhard R. Link
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a sub
I guess you'd consider that
> cheating. :-)
If you want to know why something does not start then this won't help
much.
Bernhard R. Link
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lis
* Tollef Fog Heen [120224 10:45]:
> ]] "Bernhard R. Link"
> > * Tollef Fog Heen [120223 22:21]:
> > > ]] "Bernhard R. Link"
> > > Your shell is most likely implemented in C, but it's not like you sit
> > > down and have to debug it eve
* Tollef Fog Heen [120223 22:21]:
> ]] "Bernhard R. Link"
> Your shell is most likely implemented in C, but it's not like you sit
> down and have to debug it every other day. Why do you assume that you
> need to do so just because policy is encoded in .ini-like files
not your opinion with insults I will
not take much efford to fix your packages but rather try to get the
packages I use in a working state.
Bernhard R. Link
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Troub
1 - 100 of 482 matches
Mail list logo
