Bug#816247: general: hardening distro is an afterthought

2016-02-28 Thread Richard Jasmin
Package: general Severity: normal Tags: newcomer upstream patch Dear Maintainer, In RE of my overview of debian security(and the forced do-it-yourself mentality) I am providing a general coverage of hardening policy with Debian STABLE. There is much to learn from other distros here, namely the I

Re: How to deal with "assets" packages shadowing real upstream

2016-02-28 Thread Paul Wise
On Mon, Feb 29, 2016 at 5:05 AM, Antonio Terceiro wrote: > IMO both in this specific case, and in the general case, the correct > technical decision is to track the actual upstream as a proper > Javascript package (supporting both browser usage and NodeJS, if it > makes sense), and make the conven

Re: How to deal with "assets" packages shadowing real upstream

2016-02-28 Thread Antonio Terceiro
On Fri, Feb 26, 2016 at 10:37:48PM +0100, Jonas Smedegaard wrote: > I do recall our conversation at Debconf. That was however, I believe, > an agreement only between teams. I believe we cannot impose team rules > on Debian as a whole: I can file a _whishlist_ bugreport against a > package requ

Re: Re: Making Debian ports less burdensome

2016-02-28 Thread Ralf Treinen
On Sun, Feb 28, 2016 at 02:41:42PM +, peter green wrote: > 5: in the dose case seperating out arch specific packages (which are not > allowed to be uninstallable) from arch all packages (which are allowed to be > uninstallable), it is indicated in the list with an [all] tag but spotting > the

Re: Re: Making Debian ports less burdensome

2016-02-28 Thread peter green
I would have thought porters would be following the buildd/piuparts/CI pages for their port (where available) and thus would not need to be notified about arch-specific FTBFS or testing issues. If porters are relying on package maintainers or some automation to notify them instead of being pro-ac

Re: Re: Debian package on Windows

2016-02-28 Thread igor80
> I could be useful to create a Debian GNU/ReactOS port to avoid the > proprietary software dependency of a cross-compiled-only port. Really? Wow! -- igor

RE:Creating directory /sbuild-nonexistent/.lyx/

2016-02-28 Thread PICCA Frederic-Emmanuel
> please file bugs if you find other packages which try to access $HOME during > the build process. ok,I will do a bug report. Cheers Fred

Re: Creating directory /sbuild-nonexistent/.lyx/

2016-02-28 Thread Bastian Blank
Hi On Sun, Feb 28, 2016 at 09:09:45AM +, PICCA Frederic-Emmanuel wrote: > I know how to prevent this with the -userdir parameter of lyx, but I would > like to now if this is not a bug in sbuild ? > what is the expected behavious from sbuild when something try to create a > config file in th

Re: Creating directory /sbuild-nonexistent/.lyx/

2016-02-28 Thread Johannes Schauer
Hi, Quoting PICCA Frederic-Emmanuel (2016-02-28 10:09:45) > I am preparing the next tango package, so I need to build the doc with lyx. > > But then I get this error message. > > make[5]: Entering directory '/<>/tango-9.2.0~a+dfsg/build/doc/src' > cd ../../../doc/src; /usr/bin/lyx --export pdf2

Re: Creating directory /sbuild-nonexistent/.lyx/

2016-02-28 Thread Andrey Rahmatullin
On Sun, Feb 28, 2016 at 09:09:45AM +, PICCA Frederic-Emmanuel wrote: > make[5]: Entering directory '/<>/tango-9.2.0~a+dfsg/build/doc/src' > cd ../../../doc/src; /usr/bin/lyx --export pdf2 tango.lyx > LyX: Creating directory /sbuild-nonexistent/.lyx/ > Failed to create directory. Exiting. > > i

Creating directory /sbuild-nonexistent/.lyx/

2016-02-28 Thread PICCA Frederic-Emmanuel
Hello, I am preparing the next tango package, so I need to build the doc with lyx. But then I get this error message. make[5]: Entering directory '/<>/tango-9.2.0~a+dfsg/build/doc/src' cd ../../../doc/src; /usr/bin/lyx --export pdf2 tango.lyx LyX: Creating directory /sbuild-nonexistent/.lyx/ Fai