Re: can we (fully) fix/integrate NetworkManager (preferred) or release-goal its decommissioning

[Josselin Mouette]

Le jeudi 30 août 2012 à 22:19 +0200, Wouter Verhelst a écrit : 
> On Fri, Aug 24, 2012 at 10:44:11AM +0200, Andrew Shadura wrote:
> > How do you suppose it's possible to undo arbitrary network
> > configuration done by arbitrary set of tools when there's no central
> > place to hold such information (and can't possibly be)?
> 
> Actually, the kernel holds that information. Any tool can just query the
> kernel for information, and decide what to do with what's returned.

Yes it does, but does it hold it in a meaningful, structured way? In
complex setups, for example, there might be no certain way to say which
interface is related to which route. Or to tell which low-level
interface another interface depends on (think tunnels managed by
userland tools).

Actually if there was at least a *standard*, low-level (or in-kernel)
tool to return structured information about the current network
configuration, maybe high-level network tools (such as ifupdown and NM)
could be redesigned in a completely different, much more compatible,
way.

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


--
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/1346399787.3479.451.camel@pi0307572

Re: Bug#684396: ITP: openrc -- alternative boot mechanism that manages the services, startup and shutdown of a host

[Josselin Mouette]

Le vendredi 31 août 2012 à 04:18 +0300, Serge a écrit : 
> 2012/8/10 Josselin Mouette wrote:
> > Because being able to choose between alternatives for core features such
> > as the init system only brings more bugs and no added value.
> 
> Sorry, I don't understand this point.
> 
> If it's about just adding more bugs without bringing anything good
> with it — sure, it's a bad idea.

It is exactly what init system multiplication is about.

> But as long as:
> 1. It breaks nothing for existing installations (i.e. does not
> change defaults, 

That is already far-stretched.

> does not break existing custom scripts,

This is even more far-stretched.

> even
> is not installed by default)
> 2. It has something, that is not provided by other packages,
> meaning, it makes someone happy. (!)

Kitten pictures make me happy. Can we ship them too?

> 3. There's someone willing to maintain it and fix the bugs.

That means there is someone who will pester other maintainers to “fix”
their init scripts so that they work with another half-baked init
implementation.

> PS: IMHO, saying things like "Linux is not about choice" and
> "Debian is not about being universal" just scares maintainers
> and users away from debian, and brings nothing good instead.

If you’re scared by hearing that Linux is not about choice, let me say
it again: Linux is not about choice. Not about choice. Choice is not
inherently good. Linux is not about choice. Booh.

As for Debian not being universal, this is certainly not my saying. But
toy ports and toy init systems are part of what makes Debian less
universal: being the universal OS doesn’t mean accepting every piece of
shit, it means being able to answer every user need. Adding more choice
always brings more bugs, but it does not, by far, always answer to more
user needs.

One good init system can answer all our needs, while four bad ones will
certainly not.

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


--
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/1346399420.3479.446.camel@pi0307572

Re: Stuff from /bin, /sbin, /lib depending on /usr/lib libraries

[Simon McVittie]

On 31/08/12 04:39, Serge wrote:
> thus it reduces flexibility, breaking use cases, that were working before.

Please name them. "The ability to mount my /usr requires user
interaction via a UI in /usr" doesn't count, because it has never
worked, and is logically impossible.

> For example if filesystem is supposed to be network-mounted, and network is
> brought by the user, which logs into GNOME session and manually selects wifi
> connection in nm-applet, initramfs still does not help there, since you
> can't put entire gnome session into initramfs anyway.

If user interaction is required before you can mount enough filesystems
to interact with the user, then your configuration can't work; but
that's not a regression, because it can't work now either. Debian is
pretty flexible, but we can't do the impossible.

If a filesystem is not on the critical path to boot to the point where
you can get the prerequisites for mounting filesystems, you don't need
to mount it from the initramfs. (For instance, /srv isn't needed until
later.)

S


-- 
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/50407d01.5080...@debian.org

Bug#686334: ITP: php-yubico -- PHP PEAR module for verifying Yubico YubiKey One-Time Passwords

[Klas Lindfors]

Package: wnpp
Severity: wishlist
Owner: Klas Lindfors 

* Package name: php-yubico
  Version : 2.4
  Upstream Author : Yubico Open Source Maintainers 
* URL : http://code.google.com/p/php-yubico/
* License : BSD-2-clause
  Programming Lang: PHP
  Description : PHP PEAR module for verifying Yubico YubiKey One-Time 
Passwords

The YubiKey is an USB HID devices that act like keyboards and generate
one-time passwords (OTPs).

This PHP module is used for talking to an online validation server
that implements the YK-VAL protocol, such as Yubico's YubiCloud or a
locally installed server.


-- 
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/20120831085420.3102.63631.report...@debian.lan

Re: Stuff from /bin, /sbin, /lib depending on /usr/lib libraries

[Thomas Goirand]

On 08/31/2012 11:39 AM, Serge wrote:
> Many (most?) major successes in IT history were about inventing a good
> standard communication interface to do things. IBM PC was successful
> because it could be assembled from standard easily accessible components,
> and was easy to upgrade by just replacing those components with newer
> ones. That worked so good because there were standard interfaces for
> devices (ISA, PCI, AGP, etc).
>   

This is quite off topic, but I don't think that's the reason. The reason why
the PC platform won was because both Comodore and Atari failed because
of stupid decisions. They were largely superior platforms at the time (both
software and hardware) though, and a way cheaper.

> I suggest:
> 1. Define (implicitly or explicitly) where we would allow to mount subroot
> filesystems from (that decision mainly affects /usr and partially /var,
> /home and others) and what tools are needed to do that.
> 2. Make sure that all the tools from #1 are on / partition.
> 3. Make sure that everything required for `root` user to login (and do basic
> stuff, i.e. move files, read logs and edit scripts) is on / partition.
> 4. Don't move anything else around — unless it fixes something,
> it will just add more bugs and more problems for users

You don't need to suggest that, it has been rules inside Debian for years,
and I believe (almost) everyone understands it.

It's just that some would like to change these rules, and others are
resisting.

Thomas


--
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/5040833b.60...@debian.org

Re: Discussion of uscan enhancement 1 (Was: uscan enhancement take 3: script hook)

[Jonas Smedegaard]

On 12-08-31 at 03:38am, Nicolas Boulenguez wrote:
> (apologizes for the previous empty mail)
> 
> On Thu, Aug 30, 2012 at 11:44:34PM +0200, Andreas Tille wrote:
> > On Thu, Aug 30, 2012 at 02:32:56AM +0200, Nicolas Boulenguez wrote:
> 
> > > Assume that "a" and "b" are directories, if I understand well, the 
> > > current behaviour is to recursively remove "a/b/", "a/b" and "a/" 
> > > but to ignore "a". I do not find that intuitive, and would suggest 
> > > to document it clearly.
> 
> > Could you suggest a wording which fits the requirement of "clearly 
> > documented".
> 
> Here is the meaning of Files-Excluded patterns, as I understand from 
> the perl code at 
> http://anonscm.debian.org/gitweb/?p=users/tille/devscripts.git;a=blob;f=scripts/uscan.pl;hb=bb686d032543d8ba8c5cd9c36ff8c2d9c3310761#l1493
> 
>  If $pattern contains no slash, then
>   (A) execute `find "$main_source_dir" -type f -name "$pattern" -delete`
>That is, remove all *files* in all subdirectories whose *base name* match.
>  Else
>   (B) remove the trailing slash from $pattern, if present
>   (C) execute `find "$main_source_dir" -path "$main_source_dir/$pattern"
>-print0 | xargs -0 rm -rf`
>That is, remove all *files or subdirectories* whose *full path* match.
> 
> Jonas says that this imitates Files patterns, but
> http://dep.debian.net/deps/dep5/#files-field mentions
> 
>  Patterns match pathnames that start at the root of the source tree.
>  Thus, "Makefile.in" matches only the file at the root of the tree,
>  but "*/Makefile.in" matches at any depth.
> 
> I understand that matching depends only on the existence of the path,
> not on it being a file or a directory. So
> - "foo" should match "foo", even if a directory.
> - "foo" should not match "bar/foo", even if a file.
> - "foo/" should never match, even if "foo" is a directory.
> In short, I would only expect (C) as the implementation.
> 
> > It is required that there is distinction between files and
> > directories (see the discussion on debian-devel, for instance [1] and
> > [2]).
> > [1] http://lists.debian.org/debian-devel/2012/08/msg00512.html
> > [2] http://lists.debian.org/debian-devel/2012/08/msg00449.html
> 
> In [2], Jonas says "I believe it is better to...", but does not
> explain why.
> 
> >  If I would feed 'a' to the removal algorithm it could simply
> > happen, that a file c/a would be removed as well but it should not.
> 
> With (C), the "a" pattern will not remove the "c/a" file.

Hmm.  Seems my head was stock in a too old draft of DEP-5 - or 
completely off track.  Sorry!

I'll step back and let others figure out wat is proper interpretation.


 - 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: Digital signature

Re: Stuff from /bin, /sbin, /lib depending on /usr/lib libraries

[Thomas Goirand]

On 08/31/2012 03:39 AM, Steve Langasek wrote:
> It only requires us to ensure /usr is mounted before
> init is started.
>   

Which I don't think is a good idea.

>  - /usr on a separate filesystem without the use of an initramfs: not
>supported... and no discernable user demand for this.
>   

Well, let's say I have a big crash, and I want to recover, and I
need to access /etc/lvm/archive in a single user, with of course
my /usr in a bad state, and I wouldn't be able to mount it for
various reasons. Let's say, an HDD crash, which is very common.

If I need to have /usr mounted before init starts, then I'm more
or less dead, and I'll have to get a recovery CD / USB.

If I don't need /usr, everything is fine, I can boot into single
user mode, and repair.

Guess which situation I prefer?

Now, you tell me: what are the advantage of requiring having
everything in /usr exactly? I really don't get what the advantage is.

On 08/31/2012 03:39 AM, Steve Langasek wrote:
> However, I struggled to formulate a concrete
> scenario where losing support for that last configuration would actually
> make a difference.
>   

You must have not read some of my posts then.

> No one in the various threads on debian-devel has presented such a scenario.
> They've all been arguing the straw man that "/usr as a separate fs is not
> supported", which is not what's on the table.
>   

Ditto. We did give concrete examples were recovery would be
harder with things in /usr rather than in /.

Also, please make the point into why having stuff in /usr is
to be preferred. Or is it that the *only* argument that you
have is that we are polluted by RedHat crap? If so, why
shouldn't we consider switching to an alternative of udev
like mdev, if its development goes on the right direction,
for Jessie?

Thomas


-- 
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/50408642.20...@debian.org

Bug#686339: ITP: python-wherigo -- python module for creating a wherigo player

[Bas Wijnen]

Package: wnpp
Severity: wishlist
Owner: Bas Wijnen 

* Package name: python-wherigo
  Version : 0.1
  Upstream Author : Bas Wijnen 
* URL : https://github.com/wijnen/python-wherigo
* License : AGPL-3+
  Programming Lang: Python
  Description : python module for creating a wherigo player

Wherigo cartridges are real-world adventure games, which require the user to
move with their legs instead of their keys. This module implements the logic
that a cartridge needs, except the interface. It can be used to create a
player program, or embed wherigo playing into a larger program.


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

Re: Stuff from /bin, /sbin, /lib depending on /usr/lib libraries

[Timo Juhani Lindfors]

Thomas Goirand  writes:
> If I need to have /usr mounted before init starts, then I'm more
> or less dead, and I'll have to get a recovery CD / USB.

Not completely. Just boot with break=premount and read /etc/lvm from the
initramfs shell. I've done this several times. The cool part is that you
can also start networking and netcat stuff to/from the machine that
needs to be recovered.


-- 
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/84pq6775gs@sauna.l.org

Re: Stuff from /bin, /sbin, /lib depending on /usr/lib libraries

[John Paul Adrian Glaubitz]

On Aug 31, 2012, at 11:26 AM, Thomas Goirand  wrote:

> On 08/31/2012 11:39 AM, Serge wrote:
>> Many (most?) major successes in IT history were about inventing a good
>> standard communication interface to do things. IBM PC was successful
>> because it could be assembled from standard easily accessible components,
>> and was easy to upgrade by just replacing those components with newer
>> ones. That worked so good because there were standard interfaces for
>> devices (ISA, PCI, AGP, etc).
>> 
> 
> This is quite off topic, but I don't think that's the reason. The reason why
> the PC platform won was because both Comodore and Atari failed because
> of stupid decisions. They were largely superior platforms at the time (both
> software and hardware) though, and a way cheaper.

Yes :(. Commodore died because their management was utter crap.

They basically killed every successful product they had (like the A500) and 
replaced them with ones that didn't sell well.

Plus they were stupid enough to let a huge business deal with Sun break who 
wanted to license Amigas as low-end Unix workstations.

Adrian

--
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/10d23b43-12ce-4ddb-9d50-4db5da90e...@physik.fu-berlin.de

Re: Bug#684396: ITP: openrc -- alternative boot mechanism that manages the services, startup and shutdown of a host

[John Paul Adrian Glaubitz]

On Aug 31, 2012, at 9:50 AM, Josselin Mouette  wrote:

> One good init system can answer all our needs, while four bad ones will
> certainly not.

I fully agree.

The init system is a critical part of the operating system, so we shouldn't be 
messing around with it. Focus on the best solution, period.

95% of the users don't ever interact with the init system directly, so there is 
no point in being able to have a choice here as long as we make sure we're 
using the best solution. Please don't argue that there are also dozens of 
editors or window managers available, you can't compare these. Both are way 
more visible to the user, so it's natural to be able to choose here.

While many people will disagree, I am convinced that systemd is the way to go. 
It is very fast, reliable and profits from modern hardware like SSDs or modern 
kernel features like cgroups.

Yes, systemd would break the non-Linux kernels, but we could use the 
units-to-sysV converter to solve this problem in a painless fashion.

Adrian

--
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/f37b32a1-c915-4f40-9908-cb2858d3c...@physik.fu-berlin.de

Re: [php-maint] Bug#670945: Bug#670945: Bug#670945: About the media types text/x-php and text/x-php-source

[Christoph Anton Mitterer]

On Thu, 2012-08-30 at 00:16 +0200, Christoph Anton Mitterer wrote:
> RewriteCond "%{REQUEST_FILENAME}" !-f
> RewriteCond "%{REQUEST_FILENAME}" !-d
> RewriteRule "^(.*)$" "$1.php" [last]

Tried them out in the meantime.

Seem to work as expected.


Cheers,
CHris.


smime.p7s
Description: S/MIME cryptographic signature

Re: About the media types text/x-php and text/x-php-source

[Vincent Lefevre]

On 2012-08-28 18:03:02 +0200, Christoph Anton Mitterer wrote:
> On Tue, 2012-08-28 at 15:37 +0100, Ian Jackson wrote:
> > > Then if there is a charset parameter, with a value that refers to
> > > some known text character set, I think that one can assume that
> > > the contents are encoded with this charset, thus can be displayed
> > > as text.
> > I don't think that follows at all.  It might just mean that the text
> > in (say) the zipfile filenames is in whatever charset is specified.
> 
> I agree... the charset parameter does not necessarily imply that one has
> plain text.
> At least for HTTP it's not defined (at least not int RFC 2616) how the
> charset= parameter is to be interpreted, and thus Ian's example is
> absolutely valid.

Concerning the interpretation of the charset= parameter, RFC 2616
doesn't seem to make a difference between text/* media types and
the other ones (the only difference seems to be the default). So,
with this point of view, conversion from bytes to characters may
also be incorrect for unknown text/* media types.

But I'd say that RFC 2616 is rather ambiguous. You can see a problem
that occurred in practice:

  https://github.com/edicl/hunchentoot/issues/1

-- 
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: http://lists.debian.org/20120831110021.gn19...@xvii.vinc17.org

Re: Stuff from /bin, /sbin, /lib depending on /usr/lib libraries

[Riku Voipio]

On Fri, Aug 31, 2012 at 05:39:14PM +0800, Thomas Goirand wrote:
> On 08/31/2012 03:39 AM, Steve Langasek wrote:
> >  - /usr on a separate filesystem without the use of an initramfs: not
> >supported... and no discernable user demand for this.

> Well, let's say I have a big crash, and I want to recover, and I
> need to access /etc/lvm/archive in a single user, with of course
> my /usr in a bad state, and I wouldn't be able to mount it for
> various reasons. Let's say, an HDD crash, which is very common.
 
> If I need to have /usr mounted before init starts, then I'm more
> or less dead, and I'll have to get a recovery CD / USB.

How is that different from having a botched / or /boot ? Why do you
think having a separate /usr will make / less prone to HD crashes?
You have / on RAID5 while /usr isn't?

Anyways maintaining a good recovery CD / USB is more worthwile than
keeping supporting a hard drive partitioning scheme that doesn't really
add value for users anymore.

> Now, you tell me: what are the advantage of requiring having
> everything in /usr exactly? I really don't get what the advantage is.

The main advantage is that we wouldn't be having this mail thread.

As there would be no need to ensure there is no dependencies from
/{lib,bin,sbin} to /usr, we wouldn't have the maintainer overhead
and chatter on debian-devel of trying to fix those issues.

Riku


-- 
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/20120831105538.ga18...@afflict.kos.to

Re: Stuff from /bin, /sbin, /lib depending on /usr/lib libraries

[Marco d'Itri]

On Aug 31, Thomas Goirand  wrote:

> If I need to have /usr mounted before init starts, then I'm more
> or less dead, and I'll have to get a recovery CD / USB.
If this is a concern to you, you can install the grml-rescueboot 
package and/or a similar on-disk rescue image which will provide you 
with a complete rescue environment.

> If I don't need /usr, everything is fine, I can boot into single
> user mode, and repair.
In some case you can, in some others you cannot.
But if you have a complete bootable rescue environment, which if 
slightly tuned is going to be as big as one or two initramfs (IOW, 
trivially small), then you are safe against any kind of crashes.

> Now, you tell me: what are the advantage of requiring having
> everything in /usr exactly? I really don't get what the advantage is.
I am not going to argue about this again right now.

-- 
ciao,
Marco


signature.asc
Description: Digital signature

Re: Stuff from /bin, /sbin, /lib depending on /usr/lib libraries

[Thomas Goirand]

On 08/31/2012 06:55 PM, Riku Voipio wrote:
> How is that different from having a botched / or /boot ? Why do you
> think having a separate /usr will make / less prone to HD crashes?
> You have / on RAID5 while /usr isn't?
>   

Typically, I have / on 2 small RAID1 partitions making the array on the
first
2 HDD (1 or 2 gigs), and /usr on a LVM on a much, much larger RAID array
(I use mostly software RAID1 and RAID10, but in some cases, much bigger
hardware RAID5). So yes, that's my usual server setup.

Also, / is a partition on which almost nothing is read or written, while
the others (eg: /usr, /var, /tmp, swap) are a lot more I/O intensive.
Which means that / is less prone to failure. Often, the 2nd RAID
array gets degraded, but / isn't. So it does make a lot of sense to
setup things this way, and yes, / is less prone to HD crashes this
way (I'm talking from 10 years of experience running about 100
servers this way, so it's not just theory, it's very practical experience).

> Anyways maintaining a good recovery CD / USB is more worthwile than
> keeping supporting a hard drive partitioning scheme that doesn't really
> add value for users anymore.
>   

It does add value, as per above.

I'll keep in mind Marco's suggestion of grml-rescueboot which I didn't
know and try in the next following days, it looks cool!

Thomas


-- 
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/5040d0c6.4040...@debian.org

Re: Stuff from /bin, /sbin, /lib depending on /usr/lib libraries

[Jon Dowland]

On Fri, Aug 31, 2012 at 10:57:10PM +0800, Thomas Goirand wrote:
> On 08/31/2012 06:55 PM, Riku Voipio wrote:
> > How is that different from having a botched / or /boot ? Why do you
> > think having a separate /usr will make / less prone to HD crashes?
> > You have / on RAID5 while /usr isn't?
> >   
> 
> Typically, I have / on 2 small RAID1 partitions making the array on the
> first
> 2 HDD (1 or 2 gigs), and /usr on a LVM on a much, much larger RAID array
> (I use mostly software RAID1 and RAID10, but in some cases, much bigger
> hardware RAID5). So yes, that's my usual server setup.
> 
> Also, / is a partition on which almost nothing is read or written, while
> the others (eg: /usr, /var, /tmp, swap) are a lot more I/O intensive.
> Which means that / is less prone to failure. Often, the 2nd RAID
> array gets degraded, but / isn't. So it does make a lot of sense to
> setup things this way, and yes, / is less prone to HD crashes this
> way (I'm talking from 10 years of experience running about 100
> servers this way, so it's not just theory, it's very practical experience).

I'm struggling to understand this. In the situation you outline (/ ok,
/usr, /var, /tmp, swap on another RAID which is hosed) -- whatever service
the machine was offering is surely not being offered anymore (/ being too
small to be useful for anything except a rescue environment).  So / surviving
whilst all your services/data are dead doesn't seem to be a big win to me at
all. Am I missing a detail?


-- 
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/20120831150447.GD24379@debian

Bug#686357: ITP: python-network -- python module for easy networking

[Bas Wijnen]

Package: wnpp
Severity: wishlist
Owner: Bas Wijnen 

* Package name: python-network
  Version : 0.1
  Upstream Author : Bas Wijnen 
* URL : https://github.com/wijnen/python-network
* License : AGPL-3+
  Programming Lang: Python
  Description : python module for easy networking

Implementing networking in C is a pain. Unfortunately, much of that pain is
copied to Python. This module instead tries to follow the "batteries included"
approach, like the rest of Python. With this module, networking is a piece of
cake. It can use tcp sockets and unix domain sockets, and supports avahi.

This module provides four classes: Socket and Server for string-based
connections, and RPCSocket and RPCServer for connections which call methods on
remote objects. All of this is symmetrical: once the connection is
established, the client and server use the same interface.


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

Re: Stuff from /bin, /sbin, /lib depending on /usr/lib libraries

[Peter Samuelson]

[Thomas Goirand]
> Typically, I have / on 2 small RAID1 partitions making the array on the
> first
> 2 HDD (1 or 2 gigs), and /usr on a LVM on a much, much larger RAID array
> (I use mostly software RAID1 and RAID10, but in some cases, much bigger
> hardware RAID5). So yes, that's my usual server setup.

I guess I can understand that you want your /usr to be resizeable, but
really, life is so much simpler when you just go ahead and create a 12
GB root filesystem (and no separate /usr) and be done with it.  The
days have long passed when that 10 or 11 GB of wasted space was
anything to worry about.

> Also, / is a partition on which almost nothing is read or written,
> while the others (eg: /usr, /var, /tmp, swap) are a lot more I/O
> intensive.  Which means that / is less prone to failure.

I always thought reads were pretty harmless and it's mostly writes you
have to worry about (both for bugs in the OS FS, and for the physical
media).  And both / and /usr should have very few writes,
percentage-wise.

I used to think keeping / fully self-contained was useful.  But it is a
non-zero amount of effort, and I'm becoming convinced that these days,
the separate /usr is going the way of the shared /usr/share.

Peter


-- 
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/20120831155225.gb4...@p12n.org

Re: can we (fully) fix/integrate NetworkManager (preferred) or release-goal its decommissioning

[Ben Hutchings]

On Fri, 2012-08-31 at 09:56 +0200, Josselin Mouette wrote:
> Le jeudi 30 août 2012 à 22:19 +0200, Wouter Verhelst a écrit : 
> > On Fri, Aug 24, 2012 at 10:44:11AM +0200, Andrew Shadura wrote:
> > > How do you suppose it's possible to undo arbitrary network
> > > configuration done by arbitrary set of tools when there's no central
> > > place to hold such information (and can't possibly be)?
> > 
> > Actually, the kernel holds that information. Any tool can just query the
> > kernel for information, and decide what to do with what's returned.
> 
> Yes it does, but does it hold it in a meaningful, structured way? In
> complex setups, for example, there might be no certain way to say which
> interface is related to which route.

I wish you would give an example.

> Or to tell which low-level
> interface another interface depends on (think tunnels managed by
> userland tools).

You're thinking about packet forwarding in userland?

> Actually if there was at least a *standard*, low-level (or in-kernel)
> tool to return structured information about the current network
> configuration, maybe high-level network tools (such as ifupdown and NM)
> could be redesigned in a completely different, much more compatible,
> way.

The kernel API is called rtnetlink (or NETLINK_ROUTE) and NM already
uses it.  Not all device relationships are properly represented through
it yet, but people are working on it.

Ben.

-- 
Ben Hutchings
Theory and practice are closer in theory than in practice.
- John Levine, moderator of comp.compilers


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

Re: Bug#684396: ITP: openrc -- alternative boot mechanism that manages the services, startup and shutdown of a host

[Serge]

2012/8/31 Josselin Mouette wrote:

>>> Because being able to choose between alternatives for core features
>>> such as the init system only brings more bugs and no added value.
>>
>> Sorry, I don't understand this point.
>>
>> If it's about just adding more bugs without bringing anything good
>> with it — sure, it's a bad idea.
>
> It is exactly what init system multiplication is about.

Yeah, one init system, one kernel, one libc, one distribution, one
window manager, one OS. Looks like a windows-way. :)
"640kb ought to be enough for anybody." :)

>> But as long as:
>> 1. It breaks nothing for existing installations (i.e. does not
>> change defaults,
>
> That is already far-stretched.
>
>> does not break existing custom scripts,
>
> This is even more far-stretched.

Not sure I understand you here.

>> even is not installed by default)
>> 2. It has something, that is not provided by other packages,
>> meaning, it makes someone happy. (!)
>
> Kitten pictures make me happy. Can we ship them too?

Sure. I would also like to see a `kitten-wallpapers` package,
if it's free (e.g. CC-BY-SA) of course.

>> 3. There's someone willing to maintain it and fix the bugs.
>
> That means there is someone who will pester other maintainers to “fix”
> their init scripts so that they work with another half-baked init
> implementation.

Not necessary. It's ITP, not RFP. That may mean that there would be someone
who will send patches to other maintainers to fix their init scripts, that
do not obey debian standards. If they do obey standards but still don't
work under openrc then it's a bug either in debian standard or in openrc,
and one of them should be fixed anyway.

> If you’re scared by hearing that Linux is not about choice, let me say
> it again: Linux is not about choice. Not about choice. Choice is not
> inherently good. Linux is not about choice. Booh.

Hm, I use linux exactly because it's about choice. It allows me to do things
that no other system does. In linux I can choose those things that suit me
and use them. POSIX allows me to choose kernel and libc. XDG and X11 allows
me to choose desktop environment. HTTP RFC allows me to choose the best
webserver and best browser. Lots of programs in repository allows be to
choose the best program that suits me. If I still miss some feature that I'd
chose, GPL allows me to patch the sources and get the feature I've chosen.

Do you use Linux? Why? Because it's cheap?

Linux is still not about choice? Then let's make it be about choice!

> As for Debian not being universal, this is certainly not my saying.
> But toy ports and toy init systems are part of what makes Debian less
> universal: being the universal OS doesn’t mean accepting every piece
> of shit, it means being able to answer every user need.

So, if user needs to see something in debian repository then being
universal means having it in repository. :)

> Adding more choice always brings more bugs, but it does not,
> by far, always answer to more user needs.

Agree. That's #2 of my 3 points. If nobody really needs it, meaning,
if nobody asked for it, and it does not make anyone happy, there's
no need to spend time on it. Does openrc make anyone happy?

But if it has some advantages over existing systems, it at least deserves
the right to be chosen by those who needs those advantages.

> One good init system can answer all our needs, while four bad ones will
> certainly not.

What if that good init system is openrc?

-- 
  Serge


--
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/CAOVenEr4-5q=sb8unrqo3gwfute7xumih_0x8dbqknwnxzw...@mail.gmail.com

Re: Bug#684396: ITP: openrc -- alternative boot mechanism that manages the services, startup and shutdown of a host

[Serge]

2012/8/31 John Paul Adrian Glaubitz wrote:

> The init system is a critical part of the operating system, so we
> shouldn't be messing around with it. Focus on the best solution,
> period.

It's often someone says something similar about many ITPs. I believe noone
should say things like that, unless he wants to scare everybody away and
have Debian forgotten and dead. Saying that you not only reduce the number
of bugs in Debian, but you also reduce the number of people working on
Debian, because when they hear that they just turn around and go away.

If I was an employee of Debian Inc, and I was paid to spend my 40 hours/week
to my company, then you could tell me "don't mess around openrc, focus on
upstart, that's a chief's order" (that may work for RedHat). But Debian
does not pay me, and noone can tell me what to do.

When I come and say "Hey, I want to work on openrc in debian" (replace
"openrc" with any other package), I mean what I say. Most probably I just
like this particular software for some reason. And it usually never means
that I also want to work on upstart/systemd/sysvinit/etc. So when you tell
me "don't mess around it", I won't drop openrc, I'll just drop debian.

You can only politely ask "Please, before continuing to work on openrc,
look at other init systems, maybe you will find there what you need, or
maybe it would be easier for you to implement the features you need in
those systems instead of maintaining a new init system on your own". But
you can't say me what should I do, because I'll just go to Arch/Gentoo,
that are not as hostile.

If we want debian to be a successful and popular distribution, we should
welcome everybody, does not matter what they want to work on. That should
bring more people to debian. And we want more people to work on debian,
don't we? We must help them to work on it, and just hope, that some day
they will also help us to work on our projects too. That's IMHO, of course.

> 95% of the users don't ever interact with the init system directly, so
> there is no point in being able to have a choice

Bad argument. :) 95% of the users don't even know what Linux is (it's just
a kernel, you know) and they certainly don't interact with it directly.
But it does not mean that we can forget about linux and never allow
people to choose it. :)

-- 
  Serge


-- 
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/CAOVenEpJT63OYbPRtzZcDyk7XkZhi=1vn8sd0tnqd7gv9pf...@mail.gmail.com

Bug#686380: ITP: asn1c -- ASN.1 compiler for C

[Eugene Seliverstov]

Package: wnpp
Severity: wishlist
Owner: Eugene Seliverstov 

* Package name: asn1c
  Version : 0.9.21
  Upstream Author : Lev Walkin 
* URL : http://asn1c.sourceforge.net
* License : BSD
  Programming Lang: C
  Description : ASN.1 compiler for C

This ASN.1 compiler turns the formal ASN.1 specifications into the C
code. The compiler is shipped together with conformant BER/DER/XER
codecs. The X.509 and GSM TAP3 decoding examples are shipped as well.

A package asn1c is maintained by W. Martin Borgert .
After "O" call adopters were not found and the package was removed from
testing/unstable. Not sure if it is possible to adopt a removed package.
I can help in maintaing asn1c or try to maintain it myself.

Thank you for attention.


-- 
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/20120831174331.27081.98538.reportbug@baryon

Re: Stuff from /bin, /sbin, /lib depending on /usr/lib libraries

[Thomas Goirand]

On 08/31/2012 11:04 PM, Jon Dowland wrote:
> I'm struggling to understand this. In the situation you outline (/ ok,
> /usr, /var, /tmp, swap on another RAID which is hosed) -- whatever service
> the machine was offering is surely not being offered anymore (/ being too
> small to be useful for anything except a rescue environment).  So / surviving
> whilst all your services/data are dead doesn't seem to be a big win to me at
> all. Am I missing a detail?
>   
The rootfs contains all the configuration (eg: /etc), and stuff
like /etc/lvm/archive/, RAID UUID, and all sorts of things which
are vital if you want to have any chance of recovering the rest
(eg: your data hosted in /var).

Thomas


-- 
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/5040ffaa.7030...@debian.org

Re: can we (fully) fix/integrate NetworkManager (preferred) or release-goal its decommissioning

[Serge]

2012/8/30 Wouter Verhelst wrote:

>> How do you suppose it's possible to undo arbitrary network
>> configuration done by arbitrary set of tools when there's no central
>> place to hold such information (and can't possibly be)?
>
> Actually, the kernel holds that information. Any tool can just query the
> kernel for information, and decide what to do with what's returned.

Not sure. Will it work for user-space configuration too? I.e. `ifdown`
may have have to stop `dhclient` and `wpa_supplicanf`. Is it possible
to detect such cases automatically?

-- 
  Serge


-- 
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/caoveneqgmo76fz-ccrpnc0rmi5hdcy7tkr6qs+h0ssknxmr...@mail.gmail.com

Re: Stuff from /bin, /sbin, /lib depending on /usr/lib libraries

[Thomas Goirand]

On 08/31/2012 11:52 PM, Peter Samuelson wrote:
> I guess I can understand that you want your /usr to be resizeable

Not only this. I want it on a RAID10 or RAID5 which goes faster than
my / that is hosted in a slower RAID1.

> but
> really, life is so much simpler when you just go ahead and create a 12
> GB root filesystem (and no separate /usr) and be done with it.

Maybe more simple, but then I will loose the advantages that I
already explained. And more importantly: I don't care simple.

> The
> days have long passed when that 10 or 11 GB of wasted space was
> anything to worry about.
>   

This has nothing to do with the amount of space.
But if you want to go on that ground...

Today, you say 10GB. What about in 5 years? Can
you easily predict what will be my needs? I don't.

> I always thought reads were pretty harmless and it's mostly writes you
> have to worry about (both for bugs in the OS FS, and for the physical
> media).  And both / and /usr should have very few writes,
> percentage-wise.
>   

It depends what you do, I'd say. But yes of course, you'd have very few,
and even maybe zero once the system is setup, writes on /usr. But if
your computer has a lot of activities taking a lot of RAM, chances are
that stuff will be kicked out of the cache and get read again.

> I used to think keeping / fully self-contained was useful.  But it is a
> non-zero amount of effort, and I'm becoming convinced that these days,
> the separate /usr is going the way of the shared /usr/share.
>
> Peter
>   

Isn't it because you are just becoming a bit lazy? :)

You could also have tell me to use just one single partition, and
that having a separate /tmp, /var and so on totally useless too.
We could argue as well during huge threads about it. :)

Thomas


-- 
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/50410280.4030...@debian.org

Re: [b-d][falla] acl2

[Julien Cristau]

On Thu, Aug 30, 2012 at 15:23:53 -0400, Camm Maguire wrote:

> Greetings!
> 
> Stephen Gran  writes:
> 
> > Why not add logging to the Makefile, or cat debian/mini-proveall.out or
> > something?  This doesn't look like a dead end to me.
> >
> 
> Thanks so much for your suggestion!  Can uploads instruct all
> autobuilders but for a single arch to ignore the package?  The build is
> very intensive.

Upload to experimental, with

build:
ifeq ($(DEB_BUILD_ARCH), foo)
do_something
else
# don't bother
exit 1
endif

in debian/rules.

Cheers,
Julien


signature.asc
Description: Digital signature

Re: Bug#683666: RFH: gradle -- Groovy based build system

[Damien Raude-Morvan]

Le jeudi 02 août 2012 18:26:44, Miguel Landaeta a écrit :
> I request assistance with maintaining the gradle package.

JFTR, I had a private discussion with Miguel and we will co-maintain Gradle. 
I'm working on new upstream release (which, sadly, won't work for Wheezy 
because of needed dependencies).

Cheers,
-- 
Damien


--
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/201208312035.49460.draz...@drazzib.com

Re: can we (fully) fix/integrate NetworkManager (preferred) or release-goal its decommissioning

[Serge]

2012/8/28 Ben Hutchings wrote:

>> It should not be that hard to fit them all.
>>
>> All connections I can think of belong to one of two categories:
>> 1. Permanent connections. Those are "setup-and-forget" connections.
>> Typical for servers and wired desktops. Can be managed with ifupdown.
>> 2. Temporary connections. Those are "use-once-and-forget" connections
>> (e.g. wifi in airport/hotel). Typical for mobile/moveable devices.
>> They're different from #1 because they should not be stored in configs.
> [...]
>
> I don't think there is this hard line between 'permanent' and
> 'temporary' connections.

It depends on what one calls "permanent".

It was just about whether it's possible to write a tool to please
everybody. And I was thinking how to do that. I suggested to split
all connections into two categories: "permanent" (stored in confis,
i.e. "setup-and-forget") and "temporary" (not stored in configs, i.e.
"use-once-and-forget"). Maybe I chose ambiguous names for those
categories, feel free to suggest any better. :)

There're also two interface types: CLI and GUI.
So that would be 4 ways to make a connection:
1.a. Permanent-CLI (ifupdown or a shell-script)
1.b. Permanent-GUI (NetworkManager)
2.a. Temporary-CLI (shell)
2.b. Temporary-GUI (NetworkManager)

None of tools support all 4 points good enough _yet_, that's why none
of them suits everybody. What I was trying to say is that it's still
possible to extend any of them to "fit them all", somebody just need
to extend it to support all 4 kinds.

Such tool, if existed, should please everybody. :)

> Hotel wifi certainly isn't 'use-once-and-forget'. I should be able to
> configure it when I arrive and have it remembered as long as I stay.

It does not matter how often you use it. It's just whether you store
it in configs (that's what I called "permanent") or not ("temporary").

> There are several other categories of dynamic connections, including:
> 3. VPN tunnels (server end)
> 4. Connections to a VM
>
> Most likely these should not be managed by either ifupdown or NM.

Not currently, right. But if someone could extend some of them to
support these, why not? Imagine a GUI/TUI (winetricks-like) front-end
for ifupdown, that allows you to configure VPN with a few simple
dialogs and store basic configs in /etc. :) If only someone wrote it...

-- 
  Serge


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

Re: Bug#684396: ITP: openrc -- alternative boot mechanism that manages the services, startup and shutdown of a host

[Thomas Goirand]

On 08/31/2012 03:50 PM, Josselin Mouette wrote:
> That means there is someone who will pester other maintainers to “fix”
> their init scripts so that they work with another half-baked init
> implementation.
>   

Ah... And that will not happen with systemd? Come on, we all
know that we will have to change stuff archive wide, whatever
decision we take.

> But
> toy ports and toy init systems are part of what makes Debian less
> universal: being the universal OS doesn’t mean accepting every piece of
> shit

I'm not sure what you call "every piece of shit", I just hope this isn't
OpenRC or "toy ports" that you are talking about here.

> One good init system can answer all our needs, while four bad ones will
> certainly not.
>   

I guess this depends what you call "good".

For me, something that imposes on us decisions that are forcing:
- move to /usr and no chances to change this
- configuration files outside /etc just because of internal limitations
of RPM, which goes against our policy manual
- incompatibility with anything else than Linux, and not even
a chance that upstream accept patches to change this

Add this a "hostile upstream", and it becomes more a threat
than an anything else, even if it's technically better and with
more features than any other init system.

Sure, OpenRC doesn't have (yet) all the features of systemd.
But because of the above, it might be worth to *at least* give
it a chance.

Thomas


--
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/504108ed.3030...@debian.org

Re: Bug#684396: ITP: openrc -- alternative boot mechanism that manages the services, startup and shutdown of a host

[John Paul Adrian Glaubitz]

On Fri, Aug 31, 2012 at 08:28:27PM +0300, Serge wrote:
> 
> It's often someone says something similar about many ITPs. I believe noone
> should say things like that, unless he wants to scare everybody away and
> have Debian forgotten and dead. Saying that you not only reduce the number
> of bugs in Debian, but you also reduce the number of people working on
> Debian, because when they hear that they just turn around and go away.

I don't see how these people help Debian if they start pushing their
own solution instead of helping to improve what is already there.

> If I was an employee of Debian Inc, and I was paid to spend my 40 hours/week
> to my company, then you could tell me "don't mess around openrc, focus on
> upstart, that's a chief's order" (that may work for RedHat). But Debian
> does not pay me, and noone can tell me what to do.

Well, yes. Debian has it's policy, a social contract and the DFSG. You
are certainly not allowed to do anything you want unless you start
your own blend of Debian by forking it.

> When I come and say "Hey, I want to work on openrc in debian" (replace
> "openrc" with any other package), I mean what I say. Most probably I just
> like this particular software for some reason. And it usually never means
> that I also want to work on upstart/systemd/sysvinit/etc. So when you tell
> me "don't mess around it", I won't drop openrc, I'll just drop debian.

If that was really the case, how come there are so many orphaned
packages in Debian? I'm not saying I wouldn't trust your words, but
you cannot seriously promise you will always be there to take care of
OpenRC if you're the only maintainer.

> You can only politely ask "Please, before continuing to work on openrc,
> look at other init systems, maybe you will find there what you need, or
> maybe it would be easier for you to implement the features you need in
> those systems instead of maintaining a new init system on your own". But
> you can't say me what should I do, because I'll just go to Arch/Gentoo,
> that are not as hostile.

I don't understand your rage. Debian has always been strict about its
policies, this isn't really new. As Josselin already pointed out,
there are rules and you are not allowed to do what you want. If you
don't agree with that, it's fine. But please don't force this onto Debian.

> If we want debian to be a successful and popular distribution, we should
> welcome everybody, does not matter what they want to work on. That should
> bring more people to debian. And we want more people to work on debian,
> don't we? We must help them to work on it, and just hope, that some day
> they will also help us to work on our projects too. That's IMHO, of course.

Debian is already very popular and successful and I don't see how
OpenRC would help Debian gain more popularity.

> > 95% of the users don't ever interact with the init system directly, so
> > there is no point in being able to have a choice
> 
> Bad argument. :) 95% of the users don't even know what Linux is (it's just
> a kernel, you know) and they certainly don't interact with it directly.
> But it does not mean that we can forget about linux and never allow
> people to choose it. :)

I was actually talking about Linux users, I was not referring to all
people using computers in the world.

My point is, 95% of the people who install a Debian or Ubuntu nowadays
simply don't care what init system they are using as long as the code
is mature and reliable.

Your arguments aren't - at least - convincing me why we should have
OpenRC in Debian. If you really want to convince me and others being
sceptical about OpenRC, then you should list a number of arguments why
OpenRC is actually a good alternative to the existing init systems in
Debian.

There should be at least some compelling technical arguments for
OpenRC. Saying that you don't like systemd or its upstream author
doesn't count, because this isn't something which affects end users.

A valid argument in favor of OpenRC and against systemd is certainly
that the former is platform-agnostic. But I think that the non-Linux
ports of Debian aren't (yet) important enough to weigh strong enough
in such decisions.

Cheers,

Adrian


-- 
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/20120831200609.ga16...@physik.fu-berlin.de

Re: Bug#686357: ITP: python-network -- python module for easy networking

[Nikolaus Rath]

Bas Wijnen  writes:
> Package: wnpp
> Severity: wishlist
> Owner: Bas Wijnen 
>
> * Package name: python-network
>   Version : 0.1
>   Upstream Author : Bas Wijnen 
> * URL : https://github.com/wijnen/python-network
> * License : AGPL-3+
>   Programming Lang: Python
>   Description : python module for easy networking
>
> Implementing networking in C is a pain. Unfortunately, much of that pain is
> copied to Python. This module instead tries to follow the "batteries included"
> approach, like the rest of Python. With this module, networking is a piece of
> cake. It can use tcp sockets and unix domain sockets, and supports avahi.

I think this paragraph is not saying anything useful at all. It would be
great if the description could actually describe how this module is
different from the standard Python interface (rather than how much
better it is).


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/87bohq93mg@vostro.rath.org

Re: Inconsistency between mime-support, shared-mime-info and file for PHP files media types.

[Charles Plessy]

Le Thu, Aug 30, 2012 at 12:48:01AM -0700, Russ Allbery a écrit :
> 
> That's the reason why people are pursuing generating the metamail-style
> database *from* the XDG MIME specification so that we can use a richer
> specification in as many places as possible but fall back on the previous
> standard for applications that still use it.

Hi Russ,

I would be interested to have pointers to such projects.

For the registered media types, in my undestanding both mime-support (or its
equivalents in other distributions) and shared-mime-info (through its XDG
upstream) are tracking IANA's definitions, which is a duplication of work that
I would be glad to see resolved.  The biggest hurdle is probably that the
divergence in regard to the unregistered types, and the potential side effects
of changes if a merger happened.

Have a nice week-end,

-- 
Charles


-- 
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/20120901005410.ga21...@falafel.plessy.net

Re: Inconsistency between mime-support, shared-mime-info and file for PHP files media types.

[Russ Allbery]

Charles Plessy  writes:
> Le Thu, Aug 30, 2012 at 12:48:01AM -0700, Russ Allbery a écrit :

>> That's the reason why people are pursuing generating the metamail-style
>> database *from* the XDG MIME specification so that we can use a richer
>> specification in as many places as possible but fall back on the
>> previous standard for applications that still use it.

> Hi Russ,

> I would be interested to have pointers to such projects.

> For the registered media types, in my undestanding both mime-support (or
> its equivalents in other distributions) and shared-mime-info (through
> its XDG upstream) are tracking IANA's definitions, which is a
> duplication of work that I would be glad to see resolved.  The biggest
> hurdle is probably that the divergence in regard to the unregistered
> types, and the potential side effects of changes if a merger happened.

Well, perhaps I'm confused, since I thought that was part of what you were
working on!  :)

There was a previous discussion on debian-devel about this, during which I
posted a scetch of an implementation strategy for converting the XDG MIME
files to the mailcap syntax.  Someone else then fleshed out that script a
bit more, and I thought submitted it to the BTS, and then there was some
subsequent discussion in the Technical Committee in the context of the
evince application/pdf MIME registration that I thought indicated someone
was working on that further.  It may be that I had misunderstood.

-- 
Russ Allbery (r...@debian.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/87r4qmjwo2@windlord.stanford.edu

Re: Bug#684396: ITP: openrc -- alternative boot mechanism that manages the services, startup and shutdown of a host

[Thomas Goirand]

On 09/01/2012 04:06 AM, John Paul Adrian Glaubitz wrote:
> There should be at least some compelling technical arguments for
> OpenRC.
There are, and they have been listed already.

It goes from a more manageable code (for some parts, the same
feature as in systemd, but with a code that is 5 times smaller),
to the fact that it may work with something else than Linux,
or the fact that it supports also mdev. These are very interesting
features. The fact that upstream is also willing to help is also
very good.

It feels like repeating...

Thomas


-- 
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/50418ef1.1060...@debian.org

Re: Bug#684396: ITP: openrc -- alternative boot mechanism that manages the services, startup and shutdown of a host

[Patrick Lauer]

On 09/01/12 04:06, John Paul Adrian Glaubitz wrote:
> On Fri, Aug 31, 2012 at 08:28:27PM +0300, Serge wrote:
>> It's often someone says something similar about many ITPs. I believe noone
>> should say things like that, unless he wants to scare everybody away and
>> have Debian forgotten and dead. Saying that you not only reduce the number
>> of bugs in Debian, but you also reduce the number of people working on
>> Debian, because when they hear that they just turn around and go away.
> I don't see how these people help Debian if they start pushing their
> own solution instead of helping to improve what is already there.
>
Sometimes those two are the same thing ...


-- 
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/504198a7.4010...@gentoo.org

Re: Inconsistency between mime-support, shared-mime-info and file for PHP files media types.

[Charles Plessy]

Le Fri, Aug 31, 2012 at 07:37:17PM -0700, Russ Allbery a écrit :
> 
> There was a previous discussion on debian-devel about this, during which I
> posted a scetch of an implementation strategy for converting the XDG MIME
> files to the mailcap syntax.  Someone else then fleshed out that script a
> bit more, and I thought submitted it to the BTS, and then there was some
> subsequent discussion in the Technical Committee in the context of the
> evince application/pdf MIME registration that I thought indicated someone
> was working on that further.  It may be that I had misunderstood.

Now I understand :)

There are two FreeDeskotp (XDG) works relevant to media (MIME) types.

 - The menu entry specification 
(http://standards.freedesktop.org/menu-spec/latest/),
   where a program can declare that it can operate on a given media type.  This
   is the one that was recently discussed, and indeed mime-support in 
experimental
   is a first step into de-duplication of information between packages desktop 
menu
   entries and mailcap entries.

 - The shared MIME info database and its specification 
(http://freedesktop.org/wiki/Software/shared-mime-info)
   
(http://standards.freedesktop.org/shared-mime-info-spec/shared-mime-info-spec-latest.html),
   where media types are associated with file suffixes.  Some of these 
associations
   stem from the media type registrations to the IANA, which in the 
mime-support package
   are reflected in /etc/mime.types.  The shared MIME info database is 
distributed
   in Debian's package shared-mime-info, and in theory, this package would be 
able
   to produce and distribute /etc/mime.types as well.  In practice, I think 
that the
   unregistered types should be compared first.

I hope I (or others) will find time to submit a patch to the Policy in the next
months, to describe shared-mime-info in the same way as mime-support.

There is a third provider of media types, the "file" package.  I think it would
be good to eventually have a solid description of how media types are inferred 
in
Debian systems, and which packages operate on which installation profiles 
(mime-support
and file are of standard priority, while shared-mime-info is optional).

By the way, I completely agree to the comment you made to Josselin.  The
packages providing the minimal functionality are not a hindrance to more
advanced solutions.  I hope that the recent upload of mime-support to
experimental is a clear enough message.

Cheers,

-- 
Charles Plessy
Tsurumi, Kanagawa, Japan


-- 
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/20120901060852.ga22...@falafel.plessy.net