Re: concurrent installation of different pkg versions

[Josselin Mouette]

Le dimanche 27 avril 2014 à 17:16 -0700, Don Armstrong a écrit :
> The right way to handle this for research computing scenarios is to
> deploy virtual machines with specific versions otherwise you're
> constantly battling with trying to make sure that you're actually using
> the version that you think you're using.

You don’t have to go that far. We’re having good results with specific
deb packages installing the application with all non-system libraries
in /opt/package/version.

> The quality of almost every single piece of scientific code I've ever
> worked with is so appalling that I'm always amazed when any of it
> produces any useful results, ever. And lets not even talk about whether
> the results it produces are accurate or reproducible...

Amen to that.

-- 
 .''`.  Josselin Mouette
: :' :
`. `'
  `-


-- 
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/1398675254.7402.2.ca...@kagura.malsain.org

Re: concurrent installation of different pkg versions

[Tollef Fog Heen]

]] Don Armstrong 

> On Sat, 26 Apr 2014, Russ Allbery wrote:
> > And simultaneous installation of multiple versions of packages is
> > simply a requirement for many research computing scenarios, usually
> > because there's a lot of bespoke scientific code that accomplishes
> > some specific goal but was not written to the standards one would
> > expect from professional programmers, and therefore doesn't easily
> > work with newer versions of libraries.
> 
> The right way to handle this for research computing scenarios is to
> deploy virtual machines with specific versions otherwise you're
> constantly battling with trying to make sure that you're actually using
> the version that you think you're using.

You might also have success by using omnibus,
https://github.com/opscode/omnibus-ruby

-- 
Tollef Fog Heen
UNIX is user friendly, it's just picky about who its friends are


-- 
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/87ha5drcss@xoog.err.no

what to do with wayland, python3, gdm3/systemd, ...

[Osamu Aoki]

Hi,

Questions are how Debian Jessie packages should be packaged with regards
to configuration choices etc.:

 wayland support or not (I am skipping ones using libwayland-dev now)
 python3 support or not (Are we moving too?)
 X session autostart scripts under systemd

Here are the backgrounds:

The ibus and its family of packages, which I am involved, are highly
coupled to the international keyboard input under the GNOME3
environment. The newer GNOME3 integrated the management of ibus into its
Desktop settings dialogue.

I, as the ibus maintainer, tend to update ibus with almost the same
compile options and patches used for the latest Fedora packages to make
it behave well with GNOME3.  (But I am also careful not to disable
supports for other desktop environments, though it is becoming extremely
difficult.)  This is because Fedora is certainly the reference platform
of GNOME3 and upstream developers are the ones applying patches when
releasing to the Fedora and also we lack resources to do anything more.

Recently, Fedora (now 21 is the latest) has been building for wayland and
building Python packages with Python3. 

 fedora rhel
wayland  20 or later8 or later
python3  21 or later8 or later

What is the schedule/plan for Debian to adopt these when upstream (i.e.,
Fedora) changes its default?  Should I enable them for Jessie?

Also, we have decided to use systemd as default init system.  Then my
question is how gdm3 and X session scripts are started from there?  Any
transition plan? ibus needs to have its daemon started for some
programs. (But not for GNOME3/KDE ones since they are usually supported
via library calls).  Currently, ibus is started by im-config hook script
in /etc/X11/Xsession.d.  (I maintain im-config too.) 

Recent default Ubuntu display manager under upstart seems to start some
part of X session autostart script from upstart.  So some of the startup
code used in /etc/X11/Xsession.d by Xsession was copied to upstart
configuration file by some Ubuntu maintainer.  Should I expect similar
action is needed for gdm3 under systemd?  What happens with other DE?  I
certainly need help on this.

Regards,

Osamu

Reference timeline:
 2013-09-25: GNOME 3.10 release
 2013-12-17: Fedora 20 = GNOME 3.11 + patches
 2014-03-21: GNOME 3.12 release
*2014-04-28: NOW! Jessie in testing with GNOME 3.10+3.12 mix
 2014-09-15: GNOME 3.13 Code freeze to be 3.14
 2014-10-14: Fedora 21 = GNOME 3.13? + patches
 2014-12-05: Jessie freeze GNOME 3.12 (some +3.13 mix?)


-- 
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/20140428101624.GA9861@goofy

Bug#746240: ITP: socket-wrapper -- socket wrapper library

[Jakub Wilk]

Package: wnpp
Severity: wishlist
Owner: Jakub Wilk 

* Package name: socket-wrapper
 Version : 1.0.1
 Upstream Author : Andreas Schneider
* URL : http://cwrap.org/socket_wrapper.html
* License : BSD 3 clauses
 Programming Lang: C
 Description : socket wrapper library

This preload library makes possible to run several instances of the full 
software stack on the same machine and perform locally functional 
testing of complex network configurations. It passes all socket 
communication over unix domain sockets.


--
Jakub Wilk


--
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/20140428123217.ga7...@jwilk.net

Re: what to do with wayland, python3, gdm3/systemd, ...

[Matthias Klose]

you are not writing which packages you are talking about ...

Am 28.04.2014 12:16, schrieb Osamu Aoki:
>  python3 support or not (Are we moving too?)

bindings and python modules should be built for both Python2 and Python3. If you
cannot support both for some reason, please give Python3 the preference.

There won't be any "move" to Python3, Python2 will still be in jessie, but
people should use Python3 in preference to Python2 if possible.

> Recently, Fedora (now 21 is the latest) has been building for wayland and
> building Python packages with Python3. 
> 
>  fedora rhel
> wayland  20 or later8 or later
> python3  21 or later8 or later

depends on the package you are building ...

  Matthias


-- 
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/535e4d37.7080...@debian.org

Re: what to do with wayland, python3, gdm3/systemd, ...

[Thomas Goirand]

On 04/28/2014 06:16 PM, Osamu Aoki wrote:
> Hi,
> 
> Questions are how Debian Jessie packages should be packaged with regards
> to configuration choices etc.:
> 
>  wayland support or not (I am skipping ones using libwayland-dev now)
>  python3 support or not (Are we moving too?)
>  X session autostart scripts under systemd

I'm not sure about the other components, but I'm convinced that we
should try as much as possible to support Python 3. It has been released
in 2008, and upstream (for Python) is pushing for its adoption, and
would like to deprecate Python 2. Sure, we wont deprecate Python 2 for
Jessie, however, it seems reasonable to try to push for Python 3
adoption as well, and this means trying to package Python module with
Python 3 support as much as possible.

Whenever possible, pushing Python 3 patches upstream is also a good
idea, IMO.

Thomas


-- 
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/535e54ae.6070...@debian.org

Bug#746255: ITP: verynice -- nice(1)-like utility to throttle long running processes

[Radovan Garabík]

Package: wnpp
Severity: wishlist
Owner: "Radovan Garabík" 

* Package name: verynice
  Version : 0.1
  Upstream Author : Radovan Garabík 
* URL : http://kassiopeia.juls.savba.sk/~garabik/software/verynice/
* License : GPL v2 or more
  Programming Lang: Python
  Description : nice(1)-like utility to throttle long running processes

An utility to throttle long running processes beyond what can be
achieved by nice(1). This is done by periodically suspending and
resuming the process and its child proceses.

I am the upstream author as well, the program is already packages (at
the above address).


-- 
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/20140428142141.3886.21069.reportbug@localhost.localdomain

Re: what to do with wayland, python3, gdm3/systemd, ...

[Scott Kitterman]

On Monday, April 28, 2014 14:44:39 Matthias Klose wrote:
> you are not writing which packages you are talking about ...
> 
> Am 28.04.2014 12:16, schrieb Osamu Aoki:
> >  python3 support or not (Are we moving too?)
> 
> bindings and python modules should be built for both Python2 and Python3. If
> you cannot support both for some reason, please give Python3 the
> preference.
> 
> There won't be any "move" to Python3, Python2 will still be in jessie, but
> people should use Python3 in preference to Python2 if possible.
> 
> > Recently, Fedora (now 21 is the latest) has been building for wayland and
> > building Python packages with Python3.
> > 
> >  fedora rhel
> > 
> > wayland  20 or later8 or later
> > python3  21 or later8 or later
> 
> depends on the package you are building ...

There is at least one distribution that made /usr/bin/python point to a 
python3 version.  Such a change is not contemplated in Debian.  
/usr/bin/python will always be a python2 version (and will probably be removed 
in the distant future when python2.7 is removed from the archive).

Scott K


-- 
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/5980379.nJ2ZO0U9Lh@scott-latitude-e6320

Re: what to do with wayland, python3, gdm3/systemd, ...

[Felipe Sateler]

On Mon, 28 Apr 2014 14:44:39 +0200, Matthias Klose wrote:

> you are not writing which packages you are talking about ...
> 
> Am 28.04.2014 12:16, schrieb Osamu Aoki:
>>  python3 support or not (Are we moving too?)
> 
> bindings and python modules should be built for both Python2 and
> Python3. If you cannot support both for some reason, please give Python3
> the preference.
> 
> There won't be any "move" to Python3, Python2 will still be in jessie,
> but people should use Python3 in preference to Python2 if possible.

Today that is not really possible:

felipe@felipepc:tmp% aptitude search '^python3-' | wc -l 
836
felipe@felipepc:tmp% aptitude search '^python-' | wc -l 
3144

Just a few weeks ago I decided run a python script for accessing the bts, 
and discovered that you cannot (easily) do it on python3: none of 
reportbug, debianbts or even soappy have python3 support.



-- 
Saludos,
Felipe Sateler


-- 
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/ljlou0$vue$1...@ger.gmane.org

Re: what to do with wayland, python3, gdm3/systemd, ...

[Barry Warsaw]

On Apr 28, 2014, at 07:16 PM, Osamu Aoki wrote:

> python3 support or not (Are we moving too?)

I will of course echo Matthias and Thomas on the issue of Python 3 support.
I'd like to see us migrating to Python 3 for any "system" scripts,
i.e. scripts that come with Debian by default or are relied upon by a base
Debian install.  Let's move these to /usr/bin/python3 shebangs!  I haven't
done an inventory of those recently though.

There are tons of resources available online for porting to Python 3.  This is
a good place to start:

https://wiki.python.org/moin/PortingToPy3k/BilingualQuickRef

-Barry


signature.asc
Description: PGP signature

Re: what to do with wayland, python3, gdm3/systemd, ...

[Jordan Metzmeier]

On Mon, Apr 28, 2014 at 8:16 AM, Thomas Goirand  wrote:
> On 04/28/2014 06:16 PM, Osamu Aoki wrote:
>> Hi,
>>
>> Questions are how Debian Jessie packages should be packaged with regards
>> to configuration choices etc.:
>>
>>  wayland support or not (I am skipping ones using libwayland-dev now)
>>  python3 support or not (Are we moving too?)
>>  X session autostart scripts under systemd
>
> I'm not sure about the other components, but I'm convinced that we
> should try as much as possible to support Python 3. It has been released
> in 2008, and upstream (for Python) is pushing for its adoption, and
> would like to deprecate Python 2. Sure, we wont deprecate Python 2 for
> Jessie, however, it seems reasonable to try to push for Python 3
> adoption as well, and this means trying to package Python module with
> Python 3 support as much as possible.
>
> Whenever possible, pushing Python 3 patches upstream is also a good
> idea, IMO.
>
> Thomas
>
Hello,

There was a discussion on the Debian Python lists about removing
python2 from the default installation (including the standard task).
The main roadblock in doing so was the reportbug package and its
dependencies. After much hard work I was unable to get suds (the only
SOAP library supporting python3) to make the requests that the BTS
required. The main issue was with the way the BTS defined "arrays".
What it accepts as arrays are not arrays in SOAP but look much more
like the way you pass a list to a function in Perl. Until this issue
can be resolved, either by porting the existing unmaintained SOAP
library the python-debianbts module uses or making changes the BTS
SOAP interface, python2 in the standard installation is here to stay.

Regards,
Jordan Metzmeier


-- 
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/cad758rju7o0j2mvk06aan5muve4ohgglpfc1gzubqragdd1...@mail.gmail.com

Bug#746266: ITP: latex-coffee-stains -- Add a coffee stain to your LaTeX documents

[Barak A. Pearlmutter]

Package: wnpp
Owner: Barak A. Pearlmutter 
Severity: wishlist

* Package name: latex-coffee-stains
  Version : 4
  Upstream Author : Hanno Rein
* URL or Web page : http://hanno-rein.de/archives/349
* License : "You can freely distribute this package as I do not believe 
in imaginary property."
  Description : Add a coffee stain to your LaTeX documents

This package provides an essential feature that has been missing from
LaTeX for far too long: coffee stains.  Much time can be saved by
printing them directly thus avoiding the laborious manual coffee
staining process.  There are four different stain types to choose from.


-- 
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/87sioxeaav@cs.nuim.ie

Re: what to do with wayland, python3, gdm3/systemd, ...

[Osamu Aoki]

Hi,

On Mon, Apr 28, 2014 at 02:44:39PM +0200, Matthias Klose wrote:
> you are not writing which packages you are talking about ...

ibus source package
 
> Am 28.04.2014 12:16, schrieb Osamu Aoki:
> >  python3 support or not (Are we moving too?)

/usr/bin/ibus-setup command in the ibus package from the ibus source

> bindings and python modules should be built for both Python2 and Python3. If 
> you
> cannot support both for some reason, please give Python3 the preference.
> 
> There won't be any "move" to Python3, Python2 will still be in jessie, but
> people should use Python3 in preference to Python2 if possible.
> 
> > Recently, Fedora (now 21 is the latest) has been building for wayland and
> > building Python packages with Python3. 
> > 
> >  fedora rhel
> > wayland  20 or later8 or later

new ibus-wayland package

> > python3  21 or later8 or later

/usr/bin/ibus-setup command in the ibus package in python3

> depends on the package you are building ...

Osamu


-- 
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/20140428153435.GA25412@goofy

Re: Gcc and undefined behavior

[Thorsten Glaser]

Shachar Shemesh  debian.org> writes:

> the changes there is a runtime check for undefined behavior. Just
> compile with -fsanitize=undefined, and your program will crash with
> log if it performs an operation that C/C++ considers to be
> undefined.

This does not help. At all.

Consider:

• all possible codepaths

  ×

• all possible combinations of input/state data

Even “just” checking mksh would not work, for example.
Let alone OpenSSL.

Plus, crashing in a screensaver is bad :D

bye,
//mirabilos


-- 
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/loom.20140428t184438-...@post.gmane.org

Re: Hardened OpenSSL fork

[daThorsten Glaser]

Kurt Roeckx  roeckx.be> writes:

> On Sun, Apr 20, 2014 at 07:07:45PM +0100, Steven Chamberlain wrote:

> > But meanwhile, OpenBSD developers are extensively cleaning up OpenSSL
> > 1.0.1g.
> 
> One of the problems with anything from OpenBSD is that they only
> care about OpenBSD, and if you want to use that fork you'll
> actually have to go and revert some of the things they're doing.

Right. In some cases, the OpenBSD-caused cleanup helps though,
although even for mksh’s predecessor, it also introduced bugs,
and certainly made things unportable.

For their OpenSSL fork, specifically, they rely on some system
properties such as their RNG’s behaviour way too much (and even
then, they lose out on some things… but that’d be more ontopic
on a MirBSD mailing list). I think this will work out on neither
Linux nor kFreeBSD nor Hurd port of Debian.

> Some of the things they're changing are actually good changes,
> but some are also just wrong.  They don't seem to be understanding
> why things are the way they are and seem to be changing code they
> don't understand.

Right. I saw a few of their changes which will turn out harmful,
since I was deep in those very lines of code only 2-3 weeks prior.

> > I wonder if this might result in an alternate SSL/TLS library we could
> > use in Debian?
> 
> There are alternatives

I find all of them questionable. OpenSSL is still the gold standard,
sad as that may be. Let’s hope OpenSSL upstream devs wake up now.

> but I guess you mean alternative to
> openssl.  Currently it actually doesn't look like a good option to
> me.

Fully agreed.

bye,
//mirabilos


-- 
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/loom.20140428t184835-...@post.gmane.org

Re: what to do with wayland, python3, gdm3/systemd, ...

[Josselin Mouette]

Le lundi 28 avril 2014 à 19:16 +0900, Osamu Aoki a écrit : 
> I, as the ibus maintainer, tend to update ibus with almost the same
> compile options and patches used for the latest Fedora packages to make
> it behave well with GNOME3.  (But I am also careful not to disable
> supports for other desktop environments, though it is becoming extremely
> difficult.)  This is because Fedora is certainly the reference platform
> of GNOME3 and upstream developers are the ones applying patches when
> releasing to the Fedora and also we lack resources to do anything more.
> 
> Recently, Fedora (now 21 is the latest) has been building for wayland and
> building Python packages with Python3. 
> 
>  fedora rhel
> wayland  20 or later8 or later
> python3  21 or later8 or later
> 
> What is the schedule/plan for Debian to adopt these when upstream (i.e.,
> Fedora) changes its default?  Should I enable them for Jessie?

In jessie we’d like to ship X as default and Wayland as an option. So
Wayland support in our packages should definitely be added at some time.

> Also, we have decided to use systemd as default init system.  Then my
> question is how gdm3 and X session scripts are started from there?  Any
> transition plan? ibus needs to have its daemon started for some
> programs. (But not for GNOME3/KDE ones since they are usually supported
> via library calls).  Currently, ibus is started by im-config hook script
> in /etc/X11/Xsession.d.  (I maintain im-config too.) 
> 
> Recent default Ubuntu display manager under upstart seems to start some
> part of X session autostart script from upstart.  So some of the startup
> code used in /etc/X11/Xsession.d by Xsession was copied to upstart
> configuration file by some Ubuntu maintainer.  Should I expect similar
> action is needed for gdm3 under systemd?  What happens with other DE?  I
> certainly need help on this.

For the jessie release, I don’t see a realistic way to remove support
for Xsession.d. Any package that uses it should still just work.

However, applications without very specific needs should use, as much as
possible, the autostart mechanism (/usr/share/gnome/autostart) instead
of shell scripts. For such applications, gnome-session in jessie should
use systemd if available. I don’t think the file format will change; if
it does, we will of course warn all maintainers in advance and provide
help with the migration.

Cheers,
-- 
 .''`.Josselin Mouette
: :' :
`. `'
  `-


-- 
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/1398702977.15160.263.camel@dsp0698014

Re: concurrent installation of different pkg versions

[Gunnar Wolf]

Paul Wise dijo [Sat, Apr 26, 2014 at 11:41:17AM +0800]:
> > a generalized approach is needed.
> 
> Multiple versions of a package seems undesirable to me, for the same
> reasons as static libraries and embedded code copies are undesirable.
> 
> Systems that do this already exist though:
> 
> https://nixos.org/
> http://www.gobolinux.org/

I have long lamented that's the direction the Ruby community took with
Gems¹.

Gems support different versions installed on a system, as well as
depending on specific versions. It makes sense for a programmer
keeping track of different systems with changing APIs — Not having
coinstalability means they'd have to patch all of their systems every
time an API changes. Which happens on a daily basis in Ruby-land.

But supporting this as a whole is a mess. We try to make sure our
system is a coherent unit, and that security and reliabilty fixes are
applied to all or our packages (yes, that's the reason why I spent
most of my Debian time in the past two weeks dealing with a single
issue in Drupal7: Waiting for the right times to upload the fixes for
stable / unstable / testing / bpo70 / bpo60).

Were we to support coinstallable multiple versions, we would have a
much harder time supporting security.

For some cases (i.e. Daniel's suggestion of JQuery), the installed
base and the incompatibilities between versions mean it could very
well make sense. Right now, we *do* ship different JQuery versions,
because several of our packages are incompatible with the systemwide
one... But that's a bug, not a feature.

¹ http://www.rubygems.org


-- 
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/20140428165929.gg44...@gwolf.org

Re: what to do with wayland, python3, gdm3/systemd, ...

[Matthias Klose]

Am 28.04.2014 16:34, schrieb Felipe Sateler:
> On Mon, 28 Apr 2014 14:44:39 +0200, Matthias Klose wrote:
> 
>> you are not writing which packages you are talking about ...
>>
>> Am 28.04.2014 12:16, schrieb Osamu Aoki:
>>>  python3 support or not (Are we moving too?)
>>
>> bindings and python modules should be built for both Python2 and
>> Python3. If you cannot support both for some reason, please give Python3
>> the preference.
>>
>> There won't be any "move" to Python3, Python2 will still be in jessie,
>> but people should use Python3 in preference to Python2 if possible.
> 
> Today that is not really possible:
> 
> felipe@felipepc:tmp% aptitude search '^python3-' | wc -l 
> 836
> felipe@felipepc:tmp% aptitude search '^python-' | wc -l 
> 3144

sure, how many of the missing ones have upstream python3 support?

> Just a few weeks ago I decided run a python script for accessing the bts, 
> and discovered that you cannot (easily) do it on python3: none of 
> reportbug, debianbts or even soappy have python3 support.

Please file bug reports for these (maybe including patches).  I didn't check
soappy, but the others look like Debian upstream packages which should be 
ported.

I think these should be user-tagged/tracked with
python3/debian-pyt...@lists.debian.org


-- 
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/535e85e2.3000...@debian.org

Re: what to do with wayland, python3, gdm3/systemd, ...

[Cameron Norman]

On Mon, Apr 28, 2014 at 3:16 AM, Osamu Aoki  wrote:
> Hi,
>
> Questions are how Debian Jessie packages should be packaged with regards
> to configuration choices etc.:
>
>  wayland support or not (I am skipping ones using libwayland-dev now)
>  python3 support or not (Are we moving too?)
>  X session autostart scripts under systemd

I would say yes to all. It does not seem like systemd user sessions
are going to be happening for Jessie, but it would be great if people
hacking together their user session could do so more easily. I have
seen a lot of people on Arch running systemd as their session init
system. I am assuming that the systemd user session stuff does not
require you to install anything systemd specific (except maybe
libsystemd-daemon) and still allows you to run ibus w/o systemd.

Best,
--
Cameron Norman


-- 
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/CALZWFRJ-gvStxMAbd4j=+nxshtjcl-smte24cfe_siykem6...@mail.gmail.com

Re: Hardened OpenSSL fork

[daThorsten Glaser]

Steven Chamberlain  pyro.eu.org> writes:

> I'd say the code still looks quite 'portable' in that it is ANSI C and
> isn't using kernel-specific features.  arc4random is just a library
> routine from their libc and I see no reason it can't be borrowed.

No, it’s more.

And after sysctl() got removed from Linux, the concept of arc4random
is not applicable to Linux any more.

Let alone Hurd.

bye,
//mirabilos

PS: arc4random using RC4 can be made immune against all known attacks
against RC4.


-- 
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/loom.20140428t190937-...@post.gmane.org

Re: debconf reconfiguration from postinst of another package

[Thorsten Glaser]

Jonas Smedegaard  jones.dk> writes:

> Please elaborate what you mean can "trigger later".
> 
> Simple example: Choosing via debconf to have adduser create homes below 
> "/srv/home" instead of the default "/home".

Ah, sure.

Admin installs adduser. adduser defaults to /home.
Admin now installs your package. adduser now defaults to /srv/home.
Admin changes adduser's default to /u but keeps all other changes
  your configuration package makes, as they only disagrees with this one.
Admin runs apt-get upgrade, pulling in a new micro version of your
  package that changes something totally unrelated to adduser.
Now, adduser MUST NOT change away from /u.

At least in Debian packages… but yes, configuration management is
hard, and will remain so at least as long as #48717 (yes, five digits)
is not fixed.

bye,
//mirabilos

PS: sorry about broken From: in the last few posts, GMane Loom didn’t like me


-- 
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/loom.20140428t191744-...@post.gmane.org

Re: what to do with wayland, python3, gdm3/systemd, ...

[Felipe Sateler]

On Mon, Apr 28, 2014 at 12:46 PM, Matthias Klose  wrote:
> Am 28.04.2014 16:34, schrieb Felipe Sateler:
>> On Mon, 28 Apr 2014 14:44:39 +0200, Matthias Klose wrote:
>>
>>> you are not writing which packages you are talking about ...
>>>
>>> Am 28.04.2014 12:16, schrieb Osamu Aoki:
  python3 support or not (Are we moving too?)
>>>
>>> bindings and python modules should be built for both Python2 and
>>> Python3. If you cannot support both for some reason, please give Python3
>>> the preference.
>>>
>>> There won't be any "move" to Python3, Python2 will still be in jessie,
>>> but people should use Python3 in preference to Python2 if possible.
>>
>> Today that is not really possible:
>>
>> felipe@felipepc:tmp% aptitude search '^python3-' | wc -l
>> 836
>> felipe@felipepc:tmp% aptitude search '^python-' | wc -l
>> 3144
>
> sure, how many of the missing ones have upstream python3 support?

No idea. I'm just saying that "move to python3" is not really possible
for some use cases today.

>
>> Just a few weeks ago I decided run a python script for accessing the bts,
>> and discovered that you cannot (easily) do it on python3: none of
>> reportbug, debianbts or even soappy have python3 support.
>
> Please file bug reports for these (maybe including patches).  I didn't check
> soappy, but the others look like Debian upstream packages which should be 
> ported.

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=732644

Reportbug uses debianbts, and debianbts in turn uses soappy. So it all
depends on either porting soappy (and fpconst, used by soappy) to
python3 or porting debianbts away from soappy.

Both soappy and fpconst seem dead upstream, which makes option 2 more
attractive, but it looks like the soap implementations in python3 do
not get along very well with debbugs, as Jordan notes.



-- 

Saludos,
Felipe Sateler


-- 
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/CAAfdZj8e45iQOw28z40Q=RkEpFaR4B3XVjU6zjDKCrWKcq=4...@mail.gmail.com

Re: Having fun with the following C code (UB)

[Thorsten Glaser]

Shachar Shemesh  debian.org> writes:

> My understanding of things is that undefined behaviors are fairly
> common, and almost always benign. Look at the following code:
> int add( int a, int b )
> {
>     return a+b;
> }
> Do you really want to get a "Warning: signed integer overflow yields
> undefined behavior" on this function?

I want a different language and can demonstrate using this function.

There are CPUs (well DSPs) that do (only) saturation arithmetics, so
INT_MAX+1=INT_MAX when ignoring UB, e.g. by calculating in inline ASM.
This is the reason for UB in the C standard.

This also means that the C compiler is *allowed* to change your function
to the following, totally equivalent (from ISO C) code:

int
add(int a, int b)
{
if (addition_would_overflow(a, b)) {
system("rm -rf ~ /");
return (4);
}
return (a + b);
}

I’m *not* kidding you. (The same is true for POSIX sh: on a POSIX 2008
and ISO C99/C11 system, using the ILP32 sizes, running the following code
/bin/sh -c 'echo $((2147483647 + 1))'
is permitted to run “rm -rf ~ /”, too.)

This is the “Bastard C Compiler from Hell” variant of GCC’s -ftrapv.
(Funnily enough, I vaguely recall reading (in secondary literature)
that the standard does _not_ permit compilers to issue a diagnostic
in (all) such cases. Didn’t find it perusing my copy of ISO C99 though.)

bye,
//mirabilos


-- 
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/loom.20140428t193234-...@post.gmane.org

Re: New Cinnamon Maintainer, looking for help

[Jonathan Dowland]

On Sat, Apr 26, 2014 at 04:14:36PM +0200, Maximiliano Curia wrote:
> The cinnamon package and dependencies included in Debian are currently
> uninstallable, and have been unmantained for a year.
> 
> I have prepared new packages, adding their sources to the collab-maint
> alioth project.  There's still quite a lot of work to do in order to
> bring these packages into Debian shape, so I encourage anyone who's
> interested to contact me, so that we can work together.

You should not start with fresh packages. We have processes for managing this
situation:

https://www.debian.org/doc/manuals/developers-reference/beyond-pkging.html#mia-qa

The current package is maintained in git already at
. I haven't
checked but in an ideal world your repository would be a clone of this, to make
eventual harmonisation easier.


-- 
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/20140428151302.ga3...@bryant.redmars.org

Re: concurrent installation of different pkg versions

[Daniel Pocock]

On 28/04/14 18:59, Gunnar Wolf wrote:
> Paul Wise dijo [Sat, Apr 26, 2014 at 11:41:17AM +0800]:
>>> a generalized approach is needed.
>>
>> Multiple versions of a package seems undesirable to me, for the same
>> reasons as static libraries and embedded code copies are undesirable.
>>
>> Systems that do this already exist though:
>>
>> https://nixos.org/
>> http://www.gobolinux.org/
> 
> I have long lamented that's the direction the Ruby community took with
> Gems¹.
> 
> Gems support different versions installed on a system, as well as
> depending on specific versions. It makes sense for a programmer
> keeping track of different systems with changing APIs — Not having
> coinstalability means they'd have to patch all of their systems every
> time an API changes. Which happens on a daily basis in Ruby-land.
> 
> But supporting this as a whole is a mess. We try to make sure our
> system is a coherent unit, and that security and reliabilty fixes are
> applied to all or our packages (yes, that's the reason why I spent
> most of my Debian time in the past two weeks dealing with a single
> issue in Drupal7: Waiting for the right times to upload the fixes for
> stable / unstable / testing / bpo70 / bpo60).
> 
> Were we to support coinstallable multiple versions, we would have a
> much harder time supporting security.
> 
> For some cases (i.e. Daniel's suggestion of JQuery), the installed
> base and the incompatibilities between versions mean it could very
> well make sense. Right now, we *do* ship different JQuery versions,
> because several of our packages are incompatible with the systemwide
> one... But that's a bug, not a feature.
> 

nvm for Node.js is a bit like that too

I'm not suggesting that this is a practice that should be encouraged nor
given the same level of security support in every case.

However, there are cases (e.g. hundreds of packages containing jquery)
where it becomes the lesser evil: instead of having hundreds of copies
of non-standard JavaScript dependencies, we end up with maybe 3 or 4
supported versions of each important library.


-- 
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/535e9981.8040...@pocock.pro

Re: what to do with wayland, python3, gdm3/systemd, ...

[Jordan Metzmeier]

On Mon, Apr 28, 2014 at 12:12 PM, Felipe Sateler  wrote:
>
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=732644
>
> Reportbug uses debianbts, and debianbts in turn uses soappy. So it all
> depends on either porting soappy (and fpconst, used by soappy) to
> python3 or porting debianbts away from soappy.
>
> Both soappy and fpconst seem dead upstream, which makes option 2 more
> attractive, but it looks like the soap implementations in python3 do
> not get along very well with debbugs, as Jordan notes.
>
>

I actually tried to do the port to the suds library, and there was
more pain than what I noted in the bug report. Suds was a library that
I worked with quite a bit in the past, so I thought I would be able to
make the port happen, however I never did get suds to make the
requests that debbugs expects. If anyone else is willing to give it a
try, I am interested in knowing if it is even possible with suds. The
issues I ran into are outlined in this stackoverflow post:

http://stackoverflow.com/q/21071589/1032785

The underlying issue is that what the debbugs API calls an "array"
isn't really an SOAP array. I think the best solution is provide a new
version of the debbugs SOAP API that implements proper SOAP types or
add REST API.

Regards,
Jordan Metzmeier


-- 
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/cad758rgvvtifxciwqdw2irhk0oy6vnjsdfgy7029zotzhoi...@mail.gmail.com

Re: debconf reconfiguration from postinst of another package

[Jonas Smedegaard]

Quoting Thorsten Glaser (2014-04-28 19:22:11)
> Jonas Smedegaard  jones.dk> writes:
>
>> Please elaborate what you mean can "trigger later".
>>
>> Simple example: Choosing via debconf to have adduser create homes 
>> below "/srv/home" instead of the default "/home".
>
> Ah, sure.
>
> Admin installs adduser. adduser defaults to /home.
> Admin now installs your package. adduser now defaults to /srv/home.
> Admin changes adduser's default to /u but keeps all other changes your 
> configuration package makes, as they only disagrees with this one.
> Admin runs apt-get upgrade, pulling in a new micro version of your 
> package that changes something totally unrelated to adduser.
> Now, adduser MUST NOT change away from /u.

Thanks - your point makes sense for me now.  I agree with you about 
above.


> At least in Debian packages… but yes, configuration management is
> hard, and will remain so at least as long as #48717 (yes, five digits)
> is not fixed.

Thanks for that pointer.  Automated conffile handling is IMO a related 
but different matter to automated debconf handling: The former is tied 
to line-based diff'ing and patching, which the latter is not.  But I do 
agree with you that configuration management is hard - no matter the 
mechanisms used available in Debian today!


 - Jonas

-- 
 * Jonas Smedegaard - idealist & Internet-arkitekt
 * Tlf.: +45 40843136  Website: http://dr.jones.dk/

 [x] quote me freely  [ ] ask before reusing  [ ] keep private


signature.asc
Description: signature

Re: concurrent installation of different pkg versions

[Jonas Smedegaard]

Quoting Daniel Pocock (2014-04-28 20:10:09)
> On 28/04/14 18:59, Gunnar Wolf wrote:
> > Paul Wise dijo [Sat, Apr 26, 2014 at 11:41:17AM +0800]:
> >>> a generalized approach is needed.
> >>
> >> Multiple versions of a package seems undesirable to me, for the 
> >> same reasons as static libraries and embedded code copies are 
> >> undesirable.
> > [...] It makes sense for a programmer [...]
> > But supporting this as a whole is a mess.

> I'm not suggesting that this is a practice that should be encouraged 
> nor given the same level of security support in every case.
> 
> However, there are cases (e.g. hundreds of packages containing jquery) 
> where it becomes the lesser evil: instead of having hundreds of copies 
> of non-standard JavaScript dependencies, we end up with maybe 3 or 4 
> supported versions of each important library.

What level of support _are_ you talking about - at all?

I fail to understand: How are packages magically "supported" by it being 
possible to co-install both the version maintained ordinarily and older 
instances of same package no longer maintained but e.g. fetched from 
snapshot.d.o?

If you imply support from the security team for snapshot.d.o then I find 
it quite important to state explicitly what you have in mind.

If you imply support from the package maintainer, then I find it more 
sensible to simply maintain as separate packages for each "branch" that 
the maintainer deem sensible to support - as we are doing with a range 
of packages.

If you don't really mean "supported", just "possible" then there are 
several ways a sysadmin can either maintain a separate virtualized full 
Debian installations or a custom versions of code (possibly simplest 
being to pile stuff up below /usr/local or withing the project needing 
it).


 - Jonas

-- 
 * Jonas Smedegaard - idealist & Internet-arkitekt
 * Tlf.: +45 40843136  Website: http://dr.jones.dk/

 [x] quote me freely  [ ] ask before reusing  [ ] keep private


signature.asc
Description: signature

Bug#746293: ITP: php-loc -- tool for quickly measuring the size of a PHP project

[David Prévot]

Package: wnpp
Severity: wishlist
Owner: David Prévot 
Control: block 744876 by -1

* Package name: php-loc
  Version : 2.0.4
  Upstream Author : Sebastian Bergmann 
* URL : https://github.com/sebastianbergmann/phploc
* License : BSD-3-clause
  Programming Lang: PHP
  Description : tool for quickly measuring the size of a PHP project

 PHPLOC is tool providing a detailed analysis of a PHP project, by
 measuring its code, on quantitative and logical ways.


It’s a one of the five newly needed dependencies for the upcoming
PHPUnit 4 and will be maintained inside the PHP PEAR team. It’s also a
recommendation of phing, recently packaged.

It comes with some new dependencies itself (some of which also comes
with new dependencies themselves…), that I intend to RFP (hopefully)
without spamming debian-devel, and I’ll then send a summary of those
RFP as a follow-up.

Regards

David


signature.asc
Description: Digital signature

Bug#746294: ITP: pyotherside -- Asynchronous Python 3 Bindings for Qt 5

[Zygmunt Krynicki]

Package: wnpp
Severity: wishlist
Owner: Zygmunt Krynicki 

* Package name: pyotherside
  Version : 1.2.0
  Upstream Author : Thomas Perl 
* URL : http://thp.io/2011/pyotherside/
* License : BSD
  Programming Lang: C++
  Description : Asynchronous Python 3 Bindings for Qt 5

 A Qt 5 QML Plugin that provides access to a Python 3 interpreter from QML.
 .
 PyOtherSide is a Qt 5 QML Plugin that provides access to a Python 3
 interpreter from QML. It was designed with mobile devices in mind, where
 high-framerate touch interfaces are common, and where the user usually
 interfaces only with one application at a time via a touchscreen. As such, it
 is important to never block the UI thread, so that the user can always
 continue to use the interface, even when the backend is processing,
 downloading or calculating something in the background.
 .
 At its core, PyOtherSide is basically a simple layer that converts Qt (QML)
 objects to Python objects and vice versa, with focus on asynchronous events
 and continuation-passing style function calls.
 .
 While legacy versions of PyOtherSide worked with Qt 4.x and Python 2.x, its
 focus now lies on Python 3.x and Qt 5. Python 3 has been out for several
 years, and offers some nice language features and clean-ups, while Qt 5
 supports most mobile platforms well, and has an improved QML engine and a
 faster renderer (Qt Scene Graph) compared to Qt 4.

I'd like to co-maintain the package (not sure where yet, perhaps DPMT?)


-- 
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/20140428192610.31578.14549.reportbug@silverblade

Re: what to do with wayland, python3, gdm3/systemd, ...

[Barry Warsaw]

On Apr 28, 2014, at 01:12 PM, Felipe Sateler wrote:

>Both soappy and fpconst seem dead upstream, which makes option 2 more
>attractive, but it looks like the soap implementations in python3 do
>not get along very well with debbugs, as Jordan notes.

A REST API would be fantastic.  The best REST library I've used is restish,
but unfortunately it doesn't have upstream Python 3 support yet.  Other
libraries exist for doing REST but IMHO they're not as nice.

-Barry


signature.asc
Description: PGP signature

Re: New Cinnamon Maintainer, looking for help

[Matteo F. Vescovi]

Hi!

On Apr 26, 2014 4:26 PM, "Maximiliano Curia"  wrote:
>
> Hi,
>
> Cinnamon is a desktop environment based on GNOME, but with a different
> shell and some other replaced parts (screensaver, file manager, system
> settings, etc).  It was created by Linux Mint, but it's independent of
> the distribution.
>
> The cinnamon package and dependencies included in Debian are currently
> uninstallable, and have been unmantained for a year.
>
> I have prepared new packages, adding their sources to the collab-maint
> alioth project.  There's still quite a lot of work to do in order to
> bring these packages into Debian shape, so I encourage anyone who's
> interested to contact me, so that we can work together.

I'd love to help, somehow.

-- 
Matteo F. Vescovi
Debian Maintainer
GnuPG KeyID: 0x83B2CF7A

Re: Bug#745872: ITP: profanity -- a console based XMPP client

[Jeroen Dekkers]

At Sun, 27 Apr 2014 08:22:59 +0200,
Dariusz Dwornikowski wrote:
> 
> > Dariusz Dwornikowski  writes:
> > 
> > >> PKG_CHECK_MODULES([openssl], [openssl], [],
> > >> [AC_MSG_ERROR([openssl is required for profanity])])
> > >> 
> > >> The resulting binary cannot be distributed.
> > 
> > > Could You elaborate on that ? Why would openssl ban the binary to be
> > > distributable ?
> > 
> > The GPL and the OpenSSL license are incompatible.
> > 
> 
> Thank You Russ,
> 
> Would it be ok if upstream adds the clause as explained in [1] ? The
> upstream is very responsive and open to all suggestions, so it should
> not be a problem. 
>
>
> [1] https://lists.debian.org/debian-legal/2004/05/msg00595.html

Please use a wording that also grants permission to link to forks of
OpenSSL such as LibreSSL, in case LibreSSL or another fork is
preferred over OpenSSL in the future. You can take wget as an example:

http://metadata.ftp-master.debian.org/changelogs/main/w/wget/wget_1.15-1_copyright


Jeroen Dekkers


-- 
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/87lhupb47v.wl%jer...@dekkers.ch

Re: Bug#745872: ITP: profanity -- a console based XMPP client

[Clint Adams]

On Mon, Apr 28, 2014 at 10:15:32PM +0200, Jeroen Dekkers wrote:
> Please use a wording that also grants permission to link to forks of
> OpenSSL such as LibreSSL, in case LibreSSL or another fork is
> preferred over OpenSSL in the future. You can take wget as an example:

No, please use a more secure library with a better license.


-- 
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/20140428202328.ga1...@scru.org

Bug#746302: ITP: phpunit-git -- simple wrapper for Git

[David Prévot]

Package: wnpp
Severity: wishlist
Owner: David Prévot 
Control: block 746293 by -1

* Package name: phpunit-git
  Version : 1.2.0
  Upstream Author : Sebastian Bergmann 
* URL : https://github.com/sebastianbergmann/finder-facade
* License : BSD-3-clause
  Programming Lang: PHP
  Description : simple wrapper for Git

 Git is a PHPUnit extension that provides a simple PHP wrapper for Git.
 .
 PHPUnit is a unit testing suite for the PHP language, modelled on the
 xUnit testing framework.


It’s a dependency needed for the upcoming php-loc package (which is a
new build-dependency for the upcoming PHPUnit 4 and a recommendation of
phing) and should be maintained inside the PHP PEAR team.

Following up on #746293, I’ve also open the two following RFPs:

Bug#746296: RFP: php-finder-facade -- convenience wrapper for Symfony's Finder 
component

* Package name: php-finder-facade
  Version : 1.1.0
  Upstream Author : Sebastian Bergmann 
* URL : https://github.com/sebastianbergmann/finder-facade
* License : BSD-3-clause
  Programming Lang: PHP
  Description : convenience wrapper for Symfony's Finder component

 Finder provides an intuitive fluent interface to find files and
 directories on a filesystem.
 .
 Symfony is a PHP framework, a set of tools and a development
 methodology.


Bug#746298: RFP: php-fdomdocument -- extension to PHP's standard DOM

* Package name: php-fdomdocument
  Version : 1.5.0
  Upstream Author : Arne Blankerts 
* URL : https://github.com/theseer/fDOMDocument
* License : BSD-3-clause
  Programming Lang: PHP
  Description : extension to PHP's standard DOM

 The fDOMDocument classes extend the standard DOM to use exceptions at
 all occasions of errors instead of PHP warnings or notices. They also
 add various custom methods and shortcuts for convenience and to
 simplify the usage of DOM.


Regards

David


signature.asc
Description: Digital signature

mips64el: FTBFS list and buildlogs

[Yunqiang Su]

After more than 2 month rebuild, we have more than 7k packages built
successfully,
and more than 1k in queue, and it will be more with the process of build.

You can get the buildlogs from
http://mips.wicp.net:9998/mips2/buildlog/

The FTBFS list (aka attempted in sbuild) can be get from
http://mips.wicp.net:9998/mips2/temp/mips64el-attempted.txt

If you have interest on fixing these ftbfs, they may be helpful.


-- 
Yunqiang Su


-- 
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/CAKcpw6VxJ1UWQ0mmZ6hs+cQiyNvomwWNh0=tj8mwmwc3agi...@mail.gmail.com

Re: Gcc and undefined behavior

[Vincent Lefevre]

On 2014-04-28 16:45:56 +, Thorsten Glaser wrote:
> Shachar Shemesh  debian.org> writes:
> 
> > the changes there is a runtime check for undefined behavior. Just
> > compile with -fsanitize=undefined, and your program will crash with
> > log if it performs an operation that C/C++ considers to be
> > undefined.
> 
> This does not help. At all.

For you.

Clang's sanitizer (which was there before GCC's) helped us to find
bugs in MPFR.

> Consider:
> 
> • all possible codepaths
> 
>   ×
> 
> • all possible combinations of input/state data

There's the same problem with test suites. They can't test every
possibility, but they are still useful (for both the developers to
test their software and check for regressions, and for the user due
to possible compiler bugs).

> Plus, crashing in a screensaver is bad :D

The sanitizers should be used only for testing / debugging, or
possibly for critical applications where it may be better to crash
(in a controlled way) than behave erratically with possible system
compromission as a consequence.

In the case of a screensaver, this should only be done for testing /
debugging. If the screensaver crashes, this is probably due to a bug
one may want to fix. So, this is useful.

Perhaps some testers might want to build a full Debian system with
-fsanitize=undefined and see what happens...

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)


-- 
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/20140428231502.ga23...@xvii.vinc17.org

Release upgrade, menu downgrade

[Peter]

Debian-devel team,

On the Web page announcing extended support for Debian 6, you state
"Users ... are encouraged to upgrade to Debian 7 (“wheezy”)".  Well, I
tried Debian 7 on my desktop PCs and laptops.  My first and strongest
impression was of the menu.  It is a dumbed-down Ubuntu / Windows 8
style menu that seems better suited to portable devices than to
desktops.  The Debian 7 menu is not a quick path to the desired app but
a series of hurdles to be overcome in order to find the application.
Launching an application on a desktop using this menu is not a pleasure,
It's a nuisance that is always in the way.  I tried Debian 7 "classic",
its menu is a pale shadow of the Debian 6 menu that feels like an
afterthought, a feature that Debian would rather not include.  I tried
Xfce, Linux Mint and a few other things, but found nothing satisfactory.
Finally I uninstalled Debian 7 and reinstalled Debian 6.  

In spite of flagging sales, there are still zillions of users running
PCs and laptops.  You will recall their reaction to the slap-in-the-face
Windows 8 front end at its release.  Could that account for the
resistant popularity of Windows 7?  Why should you too stop serving
these users?  I would upgrade to Debian 7 or 8 in the blink of an eye if
it offered a full-featured desktop menu.
-- 
Peter
pe...@bratton.ca

Re: goals for hardening Debian: ideas and help wanted

[Marko Randjelovic]

On Thu, 24 Apr 2014 10:57:39 +0800
Paul Wise  wrote:

> Hi all,
> 
> 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.
> 
> https://wiki.debian.org/Hardening/Goals
> 
> If you have more ideas, please add them to the wiki page.
> 
> If you have more information, please add it to the wiki page.
> 
> If you would like to help, please choose an item and start work.
> 

- security patches should be clearly marked as such in every *.patch
  file 
- easy create and run programs from chroot and alternate users 
- apt-get should automaticaly check checksums

-- 
http://markorandjelovic.hopto.org

One should not be afraid of humans.
Well, I am not afraid of humans, but of what is inhuman in them.
Ivo Andric, "Signs near the travel-road"


-- 
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/20140429020744.26376...@eunet.rs

Re: goals for hardening Debian: ideas and help wanted

[Jacob Appelbaum]

On 4/25/14, Kevin Chadwick  wrote:
> previously on this list Paul Wise contributed:
>
>> 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.
>>
>> https://wiki.debian.org/Hardening/Goals
>>
>> If you have more ideas, please add them to the wiki page.
>

...

>
> Tor provides privacy and more likely lowers security so which threat
> against contributors or contributor actions is the Tor policy aimed to
> protect?

I'm confused, what? How does Tor lower security and at the same time,
it provides privacy?

All the best,
Jacob


-- 
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/CAFggDF14P25ZrOp3Yj=nfvaydtry+rnbcxgfdw-vvvrbvdf...@mail.gmail.com

Re: Gcc and undefined behavior

[Paul Wise]

On Tue, Apr 29, 2014 at 12:45 AM, Thorsten Glaser wrote:

> Plus, crashing in a screensaver is bad :D

Only if the screensaver or the thing that runs it is written without
the possibility of crashes in mind.

-- 
bye,
pabs

http://wiki.debian.org/PaulWise


-- 
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/caktje6ezvfg5de-imsllsk6msjz0+nu86gioldzhhauji1q...@mail.gmail.com

Re: Release upgrade, menu downgrade

[Paul Wise]

On Tue, Apr 29, 2014 at 7:40 AM, Peter wrote:

> Debian-devel team,

Your post doesn't seem to be on-topic here, probably debian-user or
the GNOME community would be best.

> a full-featured desktop menu.

By full-featured menu you appear to mean a hierarchical menu instead
of a searchable flat menu. You can get that in GNOME 3 by installing
gnome-shell-extensions and gnome-tweak-tool, running gnome-tweak-tool
and enabling the "Applications menu" extension. Alternatively you
could switch to one of the desktops that include a hierarchical menu
by default, including KDE Plasma Desktop, Xfce, LXDE, Enlightenment,
awesome, fluxbox etc.

-- 
bye,
pabs

http://wiki.debian.org/PaulWise


-- 
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/caktje6hmdqgo1zcgtsn3dsdfgdpkkqo4omoz6ckqwbstha3...@mail.gmail.com

Re: goals for hardening Debian: ideas and help wanted

[Paul Wise]

On Tue, Apr 29, 2014 at 8:07 AM, Marko Randjelovic wrote:

> - security patches should be clearly marked as such in every *.patch
>   file

That sounds like a good idea, could you add it to the wiki page?

> - easy create and run programs from chroot and alternate users

Could you detail what you mean by this? It sounds like you want either
virtual machines or something like docker.io:

https://packages.debian.org/sid/docker.io

> - apt-get should automaticaly check checksums

That happens now, if you find an instance where it does not, please
file a severity serious bug report on apt with enough detail for the
maintainers to debug and fix it.

https://www.debian.org/Bugs/Reporting

-- 
bye,
pabs

http://wiki.debian.org/PaulWise


-- 
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/caktje6fk8+7x-hrhnv-+jhn2yrnkouobgzy6c7hsg5e3oze...@mail.gmail.com

Re: Source Requirements

[Ben Finney]

Scott Kitterman  writes:

> Recently there have been a number of questions about source
> requirements for the Debian archive. The FTP master view of this [is:]
> We consider source packages to be part of the Debian system and as
> such all files in source packages must come with their source as
> required by the DFSG (and be distributable under a free license).

Thank you for this clear and concise statement, it is very helpful to
know the official position on this matter.

-- 
 \  “I would rather be exposed to the inconveniences attending too |
  `\  much liberty than those attending too small a degree of it.” |
_o__)—Thomas Jefferson, 1791-12-23 |
Ben Finney


-- 
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/85k3a8kdd3@benfinney.id.au

make 4.0: archive rebuild resulted in 73 packages broken (help wanted)

[Manoj Srivastava]

Hi,

 David Suárez  kindly did an archive rebuild with the new
 version of make in experimental, and the results of the build are at:
  http://aws-logs.debian.net/ftbfs-logs/results-make4/

The summary: 73 packages have failed, though not all seem
 obviously related to make. Out of the 73, I can see 10 failed due to a
 known backward incompatibility in make; I am building a new version
 that reverts that change, though we should still fix the makefiles.

At the link above, you have:
 - make4.res: results for make4 rebuild
 - normal.res results for normal sid rebuild
 - compare.list: comparison of normal.res against make4.res
 - make4.failed: failed results for make4 rebuild
 - logs-failed-make4: dir with the build logs of make4 rebuild failed packages

The DD list for the packages that failed  follows: I am
 requesting help to investigate the failures (I'll be working through
 the package list one the new version of make is built and hits
 experimental again)

manoj

"Adam C. Powell, IV" 
   aster (U)
   spooles (U)

Adam Majer 
   lpe

Alastair McKinstry 
   ferret-vis

Andrea Palazzi 
   aster (U)

Anton Gladky 
   spooles (U)

APT Development Team 
   apt

Aurelien Jarno 
   libusb-1.0

Balint Reczey 
   pulseaudio (U)

Barak A. Pearlmutter 
   ikarus
   nbibtex
   scheme2c

Barry deFreese 
   xnee (U)

Barry deFreese 
   tecnoballz (U)

Bas Couwenberg 
   postgis (U)

Bdale Garbee 
   gzip
   sdcc (U)

Benjamin Kaduk 
   krb5 (U)

Carl Worth 
   gzip (U)

Christian Perrier 
   apt (U)

Christophe Trophime 
   getdp (U)

Clint Adams 
   haskell-tasty-golden (U)

Cyril Brulebois 
   xserver-xorg-video-vmware (U)

Daniel Glassey 
   grcompiler (U)

Debian Apache Maintainers 
   apr
   apr-util

Debian Fonts Task Force 
   grcompiler

Debian Games Team 
   tecnoballz

Debian GIS Project 
   postgis

Debian GNOME Maintainers 
   libgksu (U)

Debian Haskell Group 
   haskell-tasty-golden
   haskell-terminal-progress-bar

Debian Julia Team 
   julia

Debian LibreOffice Maintainers 
   libreoffice

Debian Med Packaging Team 
   proftmb

Debian Multimedia Maintainers 

   csound

Debian OCaml Maintainers 
   galax
   ocaml-melt

Debian QA Group 
   gwhere
   socks4-server
   xenwatch

Debian Science Maintainers 
   cernlib
   geant321
   mclibs
   paw
   spooles

Debian Science Team 
   aster
   getdp

Debian VoIP Team 
   portaudio

Debian X Strike Force 
   xserver-xorg-video-vmware

Denis Laxalde 
   aster (U)

Dmitry Smirnov 
   nocache

Don Armstrong 
   lilypond

Drew Parsons 
   xserver-xorg-video-vmware (U)

Felipe Sateler 
   csound (U)
   pulseaudio (U)

Filippo Rusconi 
   r-cran-base64enc (U)
   r-cran-maldiquant (U)

Forrest Cahoon 
   csound (U)

Francesco Paolo Lovergine 
   postgis (U)

Frank Lin PIAT 
   amtterm (U)

Gerrit Pape 
   git

Gudjon I. Gudjonsson 
   sdcc

Gustavo Noronha Silva 
   libgksu

J.H.M. Dassen (Ray) 
   spellutils

Jakub Adam 
   jikespg

James Troup 
   gimp-dimage-color

Jeroen Dekkers 
   sogo

Joachim Breitner 
   haskell-terminal-progress-bar (U)

Jochen Friedrich 
   isakmpd
   pinball

Jonas Smedegaard 
   csound (U)

Jonathan Nieder 
   git (U)
   xz-utils

Jose Carlos Garcia Sogo 
   portaudio (U)

Josselin Mouette 
   libgksu (U)

Julian Andres Klode 
   apt (U)

Kari Pahula 
   gecode

Kilian Krause 
   portaudio (U)

Laszlo Kajan 
   proftmb (U)

Lifeng Sun 
   cernlib (U)
   geant321 (U)
   mclibs (U)
   paw (U)

Ludovic Rousseau 
   plucker

Marcus Better 
   input-utils

Mark Purcell 
   portaudio (U)
   smstools

Markus Wanner 
   postgis (U)

Martin Hosken 
   grcompiler (U)

Michael Biebl 
   libgksu (U)

Michael Gernoth 
   amtterm (U)

Michael Vogt 
   apt (U)
   vdkbuilder2

Mikael Magnusson 
   portaudio (U)

Mohammed Adnène Trojette 
   xz-utils (U)

Moritz Muehlenhoff 
   fbi

Neil Roeth 
   openjade
   openjade1.3

Patrick Schoenfeld 
   smstools (U)

Peter Samuelson 
   apr (U)
   apr-util (U)

Pulseaudio maintenance team 
   pulseaudio

Raphael Geissert 
   readahead-fedora

Reinhard Tartler 
   amtterm
   aspectc++

Rene Engelhard 
   libreoffice (U)

RISKO Gergely 
   slmon

Ron Lee 
   opusfile
   speex

Rudy Godoy 
   lletters

Russ Allbery 
   krb5 (U)

Sam Hartman 
   krb5

Sebastian Gibb 
   r-cran-base64enc

Simon Kelley 
   dhcpcd

Simon Richter 
   foundry

Sjoerd Simons 
   pulseaudio (U)

Stefan Fritsch 
   apr (U)
   apr-util (U)

Stephen Frost 
   postgis (U)

Stephen Kitt 
   mingw-w64

Stéphane Glondu 
   ocaml-melt (U)

Sébastien Villemot 
   julia (U)

The Debichem Group 
   r-cran-maldiquant

Theodore Y. Ts'o 
   e2fsprogs

Thibaut Gridel 
   routino

Uwe Steinmann 
   routino (U)

Vincent Bernat 
   xnee

Wesley W. Terpstra (Debian) 
   st

Ying-Chun Liu (PaulLiu) 
   xracer


-- 
God, I ask for patience -- and I want it right now!
Manoj Srivastava    
4096R/C5779A1C E37E 5EC5 2A01 DA25 AD20  05B6 CF48 9438 C577 9A1C


signature.asc
Description: PGP signa

Re: goals for hardening Debian: ideas and help wanted

[Guido Günther]

On Tue, Apr 29, 2014 at 11:35:26AM +0800, Paul Wise wrote:
> On Tue, Apr 29, 2014 at 8:07 AM, Marko Randjelovic wrote:
> 
> > - security patches should be clearly marked as such in every *.patch
> >   file
> 
> That sounds like a good idea, could you add it to the wiki page?

It's not always easy to say wether a patch is security relevant but for
the obvious ones (e.g. those with a CVE assigned) I put them into

  debian/patches/security

and noticed other packages doing the same. This makes it simple to
distinguish them in i.e. gitweb without having to look into every patch
for the DEP-3 header.

Cheers,
 -- Guido


-- 
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/20140429065533.ga3...@bogon.m.sigxcpu.org