Re: A few observations about systemd

[Marc Haber]

On Sun, 17 Jul 2011 13:54:14 +0200, Juliusz Chroboczek
 wrote:
>Systemd deprecates shell scripts

How is one supposed to handle the case where the configuration the
daemon actually runs with needs to be generated, which is commonly
done in the init script's start target?

Greetings
Marc
-- 
-- !! No courtesy copies, please !! -
Marc Haber |   " Questions are the | Mailadresse im Header
Mannheim, Germany  | Beginning of Wisdom " | http://www.zugschlus.de/
Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fon: *49 621 72739834


--
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/e1qjqvv-0002my...@swivel.zugschlus.de

Re: [Lennart Poettering] Re: A few observations about systemd

[Raphael Hertzog]

I have to agree with Tollef here, the number of uninformed comments
(and even of respected figures like Wouter) is hurting this discussion.
Please people, if you don't want to see this discussion turn into a
troll-flamefest, don't treat it like if it was one!

I am among the people who are proud to see that we managed to achieve
Debian kfreebsd. But I am also among the people who believe that we have
to embrace the future and not just follow 2 years after everyone else has
made the switch. I am very much in favor of switching to some
more modern init system, be it upstart or systemd. It would be insane
to keep insserv just because of kfreebsd.

We should be shaping the future and not be simple followers. I agree
with Joey Hess that we should have init systems that make use of all the
powers of Linux on Linux and make use of all the powers of FreeBSD on
FreeBSD.

This is why interfaces are much more important than the individual
implementations. This is what has been suggested in this thread
(see http://lists.debian.org/1311064535.2467.3.camel@kirk) and
even what Lennart pointed out in his initial blog post [1]:
| If folks want to implement something similar for other operating systems,
| the preferred mode of cooperation is probably that we help you identify
| which interfaces can be shared with your system, to make life easier for
| daemon writers to support both systemd and your systemd counterpart.
| Probably, the focus should be to share interfaces, not code.

It's also relatively close to the position of upstart's upstream from
what I have understood.

On Tue, 19 Jul 2011, Gergely Nagy wrote:
> Thus, upstream has to jump through a large heap of hoops to support
> systemd properly (and if not going for proper systemd support, making
> use of its new features, I see no point in writing a service file to
> begin with).

Even if you use the good old init script with systemd, you do benefit
from many of its new features like the fact that each daemon is using
its own cgroup and that you can reliably kill it and all its childrens.

Cheers,

[1] http://0pointer.de/blog/projects/systemd.html
-- 
Raphaël Hertzog ◈ Debian Developer

Follow my Debian News ▶ http://RaphaelHertzog.com (English)
  ▶ http://RaphaelHertzog.fr (Français)


-- 
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/20110720073707.ge31...@rivendell.home.ouaza.com

Re: [kfreebsd] massive report for uninstallable FUSE packages

[Aurelien Jarno]

On Sat, Jul 16, 2011 at 09:38:35PM +0200, Robert Millan wrote:
> After receiving some feedback which allowed me to improve the
> template, this is the message I intend to use for the bug reports:
> 
> Package: %package%
> Severity: important
> User: debian-...@lists.debian.org
> Usertags: kfreebsd
> 
> Hi
> 
> This package is not installable on kfreebsd-i386 or kfreebsd-amd64 because it
> depends unconditionally on fuse-utils.
> 
> If %package% depends on fuse-utils only to ensure that FUSE support is 
> enabled,
> please consider adjusting the dependency to something like:
> 
>   Depends: fuse [linux-any] | fuse4bsd [kfreebsd-any]
> 
>   (example uses "fuse" because fuse-utils is now a transitional package that
>   depends on fuse)

I think it should be ',' instead of '|' here, there is no need for
alternative, the architecture conditionals already do the job.

-- 
Aurelien Jarno  GPG: 1024D/F1BCDB73
aurel...@aurel32.net http://www.aurel32.net


-- 
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/20110720081738.gb26...@volta.aurel32.net

Re: [Lennart Poettering] Re: A few observations about systemd

[Josselin Mouette]

Le mardi 19 juillet 2011 à 22:30 +0200, Martin Wuertele a écrit : 
> So if trolling is on add another one: it doesn't have udev

Which makes it impossible to support a large variety of hardware now
that the HAL crapware is going out.

-- 
 .''`.  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/1311150096.4372.240.camel@pi0307572

Re: [Lennart Poettering] Re: A few observations about systemd

[Gergely Nagy]

Raphael Hertzog  writes:

> On Tue, 19 Jul 2011, Gergely Nagy wrote:
>> Thus, upstream has to jump through a large heap of hoops to support
>> systemd properly (and if not going for proper systemd support, making
>> use of its new features, I see no point in writing a service file to
>> begin with).
>
> Even if you use the good old init script with systemd, you do benefit
> from many of its new features like the fact that each daemon is using
> its own cgroup and that you can reliably kill it and all its childrens.

There are benefits, indeed. But once one wants to use all the power
systemd provides, that's going to be a much bigger task. Bigger than
having to maintain a sysvinit script and a simple & dumb systemd service
file.

Not to mention that users who customised their init scripts will
suddenly have to figure out how to do the same stuff with systemd - with
no automatic upgrade path.

For example, many programs on my system have a file in /etc/default,
which file is sourced by the init script. These customisation options
will need to be migrated to systemd aswell, which is yet another burden
on the Debian package maintainer.

-- 
|8]


-- 
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/87d3h5e4rm@balabit.hu

Re: A few observations about systemd

[Paul Wise]

On Wed, Jul 20, 2011 at 9:10 AM, Marc Haber wrote:

> How is one supposed to handle the case where the configuration the
> daemon actually runs with needs to be generated, which is commonly
> done in the init script's start target?

Such packages can be supported by ExecStartPre, as documented in the
systemd.service manual page.

 ExecStartPre=/usr/bin/generate-my-config-file

I've never seen any package that needs this, do you have some examples?

-- 
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/CAKTje6EF7bShzCkfp9tm86q9tOx561Gbn=mq-vkj5jazld4...@mail.gmail.com

Re: A few observations about systemd

[Tollef Fog Heen]

]] Marc Haber 

Hi,

| On Sun, 17 Jul 2011 13:54:14 +0200, Juliusz Chroboczek
|  wrote:
| >Systemd deprecates shell scripts
| 
| How is one supposed to handle the case where the configuration the
| daemon actually runs with needs to be generated, which is commonly
| done in the init script's start target?

(I don't think it's commonly done, but that's besides the point.)

You'd then call a wrapper script that generates the configuration, so in
that respect it would be quite similar to today.

Something like:

ExecStartPre=/usr/sbin/update-exim4.conf
ExecStart=/usr/sbin/exim4 -bd -q30m

should do what you want.

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


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/87aac9gxgt@qurzaw.varnish-software.com

Re: [Lennart Poettering] Re: A few observations about systemd

[Paul Wise]

On Wed, Jul 20, 2011 at 10:27 AM, Gergely Nagy wrote:

> Not to mention that users who customised their init scripts will
> suddenly have to figure out how to do the same stuff with systemd - with
> no automatic upgrade path.

No, existing init scripts work with systemd, as stated already in this
thread. Otherwise no-one would ever want to try or adopt it.

> For example, many programs on my system have a file in /etc/default,
> which file is sourced by the init script. These customisation options
> will need to be migrated to systemd aswell, which is yet another burden
> on the Debian package maintainer.

Lennart's latest blog post "systemd for Administrators, Part IX"
covers this topic. There even seems to be ways to keep the existing
/etc/default files, but personally I would like to see /etc/default go
away entirely.

http://0pointer.de/blog/projects/on-etc-sysinit.html

-- 
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/CAKTje6Ghbo57XzL5uBGWHAubCEEph9bOO2Ow8ik1asyoY3=+x...@mail.gmail.com

Re: Bug#634811: ITP: dillo -- fast and light web browser based on FLTK 1.3

[Adam Borowski]

On Wed, Jul 20, 2011 at 06:26:02AM +0100, Neil Williams wrote:
> > * Package name: dillo
> 
> I remember asking for dillo to be removed due to the above, I'm glad
> someone has had time to fix the issues. Is dillo v3.0 using GTK 3 or
> GTK 2 with no deprecated code or just FLTK1.3? (I'm assuming dillo3 for
> Debian would change the default build to not statically link FLTK.)
> 
> How does the (unreleased) version compare with Arora (my current
> candidate for "small but usable web browser") and how soon is it
> likely to be ready for release? 

Arora is just a yet another interface for webkit; it takes over an order of
magnitude more disk space than dillo+fltk, and I guess it has memory usage
in that region as well.

On the other hand, Dillo's support for CSS and such is sketchy at best.
There's no javascript or anything of that kind as well.

Another thing is, Arora is dead upstream and no one stepped in to revive it. 

-- 
1KB // Yo momma uses IPv4!


signature.asc
Description: Digital signature

Re: [Lennart Poettering] Re: A few observations about systemd

[Josselin Mouette]

Le mardi 19 juillet 2011 à 21:26 +0200, Wouter Verhelst a écrit : 
> kFreeBSD is currently released as a "technology preview". With that, we
> mean it works, but it isn't necessarily ready yet for prime usage. The
> fact that there currently aren't many users yet isn't surprising in that
> light. However, as the port matures, it's not unthinkable that there
> will be many more users.
> 
> Frankly, I'd be somewhat surprised if some time after the release of
> wheezy (but still before wheezy+1), usage of Debian kFreeBSD did not
> surpass that of the i386 port.

You must be joking. So far only a very small subset of packages have
been actually checked as working on kfreebsd. People are not going to
risk seeing a dysfunctional system just so that they have pf and ZFS,
unless they really need it.

> > You disagree with systemd service files being much simpler than sysv
> > init scripts for many daemons?
> 
> No, I disagree with your statement that life of many maintainers of
> daemon packages is a complete nightmare currently.
> 
> Perhaps some things would be a bit easier to do with systemd unit files;
> but most initscripts are slightly-modified template initscripts from
> dh-make anyway; it's not as if they require a lot of effort to maintain.

It’s not such a lot of effort indeed, but the quality of the result is
not impressive either. Our init scripts are overall inconsistent and
buggy.

-- 
 .''`.  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/1311151866.4372.249.camel@pi0307572

Re: [Lennart Poettering] Re: A few observations about systemd

[Bernhard R. Link]

* Uoti Urpala  [110719 23:31]:
> Wouter Verhelst  debian.org> writes:
> > Debian is the 'Universal' operating system, and many of our developers
> > (including myself) pride themselves on that. We port to many
> > architectures, we port to multiple kernels. It's one of the defining
> > features of Debian: you can run it /anywhere/
>
> This is an almost religious argument. You take the value of running on 
> multiple
> kernels as an article of faith, with no evaluation of the benefits (either to
> people directly using such ports, or possible feedback to the main
> distribution). It's hard to make rational arguments against such a position,
> other than to note that the position is irrational and causes practical harm
> where it interferes with rational decisions.

If you do not address the issues, but try to reduce arguments to
something almost absurd then of course you will have problems to refute
things.

Universal is not so much about choice of kernels. It's about not
excluding people. Saying "This is no problem for 95% of people, why care
about the rest if it makes things harder for such a vast majority" might
sound reasonable if not thinking about it. Of course such decisions will
often not be independent, but in that case 14 such decisions would
already be enough to rule out over more than half the people.

We should care about niches or minorities, if only because every single
person in earth is in some niche or part of some minority. Noone if
mayority in every single aspect.

Please understand that a "You are all doing it wrong since ever,
everything you know shall no longer have any value, I know how things
should be done instead and I do not even care about the big obvious cases
where this no longer works" will not become sounding better to people by
claiming that the obvious victims have no value and should not exist
anyway.

Bernhard R. Link


-- 
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/20110720090317.ga15...@pcpool00.mathematik.uni-freiburg.de

Re: [Lennart Poettering] Re: A few observations about systemd

[Jon Dowland]

On Tue, Jul 19, 2011 at 09:26:33PM +0200, Wouter Verhelst wrote:
> Frankly, I'd be somewhat surprised if some time after the release of wheezy
> (but still before wheezy+1), usage of Debian kFreeBSD did not surpass that of
> the i386 port.

I'd be *very* surprised.  I can only imagine this happening if the vast
majority of Debian users finally moved off to other distributions (i.e., parity
by decreasing i386 usage, not be increasing kFreeBSD usage).


-- 
Jon Dowland


-- 
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/20110720091100.GB3796@pris

kFreeBSD debian-installer in Xen domU [Was: (Re: A few observations about systemd)]

[Ian Campbell]

On Tue, 2011-07-19 at 14:04 +, The Fungi wrote:
> I do in fact run kFreeBSD, and further, I do it within DomU on
> Debian/squeeze i386 Xen Dom0 hosts (though I had to install the root
> FS from the kFreeBSD D-I ISO under QEMU initially and then boot the
> result in Xen). 

Producing a Linux d-i image which worked in a domU was reasonably easy
(assuming a suitable kernel flavour exists in the archive), if you are
interested in doing the same for kFreeBSD I'd be more than happy to give
some guidance/pointers etc.

Presumably, given the necessary host hardware support, you could also
have installed as an HVM guest rather than QEMU and subsequently
switched to PV kFreeBSD. I'm not sure if FreeBSD has PV in HVM driver
support or not, I know some of the *BSDs do.

Ian.

-- 
Ian Campbell

The superfluous is very necessary.
-- Voltaire


-- 
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/1311152643.20648.175.ca...@zakaz.uk.xensource.com

Re: [Lennart Poettering] Re: A few observations about systemd

[Jon Dowland]

On Wed, Jul 20, 2011 at 12:52:36AM +0200, Wouter Verhelst wrote:
> Where it came from is less important than what it represents today to some of
> us. I believe I can read in your post that you don't like it; but certainly
> this is not true for all of us.

It completely predates Debian releasing non-Linux kernels and is not mentioned
in the social contract.   That some people feel it justifies (or even mandates)
non-Linux kernels in Debian is a retcon.  pf, ZFS; these are valid reasons
stated that support kFreeBSD.  "I interpret 'the Universal OS to mean'…" is
not.


-- 
Jon Dowland


-- 
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/20110720091529.GC3796@pris

Re: A few observations about systemd

[Christian PERRIER]

I don't know for any of you folks, but carrying an endless thread with
the name of someone doesn't make me very comfortable.

Could at least people participating in this thread drop Lennart's name
from the Subject: field?

TIA...



signature.asc
Description: Digital signature

Re: [Lennart Poettering] Re: A few observations about systemd

[Stefano Zacchiroli]

On Wed, Jul 20, 2011 at 09:37:07AM +0200, Raphael Hertzog wrote:
> I am among the people who are proud to see that we managed to achieve
> Debian kfreebsd.

Same here, I've always mentioned GNU/kFreeBSD as one of the things I'm
most proud of in the Squeeze release. I'd be no less proud of seeing
Debian grow other non-Linux ports (e.g. Hurd) in future releases. No
matter how unimportant those ports might seem to people using only
GNU/Linux, the make Debian today one of the most important porting
platforms for our upstreams and users. They can both benefit from Debian
seeing how portable their software really is. This is an important role
that Debian is playing in the whole ecosystem of Free Software.

> We should be shaping the future and not be simple followers. I agree
> with Joey Hess that we should have init systems that make use of all
> the powers of Linux on Linux and make use of all the powers of FreeBSD
> on FreeBSD.

I agree with this as well. Even if it might seem at stake with the
former argument, I believe it is not. We cannot hold back advancements
just because one part of our huge archive does not support them; doing
so would mean taking a rather extreme (and wrong, imo) side in the
trade-off among "universality" (in the technical sense of "runs
everywhere") and "advanced" (when compared to other distros).

If we lag behind in features that are good for GNU/Linux users (who are
the vast majority of our users) just because users of some ports can't
have them, we might force users to choose other distros, renouncing to
some of the unique features that Debian has to offer (freedom, quality,
open development, etc.). This of course goes both way: we should not
hold back non-Linux features on non-Linux kernels because the Linux
kernel lack them. Adopting that as a general principle would mean
offering, overall, the intersection of features available in all our
ports, something which is doomed to reduce with the growth of the number
of ports.

But what I find surprising in this discussion (with notable exception,
luckily) is the feeling that portability is boolean: it is not. It is
rather a trade-off among the work that needs to be done / code that
needs to be maintained and the distro-wide technical choices that we
make. In that respect, the fact that systemd upstream might decide not
to integrate upstream our chances is sad, but it's not the end of the
world: it won't be the first nor the last upstream not willing to
integrate some of our changes.

> This is why interfaces are much more important than the individual
> implementations. This is what has been suggested in this thread

And speaking about interface, another surprising absence in this thread
is the mention of Debian's most important "interface", namely the Debian
Policy. No matter how much we discuss whether systemd (or upstart, fwiw)
is good or not in this thread, the discussion won't make adopting it any
easier. init.d scripts are explicitly supported by the Debian Policy and
required for packages shipping services. That means that the first
mandatory step to have support for a non SysV init system in Debian is
to add support for it into policy.

That has started after the "upstart in Debian" BoF at DebConf10 and is
being tracked in #591791. I've pointed the systemd maintainer to it a
long time ago and he has chimed in there (thanks Tollef!). I'm not
following the bug log closely, but it seems to me that they are also
discussing there how to generalize the policy change to other init
systems, such as systemd. That is very good and has way more chances of
changing the status quo in Debian than any pro- or against-systemd
thread on -devel.

Cheers.
-- 
Stefano Zacchiroli -o- PhD in Computer Science \ PostDoc @ Univ. Paris 7
zack@{upsilon.cc,pps.jussieu.fr,debian.org} -<>- http://upsilon.cc/zack/
Quando anche i santi ti voltano le spalle, |  .  |. I've fans everywhere
ti resta John Fante -- V. Capossela ...| ..: |.. -- C. Adams


signature.asc
Description: Digital signature

Re: A few observations about systemd

[Josselin Mouette]

Le mercredi 20 juillet 2011 à 10:29 +0200, Paul Wise a écrit : 
> Such packages can be supported by ExecStartPre, as documented in the
> systemd.service manual page.
> 
>  ExecStartPre=/usr/bin/generate-my-config-file
> 
> I've never seen any package that needs this, do you have some examples?

exim4 and gdm3 are notorious examples.

-- 
 .''`.  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/1311155338.4372.255.camel@pi0307572

Re: A few observations about systemd

[Josselin Mouette]

Le mardi 19 juillet 2011 à 13:41 -0500, Peter Samuelson a écrit : 
> [Uoti Urpala]
> > IMO letting kFreeBSD block a technology like systemd (or even letting
> > it have a significant impact on the discussion about whether it's
> > desirable to introduce the technology for the main Linux case) would
> > only be justifiable if there were very solid arguments why kFreeBSD
> > is a big net win for the project, or after a vote showing significant
> > support for the port.
> 
> IMO letting systemd block a technology like kFreeBSD (or even letting
> it have a significant impact on the discussion about whether it's
> desirable to introduce the port for Debian releases) would
> only be justifiable if there were very solid arguments why systemd is
> a big net win for the project, or after a vote showing significant
> support for the package.

You are both framing the discussion through a fallacy: that the only
choice we have is either to drop kfreebsd or to keep insserv forever.

There is no point in doing that. The only thing you are achieving is
throwing people against one another, without anything happening at the
technical level.

Having concluded from this thread that 1) kfreebsd is important to
Debian and 2) systemd is important for Debian, the question cannot be
which one we choose between the two, but HOW we achieve both with the
least pain possible.

Several people have already explained that it should be possible to
write a script, working for most packages, to generate old-style init
scripts from systemd service files, allowing for a compatibility wrapper
on top of insserv for kfreebsd (until systemd is ported or a compatible
init is written for it).

-- 
 .''`.  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/1311155761.4372.262.camel@pi0307572

Conciliating systemd and GNU/kFreeBSD

[Cyril Brulebois]

Hi all.

(Putting -bsd@ in the loop, since I believe not everyone there reads
 -devel@. The (very long) thread starts at:
   http://lists.debian.org/debian-devel/2011/07/msg00269.html)

Josselin Mouette  (20/07/2011):

> You are both framing the discussion through a fallacy: that the only
> choice we have is either to drop kfreebsd or to keep insserv forever.
> 
> There is no point in doing that. The only thing you are achieving is
> throwing people against one another, without anything happening at the
> technical level.
> 
> Having concluded from this thread that 1) kfreebsd is important to
> Debian and 2) systemd is important for Debian, the question cannot be
> which one we choose between the two, but HOW we achieve both with the
> least pain possible.



> Several people have already explained that it should be possible to
> write a script, working for most packages, to generate old-style init
> scripts from systemd service files, allowing for a compatibility
> wrapper on top of insserv for kfreebsd (until systemd is ported or a
> compatible init is written for it).


Tollef also mentioned that on IRC, and I fail to see any better option
right now. Some mentioned there could be security risks involved, in
case one package relies on this or that feature on systemd's side, but I
guess we could also live with a few special cases where init.d scripts
could be maintained manually (rather than autogenerated from systemd
service files).

Mraw,
KiBi.


signature.asc
Description: Digital signature

Re: A few observations about systemd

[Marco d'Itri]

On Jul 20, Josselin Mouette  wrote:

> Having concluded from this thread that 1) kfreebsd is important to
> Debian and 2) systemd is important for Debian, the question cannot be
I think that both statements are not so much obvious, but anyway...

> which one we choose between the two, but HOW we achieve both with the
> least pain possible.
A more interesting question is: if systemd or upstart were adopted,
would the kFreeBSD porters be willing to implement everything needed
to support on their ports the packages using a non-traditional init
configuration, in the way they consider appropriate and without causing
a significant burden on the other ports?
I think that a clear statement from the kFreeBSD porters about this
would help concluding this debate.

-- 
ciao,
Marco


signature.asc
Description: Digital signature

Re: Bug#634235: ITP: mess-desktop-entries -- Desktop entries for MESS ROMS

[Jordi Mallach]

On Wed, Jul 20, 2011 at 02:45:14AM +0200, Jonas Smedegaard wrote:
> This package appeared in main and does not depend on MESS, only enhances 
> it - still it seems to me that this package have no use without MESS and 
> therefore should instead be in contrib - because MESS is in non-free.

This was noted by Tolimar when he accepted the package, and I made the
changes in -2, which should be sitting in NEW right now.

Jordi
-- 
Jordi Mallach Pérez  --  Debian developer http://www.debian.org/
jo...@sindominio.net jo...@debian.org http://www.sindominio.net/
GnuPG public key information available at http://oskuro.net/


-- 
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/20110720115832.gc22...@aigua.oskuro.net

Re: Bug#634235: ITP: mess-desktop-entries -- Desktop entries for MESS ROMS

[Alexander Reichle-Schmehl]

Am 20.07.2011 13:58, schrieb Jordi Mallach:

> This was noted by Tolimar when he accepted the package, and I made the
> changes in -2, which should be sitting in NEW right now.

... and got accepted four minutes, after you sent your mail ;)


Best regards,
  Alexander


-- 
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/4e26cb90.70...@debian.org

Bug#634840: ITP: eviacam -- A cross platform webcam based mouse emulator

[Cesar Mauri]

Package: wnpp
Severity: wishlist
Owner: Cesar Mauri 


* Package name: eviacam
  Version : 1.5.1
  Upstream Author : Cesar Mauri 
* URL : http://viacam.org
* License : GPL
  Programming Lang: C, C++
  Description : A cross platform webcam based mouse emulator

Enable Viacam (aka eViacam) is a mouse replacement software that
moves the pointer as you move your head. It works on standard
computer equipped with a web camera. No additional hardware is
required. Based on the award winning Facial Mouse software.

Launched in 2008, it is a mature and actively maintained project
whose main purpose is to provide an alternative access method
for people with disabilities. In fact some of its contributors
are actual users of the software.

My main motivation for maintaining this software is due to the 
lack of a full featured, well maintained replacement.

Sponsor required. 

-- System Information:
Debian Release: 5.0.6
  APT prefers oldstable
  APT policy: (500, 'oldstable')
Architecture: i386 (i686)



-- 
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/20110720120453.17264.99009.report...@boneprime.pau

DEP5 public-domain Question

[Yaroslav Halchenko]

quick one -- where to place "public domain" -- into Copyright or
License?

http://dep.debian.net/deps/dep5/
kinda suggests to use short license name "public-domain" within License:
field.  But also it suggests that Copyright is the correct place for
such information (which I agree with, since being "public domain" is
about ownership, not description of the use terms)

Also, the DEP5 checker has no clue about public-domain as a short
license either:

$> config-edit -application dpkg-copyright -ui none
Configuration item 'Files:"scikits/statsmodels/datasets/anes96/anes96.csv
   scikits/statsmodels/datasets/grunfeld/grunfeld.csv
   scikits/statsmodels/datasets/longley/longley.csv
   scikits/statsmodels/datasets/macrodata/macrodata.csv
   scikits/statsmodels/datasets/nile/nile.csv
   scikits/statsmodels/datasets/randhie/randhie.csv
   scikits/statsmodels/datasets/stackloss/stackloss.csv
   scikits/statsmodels/datasets/strikes/strikes.csv
   scikits/statsmodels/datasets/sunspots/sunspots.csv" License short_name' has 
a wrong value:
license public-domain is not declared in main License section. Expected 
BSD-3

and if I omit license for works in public-domain (mentioned in Copyright:)

$> config-edit -application dpkg-copyright -ui none   
Configuration item 'Files:"scikits/statsmodels/datasets/anes96/anes96.csv
   scikits/statsmodels/datasets/grunfeld/grunfeld.csv
   scikits/statsmodels/datasets/longley/longley.csv
   scikits/statsmodels/datasets/macrodata/macrodata.csv
   scikits/statsmodels/datasets/nile/nile.csv
   scikits/statsmodels/datasets/randhie/randhie.csv
   scikits/statsmodels/datasets/stackloss/stackloss.csv
   scikits/statsmodels/datasets/strikes/strikes.csv
   scikits/statsmodels/datasets/sunspots/sunspots.csv" License short_name' has 
a wrong value:
Undefined mandatory value.


-- 
=--=
Keep in touch www.onerussian.com
Yaroslav Halchenko www.ohloh.net/accounts/yarikoptic


-- 
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/20110720133909.gb16...@onerussian.com

Re: A few observations about systemd

[Juliusz Chroboczek]

> That is very good and has way more chances of changing the status quo
> in Debian than any pro- or against-systemd thread on -devel.

Just to clarify -- this is not a pro- or against- thread, which, as I've
tried to make clear in my initial mail, would be premature.  My goal is
to get people thinking about the current work being done on next-gene-
ration init systems, and it appears that I have succeeded.

Let me be more explicit.  Over the last few years, we've seen a mul-
titude of new init systems appear.  The other distributions have been
switching like crazy -- as far as I'm aware (I may be wrong) Gentoo went
for initng, then switched back to SV init, Fedora switched to upstart
and then, within two releases, to systemd, openSuSE switched to upstart,
then started switching to systemd, then apparently stalled.

This sort of disruption is not good for the users; neither is it good
for the developers' morale (a vitally important consideration for
a distribution that relies on volunteer labour).  Again, this is just my
private opinion (and as you know I'm not even a DD, just an enthusiastic
user), but I'd like to see Debian wait until the dust settles.  I'm
acutely aware, however, that waiting only makes sense if Debian developers
are aware of the ongoing community-wide debate, and participate in it.
Which is why the work of people like Tollef and Scott is so crucially
important.

So folks -- please relax.  Please play with runit, play with initng,
play with upstart, play with systemd.  Oh, and read djb's thoughts on
the subject[1].  When enough Debian developers are competent to have an
opinion on the new init systems, the Debian community will naturally
converge on the technically correct solution; at that point, fitting the
non-Linux kernels into the picture will be a simple matter of hacking.

As a final note, Bastien and Ian have outlined a different architecture
for a new init system, one that does not rely on running 700 kB of text
under pid 1.  I happen to agree with their vision.

-- Juliusz

[1] http://cr.yp.to/daemontools/faq/create.html  Please note that I am
not suggesting daemontools as a solution, just recommending that
people be aware of the rationale behind it.


-- 
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/877h7dozj4.fsf...@trurl.pps.jussieu.fr

Re: [kfreebsd] massive report for uninstallable FUSE packages

[Robert Millan]

2011/7/20 Aurelien Jarno :
> I think it should be ',' instead of '|' here, there is no need for
> alternative, the architecture conditionals already do the job.

Hi Aurelien

You're right.  I just followed existing practice, but I admit it's not
entirely consistent.

However, since this is basically cosmetical and the effect is the
same, I don't think it's worth sending an update to each of the bug
reports.  But if you still want it, feel free to, I have no objection.

-- 
Robert Millan


-- 
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/CAOfDtXMZBcXB=rqbp7duww7eb+p87d2rauu+canwpefjigg...@mail.gmail.com

Re: [Lennart Poettering] Re: A few observations about systemd

[Marco d'Itri]

On Jul 20, Russ Allbery  wrote:

> > Again, why?
> ZFS is a pretty big one.
It is about as stable as BTRFS on Linux, so I do not see either a
compelling argument right now.

-- 
ciao,
Marco


signature.asc
Description: Digital signature

Re: .la file removal, multiarch for plugins

[Steve Langasek]

Hi Lionel,

On Sun, Jul 10, 2011 at 04:48:16PM +0200, Lionel Elie Mamane wrote:
> >>>  To finish an old release goal from Squeeze, to comply with Policy
> >>> 10.2 and to ease the introduction of MultiArch, I'm filing bugs
> >>> against packages which contain .la files which can be either removed
> >>> or stripped of the dependency_libs variable.

> >> Policy 10.2 says:

> >>  These requirements for handling of .la files do not apply to loadable
> >>  modules or libraries not installed in directories searched by default
> >>  by the dynamic linker.

> > All true, but (...) clearing the dependency_libs field in the .la
> > file is still necessary even if the .la file is retained for the
> > purposes of things like libltdl. (It is also safe for libltdl usage
> > as this relies on a different part of the .la file.)

> OK. What is slightly unclear to me, is that "being loaded by libltdl"
> is a thing that is external to the package. If there is *one* program
> anywhere (even not packaged in Debian or local to an enterprise) that
> uses libltdl to load library foo, we break that program by removing
> the .la file. So I don't really understand why we (we=Debian) consider
> it a good thing to remove the .la file, even if nothing in Debian, or
> nothing we know of, uses libltdl to load that library.

If we're talking about shared libraries, this is a non issue.  the .la file
is named like the .so symlink, i.e. without the soname; dlopening a shared
library without specifying an soname is Broken and Wrong.  So there's no
reason for us to worry about breaking something that's already entirely
broken.

For plugins / DSOs, it's important to not break compatibility with other
software that might be opening them in a way that references the .la file,
true; but in most cases these are plugins for a specific piece of software,
so we know conclusively whether or not the .la file is used for the lookup.
In this respect, ODBC is a special case.  The UnixODBC documentation and
examples certainly all use the .so, not the .la, but ODBC drivers can also
be used directly without going through the driver manager, and if the .la
exists on the system then it's always possible that someone has referenced
it in their odbcinst.ini, too.

So if you are concerned that users are referencing a .la file for an ODBC
driver, it's not a bug for you to leave it in place indefinitely.  However,
I think this is a really small compatibility break and would personally not
worry much that this would have an impact on users.

> > With MultiArch, you may still get problems here because those
> > directories will be changing. If those paths are within the sole
> > control of this package, fine - both parts can change at the same time.
> > If you're relying on paths which come from a separate source package,
> > it'll likely break.

> I suppose we'll have a controlled / synchronised migration for all
> ODBC drivers? Or should each driver just unilaterally stick
> $(dpkg-architecture -qDEB_HOST_MULTIARCH) somewhere in the path?

> I presume that
>  /usr/lib/$(dpkg-architecture -qDEB_HOST_MULTIARCH)/odbc
> is better than
>  /usr/lib/odbc/$(dpkg-architecture -qDEB_HOST_MULTIARCH)

> This would work for ODBC drivers because they are registered anyway,
> so really, (if I understand well) as far as the ODBC libraries and
> applications are concerned, they can be anywhere. Nevertheless, IMHO,
> it would be "cleaner" if all ODBC drivers made the same choice.

I think it would be premature for ODBC drivers to switch to multiarch paths.
There would be no benefit, because the ODBC driver manager doesn't have a
search path for drivers that includes any multiarch paths, so you would have
to hard-code the driver path in the odbcinst.ini - so then it's
architecture-specific anyway and you've gained no ability to use drivers for
multiple architectures side-by-side!

Multiarch is a transition that will have a very long tail, and that's
perfectly ok.  There's certainly no need to rush to convert things to new
paths where there isn't a clear and understood benefit.

> Other loadable libraries (typically plugins / extensions; I'm thinking
> of my xchat-guile package here) that are dlopen()ed or loaded using
> libltdl, I presume the loading application will have to be fixed to
> lead from a multiarch path anyway, so the plugins have to wait for the
> app to do it first.

Yes.  For examples of how this can be done, feel free to look at the
gdk-pixbuf and glib2.0 patches.

Cheers,
-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
Ubuntu Developerhttp://www.debian.org/
slanga...@ubuntu.com vor...@debian.org


signature.asc
Description: Digital signature

Bug#634847: ITP: xul-ext-dactyl -- keyboard-accessible user interfaces for XUL-based applications

[Michael Schutte]

Package: wnpp
Severity: wishlist
Owner: Michael Schutte 

[Cc-ing pkg-mozext-maintainers, whom I’d like to join for packaging
this, and Vimperator maintainer Francois Marier]

* Package name: dactyl
  Version : 1.0~b6.1
  Upstream Author : Doug Kearns ,
Kris Maglione ,
Martin Stubenschrott 
* URL : http://dactyl.sourceforge.net/
* License : MIT
  Programming Lang: JavaScript (XUL)
  Description : keyboard-accessible user interfaces for XUL-based 
applications

The Dactyl project offers Vim-inspired, keyboard-accessible user
interfaces for Iceweasel/Firefox (Pentadactyl), Icedove/Thunderbird
(Teledactyl), and Songbird (Melodactyl).  It allows to navigate these
applications with sensible key bindings instead of the mouse.

Initially, only a xul-ext-pentadactyl binary will be provided, since the
other two extensions are still in a pre-alpha stage.

This is a fork of the Vimperator extension (which is already in Debian),
but as Vimperator is moving on [1] and Pentadactyl appears to retain its
“classic” appearance and behavior, it makes sense to offer this choice.

[1] http://code.google.com/p/vimperator-labs/wiki/Vimperator3DesignGoals

-- 
Michael Schutte   | michi@{uiae.at,debian.org}
Innsbruck, Austria| happily accepting encrypted mail
OpenPGP: 0x16fb 517b a866 c3f6 8f11 1485 f3e4 122f 1D8C 261A


signature.asc
Description: Digital signature

Re: [Lennart Poettering] Re: A few observations about systemd

[Mike Hommey]

On Wed, Jul 20, 2011 at 04:31:24PM +0200, Marco d'Itri wrote:
> On Jul 20, Russ Allbery  wrote:
> 
> > > Again, why?
> > ZFS is a pretty big one.
> It is about as stable as BTRFS on Linux, so I do not see either a
> compelling argument right now.

BTRFS ? stable ? You must be living in the future.

Mike


-- 
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/20110720143901.ga9...@glandium.org

Re: [Lennart Poettering] Re: A few observations about systemd

[Marco d'Itri]

On Jul 20, Mike Hommey  wrote:

> > > > Again, why?
> > > ZFS is a pretty big one.
> > It is about as stable as BTRFS on Linux, so I do not see either a
> > compelling argument right now.
> BTRFS ? stable ? You must be living in the future.
My point.

-- 
ciao,
Marco


signature.asc
Description: Digital signature

Re: [Lennart Poettering] Re: A few observations about systemd

[Wouter Verhelst]

On Wed, Jul 20, 2011 at 04:31:24PM +0200, Marco d'Itri wrote:
> On Jul 20, Russ Allbery  wrote:
> 
> > > Again, why?
> > ZFS is a pretty big one.
> It is about as stable as BTRFS on Linux, so I do not see either a
> compelling argument right now.

Do you have any data to back up that statement? There have been some
issues in the past with ZFS on 32bit machines and/or low-memory
situations, but if you use it in the environment that it's meant for
(large deployments), it's pretty stable.

-- 
The volume of a pizza of thickness a and radius z can be described by
the following formula:

pi zz a


-- 
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/20110720144830.ge5...@grep.be

Re: A few observations about systemd

[Uoti Urpala]

Bernhard R. Link  debian.org> writes:
> * Uoti Urpala  pp1.inet.fi> [110719 23:31]:
> > Wouter Verhelst  debian.org> writes:
> > > Debian is the 'Universal' operating system, and many of our developers
> > > (including myself) pride themselves on that. We port to many
> > > architectures, we port to multiple kernels. It's one of the defining
> > > features of Debian: you can run it /anywhere/
> >
> > This is an almost religious argument. You take the value of running on
> > multiple
> > kernels as an article of faith, with no evaluation of the benefits (either
> > to
> > people directly using such ports, or possible feedback to the main
> > distribution). It's hard to make rational arguments against such a position,
> > other than to note that the position is irrational and causes practical harm
> > where it interferes with rational decisions.
> 
> If you do not address the issues, but try to reduce arguments to
> something almost absurd then of course you will have problems to refute
> things.

I don't see how this applies to what you're replying to. In the discussion with
Wouter I did quite a lot better at addressing factual issues than he did.

> Universal is not so much about choice of kernels. It's about not
> excluding people. Saying "This is no problem for 95% of people, why care

I think you're committing exactly the fallacy I described in the part you
snipped. You think that "excluding" people who want a particular kernel is
significant when it's a "big thing" like a kernel. But _any_ case of not
supporting something can be described as "exclusion". Any time a package is
dropped, Debian is "excluding" the people who want to use that package. Every
time a decision is made not to package something people are being "excluded".
When Debian Linux fails to run on a specific submodel X of hardware Y, people
who use that hardware are "excluded". Any of those cases can affect a much
larger number of people than kFreeBSD support.

If it were possible to support every use case and every piece of hardware then
things would be different. But it is not possible. You have to prioritize
things. And it is exactly the lack of a rational approach to this that I was
criticizing above. When a bug goes unfixed and that prevents a user from
achieving whatever goal he had, that is no better than someone being unable to
achieve what he wanted because kFreeBSD was not available (and in fact I'd say
the latter would typically be less severe, as the typical goal would be just
"play with kFreeBSD for its own sake").

Supporting things like kFreeBSD is a lot of effort to benefit few people. If
it's what a volunteer wants to work on then that is his right. But to insist
that others should work on it is wrong; project-wide priorities should be based
on rational decisions instead. And to compare "support kFreeBSD" and "make Linux
work well for a larger number of people" and claim that kFreeBSD stands more for
"inclusion" is nothing but bullshit rhetoric.


-- 
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.20110720t175223-...@post.gmane.org

Re: [Lennart Poettering] Re: A few observations about systemd

[Russ Allbery]

m...@linux.it (Marco d'Itri) writes:
> On Jul 20, Russ Allbery  wrote:

>> ZFS is a pretty big one.

> It is about as stable as BTRFS on Linux, so I do not see either a
> compelling argument right now.

I know from actual, real-world testing and usage of specifically Debian
kFreeBSD that ZFS is stable enough for production use.  I don't personally
know anything about BTRFS, so I don't know if it's a comprehensive
replacement for the facilities of ZFS, or anything about its stability.

-- 
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/87r55kzz6d@windlord.stanford.edu

Re: A few observations about systemd

[Russ Allbery]

Josselin Mouette  writes:

> Having concluded from this thread that 1) kfreebsd is important to
> Debian and 2) systemd is important for Debian, the question cannot be
> which one we choose between the two, but HOW we achieve both with the
> least pain possible.

+1

-- 
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/87mxg8zz5d@windlord.stanford.edu

Re: Bug#634811: ITP: dillo -- fast and light web browser based on FLTK 1.3

[Andrey Rahmatullin]

On Wed, Jul 20, 2011 at 10:42:07AM +0200, Adam Borowski wrote:
> > How does the (unreleased) version compare with Arora (my current
> > candidate for "small but usable web browser") and how soon is it
> > likely to be ready for release? 
> Arora is just a yet another interface for webkit; it takes over an order of
> magnitude more disk space than dillo+fltk, and I guess it has memory usage
> in that region as well.
> 
> On the other hand, Dillo's support for CSS and such is sketchy at best.
> There's no javascript or anything of that kind as well.
What about links2 -g?

-- 
WBR, wRAR


signature.asc
Description: Digital signature

Re: kFreeBSD debian-installer in Xen domU [Was: (Re: A few observations about systemd)]

[The Fungi]

On Wed, Jul 20, 2011 at 10:04:03AM +0100, Ian Campbell wrote:
> Producing a Linux d-i image which worked in a domU was reasonably
> easy (assuming a suitable kernel flavour exists in the archive),
> if you are interested in doing the same for kFreeBSD I'd be more
> than happy to give some guidance/pointers etc.

At the risk of drifting off topic a bit, I expect this would be a
welcomed update to the Xen topic on the kFreeBSD wiki page. Once
it's bootstrapped into a working root FS, the current kernel
packages have sufficient support baked in these days so it's just a
matter of having a working installer now.

> Presumably, given the necessary host hardware support, you could also
> have installed as an HVM guest rather than QEMU and subsequently
> switched to PV kFreeBSD. I'm not sure if FreeBSD has PV in HVM driver
> support or not, I know some of the *BSDs do.

In my current reference implementation, unfortunately not. These
host machines, while consisting of internally highly-redundant
components, employ older Intel Pentium III processors (Compaq
Proliant DL380 G2 series from 8+ years ago).
-- 
{ IRL(Jeremy_Stanley); WWW(http://fungi.yuggoth.org/); PGP(43495829);
WHOIS(STANL3-ARIN); SMTP(fu...@yuggoth.org); FINGER(fu...@yuggoth.org);
MUD(kin...@katarsis.mudpy.org:6669); IRC(fu...@irc.yuggoth.org#ccl);
ICQ(114362511); YAHOO(crawlingchaoslabs); AIM(dreadazathoth); }


-- 
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/20110720175815.gn1...@yuggoth.org

Re: Bug#634811: ITP: dillo -- fast and light web browser based on FLTK 1.3

[Axel Beckert]

Hi,

Andrey Rahmatullin wrote:
> > On the other hand, Dillo's support for CSS and such is sketchy at best.
> > There's no javascript or anything of that kind as well.
> What about links2 -g?

JavaScript support in links2 has been killed by upstream in the 2.1 release:

Mon Apr 16 01:49:07 MET DST 2007 mikulas:

Javascript was removed. The reason is that it is very buggy, Martin
Pergel doesn't have time to develop it and code is so messy that no one
else can understand it.

If you use links for special purposes (embedded devices, etc.), you can
bring javascript back by copying javascript files from previous release,
removing "dnl javascript" lines from configure.in, adding *.c and *.h
files to Makefile.am and re-running automake and autoconf.

Javascript hooks from main code were not removed --- they just won't be
maintained.

Regards, Axel (who'll upload links2 2.3pre2 soon, too :-)
-- 
 ,''`.  |  Axel Beckert , http://people.debian.org/~abe/
: :' :  |  Debian Developer, ftp.ch.debian.org Admin
`. `'   |  1024D: F067 EA27 26B9 C3FC 1486  202E C09E 1D89 9593 0EDE
  `-|  4096R: 2517 B724 C5F6 CA99 5329  6E61 2FF9 CD59 6126 16B5


-- 
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/20110720174040.gn29...@sym.noone.org

Re: DEP5 public-domain Question

[Russ Allbery]

Yaroslav Halchenko  writes:

> quick one -- where to place "public domain" -- into Copyright or
> License?

> http://dep.debian.net/deps/dep5/
> kinda suggests to use short license name "public-domain" within License:
> field.  But also it suggests that Copyright is the correct place for
> such information (which I agree with, since being "public domain" is
> about ownership, not description of the use terms)

I think public domain in the Debian DEP-5 context is a license.  While
it's not legally a license, the public domain status serves the same
purpose: telling people what rights they have to use the work.  So I would
do something like:

License: public-domain
 

You do need some sort of statement about why the work is in the public
domain, since that's a rather unusual status and requires some
justification (such as that it's a US government work).

-- 
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/871uxkygh7@windlord.stanford.edu

Re: Bug#634811: ITP: dillo -- fast and light web browser based on FLTK 1.3

[Axel Beckert]

Hi,

Adam Borowski wrote:
> On Wed, Jul 20, 2011 at 06:26:02AM +0100, Neil Williams wrote:
> > I remember asking for dillo to be removed due to the above, I'm glad
> > someone has had time to fix the issues. Is dillo v3.0 using GTK 3 or
> > GTK 2 with no deprecated code or just FLTK1.3? (I'm assuming dillo3 for
> > Debian would change the default build to not statically link FLTK.)

Just FLTK 1.3 from what I saw so far. (Looked at the FLTK 1.3 port
closer some months ago, but it wasn't ready at that time. Now it looks
much better, so I published the ITP. :-)

> > How does the (unreleased) version compare with Arora (my current
> > candidate for "small but usable web browser") and how soon is it
> > likely to be ready for release? 
> 
> Arora is just a yet another interface for webkit; it takes over an order of
> magnitude more disk space than dillo+fltk, and I guess it has memory usage
> in that region as well.

I can just agree with that.

In generally, I don't think Dillo or Links2 can replace a web browser
with a full-blown rendering engine like Gecko, WebKit, etc., if you
want CSS and JS to work. But for some special purposes or the quick
lookup in the web, they serve very well (especially with the focus on
"quick" -- I don't want to load my whole browser session just lookup
one thing on Wikipedia or so :-).

The only more or less low-footprint browser which IMHO comes close the
big rendering engines is Netsurf. It's unfortunately not in Squeeze
due to some issues with build-dependencies (the used parser generator
suddenly started to fail) and new upstream versions needed a fistful
of new libraries to be packaged, too. But the version now in Wheezy
and Sid should be fine again.

Neil: Ever looked at the keyboard-focussed browsers in Debian like
Conkeror, Luakit, Uzbl or Surf? They all have one of the bloaty
rendering engines (WRT dependencies and memory usage) but are usually
quicker and more responsive than their GUI pendants. (300 to 400 tabs
in Conkeror are no performance issue. Try that with
Firefox^WIceweasel. :-)

> Another thing is, Arora is dead upstream and no one stepped in to
> revive it. 

Oops. That's a pity. From the classical GUI browsers with WebKit I
liked that one most. Would Rekonq be a suitable drop-in replacement
for Arora?

Regards, Axel
-- 
 ,''`.  |  Axel Beckert , http://people.debian.org/~abe/
: :' :  |  Debian Developer, ftp.ch.debian.org Admin
`. `'   |  1024D: F067 EA27 26B9 C3FC 1486  202E C09E 1D89 9593 0EDE
  `-|  4096R: 2517 B724 C5F6 CA99 5329  6E61 2FF9 CD59 6126 16B5


-- 
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/20110720175918.go29...@sym.noone.org

Re: DEP5 public-domain Question

[Jakub Wilk]

* Russ Allbery , 2011-07-20, 11:06:

http://dep.debian.net/deps/dep5/
kinda suggests to use short license name "public-domain" within 
License: field.  But also it suggests that Copyright is the correct 
place for such information (which I agree with, since being "public 
domain" is about ownership, not description of the use terms)


I think public domain in the Debian DEP-5 context is a license.  While 
it's not legally a license, the public domain status serves the same 
purpose: telling people what rights they have to use the work.  So I 
would do something like:


License: public-domain
is in the public domain>


So what to put in the Copyright field? It's a required one.

--
Jakub Wilk


--
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/20110720181946.ga2...@jwilk.net

Re: Bug#634811: ITP: dillo -- fast and light web browser based on FLTK 1.3

[Andrey Rahmatullin]

On Wed, Jul 20, 2011 at 07:40:40PM +0200, Axel Beckert wrote:
> > > On the other hand, Dillo's support for CSS and such is sketchy at best.
> > > There's no javascript or anything of that kind as well.
> > What about links2 -g?
> 
> JavaScript support in links2 has been killed by upstream in the 2.1 release:
I mean, "how is dillo compared to links2 -g if they both have similar
restrictions and links2 -g is (well, was in 2007) IIRC quite light and
fast".

-- 
WBR, wRAR


signature.asc
Description: Digital signature

Re: A few observations about systemd

[brian m. carlson]

On Wed, Jul 20, 2011 at 04:36:35PM +, Uoti Urpala wrote:
> I think you're committing exactly the fallacy I described in the part you
> snipped. You think that "excluding" people who want a particular kernel is
> significant when it's a "big thing" like a kernel. But _any_ case of not
> supporting something can be described as "exclusion". Any time a package is
> dropped, Debian is "excluding" the people who want to use that package. Every
> time a decision is made not to package something people are being "excluded".
> When Debian Linux fails to run on a specific submodel X of hardware Y, people
> who use that hardware are "excluded". Any of those cases can affect a much
> larger number of people than kFreeBSD support.

I think the difference with excluding a package is that nobody is
willing or able to do the work.  Perhaps the package requires more time
than the maintainer has, or it's a very difficult package to maintain
and nobody that wants to is able to.

In most cases, if a package is buggy on some platform, the porters will
either fix it or exclude it from that platform.  Nevertheless, we expect
Essential packages to work on all of our systems.  Since you're
interested in changing the status quo (which init is the default),
you're obligated to do most of the work to fix whatever breakage occurs.
This is true for most FLOSS projects, including the Linux kernel, not
just Debian.

> If it were possible to support every use case and every piece of hardware then
> things would be different. But it is not possible. You have to prioritize
> things. And it is exactly the lack of a rational approach to this that I was
> criticizing above. When a bug goes unfixed and that prevents a user from
> achieving whatever goal he had, that is no better than someone being unable to
> achieve what he wanted because kFreeBSD was not available (and in fact I'd say
> the latter would typically be less severe, as the typical goal would be just
> "play with kFreeBSD for its own sake").

The priority is based on who is willing to do the work.  I submit
patches to software I use if it is buggy because I want the bug fixed
*now*, usually because it's impeding my immediate work.  If it's that
important to me, I have to take some responsibility for fixing it if
that's within my capabilities.

Many people find kFreeBSD important to them and have consequently done
the work to bring it to fruition.  It appears that people have stepped
up to do the work to bring it to where it is.  It also appears that
Debian is keeping the FreeBSD kernel; the only safe assumption is that
Debian will continue to do so at least for the immediate future.  If
having systemd as the default init in Debian is very important to you,
you should probably put in the work to make it a viable choice for
Essential.  Right now, the portability problems make it not so.

> Supporting things like kFreeBSD is a lot of effort to benefit few
> people. If it's what a volunteer wants to work on then that is his
> right. But to insist that others should work on it is wrong;
> project-wide priorities should be based on rational decisions instead.
> And to compare "support kFreeBSD" and "make Linux work well for a
> larger number of people" and claim that kFreeBSD stands more for
> "inclusion" is nothing but bullshit rhetoric.

But here, the kFreeBSD porters (just like the porters, for say, sparc)
have done most of the work.  Yes, maintainers need to accept patches in
some cases.  But the porters do most of the work because that's what
interests them or perhaps because their employers need that
functionality or just because it's fun.

It's not uncommon to see people maintain software or ports that they may
already be using at work.  The Kerberos maintainers are an excellent
example here.  Several HP people help maintain the ia64 port.  And as
long as their work within Debian is for the benefit of Debian, who
cares?

If a package simply cannot be used on kFreeBSD, then ok, that happens.
Would it be nice if systemd were portable?  Yes.  But if we assume that
it's not, then we have to accept that.  The question here is whether
we're effectively willing to make a non-portable package part of
Essential.  The question would be the same if systemd pervasively used
unaligned accesses or inb/outb or some other non-portable construct.
Would we jettison sparc and ia64 in favor of it?

-- 
brian m. carlson / brian with sandals: Houston, Texas, US
+1 832 623 2791 | http://www.crustytoothpaste.net/~bmc | My opinion only
OpenPGP: RSA v4 4096b: 88AC E9B2 9196 305B A994 7552 F1BA 225C 0223 B187


signature.asc
Description: Digital signature

Re: DEP5 public-domain Question

[Russ Allbery]

Jakub Wilk  writes:
> * Russ Allbery , 2011-07-20, 11:06:

>> I think public domain in the Debian DEP-5 context is a license.  While
>> it's not legally a license, the public domain status serves the same
>> purpose: telling people what rights they have to use the work.  So I
>> would do something like:
>>
>> License: public-domain
>>  >  in the public domain>

> So what to put in the Copyright field? It's a required one.

I'd just say:

Copyright: Public Domain

-- 
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/87ei1kx0pv@windlord.stanford.edu

Re: DEP5 public-domain Question

[Lars Wirzenius]

On Wed, Jul 20, 2011 at 08:19:46PM +0200, Jakub Wilk wrote:
> So what to put in the Copyright field? It's a required one.

I'd do something like this:

Copyright: not applicable
License: public-domain
 This work was created by the government of the United States of
 America without any of the usual attempts to circumvent the
 policy that all such works are without copyright. It is therefore
 in the public domain. See http://... for information of how
 the work was created.

Or like this:

Copyright: nobody
License: public-domain
 The authors of this work live in a jurisdiction where the
 concept of public domain actually exists, and have gone through
 all the necessary steps to put the work into the public domain.
 These steps are document at http://... Thus, the usual
 misunderstanding that something is in the public domain,
 even though it isn't, do not apply. Yay.

Or even like this:

Copyright: no-one
License: public-domain
 This was created by unknown people across unknown aeons, and
 changed and updated by lots of more people. It was sung by
 medieval bards, and touched by that Shakespeare dude, and 
 possibly even Mary Queen of Scots. Who knows? Nobody knows,
 not even the Shadow knows! There is no evil lurking in the
 minds of anyone here. 
 .
 This work is therefore not copyrighted by anyone, and is as 
 much in the public domain as anything can be. Truly, utterly,
 totally. Be happy.

-- 
Freedom-based blog/wiki/web hosting: http://www.branchable.com/


-- 
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/20110720183318.gb7...@havelock.liw.fi

Re: A few observations about systemd

[Ben Hutchings]

On Wed, 2011-07-20 at 18:27 +, brian m. carlson wrote:
> On Wed, Jul 20, 2011 at 04:36:35PM +, Uoti Urpala wrote:
> > I think you're committing exactly the fallacy I described in the part you
> > snipped. You think that "excluding" people who want a particular kernel is
> > significant when it's a "big thing" like a kernel. But _any_ case of not
> > supporting something can be described as "exclusion". Any time a package is
> > dropped, Debian is "excluding" the people who want to use that package. 
> > Every
> > time a decision is made not to package something people are being 
> > "excluded".
> > When Debian Linux fails to run on a specific submodel X of hardware Y, 
> > people
> > who use that hardware are "excluded". Any of those cases can affect a much
> > larger number of people than kFreeBSD support.
> 
> I think the difference with excluding a package is that nobody is
> willing or able to do the work.  Perhaps the package requires more time
> than the maintainer has, or it's a very difficult package to maintain
> and nobody that wants to is able to.
> 
> In most cases, if a package is buggy on some platform, the porters will
> either fix it or exclude it from that platform.  Nevertheless, we expect
> Essential packages to work on all of our systems.
[...]

Er, no: http://packages.debian.org/squeeze/freebsd-utils

Ben.

-- 
Ben Hutchings
Absolutum obsoletum. (If it works, it's out of date.) - Stafford Beer


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

Re: A few observations about systemd

[brian m. carlson]

On Wed, Jul 20, 2011 at 08:44:43PM +0200, Ben Hutchings wrote:
> On Wed, 2011-07-20 at 18:27 +, brian m. carlson wrote:
> > In most cases, if a package is buggy on some platform, the porters will
> > either fix it or exclude it from that platform.  Nevertheless, we expect
> > Essential packages to work on all of our systems.
> [...]
> 
> Er, no: http://packages.debian.org/squeeze/freebsd-utils

I stand corrected.  I didn't recall that being essential last time I
looked, but it's been awhile.

-- 
brian m. carlson / brian with sandals: Houston, Texas, US
+1 832 623 2791 | http://www.crustytoothpaste.net/~bmc | My opinion only
OpenPGP: RSA v4 4096b: 88AC E9B2 9196 305B A994 7552 F1BA 225C 0223 B187


signature.asc
Description: Digital signature

Re: Bug#634811: ITP: dillo -- fast and light web browser based on FLTK 1.3

[Axel Beckert]

Hi Andrey,

Andrey Rahmatullin wrote:
> > > > On the other hand, Dillo's support for CSS and such is sketchy at best.
> > > > There's no javascript or anything of that kind as well.
> > > What about links2 -g?
> > [...]
> I mean, "how is dillo compared to links2 -g if they both have similar
> restrictions and links2 -g is (well, was in 2007) IIRC quite light and
> fast".

Ah, ok.

Well, links -g still looks a lot like being a text-mode application
even if run with its X interface. Especially all dialog popups are
rendered the same way they are rendered in text mode, i.e. no dialog
window, just a text frame around the question. And I expect that quite
some people prefer a more common way to render stuff under X.

Before having a working Dillo (again) I though can't make comparisons
about memory usage and speed. And I don't remember the values from
Dillo 1. And I don't expect them to be exactly the same as back then
anyway. :-)

Regards, Axel
-- 
 ,''`.  |  Axel Beckert , http://people.debian.org/~abe/
: :' :  |  Debian Developer, ftp.ch.debian.org Admin
`. `'   |  1024D: F067 EA27 26B9 C3FC 1486  202E C09E 1D89 9593 0EDE
  `-|  4096R: 2517 B724 C5F6 CA99 5329  6E61 2FF9 CD59 6126 16B5


-- 
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/20110720193449.gp29...@sym.noone.org

Re: A few observations about systemd

[Uoti Urpala]

brian m. carlson  crustytoothpaste.net> writes:
> On Wed, Jul 20, 2011 at 04:36:35PM +, Uoti Urpala wrote:
>> I think you're committing exactly the fallacy I described in the part you
>> snipped. You think that "excluding" people who want a particular kernel is
>> significant when it's a "big thing" like a kernel. But _any_ case of not
>> supporting something can be described as "exclusion". Any time a package is
>> dropped, Debian is "excluding" the people who want to use that package. Every
>> time a decision is made not to package something people are being "excluded".
>> When Debian Linux fails to run on a specific submodel X of hardware Y, people
>> who use that hardware are "excluded". Any of those cases can affect a much
>> larger number of people than kFreeBSD support.
> 
> I think the difference with excluding a package is that nobody is
> willing or able to do the work.  Perhaps the package requires more time
> than the maintainer has, or it's a very difficult package to maintain
> and nobody that wants to is able to.

How's this relevant to what you're replying to? What I was saying was that
there's no rational basis to call dropping kFreeBSD support "exclusion" and
claim that makes it somehow categorically different and worse than dropping
support for any random package. Both should be evaluated on the same scale. Your
reply doesn't seem to address this at all.


> Since you're
> interested in changing the status quo (which init is the default),
> you're obligated to do most of the work to fix whatever breakage occurs.
> This is true for most FLOSS projects, including the Linux kernel, not
> just Debian.

I have personal experience with these kind of issues, and the approach you seem
to favor does not work in practice when the changes are big and resources are
limited. Changing the status quo must be allowed to involve deprecating
something or leaving its handling to the people who personally want to keep the
particular feature. 

Compare introducing systemd to introducing libgtk2. libgtk2 was added to the
archive, applications migrated from gtk1 to gtk2, and eventually gtk1 support
was dropped and applications which required it were dropped with it. Suppose
someone brings systemd support to a level where it can be made the default on
Linux. Then daemons migrate to systemd files and eventually sysvinit support is
dropped and ports which still depend on sysvinit are dropped with it. Of course
we'd want to complete the transition faster than the time both gtk1 and gtk2
were available. But I think even dropping Hurd/kFreeBSD immediately would affect
fewer people than dropping gtk1 support did at the point it was done. Why should
users of kFreeBSD be considered more important than the people using gtk1-only
applications?


> But here, the kFreeBSD porters (just like the porters, for say, sparc)
> have done most of the work.  Yes, maintainers need to accept patches in
> some cases.  But the porters do most of the work because that's what
> interests them or perhaps because their employers need that
> functionality or just because it's fun.

If people who want to support kFreeBSD volunteer to handle everything related to
systemd compatibility then there's of course no problem and no reason to even
consider the issue when talking about whether to adopt systemd or not. If they
implement compatibility wrapper for systemd control files or a BSD port of
systemd itself (NOT patches to add BSD portability to Debian's main systemd
package; that would make it much harder to update to new upstream versions and
would likely cause regressions on Linux) then people can go on developing on
Linux and kFreeBSD will take care of itself. But it doesn't sound like people
are actually volunteering to do that.


> If a package simply cannot be used on kFreeBSD, then ok, that happens.
> Would it be nice if systemd were portable?  Yes.  But if we assume that
> it's not, then we have to accept that.  The question here is whether
> we're effectively willing to make a non-portable package part of
> Essential.  The question would be the same if systemd pervasively used
> unaligned accesses or inb/outb or some other non-portable construct.
> Would we jettison sparc and ia64 in favor of it?

I think calling systemd unqualified "nonportable" as opposed to everything else
being "portable" is somewhat misleading. It's not like every other package would
depend on strict standard POSIX functionality only. In this case the non-POSIX
functionality is just something that is not available on BSD.

"Unaligned accesses" sound like they'd indicate issues more likely to cause
problems on Linux too, and might also affect ability to run on any new processor
architecture (though of course then it might be reasonable to assume that
systemd would be fixed if an important new architecture appeared). But assuming
that would somehow not be the case and it would strictly be a question between
benefits of systemd vs benefits of keeping sparc and i

Re: A few observations about systemd

[Russell Coker]

Uoti, if you spend your time patching systemd for freebsd instead of arguing 
you will do more to get systemd supported.
-- 
My bloghttp://etbe.coker.com.au
Sent from an Xperia X10 Android phone


-- 
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/ebd529f6-39c1-4662-883a-afcf8bbc4...@email.android.com

Re: A few observations about systemd

[Uoti Urpala]

Russell Coker  coker.com.au> writes:
> Uoti, if you spend your time patching systemd for freebsd instead of arguing
> you will do more to get systemd supported.

Even assuming that Debian would fail to support systemd without such a port, I'd
rather spend my programming time working on software that I find interesting or
that is useful to a large number of people, not software that would exist
primarily for the sake of working around social problems in Debian.


-- 
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.20110721t003512-...@post.gmane.org

MediaWiki 1.17.0 new stable release from Wikimedia

[John W Foster]

There is a new stable release from Wikimedia of MediaWiki 1.17.0  Any
idea when we will see it packaged for Debian. It is said to support
substitution// {{subst}} & {{safesubst}} // so that the error message we
are getting with Ver. 1.15 will be resolved. It is an important upgrade
for those of us who use this software. Thanks!
Frosty


-- 
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/1311198411.10868.4.ca...@beast.home

Bug#634933: ITP: speechd-up -- Interface between Speech-dispatcher and Speakup

[jp]

Package: wnpp
Severity: wishlist
Owner: jp 


* Package name: speechd-up
  Version : 0.5~20110719
  Upstream Author : Hynek Hanke 
Kirk Reiser 
Jan Buchal 

* URL : git://github.com/williamh/speechd-up.git
* License : GPL-2
  Programming Lang: C
  Description : Interface between Speech-dispatcher and Speakup
 If you want to have sound on the console with a commercial speech synthetiser,
 such as ibmtts, you need a connector between the speech synthetiser and the
 speakup_soft module. As there has not been any usable connector since Squeeze,
 this package has this function. It is useless if you use a free speech
 synthetiser as Espeak, as a connector exists and is packaged; see the espeakup 
 package. It is also useless if you use speechd-el with Emacs.



-- 
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/20110721011235.28768.47797.reportbug@sid

Bug#634934: ITP: speakup-tools -- Tools to customize speakup module

[jp]

Package: wnpp
Severity: wishlist
Owner: jp 


* Package name: speakup-tools
  Version : 0.0~git20110720
  Upstream Author : The speakup Team
* URL : http://linux-speakup.org/speakup-tools.git
* License : GPL-2+
  Programming Lang: Shell-script

  Description : Tools to customize speakup module

 This package provides three scripts to configure and make easier using
 speakup_soft module. One script allows you to choose another language so that
 speakup's messages are in your language. talkwith allows you to change the used
 speech synthetiser, on the ply, as root user. speakupconf allows you to save 
 the user's settings and load them. It is important to keep your settings
 (language, pitch of your speech synthetiser, volume, etc.). It allows you to 
go 
 further than the kernel module itself, which provides the basic driver for the
 software speech synthetiser.



-- 
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/20110721011954.28963.34293.reportbug@sid

help with git

[Norbert Preining]

Hi everyone,

I have a question regarding git/debian/upstream.

I have a git repository on git.debian.org for packaging upstream,
and I push/pull from that to my local laptop dev.

I use git-import-org and friends, so the layout is:
$ git branch
  for-squeeze
  master
  pristine-tar
  upstream
$
where the master is generated from git-import-orig.

I now want to include upstream git into a branch, either the upstream
branch itself, or some other/new one, but I have no idea how
to set that up? 

Can someone help me here? The remote is some
git://gitorious.org//.git

By now I have added a remote to my .git/config:
[remote "upstream-git"]
url = git://gitorious.org/mu/mu-ng.git
fetch = +refs/heads/*:refs/remotes/upstream-git/*
tagopt = --tags

Set up with git remote add --tags upstream-git git://gitorious.org/mu/mu-ng.git

But somehow I don't manage to get a branch that follows that remote.
I tried to add:
[branch "upstream-new"]
remote = upstream-git
merge = refs/heads/master
but that tells me:
Your configuration specifies to merge with the ref 'master'
from the remote, but no such ref was fetched.

Sorry, I am a bit at loss here. Any suggestions how to do this properly?

Thanks and all the best

Norbert

Norbert Preiningpreining@{jaist.ac.jp, logic.at, debian.org}
JAIST, Japan TeX Live & Debian Developer
DSA: 0x09C5B094   fp: 14DF 2E6C 0307 BE6D AD76  A9C0 D2BF 4AA3 09C5 B094

GLOSSOP (n.)
A rouge blob of food. Glossops, which are generally streaming hot and
highly adhesive invariably fall off your spoon and on to the surface
of your host's highly polished antique-rosewood dining table. If this
has not, or may not have, been noticed by the company present, swanage
(q.v.) may be employed.
--- Douglas Adams, The Meaning of Liff


-- 
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/20110721021012.gc2...@gamma.logic.tuwien.ac.at

Bug#634940: ITP: tine20 -- Tine 2.0 is an webbased open source project which combines groupware and CRM in one consistent interface.

[Lars Kneschke]

Package: wnpp
Severity: wishlist
Owner: Lars Kneschke 


* Package name: tine20
  Version : 2011-05-1
  Upstream Author : Lars Kneschke 
* URL : http://www.tine20.org/
* License : AGPL-3
  Programming Lang: PHP, JavaScript
  Description : Tine 2.0 is an webbased open source project which combines 
groupware and CRM in one consistent interface.

Tine 2.0 is an webbased open source project which combines groupware and CRM
in one consistent 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/20110721034019.11760.13639.reportbug@localhost6.localdomain6

Re: MediaWiki 1.17.0 new stable release from Wikimedia

[Paul Wise]

On Wed, Jul 20, 2011 at 11:46 PM, John W Foster wrote:

> There is a new stable release from Wikimedia of MediaWiki 1.17.0  Any
> idea when we will see it packaged for Debian. It is said to support
> substitution// {{subst}} & {{safesubst}} // so that the error message we
> are getting with Ver. 1.15 will be resolved. It is an important upgrade
> for those of us who use this software. Thanks!

Please resend your mail to the bug report about this issue:

613...@bugs.debian.org
http://bugs.debian.org/613791

That said, it looks like the Debian maintainers of mediawiki need help
with it, so you might end up joining the team and doing the upgrade
yourself :)

-- 
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/CAKTje6Geyr=iUvwj8CdK0mAsy8=+vh31cnkffddzn3uso1t...@mail.gmail.com