Re: goals for hardening Debian: ideas and help wanted

Hi Paul, On Sun, Jun 08, 2014 at 10:13:27AM +0800, Paul Wise wrote: > We kind-of already support that; Debian Live is essentially that. What > would official support for read-only root look like to you? Option in > the installer? Probably fix the last bits of details that makes a read-only insta

Re: goals for hardening Debian: ideas and help wanted

On Thu, Apr 24, 2014 at 10:57:39AM +0800, Paul Wise wrote: > I have written a non-exhaustive list of goals for hardening the Debian > distribution, the Debian project and computer systems of the Debian > project, contributors and users. > If you have more ideas, please add them to the wiki page. W

Re: Why not 03 ?

On Mon, Jun 02, 2014 at 10:36:01AM -0300, Henrique de Moraes Holschuh wrote: > As long as you have a way to regression-test. And I don't mean performance > regressions, either. Although issues with -O3 are rare, they're not unheard > of. Looking at the `man gcc' page, I fail to see, outside comp

Re: Why not 03 ?

On Fri, May 30, 2014 at 11:10:29AM +1000, Russell Stuart wrote: > In particular -O3 turns on auto-vectorisation. It can provide a big > speed up to programs that can take advantage of it [...] > As others have pointed our -O3 turns on optimisations that help on some > architectures and hinder on o

Why not 03 ?

Hi folks, I have a rather silly question: most (all ?) packages are built by default with -02 - something which is inherited from autotool's '-g -O2' default flagsd, I presume. Is -O3 considered too dangerous ? (AFAICS, potential issues are mainly present in O2) Or is it considered worthless b

Debian business card with qr-code

Hi folks!, In addition to the various business card samples at https://www.debian.org/events/materials/business-cards/, I slightly modified the "traditional-new" version to have a two-sided version, with an optional QR-code. http://debian.httrack.com/card-traditional-new-2/ (Not sure if this is r

Re: Building/testing on s390x

Le 13/04/2014 17:39, Peter Palfrader a écrit : > Building shouldn't rely on the network in the first place. Humm, this is a very good point, and it did give me some headache. The problem is: how do you *really* test basic functions of a website copier /without/ network ? Solution 1: do not run u

Re: Building/testing on s390x

Le 13/04/2014 17:04, Xavier Roche a écrit : > Le 13/04/2014 16:56, Philipp Kern a écrit : >> zelenka should just work with the instructions on >> https://dsa.debian.org/doc/schroot/ — just use chroot:sid_s390x-dchroot > > Thanks - I should have read more carefully! By the

Re: Building/testing on s390x

Le 13/04/2014 16:56, Philipp Kern a écrit : > zelenka should just work with the instructions on > https://dsa.debian.org/doc/schroot/ — just use chroot:sid_s390x-dchroot Thanks - I should have read more carefully! -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject

Building/testing on s390x

Hi folks!, So I'm having an issue on s390x (https://buildd.debian.org/status/package.php?p=httrack&suite=sid) and I just wanted to quickly check why the package wasn't building. As far as I can see, neither zandonai nor zani can be accessed by DD, and zelenka does not have any way to build (yet ?

tests/test-suite.log build failures

Hi folks! I had a build failure (*) on my package due to a failing unit test, and the only information I got (with the failng unit test) was: # TOTAL: 12 # PASS: 11 # SKIP: 0 # XFAIL: 0 # FAIL: 1 # XPASS: 0 # ERROR: 0

Re: Bits from keyring-maint: Pushing keyring updates. Let us bury your old 1024D key!

Le 05/03/2014 15:05, Jeremy T. Bouse a écrit : > I would tend to side more with Odyx here in that the keys are still > considered trustworthy enough to be in the keyring but we're encouraging > moving to stronger keys and no longer accepting these keys to be > included. Yes, this was my thoughts,

Re: Bits from keyring-maint: Pushing keyring updates. Let us bury your old 1024D key!

Le 03/03/2014 19:13, Gunnar Wolf a écrit : > If you have a key with not-so-many active DD signatures (with > not-so-many ≥ 2) waiting to get it more signed, stop waiting and > request the key replacement². I have a rather silly question: would a mail (signed with this key) request to the DDs who a

Re: Test suite best practices ?

Le 03/06/2013 10:58, Neil Williams a écrit : > One thing which hasn't been mentioned so far, always ensure that your > test suite only runs if DEB_BUILD_OPTIONS="nocheck" is *not* set. > ifeq (,$(filter nocheck,$(DEB_BUILD_OPTIONS))) > # Code to run the package test suite. > endif Note that

Re: Test suite best practices ?

Le 02/06/2013 21:30, Russ Allbery a écrit : > the test programs should be handled by libtool > (replaced with shell scripts that set LD_LIBRARY_PATH and invoke the right > binary) so that they can run successfully from the build tree. In other > words, as long as the test suite is built with libtoo

Test suite best practices ?

Hi folks, Are there any "best practices" on how to handle test suite in Debian ? Currently the best way seems to use the automake's testsuite, and call dh_auto_test after dh_auto_build - but it generally needs some hacking wrt. library and binary pathes - ie. something ugly like: # Makefile.am T

Re: 2013 sometimes still feels like 2003 or 1993 (Re: NEW processing during freezes

Le 04/05/2013 15:37, Xavier Roche a écrit : > something that you can not detect unless you setup a complete chrooted > build environment, which is a bit cumbersome to do) Replying to myself - I should have pointed out that pbuilder was actually a really straightforward way to do that

Re: 2013 sometimes still feels like 2003 or 1993 (Re: NEW processing during freezes

Le 02/05/2013 20:12, Russ Allbery a écrit : > Yes, speaking as someone who has, on several occasions, uploaded arch: all > binary packages with source package problems and not discovered that until > months later via a FTBFS bug from an archive rebuild, I think we should > rebuild all arch: all pac

Re: desktop-command-not-in-package: link to an arch-dependent package in a arch-independent package

Julien Cristau a écrit : No. You don't need any conflicts, you need Replaces: B (<< new) in the new A and upgrades will work just fine. Yes, works fine, thanks! One more lintian warning removed :) -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscrib

Re: desktop-command-not-in-package: link to an arch-dependent package in a arch-independent package

Hi Ralf , Ralf Treinen a écrit : For me solution 1 is also justified when putting the .desktop file into the arch-dependent package. Since the arch-dependent package depends on the common package lintian shouldn't complain Well, at first glance I wanted to make the two packages cross-dependend

desktop-command-not-in-package: link to an arch-dependent package in a arch-independent package

Hi folks, How to deal with a desktop-command-not-in-package lintian warning when a .desktop file in a "common" package B references a binary in package A ? Typically the package A used to contain static/arch-independent data which was splitted to a B "common" package to comply with debian pa

Re: Debian vs. Ubuntu source control file

Russ Allbery wrote : I'm pretty sure Lintian doesn't care. Yep, but not debcheck (as Paul Wise corrected), which would produce another warning -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: Debian vs. Ubuntu source control file

Raphael Hertzog a écrit : What do you, folks, think of this case ? I would merge the change even if the package doesn't exist. What about lintian crying in the rain ? More seriously, can we assume that we'll never have package name collisions (ie. "foo", if exist on two distributions, are gu

Debian vs. Ubuntu source control file

[ Don't hesitate to redirect me to an already discussed solution/thread/FAQ/anything if necessary, but I didn't find anything related in recent (months) debian-devel. ] Hi folks (and happy new year to all DD), A minor issue (reported by Nick Ellery) with debian vs. ubuntu package is that the

Re: postinst-has-useless-call-to-ldconfig with a -dev package because of .so development files ?

Aaron M. Ucko a écrit : More likely because of the private shared libraries in /usr/lib/httrack/libtest. dh_makeshlibs -X/usr/lib/httrack/libtest Darn - this was indeed the solution, thanks! -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL

postinst-has-useless-call-to-ldconfig with a -dev package because of .so development files ?

Hi folks, I'm trying to solve a small "postinst/postrm-has-useless-call-to-ldconfig" lintian warning in the binary package libhttrack-dev (source package: httrack) I suppose that dh_makeshlibs adds it because of .a/.so devel files being placed in /usr/lib (?) Is there a clean way to preven

Re: Bug#422137: ITP: 455FE10422CA29C4933F95052B792AB2 -- l33t h4x0r numb3r

> This package contains the "09F911029D74E35BD84156C5635688C0" number. The package should also contain the '455FE10422CA29C4933F95052B792AB2' number, which is also a very cool number. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTE

Re: Bug#422137: ITP: 09F911029D74E35BD84156C5635688C0 -- l33t h4x0r numb3r

Josselin Mouette a écrit : * Package name: 09F911029D74E35BD84156C5635688C0 This package contains the "09F911029D74E35BD84156C5635688C0" number. Geez :p If you want to be evil enough, I suggest that the library looks up a v6 record (such as mpa^Wevilnumber.debian.org), which would re

Broken package and update (Was: How to properly move a file from a .deb to another one ?)

Goswin von Brederlow wrote: Darn, this is a vicious packaging bug.. playing with the might be the solution to kick the simlink ? Be carefull and check with policy and packaging manual on this. Changing between link and dir is a complicated thing to do. Darn, I just uploaded the httrack-doc_3.

Re: How to properly move a file from a .deb to another one ?

swin von Brederlow a écrit : >> *BUT* note that /usr/share/doc/httrack/html is actually a simlink to >> ../../httrack/html (the reason is BUG 362836, which pointed that > You mean ../../../httrack/html, right? No, this is ../../html (jumping two levels teleports you to /usr/share - the html level

Re: How to properly move a file from a .deb to another one ?

libhttrack1 (3.41.6-1) ... Setting up proxytrack (3.41.6-1) ... dpkg: error processing webhttrack (--install): package webhttrack is not ready for configuration cannot configure (current status `config-files') Setting up httrack (3.41.6-1) ... Setting up libhttrack-dev (3.41.6-1) ... Erro

How to properly move a file from a .deb to another one ?

Hi folks, This is probably a louzy and obvious question, but I'm trying to fix a package error (files moved from a .deb to another one). When upgrading two packages (A and B) to the new version, dpkg is having some troubles, because some files from the new package A were actually in the old pa

Re: Honesty in Debian (was Re: Amendment to GR on GFDL, and the changes to the Social Contract

On Mon, 13 Feb 2006, Sven Luther wrote: > > Fonts or documentations are not softwares, for god's sake! > everything that is not hardware is software So a cat is a software, or a hardware ? Do I have to provide the sources (the DNA full sequence) if I want to give a kitten to someone, following the

Re: Honesty in Debian (was Re: Amendment to GR on GFDL, and the changes to the Social Contract

On Mon, 13 Feb 2006, Thomas Weber wrote: > Well, there are cases where the differences are totally unclear. Let's > start with PostScript files, go to interactive PDFs and -- while we are > at it -- let's think about HTML files with Javascript. Yes and no. They are clearly documentation in their f

Re: Honesty in Debian (was Re: Amendment to GR on GFDL, and the changes to the Social Contract

On Mon, 13 Feb 2006, Sven Luther wrote: > Nope, but i think those who try to hide the issue of non-free material in > main, by insisting that it is not software Fonts or documentations are not softwares, for god's sake! > I want to remind you all, that previous to the two GRs which clarified the

Re: Amendment to GR on GFDL, and the changes to the Social Contract

On Thu, 9 Feb 2006, Henrique de Moraes Holschuh wrote: > > Well, maybe the wording was not deceptive enough ? > Maybe people should get re-acquinted with GR 2004-04 and its results before > they bring up GR 2004-03, even for jokes. No, no. The funny joke is to modify the constitution with a decept

Re: Amendment to GR on GFDL, and the changes to the Social Contract

On Thu, 9 Feb 2006, Josselin Mouette wrote: > Le jeudi 09 février 2006 à 11:12 +0100, Xavier Roche a écrit : > > Maybe we could suggest another "editorial change" and revert to the > > previous wording (not everything is software) > This has already been voted. An

Re: Amendment to GR on GFDL, and the changes to the Social Contract

On Thu, 9 Feb 2006, Jérôme Marant wrote: > I'd propose to revert this and clearly define what software is. I fully agree. The "Holier than Stallman" stuff is really getting ridiculous. After the firmware madeness, now the documentation madeness. And after that, the font madeness maybe ? (after all

Re: Amendment to GR on GFDL, and the changes to the Social Contract

On Thu, 9 Feb 2006, Marco d'Itri wrote: > Well, maybe the people who mislabeled the "everything is software" vote > as an "editorial change" and deceived many other developers should have > tought about this. Maybe we could suggest another "editorial change" and revert to the previous wording (not

zlib1g/zlib1g-dev mismatch on caballero/sarti builders ?

Hi folks, I have (in the httrack source package) a build-depends containing "zlib1g, zlib1g-dev" - is there anything wrong with this dependency ? Some builders seems to have troubles: http://buildd.debian.org/fetch.php?&pkg=httrack&ver=3.40.1-1&arch=ia64&stamp=1137978811&file=log&as=raw http:/

Re: Your Confirmation Required

On Tue, 27 Dec 2005 [EMAIL PROTECTED] wrote: > This message is to verify that you wish to have your > email address: debian-devel@lists.debian.org added to the > Alharamain Sermon(english) Couldn't we have a BLACKLIST to filter out spamme^Widiots who can not handle properly their spamm^mailing lis

Additional binary package generated by a source package: how to handle this ?

Hi folks, If a source package "foo", which produces a binary package (say, "bar"), also produces an additional "baz" package in an updated version, how this should be handled ? Any specific things to do, apart from appending the debian/control file (and debian/baz.files) with the new entry ? Wi

Re: Bug#323722: maintainer seems MIA, we should orphan this package.

On Thu, 18 Aug 2005, Roberto Lumbreras wrote: > Maybe you are right with progsreiserfs, it is not my favorite package to > fsck my filesystem, it has lots of bugs, but if there are fixes we > should let Jose Luis or someone to fix them. By the way, why do we have two separate packages for reiserf

Re: Greylisting for @debian.org email, please

On Fri, 17 Jun 2005, Andreas Barth wrote: > Come one. We're speaking on additional 5 minutes on the first > connection. Greylist works quite well for me, and I really hope that we > manage to deploy anti-spam-tools on Debian. Me too. See also some interesting tips here for Sendmail:

Re: New Nokia device is Debian-based?

On Mon, Jun 06, 2005 at 02:19:20PM +0200, Michelle Konzack wrote: > Many of those Patents a not related to OSS. Yes, true. But many other "non software" patents are actually disguised software patents (such as implementing a trivial algorithm on a chip - hey, these ARE software patents) > And s

Re: New Nokia device is Debian-based?

On Mon, Jun 06, 2005 at 01:33:00PM +0200, Jesus Climent wrote: > That is the key: OSS cannot be killed, not while EU and USA's governments, > local and nationwide, are promoting, using and even developing OSS themselves. I can't be killed, but it can be expensive. What will do governments, local a

Re: New Nokia device is Debian-based?

On Mon, Jun 06, 2005 at 11:47:50AM +0200, David Weinehall wrote: > So, I take it you don't buy any products from Apple, IBM, Sony, > etc either? Same for Alcatel, Ericsson and Siemens, who actively support software patents in Europe :( They all sent threat/blackmail letters to European government

Re: stack protection

On Thu, 21 Aug 2003, Russell Coker wrote: > Who is interested in stack protection? > I think it would be good to have some experiments of stack protected packages > for Debian. > Also is there any interest in uploading a kernel-image package with the grsec > PaX support built in? grsec is IMHO

Re: hey

It might be a good idea to reject MIME messages in -devel? Do we need attachments? (patchs can be inserted in the message body)

Re: Opteron donation?

Martin Michlmayr - Debian Project Leader wrote: Digital Network UK and FMS Computer have kindly agreed to donate machines to Debian. This is great news. Discussions on opteron port will be done in -devel? (especially problems like /lib+/lib64 vs /lib+/lib32, upgrading problems from i386 to optero

Re: Homepage & snapshot in debian/control?

Stefano Zacchiroli wrote: I agree on the Homepage field. Many times I've been asked by not-so-expert debian users on how to find the homepage of a package shipped with debian. Passing through copyright file is not so easy and probably even not so appropriate. A "Homepage:" field would then be okay?

Re: No crc32 package in Debian?

On Thu, Jul 03, 2003 at 04:25:25PM +0200, Benjamin Drieu wrote: > Doesn't cksfv does the job ? Absolutely - I did not find it in the first time, as the primary goal was to generate sfv files (but you can get the CRC inside it)

No crc32 package in Debian?

I was looking for the very simple "crc32" binary to compute checksums for files, and couldn't find it. There is a crc32 perl lib, but no crc32 package. I know that md5 (or even sha-160) hash fingerprints are better, but in many cases (like tar archives on tapes, or ftp files) you have only CRC-3

Re: Update re: read-only root filesystem

> To tell the truth, I didn't realize that so many files in /dev/ > were being fiddled. Obviously, one solution to the problem is > to have a separate writable /dev/ filesystem, e.g., devfs. Note that devfs is still "experimental" in 2.4 Another remark for the HOWTO : mounting /tmp in "tmpfs" (s

Re: Update re: read-only root filesystem

> this is not a problem due to devpts filesystem. Okay, using devfs it works perfectly. A remaining problem is also Samba: [2003/06/22 11:09:07, 0] passdb/machine_sid.c:pdb_generate_sam_sid(85) unable to open or create file /etc/samba/MACHINE.SID. Error was Read-only file system So actually s

Re: Update re: read-only root filesystem

hould I fill a BTS for the /etc/init.d/sysklogd bogus with read-only /dev problem anyway? --- Xavier Roche [EMAIL PROTECTED]

Re: Update re: read-only root filesystem

[I hope I did not sent twice this mail] > Packages that still employ variable files in /etc/ include: > mount, ifupdown, dhcpcd, linuxlogo, ppp, util-linux. > Fortunately, some of the files can be replaced by symlinks. > See my README file at > http://panopticon.csustan.edu/thood/readonly-root

Re: Update re: read-only root filesystem

> Packages that still employ variable files in /etc/ include: > mount, ifupdown, dhcpcd, linuxlogo, ppp, util-linux. > Fortunately, some of the files can be replaced by symlinks. > See my README file at > http://panopticon.csustan.edu/thood/readonly-root.html > for (incomplete) information. >

Re: Debian for x86-64 (AMD Opteron) and migration?

Ok, a bit late in this thread, but just a small remark on the future Opteron port : we have to take a *great* care of the migration process. The main difference betweek Intel-64 and AMD-64, if I am correct, is that administrators can unplug their ix86 disk from the server, and replug it on a opte

Build problems on mips/mipsel: Assembler messages: Branch out of range

I encountered several compiling problems on s390 and mips due to compiler capacity error, and apparently disabling optimizations on s390 did the trick. Unfortunately, it did not the trick on mips & mipsel archs: gcc -DHAVE_CONFIG_H -I. -I. -I.. -DINET6 -DPREFIX=\"/usr\" -DSYSCONFDIR=\"/etc\" -D

Re: Build problems on s390 & hppa (compiler/assembler bugs?)

>>I believe that you have hit a compilation limit in the pa backend. You >>have an unconditional branch that can't reach its target. The only work >>around at the moment is to compile without optimization. See the comments >>in pa/pa.md for the "jump" insn. We need a scratch register to load t

Re: Build problems on s390 & hppa (compiler/assembler bugs?)

>>No, you don't have to patch configure.in. Simply doing >>CFLAGS=-O0 -Whatever_you_want ./configure >>should do it. Of course, you want to put that in a make if-statement, so >>that it's only executed on the specific failing architectures... Yes, that's what I was thinking about. I suppose I'll

Build problems on s390 & hppa (compiler/assembler bugs?)

Hi, I am currently in "new maintainer phase", and my package was sponsored by Christian Marillat, and uploaded to the autobuilder. (I am also the author of the original package) I have two build problems ; one on s390, mips & mipsel architectures, and one on hppa architecture. (see http://buil