Re: Jessie Release Date: 2015-04-25
On 2015-03-31 21:58, Niels Thykier wrote: * unfixed RC bugs in key packages, please see [1]. [1] https://udd.debian.org/bugs/?release=jessie_and_sid&merged=ign&keypackages=only&fnewerval=7&flastmodval=7&rc=1&ctags=1&cdeferred=1&sortby=id&sorto=asc&format=html#results At the time of posting, there was a bug for unrar in this list. I think this one -- https://bugs.debian.org/774171 , it was fixed the next day. Do I understand it right: a bug in a non-free package could be release-critical for Debian? I thought non-free area is not part of the Debian system... -- Alexander Cherepanov -- 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/5521a4d2.9040...@mccme.ru
Re: Jessie Release Date: 2015-04-25
[Forgot to send it to the list.] On 06.04.2015 00:21, Russ Allbery wrote: Alexander Cherepanov writes: At the time of posting, there was a bug for unrar in this list. I think this one -- https://bugs.debian.org/774171 , it was fixed the next day. Do I understand it right: a bug in a non-free package could be release-critical for Debian? I thought non-free area is not part of the Debian system... It's RC for the package, but not for Debian. In other words, if the bug isn't fixed, the package would be pulled from the release, but it's pretty unlikely that it would hold up the release itself. Shouldn't it then be excluded from the list of _key_ packages? -- Alexander Cherepanov -- 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/552239d8.3070...@mccme.ru
Re: The Spirit of Free Software, or The Reality
[Resending to the list, sorry.] On 2015-07-17 16:03, Thorsten Glaser wrote: Ian Jackson chiark.greenend.org.uk> writes: The problem is simply that the icons are non-DFSG-free. You could make a screenshot from where the original icons are shown, then re-encode those tiny 16x16px thingies into new *.ico files with GIMP. This is sorta like taking a photograph (if in doubt, take an actual photo), I guess taking a photograph doesn't change a copyright status of a thing in most jurisdictions (or make things even more complex if there is creativity in the photo itself etc.) or a bitmap font (where neither the font nor the indi‐ vidual glyphs fall under copyright law), Fonts are special in that their creative form serves a functional role at the same time. Hence they are frequently protected by patents or some such. In practice, the copyright situation in US for bitmap fonts is mostly clear but for non-bitmap fonts it is kinda surreal. so only trademark law matters, and Don already said Debian can “probably” use them to refer to the sites in question. -- Alexander Cherepanov -- 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/55abf2f0.7010...@openwall.com
Re: Packaging of static libraries
h are nowadays forbidden. So the C committee has failed at its task. [1] The task of the committee was to balance several principles. Why many (especially in Free Software world) consider being a high-level assembler a much more important principle than other ones is not clear to me. The second is to ask what is most useful. And there again the C committee have clearly failed. Apparently others disagree. We in Debian are in a good position to defend our users from the fallout from this problem. We could change our default compiler options to favour safety, and provide more traditional semantics. Debian (and other distros) have somewhat unusual stakes in the UB debate due to the porting needs. A lone developer can choose to support only one platform and is free then to complain that C doesn't provide full freedom of assembler for this platform. But Debian often takes such programs and build them for many other architectures. As an example consider shifts by a value greater than or equal to the width of the left operand. They are UB in C and work differently on different CPUs. Will it benefit Debian to declare them implementation-defined in C? Probably not. Another example is unaligned accesses. It looks like Debian (and Free Software community in general) should strongly favor portability of the standard C over the ability to serve as a high-level assembler. We would have influence upstream (for example to further advance the set of available safety options) if we cared to use it. But sadly it seems that the notion that our most basic and widely-used programming language should be one that's fit for programming in is not yet fully accepted. At the very least we should fiercely resist any further broadening of the scope of the C UB problem. Then the first thing to do is to stop upgrading gcc. Doesn't seem like a very practical approach. Next thing is to add options like -fwrapv or -fno-strict-overflow, -fno-delete-null-pointer-checks, -fno-strict-aliasing but is there a chance for consensus about it? Doubtful, but who knows... Perhaps less controversial is fixing UB (and other bugs) in the existing code. Several years ago this was hopeless but recently some tools emerged that allow to tackle the problem. First of all, sanitizers -- ASan, UBSan, MSan, TSan, ... While running everything in valgrind is not very convenient, building everything with ASAN seems quite feasible. Recent activity related to Debian: http://balintreczey.hu/blog/progress-report-on-hardened1-linux-amd64-a-potential-debian-port-with-pie-asan-ubsan-and-more/ https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=812782 https://github.com/Mohit7/Debian-ASan The last project contains a list of several hundreds packages that fail to build or run with ASan. Unlike UBSan problems which may or may not lead to a bug in an executable now or in future, ASan problems are quite real right now. After the problems found with ASan and UBSan are dealt with, other tools could be used to find further problems: - STACK (mentioned above); - tis-interpreter -- https://github.com/TrustInSoft/tis-interpreter -- a recently released "interpreter for finding subtle bugs in programs written in standard C"; - libcrunch -- https://github.com/stephenrkell/libcrunch -- a tool "for fast dynamic type checking". The tools are there, is there will to fix things?.. Perhaps some mixed approach is possible. E.g., disable some optimizations by default and reeenable them when tests with ASan etc. pass. Or vice versa -- disable some optimization when tests fail to pass with ASan enabled. -- Alexander Cherepanov
Re: Packaging of static libraries
On 2016-04-13 17:19, Vincent Lefevre wrote:
On 2016-04-13 12:40:39 +0100, Ian Jackson wrote:
Vincent Lefevre writes ("Re: Packaging of static libraries"):
Note that by default, shared libraries would still be used, so that
this would affect only users with specific applications, who would
want to optimize as much as possible.
This assumption, that someone using static libraries wants to
"optimizse as much as possible" (ie, that they would prefer a fast
non-working program to a slow working one) is completely unfounded.
For libraries with a good testsuite (good coverage...) and checked
with an UB sanitizer, the program would be working. At least the
remaining bugs should not be related to UB.
Unfortunately UBSan is quite limited, e.g., it doesn't check for
violations of strict aliasing rules. And boundary checks are very
limited. In particular UBSan doesn't replace ASan at all.
--
Alexander Cherepanov
