Re: Bug#687103: ITP: maps -- OpenStreetMap client for the GNOME Desktop

[Andreas Tille]

On Wed, Sep 12, 2012 at 02:45:40PM +0300, Timo Juhani Lindfors wrote:
> Wookey  writes:
> > And navit and marble and foxtrotGPS and gpsdrive and viking and
> > gpxviewer and memphis.
> 
> Hey you forgot monav :)

Do you know that there is a page which (hopefully - just tell me if I'm
wrong!) lists all OSM related applications in Debian?

   http://blends.alioth.debian.org/gis/tasks/osm

Its builded using the Blends framework[1] and it is my poor share to
support the Debian GIS team (any more knowledged input about packages
that might fit into the GIS scope would be more than welcome).

Kind regards

  Andreas.

[1] http://blends.alioth.debian.org/blends/

-- 
http://fam-tille.de


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20120913070932.ga9...@an3as.eu

Bug#687258: ITP: mpdris2 -- media player interface (MPRIS2) bridge for MPD

[Simon McVittie]

Package: wnpp
Severity: wishlist
Owner: Simon McVittie 

* Package name: mpdris2
  Version : 0.2+git2012.08.14
  Upstream Author : Jean-Philippe Braun, Mantas Mikulėnas
* URL : https://github.com/eonpatapon/mpDris2
* License : GPL-3+
  Programming Lang: Python
  Description : media player interface (MPRIS2) bridge for MPD

mpDris2 is an implementation of the MPRIS2 media player interface as a
client for MPD, allowing MPRIS2 clients to control MPD and observe its
track changes via a standard D-Bus interface.

It can also respond to multimedia keys if running under GNOME,
and send track-change notifications if python-notify is installed.

---

mpDris2 supersedes the mpdris package (maintained by Michal Čihař and
RFA'd since 2011). mpDris implements MPRIS v1, which is no longer widely
supported; mpDris2 implements MPRIS v2.1, and works with more
modern MPRIS clients such as

(also by Jean-Philippe Braun). It is also said to work with Ubuntu Unity,
although I haven't tested that.

I intend to maintain this package in collab-maint, unless the pkg-mpd
team want to claim it. Co-maintainers welcome.


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/20120911083239.ga21...@reptile.pseudorandom.co.uk

Re: "X-" Prefixes deprecated by RFC 6648.

[Simon Josefsson]

Christoph Anton Mitterer  writes:

> Hey.
>
> Apart from the question whether this RFC is anyhow reasonable...
>
> On Thu, 2012-09-13 at 08:55 +0900, Charles Plessy wrote:
>> Category: Best Current Practice
> Can a BCP deprecate stuff which is standardised by RFCs from the
> standards track?

What RFCs are you thinking of?  The "X-" stuff was removed from e-mail
standards long time ago, IIRC.

/Simon


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/87mx0upc87@latte.josefsson.org

Bug#687490: ITP: python-django-mezzanine -- CMS built using the Django framework

[Per Andersson]

Package: wnpp
Severity: wishlist
Owner: Per Andersson 

* Package name: python-django-mezzanine
  Version : 1.2.4
  Upstream Author : Stephen McDonald 
* URL : http://mezzanine.jupo.org/
* License : BSD
  Programming Lang: Python, Javascript
  Description : CMS built using the Django framework

 Mezzanine is a powerful, consistent, and flexible content management platform.
 Built using the Django framework, Mezzanine provides a simple yet highly
 extensible architecture that encourages diving in and hacking on the code.
 .
 In some ways, Mezzanine resembles tools such as Wordpress that provide an
 intuitive interface for managing pages, blog posts, form data, store products,
 and other types of content. But Mezzanine is also different. Unlike many other
 platforms that make extensive use of modules or reusable applications,
 Mezzanine provides most of its functionality by default. This approach yields
 a more integrated and efficient platform.


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/20120913085225.18928.46778.report...@pong.oshw.org

Re: Towards d-i wheezy beta 3

[Wolodja Wentland]

On Mon, Sep 10, 2012 at 11:44 +0200, Marco d'Itri wrote:

> Also, we should mention somewhere (the install documentation?) that 
> non-free should be enabled to install microcode fixes which may be 
> critical to maintain the system stability.

Could you elaborate on this please? I have been running systems just fine
even though microcode.ctl (and corresponding microcode) was not installed and
a look at microcode.ctl's popcon [0] confirms that a majority of users do the
same.

If system stability does, in fact, depend *critically* on the presence of
microcode does this also mean that everybody should install it? What are the
implications of not installing it?

[0] http://qa.debian.org/popcon.php?package=microcode.ctl
-- 
Wolodja 

4096R/CAF14EFC
081C B7CD FF04 2BA9 94EA  36B2 8B7F 7D30 CAF1 4EFC


signature.asc
Description: Digital signature

Bug#687505: ITP: python-glanceclient -- Client library for Openstack glance server.

[Mehdi Abaakouk]

Package: wnpp
Severity: wishlist
Owner: Mehdi Abaakouk 

* Package name: python-glanceclient
  Version : folsom
  Upstream Author : Openstack
* URL : https://github.com/openstack/python-glanceclient
* License : Apache-2
  Programming Lang: Python
  Description : Client library for Openstack glance server.

This is a client for the Glance which uses the OpenStack Image API.
There's a Python API (the ``glanceclient`` module), and a command-line script 
(``glance``).


-- 
Mehdi Abaakouk
mail: sil...@sileht.net
irc: sileht


signature.asc
Description: Digital signature

Bug#687510: ITP: python-warlock -- Python object model built on top of JSON schema

[Mehdi Abaakouk]

Package: wnpp
Severity: wishlist
Owner: Mehdi Abaakouk 

* Package name: python-warlock
  Version : 0.4.0
  Upstream Author : Brian Waldon
* URL : http://github.com/bcwaldon/warlock
* License : Apache-2
  Programming Lang: python
  Description : Python object model built on top of JSON schema



-- 
Mehdi Abaakouk
mail: sil...@sileht.net
irc: sileht


signature.asc
Description: Digital signature

Bug#687518: ITP: python-cinderclient -- python bindings to the OpenStack Volume API

[Mehdi Abaakouk]

Package: wnpp
Severity: wishlist
Owner: Mehdi Abaakouk 

* Package name: python-cinderclient
  Version : folsom
  Upstream Author : Openstack
* URL : https://github.com/openstack/python-cinderclient
* License : Apache-2
  Programming Lang: Python
  Description : python bindings to the OpenStack Volume API

This is a client for the OpenStack Volume API. There's a Python API
(the ``cinderclient`` module), and a command-line script (``cinder``).
Each implements 100% of the OpenStack Volume API.


-- 
Mehdi Abaakouk
mail: sil...@sileht.net
irc: sileht


signature.asc
Description: Digital signature

Re: Towards d-i wheezy beta 3

[Henrique de Moraes Holschuh]

On Thu, 13 Sep 2012, Wolodja Wentland wrote:
> On Mon, Sep 10, 2012 at 11:44 +0200, Marco d'Itri wrote:
> > Also, we should mention somewhere (the install documentation?) that 
> > non-free should be enabled to install microcode fixes which may be 
> > critical to maintain the system stability.
> 
> Could you elaborate on this please? I have been running systems just fine
> even though microcode.ctl (and corresponding microcode) was not installed and
> a look at microcode.ctl's popcon [0] confirms that a majority of users do the
> same.

Either your system doesn't happen to have a processor with any of the worst
bugs, possibly because your BIOS/EFI has up-to-date microcode, or you're
just lucky.

The kernel could be working with reduced functionality to avoid triggering
the bug (it usually logs something when it notices it has to do that), and
it is also possible that you just didn't notice any issues because they can
be hard to detect. 

It is a fact that most users consider application or system crashes,
lock-ups, and slight malfunctions caused by data corruption to be facts of
life, and will blame software bugs first and foremost.  As long as they are
not too frequent, they will rarely even consider the possibility of hardware
problems.

> If system stability does, in fact, depend *critically* on the presence of
> microcode does this also mean that everybody should install it? What are the
> implications of not installing it?

The BIOS/EFI will almost always already have a microcode patch level to
apply to your processor.  You know something had to update the processor
microcode if the "microcode" line in /proc/cpuinfo is anything different
from zero (requires a recent kernel.  3.2 shows it).  So yes, it is very
often quite critical.

The question then becomes: does your EFI/BIOS have the latest microcode
updates?  Have you updated your BIOS/EFI recently?  Most users _never_
update the system firmware.  And some vendors just plain don't release
BIOS/EFI updates.

System stability depends critically on the presence of microcode that is as
up-to-date as required to cover all serious bugs on all features of the
processor that your workload uses.

So, chances are you don't need it.  Or that you need it, but you won't know
because it will cause data corruption or some sort of malfunction only once
a blue moon and you'd never notice the problem, or you end up blaming it on
something else.  Maybe you'd benefit from a microcode update, but since it
fixes errata that just causes, e.g. slight incorrect performance monitoring,
or some waste of power, or some slowdown because the kernel can't do all it
should be able to on your processor, you just didn't notice.

If you need to know for sure, you have to get the processor errata
documentation from Intel or AMD, check the errata list and the list of
errata fixed by microcode.  Also, these documents are not static, they do
get updated when new errata are disclosed.

AMD is much better at telling you what they're fixing with a microcode
update, the list of errata fixed is already in the README's of the
amd64-microcode package so you only need the processor documentation to know
what the errata numbers mean.  With Intel, you might or might not get a list
of errata fixed by a microcode version in the "processor specification
update" documents (and usually you don't get anything).

-- 
  "One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie." -- The Silicon Valley Tarot
  Henrique Holschuh


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20120913121749.ga29...@khazad-dum.debian.net

versioned dependency on the libhdf5-7 virtual package

[Ivan Shmakov]

This issue was already discussed [1], and I've filed the
respective bug report [2] (to which there was no reply so far,
though), but now I see that there's a few more packages in
Wheezy with a dependency on libhdf5-7.  Consider, e. g.:

$ bzcat \
  < http.debian.net/debian/dists/wheezy/main/binary-amd64/Packages.bz2 \
  | gawk '/^Package: / { pkg = $2; } /Version: / { vers = $2; }
  / libhdf5-7 \(/ { printf("%-23s %s\n", pkg, vers); }' 
libhe5-hdfeos0  5.1.13.dfsg.1-3
libhdf5-7-dbg   1.8.8-9
libhdf5-dev 1.8.8-9
cgns-convert3.1.3.4-1
libnexus0   4.2.1-svn1614-1+b1
libnexus0-java  4.2.1-svn1614-1+b1
nexus-tools 4.2.1-svn1614-1+b1
r-cran-hdf5 1.6.10-1
tessa   0.3.1-6
tessa-mpi   0.3.1-6
udav0.7.1.2-3
$ 

Any chance this issue will be rectified?  (Or should I file bug
reports against these packages?)

TIA.

[1] news:udlvci28as8@dr-wily.mit.edu
http://permalink.gmane.org/gmane.linux.debian.science/5353
[2] http://bugs.debian.org/680400

-- 
FSF associate member #7257  http://sfd.am-1.org/


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/86a9wu9iky@gray.siamics.net

Re: "X-" Prefixes deprecated by RFC 6648.

[Tanguy Ortolo]

Charles Plessy, 2012-09-13 01:55+0200:
> I would like to share with you the recently published RFC 6648, which
> deprecates the use of "X-" prefixes in "application protocols"

Perhaps we should consider changing the way we write user-defined
control fields (policy §5.7)? Instead of things like
XBCS-Comment: This field will appear in the changes, binary and
source control files

we may want to write:
tanguy.debian.org-BCS-Comment: …

or:
team.alioth.debian.org-BCS-Comment: …

-- 
 ,--.
: /` )   Tanguy Ortolo  
| `-'Debian Developer   
 \_


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/k2ss48$1vq$1...@ger.gmane.org

Re: "X-" Prefixes deprecated by RFC 6648.

[Scott Kitterman]

On Thursday, September 13, 2012 02:55:04 PM Tanguy Ortolo wrote:
> Charles Plessy, 2012-09-13 01:55+0200:
> > I would like to share with you the recently published RFC 6648, which
> > deprecates the use of "X-" prefixes in "application protocols"
> 
> Perhaps we should consider changing the way we write user-defined
> control fields (policy §5.7)? Instead of things like
> XBCS-Comment: This field will appear in the changes, binary and
> source control files
> 
> we may want to write:
> tanguy.debian.org-BCS-Comment: …
> 
> or:
> team.alioth.debian.org-BCS-Comment: …

I don't think so.  The premise of RFC 6648 is that generally X dash fields 
either never get updated to "proper" fields or if they do it creates confusion 
about which is correct.

In the case of Debian, we do want to distinguish between experimental and 
"proper" fields in control files and we do update them, so I think the premise 
of RFC 6648 doesn't apply to Debian.

Scott K


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/1643317.6Qy5rd4XGC@scott-latitude-e6320

Re: "X-" Prefixes deprecated by RFC 6648.

[Guillem Jover]

On Thu, 2012-09-13 at 14:55:04 +, Tanguy Ortolo wrote:
> Charles Plessy, 2012-09-13 01:55+0200:
> > I would like to share with you the recently published RFC 6648, which
> > deprecates the use of "X-" prefixes in "application protocols"
> 
> Perhaps we should consider changing the way we write user-defined
> control fields (policy §5.7)?

Why?

> Instead of things like
> XBCS-Comment: This field will appear in the changes, binary and
> source control files

The X gets discarded on output, so the field names will not have an X-
in the changes, binary or source control files. It should really be
thought more as a marker for the BCS flags than as a private field
marker.

> we may want to write:
> tanguy.debian.org-BCS-Comment: …
> 
> or:
> team.alioth.debian.org-BCS-Comment: …

There's already the Private- prefix which can be further namespaced,
is preserved on output, and avoids dpkg-deb giving warnings about
unknown fields (documented in deb-src-control(5)).

thanks,
guillem


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20120913151442.ga25...@gaara.hadrons.org

Processor microcode update packages (was: Towards d-i wheezy beta 3)

[Nikolaus Rath]

Henrique de Moraes Holschuh  writes:
> On Thu, 13 Sep 2012, Wolodja Wentland wrote:
>> On Mon, Sep 10, 2012 at 11:44 +0200, Marco d'Itri wrote:
>> > Also, we should mention somewhere (the install documentation?) that 
>> > non-free should be enabled to install microcode fixes which may be 
>> > critical to maintain the system stability.
>> 
>> Could you elaborate on this please? I have been running systems just fine
>> even though microcode.ctl (and corresponding microcode) was not installed and
>> a look at microcode.ctl's popcon [0] confirms that a majority of users do the
>> same.
>
[...]
>
> System stability depends critically on the presence of microcode that is as
> up-to-date as required to cover all serious bugs on all features of the
> processor that your workload uses.

I think this should be mentioned somewhere *much* more prominent. I
consider myself pretty tech-savy, but only stumbled upon this just now
on the this list. Can a non-free package be made essential or
required? It seems there is really absolutely no-reason other than
non-freeness for not installing this by default.


Best,

   -Nikolaus

-- 
 »Time flies like an arrow, fruit flies like a Banana.«

  PGP fingerprint: 5B93 61F8 4EA2 E279 ABF6  02CF A9AD B7F8 AE4E 425C


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/87ipbi3pr0.fsf...@kosh.rath.org

Re: Processor microcode update packages (was: Towards d-i wheezy beta 3)

[Andrei POPESCU]

On Jo, 13 sep 12, 11:29:39, Nikolaus Rath wrote:
> 
> I think this should be mentioned somewhere *much* more prominent. I
> consider myself pretty tech-savy, but only stumbled upon this just now
> on the this list. Can a non-free package be made essential or
> required? It seems there is really absolutely no-reason other than
> non-freeness for not installing this by default.

Could the various microcode packages be Suggested or even Recommended by 
firmware-linux-nonfree?

Kind regards,
Andrei
-- 
Offtopic discussions among Debian users and developers:
http://lists.alioth.debian.org/mailman/listinfo/d-community-offtopic


signature.asc
Description: Digital signature

Bug#687543: ITP: udpxy -- udpxy is a UDP-to-HTTP multicast traffic relay daemon

[Alex 'AdUser' Z]

Package: wnpp
Severity: wishlist
Owner: "Alex 'AdUser' Z" 

* Package name: udpxy
  Version : 1.0.23
  Upstream Author : Pavel V. Cherenkov 
* URL : http://www.udpxy.com
* License : GPL-3+
  Programming Lang: C
  Description : udpxy is a UDP-to-HTTP multicast traffic relay daemon

 udpxy is a UDP-to-HTTP multicast traffic relay daemon:
 it forwards UDP traffic from a given multicast subscription
 to the requesting HTTP client.


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/20120913155518.15744.67092.report...@balthasar.home.lan

Re: Processor microcode update packages (was: Towards d-i wheezy beta 3)

[Henrique de Moraes Holschuh]

On Thu, 13 Sep 2012, Nikolaus Rath wrote:
> Henrique de Moraes Holschuh  writes:
> > On Thu, 13 Sep 2012, Wolodja Wentland wrote:
> >> On Mon, Sep 10, 2012 at 11:44 +0200, Marco d'Itri wrote:
> >> > Also, we should mention somewhere (the install documentation?) that 
> >> > non-free should be enabled to install microcode fixes which may be 
> >> > critical to maintain the system stability.
> >> 
> >> Could you elaborate on this please? I have been running systems just fine
> >> even though microcode.ctl (and corresponding microcode) was not installed 
> >> and
> >> a look at microcode.ctl's popcon [0] confirms that a majority of users do 
> >> the
> >> same.
> >
> [...]
> >
> > System stability depends critically on the presence of microcode that is as
> > up-to-date as required to cover all serious bugs on all features of the
> > processor that your workload uses.
> 
> I think this should be mentioned somewhere *much* more prominent. I
> consider myself pretty tech-savy, but only stumbled upon this just now
> on the this list. Can a non-free package be made essential or
> required? It seems there is really absolutely no-reason other than
> non-freeness for not installing this by default.

For non-free, the priority doesn't make any difference.  It cannot be made
essential or required, because that doesn't make sense for non-free.
Basically, everything in non-free is effectively priority "extra".  That
said, both packages have their priority set to "standard" in the control
file, but ftp-masters decided to lower it.

It is also worth notice that enabling non-free is not just optional, it is
officially discouraged: non-free is not even mentioned by the Debian Wheezy
installer unless you're in expert mode.

And yes, the only reason to not have it installed by default on every x86
Debian system with an Intel or AMD processor is the non-freeness.

-- 
  "One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie." -- The Silicon Valley Tarot
  Henrique Holschuh


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20120913164559.gb29...@khazad-dum.debian.net

Re: Processor microcode update packages (was: Towards d-i wheezy beta 3)

[Henrique de Moraes Holschuh]

On Thu, 13 Sep 2012, Andrei POPESCU wrote:
> On Jo, 13 sep 12, 11:29:39, Nikolaus Rath wrote:
> > I think this should be mentioned somewhere *much* more prominent. I
> > consider myself pretty tech-savy, but only stumbled upon this just now
> > on the this list. Can a non-free package be made essential or
> > required? It seems there is really absolutely no-reason other than
> > non-freeness for not installing this by default.
> 
> Could the various microcode packages be Suggested or even Recommended by 
> firmware-linux-nonfree?

Probably not, because our support for arch-lists outside of
build-dependencies is just a hack (it is resolved at package build time, and
the dependencies are ommited based on the build arch).  The microcode
packages are arch-specific, and firmware-linux-nonfree is arch all.  Arch
all cannot have any arch-specific binary package dependencies.

This means a recommends or suggests for the two microcode packages, if added
to firmware-linux-nonfree, would be visible, and not satisfiable, on every
arch but i386 and amd64.

-- 
  "One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie." -- The Silicon Valley Tarot
  Henrique Holschuh


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20120913164947.gc29...@khazad-dum.debian.net

Re: Microcode and the installer (Re: Towards d-i wheezy beta 3)

[Henrique de Moraes Holschuh]

On Mon, 10 Sep 2012, Jonathan Nieder wrote:
> (replying to -devel and -boot only)
(I am not subscribed to -boot.  Please keep -devel on replies, or CC me
directly).

> Henrique de Moraes Holschuh wrote:
> > On Mon, 10 Sep 2012, Philipp Kern wrote:
> >> If we do that the same should also happen for firmware-linux-nonfree. 
> >> Loading
> >> the radeon KMS module without firmware available results in an unusable
> >> (text) console. (Yes, it might be considered a bug that radeon is loadable
> >> without.)
> >
> > Sounds good to me.
> >
> > What should I clone and hack to try to implement this?
> 
> , I think.

It is actually the hw-detect module, and adding support for the two system
processor microcodes is somewhat trivial... as long as I ignore VMs.  I just
need to add a hook to pre-pkgsel.d.

If I want to skip installing the processor microcode on VM images, I need to
install and "in-target" run virt-what before the hook can decide whether
installing the microcode packages is warranted or not.

Should I attempt to install virt-what (which brings dmidecode as a
dependency) to avoid wasting space on VM images ?

-- 
  "One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie." -- The Silicon Valley Tarot
  Henrique Holschuh


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/2012091316.gd29...@khazad-dum.debian.net

Re: Processor microcode update packages (was: Towards d-i wheezy beta 3)

[Wolodja Wentland]

On Thu, Sep 13, 2012 at 13:45 -0300, Henrique de Moraes Holschuh wrote:
> On Thu, 13 Sep 2012, Nikolaus Rath wrote:

> > I think this should be mentioned somewhere *much* more prominent. I
> > consider myself pretty tech-savy, but only stumbled upon this just now
> > on the this list. Can a non-free package be made essential or
> > required? It seems there is really absolutely no-reason other than
> > non-freeness for not installing this by default.

> It is also worth notice that enabling non-free is not just optional, it is
> officially discouraged: non-free is not even mentioned by the Debian Wheezy
> installer unless you're in expert mode.

The main problem I see is that there seem to be essentially two types of
packages in non-free right now, namely those that contain firmware/microcode
(etc) and are crucial for correctly working hardware and the rest. Most users,
and even those that prefer to install only free software, would probably want
to install all packages from non-free that are appropriate for their hardware.

> And yes, the only reason to not have it installed by default on every x86
> Debian system with an Intel or AMD processor is the non-freeness.

It is quite unfortunate that users who decide to not install non-free software
have to accept the fact that their hardware might work unreliable (if at all).
New users should, however, be made aware of this fact and offered help during
the installation to install appropriate packages. (either by the installer or
by making this explicit in the documentation)
-- 
Wolodja 

4096R/CAF14EFC
081C B7CD FF04 2BA9 94EA  36B2 8B7F 7D30 CAF1 4EFC


signature.asc
Description: Digital signature

Dyson project (Debian on illumos kernel)

[Игорь Пашев]

Hi, all.

I think it's time to announce, that I've been working on a new Debian
port from the last fall.
This is Debian on illumos kernel (formerly OpenSolaris) - http://osdyson.org

It really aims to be *general-purpose* OS, not a server, a destop or
an appliance.

I was motivated because Nexenta Core Platform is dead [1] and because I can :-)
And, in fact, NCP was not following Debian design:
1. It has terrible multiarch: 32- and 64-bit components in a signle package.
2. Huge packages like system-library with all libraries from illlumos, including
libc, PAM, Kerberos, python bindings and many others.

Dyson is a Debian derivative constructed from scratch. I'm doing
carefull packaging
of illumos bits (all nifty things like libc1, libc1-dev, libc-bin, etc
are present ;-).
I'm throwing out all illumos components which exists as separate
projects, keeping
only things which is unique for illumos: ZFS, DTrace, Fault Managment,
devfsadm, RBAC, SMF, etc.
I guess it is quite similar to Debian/kfreebsd. For example,
I have ported Linux PAM, shadow, openSSH. I'm using GNU userland. Of
course, some tools
will need to be patched to support some illumos features.

I'm following Debian testing/unstable. Dyson has multiarch support with
DEB_HOST_MULTIARCH=x86_64-illumos or i386-illumos.
Currently, it is only x86_64-illumos, dpkg arch is "illumos-amd64".
You can browse package at http://apt.osdyson.org/


Thus Dyson is to be Debian as much as possible, it even has package "locales"
and one can issue "dpkg-reconfigure locales" :-)


For now Dyson exists only in my VM. Here is a VirtualBox HDD image:
ftp://osdyson.org/download/vdi/, but I'm not sure if anyone can smoothly upgrade
from APT repo due to conflicts. I'm not going to bother with it while
illumos packaging
is a kind of scientific investigation :-) It has X server, but I
didn't compile any driver yet.

Also there is a bootable ISO: ftp://osdyson.org/download/iso/2012-05-22/

I do not have installer yet, but have some thoughts:
http://git.osdyson.org/?p=live.git

Currently i'm working on packaging illumos from source [2]
I've patched GNU make to support illumos makefiles [3] as well as GNU
ld from binutils
to support LD_ALTEXEC [4] since illumos linker is required to build
illumos sources
and GNU toolchain is the default on Dyson (GCC 4.7, binutils 2.22+)
I've written debhelper addons to ease building illumos [5]

 In a long term I'd like to have glibc ported [6].

A side effect of Dyson project is a "socialization" of illumos with
opensource world,
so it will be possible to have Gentoo on illumos kernel. It will
better fit with other
open source projects and development tools (cc, bison, flex, etc).
Just one example:
illumos kernel (yes. kernel, not userspace) has own kerberos implementation
and ships /usr/include/gssapi/gssapi.h. This prevents from installing
other kerberos
libraries. I've moved illumos gssapi.h inot /usr/include/sys/.

In a short term Dyson uses illumos kernel, illumos libc and SMF as init system.

Ok, there are to many thing I'd like to tell, it is easier for me to
answer questions :-)
You are welcome!


[1] http://wiki.illumos.org/pages/viewpage.action?pageId=1147367
[2] 
http://git.osdyson.org/?p=illumos-packaging.git;a=shortlog;h=refs/heads/source
[3] https://github.com/ip1981/gunmake/commits/sunmake
[4] 
http://osdyson.org/projects/binutils/repository/entry/patches/300_ld_altexec.patch
[5] http://git.osdyson.org/?p=dh-illumos.git
[6] https://github.com/ip1981/kopensolaris-glibc/commits/master


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/CALL-Q8xUE1_kB_5wVm+v8_=6mcceyho1vom0kc3r1k3wpnq...@mail.gmail.com

Handling /etc/modprobe.d and module load order

[Amit]

Hello,

I am using debhelper 9.20120115 and would like some advice on bundling
/etc/modprobe.d/package.modprobe and /etc/modules.

 1. I am currently using dh_installmodules to install package.modprobe.
However, I noticed that the automated debhelper commands in
postins/postrm don't run update-initramfs. Is updating initramfs not
necessary?

 2. I also need to specify module load order so I am bundling
/etc/modules. However, there doesn't seem to be a debhelper script
to handle /etc/modules.

I searched the list archives and found conflicting arguments regarding
the use of update-initramfs after updating /etc/modules or
/etc/modprobe.d/.

Thanks for any help,
Amit


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/loom.20120913t211146-...@post.gmane.org

Re: Dyson project (Debian on illumos kernel)

[Arno Töll]

Hi,

On 13.09.2012 20:48, Игорь Пашев wrote:
> I think it's time to announce, that I've been working on a new Debian
> port from the last fall.
> This is Debian on illumos kernel (formerly OpenSolaris) - http://osdyson.org


I like that idea (but I'm also involved in other "toy ports"). Do you
have any concrete plan to make a Debian port out of your project, aiming
full integration into Debian?


> It really aims to be *general-purpose* OS, not a server, a destop or
> an appliance.

... which usually raises questions about the driver usability. In
particular I wonder, if you looked at the kernel with respect to the
Debian's Free Software Guidelines, i.e. did you strip off non-free
drivers and blobs from the pristine kernel?

More generally speaking: Did you develop your port by having freeness of
(source) packages in mind?

> Dyson is a Debian derivative constructed from scratch. I'm doing
> carefull packaging
> of illumos bits (all nifty things like libc1, libc1-dev, libc-bin, etc
> are present ;-).

So you use the Solaris libc? Did you test that for interoperability with
Debian's (e)glibc? Note, kFreeBSD is also using a (patched) version of
(e)glibc, not FreeBSD's libc. I read below, you would like to use
(e)glibc as well, what are major issues there?

> only things which is unique for illumos: ZFS, DTrace, Fault Managment,
> devfsadm, RBAC, SMF, etc.

Did you make proper source packages out of that? Do you have some
statistics how much of Debian main builds on your system for the time
being?


> Currently i'm working on packaging illumos from source [2]
> I've patched GNU make to support illumos makefiles [3] as well as GNU
> ld from binutils
> to support LD_ALTEXEC [4] since illumos linker is required to build
> illumos sources
> and GNU toolchain is the default on Dyson (GCC 4.7, binutils 2.22+)
> I've written debhelper addons to ease building illumos [5]

While this is an implementation detail being up to you, I suggest to
look at kfreebsd core packages. These had a similar problem (GNU make
vs. BSD make), and it was solved in a pretty lazy way. YMMV.

> Just one example:
> illumos kernel (yes. kernel, not userspace) has own kerberos implementation
> and ships /usr/include/gssapi/gssapi.h. This prevents from installing
> other kerberos
> libraries. I've moved illumos gssapi.h inot /usr/include/sys/.

Historically, Linux did similar things. For example we had a kernel NFS
server and user space NFS servers for a long time. That said, Kerberos
is another level of insanity, without doubt.

-- 
with kind regards,
Arno Töll
IRC: daemonkeeper on Freenode/OFTC
GnuPG Key-ID: 0x9D80F36D



signature.asc
Description: OpenPGP digital signature

Re: Handling /etc/modprobe.d and module load order

[Ben Hutchings]

On Thu, 2012-09-13 at 19:19 +, Amit wrote:
> Hello,
> 
> I am using debhelper 9.20120115 and would like some advice on bundling
> /etc/modprobe.d/package.modprobe and /etc/modules.
>
>  1. I am currently using dh_installmodules to install package.modprobe.
> However, I noticed that the automated debhelper commands in
> postins/postrm don't run update-initramfs. Is updating initramfs not
> necessary?

That depends on what are you trying to do.

>  2. I also need to specify module load order so I am bundling
> /etc/modules. However, there doesn't seem to be a debhelper script
> to handle /etc/modules.

Don't ever touch /etc/modules, that's for the user/administrator.  You
can load modules from an init script if there is really no better way.

> I searched the list archives and found conflicting arguments regarding
> the use of update-initramfs after updating /etc/modules or
> /etc/modprobe.d/.

/etc/modules is used by the init scripts, not the initramfs.
/etc/modprobe.d *does* get copied to the initramfs and I think you're
right that update-initramfs should generally be called after it's
updated.  Perhaps initramfs-tools should have a file trigger for it,
though.

Ben.

-- 
Ben Hutchings
Make three consecutive correct guesses and you will be considered an expert.


signature.asc
Description: This is a digitally signed message part

Re: Handling /etc/modprobe.d and module load order

[Michael Biebl]

Am 13.09.2012 22:53, schrieb Ben Hutchings:
> On Thu, 2012-09-13 at 19:19 +, Amit wrote:

>>  2. I also need to specify module load order so I am bundling
>> /etc/modules. However, there doesn't seem to be a debhelper script
>> to handle /etc/modules.
> 
> Don't ever touch /etc/modules, that's for the user/administrator.  You
> can load modules from an init script if there is really no better way.

You can use a modules-load.d file [1]. While the idea originally comes
from systemd, it has also been implemented in the kmod (f.n.a.
module-init-tools) package.

Cheers,
Michael

[1] http://0pointer.de/public/systemd-man/modules-load.d.html



signature.asc
Description: OpenPGP digital signature

Re: Handling /etc/modprobe.d and module load order

[Amit]

Ben Hutchings  decadent.org.uk> writes:

[snip]

> >  1. I am currently using dh_installmodules to install package.modprobe.
> > However, I noticed that the automated debhelper commands in
> > postins/postrm don't run update-initramfs. Is updating initramfs not
> > necessary?
> 
> That depends on what are you trying to do.

Trying to load usbhid and passing a quirks parameter so that it ignores
a specific device. Then, I have my own kernel module to control that
device.

> 
> >  2. I also need to specify module load order so I am bundling
> > /etc/modules. However, there doesn't seem to be a debhelper script
> > to handle /etc/modules.
> 
> Don't ever touch /etc/modules, that's for the user/administrator.  You
> can load modules from an init script if there is really no better way.
> 

OK. So I blacklist the modules in package.modprobe. And then load them
in the order I want in package.init by just calling modprobe?

> > I searched the list archives and found conflicting arguments regarding
> > the use of update-initramfs after updating /etc/modules or
> > /etc/modprobe.d/.
> 
> /etc/modules is used by the init scripts, not the initramfs.
> /etc/modprobe.d *does* get copied to the initramfs and I think you're
> right that update-initramfs should generally be called after it's
> updated.  Perhaps initramfs-tools should have a file trigger for it,
> though.
> 

I ran some tests, and we definitely do need to update initramfs after
any changes under /etc/modprobe.d.

Thanks for reply.


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/loom.20120913t230818-...@post.gmane.org

Re: Handling /etc/modprobe.d and module load order

[Amit]

Michael Biebl  michaelbiebl.de> writes:

> 
> Am 13.09.2012 22:53, schrieb Ben Hutchings:

[snip]

> > Don't ever touch /etc/modules, that's for the user/administrator.  You
> > can load modules from an init script if there is really no better way.
> 
> You can use a modules-load.d file [1]. While the idea originally comes
> from systemd, it has also been implemented in the kmod (f.n.a.
> module-init-tools) package.
> 

Thanks. Looks like this is only implemented in the newer debian systems
correct?

Couldn't find it in squeeze.

> Cheers,
> Michael
> 
> [1] http://0pointer.de/public/systemd-man/modules-load.d.html
> 
> 


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/loom.20120913t235133-...@post.gmane.org

Re: Handling /etc/modprobe.d and module load order

[Ben Hutchings]

On Thu, 2012-09-13 at 21:47 +, Amit wrote:
> Ben Hutchings  decadent.org.uk> writes:
> 
> [snip]
> 
> > >  1. I am currently using dh_installmodules to install package.modprobe.
> > > However, I noticed that the automated debhelper commands in
> > > postins/postrm don't run update-initramfs. Is updating initramfs not
> > > necessary?
> > 
> > That depends on what are you trying to do.
> 
> Trying to load usbhid and passing a quirks parameter so that it ignores
> a specific device. Then, I have my own kernel module to control that
> device.

What is this driver?

> > >  2. I also need to specify module load order so I am bundling
> > > /etc/modules. However, there doesn't seem to be a debhelper script
> > > to handle /etc/modules.
> > 
> > Don't ever touch /etc/modules, that's for the user/administrator.  You
> > can load modules from an init script if there is really no better way.
> > 
> 
> OK. So I blacklist the modules in package.modprobe. And then load them
> in the order I want in package.init by just calling modprobe?

Unless you're doing something very unusual, you let udev load the module
automatically based on its device ID table.

> > > I searched the list archives and found conflicting arguments regarding
> > > the use of update-initramfs after updating /etc/modules or
> > > /etc/modprobe.d/.
> > 
> > /etc/modules is used by the init scripts, not the initramfs.
> > /etc/modprobe.d *does* get copied to the initramfs and I think you're
> > right that update-initramfs should generally be called after it's
> > updated.  Perhaps initramfs-tools should have a file trigger for it,
> > though.
> > 
> 
> I ran some tests, and we definitely do need to update initramfs after
> any changes under /etc/modprobe.d.

Yes, usbhid is included in the initramfs so any options need to be in
there too.

Ben.

-- 
Ben Hutchings
Logic doesn't apply to the real world. - Marvin Minsky


signature.asc
Description: This is a digitally signed message part

Re: Dyson project (Debian on illumos kernel)

[Paul Wise]

On Fri, Sep 14, 2012 at 2:48 AM, Игорь Пашев wrote:

> I think it's time to announce, that I've been working on a new Debian
> port from the last fall.
> This is Debian on illumos kernel (formerly OpenSolaris) - http://osdyson.org

Is your plan to create a Debian derivative or a Debian port to be
integrated into Debian proper?

We already have one of the former based on OpenSolaris/IllumOS:

http://wiki.debian.org/Derivatives/Census/StormOS

Their patches against Debian packages might be helpful to you:

http://dex.alioth.debian.org/census/StormOS/patches/

If you want to make a Debian port instead, your first step would be to
move Dyson to debian-ports.org

You would also need to have license compatibility between your libc
and all the GPLed stuff in Debian.

If you don't intend to create a Debian port, please join the Debian
derivatives census and take a look at our other derivatives stuff:

http://wiki.debian.org/Derivatives
http://wiki.debian.org/DerivativesFrontDesk
http://wiki.debian.org/DerivativesFrontDesk/FAQ
http://wiki.debian.org/Derivatives/Census
http://wiki.debian.org/Derivatives/Guidelines
http://wiki.debian.org/Derivatives/CensusQA
http://wiki.debian.org/Derivatives/Integration

-- 
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: 
http://lists.debian.org/CAKTje6G8U2Vy0roWr9=GxjwJKb-=nvqzge7vkmqshr-x5yv...@mail.gmail.com

Re: "X-" Prefixes deprecated by RFC 6648.

[Christoph Anton Mitterer]

On Wed, 2012-09-12 at 20:59 -0400, Scott Kitterman wrote:
> Anything that's X dash is most likely non-standard.
Of course,... I referred to that other RFCs may still expect the
"experimental" semantics of "X-"


> It can't AIUI, but this is mostly about future usage and not going back and 
> creating a lot of namespace churn.
I just quickly read over the RFC, but it seemed to be doing just that?!


On Thu, 2012-09-13 at 10:18 +0200, Simon Josefsson wrote:
> What RFCs are you thinking of?  The "X-" stuff was removed from e-mail
> standards long time ago, IIRC.
Well I don't have all RFCs in mind,... but weren't there others, that
gave "x-" that meaning for e.g. MIME types or URI schemas?


Cheers,
Chris.


smime.p7s
Description: S/MIME cryptographic signature

Work-needing packages report for Sep 14, 2012

[wnpp]

The following is a listing of packages for which help has been requested
through the WNPP (Work-Needing and Prospective Packages) system in the
last week.

Total number of orphaned packages: 457 (new: 4)
Total number of packages offered up for adoption: 141 (new: 0)
Total number of packages requested help for: 66 (new: 0)

Please refer to http://www.debian.org/devel/wnpp/ for more information.



The following packages have been orphaned:

   arpwatch (#686996), orphaned 5 days ago
 Description: Ethernet/FDDI station activity monitor
 Installations reported by Popcon: 1067

   boxes (#686997), orphaned 5 days ago
 Description: Textmode box- and comment drawing filter
 Installations reported by Popcon: 212

   whowatch (#686999), orphaned 5 days ago
 Description: Real-time user logins monitoring tool
 Installations reported by Popcon: 392

   xfingerd (#686998), orphaned 5 days ago
 Description: BSD-like finger daemon with qmail support
 Installations reported by Popcon: 10

453 older packages have been omitted from this listing, see
http://www.debian.org/devel/wnpp/orphaned for a complete list.



No new packages have been given up for adoption, but a total of 141 packages
are awaiting adoption.  See http://www.debian.org/devel/wnpp/rfa_bypackage
for a complete list.



For the following packages help is requested:

   apt-xapian-index (#567955), requested 955 days ago
 Description: maintenance tools for a Xapian index of Debian packages
 Installations reported by Popcon: 56351

   asymptote (#517342), requested 1294 days ago
 Description: script-based vector graphics language inspired by
   MetaPost
 Installations reported by Popcon: 3172

   athcool (#278442), requested 2879 days ago
 Description: Enable powersaving mode for Athlon/Duron processors
 Installations reported by Popcon: 76

   balsa (#642906), requested 354 days ago
 Description: An e-mail client for GNOME
 Installations reported by Popcon: 253

   bastille (#592137), requested 768 days ago
 Description: Security hardening tool
 Installations reported by Popcon: 198

   boinc (#511243), requested 1344 days ago
 Description: BOINC distributed computing
 Installations reported by Popcon: 1655

   cardstories (#624100), requested 507 days ago
 Description: Find out a card using a sentence made up by another
   player
 Installations reported by Popcon: 7

   chromium-browser (#583826), requested 837 days ago
 Description: Chromium browser
 Installations reported by Popcon: 10390

   debtags (#567954), requested 955 days ago
 Description: Enables support for package tags
 Installations reported by Popcon: 2507

   doc-central (#566364), requested 964 days ago
 Description: web-based documentation browser
 Installations reported by Popcon: 194

   elvis (#432298), requested 1893 days ago
 Description: powerful clone of the vi/ex text editor (with X11
   support)
 Installations reported by Popcon: 352

   fbcat (#565156), requested 974 days ago
 Description: framebuffer grabber
 Installations reported by Popcon: 141

   flightgear (#487388), requested 1545 days ago
 Description: Flight Gear Flight Simulator
 Installations reported by Popcon: 818

   freeipmi (#628062), requested 476 days ago
 Description: GNU implementation of the IPMI protocol
 Installations reported by Popcon: 1853

   gnat-4.4 (#539633), requested 1612 days ago
 Description: backport bug fixes from trunk (GCC 4.5)
 Installations reported by Popcon: 1624

   gnat-gps (#496905), requested 1477 days ago
 Description: co-maintainer needed
 Installations reported by Popcon: 415

   gnokii (#677750), requested 89 days ago
 Description: Datasuite for mobile phone management
 Installations reported by Popcon: 2358

   gnupg (#660685), requested 206 days ago
 Description: GNU privacy guard - a free PGP replacement
 Installations reported by Popcon: 123818

   golang (#668870), requested 151 days ago
 Description: Go programming language compiler - metapackage
 Installations reported by Popcon: 294

   gpa (#663405), requested 187 days ago
 Description: GNU Privacy Assistant (GPA)
 Installations reported by Popcon: 510

   gradle (#683666), requested 42 days ago
 Description: Groovy based build system
 Installations reported by Popcon: 33

   grub2 (#248397), requested 3048 days ago
 Description: GRand Unified Bootloader
 Installations reported by Popcon: 114802

   hfsprogs (#557892), requested 1023 days ago
 Description: mkfs and fsck for HFS and HFS+ file systems
 Installations reported by Popcon: 1212

   horde4 (#686007), requested 17 days ago

Re: Dyson project (Debian on illumos kernel)

[Paul Wise]

On Fri, Sep 14, 2012 at 2:48 AM, Игорь Пашев wrote:

> I think it's time to announce, that I've been working on a new Debian
> port from the last fall.
> This is Debian on illumos kernel (formerly OpenSolaris) - http://osdyson.org

I forgot to mention this site, perhaps their stuff will help you:

http://csclub.uwaterloo.ca/~dtbartle/opensolaris/

-- 
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: 
http://lists.debian.org/CAKTje6FY4Am4=jXjNfVyRTxYUH15rfFrgDbh2XQVo4H=jr-...@mail.gmail.com