Re: Should .a library contains non-reallocatable code?
* 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 proposing that shared libraries should not be built, and
> used, when possible. We are only discussing here the case where
> building a shared library is not feasible for some reason.
>
> The most common reason is that the shared library has no stable ABI:
> that is, upstream make API changes willy-nilly. In that case ...
>
> > printf 'LIBFOO_0.'$REVISION' {\n global:\n *\n};\n' > foo.map
> > gcc --shared -Wl,--version-script=foo.map -Wl,--soname
> > libfoo.so.0.${REVSION} -o libfoo.so.0.${REVSION} ...
> > ln -s libfoo.so.0.${REVSION} libfoo.so
>
> ... this approach will lead to ABI-change-related breakage.
How do you think this can lead to breakage that your suggestion to merge
the static library into the dynamic library using it can not?
> Where only a static library is provided, it should be built _with_
> -fPIC unless it is expected never to be included in any shared object
> (which is probably hard to predict, but I guess there might be cases
> where the maintainer might know).
If you change that to "unless it is expected to never be
included in any shared object correctly." you get the current policy.
Because I can hardly think of a shared library for which that is not
expected.
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/20150227183331.ga2...@client.brlink.eu
Re: Should .a library contains non-reallocatable code?
* Ian Jackson [150224 18:51]:
> Right. I think that the right answer to this, in these cases, is
> either to use an explicit symbol export file or to adjust the link
> command lines.
"adjust the link command lines" ? That's like saying the mine field
is safe because people will know which way through it is safe (at least
the second time they pass).
Creating multiple copies by creating shared libraries that merge
the static library in so that might end up multiple times in the same
library, and in a way they leak those implementation and might override
even things in programs linking against that library is at best a gross
hack, at worst a disaster waiting to happen.
"explicit symbol export file"
While this might be possibly avoid problems, it is quite a hard thing to
do. As there needs to be the default to hide everything (unless you
assume a library author incapabable of managing a ABI on the one hand
but able to properly make all symbols match some easy pattern) you
need an explicit whitelist one what you export from the merged library.
And in both cases you still have the problem that you have object code
copies in other packages, including all the problems like the need to
keep multiple source versions around, security updates being quite a
hassle, needing more memory if that code ends up in multiple libraries
and so on. (Not to speak of all the other problems of static libraries,
like breaking the versioning of symbols used from other libraries and
stuff like that).
Compare that to the straightforward case of just building a dynamic
instead of a static library with some simple:
printf 'LIBFOO_0.'$REVISION' {\n global:\n *\n};\n' > foo.map
gcc --shared -Wl,--version-script=foo.map -Wl,--soname libfoo.so.0.${REVSION}
-o libfoo.so.0.${REVSION} ...
ln -s libfoo.so.0.${REVSION} libfoo.so
which also gives you all the advantages of not having needlessly
multiple copies of the same version of the compile code around
and get all the other goodies (like automatic tracking where it is
used and 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 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/20150226230057.ga3...@client.brlink.eu
Re: Should .a library contains non-reallocatable code?
* Ian Jackson [150224 15:50]:
> > You still pollute the ABI with the details of the internals:
> >
> > if you try to change main.c to:
> > #include
> > #include "foo1.h"
> > #include "bar2.h"
> > int main() {
> > double rr1;
> > foo(&rr1);
> > int r1 = rr1;
> > int r2 = bar2();
> > printf("%d %d\n", r1, r2);
> > return 0;
> > }
> >
> > and run gcc -Wall main.c -L. -lbar2 -lfoo1 ; LD_LIBRARY_PATH=. ./a.out
> > you get:
> > foo2: 0x7f42db6f0a48
> > foo2: 0x7f42db6f0a48
> > 0 17
> >
> > (In this specific case a version script might helps, but I'd not bet
> > on helping in all cases).
>
> I don't know what exactly you ran. Your transcript is not complete
> and I don't get the same results. I suspect you didn't pass
> -Bsymbolic everywhere.
>
> I changed main.c to contain the code you just showed, and reran by
> ./build script (same as before), and got this:
[...]
>
> (64)ian@zealot:~$ ./build
> + egrep . bar.c bar1.c bar1.h bar2.c bar2.h foo.c foo1.c foo1.h foo2.c foo2.h
> main.c t.c build
> [...]
> main.c:#include
> main.c:#include "foo1.h"
> main.c:#include "bar2.h"
> main.c:int main() {
> main.c: double rr1;
> main.c: foo(&rr1);
> main.c: int r1 = rr1;
> main.c: int r2 = bar2();
> 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 need a bit of bad luck to use -lbar2 -lfoo1 in
that order and you get the problem. -Bsymbolic only helps against bar
being poluted. It does not help against libbar polluting the main
program. (For this you need at least something like symbol versioning
to hide the symbols).
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/20150224173825.ga1...@client.brlink.eu
Re: Should .a library contains non-reallocatable code?
* 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(void) {return foo();}' > bar.c
> > echo 'int main() {return bar();}' > main.c
> > gcc -c -Wall foo.c
> > ar rs libfoo.a foo.o
> > gcc -shared -fPIC -Wall bar.c -o bar.so
> > gcc -Wall main.c -L. -lbar -lfoo
> > ./a.out
> > echo $?
>
> > works just fine.
>
> It won't with something more complex on all architectures. I think there
> are architectures (i386, maybe?) where you can link non-PIC code into a
> shared library with a performance penalty, and (as mentioned by another)
> it doesn't matter for code where there's no difference between PIC and
> non-PIC. But this will definitely break on some architectures (including
> amd64, IIRC).
>
> There's been lots of discussion of this on the Libtool list, and I've had
> to deal with this from time to time in various upstream projects where I
> wanted to assemble a shared library from various internal helper
> libraries. Take a look at all the work that Libtool does to handle
> convenience libraries for exactly this reason.
You are speaking about linking .a helper libraries into a shared object.
I'm about the case that a shared library has a dependency on a different
static library instead.
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/20150224015905.gb2...@client.brlink.eu
Re: Should .a library contains non-reallocatable code?
* 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 references here. As I do not merge it into a dynamic object,
it does not make any difference, though.
(Also "data references" is a bit misleading, as data references and code
references
do not really make a difference.
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/20150224014724.ga2...@client.brlink.eu
Re: Should .a library contains non-reallocatable code?
* 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 libfoo.a, and libfoo.a is not -fPIC, then
> > >libbar has to be shipped as a a static library too
>
> Jeff is correct.
> >
> > 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(void) {return foo();}' > bar.c
> > echo 'int main() {return bar();}' > main.c
> > gcc -c -Wall foo.c
> > ar rs libfoo.a foo.o
> > gcc -shared -fPIC -Wall bar.c -o bar.so
> > gcc -Wall main.c -L. -lbar -lfoo
> > ./a.out
> > echo $?
> >
> > works just fine.
>
> Did you actually try this before posting ?
Oh, I copied the wrong lines from the backlog here. It seems they
were a bit to trivial so autocorrection made me miss them reading over
them.
> Furthermore, as Simon Richter points out, this happens to work only
> because 1. your foo.c happens not to contain any data references, and
Data references work fine, too:
echo 'extern int val; void foo(int s) {val=s;}' >
echo 'int val = 2; void foo(int s) {val=s;}' > foo.c
echo 'extern int val;int bar(void) {return val;}' >
gcc -c -Wall foo.c
ar rs libfoo.a foo.o
gcc -shared -fPIC -Wall bar.c -o libbar.so
echo 'int main() {foo(17);return bar();}' > main.c
gcc -Wall main.c -L. -lbar -lfoo
LD_LIBRARY_PATH=. ./a.out
echo $?
> 2. your construction of bar.so (should be libbar.so) produces a shared
> library with unresolved references to libfoo, which is not usual or
> desirable.
Using a static library is undesirable. Unresolved symbols is just the
way dependencies of libraries works. The only thing missing here is
the missing dependency on the static library. But that is simply not
possible with static libraries.
> (In particular, this would vitiate libbar's stable
> API/ABI.)
This you have to explain.
If you think there is another way a dynamic library can use a static
library please tell so.
> (64)ian@zealot:~$ echo 'int x=17; int foo(void){ return x; }' >foo.c
> (64)ian@zealot:~$ echo 'int bar(void) {return foo();}' > bar.c
> (64)ian@zealot:~$ echo 'int main() {return bar();}' > main.c
> (64)ian@zealot:~$ gcc -c -Wall foo.c
> (64)ian@zealot:~$ ar rs libfoo.a foo.o
> (64)ian@zealot:~$ gcc -shared -fPIC -Wall bar.c -L. -lfoo -o libbar.so
> bar.c: In function ?bar?:
> bar.c:1:1: warning: implicit declaration of function ?foo?
> [-Wimplicit-function-declaration]
> /usr/bin/ld: ./libfoo.a(foo.o): relocation R_X86_64_PC32 against
> symbol `x' can not be used when making a shared object; recompile with
> -fPIC
> /usr/bin/ld: final link failed: Bad value
> collect2: error: ld returned 1 exit status
What you do here is creating a dynamic library that merges the contents
of foo and bar. This is totally broken. If anything else uses the same
static library you get multiple symbols. If there versions differ that
means harvoc. With data parts you may end up with multiple versions.
There are only two possibilities:
You want a static library, then the static library has to be linked into
the executeable directly.
You foo within a dynamic library. Then instead of creating a dynamic
library that includes foo you can just as well create dynamic libfoo.so
and link against that.
> > > * foomodule is a Python wrapper for libfoo, so it must be shipped
> > >as a .so, but if it links libfoo.a, and libfoo.a is not -fPIC,
> > >it is not possible to build foomodule at all
> >
> > That is indeed the case. Note that simply compiling it with -fPIC might
> > not be enough here. As you need to include the actual library in the
> > module, this might mean you might end up with multiple copies of the
> > library, which might also mean multiple copies of any data it has or
> > with different versions of the same library in the same executeable
> > (and you cannot really have symbol versioning with a static library).
>
> That not usually a problem. Providing that only the relevant symbols
> are exported from the .so, the executable simply results in multiple
> completely independent copies of the static library.
Your example above misses that.
echo "int foo(void) {return 7;}" > foo1.c
echo "int foo(void) {return 13;}" > foo2.c
echo 'int bar(void) {return foo();}' > bar.c
echo 'int main() {return bar();}' > main.c
gcc -c foo1.c
gcc -c foo2.c
gcc -fPIC -c foo1.c
rm libfoo.a
Re: Should .a library contains non-reallocatable code?
* Jeff Epler [150220 00:19]:
> Here are two scenarios where building a static library (libfoo) with
> -fPIC is desirable:
>
> * libbar has a stable API, so it should be shipped as a .so,
>but if it links libfoo.a, and libfoo.a is not -fPIC, then
>libbar has to be shipped as a a static library too
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(void) {return foo();}' > bar.c
echo 'int main() {return bar();}' > main.c
gcc -c -Wall foo.c
ar rs libfoo.a foo.o
gcc -shared -fPIC -Wall bar.c -o bar.so
gcc -Wall main.c -L. -lbar -lfoo
./a.out
echo $?
works just fine.
> * foomodule is a Python wrapper for libfoo, so it must be shipped
>as a .so, but if it links libfoo.a, and libfoo.a is not -fPIC,
>it is not possible to build foomodule at all
That is indeed the case. Note that simply compiling it with -fPIC might
not be enough here. As you need to include the actual library in the
module, this might mean you might end up with multiple copies of the
library, which might also mean multiple copies of any data it has or
with different versions of the same library in the same executeable
(and you cannot really have symbol versioning with a static library).
(If the wrapper is nor for the library itself (but only a library used
by that) this makes it quite dangerous. On the other hand it is a
wrapper for a library depending on an other yet-too-immature-to-have-a-.so
library, so it's quite safe to assume it is so experimental having a
python wrapper makes not much sense anyway.
If the python wrapper is for the library, than an _pic.a only is needed
if that wrapper is not generated by the same source package).
> Unless the circumstances of libfoo make these scenarios unlikely, it
> seems like it is better for other packages to prefer -fPIC even when
> building a static library.
>
> I wonder whether these scenarios were considered when the Policy was
> written.
Static libraries have many serious drawbacks (there are copies in many
programs, so every fix needs a recompile-orgy, multiple copies waste
more RAM, no built-in inter-library-dependencies, ...) and since then
even gotten more (headers if libraries the .a uses (like libc, ...) are
used at compile time, but they are only attached to symbol versions once
the .a in linked into something, so they might not match the headers,
...) since then.
Once something is actually used by other things it is really a good
idea to provide a dynamic library. (And conversely, if something is
not yet able to provide a 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
Re: Architectures where unaligned access is (not) OK?
* Simon McVittie [141121 13:42]:
> A couple of questions for people who know low-level things:
>
> * Of Debian's architectures (official and otherwise), which ones are
> known/defined/designed to be OK with unaligned accesses from
> user-space, and which ones (can be configured to) crash or give wrong
> answers?
[...]
> The ones I know for sure are:
>
> - OK: any-i386, any-amd64
Are you sure about those, especially amd64? AFAIK some newer
instructions (I think something about vector code) have much tighter
requirements than the old 80386 modus operandi of "everything might be
unaligned,
it is just slower then").
> The context is that
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=757037 describes lzo2
> failing to start up on armel due to unaligned memory accesses. lzo2 has
> a cpp macro, LZO_CFG_NO_UNALIGNED which can be defined to stop it doing
> "clever" things with casting pointers.
'"clever" things with casting pointers' sounds like someone thought C
was an assembler and not a language with quite tight requirements on
what you are allowed to do. If something does 'clever things' I strongly
recommend to compile it with -O0. Optimisation of the compiler is only
supposed to keep the behaviour of conforming code, with 'clever' things
everything is possible.
> If the maintainer doesn't object
> (or fix the bug of course), I intend to NMU lzo2 to use that macro on at
> least armel; I would like to sanity-check whether I should be using a
> blacklist or whitelist approach, and which architectures other than
> armel should be on the blacklist, or which architectures other than x86
> should be on the whitelist.
>
> Relatedly, if we have
>
> typedef struct lzo_memops_TU2_struct {
> unsigned char a[2];
> } lzo_memops_TU2;
>
> *(lzo_memops_TU2 *) (void *) dest =
> *(const lzo_memops_TU2 *) (void *) src;
>
> is gcc within its rights to optimize that into an aligned 16-bit load
> and an aligned 16-bit store, even though alignof(lzo_memops_TU2) == 1;
> or should gcc be emitting pessimistic byte-by-byte code for that?
With the "*(const lzo_memops_TU2 *) (void *) src" you tell the compiler
that src is pointing to a memory address that is a lzo_memops_TU2_struct.
In a case where it is not gcc is free to assume that this code path is
not inteded to be ever executed and may replace it in any way it see fit
to cope with other code paths (luckily replacing the code with
'system("rm -rf /");' is unlikely to happen, though 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 anything else is fair game for the compiler to assume it is dead
code.
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/20141121133100.ga8...@client.brlink.eu
Re: RFC: DEP-14: Recommended layout for Git packaging repositories
* Ron [141119 07:21]: > I believe Bernhard explained earlier that git-dpm allows the replacement > character to be configurable (but also offers just a single character > for all replacements). git-dpm doesn't have a replacement-character configurable, but different control sequences for the variable parts of tags supporting different version schemata, so one can configure "debian%e-%v" for the old style 1:2:3~4 generating tag name "debian1-2_3_4". And "debian/%E%V" would give "debian/1.2.3.4" and "foobar-%e%v" would give "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 create code for 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/20141120193737.ga1...@client.brlink.eu
Re: RFC: DEP-14: Recommended layout for Git packaging repositories
* 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 vendor. The retrieved string must be > > > converted to lower case. This allows users to override the current vendor > > > by setting `DEB_VENDOR` in their environment (provided that the vendor > > > information does exist in `/etc/dpkg/origins/`). > > > > Is using the vendor you use git on a good default for the vendor code > > you are currently working on? In my experience those two are quite > > unrelated. > > Do you have a better default to suggest? In any case, having a default > value is certainly better than not having one and forcing everybody to > configure it in some ways. I'm not so sure about that. Having a broken default can be more annoying than not having a default at all. > I try to work in Kali chroots when I do Kali work. It's true that > it's not always the case but if there were real differences right now I > would pay more attention or would ensure to have the proper environment. Well, for test-building stuff and things like that going to the proper environment is nice, but why having the need to have gitk and new enough versions of your helper tools around everywhere? > > > Version mangling > > > > > > > > > When a Git tag needs to refer to a specific version of a Debian package, > > > the Debian version needs to be mangled to cope with Git's restrictions. > > > The colon (`:`) needs to be replaced with a percent (`%`), and the tilde > > > (`~`) needs to be replaced with an underscore (`_`). > > > > Is there a previous case of encoding colons with percent signs? > > This is the current convention used by git-buildpackage and I believe the > "%" has been picked because it's visually close to ":" (i.e. two dots/two > circles). > > > If it is inventing a third way instead of using on of the existing ones, > > is sounds like a bad idea. > > Do you suggest to use URL encoding? That's rather heavyweight for two > special cases that can be easily mapped to other characters that are not > used in version strings. And it would convert characters that do not > need any special escaping currently. No, I was refering to the many ways to encode. I was yet aware of encoding 2:1-3~4 as debian2-1-3_4 debian-2_1-3_4 debian-2.1-3.4 I guess using single letters as format identifiers in git-dpm's tag specification was a bit optimistic... > > Tags are only based on versions are also quite hard to shuffle around. > > I'd strongly suggest adding the name of the source package to those, > > otherwise accessing multiple packages in on repository causes a big > > mess. (git keeps branches in the per-origin "remote" namespace when > > fetching stuff, tags only have one global namespace, local and remote). > > I don't think this makes sense. The common case is a single software per > git repository. If you have multiple software, then the git way is > to use git submodules. If you have an upstream that doesn't follow those > conventions, then it's a good reason to not follow DEP-14 for the tagging > of your Debian releases. While having a repository hosting multiple projects permanently makes in many cases not that many sense (though I sometimes prefer it for some small stuff, as it allows to make/update a mobile backup with a single git command), cherry picking commits from other repositories in git to my knowledge requires fetching at least part of that history in your current working repository. When fetching too much by mistake the global nature of tags can make quite a mess. > > > Native packages > > > === > > > > > > The above conventions mainly cater to the case of non-native packages, > > > that is when the upstream developers and the package maintainers are > > > not the same set of persons. > > > > > > When upstream is Debian (or one of its derivative), the upstream vendor > > > should not use the usual `/` prefix (but all others vendors should > > > do so). The main development branch can be named `master` instead of > > > the codename of the target distribution (although you are free to still > > > use the codename if you wish so). > > > > Does native here mean a native package or a package developed primarily > > for Debian (which can also use a non-native packaging)? This paragraph > > seems to mix those two concep
Re: RFC: DEP-14: Recommended layout for Git packaging repositories
es > === > > The above conventions mainly cater to the case of non-native packages, > that is when the upstream developers and the package maintainers are > not the same set of persons. > > When upstream is Debian (or one of its derivative), the upstream vendor > should not use the usual `/` prefix (but all others vendors should > do so). The main development branch can be named `master` instead of > the codename of the target distribution (although you are free to still > use the codename if you wish so). Does native here mean a native package or a package developed primarily for Debian (which can also use a non-native packaging)? This paragraph seems to mix those two concepts quite a bit. > Patch queue tags > > > A patch queue branch is a (temporary) branch used to define the set > of upstream changes that the package will contain, its content is > generally used to later update `debian/patches` in the resulting > source package. s/(temporary)/(possibly temporary)/ ? > What to store in the Git repository > --- > > It is recommended that the packaging branches contain both the upstream > sources and the Debian packaging. Users who have cloned the repository > should be able to run `dpkg-buildpackage -b -us -uc` without doing > anything else (assuming they have the required build dependencies). ++ (except that one of course needs to get the .orig.tar.gz using pristine-tar or uscan for a non-native package needs to be an exception from "anything else") > Managing debian/changelog > - > > This DEP makes no specific recommendation on how to manage the Debian > changelog. Some maintainers like to use tools like `gbp dch` to generate > the changelog based on Git commit notices, others 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 it much easier to merge between different packaging > branches. Ugh. Please do not encourage tools to pester with my git config. (Perhaps this want meant as something to do when automatically creating a repository for you?) Bernhard R. Link P.S: I think the timing for this proposal it not that good. I'd rather waste my time looking for some RC bugs to fix as long as there might still be some easy ones left so shortly after the freeze. -- 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/20141113192257.ga2...@client.brlink.eu
Re: dgit and git-dpm
* Ian Jackson [141103 19:13]:
> The point is that the dgit user probably will have done git diff
> before dgit build / push. git diff provides a more convenient diffing
> tool than debdiff, and eyeballing the same thing twice is makework.
git diff is a nice tool. But it has it limits. 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...@lists.debian.org
Archive: https://lists.debian.org/20141103213245.ga4...@client.brlink.eu
Re: dgit and git-dpm
* Ian Jackson [141030 13:42]:
> Thorsten Glaser writes ("Re: dgit and git-dpm"):
> > – I’d prefer users of even dgit, no matter how good it may be, to
> > not rely on that.
>
> Again, why ?
To do an NMU, one has to generate a debdiff anyway to post it to the
bug report (as the rules for NMUs mandate).
And the debdiff is the real difference so the real changes done, so
worth looking at.
How is being quite sure what would be in there with dgit that much
different as with other NMUs? Where is the difference to
"I just applied those two patches from the 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 subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20141103061735.ga1...@client.brlink.eu
Re: Bug#752450: ftp.debian.org: please consider to strongly tighten the validity period of Release files
* Christoph Anton Mitterer [141030 05:10]: > To be honest, it's really awkward to see how much all this is apparently > fought against. You have been told again and again that what you suggest would make the whole thing less useable to the point that it reduces security for many people. You have been told that your thread model is quite strange, in that you assume that people will - not only notice every MITM with too old a signature even though you suggest to change the system so that this will cause far more false positives, - but will also investigate every short network or mirror problem so that the far easier MITM of making the security mirrors inaccessible (which your suggested 'improvement' does nothing against) is not possible, - but are not able to notice if there are no security updates applied. What do you expect? That people on the list think it is a good idea to do what in their eyes only lowers Debian's security just because someone continues to claim the opposite? Please take a step back and try to understand why people think this will not help (It is not because they do not believe in evil resourceful governments). This 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 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/20141031114804.gb1...@client.brlink.eu
Re: Bug#754513: ITP: libressl -- SSL library, forked from OpenSSL
* Mike Hommey [140713 12:55]: > > … while IMHO it's possible to safely mix openssl and libressl if we prepare > > for that (i.e. make sure that _everything_ in libressl is only exported > > with properly versioned symbols) > > Contrary to what you seem to believe, this only really works if *both* > libraries have versioned symbols. Otherwise, you can end up with > libraries linked against the unversioned one using symbols from the > versioned one at run time when both are loaded in the same address > space. Actually, "both having versioned symbols" 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 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/2014071333.ga6...@client.brlink.eu
Re: Why not 03 ?
* Julian Taylor [140601 14:29]: > I would not go into detail about O2 or O3 in the policy. > The meaning of these flags is very compiler specific. E.g. clang will > enable vectorization already at O2 and adds almost no extra passes with O3. > > I think it would be better to simply state: > If the upstream optimization options differ from the ones of the default > debian toolchain it is recommended to override the debian defaults to > match the ones upstream uses during packaging. > Upstream usually has choosen particular options for a reason, they know > their software best. I think one of the examples here was scientific software. Assuming "upstream knows what they do" is very unlikely to be true there. I'd rather argue for a "unless you know what you do, use -O2", which is almost the current state. (I'd rather argue that 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? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140601124250.gb2...@client.brlink.eu
Re: dpkg-dev: please reject native/non-native version when building native/non-native source packages
* Charles Plessy [140205 14:18]: > Who benefited directly from the change of behavior ? Nobody ? Then please > revert it; it was not necessary. Most import are people starting to create Debian packages. At least with 3.0 source packages they no longer have to care about the different meanings of native vs non-native. A package either is native, then both the version and the package reflect this, or they are non-native. No more chances to only switch one of the fields but not the other by mistake. It also helps users, as it makes it easier to guess what things look like, from only looking at the version. Finally it makes it easier for writers of tools to deal with Debian packages, as there are some absurd corner cases fewer. (The most absurd one is a 3.0(quilt) with a package without hyphen. The resulting filenames are simply ...). > Alternatively, please rename the "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 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: http://lists.debian.org/20140205172131.gb1...@client.brlink.eu
Re: Bug#737634: dpkg-dev: please reject native/non-native version when building native/non-native source packages
* Sam Hartman [140205 13:27]: > no, that means I have to maintain the artifact (namely the > .orig.tar.gz). > The archive software (both reprepro and dak were I to use that) require > that the .orig.tar.gz not change checksums. > > I don't want my build machines to be able to push back to my master > repository. > Nor do I want to have to release upstream versions if I lose state on my > build machines. > So this violates my requirements because I have to maintain an artifact > of dpkg-source (the .orig.tar.gz) and makesure its checksum never > changes. 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 debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20140205171418.ga1...@client.brlink.eu
Re: GnuTLS in Debian
* Thomas Goirand [131228 08:30]: > don't think it does anymore, especially seeing that almost no upstream > author cares about Debian's nit-picking on this particular issue. We're > just beating ourselves for no valid reason. Almost no upstream author cares about licensing at all. The mayority of them has no problems giving self-contradictionary terms. Distributing stuff with no license at all. Or simply copying other people's code without looking at the license or even without including any license statement or even copyright notice. Debian is no corporation 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. 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/20131228100904.gb12...@client.brlink.eu
Re: GnuTLS in Debian
* 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 unfairness. This > >> is obviously not Red Hat's fault. > > > Could you please stop using that word "idiosyncratic". > > I believe idiosyncratic is exactly the correct term: > > idiosyncratic > adj 1: peculiar to the individual; "we all have our own > idiosyncratic gestures"; "Michelangelo's highly > idiosyncratic style of painting" > > and therefore decline to stop using it. Given that the GPL FAQ and thus the authors of the license seem to be of the same opinion, calling an interpretation you do not like as "peculiar to the individual" is already quite derogative. Using a term that sounds quite similar like idiotic for this is something even a troll could not do better. 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/20131228100308.ga12...@client.brlink.eu
Re: GnuTLS in Debian
* Russ Allbery [131224 01:42]: > On the contrary, it's Debian's insistence on following an idiosyncratic > license interpretation that's creating the supposed unfairness. This is > obviously not Red Hat's fault. Could you please stop using that word "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
Re: think twice before enabling -D_FORTIFY_SOURCE=2 for C projects without thorough build-time testing
* Kees Cook [130921 17:08]: > In a theoretical sense, sure. In this particular case, why bother breaking > it when it's a trivial 1 line fix? My original approach was to fix it in > libc and do a mass bug filing. Everyone wins. If we want to reject the > undefined behavior, we should modify the compiler to reject it. Seems to me > it's a bug to even allow undefined behavior. The whole point of undefined behaviour in C is that the compiler/implementor/... does not have to care. Checking every time would make it slower, requesting any specific behaviour would make it slower. (Some argue a compiler might not even reject a program with only undefined behaviour, but that the standard required some program as result, just making no claim about what that program should do). The compiler not warning against it is a shortcoming, but not a bug. Writing a program 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 a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130921190422.ga11...@client.brlink.eu
Re: new hashes (SHA512, SHA3) in apt metadata and .changes files?
* Paul Wise [130802 15:54]: > > In any case, removing md5 support seems like a bad idea to me right > > now, as older software might not have been adapted to check the other > > hashes, or would imply breaking the current .dsc and ,changes formats, > > as the Files field uses md5. > > We've had SHA1 since before snapshot.d.o data started (2005), I would > guess any relevant software would have been updated in the last 8 > years. In 2008 ubuntu had Sha256Sums wrong which showed that back then almost not software even bothered to check those fields: https://bugs.launchpad.net/ubuntu/+source/apt/+bug/243630 non-md5sum hashses in Sources generated by DAK were incomplete until the generation code moved away from apt-ftparchive (early 2011 I think), thus only the Files: part with md5sums was the only reliable way to get the list of all files belonging to it. Support for non-md5sum hashes was added to dpkg-scansources/apt-ftparchive with apt (0.7.25.3) released to unstable 2010-02-01, first released with squeeze. So it is not some 8 years. It is more "since squeeze" that Debian and some of the common tools even produce complete 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 "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130803075234.ga3...@client.brlink.eu
Re: AGPLv3 Compliance and Debian Users
* Howard Chu [130712 03:51]: > Indeed. If you're a dissident fighting your own government, then > complying with a license that can only be enforced by a government > agency is probably the least of your worries. Indeed. That's why every interpretation of the dissident test I've heard assumes you are a dissident that had to flee his country. If your new host country then has to forbid you earning money with the software you know best because you had to violate the license to not be caught back when you still were at home, then you are caught in the extreme situation 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://lists.debian.org/20130713234247.ga5...@client.brlink.eu
Re: Berkeley DB 6.0 license change to AGPLv3
* 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 bit of a hassle, but worst case means that you cannot help > > others with the software changes you have done (bad enough but worth the > > hassle to have the source) if you miss some of the sources. But if the > > sources may contain any passwords or other internal data you cannot/do > > not want to share, so will likely the binary so that is no difference. > > On this level, the analogy GPL/AGPL still seems correct to me. For me GPL is like police patroling in the streets and AGPL is like policy getting the right to visit my bedroom at evening to look under the bed for monsters at their discretion. > A software distributed under AGPL will likely come with mechanisms > already in place to point to its source code --- that might not be the > case today yet, due to the scarce popularity of AGPL, but that's a > separate matter. That means that you can easily run unmodified version > of an AGPL'd program, for any purpose, without particular restrictions. I hope will all agree that the unmodified case does not matter at all. > If you modify the software you might get in trouble but, according to my > personal ethics, that's the trouble you should have. I accept that I am not allowed to modify some software. But I refuse to call such software free. > However, please > note that as long as you run the software only for yourself, you don't > have any problem. This is not the 1990ties anymore. Not allowing net access is quite an big contraint. Some better definitions might reduce the problem here. But given the way section is formulated I see nothing that would make an exception for something only used by me and everyone else interacting with it only by getting a loging prompt and a failure message when they do not provide my username and password. > You might encounter problems only in the case you've > modified the software, you want *others* to use it over the net, and you > don't provide the source code that include your modifications. So if I patch a IRC client for my personal use to also show me some other information (as I do not want too many open windows) and that client contains AGPL code, does that fall under section 13 (assuming it supports CTCP)? Have I lost the right to patch my programs locally in a quick and dirty way embedding hostnames and passwords and logic to access some private services in it without implementing a fake-irc server for that information or some general message passing mechanism? Even if defining the undefined "interacting" to need more interaction, let's look at some website provided by some of the "all-in-one" thing. Assume it has some content mangement part, partly showing public information, partly only accessible by me (or if "I" in this example was a company by my employees). And also a blog with comments (as I think it will hard to define "interacting" so narrowly that it will not contain that). Now if I want the private part to show me some information from some other source, I am again forced to have split things 'cleanly' on my systems with AGPL. > That shift is coherent with the shift in the most common deployment > [...] Not every solution can be shifted. If some fly does not allow me to sleep by its noise, I will either kill it or open an window and throw it out. But if I had a cat and that would be too loud, neighter would be a solution (perhaps the second if I lived at ground floor). And if you have a baby, ... There can be no freedom without restricting them to actually have them in the one way or the other. But for such a restriction to be justified, it needs both to be effective in protecting another freedom and not cause greater harm than it brings. In every way I see that you could make the definitions, AGPL will fail at the one or the other: Assume a AGPL program being modified or a program using AGPL libraries to be interacting only via answering HTTP Requests and returning all it's source code when "/source.tar.gz" is requested and giving proper notice of this and the license and so on. Either the AGPL permits such a program (or any AGPL program transformed into such a program) to be run bound to a private IP or localhost and all user interaction via a reverse proxy or loadbalancer that returns 403 for "/source.tar.gz" or it forbids it. In the first case the added restrictions are totally useless, especially against the big "software as a service" players that it claims to target, as those will likely have some loadbalancer doing some filtering anyway. I
Re: Berkeley DB 6.0 license change to AGPLv3
* Stefano Zacchiroli [130704 09:24]: > I mean, sure, it *is* more tricky to provide such a URL for users that > will be running a *modified* version of INN. But it is exactly the same > kind of difficulties that people distributing modified copylefted > software will have to face to uphold GPL (or equivalent) terms. 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 bit of a hassle, but worst case means that you cannot help others with the software changes you have done (bad enough but worth the hassle to have the source) if you miss some of the sources. But if the sources may contain any passwords or other internal data you cannot/do not want to share, so will likely the binary so that is no difference. With AGPL you are no longer allowed to run the software in this case. I do not see how a software restricting running a software can still be called free. Low quality software modifications are not the best. It would be far nicer if anyone just wrote nice general frameworks for their specific needs and submitted them upstream. But limiting the users freedom to be able to do and finance that is absurd. If you are no longer allowed to make some quick and dirty modifications to make our software work for you, then in the sum it is no more free at all. > For people who > are fine with the copyleft approach (and of course not all of us are) > AGPL shouldn't be particularly shocking. Sorry, once I am no longer allowed to run some software on my computer because I modified it to my needs, then it simply is not free. People still calling that free is shocking for me indeed. > In that sense, AGPL is just a > new release of GPL that 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. 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/20130706154116.ga3...@client.brlink.eu
Re: Berkeley DB 6.0 license change to AGPLv3
* Paul Tagliamonte [130702 15:15]:
> Again, why do you plan on removing free software from main due to a
> change in license?
Licenses matter. Just because something it acceptable for Debian
main does not mean it is a good idea to have something licensed under
a specific license. So removing 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.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20130702175730.ga3...@client.brlink.eu
Re: jessie release goal: verbose build logs
* Matthias Klose [130614 13:36]: > Verbose build logs allow to analyse package builds and give hints to more > issues > regarding the build, especially for the hardening flags. The lintian > hardening > checks are incomplete, because they rely on the inspection of the generated > binaries, which may be incomplete especially for many plugins or dynamically > loadable extensions. While I agree that a build log without compiler arguments is essentially worthless, could we please not call something that is not too silent "verbose"? Verbose is something that 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. 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/20130614223601.gb3...@client.brlink.eu
Re: default MTA
* Jonathan Dowland [130611 18:35]: > On Fri, Jun 07, 2013 at 12:45:07PM +0200, Marc Haber wrote: > > Sendmail has just one more layer of indirection by virtue of the m4 > > macros. Postfix has most of its behavior hard coded in the C sources, > > while exim's behavior can be controlled by run-time configuration if > > an advanced user wants to do things that Debian's abstraction layer > > was not designed to handle. > > There are a class of users between beginner and exim expert for which the > current state of affairs is not optimal. I don't know how big that class > is but I've been in it for ten years. The only class of users I can imagine the current situation not optional is someone being used to postfix[1]. When I remember learning exim I found it quite nice that the config is quite self-explaining what it is actually 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 debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130611210523.gb3...@client.brlink.eu
Re: default MTA
* Chris Knadle [130606 14:53]: > I'm glad you asked this, because it prompted me to investigate further. This > was something I was told was commonly done, but it looks now like it might be > a misnomer. I'm not able to find a concrete example of a system that allows > SMTP MTA transfers but doesn't allow telnet to the SMTP port. [The instances > that seemed to fit the symptoms look like they have more "normal" root > causes, > such as ISP port 25 filtering.] > > Because I had repeatedly been told that telnet to the MTA was a security > problem, prior to now I had suspected that blocking telnet to SMTP might be > possible via firewall filtering that distinguished the "type of service" > somehow, but after doing some packet sniffing and examining the resulting > packet internals I'm starting 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 the telnet protocol. 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/20130606171839.ga3...@client.brlink.eu
Re: [clang] Report bugs on packages failing to build with clang
* Colin Watson [130604 15:47]: > On Wed, May 29, 2013 at 10:08:59PM +0200, Michael Tautschnig wrote: > > I think this will likely improve code quality, hence I'm much in > > favour of this, in particular when it comes to outright bugs. But a > > non-negligible fraction of the build failures, I believe, are due to > > the use of nested functions. This could well be considered design > > decisions when used intentionally (unlike, e.g., [684508], where I > > have already filed a bug). I'm not sure whether upstream will be very > > keen on such bug reports? > > clang.debian.net lists 39 instances of these, though I think the buildd > is a bit behind so there are probably a few more. At least one more of the 432 "Not categorized" is also due to this missing feature in clang (reprepro). As clang seems to gives quite 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 functions. 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/20130605194043.ga3...@client.brlink.eu
Re: default MTA
* Marc Haber [130530 12:39]: > While I don't consider postfix as bad as you describe, I tend to > describe Postfix as the menu in a better restaurant: A relatively > small number of sophisticated dishes which you can choose from, and > if you like them, you will be perfectly satisfied. If you want fries > instead of plain potatoes, you're basically hosed. It's not that bad. Even the postfix kitchen can make fries. The tricky part is having one person served potatoes while the other person asks for fries, because the person putting those on the dish is not allowed to look at the order so they cannot determine from the drink whom they are making the food for. You need to employ two of them, one doing potatoes and the other one fries, but the waiter is not allowed to chose which kitchen the order is sent to, so you have to tell the waitor to write the order 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. 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/20130530135531.ga4...@client.brlink.eu
Re: default MTA
* Chris Knadle [130529 08:29]: > - Exim configuration is more human readable than Postifx's, IMHO. > > Postfix configuration is concise but terse, and there are typically > blocks of options separated by commas that doesn't easily allow > commenting on specific config options. Configurability is an important point. Having had to use postfix lately I'm quite suprised anyone voluntarily uses that thing. Postfix feels like some ad-hoc configuration gone absurd, by only making special use cases configuable and then misusing those options for other things. Together with this splitting in many little programs which all lack most of the information, configuring postfix is a large puzzle and any advanced postfix configuration (even from the official documentation) looks like McGyver was out of duct-tape but had to build a nuclear reactor from 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 "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130530091105.ga3...@client.brlink.eu
Re: parsable copyright format 1.0 (jessie release goals)
* Sune Vuorela [130512 12:43]: > It is too much work for far too little gain. What *is* the gain? > What is the gain of copyright files? One big gain of a copyright file is the act of doing it. For software to be distributable every copyright owner has to have given his permission. To know that you have all those permissions, you first need to know who those people actually are. It also documents our reasonable exercises to reach our believe that this is distributable. I'd guess in some legislations such efford can make the difference between "just distribute it no more" 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
Re: Merging / and /usr (was: jessie release goals)
* Roger Leigh [130509 13:34]: > The assumptions here are that a separate rootfs decreases the chance > of breakage, and that you'll need the rootfs to perform the rescue. No, the point is that having two file systems reduces the amout of breakage you get. All the important stuff is in / while /usr is mostly static data easily (at least outside /usr/local, and even there more likely than say /etc) recoverable or not that important if lost. Also with the tools in / you can usually repair problems in /usr. There is just the right kernel and just the right versions of all tools. You can do most of the stuff with some rescue-disc, if the versions fits. But too often there are differences. And getting some other tool it misses means you need to either install it in an ramfs and hope you do not need to reboot or you need to have some spare partition on the hw left. And you do not have access to your fstab. While each of those problems is managable alone, they sum up. Each adds to the time you need. And time is often something you do not really want to spend in case you have a problem. And while there is no proof that when having one small and one large partition, the small partition is less likely to fail than everything in one large partition together, both reason and experience demand that this point is quite more than an "assumption". > Regarding rescue, the initramfs has a rescue shell which I've found > to be just as useful as single user mode. Once it has mounted the > rootfs, you can chroot into that and do whatever you would normally > do to rescue /usr. [Assuming a separate /usr.] If it doesn't get as > far as mounting the rootfs, then you'll need some rescue disc in any > case. I find the busybox shell to be just as effective as a rescue > disc in most cases. "rescue /usr" in a seperate / + /usr setting usually means making sure it can be mounted again. (Or to transfer data elsewhere, which is also much easier when your normal network setup is already available). > In the case 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 words: to make essential functionality not available if /usr is broken. 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/20130509150537.gb4...@client.brlink.eu
Re: Merging / and /usr (was: jessie release goals)
* Marco d'Itri [130509 16:03]: > So, please let me know if you have some technical objections better > than "it's an hack". Having a seperate / means you have an instant rescue image that has just the right kernel and tools you need to repair the rest of your system. You also have one small filesystem with all the important stuff like /etc in it while the boring large distro stuff is in another partition. You also have a partition border between most of the random stuff and the important stuff. All those are real advantages that people care about. A simple "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". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130509143822.ga4...@client.brlink.eu
Re: jessie release goals
* Wookey [130507 23:31]:
> The tradeoff is:
> 1) (Move _all_ headers to /usr/include/triplet)
> * Much duplication of installed headers
> * Only one system include dir, which fits current build-system
> expectations
Which would also punish the libraries getting headers 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". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20130507230831.ga5...@client.brlink.eu
Re: 2013 sometimes still feels like 2003 or 1993 (Re: NEW processing during freezes
* Russ Allbery [130504 00:32]: > The way to ensure that builds in non-clean environments work properly is > to devise a method for testing them, and to do those tests on a regular > basis and turn test failures into bugs. Noone is speaking about non-clean environments, but only about non-minimal, non-artifical ones. > Trying to get at this testing indirectly by putting conditions on initial > archive uploads doesn't really accomplish the goal. It's a very random > and scattershot way of testing that already doesn't work for any of us who > use pbuilder 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". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130503230506.ga18...@client.brlink.eu
Re: git as a source package format?
* Daniel Pocock [130501 21:28]: > Would there be any hard objection to a source package format based on > git-bundle? I think a git based source package has quite some problems. - failing to properly make changes visible While you can express every history-graph in git, that is not an advantage. Changes relative to upstream sources found in a Debian source package should not only be present by recording history, but as many people as possible should be able to see what is actually changed in the package, and to reuse those changes elsewhere (either as upstream or sidestream). Debian is not like the BSDs[1] that just import some source into their CVS, make modifications at will, sometimes merge a new upstream version and some years later the only way to see what they changes is doing a full diff and hope you can isolate some of the changes. We do not fork but want the changes we need either upstream or also useable by other. Other distributions and users not using Debian are not our enemies, but partners towards a general advance of free software. While you can use git to keep changes in a way to make them reviewable and ready to transmit them elsewhere (git rebase -i is great), if you have that information ready then generating a "3.0 (quilt)" package is trivial, and having changes expressed the same way in different packages makes it easier for everyone to find the information. (At least any other format should come with a way to support being show at patch-tracker.debian.org). [1] They might have changed. It has been a long time since I looked. - hiding stuff in obscure formats While a git-bundle is a format that is not that complicated to use once you are used to it, even the average git user will rarely know how to handle it manually. That means people not having the Debian tools available can hardly do anything with them on their own. Additionally needing to have some special VCS installed to look at a specific program can be a huge burden. While git got quite a decent pervasiveness now, not everyone has it and with the next hype it might equally fast being gone again. At least using such a git format should be absolutely forbidden if upstream uses any other free VCS. (I've seen packages in Debian that used one VCS, having upstream some inter-distribution working group that used anyother VCS that finaly was based on some big comercial player that published the free version on yet another VCS. That's annoying.) > In other words, dpkg-source would extract all repository history (or all > of the branch used to build the package) using the git-bundle command. > The bundle file would then be uploaded to the FTP server instead of a > traditional source tarball. > > A slight variation of this idea is that the repository would be cloned > into a temporary bare repo, and that bare repo would be tarred up and > the tarball would become the source upload. - legal problems if you have all the history it is practically unreviewable for undistributeable stuff, and if that stuff is old enough, it is usually quite hard to get it out of the history. (There is filter-branch, but one does not take such an approach lightly). This is not a big problem for having those at alioth or other sides (You'll have to ask a lawyer, but I'd guess the ill effects are either limited to Debian losing all their money or only the team/uploader it is in. And likely alioth admins can just remove the git repository there in case something is found or someone sues and thereby reduce any penalties perhaps even till none are left. But the source packages are found on DVDs and mirrors all over the world. Many people help us distributing Debian. We owe them to do out best to keep them out of legal trouble for doing so. And source is what people need to actually make use of many of the software (especially GPL). People providing stuff based on Debian (be it pre-installed computers, appliances based on Debian, distributions based on Debian, ...) need to have the source ready to do so. If they use Debian binary packages, just keeping the Debian source package is the obvious way. Unless we switch to a source format where those can no longer be legally distributed. > Then again, some of that behavior could be achieved by creating an > `apt-get vcs-clone' function 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 "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130503165022.ga3...@client.brlink.eu
Re: 2013 sometimes still feels like 2003 or 1993 (Re: NEW processing during freezes
* Holger Levsen [130502 12:28]: > > People do this all the time: upload packages built against local packages, > > experimental or even on Ubuntu to Debian sid. > > /me shivers. This hurts. There is no reason not to rebuild in sane > environments. Can we please fix this for the next release?! I'm not sure the cure is not worse than the problem. Apart from the big problem of making it even easier for people to upload trash without testing it (both wasting buildd resources and lettings users install broken packages which any trivial testing would have catched, from which I've seen far too many), reducing the buildability of packages is a cruical problem for freedom. If we step towards rebuilding everything in a highly artifical environment, it should be made clear that a package having missing build-conflicts or any other bug preventing it from being built on a real system should still be important bugs afterwards. Once we drop that and only give people the right to modify the software we distribute but no longer the possiblity to do so on their own, the "Free" we are so proud on gets mood. Also build systems tend to degrade quite 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 with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130503171134.gb3...@client.brlink.eu
Bug#706160: general: it should be easier for ordinary developers to work with Debian packages
* 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 are too many arcane commands that have to be called. ./debian/rules build fakeroot ./debian/rules binary Everything else is mostly convenience wrappers. > - It's not obvious how to modify the patch set directly. modify upstream files, call dpkg-source --commit > - There is no attempt at managing multiple source versions. First you say things are too complicated, then you complain about some obscure missing option I never found any use case for. > How Simple Tasks are approached: > Given a program that is not packaged for Debian and is not > sufficiently useful to the general public to be worth the maintenance > burden, install it such that the package manager knows about it. > Debian: > - checkinstall is buggy, quirky, and has no upgrade path. > - I still haven't figured out how to do this easily. Based on the > 'hello' package, which is the simplest possible package, this > requires writing a hundred lines of voodoo. A random sampling of > existing package I've looked at agrees with this as a lower bound. You can't have easy and high-quality at the same time. Most of the tools used for official Debian package have the minimal complexity needed for some quality. Apart from having someone write tools to simply create private packages there is not much that can be done here. (and from what you describe for Gentoo, I do not really see how a dh_make ; vim debian/* ; dpkg-buildpackage is more complicated than the Gentoo case). > Given a completed set of package information for such a package, > distribute it in a way that is easy for others to install. > Debian: > - Still haven't figured out the right way. There are many ways, because needs are different. > - I did find the 'dget' command that does some things. How was I > supposed to know about this obscure command for a common use case? dget is simply a convenience wrapper. Just have three files to download for a source package. Anyone can click at three links easily. > - You probably have to ship the whole huge .orig.tar.gz file, even > though it's available on the internet under a different name, or > even if it's really a git snapshot. Sorry, but this is bullshit. If you want to make it easy for users, put the .orig.tar.gz there. References too external resources will always go stale and are and endless source of user frustration. > Given a program with a buggy upstream release, apply a patch. > Debian: > - After trying to make local changes, it said: dpkg-source --commit > - But it is tedious when you already have a full patch from upstream. patch -i patchfile ; dpkg-source --commit I thought it was about users knowing the basic command line utilities? > Given a program with buggy Debian packaging, revert a patch. > Debian: > - no clue, it keeps trying to readd the changes and it's not obvious > how to wipe the working tree. The very easy way: just revert the change and add another dpkg-source --commit The direct way: revert the change, remove the line from debian/patches/series The complicated way: use quilt or some other high-level tool. >Gentoo: > - Assume that you're competent enough to get ahold of a patch. > - Add the patch to files/ (which is shared between all versions of >the package, though you can of course use a different name). > - Add the filename to the PATCHES=() variable, remanifest. > > Gentoo: > - Remove the filename from the PATCHES=() variable, remanifest. Yeah, because every patch can simply be removed without any effects on the other patches, you can just apply any patches you need to the version you need. And if it doesn't you can just apply manually, fix it and produce a new clean patch. NOT, seriously. That you can just do stuff in your working directory, build and fix again iteratively in your working directory and finally have some working package is in my eyes one of the biggest strengths of Debian's package format w.r.t. low entrance and making it easy for unexperienced people to use Debian to meed their needs. > Gentoo: > - cp foo-1.ebuild foo-2.ebuild; ebuild foo-2.ebuild manifest > - Typically, the source URL will automatically change based on the > version number. If this is not the case, it is very obvious to fix. your gentoo solution is the equivalent of copying the debian/ directory around. > In conclusion: > The current Debian way is complicated. The Gentoo way is simple. This is > not tied to the fact that Gentoo is a source-based distribution, although > that does enc
Re: Go (golang) packaging, part 2
* Russ Allbery [130201 21:38]: > > If you want bleeding edge, then you are not a normal user and you > > certainly aren't a system administrator that wants to keep a controlled > > system they can reproduce. > > Speak for yourself. I've been a system administrator for twenty years, > and sometimes I have to deploy bleeding-edge code in order to accomplish a > particular task. You can do that in ways that also give you a > reproducible system. > > Using Debian packages is a *means*, not an *end*. Sometimes in these > discussions I think people lose sight of the fact that, at the end of the > day, the goal is not to construct an elegantly consistent system composed > of theoretically pure components. That's a *preference*, but there's > something that system is supposed to be *doing*, and we will do what we > need to do in order to make the system functional. > > Different solutions have different tradeoffs. Obviously, I think Debian > packages are in a particularly sweet spot among those tradeoffs or I > wouldn't invest this much time in Debian, but they aren't perfect. There > are still tradeoffs. (For example, Debian packages are often useless for > research computing environments where it is absolutely mandatory that > multiple versions of any given piece of software be co-installable and > user-choosable.) Of course there are trade-offs. For every rule, as sensible it might be, there can be a need great enough to ignore it. Using software not properly packaged is not so different from modifying files in /usr/lib from the distribution, compiling passwords or other hardcoded stuff directly into programs, using binaries you have no source of or even using those and patching the binary or many many other things you can do and sometimes you have to do. That there are no guidelines that are absolute and that may not be better ignored in some cases does not change that in general they show a useful path that leaving without a good reason is no good idea. And a "only use distro packaged software" is a very useful guideline. There are so many advantages in this that "you cannot get this with distro packages" is a very good argument against anything you cannot get this way. There will always be a case where there can be a more 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, ...) around as possible. And most of the features for developers are just additional nightmares for the administrator. 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/20130201223958.gb3...@client.brlink.eu
Re: Packages with incomplete .md5sum files
* Andreas Beckmann [130115 11:20]: > On 2013-01-15 10:29, Julien Cristau wrote: > > There's no requirement for md5sums files in the first place AFAIK. How > > are incomplete md5sums worse than no md5sums? If anything this stuff > > should be minor IMO. > > If a package is shipping no .md5sum at all, it will be created by dpkg > at installation time. > > A partial .md5sum however will not be "completed". This hides some > shipped files from debsums, defeating its purpose. That depends what the purpose is supposed to be. Having debsums by default create fake .md5sum files for packages not shipping them defeats the purpose md5sums is most useful for: to check that the files in your filesystem are correct and where not corrupted by faulty hardware. (As in my experience almost all of those problems happen when writing to the disk (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 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/20130115215008.ga3...@client.brlink.eu
Re: [RFC] Go (golang) packaging
* Michael Stapelberg [130102 09:13]: > Given that we already have python-* and ruby-*, I’d find golang-* more > consistent. We also have lib*-perl. Ruby seems to have changed recently from lib*-ruby to ruby-*. (Does anyone know of the reason that changed? For I only remember all the reasons for the old naming scheme and see no reasons in favor of the new) > Which specific tools/places do you have in mind that have to > truncate package names? Most GUIs will truncate depending on the size of the window. > >> (and of course just “codesearch” for the binaries). > > > > I assume s/binaries/sources/? And I'd suggest to just not policy the > No, I really meant binaries, as in “cgrep”, “cindex” and “csearch” in > this specific case. And what is the name of the binary package those programs will be in? > > 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? > As pabs has pointed out, I did that, but the general rule of thumb is > that we want to have lots of packages first and an archive section > second. Too avoid packaging mistakes and to have the wording ready I'd suggest to already prepare the wording (I guess in the section later will be everything that is is now in libdevel plus golong toolchain 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
Re: [RFC] Go (golang) packaging
* Michael Stapelberg [130101 14:45]: > Furthermore, the package names should be e.g. “golang-codesearch” for > the library code.google.com/p/codesearch Please also consider "codesearch-golang". Especially with longer package names not everything can show the full name so the beginning should be the more important information. > (and of course just “codesearch” for the binaries). I assume s/binaries/sources/? And I'd suggest to just not policy the source package names at all (as there really is no "one rule who fits them all" and there is no reason to have 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 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/20130102071555.ga3...@client.brlink.eu
Re: unsafe use of gpg
* Ansgar Burchardt [121214 16:18]: > 2, Not asking gpg to verify signatures: > > I also found packages that call gpg in the form "gpg $file" and expect > gpg to verify the signature on $file and output the signed data. Indeed > it does so for *signed* files, but if you just give it unsigned data > packed into an OpenPGP message, it will happily just extract that > without caring about signatures. (One can generate those messages with > 'gpg --store'.) > > Sadly gpg doesn't seem to provide a painless way to check for a valid > signature and extracting the signed data[2]. Or did I miss something? Instead of inventing new ways for this, I'd suggest to instead ask the more important question: What worth is checking for a signature if you are not checking who is signing it? Better either use --status-fd or use some wrapper like libgpgme to retrieve what key actually signed it and check that information instead. (While "just dump your own keyring somewhere and assume everything in there might sign anything and be trusted" might look like an easy hack, it hardly scales and might be quite brittle assuming quite 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? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20121214222149.ga19...@client.brlink.eu
Re: Really, about udev, not init sytsems
* Jon Dowland [121130 16:06]:
> I do not agree that reconfiguring your machine to avoid an initrd is a normal
> standard desktop configuration. There's also several other things about your
> setup which I would argue are not standard (see below)
Will Debian come by default with 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.debian.org
Archive: http://lists.debian.org/20121130182310.ga18...@client.brlink.eu
Re: Really, ...
* 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 happens if one > > runs into a not-yet fixed bug is an important issue for many people. > > Absolutely. But again, this is true for any software and this is > *especially* true for old designs which couldn't cover certain setups > which simply didn't exist back then. But you have to understand that you put something that only does promises against something that exists. Something that exists means that people have experiences with it, now how it behaves, know how to debug it and now how to make it work again when it breaks. On the other side is systemd which has not yet been available in a single Debian release and could not yet prove itself anywhere. So if it would be proposed as some more init system to support or a cool new stuff to experiment with it, you would not get that much emotional reactions. But as people demanded making it the only available system before it could prove itself and while all most people know is that it is quite a different design which wants to solve all the problems at the same time (which often enough means it creates more problems than it solves) and that it has ties which other projects people have had no good experiences with (for enough people pulse-audio is a synonym of "my sound is not working") you should have a different reaction than ridiculing people not wanting to bet their future on it. > You know the famous quote: "640 kB ought to be enough!" But I also know which happened to the 80286, which offered quite a lot more memory and many nice things like fine grained memory proection: It only looked nice on the paper but (with some noble exceptions) was just not worth the hassle, so that people prefered to stay with a 1 MB limit for many years to come. > Yes, I see your point. But again, what I said before, how many people > are actually digging into such low-level code? Someone who is jumping > into kernel or plumberland development always has to have a certain > background knowledge. It requires more skills and experience as > opposed to writing desktop applications or smart phone apps. This is exactly the mindset that scares people away from systemd. An application that does not behave is no big problem. One can easily ditch it and replace it withanother. One has all the bells and whistles of your full desktop available while you debug it. It's all quite well understood. If your init system does not work -- and one day it will not work, there is no way that can be avoided, there is no perfect bug-free software out there and especially when the task is to cope with all possible hardware and their little quirks and timing problems, all the different combinations of services and daemons out there and so on -- you are set back much more. So if you end up in a situation like that, what do you do as user? Some will say "oh, it does not work. Let's try to reinstall the machine and if that does not help let's try another distribution. Perhaps the next release in two years will work. Or perhaps what I wanted to do is not that important, so I will just not do that". But for many people that would not be a solution but the absolute nightmare. Being at the mercy of the computer; not being able to decide what your machine does and what not; being totally powerless and dependent on whether someone has decided that what you want to do makes sense or not. So being a more complex thing means it must be easier. Easier to understand what it does. Easier to understand why something does not work. Easier to fix it once it breaks. > But do you really think that we should keep every part of the system > brain-dead simple that everyone understands at the cost of reliablity > and performance? Do you really not understand why people think that? And what does reliability mean if it can stop working and I can do nothing against that at all? > I see your argument about keeping stuff simple, but again, if you want > to be able to solve more complex tasks with your computer, the > software on it itself has to become more complex. Strangely the complexity of the solution has seldom been related to the complexity of the problem and always been the opposite of reliablity in the past. So this is merely a false assertion. > > Claiming that it will work for everyone and that > > anyone not being able to name a problem existing now has no arguments > > does not help. > > Do System V Init or Upstart work in EVERY single use case? Actually, all my experiences with upstart has been when it does not work. And then it was always a pain to work with. So in my experien
Re: Really, ...
* John Paul Adrian Glaubitz [121129 18:12]:
> This is actually a true valid point which I personally would accept as
> an argument against systemd. Without looking into the details, this
> seems to be something that can be fixed by a new upload, doesn't it?
Almost any actual specific problem can be fixed with a new upload.
Any reason given to believe that there will be problems left or that
remaining problems will have a bigger impact are not probable with
actual problems (because any actual problem usually can be fixed,
or claimed to be a non-problem).
I think noone claims that systemd would not be the superior design
in a world where there is bug-free, perfect software prepared to handle
every possible situation it will be thrown into. 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 happens if one
runs into a not-yet fixed bug is an important issue for many people.
Free software has always been a way to avoid being helplessly at the
mercy of some software. So handing over the basics of your computer
to a much more complex system can be quite frightening for many
people around here. Claiming that it will work for everyone and that
anyone not being able to name a problem existing now has no arguments
does not help. It only makes sure people are reassured that systemd is
not for them. Combine that with vocal demands that it should be the
only allowed init process 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". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20121129192240.ga16...@client.brlink.eu
Re: the right bug severity in case of data corruption
* Adam Borowski [121127 16:32]:
> So, what's the reason mbox is still the default in Debian?
Because it works and causes the smallest amount of problems
given all the other changes.
> Among other gains, data loss because of mboxo would be gone.
Continuing to call that "data 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
Re: Mass bug filling about proprietary code of adobe in our type1 fonts
* Adam Borowski [121125 15:20]: > On Sun, Nov 25, 2012 at 02:07:03PM +, Bart Martens wrote: > > On Sun, Nov 25, 2012 at 02:34:34PM +0100, Wouter Verhelst wrote: > > > If there is code in a font that has a license attached to it which does > > > not meet the DFSG, then it should go out of Debian; not because we're > > > not allowed to keep it in Debian by the author of said code, but because > > > we don't *want* it to be in Debian, according to the DFSG. > > > > I agree with Wouter on the above. Moreover, if it doesn't have a license, > > or > > it's not clear whether there is a license, or if the license doesn't allow > > redistribution, then it must go out of Debian not because we want it out but > > because we're not allowed to redistribute it, not even in section non-free. > > You might want to ask Adobe first, though, before removing anything. The EULAs of the different Adobe products are easily found in the net. And they also list many pragraphs about the stuff embedded into documents. Most of them are quite restrictive. For example for pdf forms (those pdf documents where the receiver can fill in stuff) created with Adobe programs, every organisation might as far as I read it either only distribute 500 different pdf forms to an unlimited amount of people, or a unlimited number of pdf forms to at most 500 different people (no matter how many normal licenses of the programs you have, I guess you need some special mass pdf form license otherwise). If I remember correctly for embedded font software (I think that means true type and non-rasterized postscript fonts), there is the permission to place a copy in one (and only one) printer. And 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 to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20121125154119.ga10...@client.brlink.eu
Re: the right bug severity in case of data corruption
* Christoph Anton Mitterer [121124 17:42]: > I've recently reported several bugs against MUAs and mail tools, that > employ the mboxo (note the trailing "o") format to either store or > import mails. > So,... bringing this up here at d-d, as I think it would be good for > Debian to have a well thought position in how to handle this family of > corruption bugs... I'd say if you complain about a tool not documenting what mbox format it is using, that is a minor bug. If you want an option to also support another mbox format but mboxo, then I'd vote 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 converted to upper case. 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/20121124201101.gb7...@client.brlink.eu
Re: [PROPOSAL v2] Orphaning another maintainer's packages
* 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 note of "will look into this later". > > Me. Does this also include packages where you are listed as Uploader? ;-> > It is a question of respect to the bug reporter to at least respond > to the issue. I do not disagree that it is something that should be done. But that does not mean it is never forgotten. (Or one discusses with the submitter privately and forgets to follow up in the bug report or or or). 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/20121031194817.ga12...@client.brlink.eu
Re: [PROPOSAL v2] Orphaning another maintainer's packages
* Andreas Tille [121031 08:06]: > > Consider the case where a maintainer objects. In that case you're > > counting in the previous "long waiting" time a period which the > > orphaner probably thinks shows disinterest in the package, but during > > which the maintainer may well feel (for part of the time at least) > > that the package simply didn't need any attention. > > I keep on thinking that we are talking about different packages. If a > maintainer is "simply feels that the packages didn't need any attention" > these are not packages which are for instance: > > - lagging *way* behind upstream (regarding time or version number) There were some cases in the past where the maintainer did not package new upstream version because they had some serious issues (or because they only wanted to follow stable releases in cases where stable and preview releases were hard to distinguish for a outsider) while someone else mistook this for a missing action. > - leaving open bugs simply unanswered (=do not give any reasons > for not working on a bug) 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 note of "will look into this later". > I do not speak about feelings but measurable facts. Many facts are not black and white, but in practise there is much of gray. > > Also this argument is a form of "this has been waiting for ages so now > > it is urgent" which I don't really agree with (unless there's an > > actual deadline of course). > > I would rather call it a "this has been waiting for ages so you are > obviosely not interested and no harm is done if I take action nowish". This assumes that it actually has been waiting for so long. Different people often see things from a different perspective. And the point of this waiting is exactly to make sure that this view is not missing. If it 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
Re: Mandatory -dbg packages
* Ben Hutchings [121028 17:02]: > There are plenty of bugs that involve 'undefined behaviour' that in > practice depends on whether optimisation is enabled. Unless you have a > good idea what's going wrong, how do you know that 'noopt' won't hide > the bug? If the bug still shows up with the library recompiled with 'noopt', then no harm done. If it is a bug in the library, you want to look there anyway (and you will most likely want to compile different parts of it with or without optimisation or any other technique; in any case you will want more of the library than just the binary and some debugging symbols of it). The only case where a noopt library variant is a disadvantage is a very ugly case of heisenbug, that is hidden by the slightly changed library. > Also, gdb and the GNU toolchain have recently got a lot better > at handling highly optimised code (tracking variables in registers, > treating inlined functions as logically separate functions, etc.). Yeah, they got a lot better. But even if gdb got perfect in that regard it can still not show what isn't there (like the value of a variable (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
Re: Mandatory -dbg packages
* Philip Ashmore [121028 09:12]: > Yeah, in (cough)Fedora, kdbg even offers to download and install > debug packages for you. > Debug packages also make back-traces more than useless, and > (cough)Ubuntu offers to download debug packages which it installs > and re-examines the back-trace to see if more are needed. While having some way to get the stripped debug info from the installed packages is nice to more easily get some debug information or to retroactively make a backtrace a bit more verbose, it is still not enough for all cases of debugging. Ideal debugging information 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 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/20121028103552.ga3...@client.brlink.eu
Re: Bugs filed in unexpected places
* Thibaut Paumard [121026 15:54]: > I don't see a reason to move it away from wnpp: its great to have a > central place for that information, but I agree it is useful to have > the info forwarded to other places (such as the PTS, and perhaps the > package's own bug page). Having a central page to show all of them is nice. Having them in one pseudo page is not really the optimal solution for that. (I usually only look for http://www.debian.org/devel/wnpp/work_needing instead because https://bugs.debian.org/wnpp is just too slow.) Putting it to the package's data is 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 listmas...@lists.debian.org Archive: http://lists.debian.org/20121026160646.ga29...@client.brlink.eu
Re: Discarding uploaded binary packages
* Chow Loong Jin [121020 18:10]: > The only argument I have seen for binary uploads is to ensure that DDs have > built the package prior to uploading it. But as someone else pointed out > earlier > in the thread, we seem to be trusting DDs a lot in other aspects, so why not > trust that they test-build packages prior to uploading them as well? Because trusting someone in one thing is not the same as trusting someone in another. Trust works best when there is accountablity. Having the binary file around, even if it is not easily accessible on some remote archive, noone can claim "I tested this, it just did work here, something must be different on the buildds" and hope to get away with it. Given that source only uploads where tried in another project and the results are scary, this accountability might make the difference to make it work. And to also name 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). 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/20121020162948.gb14...@client.brlink.eu
Re: Discarding uploaded binary packages
* Michael Gilbert [121017 22:19]:
> Anyway, reading again, I not sure that your reply actually considers
> build path sanitization problems, which is what my statement was
> about.
I'm stating that doing all the builds on buildds will not avoid the
need to fix the package. (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: http://lists.debian.org/20121017205532.gb5...@client.brlink.eu
Re: Discarding uploaded binary packages
* Michael Gilbert [121016 04:59]:
> Anyway, all of these build system path sanitization issues can be
> eliminated by using the buildds for all architectures, since paths
> will start with at least /build that requires root-level action to
> exist on users' systems.
They are not eliminated by using only buildds. They are only moved
towards people that want to build their privately patched software
then, which is something they have a right to do. A package not
building properly or differently when built in a clean system with
all the build-depended packages installed 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 "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20121017200750.ga5...@client.brlink.eu
Re: Debian should move away from MD5 (and at best also from SHA1) (in secure APT and friends)
* 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. > > This argument is based on the incorrect assumption that everyone in the > world knows md5 is broken. No it is based on the assumption that in that set of people that care about security at all but have little enough knowledge of security to mix up protection against faulty hardware with protection against attackers there is at least one user having heared the meme "md5 considered broken" and might combine those half-knowledges to the correct result that debsums is not about security against attackers. Causing at least one user to not think they could use debsums as protection against wilfull file modification by sticking with md5 is (given there are no benefits from switching hashes at all) a very strong argument that switching hashes for debsums to stick to the hashes it uses. 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/20121014111405.ga15...@client.brlink.eu
Re: Debian should move away from MD5 (and at best also from SHA1) (in secure APT and friends)
* Christoph Anton Mitterer [121011 19:39]: > On Thu, 2012-10-11 at 11:35 -0500, Peter Samuelson wrote: > > What makes sense is to use a hash that has the properties that are > > needed for a particular application. > Well... I think that's only really required if performance is very > critical, e.g. when you're on embedded devices or so,... but the places > I've mentioned should have probably no disadvantages by using a "strong" > algo,... not to mention that newer algos like Keccack are quite fast. There is a disadvantage of having longer hashsums, thus making it harder for people to compare. The only reason that for those md5 is optimal and not crc32 is that there is only one md5 and there is a nice always available tool to compute it, so people can compare it more easy. > > To use your example of dpkg file checksums, their purpose has _nothing_ > > to do with security. > Well their _intended_ purpose,.. that's right. > But nothing keeps people from using it a security manner (e.g. by > replication it to a "secure" remote node or so) and in fact... e.g. > rkhunter already has a mode 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 they can use that information for security. 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/20121012071732.ga4...@client.brlink.eu
Re: ${HOME} vs. g_get_home_dir ()
* Russ Allbery [120926 21:42]:
> > 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_home_dir directly.
>
> Oh, I'm glad that they at least document this. But it would still be nice
> if the default did the right thing.
Though I guess changing the default upstream is hard, given the feedback
I got in tha past and the general 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 Debian would profit from having a smaller diff).
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/20120927124400.ga13...@server.brlink.eu
Re: ${HOME} vs. g_get_home_dir ()
* Simon McVittie [120926 18:50]:
> ... but I don't think this is the right way to make it happen. Please
> research previous discussion to check that you're not missing arguments
> that have happened in the past, then if you still think your proposal is
> the best option, take it upstream.
This was already taken upstream and upstream's opinion was
"if we do this as the unix guys expect then users complain that
changing $HOME changes the home directory.".
> I can see the value in having everything follow the same precedence,
> $HOME > getpwent - predictability is good. However, having Debian's GLib
> contradict behaviour that is specifically documented upstream doesn't
> sound as though it promotes predictability.
It's nice to see this finally documented upstream. (Back in time
it claimed to get the home directory 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_home_dir directly.
Bernhard R. Link
(And tip of the day: If you are working with multiple home directories
regulariy and get tired of badly written programs confusing the initial
home directory with the current one, setting the initial home directory to
the empty string can help in many cases (though you lose having a
default one for programs not getting one set)).
[1] For example
http://developer.gnome.org/glib/2.33/glib-Miscellaneous-Utility-Functions.html#g-get-home-dir
--
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/20120926174814.ga7...@client.brlink.eu
Re: assumptions about the build environment.
* peter green [120921 21:26]: > I just discovered that on my beagleboard XM (under armhf sid) nacl > (which previously build on a debian experimental armhf buildd but > not a debian unstable armhf buildd) will build if /sys is mounted > but will not build if it is not mounted. Can packages assume that > /sys will be mounted in the build environment or not? I'm quite suprised to see /sys to be mounted in chroots. Wasn't one of the reasons to start /sys and not put the info there in /proc to not have to have it available in chroots? Shouldn't that information 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
Re: packaging a tiny/trivial blob in a DFSG-clean way?
* Michael Tokarev [120914 23:12]: > But I'm still a bit, well, uncomfortable to ship the blobs, > even if the source is available and it is verified on buildds > during package build on corresponding architectures. > > Allowing such packaging may act as a bad example in the future. > > And yes, that'd be the BEST option, ever, from whole packaging > point of view, including debian archive management too. We currently do not ensure hard that other things can be built either. Things were able to build when they were uploaded and sometimes thankfully someone even checks if they still build (and judging from the many FTBFS bugs filed in the process, being buildable back then and being buildable now is really not the same). So I don't see why storing the result and comparing it to a newly built one (and failing if it does not match) on the corresponding 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.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120915080309.ga30...@client.brlink.eu
Re: Bug#684396: ITP: openrc -- alternative boot mechanism that manages the services, startup and shutdown of a host
* Ben Hutchings [120820 20:21]: > I don't think we should expect other developers to spend any large > amount of time to help with our own pet projects, except in so far as > they benefit 'our users and the free software community', which I take > to mean collective interests (i.e. numbers matter). Right now, most > package maintainers can provide more benefit to more users by working > on bugs that affect x86, than by spending that same time investigating > even the most serious problems on some other architecture. Of course > they should not stand in the way of porters and should be ready to > answer questions and apply reasonable patches. While I agree with the first part (people doing their pet stuff should not distract others), I see the roles afterwards differently, though: Most software working only on x86 is simply some pet project, with code so broken that any newer compiler version will likely break it[1]. And it is porters that waste their time fixing bugs in toy software, most of the time having to cope with code so broken it is a miracle it worked even on any compiler version on x86[2]. There is some minor number of port specific issues (though they are of course quite frustrating as one as maintainer of a package can do little in this case), but in my experience the numbers are similar as with alleged bugs of compiler misoptimising code: in over 95% of cases it is a bug in the program instead. More often than not 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 program can give very little information, almost all optimisations involve some step of "the rules forbid this behavior as it would not work on some obscure architecture, so I can assume that behavior is not the intended, so I can optimize for the other case". [2] Well, it's not really a miracle, but observation bias: Only that buggy code that 'luckily' did not cause breakage on previous compiler versions on x86 (or on sparc if you look at 15 years old code) has survived testing by the original authors, so you only meet those, unlikely as they are. -- 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/20120821093243.ga2...@client.brlink.eu
Re: Minified javascript files
* Vincent Bernat [120818 21:18]: > The difference is that we need to bug upstream about a file that we > won't even use. There is no real bug (not even a licensing issue). They are distributing files without source, so everyone else can either not just easily modify it or verify if it really does what it is supposed to do. This is definitely a shortcoming in what upstream ships and really something you should bug upstream about. > We request him to add a file that we won't use anyway. There is more than just "us". If it is for us, they could just remove the file. It's for the people that those files is supposed to be for. They should have the right to change it, for which they effectively need the source. > I don't know many upstream who have so much free time. If just adding a source file they hopefully have anyway or to remove a file does 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". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120819131132.ga9...@client.brlink.eu
Re: Minified javascript files
* Raphael Hertzog [120817 14:04]:
> That way, there's no need to strip unused RFC, minified javascript, Flash
> files,
> PDF without sources, etc.
Striping them away is only the forth best solution. There are some better
solutions like:
- make upstream include the sources
- include the sources yourself
- make upstream not include files without source
That might not always be easy, but it's not different from getting any
other fixes upstream.
> All this has been useless bureaucracy which has drawn people away.
If people are drawn away by someone caring for the 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
Re: Fixing the mime horror ini Debian
* Per Olofsson [120713 12:18]:
> 1. Rewrite xdg-utils so that it is robust and always works.
It you want to make xdg-open useable for everything, please also
add a way to specify the mime type as option. Without that using
it for opening mail attachements or stuff downloaded (i.e. things
that 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://lists.debian.org/20120713114519.ga2...@client.brlink.eu
Re: Bug#679078: ITP: acpi-support-minimal -- minimal acpi scripts
* Michael Meskes [120626 14:48]: [ Guillem Jover [120626 12:05]:] > > I'll be reopening 665987, but if that gets closed again I'd be very > > happy to switch to acpi-support-minimal from my now locally built > > acpi-support packages w/ the consolekit dependency removed. > [...] I'm absolutely willing > to listen to ideas of solving this, which imo would be a much better solution > than creating an additional package that will only partly work. [...] I'd prefer to get this fixed in acpi-support-base, but I think you have made your point very clear that the only purpose of that package is to not do anything if some power manager is running and that to detect this perfectly you are totally willing to force anyone to install consolekit (and thus dbus) who justs wants his system shutting down cleanly when the power button is pressed. That this is not issue for you at all and that you do not see any problem in introducing this change 2012-06-21 i.e. shortly before the freeze. > "If that gets closed again" sounds like I was closing the bug without > a reason, which I didn't. That sentence was much more neutral than 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 with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120627093253.ga3...@client.brlink.eu
Bug#679078: ITP: acpi-support-minimal -- minimal acpi scripts
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. It does not require any other daemons but acpid. For a less minimal version, install the "acpi-support-base" or "acpi-support" packages. -- 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/20120626085241.ga4...@client.brlink.eu
Re: Lintian warning: hardening-no-fortify-functions & version numbering
* Ben Hutchings [120625 19:21]: > GNU make's implicit rules use CPPFLAGS. If other build systems or > overriden rules don't use it, it's a bug. This can of course be > worked around in debian/rules. I'd not call it a bug. It's just some stranger behavior. Not 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". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120625184310.gd...@client.brlink.eu
Re: Lintian warning: hardening-no-fortify-functions & version numbering
* Russ Allbery [120624 23:13]:
> When integrating with a build system that uses only one variable for
> compilation flags, just pass the concatenation of CFLAGS and CPPFLAGS into
> it. This is trivially done in debian/rules without modifying the upstream
> source.
Build systems not doing CPPFLAGS often also are incorrect in other
aspects. Like using CFLAGS where CXXFLAGS are meant. Or having a
differently named LDFLAGS. Or not having LDFLAGS at all and needing them
in a variable called CFLAGS, too. Or only passing LDFLAGS at link time so
needed CFLAGS or CXXFLAGS concatenated 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 debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20120625083304.ga3...@client.brlink.eu
Re: Lintian warning: hardening-no-fortify-functions & version numbering
* Lars Wirzenius [120624 12:30]: > On Sat, Jun 23, 2012 at 03:27:07PM -0700, Russ Allbery wrote: > > CFLAGS is an old, long-standing make thing. CPPFLAGS is newer and I > > believe was introduced by Autoconf > > I don't know the history of CPPFLAGS. It's possible 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 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/20120624203026.ga8...@client.brlink.eu
which flags to pass to gcc/g++
* Serge [120624 00:15]:
> Or you mean that they should run `gcc`/`g++` with CPPFLAGS?
> If you do, then... How should they do that?
gcc $(CPPFLAGS) $(CFLAGS) -c -o foo.o foo.c
gcc $(CFLAGS) $(LDFLAGS) -o foo foo.o
gcc $(CPPFLAGS) $(CFLAGS) $(LDFLAGS) -o foo foo.c
g++ $(CPPFLAGS) $(CXXFLAGS) -c -o foo.o foo.cpp
g++ $(CXXFLAGS) $(LDFLAGS) -o foo foo.o
g++ $(CPPFLAGS) $(CXXFLAGS) $(LDFLAGS) -o foo foo.cpp
I.e: the rules are:
* whenever calling gcc pass CFLAGS,
* whenever calling g++ pass CXXFLAGS.
* Whenever it links (i.e. without -c, -E or -S) pass LDFLAGS.
* Whenever it will preprocess 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 subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20120624091919.ga2...@client.brlink.eu
Re: Maintainers, teams, Uploaders, DMs, DDs, etc.
* Ian Jackson [120613 17:35]: > 5. Introduce a new conventional location for information useful to >NMUers, > debian/README.nmu > >Explicitly state that someone preparing or sponsoring an NMU should >consult this file. Statements in this file may supplement, but do >not overrule, the NMU criteria established by the Developers' >Reference, by the release team, or elsewhere. > >Explicitly state that NMUers are NOT necessarily required to >consult README.maintain. Adding something for NMUs in the package without adding some way to give more information for NMUs outside the package might result in information getting in there that will usually be outdated when an NMU is needed. (after all, NMUs are especially common when noone else did an upload for a longer time, so a upload just to get that file within the package 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
Re: Starting services automatically after install
* Toni Mueller [120603 11:41]: > Since we obviously can't agree on *how* the service is to be run, one > could just ask the user, eg., in the case of a printing service: > > "I just installed the file sharing service. Do you want to start > sharing immediately (will allow other people to access > files/media/printers)?" The print servers I looked at did not allow remote access by default since somewhen in the 90ties. > But for a more real-world example, consider slapd, which also starts > immediately, but is imho quite unlikely to be configured appropriately > by Joe Average User who doesn't understand that he needs to start Samba > before being able to share his files, and which is impossible to > configure appropriately by answering debconf questions in the first > place? What has slapd to do with samba and why don't you want it run? actually I'd be quite confused if slapd had not been already running after installing... > > If a service comes with a default config that can be a real security > > concern, then that alone needs fixing. > > Many services come, eg. Apache comes with it, too (and eg. grabs all > sockets it can, one of my pet peeves). Sorry, you have to explain this. Do you claim apache has a security concern in its default config? > > As administrator I also prefer that I just have to copy a config and > > install the package. Anything not 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. > > You have to say something like '/etc/init.d/service restart', anyway, > after you put your own config into place. What's so much different from > saying '/etc/init.d/service start' instead, in such a case? That I do not have to do it? Either I have copied the config first or for a full install that will get a reboot anyway when deployed. > Asking the unwitting user and providing a 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
Re: Starting services automatically after install
* Aaron Toponce [120602 16:26]: > However, I am calling into question the validity of starting a service by > default post-install. I think it introduces security concerns, possible > headaces on the local LAN, and just unnessary work for the administrator. > Other than "if you don't want a service, don't install the package" > agrument, I don't understand why services _should_ be started by default > post-install. Try to see it from the other side: I don't understand why you would a like a service not started by default. The daemon is there to be run, so running it is the most sensible approach in almost all cases[1]. If a service comes with a default config that can be a real security concern, then that alone needs fixing. As administrator I also prefer that I just have to copy a config and install the package. Anything not 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 first needs a subnet configured. But if I place a dhcpd.conf at the right location it starts as it should... -- 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/20120603062134.ga2...@client.brlink.eu
Re: Moving /tmp to tmpfs is fine
* Ben Hutchings [120527 17:25]:
> Creating arbitrarily large temporary files outside the user's home
> directory is generally going to be unreliable.
The only thing more unreliable than that is creating arbitrary large
file in user's home directory. If it is not supposed to be persistent
data that is available on every node the user can log in, then it does
not belong into the home directory (unless the user explicitly choose
to set TMPDIR there). The home directory can be quite slow (because
being remote, being encrypted, ...) and quite scarce (permanent storage
on server discs with redudancy and backup strategies is not that cheap).
Unless a program is explicitly told otherwise, temporary files belong
to TMPDIR and if that is not set to /tmp. (or any subdirectory thereof
the programs like to create). If that is too small, then it is too
small. The admin is able to 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 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/20120528084732.ga4...@client.brlink.eu
Re: Bug#481129: Bug#671503: general: APT repository format is not documented
* Paul Wise [120519 01:39]: > I would like to see the flat-style repository documented too, since > some of the derivatives in the Debian derivatives census use it and I > would like to lint their apt repositories. I my humble opinion the best documentation for the "flat-style" 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
Re: why do people introduce stup^Wstrange changes to quilt 3.0 format
* Adam Borowski [120518 11:37]: > You complain about forcing people to use git, while you push quilt onto > everyone else. > [...] > > I really wish there was a "3.0" format besides "3.0 (quilt)", so people are > not mislead into thinking they have to (or even, would gain anything) from > writing patches in quilt's format. Noone is forcing quilt on anyone. We need a source format that can properly represent changes to the upstream source code and that is best done as some series of patches. Using a format that is a subset of quilt without all the magic makes sense as that makes it easy for anyone to write or read. (It's just a set of patches to be applied with -p1 and a file to list the names of those patches line by line, i.e. no special sort algorithm for filesnames needs to be defined). One of the biggest faults of "3.0 (quilt)" is its name. It should really have been called "3.0 (patches)" or even better "3.0 (non-native)". A proper package should either have no upstream changes or broken down changeset that can actually be applied. If you have those changes it is trivial to create a "3.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 subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120518145644.gb2...@client.brlink.eu
Re: problems with quilt and 3.0 (quilt) format again
* Norbert Preining [120515 01:10]:
> For these kind of things the expected behaviour is that quilt and
> dpkg-source behave the same way, and if not, dpkg-source should
> warn or whatever.
I think the patched debian source format should not depend on what
quilt does but be sensible within 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 "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20120515085132.gb2...@client.brlink.eu
Re: Making -devel discussions more viable
* Russ Allbery [120502 18:06]: > I don't want technical decisions in this project to > only be discussed by people who enjoy the noise. That's why it is cruical to get the noise reduced. If in any discussion there is a DD escalating the flames then there won't be any people with technical arguments left. Getting some non-contributers out of the picture will not change it much. I wholeheartly believe that the only reason you see those people so prominently is that everything else already is in ignore mode because of contributors heating the flames. > So, while "don't add to the noise" is *part* of the solution, if one just > says that and puts a period at the end, it makes the problem worse. It > needs to be part of a solution that actually *reduces the noise*. Not adding to the noise is reducing the noise. And especially telling people 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, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120502164118.gb2...@client.brlink.eu
Re: Making -devel discussions more viable
* 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 > >> is thus: Please refrain from any more posts to this discussion. > > > I have nothing against this principle, and I do this. But I also stop > > reading such threads. And this means I read less and less of this list. > > Right. As good as that idea sounds on the surface, what that actually > translates into in practice is making debian-devel useless. And how does enhancing the noise rate by adding mails not about technical arguments make the mailing lists useful? 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/20120502123933.ga18...@server.brlink.eu
Re: Node.js and it's future in debian
* Russ Allbery [120501 19:28]: > I have to admit that I'm tempted to change Policy from "if there's no > consensus, rename both of them" to "if there's no consensus, try harder to > reach a consensus, and the technical committee decides in last resort." > > Most of the time, renaming both of them isn't the right answer. On the other hand, if renaming both of them is the only possible outcome if both parties cannot agree, it makes it more likely both sides will actually be willing to discuss the matter, instead of just issuing demands, 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
Re: Making -devel discussions more viable
* Russ Allbery [120430 19:11]: > I want our technical discussions to be welcoming to anyone who has > information to share and who can bring additional clarity and insight to > the discussion. But once things start getting heated or people start > throwing around accusations or verge towards personal attacks, there's a > real psychological difference between people who are contributing to > Debian and people who aren't. I'd rather argue that abusive behaviour from contributors is far worse than from non-contributors. It's easier to ignore people not involved and people not doing anything are usually not around for long. There is also nothing keeping anyone with technical arguments out of a discussion as someone insulting anyone with different opinions and if running out of insults accusing people as not being contributors. 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 is thus: Please refrain from any more posts to this discussion. I do not care if you rationalize it as "no need to feed the troll" or if you understand you left the level 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 "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120501103126.ga2...@client.brlink.eu
Re: Enabling hardened build flags for Wheezy
* Charles Plessy [120430 16:26]: > If people who are interested by improving our dozens of thousands upstream > makefiles could spend time forwarding patches upstream by themselves, that > would be appreciated. I have a hard time finding convincing words when I > think > the patch is borderline useless. What are you talking about? Sorry, but I really cannot make any sense out of that. Let me try to explain the situation, so you can tell me where you disagree: We want some options enabled in as many package builds as possible. Options that have not been the decade long defaults in compilers, so they break a significant amount of software. Changing the compiler defaults would have the side effect of also affecting users and forcing all packages to cope with the changed defaults at once. (And the packages having the hardest to fix issues are usually the packages with the most absurd build systems, so having to fix all of them to include compiler options disabling the hardening flags is not that easy). So instead of an opt-out by changing what the compiler does by default and forcing the package maintainer to override them, we have a opt-in system: the maintainer can give the options to the build system. For that there is the new dpkg-buildflags command, that outputs all categories of flags a package maintainer would want to have: It give you preprocessor flags, it gives you C compiler flags, it gives you C++ compiler flags, it gives you fortran compiler flags and it gives you linker flags. By default it gives some default hardning flags but also supports the maintainer requesting more intrusive flags or disabling some classes of flags (see the discussion of DEB_BUILD_MAINT_OPTIONS in dpkg-buildflags manpage). It's also done in a way that support for 'noopt' it automatic, so it even makes it even less work for the maintainer. To ease it for package maintainers, the flags dpkg-buildflags generates have the names the GNU coding standards request all package build systems should support. As those are quite influental, many build systems name them this way. And as they are split into the flags the different tools want to have, every other scheme can be computed out of those easily by just appending those set of flags you need. If you have a build-system that does not support passing flags to the compiler, then you won't get support for hardning with this opt-in way, of course. But such a package would also have no way to override a specific set of hardening flags, so it would have problems with the opt-out way to, because it cannot opt-out. As not everyone build systems has the same names for variables holding the compiler (meaning preprocessor/actual compiler/linker) flags. There is not even theoretically (compare "halting problem") a way to determine what the variables are named like and what content they expect. This simply needs a human to look at it and say which flags need to be put where so that the upstream build system will pick them up. If a build system does not support passing flags to the compiler, and you want it to have hardening flags, that might need some makefile patches. But if there is no time for this or this is too complicated, then one can just do without, generating a package without hardening (and most likely also without support for noopt and the like, so do not suppose other people will be extremly willing to help you fix the bugs in it), but so be it. The release goal is "This goal is to update as many packages as possible to use security hardening 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 hardening flags or it must be removed from Debian". 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/20120501095606.ga2...@client.brlink.eu
Re: Enabling hardened build flags for Wheezy
* Charles Plessy [120430 04:31]: > Sorry to rant again, but am I the only one thinking that we are in most of the > case wasting everybody's time by not simply passing all the hardening flags by > default in CFLAGS ? In my experience (and I maintain more than 100 packages), > it is extremely rare to need to ensure that the compiler, preprocessor and > linker flags are in three separate variables. > > When we need to modify a large number of packages in order to propagate a > change, isn't this meaning that we are not picking the most efficient > defaults ? As I wrote again, keeping them seperate means you can support both cases: systems following GNU coding standards to keep them seperate and systems wanting them in one place. If you mix them first you cannot seperate them later. There is also no way this can work without any maintainer intervention. You need to look what the flags are called. It is quite common for hand-written flags to use CFLAGS where CXXFLAGS is meant for example. So you as maintainer have to decide what mapping to use anyway. If you need CFLAGS='$(CFLAGS)' CPPFLAGS='$(CPPFLAGS)' or CFLAGS='$(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 always working. 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/20120430084657.ga2...@client.brlink.eu
Re: Bug#668556: ITP: dparser -- a scannerless GLR parser generator
* 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 extending the acronyms, I propose to change the > long description as follows: > > DParser is a scannerless, generalized left-to-right, rightmost > deviation (GLR) parser generator based on the Tomita algorithm. It is > self-hosted and very easy to use. Grammars are written in a natural > style of extended Backus-Naur form (EBNF) and regular expressions and > support both speculative and final actions. > > I'm not a native speaker, so please feel free to comment on spelling, > grammar, comma or other errors. I'm not sure that is that much more understandable for people not knowing the concepts or for people trying to understand what this package does and why some other admin installed it (or why a user requests its installation). Let's take a look at start of bison's description: Bison is a general-purpose parser generator that converts a grammar description for an LALR(1) context-free grammar into a C program to parse that grammar. That sentence also describes what a parser generator is (so even someone not so deep into computer science knows what this package is about), while still containing the details and not being much longer. I personally cannot take much more out of "generalized left-to-right, rightmost deviation (GLR) parser generator" than out of "GLR parser", I'd need to look it up anyway, so "GLR parser generator" is quite well in my eyes. For the grammer I personally would prefer it expanded, though I think it is more understandable as "EBNF (extended Backus-Naur form) Grammer" than the other way around. Other questions I ask myself when looking at the description: What is "based on the Tomita algorithm" about? Wikipedia tells me GLR parser generators are based on work of Tomita, so is that a description of "GLR parser" or is it a somehow important implementation detail that this is based on the original and not some reinvention or totally different algorithm one would also call GLR parser? Would that information be important for anyone to decide if they want to install that package or not? What is "a natural style of EBNF" supposed to mean? Are there any unnatural styles of EBNF? Does it mean I can write something I would be able to identify as EBNF in contrast to other parser generators? As EBNF is already about forms of expression grammars, what is meant here that not having that could still be called EBNF? That might be only my ignorance, so my question: "Does this 'natural style of' give anyone a information they would want when determining if installing or uninstalling this package?" What is "scannerless"? After considering that "does not contain a scanner" does not make much sense I guess it means I do not need something like flex run first to translate the input into tokens? Perhaps that can also expressed more generally understandable. If all my guesses above are right, that would result in something like: DParser is a scannerless GLR parser generator that converts a grammar given in EBNF (extended Backus-Naur form) and regular expressions into to parse that grammer without needing an extra scanner to tokenize the input. (With perhaps "GLR" being replaced with "GLR (generalized left-to-right, rightmost deviation)" and perhaps "to tokenize the input" removed). -- 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/20120414133220.gb2...@client.brlink.eu
Re: On init in Debian
* Marco d'Itri [120321 09:34]: > On Mar 21, Svante Signell wrote: > > And how do you expect non-experts be able to solve problems when they > > pop up. Buying consultant services from the experts? > Non-experts are not able to solve any problem, so this is not an issue. I'm really fed up with this elitism. There are not only experts and people knowing nothing. The is a wide range between. By building things that either work or are impossible to fix you might be able to finaly produce a situation like that, with dependent users not being able to do anything and only people taking some explicit courses able to fix things. But that is neither was the situation currently is in the Linux world not what it should become. Actually I think enabling people to gradually understand the system they use and being able to fix the problems they run into is a even more 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 'experts'? 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/20120321090152.ga2...@client.brlink.eu
Re: Enabling hardened build flags for Wheezy
* Charles Plessy [120307 16:27]: > Thanks (and thanks Cyril) for the hint. Still there are two things > I do not understand: > > - Why and when it is a problem to add preprocessor flags in CFLAGS. Becuase CFLAGS is not meant for preprocessor flags. Adding stuff in unexpected places might break correct stuff. There are usually 4 variables for C/C++ code: CPPFLAGS is for options for the preprocessor like -D and -I CFLAGS is flags for the C compiler CXXFLAGS is flags for the C++ compiler LDFLAGS if flags for the linker. The rules are: - if you call the preprocessor, or a compiler in a way to call the preprocessor, you give it CPPFLAGS. - if you call the linker (ideally by calling the compiler in a way to invoke the linker (i.e. without -c)) you give it LDFLAGS. - if you call the compiler, you give it CFLAGS (for gcc) or CXXFLAGS (for g++). That is you usually have something like (with usually more variables, as most software needs some hardcoded values that should not go in the user variables): g++ $(CPPFLAGS) $(CXXFLAGS) $(LDFLAGS) bar.cc -o progname gcc $(CPPFLAGS) $(CFLAGS) $(LDFLAGS) bar.c -o progname g++ $(CPPFLAGS) $(CXXFLAGS) -c foo.cc -o foo.o gcc $(CPPFLAGS) $(CFLAGS) -c foo.c -o foo.o g++ $(CXXFLAGS) $(LDFLAGS) foo.o -o progname gcc $(CFLAGS) $(LDFLAGS) foo.o -o progname The reason you should give CFLAGS/CXXFLAGS when giving the compiler a .o file is that linking might also produce code (when using lto, or when generating shared libraries, or ...) which needs to get the same options. Thus depending on upstream's build scripts, you might need to put multiple flags in different variables (sometimes putting CPPFLAGS and CFLAGS in a variable called CFLAGS, sometimes CFLAGS and LDFLAGS in a variable called LDFLAGS and so on). > - Why we chose the solution that require more extensive changes >to the packages. By having each categorie in its own variable and having those variables named as the influental GNU coding standards requiring them to be, we get the possibility to support any system and doing the right thing automatically for the majority. (Merging values is easy, splitting is not). It requires no change for good packages. For packages not following the usual semantics you will have to find out which flags to put where anyway, so it does not get more complicated, either. Also note that if upstream's build system does not support CPPFLAGS, chances are it does not support LDFLAGS either. So you might want to look at this and perhaps mangle it into something either). Another often seen mistake in hand-written Makefiles is using CFLAGS 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 listmas...@lists.debian.org Archive: http://lists.debian.org/20120307190137.ga17...@server.brlink.eu
Re: Quilt patch for patching things in the debian folder
* Neil Williams [120307 10:35]:
> Not within Debian uploads and buildd's, true, but there are good reasons
> for this to remain technically possible for derivatives. The ability for
> someone downstream of Debian to patch debian/control[.in] and [...]
On the other hand that is also a very good reason to forbid that.
Whether it might make sense for derivatives to mangle upstream with
packaging changes in other files might be a matter of opinion
(I'm personally quite happy that is no longer possible), but
debian/control should really be something you should be able to extract
in a sane way. I consider it one of the major flaws of 1.0 packages that
you cannot sanely extract debian/control out of it (you can do some
heuristics that can extract most of the packages like changestool
(from package repepro) does, but no always working way), while 3.0
(quilt) there 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
Archive: http://lists.debian.org/20120307111527.gb14...@server.brlink.eu
the advantages of supporting many architectures.
* 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 program you just do not > > *yet* see on your usual pet architectures. And some more because the > > program is just doing some very narrowing assumptions. > > Yes, such bugs do exist. However, I think the benefit of testing on > other architectures to uncover such bugs has been exaggerated. I think the benefit was that we have a amd64 port almost instantly. I guess without it there would have been years before most people would have dared to use 64 bit userspace. (Considering how long people used 32 bit userspace to still have flash and stuff running easily, imagine what would have happend if major parts of the free software stack would still have had that problems). > Many of > the problems that end up taking the most time are toolchain issues > specific to the architecture. While those are the most annoying ones, in my experience they are the absolute minority. > Typical free software projects already > have multiple known issues that actually affect people even on popular > architectures; ability to find one more thing that's in principle broken > is not particularly valuable. Depends on what free software projects you use. Usually the hard part about getting them bug-free is finding the bugs, not fixing them. Every bug hitting the maintainer directly and now usually does not even exist in the release. > > Imagine how long amd64 would have taken, if people had not had years > > to fix all those 64 bit bugs on alpha first (Which never really got > > a mainstream architecture and where it was used was quite server-only. > > Who would have guessed that fixing games to run there would have had > > benefits in a so soon future?) > > I'm not sure exactly how long more AMD64 support would have taken > without Alpha, but I think it would have become supported reasonably > fast in any case, and likely with substantially less overall effort than > by fixing issues as they come up through Debian Alpha builds. "First > upstream developer of a game gets an AMD64 machine and makes the game > run on it" is just inherently a lot more efficient than "Debian > maintainer forwards reports about game not working on Alpha". Without the whole software stack mostly ready to be used with 64 bit, how many upstreams would run their 64 bit machines with a 64 bit userspace? And how often do upstreams buy new computers? And most of the time it is "Debian maintainer forwards patch to upstream", whether that patch is from a user, a maintainer or a porter. > If you want to help the development of upstream projects in general, > there's an obvious thing that could use more resources: make sure that > the latest upstream code is always available in Debian unstable (or if > it's likely to cause breakage, at least in experimental), and don't let > the introduction of new upstream versions in unstable stop around > releases. Having satisfied users also helps upstream. Thus preparing a tested release users can actually use helps upstream more than just someone looking at their latest versions. > Getting more feedback about changes quickly is a lot more > important than testing on unusual architectures. Those are different eyes. The big advantage of different architectures is the variety. Bugs in the code causing the compilers only generating working programs by chance for example is something that is better caught on some "unusual" architecture first. There only a few users are effected. If the bug is only caught once there is a newer compiler, then it effects far more people. (And if there was no distribution out there fixing those bugs in upstream software then more upstream projects would fail with newer compilers, making it impossible in the long run to switch to newer compiler versions). 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/20120228171152.gb3...@server.brlink.eu
Re: A few observations about systemd
* 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 architectures, It's the task of a maintainer to fix their packages. It's the task of the porters to help the maintainers with this. 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 program you just do not *yet* see on your usual pet architectures. And some more because the program is just doing some very narrowing assumptions. Imagine how long amd64 would have taken, if people had not had years to fix all those 64 bit bugs on alpha first (Which never really got a mainstream architecture and where it was used was quite server-only. Who would have guessed that fixing games to run there would have had benefits in a so soon future?) -- 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/20120227162242.ga2...@client.brlink.eu
Re: upstart: please update to latest upstream version
* Russ Allbery [120224 19:28]: > Staring at the bug and the makefile and thinking hard is usually sufficient. It's usually sufficient (because the concept is quite easy), but once that does not work there is hardly any other chance, except wild experimenting (which I hardly would like to do with by boot system). I've yet to see a case where -d actually helps. > One of the primary features of newer init systems like upstart and systemd > is that they take care of the routine stuff automatically and thereby > reduce the conceptual surface of your init script equivalent. Simpler > things are inherently easier to debug; there are fewer variables. It's just a much more complicated setup. Daemons like to all have their special little quirks. And starting or shutting down a system tends to belong to the most ugly things to debug. Also note that quite some functionality will be some C code especially the early and very late code, I guess, where debugability is the hardest. > Yes, > the underlying infrastructure has to not be buggy, just like make has to > not be buggy, but now you're talking about debugging systemd or make, not > your 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 subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120224214914.ga5...@client.brlink.eu
Re: upstart: please update to latest upstream version
* Tollef Fog Heen [120224 13:05]: > > And that is exactly why I think you will likely need to be C programmer > > and understand the internals of systemd to debug your boot process and > > to fix it in case you have problems. > > How do you come to that conclusion? It's not like you need to be a C > programmer to debug CSS files or a C programmer to debug Makefiles. As big a fan of Makefile that I am, but they are essentially undebugable. > (Often you can get away with just doing systemctl restart foo.service; > strace -p $(pidof process), but 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...@lists.debian.org Archive: http://lists.debian.org/20120224120746.ga20...@server.brlink.eu
Re: upstart: please update to latest upstream version
* 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 every other day. Why do you assume that you > > > need to do so just because policy is encoded in .ini-like files instead > > > of shell scripts? > > > > Because shell is general purpose (and well known) enough that you can > > modify it sensibly. [...] > > I think you're approaching the problem from a somewhat weird direction. > > systemd unit files are declarative. And that is exactly why I think you will likely need to be C programmer and understand the internals of systemd to debug your boot process and to fix it in case you have problems. Or if you want to do anything not explicitly supported (for example, how easy is it with systemd to run a daemon within strace?) you might need to replace the declarative part with a shell script part, which most people will not be able to do easily. 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/20120224110300.ga25...@client.brlink.eu
Re: upstart: please update to latest upstream version
* 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 instead > of shell scripts? Because shell is general purpose (and well known) enough that you can modify it sensibly. In the long run systemd init support might grow its own language to be just another shell, but I guess until then of the typical quick-hack constructs like addings some echos, adding some cleaning code before, conditionally starting stuff, or multiple times until some condition is reached, with some filedescriptors redirected, with a strace or ltrace and things like that will not all possible in a way one can easily do. > > I've no problem with Debian supporting multiple init systems. But if > > someone claims maintaince costs are too high for that, that is in my > > eyes a reason against supporting systemd, not for only having it. > > Systemd is already in Debian, works for quite some people does not > impose any maintenance burden on people who don't use it. I really > don't see why you keep advocating removing it. Let me try to rephrase it, as I seem to have failed to formulate it understandable the first two times: What I try to say is "If there can only be one, then this should not be systemd. So if Debian shall have systemd, it should support multiple init systems." 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/20120224074733.ga2...@client.brlink.eu
Re: upstart: please update to latest upstream version
* Josselin Mouette [120223 18:36]:
> Seriously, this constant obstruction to improving the Debian system by a
> minority of whiners who don’t contribute much to relevant parts of the
> system but have an opinion on everything is getting intolerable.
As long as you react to everything 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". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20120223174211.ga10...@client.brlink.eu
