Question about menus

2012-02-23 Thread Rodolfo kix Garcia 

Hi,

I am trying to change some things in the wmaker package menu. Now the 
"root" menu is something like:


Applications->
Help->
Workspace->
Run...
Exit

In the Application submenu are included the Debian menu categories.

Editors->
Graphics->
Terminals->
Tools->

This menu is generated using the wmaker menu-method. I understand all, 
no problem.


My question is, what do you think about move the contents of the 
Applications to the "root" menu?


Editors->
Graphics->
Terminals->
Tools->
Help->
Workspace->
Run...
Exit

And, in this case, how I do it? I read some things about the Debian 
Menu System, but in the functions 
(http://www.linux-cd.com.ar/manuales/debian-menu/ch7.html), I couldn't 
find nothing to remove "Applications/" from the menu files. parent() and 
basename() functions returns the "left" part of the section, and 
stripdir() removes the subsections. how I can do it?


Thanks.
kix

PS. I sent this mail to debian-mentors, but no reply.
--
||// //\\// Rodolfo "kix" Garcia
||\\// //\\ http://www.kix.es/


--
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/3cafe63decd34ac823649f02c55e8...@kix.es

Re: upstart: please update to latest upstream version

2012-02-23 Thread Thomas Hood 
I have a few questions.  First, to repeat the original question, will
we be seeing Upstart 1.4 in Debian experimental or unstable?

Second, I would be interested in reading a good technical comparison
of Upstart and systemd.  Does anyone have a URL for me?

I know the System V init system fairly well but I am new to both
Upstart and systemd. Obviously the two are similar insofar as they are
both able to supersede SysV init.  But my newbie impression is that
the two are fundamentally different, Upstart being event-oriented and
Systemd state-oriented from the user's point of view.  So the choice
between the two isn't just a matter of taste.  Analogy: We want to
rewrite an ancient line-numbered BASIC program and now have a choice
between Python and Prolog.  One of the two languages is likely to be
better suited to the task at hand.  Which is why I'd like to see a
good, objective technical comparison.

Or perhaps each language would be best suited to part of the task
formerly performed by the BASIC program.  Which raises a third
question: is there any point in using *both* Upstart and systemd?
Example off the top of my head: Upstart takes care of early boot and
starts systemd which in turn starts service daemons.  Does this make
any sense, and if so, what would be the advantages and disadvantages
of this?
-- 
Thomas Hood


-- 
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/cajn8kfday1kgofrokn1i3+qehh4y8pehb57vqqp9jnjm+rr...@mail.gmail.com

Re: Default display manager should not be gdm3

2012-02-23 Thread Josselin Mouette 
Le mercredi 22 février 2012 à 23:52 +, Ian Jackson a écrit : 
> I wanted to add a command-line option to my X server.  I spent 15 mins
> trawling through docs and grepping for config options with no luck.
> So I asked a search engine.

Actually there is a way in squeeze (since you’re talking about squeeze).

> It turns out that:
>  * There is no way to do this without patching the gdm source code
>or using dpkg-divert to wrap the X server with a shell script
>  * Such a feature was requested in a bug in the RH/Fedora bugzilla
>in June 2008 [1].  It's also in our BTS [2].  And in the upstream
>BTS multiple times with patches (September 2009, October 2010) [3].
>Despite a lot of demand, it still seems that this simple and
>essential feature simply wasn't on anyone's radar.
>  * Worse, in September 2011 one of the upstream authors seems to
>poo-poo the idea [4]!  It looks like they are resistant to sanity.

Because of course, everything just HAS to be black and white, doesn’t
it? EVIL upstream maintainers are just opposing SANE users requesting
such a useful feature.

This feature was in squeeze and so far we didn’t reinstate it in 3.x on
upstream request. This is because they complained people used this
feature to shoot themselves in the foot and then accused gdm of being
broken. Upstream hasn’t provided the promised workaround yet, so we’ll
probably patch it again in one way or another in wheezy, but frankly
this kind of reaction makes me think of all the other legitimate bugs I
could work on.

> gdm3 also has the crazy XAUTHORITY bug [5], which was reported
> to upstream [6] who inserted a completely crazy "fix" [7] showing they
> totally fail to understand how all this stuff is supposed to work.

Just because you disagree about how things are “supposed to work” (and
really, they don’t work that much on a variety of setups that use
~/.Xauthority), you don’t have to call people crazy.

> That bug was fixed in Debian by the X maintainers adding a workaround
> to the core X session startup scripts.  Madness.

This change now guarantees you can access your X servers regardless of
the state of your authority files. What you call madness, I’d call
reliability.

> We should not still be using this software.

Yes of course, we should be choosing the *default* software for display
management based on obscure features needed by a portion of developers.
(The same goes e.g. for nested displays; personally I’m missing the
feature a lot, but so far I haven’t received a single complaint.)

I’m not saying that gdm3 is perfect; I’m in a very good position to know
it is not, given the amount of patches we have to carry from upstream
and the ones that were rejected.  But I also know what it is good for;
for example multi-user and a11y support are not comparable to
alternatives.

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

Re: upstart: please update to latest upstream version

2012-02-23 Thread Lars Wirzenius 
On Thu, Feb 23, 2012 at 10:29:37AM +0100, Thomas Hood wrote:
> I know the System V init system fairly well but I am new to both
> Upstart and systemd. Obviously the two are similar insofar as they are
> both able to supersede SysV init.

I'm mostly a newbie with both, too. However, apart from technical
differences, I see the following as a serious issue: upstart requires
contributors to sign the Canonical contributor agreement
(http://www.canonical.com/contributors). That requirement would prevent
at least some people (including myself) from being interested in
working on upstart at all, unless paid.

-- 
http://www.kickstarter.com/projects/docstory/mix-1-2-albanian


signature.asc
Description: Digital signature

Re: upstart: please update to latest upstream version

2012-02-23 Thread Goswin von Brederlow 
Riku Voipio  writes:

> On Tue, Feb 21, 2012 at 01:12:08PM -0800, Steve Langasek wrote:
>> The meme that systemd is better than upstart because it doesn't depend on
>> a shell is poppycock.  No one has done any benchmarking to support the claim
>> that /bin/sh is a bottleneck for upstart (particularly not on Debian or
>> Ubuntu, where /bin/sh is dash, not bash);
>
> I have. Not on debian, but on debianish system with dash. And the result was
> that shellscripts are indeed the bottleneck. We still did convert to upstart
> since we believed it would allow us to cut down the amount of shell scripts.
> The event based architecture however forced much more shell scripting[1]
> that made the boot time improvement much less than hoped.
>
> Riku
>
> [1] stuff like this:
>
> -snip-
> post-start script
> # wait until daemon is ready
> timeout=6
> while [ ! -e /var/run/cups/cups.sock ]; do 
> sleep 0.5
> timeout=$((timeout-1))
> -snip-

Upstart also does not support Should-Start which makes it impossible to
provide corect init scripts for a number of services. For example autofs
will not work if it uses nis because nis is not started before
autofs. Due to the lack of Should-Start the only way to get nis to start
before autofs would require autofs to depends on nis.

This design flaw makes upstart unsuitable for Debian imho, where choice
and flexibility is a large part.

MfG
Goswin


-- 
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/87ty2hzuin.fsf@frosties.localnet

Intent to file mass bugreports for ia32-libs*

2012-02-23 Thread Goswin von Brederlow 
Hi,

the goal for wheezy is to support multiarch and that means we can finaly
get rid of the ugly ia32-libs packages. For this to happen all packages
used in ia32-libs need to be multiarchified.

The ia32-libs packages contain stuff from around 150 packages (less in
number of source packages) and a number of sources have already been
multiarchified. For the rest I intent to file bugs in 3 stages: Packages
used in ia32-libs-core, used in ia32-libs and last ia32-libs-gtk.

Depending on the number of bugs in each stage I will just file them or
post a dd-list. But this is your advance warning as per policy 7.1.1 in
case I don't follow up with a dd-list.

MfG
Goswin


-- 
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/87pqd5ztsy.fsf@frosties.localnet

Re: Please test gzip -9n - related to dpkg with multiarch support

2012-02-23 Thread Goswin von Brederlow 
Russ Allbery  writes:

> Goswin von Brederlow  writes:
>
>> Changing the name in the package would break tools that rely on the name
>> (like packages.debian.org extracting the Changelog). Also ugly.
>
> We control the tools; we can change the tools.  Multiarch is a big deal.
> We weren't going to get through this without changing some tools.  (One
> should not read that as my support of this specific alternative, as I've
> not decided there yet, but in general I think it's fair game to change our
> tools to support multiarch.)

One should not read that as my rejection of this specific alternative, as
I've not decided there yet, but in general I think it's fair game to
change our tools to support multiarch.


Problem I have is with the timeframe of such a change. While we can
change packages.d.o quite quickly given somebody willing to write the
patch we can not quickly change the tools in stable. And I really really
really do not want to have to wait yet another release cycle.

MfG
Goswin


-- 
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/87lintzq9k.fsf@frosties.localnet

Re: upstart: please update to latest upstream version

2012-02-23 Thread Thomas Hood 
On Thu, Feb 23, 2012 at 11:58, Goswin von Brederlow  wrote:
> Upstart also does not support Should-Start which makes it impossible
> to provide correct init scripts for a number of services. For example
> autofs will not work if it uses nis because nis is not started before
> autofs. Due to the lack of Should-Start the only way to get nis to
> start before autofs would require autofs to depends on nis.

Is it really impossible to implement correct behavior using Upstart?
Or is it just inconvenient to do so?

Addressing partly the above and partly my own request for a technical
comparison of Upstart and systemd, there is this:
http://upstart.ubuntu.com/cookbook/#critique-of-dependency-based-init-systems
--- but it doesn't go into much depth, isn't entirely unbiased and
doesn't actually name systemd.
-- 
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/CAJn8KfAxuQZu3OZDkqB5DDE7s9ia9k7WsR2xp=9pwabtyod...@mail.gmail.com

Re: upstart: please update to latest upstream version

2012-02-23 Thread Bernhard R. Link 
* Roger Leigh  [120223 01:47]:
> Yes, there is absolutely a big cost to pay in supporting multiple
> init systems.  Choice is good when there's a benefit, but we should
> not ignore the cost we pay.

If two init system are too much to support, I'd suggest to stay with
the init working for everyone and not support systemd at all.

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/20120223123238.ga16...@server.brlink.eu

Re: Multiarch file overlap summary and proposal

2012-02-23 Thread Goswin von Brederlow 
Russ Allbery  writes:

> If this is comprehensive, then I propose the following path forward, which
> is a mix of the various solutions that have been discussed:
>
> * dpkg re-adds the refcounting implementation for multiarch, but along
>   with a Policy requirement that packages that are multiarch must only
>   contain files in classes 1 and 2 above.
>
> * All packages that want to be multiarch: same have to move all generated
>   documentation into a separate package unless the maintainer has very
>   carefully checked that the generated documentation will be byte-for-byte
>   identical even across minor updates of the documentation generation
>   tools and when run at different times.
>
> * Lintian should recognize arch-qualified override files, and multiarch:
>   same packages must arch-qualify their override files.  debhelper
>   assistance is desired for this.

I think that, provided the files are byte for byte identical across
architectures they need not be arch qualified. So they should be
refcounted and having non-identical files across archs should be
forbidden by policy. The maintainer must then resolve this by 1) making
the file identical across archs or 2) arch qualifying the name.

So lintian should support arch qualified names but policy should not
needlessly require them.

> * Policy prohibits arch-varying data files in multiarch: same packages
>   except in arch-qualified paths.
>
> * The binNMU process is changed to add the binNMU changelog entry to an
>   arch-qualified file (changelog.Debian.arch, probably).  We need to
>   figure out what this means if the package being binNMU'd has a
>   /usr/share/doc/ symlink to another package, though; it's not
>   obvious what to do here.
>
> Please note that this is a bunch of work.  I think the Lintian work is a
> good idea regardless, and it can start independently.  I think the same is
> true of the binNMU changelog work, since this will address some
> long-standing issues with changelog handling in some situations, including
> resolving just how we're supposed to handle /usr/share/doc symlinks.  But
> even with those aside, this is a lot of stuff that we need to agree on,
> and in some cases implement, in a fairly short timeline if this is going
> to make wheezy.

In case /usr/share/doc/pkg is a symlink the binNMU changelog should be
stored in the destination of the symlink. For this to work the (binNMU)
changelog should be both arch and package qualified
(changelog.Debain.bin-pkg.arch). This would allow libfoo:any,
foo-bin:any + foo-common:all to be binNMUed. Without the package
qualifier the libfoo and foo-bin package would both contain
/usr/share/doc/foo-common/changelog.Debian.arch and produce a file
overwrite error.

After a binNMU (on amd64) the following files would exist:

foo-bin:/usr/share/doc/foo-bin -> foo-common
foo-bin:/usr/share/doc/foo-common/changelog.Debian.foo-bin.amd64
foo-common: /usr/share/doc/foo-common/changelog.Debian
libfoo: /usr/share/doc/foo-common/changelog.Debian.libfoo.amd64
libfoo: /usr/share/doc/libfoo -> foo-common

The binNMU changelogs would be identical wasting a little disk and
mirror space and bandwidth but that is probably unavoidable.

One way to reduce the overhead would be to split the binNMU entry into a
separate changelog:

foo-bin:/usr/share/doc/foo-bin -> foo-common
foo-bin:/usr/share/doc/foo-common/changelog.binNMU.foo-bin.amd64
foo-common: /usr/share/doc/foo-common/changelog.Debian
libfoo: /usr/share/doc/foo-common/changelog.binNMU.libfoo.amd64
libfoo: /usr/share/doc/libfoo -> foo-common

The binNMU changelogs would be just one entry each, the reason for the
binNMU.

MfG
Goswin


-- 
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/87d395zn6m.fsf@frosties.localnet

Re: Default display manager should not be gdm3

2012-02-23 Thread The Fungi 
On 2012-02-22 23:52:09 + (+), Ian Jackson wrote:
> On my netbook I'm running a pretty vanilla install of squeeze,
> although my personal desktop session is very different to usual.
> 
> I wanted to add a command-line option to my X server. I spent 15
> mins trawling through docs and grepping for config options with no
> luck.
[...]

On my netbook I run a very vanilla install of squeeze... base
packages only plus the few hand-picked apps I need, usually with
recommends omitted. I expect the desktop session on my netbook is
unusual as well--using a keyboard-driven window manager mainly to
multiplex xterms (which in turn are mostly containers for Gnu
screen), and to be able to specify window geometry and placement
since more recent apps don't implement the traditional X11
command-line switches to do that any more.

Maybe I don't use enough of the whiz-bang graphicky features lots of
people want, but I find logging into a vty and launching startx,
just like I have for decades, to work just fine. I'm certainly not
going to begrudge others their pointy-clicky fanciness, but I also
don't expect it to be particularly more stable or tunable than other
operating systems where that sort of interface is de rigueur.

Point being, xinit and friends still work just fine, at least on my
netbooks, workstations, et cetera.
-- 
{ 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); }


-- 
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/20120223134205.go...@yuggoth.org

Re: Multiarch file overlap summary and proposal

2012-02-23 Thread Goswin von Brederlow 
Russ Allbery  writes:

> Carsten Hey  writes:
>> * Russ Allbery [2012-02-16 14:55 -0800]:
>
>>> Every file that differs has to be fixed in the current multi-arch plan.
>>> Documentation that contains its build date is going to need to be split
>>> out into a separate -docs package.
>
>> I doubt that ftpmaster would be happy about -doc packages that contain
>> just a few small man pages.
>
> I think they'll be okay with it when it's the cost of reasonable
> multiarch.
>
> I feel fairly strongly that it isn't sane to have a file overlap when the
> file doesn't match.  You then lose the error detection when there are real
> problems, and I don't trust any of us, myself included, to correctly tag
> files where it doesn't matter.
>
> On this front, I agree with Guillem: some amount of package splitting is
> fine, and package splitting instead of additional complexity, like tagging
> files that are allowed to vary, looks like a good tradeoff to me.  The
> splitting that I'm worried about is where the files are tightly coupled,
> which is not the case for development man pages that are now in -dev
> packages.

+1.

I find the argument about past experience with splitting packages and
upstream later changing files so they become arch dependent convincing
in this regard. Refcounting and no exception for file differences seems
to be the best way.

>> debianutils uses a special make target 'prebuild' in debian/rules to
>> update build system related files and PO files before the actual source
>> package is built.
>
>> This basic idea also could be used to build problematic documentation
>> files on the maintainers computer before he/she builds the package.  The
>> other targets would then install the prebuilt documentation into the
>> package without the need to build it first.  A proper dependency on
>> debian/$prebuilt_doc could ensure that maintainers do not forget to run
>> debian/rules prebuild.
>
>> If maintainers choose to use such a target, suggesting a common name for
>> it in the developers reference could be reasonable.
>
> That's an interesting idea.  That's very similar to what I already do as
> upstream (I build POD-generated man pages from my autogen script, and in
> Debian packaging don't bother to regenerate them).

Indeed. Another +1.

You are probably not the only one doing something like this. Who else
does this? What automatism do you have in your debian/rules to help?
Lets see if we can get a good set of examples to work out some
recommendations.

MfG
Goswin


-- 
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/878vjtzmjj.fsf@frosties.localnet

Re: Default display manager should not be gdm3

2012-02-23 Thread Russ Allbery 
The Fungi  writes:

> Maybe I don't use enough of the whiz-bang graphicky features lots of
> people want, but I find logging into a vty and launching startx, just
> like I have for decades, to work just fine. I'm certainly not going to
> begrudge others their pointy-clicky fanciness, but I also don't expect
> it to be particularly more stable or tunable than other operating
> systems where that sort of interface is de rigueur.

I probably missed some key thing that makes this work, but the last time I
tried, using startx when you want to launch a desktop environment like
GNOME or Xfce was quite painful and confusing.

I do use startx on those systems where I just use fvwm2, but for a desktop
environment it was much easier to get things working when starting with a
login manager like gdm3.

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

Re: Multiarch file overlap summary and proposal

2012-02-23 Thread Goswin von Brederlow 
Josselin Mouette  writes:

> Le lundi 13 février 2012 à 22:43 -0800, Russ Allbery a écrit : 
>> There's been a lot of discussion of this, but it seems to have been fairly
>> inconclusive.  We need to decide what we're doing, if anything, for wheezy
>> fairly soon, so I think we need to try to drive this discussion to some
>> concrete conclusions.
>
> Thank you very much for your constructive work.
>
>> 3. Generated documentation.  Here's where I think refcounting starts
>>failing.
>
> So we need to move a lot of documentation generated with gtk-doc or
> doxygen from -dev packages to -doc packages. But it really seems an
> acceptable tradeoff between the amount of work required and the
> cleanness of the solution.
>
>> Does this seem comprehensive to everyone?  Am I missing any cases?
>
> Are there any cases of configuration files in /etc that vary across
> architectures? Think of stuff like ld.so.conf, where some plugins or
> library path is coded in a configuration file.

Generally conffiles in library packages is a violation of policy
8.2. They would create a file overwrite conflict if the SONAME
changes. Putting the conffile into the -common package is a good
solution.

There are some exceptions where the conffiles are version qualified.
E.g.: libgtk2.0-0: /etc/gtk-2.0/im-multipress.conf

For conffiles that vary across architectures the path or name must
include the multiarch triplet.
E.g: libc6: /etc/ld.so.conf.d/x86_64-linux-gnu.conf

(Note: this is actualy a violation of policy 8.2 and needs to be fixed
when we get a libc7).

MfG
Goswin


-- 
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/874nuhzm2m.fsf@frosties.localnet

Re: upstart: please update to latest upstream version

2012-02-23 Thread Russell Coker 
On Thu, 23 Feb 2012, "Bernhard R. Link"  wrote:
> * Roger Leigh  [120223 01:47]:
> > Yes, there is absolutely a big cost to pay in supporting multiple
> > init systems.  Choice is good when there's a benefit, but we should
> > not ignore the cost we pay.
> 
> If two init system are too much to support, I'd suggest to stay with
> the init working for everyone and not support systemd at all.

What are the big costs of supporting other init systems?

Systemd supports /etc/init.d/* scripts and I believe that upstart does the 
same.  Therefore anyone who maintains a package of a daemon is not REQUIRED to 
do anything different for systemd (and I presume upstart although I have never 
used it).

There are some daemons that can give a faster system boot by taking advantage 
of the way that systemd opens listening sockets.  But I don't think that 
anyone is suggesting that every daemon must be modified to do that.  I presume 
that people who are really enthusiastic about systemd will offer patches for 
the more commonly used daemons while less commonly used daemons will keep 
doing what they do now.

I've got a few systems running systemd right now.  So far the only problems I 
have encountered seem to be related to the use of cryptsetup.  Cryptsetup is a 
little unusual in terms of daemons in that it may prompt the user for a 
password and therefore requires keyboard access (which must be unique) and a 
possible indefinite amount of time for startup.  I wouldn't be surprised if 
cryptsetup needed a minor change to work well with systemd, but I don't think 
that counts as "a big cost to pay".


Now if we were to have the installation process ask for a choice of init 
systems then it would be a more significant change.  But so far no-one has 
asked for that.  It doesn't seem unreasonable to have one default init system 
per architecture and then allow the user to replace it with a different one 
after completing the basic installation process.

-- 
My Main Blog http://etbe.coker.com.au/
My Documents Bloghttp://doc.coker.com.au/


-- 
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/201202240116.20958.russ...@coker.com.au

Re: Multiarch file overlap summary and proposal

2012-02-23 Thread Goswin von Brederlow 
Joey Hess  writes:

> Goswin von Brederlow wrote:
>> pkg:arch will still be unique and the dpkg/apt output will use the
>> architecture where required for uniqueness. So I think that after some
>> getting used to it it will be clear enough again.
>
> Here are a few examples of the problems I worry about. I have not
> verified any of them, and they're clearly biased toward code I am
> familiar with, which suggests there are many other similar problems.
>
> * Puppet not only installs packages, it may remove them. A puppet config
>   that does dpkg --purge foo will fail if multiarch is enabled, now
>   it needs to find and remove foo:*
>
> * dpkg-repack pkg:arch will create a package with that literal name (or fail)
>
> * dpkg-reconfigure probably can't be used with M-A same packages.
>   debconf probably generally needs porting to multiarch.
>
> * tasksel uses dpkg --query to work out if a task's dependencies are
>   installed. In the event that a library is directly part of a task,
>   this will fail when multiarch is enabled.
>
> * Every piece of documentation that gives commands lines manipulating
>   library packages is potentially broken.
>
> Seems like we need a release where multiarch is classed as an
> experimental feature, which when enabled can break the system. But the
> sort of problems above are the easy to anticipate ones; my real worry is
> the unanticipated classes of problems. Especially if we find intractable
> problems or levels of complexity introduced by dropping the unique
> package name invariant.
>
> My nightmare scenario is that we release with multiarch, discover that
> it's a net negative for our users (proprietary software on amd64 aside,
> nearly all the benefits are to developers AFAICS), and are stuck with it.

The specs were initialy written in such a way that single arch systems
would not change, that multiarch packages would keep functioning with a
mono-arch apt/dpkg and I think this was preserved so far.

If all interface changes foolow that idea then worst case tools will not
work in a multiarch configuration but still work in a monoarch
configuration. So let multiarch be experimental and only for developers
and risk takers. That is already a huge number of people.

MfG
Goswin


-- 
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/87zkc9y6p4.fsf@frosties.localnet

Re: upstart: please update to latest upstream version

2012-02-23 Thread Marco d'Itri 
On Feb 23, "Bernhard R. Link"  wrote:

> If two init system are too much to support, I'd suggest to stay with
> the init working for everyone and not support systemd at all.
Not an option: we really need an events-based init system.
If you want legacy at all costs, I think that Slackware is looking for 
developers.

-- 
ciao,
Marco


signature.asc
Description: Digital signature

Re: upstart: please update to latest upstream version

2012-02-23 Thread Marco d'Itri 
On Feb 23, Russell Coker  wrote:

> What are the big costs of supporting other init systems?
> 
> Systemd supports /etc/init.d/* scripts and I believe that upstart does the 
> same.
The big cost is not in managing individual "simple" daemons, but in 
everything else which you can find in /etc/init.d/.
This is mostly about mounting file systems and enabling networking.

-- 
ciao,
Marco


signature.asc
Description: Digital signature

Re: Multiarch file overlap summary and proposal

2012-02-23 Thread Goswin von Brederlow 
Russ Allbery  writes:

> I think it would be better to have a world in which all the architectures
> of the foo package on the system have to have the same version, because
> then you don't have to treat foo:i386 and foo:amd64 like they're separate
> packages.  The list of installed architectures is an *attribute* of the
> package.  A package is still either installed or not installed, but when
> it's installed, it can be installed for one or more architectures.  But if
> it's installed for multiple architectures, those architectures are always
> upgraded together and always remain consistent.  That avoids all weirdness
> of having a package work differently because the version varies depending
> on the ABI, and it significantly simplifies the mental model behind the
> package.

In such a world architecture all could also be considered another
architecture. And then foo:i386, foo:amd64 and foo:all could be
coinstallable. That would mean that files shared between architectures
could be moved into foo:all and foo:any could implicitly depend on
foo:all. The benefit of this over foo-common would be that apt-cache
search, apt-cache policy, aptitude, dpkg --remove, ... would only have
one package (foo) instead of 2 (foo + foo-common).

This has been previously suggested too but has been droped because it
would be incompatible with existing systems (i.e. monoarch dpkg couldn't
install packages from such a world).

MfG
Goswin


-- 
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/87vcmxy6dk.fsf@frosties.localnet

Re: Default display manager should not be gdm3

2012-02-23 Thread Josselin Mouette 
Le jeudi 23 février 2012 à 05:54 -0800, Russ Allbery a écrit : 
> I probably missed some key thing that makes this work, but the last time I
> tried, using startx when you want to launch a desktop environment like
> GNOME or Xfce was quite painful and confusing.

There might be some remaining problems with consolekit despite its
Xsession.d integration, but in general there is no reason for big
trouble when starting GNOME or Xfce from startx.

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

Re: Multiarch file overlap summary and proposal

2012-02-23 Thread Goswin von Brederlow 
David Kalnischkies  writes:

> On Thu, Feb 16, 2012 at 23:10, Carsten Hey  wrote:
>> * David Kalnischkies [2012-02-16 03:59 +0100]:
>>> On Thu, Feb 16, 2012 at 00:39, Russ Allbery  wrote:
>>> (the only problem i see is that i don't have ${source:Version} available
>>>  currently in the version structure, but we haven't even tried pushing
>>>  apt's abibreak to sid specifically as i feared "last-minute" changes…)
>>
>> I'm not sure if you meant this with "Source tag", anyway, the 'Packages'
>> files miss the source version too, but this could be added as optional
>> field that would be used if it differs from the 'Version:' field.
>
> It's already in for quiet some time ('current' sid amd64, first hit):
> Package: 3depict
> Source: 3depict (0.0.9-1)
> Version: 0.0.9-1+b1
> […]
>
> It's used in other places in APT, e.g. 'apt-get source', which just looks
> at the Packages file stanza. That's fine as this isn't a speed critical
> operation - but if we want it for the lock-step operation apt needs that
> piece of information in its internal structures for fast access to it and
> adding new fields in these structures will require an abibreak.
> That's the intended meaning of the quoted sentence.

Except that doesn't have to work (sorry for the ubuntu part):

Package: gcc
Source: gcc-defaults (1.93ubuntu1)
Version: 4:4.4.3-1ubuntu1

What would the version be for a binNMU of gcc-defaults? I think it would
be

Package: gcc
Source: gcc-defaults (1.93ubuntu1)
Version: 4:4.4.3-1ubuntu1+b1

What we want is for apt/dpkg to consider this to be compatible with
"4:4.4.3-1ubuntu1".

MfG
Goswin


-- 
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/87r4xly64e.fsf@frosties.localnet

Re: How to tell users that ia32-libs will go away

2012-02-23 Thread Goswin von Brederlow 
Thibaut Paumard  writes:

> Le 09/02/12 15:53, Goswin von Brederlow a écrit :
>> Hi,
>> 
>> now that a multiarch dpkg has been uploaded to experimental it looks
>> like we can finaly get rid of ia32-libs* for wheezy.
>> 
>> !!!HURAY!!!
>> 
>> The problem now is the transition:
>> 
>> 1) multiarch and ia32-libs are incompatible
>>[...]
>> What this means is that users that want to use multiarch should remove
>> ia32-libs (and lib32* really) soonest.
>
> Couldn't you make ia32-libs a meta-package pulling the multiarch version
> of the libs it used to include ?

Waiting on ftp-master confirmation for this. The idea (see earlier in
the thread) was to have

Package: ia32-libs
Architecture: amd64
Depends: ia32-libs-i386

Package: ia32-libs-i386
Architecture: i386
Depends: libfoo, libbar, libbaz, ...
Multi-Arch: foreign

The trick with an extra package would avoid the not yet permitted
"Depends: libfoo:i386" syntax.

MfG
Goswin


-- 
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/87ipixy5ez.fsf@frosties.localnet

Re: Multiarch file overlap summary and proposal

2012-02-23 Thread Raphael Hertzog 
On Thu, 23 Feb 2012, Goswin von Brederlow wrote:
> > Package: 3depict
> > Source: 3depict (0.0.9-1)
> > Version: 0.0.9-1+b1
> 
> Except that doesn't have to work (sorry for the ubuntu part):
> 
> Package: gcc
> Source: gcc-defaults (1.93ubuntu1)
> Version: 4:4.4.3-1ubuntu1
> 
> What would the version be for a binNMU of gcc-defaults?

What about trying it?

$ head -n 1 debian/changelog 
gcc-defaults (1.112+b1) unstable; urgency=low
$ debuild -us -uc
[...]
$ dpkg -I ../gcc_4.6.2-4+b1_i386.deb 
[...]
 Package: gcc
 Source: gcc-defaults (1.112)
 Version: 4:4.6.2-4+b1

In any case, the fact that the source version is unrelated to the binary
version doesn't change anything to the requirement. We just want to ensure
that all (M-A: same) co-installable packages are synchronized at the same
version (either the source version, or the binary version but stripped
from its bin-NMU suffix).

Cheers,
-- 
Raphaël Hertzog ◈ Debian Developer

Pre-order a copy of the Debian Administrator's Handbook and help
liberate it: http://debian-handbook.info/liberation/


-- 
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/20120223145305.gd5...@rivendell.home.ouaza.com

Enabling package installation for non-root users

2012-02-23 Thread John Paul Adrian Glaubitz 
Hi,

I'm looking for a way to enable non-root users to install packages on
their local machines, but not removing/purging them.

I know that probably the proper way to achieve that is PackageKit, but I
was wondering if there is also a way to allow the use of apt-get, with
constraints for certain options.

A possible solution would be an entry like this in the /etc/sudoers:

user host=(root) NOPASSWD: /usr/bin/apt-get update
user host=(root) NOPASSWD: /usr/bin/apt-get install [[\:alpha\:]]*
user host=(root) NOPASSWD: /usr/bin/apt-get -s install [[\:alpha\:]]*

However, apt-get accepts options even after specifying the package list
and also allows to remove packages by appending a minus sign.

For example, with the above entries:

apt-get install -q  will fail, however, apt-get install
 - won't. Also, apt-get install - allows the removal
of packages which we don't want.

Is there a sane way to use /etc/sudoers like above or should we
completely refrain from that and use PackageKit?

Regards,

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/1330011138.26511.6.camel@z6

Re: Default display manager should not be gdm3

2012-02-23 Thread The Fungi 
On 2012-02-23 05:54:49 -0800 (-0800), Russ Allbery wrote:
> I probably missed some key thing that makes this work, but the
> last time I tried, using startx when you want to launch a desktop
> environment like GNOME or Xfce was quite painful and confusing.
[...]

Ahh, yes... I don't try. I'm just using ratpoison with no window
decorations or anything (or no WM at all in some cases, such as on
kiosk setups which spawn an xinit wrapper straight out of the
inittab which restarts automatically when the application is
closed). I'm not meaning to insult the maintainers and upstreams of
the popular *nix DEs, who do a remarkable job with an insanely
complex collection of features... rather I tend to agree with them
that if you want to tune your X in any fundamental way (even just to
pass a command-line option to the xserver as in Ian's original
complaint) then you probably aren't the intended audience for the
default package selection.

Maybe I unjustly characterize graphical desktop environments as
buggy and inflexible, but it seems to me that the login managers
themselves are no different from the rest of the prepackaged desktop
environments in that regard. I've always assumed "Desktop" in
tasksel (like anything in tasksel, really) was intended for people
who wanted something like Mac/Windows and couldn't be bothered to
figure out what specific packages they needed for their systems. I,
on the other hand, am OCD enough to want something approximating the
Unix workstations I grew up using which gave direct and deliberate
control over every aspect of presentation and interface--but that's
not to say that I want to go back to pre-CDE/Motif X technologies by
any means (I'm glaring at you, OPEN LOOK).
-- 
{ 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); }


-- 
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/20120223154149.gp...@yuggoth.org

Re: upstart: please update to latest upstream version

2012-02-23 Thread Goswin von Brederlow 
Thomas Hood  writes:

> On Thu, Feb 23, 2012 at 11:58, Goswin von Brederlow  wrote:
>> Upstart also does not support Should-Start which makes it impossible
>> to provide correct init scripts for a number of services. For example
>> autofs will not work if it uses nis because nis is not started before
>> autofs. Due to the lack of Should-Start the only way to get nis to
>> start before autofs would require autofs to depends on nis.
>
> Is it really impossible to implement correct behavior using Upstart?
> Or is it just inconvenient to do so?

Impossible, at least I have not found a way. The upstart syntax does not
allow for "wait for nis if nis is available", which is what autofs needs.

> Addressing partly the above and partly my own request for a technical
> comparison of Upstart and systemd, there is this:
> http://upstart.ubuntu.com/cookbook/#critique-of-dependency-based-init-systems
> --- but it doesn't go into much depth, isn't entirely unbiased and
> doesn't actually name systemd.

I think both dependencies and events have merrits. What I like in
systemd design is that it mostly removes the need for dependencies since
things simply block when they try to access something that isn't running
yet. So like with upstart events services run when their prerequisites
become available.

But for me all the new init systems have a fundamental lack: They do not
have priorities.

Say you have a desktop system but also have apache, postgresql, ... for
some developement work installed. First thing you need when you turn it
on is your desktop. The apache and postgresql do not need to be running
for you to log in and read your mail. On the other hand you do not want
to have to wait for them to start up when you first access them.

So what is needed is a priotization of services. The user specifies in
some way that X has priority and only prerequisites of that should be
started. Only once that is done other services can be started.

Similar for a server. There will be some services that are more
important to bring up than others.

This goes double for running fsck. Run it first on the filesystems
needed for the important services.

MfG
Goswin


-- 
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/877gzdy2z2.fsf@frosties.localnet

Re: upstart: please update to latest upstream version

2012-02-23 Thread Marco d'Itri 
On Feb 23, Goswin von Brederlow  wrote:

> Say you have a desktop system but also have apache, postgresql, ... for
> some developement work installed. First thing you need when you turn it
> on is your desktop. The apache and postgresql do not need to be running
> for you to log in and read your mail. On the other hand you do not want
> to have to wait for them to start up when you first access them.
This should be trivial to implement: make these services conditional on 
a specific event/state and enable that state in ~/.xsession and/or 
a given time after booting.

> This goes double for running fsck. Run it first on the filesystems
> needed for the important services.
This is managed in /etc/fstab.

-- 
ciao,
Marco


signature.asc
Description: Digital signature

Re: upstart: please update to latest upstream version

2012-02-23 Thread Bernhard R. Link 
* Marco d'Itri  [120223 15:24]:
> Not an option: we really need an events-based init system.
> If you want legacy at all costs, I think that Slackware is looking for
> developers.

What's the supposed answer to this kind of ad hominem attack?
Asking you if you have too many Microsoft shares to allow Linux to
actually work?

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/20120223155737.ga2...@client.brlink.eu

Re: Enabling package installation for non-root users

2012-02-23 Thread Neil Williams 
On Thu, 23 Feb 2012 16:32:18 +0100
John Paul Adrian Glaubitz  wrote:

> Hi,
> 
> I'm looking for a way to enable non-root users to install packages on
> their local machines, but not removing/purging them.

At which point, you lose anyway because sometimes package installation
*requires* removal of another package. Plus the type of package has to
be considered - if someone chooses to install a different web server
package or a different MTA or kernel, things could become complicated.

You could avoid those problems by only having a partial local mirror of
"allowed" packages and prevent changes to other packages (because
the other packages are not listed) unless an admin moves an inactive
sources.list into place. That then complicates automatic admin updates
and adds another admin task, plus if someone does an autoremove
before adding the full source list back ... generally that's a world of
pain too.

BTW: you don't actually need root to download and unpack packages -
just as long as you unpack to an unprivileged path, it's just that this
a whole different world of pain which is primarily to support chroots
and rootfs creation etc.

What are you trying to allow / prevent?

If you want packages to behave normally, you need to install them
normally...

Anything else is just making the systems harder to administrate.

-- 


Neil Williams
=
http://www.linux.codehelp.co.uk/



pgpA65YbokBnA.pgp
Description: PGP signature

Re: upstart: please update to latest upstream version

2012-02-23 Thread Ben Hutchings 
On Thu, 2012-02-23 at 16:57 +0100, Bernhard R. Link wrote:
> * Marco d'Itri  [120223 15:24]:
> > Not an option: we really need an events-based init system.
> > If you want legacy at all costs, I think that Slackware is looking for
> > developers.
> 
> What's the supposed answer to this kind of ad hominem attack?
[...]

That is not an ad hominem attack.  Ad hominem would be dismissing the
opponent with 'but you are just an old fart'.

Many people seem to argue that 'we know the old stuff and it works
everywhere'.  The second point, 'it works everywhere' isn't really true
as there is a constant stream of bugs in init scripts and inherent
problems with the lack of real service control in sysvinit.  That leaves
'we know the old stuff' (and 'it mostly works on kFreeBSD').  And Marco
is attacking that first point.

Ben.

-- 
Ben Hutchings
If at first you don't succeed, you're doing about average.


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

Re: Enabling package installation for non-root users

2012-02-23 Thread Josselin Mouette 
Hi,

Le jeudi 23 février 2012 à 16:32 +0100, John Paul Adrian Glaubitz a
écrit : 
> I'm looking for a way to enable non-root users to install packages on
> their local machines, but not removing/purging them.
> 
> I know that probably the proper way to achieve that is PackageKit, but I
> was wondering if there is also a way to allow the use of apt-get, with
> constraints for certain options.

At work we use aptdaemon to do that. You only need to add a pkla file to
authorize the relevant actions, and aptdcon / software-center will allow
installation from the users you authorize (typically, users physically
logged on the machine).

(We even have a patch to allow only a subset of packages but it is
unfortunately a bit too hackish.)

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

Re: Enabling package installation for non-root users

2012-02-23 Thread Timo Juhani Lindfors 
Josselin Mouette  writes:
> (We even have a patch to allow only a subset of packages but it is
> unfortunately a bit too hackish.)

Would be really nice to have some standard sets available (think
"browser extensions", "command-line tools that ship no services or suid
binaries"). I'd certainly let my desktop users install these without
having to ask me or having to install them manually to their $HOME..


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

Re: upstart: please update to latest upstream version

2012-02-23 Thread Bernhard R. Link 
* Ben Hutchings  [120223 17:34]:
> On Thu, 2012-02-23 at 16:57 +0100, Bernhard R. Link wrote:
> > * Marco d'Itri  [120223 15:24]:
> > > Not an option: we really need an events-based init system.
> > > If you want legacy at all costs, I think that Slackware is looking for
> > > developers.
> >
> > What's the supposed answer to this kind of ad hominem attack?
> [...]
>
> That is not an ad hominem attack.  Ad hominem would be dismissing the
> opponent with 'but you are just an old fart'.

It's ad hominem because of "If you want legacy at all costs".
Dismissing my argument by simply claiming that systemd being inferior
in my eyes is my fault is no way to convince me.

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/20120223163944.ga3...@client.brlink.eu

Re: Default display manager should not be gdm3

2012-02-23 Thread Steve Langasek 
On Thu, Feb 23, 2012 at 08:56:22AM +0100, Vincent Bernat wrote:
> Moreover, other display  manager may not work correctly  because gdm3 is
> the only  display manager supporting  all modern stuff. For  example, we
> could switch to  something like "slim" but slim does  not play nice with
> ConsoleKit which means that a  user logged with slim won't be considered
> as a  local user and therefore  won't have rights  for power management,
> network configuration and things like that. See:
>  http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=601003

Shouldn't that be trivial to address with the use of the pam_ck_connector
module?

-- 
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

Re: upstart: please update to latest upstream version

2012-02-23 Thread Bernhard R. Link 
* Ben Hutchings  [120223 17:34]:
> Many people seem to argue that 'we know the old stuff and it works
> everywhere'.  The second point, 'it works everywhere' isn't really true
> as there is a constant stream of bugs in init scripts and inherent
> problems with the lack of real service control in sysvinit.

My point is that every init system will have a constant stream of
problems. There simply is no way anyone will ever write a system that
always work. Currently we have a system where every user has a chance to
debug and fix those problems and make their system work again. systemd
is something where mostly only a systemd developer will be able to fix
stuff (It's easy to add some echo to a init.d script, debugging C code
is not that easy). Thus anyone with problems mostly has a choice of
reinstalling, giving up or switching to something else.

> That leaves'we know the old stuff' (and 'it mostly works on kFreeBSD').
> And Marco is attacking that first point.

By suggesting anyone that knows the old system should leave Debian?

I've no problem with Debian supporting multiple init systems. But if
someone claims maintaince costs are too high for that, that is in my
eyes a reason against supporting systemd, not for only having it.

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/20120223165431.gb3...@client.brlink.eu

Re: Default display manager should not be gdm3

2012-02-23 Thread Fernando Lemos 
Em 23/02/2012 14:58, "Steve Langasek"  escreveu:
>
> On Thu, Feb 23, 2012 at 08:56:22AM +0100, Vincent Bernat wrote:
> > Moreover, other display  manager may not work correctly  because gdm3 is
> > the only  display manager supporting  all modern stuff. For  example, we
> > could switch to  something like "slim" but slim does  not play nice with
> > ConsoleKit which means that a  user logged with slim won't be considered
> > as a  local user and therefore  won't have rights  for power management,
> > network configuration and things like that. See:
> >  http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=601003
>
> Shouldn't that be trivial to address with the use of the pam_ck_connector
> module?

Unfortunately, no. Since CK 0.4.3, if i'm not mistaken, you only get
an active and local CK session if you specify the X display and the
tty for the session creation (through libck-connector).

LightDM works well with CK. XDM can be patched, there are patches
available in the mailing list, but I think they never got merged.

There's more info about CK vs. DMs in a bug I filed against XDM some
time ago, I can't look it up right now.

Regards,


--
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/canvyna9+elrg2gq52ud3axr91qbrgfeeuhbdzdcdesypxay...@mail.gmail.com

Re: upstart: please update to latest upstream version

2012-02-23 Thread Josselin Mouette 
Le jeudi 23 février 2012 à 17:54 +0100, Bernhard R. Link a écrit : 
> I've no problem with Debian supporting multiple init systems. But if
> someone claims maintaince costs are too high for that, that is in my
> eyes a reason against supporting systemd, not for only having it.

Seriously, this constant obstruction to improving the Debian system by a
minority of whiners who don’t contribute much to relevant parts of the
system but have an opinion on everything is getting intolerable.

System V init is dying. It might be the most awesome init system for
you, and actually it has been for a some time, but that doesn’t change
that fact. Developers are not going to tolerate its limitations anymore
now there are better alternatives.

Want one example? Unless someone writes missing pieces of code, and I
fail to see why they would, some GNOME 3.4 packages (yes this is for
wheezy) might have a Recommends: systemd. It’s not that I love it (I
still don’t even use it myself) but despite all the flames around it and
the destructive personality of the main developer, I can’t find any good
reason not to do that. Does it break anything? No. Does it make it
impossible for you to use this or that other package? No. It only
prevents you from hacking some shell scripts which, anyway, shouldn’t
exist to begin with. 

I’m afraid I don’t find your use case very compelling.

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

Re: Enabling package installation for non-root users

2012-02-23 Thread Matthias Klumpp 
2012/2/23 Timo Juhani Lindfors :
> Josselin Mouette  writes:
>> (We even have a patch to allow only a subset of packages but it is
>> unfortunately a bit too hackish.)
>
> Would be really nice to have some standard sets available (think
> "browser extensions", "command-line tools that ship no services or suid
> binaries"). I'd certainly let my desktop users install these without
> having to ask me or having to install them manually to their $HOME..

It would be even better to talk to the PackageKit team for
standardization ;-) (We're already working on this to support some
APTd features (Fix broken package DB for example) - most other things
are already present.)
You can change the PK settings using PolicyKit. Limiting installations
to a group of packages is not possible at time. (and not planned -
what if a package in group X requires a package of group Y? Users
could easily work around this limitation by creating a dummy package
in group X which pulls in the package from group Y, which they want.)
Cheers,
   Matthias Klumpp


-- 
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/caknhny9obnwzy4rsjgfzhzqx43aqpofvl9+mewt8y4df9jc...@mail.gmail.com

Re: upstart: please update to latest upstream version

2012-02-23 Thread Bernhard R. Link 
* Josselin Mouette  [120223 18:36]:
> Seriously, this constant obstruction to improving the Debian system by a
> minority of whiners who don’t contribute much to relevant parts of the
> system but have an opinion on everything is getting intolerable.

As long as you react to everything not your opinion with insults I will
not take much efford to fix your packages but rather try to get the
packages I use in a working state.

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/20120223174211.ga10...@client.brlink.eu

Re: Enabling package installation for non-root users

2012-02-23 Thread Josselin Mouette 
Le jeudi 23 février 2012 à 18:57 +0100, Matthias Klumpp a écrit : 
> You can change the PK settings using PolicyKit. Limiting installations
> to a group of packages is not possible at time. (and not planned -
> what if a package in group X requires a package of group Y? Users
> could easily work around this limitation by creating a dummy package
> in group X which pulls in the package from group Y, which they want.)

Huh? Sorry but I fail to see what you would work around with that.
Building a package doesn’t upload it to a repository.

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


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

Re: upstart: please update to latest upstream version

2012-02-23 Thread Josselin Mouette 
Le jeudi 23 février 2012 à 17:39 +0100, Bernhard R. Link a écrit : 
> * Ben Hutchings  [120223 17:34]:
> > That is not an ad hominem attack.  Ad hominem would be dismissing the
> > opponent with 'but you are just an old fart'.
> 
> It's ad hominem because of "If you want legacy at all costs".
> Dismissing my argument by simply claiming that systemd being inferior
> in my eyes is my fault is no way to convince me.

Why do we need to convince an old fart?

-- 
 .''`.  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/1330022427.13079.2.camel@tomoyo

please advice: restrict architectures in advance or leave it alone?

2012-02-23 Thread Yaroslav Halchenko 
Hi,

I am about to upload a fresh new package -- CDE
http://www.stanford.edu/~pgbovine/cde.html
which is heavily based on strace (pretty much it is a code fork of
strace to provide necessary functionality).

Upstream author maintains it for x86 architectures only and
unfortunately has neither time, nor hardware (nor intention at the
moment) to support others.

I know that it would fail to build on powerpc, sparc and most probably
would fail to build on anything else (but x86 linux) from the list
of architectures strace supports.  so the question -- should I even
bother to upload attempting to build for that wide set of architectures
or should immediately restrict to amd64 and i386?

would porters be interested in contributing to patch it for those other
architectures (upstream author says that it shouldn't be hard but might
be trickier to test since his test battery is not yet made generally
usable)?

Thank you in advance for the feedback
-- 
=--=
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/20120223184903.ge17...@onerussian.com

Re: Enabling package installation for non-root users

2012-02-23 Thread Matthias Klumpp 
2012/2/23 Josselin Mouette :
> Le jeudi 23 février 2012 à 18:57 +0100, Matthias Klumpp a écrit :
>> You can change the PK settings using PolicyKit. Limiting installations
>> to a group of packages is not possible at time. (and not planned -
>> what if a package in group X requires a package of group Y? Users
>> could easily work around this limitation by creating a dummy package
>> in group X which pulls in the package from group Y, which they want.)
>
> Huh? Sorry but I fail to see what you would work around with that.
> Building a package doesn’t upload it to a repository.
Ah, okay - so this only works for repos... In that case, the borders
between certain groups are fluent too... What if a package of group X
should be installed, which requires one of group Y but the user is
only allowed to install stuff from X? (I'm not against this
possibility, it just looks very unclear which policy should apply)
Cheers,
   Matthias


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

Re: Intent to file mass bugreports for ia32-libs*

2012-02-23 Thread Steve Langasek 
On Thu, Feb 23, 2012 at 12:13:33PM +0100, Goswin von Brederlow wrote:
> the goal for wheezy is to support multiarch and that means we can finaly
> get rid of the ugly ia32-libs packages. For this to happen all packages
> used in ia32-libs need to be multiarchified.

> The ia32-libs packages contain stuff from around 150 packages (less in
> number of source packages) and a number of sources have already been
> multiarchified. For the rest I intent to file bugs in 3 stages: Packages
> used in ia32-libs-core, used in ia32-libs and last ia32-libs-gtk.

> Depending on the number of bugs in each stage I will just file them or
> post a dd-list. But this is your advance warning as per policy 7.1.1 in
> case I don't follow up with a dd-list.

When filing these bugs, please cross-check with the list of already-filed
bugs for multiarch support:

  
http://bugs.debian.org/cgi-bin/pkgreport.cgi?users=multiarch-de...@lists.alioth.debian.org;tag=multiarch

And please use this same usertag for any bugs you file.

-- 
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

Re: mass bug filing of 'ucf: command not found' errors detected by piuparts

2012-02-23 Thread Andreas Beckmann 
On 2012-01-31 18:14, Andreas Beckmann wrote:
> I'm planning to file bugs against all packages that currently fail the
> piuparts test with a 'ucf: command not found' error in wheezy and sid.

As ucf became transitively essential in the mean time, this mass bug
filing is postponed until this problem can be easily checked again.

Andreas


-- 
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/4f469a4e.8020...@abeckmann.de

Re: upstart: please update to latest upstream version

2012-02-23 Thread Tzafrir Cohen 
On Thu, Feb 23, 2012 at 07:24:20AM +0100, Tollef Fog Heen wrote:
> ]] Tzafrir Cohen 
> 
> > In sysv init scripts the daemon forks into the background. In upstrart
> > and systemd it doesn't have to (or shouldn't). (not) forking requires a
> > different command-line argument, normally. This leads to odd beasts such
> > as safe_mysqld.
> 
> You can just use the --background switch to start-stop-daemon with
> sysvinit scripts.

It's still a different command. And anyway, very often the daemon itself
needs to handle the PID files, which means that I can't use that.

But more importantly, start-stop-daemon only starts and stops the daemon
once. It's not a daemon monitor. Would there be any objection if I
replaced init.d scripts in some of my packages with runit configs (as
does the git daemon)?

-- 
Tzafrir Cohen | tzaf...@jabber.org | VIM is
http://tzafrir.org.il || a Mutt's
tzaf...@cohens.org.il ||  best
tzaf...@debian.org|| friend


-- 
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/20120223200818.gh9...@pear.tzafrir.org.il

mass bug filing against packages that don't remove alternatives

2012-02-23 Thread Andreas Beckmann 
Hi,

I'm planning to file bugs against all packages that currently leave
alternatives on the system after they were removed. Forgetting to remove
alternatives usually leaves dangling symlinks on the system and in most
cases these are dangling symlinks in /usr/bin

At the moment there are 20 packages in wheezy and 13 in sid with this
problem (a few bugs are already filed), eventually some of these are
only depending on a buggy package.
Furthermore there is a currently unchecked number of packages that don't
properly migrate alternatives on upgrades from squeeze, about 300 logs
show the symptoms but most of these are probably caused by dependencies,
the number of buggy packages is hopefully much smaller.

These bugs were found by further analyzing the piuparts logfiles but
there is currently no separate report for them on piuparts.d.o.
For piuparts this is an error for the sid test (leaving unowned files
after purge), but for all other tests this is only a warning to allow
testing more packages for more serious issues.

I'll file these bugs with Severity: important since having a piuparts
clean archive is a release goal since lenny.
Or is this a policy violation that would warrant a higher severity,
especially if the package leaves dangling symlinks in /usr/bin?

A dd-list for wheezy+sid (19 source packages) is appended, this may
include packages that already had bugs filed (and these of course won't
see a new bug report).

Andreas


Blars Blarson 
   xview

Bradley Bell 
   rt-extension-assettracker (U)

Branden Robinson 
   ctwm

Damien Raude-Morvan 
   icedtea-web (U)

David Banks 
   sisc

Debian Dia Team 
   dia
   dia-shapes

Debian freesmartphone.org Team 
   vala-terminal

Debian QA Group 
   xview

Debian Request Tracker Group

   request-tracker3.8
   request-tracker4
   rt-extension-assettracker
   rt-extension-emailcompletion
   rtfm

Dmitry Smirnov 
   request-tracker4 (U)

Dominic Hargreaves 
   request-tracker3.8 (U)
   request-tracker4 (U)
   rt-extension-assettracker (U)
   rt-extension-emailcompletion (U)
   rtfm (U)

Enrico Tassi 
   lua5.2

Ivan Kohler 
   request-tracker3.8 (U)

Jacob Helwig 
   request-tracker3.8 (U)

Joachim Breitner 
   vala-terminal (U)

John V. Belmonte 
   lua5.2 (U)

Julian Andres Klode 
   sessioninstaller

Luca Bruno 
   uzbl
   uzbl (U)

Matthias Klose 
   icedtea-web (U)

Niko Tyni 
   request-tracker3.8 (U)
   request-tracker4 (U)
   rtfm (U)

Ola Lundqvist 
   vnc4

OpenJDK Team 
   icedtea-web

Philipp Kaluza 
   vala-terminal (U)

Python Applications Packaging Team

   trac-diavisview

Roland Stigge 
   dia (U)
   dia-shapes (U)

Sebastian Reichel 
   vala-terminal (U)

Stefan Ritter 
   uzbl

Thomas Bechtold 
   dia-shapes (U)

Toni Mueller 
   request-tracker3.8 (U)

Torsten Landschoff 
   fox1.6

Trent W. Buck 
   mg

W. Martin Borgert 
   trac-diavisview (U)

Wolfgang Borgert 
   dia (U)
   dia-shapes (U)


-- 
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/4f46a63d.3080...@abeckmann.de

Re: mass bug filing against packages that don't remove alternatives

2012-02-23 Thread Jakub Wilk 

* Andreas Beckmann , 2012-02-23, 21:49:
I'm planning to file bugs against all packages that currently leave 
alternatives on the system after they were removed. Forgetting to 
remove alternatives usually leaves dangling symlinks on the system and 
in most cases these are dangling symlinks in /usr/bin


The problem with alternatives is that nobody knows how to handle them 
correctly: see bug #71621 (no, I didn't forget the leading digit).


--
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/20120223205927.ga1...@jwilk.net

Re: upstart: please update to latest upstream version

2012-02-23 Thread Salvo Tomaselli 
> But for me all the new init systems have a fundamental lack: They do not
> have priorities.

I think that's gone already.. update-rc.d already does whatever it wants with 
the priorities.

-- 
Salvo Tomaselli


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

Re: upstart: please update to latest upstream version

2012-02-23 Thread Tollef Fog Heen 
]] "Bernhard R. Link" 

> My point is that every init system will have a constant stream of
> problems. There simply is no way anyone will ever write a system that
> always work. Currently we have a system where every user has a chance to
> debug and fix those problems and make their system work again. systemd
> is something where mostly only a systemd developer will be able to fix
> stuff (It's easy to add some echo to a init.d script, debugging C code
> is not that easy). Thus anyone with problems mostly has a choice of
> reinstalling, giving up or switching to something else.

Your shell is most likely implemented in C, but it's not like you sit
down and have to debug it every other day.  Why do you assume that you
need to do so just because policy is encoded in .ini-like files instead
of shell scripts?

[...]

> I've no problem with Debian supporting multiple init systems. But if
> someone claims maintaince costs are too high for that, that is in my
> eyes a reason against supporting systemd, not for only having it.

Systemd is already in Debian, works for quite some people does not
impose any maintenance burden on people who don't use it.  I really
don't see why you keep advocating removing it.

-- 
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/877gzd2qmj@qurzaw.varnish-software.com

Re: Policy 3.9.3 released

2012-02-23 Thread Andreas Tille 
Hi,

On Wed, Feb 22, 2012 at 08:07:10PM -0800, Russ Allbery wrote:
> mime
>  This separate document has been retired and and its (short)
>  contents merged into Policy section 9.7.  There are no changes to
>  the requirements.

Does this have any influence on #658139?  As far as I can see this bug
is related and I wonder whether this bug should be RC critical.

Kind regards

   Andreas.

-- 
http://fam-tille.de


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

Re: Policy 3.9.3 released

2012-02-23 Thread Russ Allbery 
Andreas Tille  writes:
> On Wed, Feb 22, 2012 at 08:07:10PM -0800, Russ Allbery wrote:

>> mime
>>  This separate document has been retired and and its (short)
>>  contents merged into Policy section 9.7.  There are no changes to
>>  the requirements.

> Does this have any influence on #658139?

This particular change is unrelated.  It just moved language from one
document to another; there was no change to the substance of the language.
(As such, it was borderline for upgrading-checklist, but since it affected
the www.debian.org copies and might have affected other dangling
references in documentation, I wanted to make sure people knew it
happened.)

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

Re: upstart: please update to latest upstream version

2012-02-23 Thread Russell Coker 
On Fri, 24 Feb 2012, "Bernhard R. Link"  wrote:
> > > > Not an option: we really need an events-based init system.
> > > > If you want legacy at all costs, I think that Slackware is looking
> > > > for developers.
> > >
> > > What's the supposed answer to this kind of ad hominem attack?
> > 
> > [...]
> > 
> > That is not an ad hominem attack.  Ad hominem would be dismissing the
> > opponent with 'but you are just an old fart'.
> 
> It's ad hominem because of "If you want legacy at all costs".
> Dismissing my argument by simply claiming that systemd being inferior
> in my eyes is my fault is no way to convince me.

http://en.wikipedia.org/wiki/Ad_hominem
http://en.wikipedia.org/wiki/Straw_man

It seems to me that it's more of a Straw Man attack than an Ad Hominem.  
Although it's not a total straw-man as it seems that the people who are 
opposed to new init systems are making too much of an issue out of legacy 
support.  In the time I've been using Debian we have had a couple of major 
changes of libc, a change of executable format, huge and significant changes 
to the kernel and the way it's packaged, replacement of the old static /dev 
with udev (and a diversion via devfs along the way), replacement of syslogd, 
and lots more.  It seems that the only things which haven't changed 
significantly are init and cron.  So reviewing those things in light of all 
the other changes seems sensible.

On Fri, 24 Feb 2012, "Bernhard R. Link"  wrote:
> My point is that every init system will have a constant stream of
> problems. There simply is no way anyone will ever write a system that
> always work. Currently we have a system where every user has a chance to
> debug and fix those problems and make their system work again. systemd
> is something where mostly only a systemd developer will be able to fix
> stuff (It's easy to add some echo to a init.d script, debugging C code
> is not that easy). Thus anyone with problems mostly has a choice of
> reinstalling, giving up or switching to something else.

Debian has already become rather difficult to debug.  During the text boot 
process we have a change to the video mode which resets the scroll-back buffer 
and makes it difficult to read early messages that appear on the console.  Now 
a serial console can make some of these things easier to debug but a recent 
hardware trend is towards making systems without a serial port.

Is there any way of capturing the old text output from /dev/console at a later 
stage in the boot?

Also a recent hardware trend is to make systems without a PS/2 keyboard port.  
It seems that the USB modules don't get loaded from the initramfs if you 
configure it with modules=dep which makes the recovery option of 
init=/bin/bash incompatible with a small initramfs on a new system.

But another issue is the creeping lack of support for systems without an 
initramfs.  For example when we had upstart upstream refusing to accept a 
patch for SE Linux support that made it impossible to use an upstart based 
distribution with SE Linux on hardware which didn't support an initramfs.

Finally one benefit of an event based booting system is that it won't become 
stuck if one daemon hangs.  I've had problems in the past when one daemon 
didn't start up and that prevented other daemons from starting due to the 
sequential processing of init scripts.

-- 
My Main Blog http://etbe.coker.com.au/
My Documents Bloghttp://doc.coker.com.au/


-- 
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/201202241131.39746.russ...@coker.com.au

Work-needing packages report for Feb 24, 2012

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

Total number of orphaned packages: 432 (new: 34)
Total number of packages offered up for adoption: 146 (new: 4)
Total number of packages requested help for: 58 (new: 2)

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



The following packages have been orphaned:

   9wm (#660496), orphaned 4 days ago
 Description: emulation of the Plan 9 window manager 8-1/2
 Installations reported by Popcon: 104

   aewm (#660497), orphaned 4 days ago
 Description: minimalist window manager for X11
 Installations reported by Popcon: 60

   cvsweb (#660684), orphaned 3 days ago
 Description: CGI interface to your CVS repository
 Installations reported by Popcon: 157

   docbook2x (#660682), orphaned 3 days ago
 Description: Converts DocBook/XML documents into man pages and
   TeXinfo
 Installations reported by Popcon: 459

   doodle (#660437), orphaned 4 days ago
 Description: Desktop Search Engine
 Reverse Depends: doodle doodle-dbg doodled libdoodle-dev
 Installations reported by Popcon: 39

   ears (#660494), orphaned 4 days ago
 Description: collection of Last.fm clients and CD-ripping tools
 Installations reported by Popcon: 65

   expat (#660681), orphaned 3 days ago
 Description: XML parsing C library - example application
 Reverse Depends: acovea adanaxisgpl afflib-tools amoeba asc audacity
   avahi-daemon bist btanks cairo-dock-mail-plug-in (258 more omitted)
 Installations reported by Popcon: 119025

   firehol (#660524), orphaned 4 days ago
 Description: An easy to use but powerful iptables stateful firewall
 Installations reported by Popcon: 489

   frozen-bubble (#660354), orphaned 5 days ago
 Description: Pop out the bubbles!
 Reverse Depends: frozen-bubble
 Installations reported by Popcon: 2642

   gnunet (#660438), orphaned 4 days ago
 Description: secure, trust-based peer-to-peer framework
 Reverse Depends: gnunet gnunet-client gnunet-dbg gnunet-dev
   gnunet-fuse gnunet-gtk gnunet-qt gnunet-server gnunet-tools
 Installations reported by Popcon: 168

   gnunet-fuse (#660439), orphaned 4 days ago
 Description: secure, trust-based peer-to-peer framework
 Installations reported by Popcon: 32

   gnunet-gtk (#660441), orphaned 4 days ago
 Description: secure, trust-based peer-to-peer framework
 Reverse Depends: gnunet-gtk-dbg gnunet-gtk-dev
 Installations reported by Popcon: 118

   gnunet-qt (#660440), orphaned 4 days ago
 Description: secure, trust-based peer-to-peer framework
 Reverse Depends: gnunet-qt-dbg
 Installations reported by Popcon: 29

   gramofile (#660220), orphaned 6 days ago
 Description: 
 Installations reported by Popcon: 209

   gurlchecker (#660679), orphaned 3 days ago
 Description: graphical websites checker
 Installations reported by Popcon: 56

   lastfmsubmitd (#660500), orphaned 4 days ago
 Description: MPD client for lastfmsubmitd
 Reverse Depends: lastmp
 Installations reported by Popcon: 182

   libapache2-mod-auth-pam (#660221), orphaned 6 days ago
 Description: module for Apache2 which authenticate using PAM
 Installations reported by Popcon: 758

   libchronic-ruby (#660501), orphaned 4 days ago
 Description: natural language date parser
 Reverse Depends: libbackgroundrb-ruby1.8 sup-mail
 Installations reported by Popcon: 136

   libextractor (#660442), orphaned 4 days ago
 Description: extracts meta-data from files of arbitrary type
 Reverse Depends: basenji doodle doodled extract fossology-agents
   fossology-agents-single gnunet-client gnunet-common gnunet-dev
   gnunet-gtk (11 more omitted)
 Installations reported by Popcon: 1089

   libextractor-java (#660443), orphaned 4 days ago
 Description: extracts meta-data from files of arbitrary type
 Reverse Depends: libextractor-java-dbg libextractor-java-dev
 Installations reported by Popcon: 16

   libextractor-python (#660444), orphaned 4 days ago
 Description: extracts meta-data from files of arbitrary type
 Installations reported by Popcon: 88

   liblockfile-ruby (#660502), orphaned 4 days ago
 Description: create NFS-safe lockfiles
 Reverse Depends: sup-mail
 Installations reported by Popcon: 131

   libmicrohttpd (#660445), orphaned 4 days ago
 Description: library embedding HTTP server functionality
 Reverse Depends: gnunet-dev gnunet-server libmicrohttpd-dbg
   libmicrohttpd-dev psensor-server yubikey-server-c
 Installations reported by Popcon: 1820

   libtrollop-ruby (#660503), orphaned 4 days ago
 Description: command-line argument processing library
 Reverse Depends: ditz sup-mail
 Installations reported

Re: upstart: please update to latest upstream version

2012-02-23 Thread brian m. carlson 
On Fri, Feb 24, 2012 at 11:31:38AM +1100, Russell Coker wrote:
> Finally one benefit of an event based booting system is that it won't become 
> stuck if one daemon hangs.  I've had problems in the past when one daemon 
> didn't start up and that prevented other daemons from starting due to the 
> sequential processing of init scripts.

The problem with event-based init systems is what to do if init
discovers a dependency loop.  I know systemd simply *silently* chose not
to start one daemon, which happened to be dbus, which made lots of
important software (e.g. gdm) simply not work.  If we're going to move
to event-based booting, this discovery needs to be made *before* the
system reboots[0] and init must complain loudly and handle it gracefully
anyway.

[0] And whatever solution we choose must handle the case where the
sysadmin drops local services into the boot process.

-- 
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: upstart: please update to latest upstream version

2012-02-23 Thread Ben Hutchings 
On Fri, Feb 24, 2012 at 11:31:38AM +1100, Russell Coker wrote:
[...]
> Debian has already become rather difficult to debug.  During the text boot 
> process we have a change to the video mode which resets the scroll-back 
> buffer 
> and makes it difficult to read early messages that appear on the console.  
> Now 
> a serial console can make some of these things easier to debug but a recent 
> hardware trend is towards making systems without a serial port.
> 
> Is there any way of capturing the old text output from /dev/console at a 
> later 
> stage in the boot?
 
Apparently systemd does that. :-)

(Though I don't see how it can cover the initramfs automatically.)

> Also a recent hardware trend is to make systems without a PS/2 keyboard port. 
>  
> It seems that the USB modules don't get loaded from the initramfs if you 
> configure it with modules=dep which makes the recovery option of 
> init=/bin/bash incompatible with a small initramfs on a new system.

This sounds like a bug; please report it.

> But another issue is the creeping lack of support for systems without an 
> initramfs.  For example when we had upstart upstream refusing to accept a 
> patch for SE Linux support that made it impossible to use an upstart based 
> distribution with SE Linux on hardware which didn't support an initramfs.
> 
> Finally one benefit of an event based booting system is that it won't become 
> stuck if one daemon hangs.  I've had problems in the past when one daemon 
> didn't start up and that prevented other daemons from starting due to the 
> sequential processing of init scripts.
 
I think our current dependency-based boot system deals with that
problem.  Login on the local console could still be stalled though,
since getty is special (to sysvinit).

Ben.

-- 
Ben Hutchings
We get into the habit of living before acquiring the habit of thinking.
  - Albert Camus


-- 
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/20120224022200.gh12...@decadent.org.uk

Re: upstart: please update to latest upstream version

2012-02-23 Thread Timo Juhani Lindfors 
Russell Coker  writes:
> Is there any way of capturing the old text output from /dev/console at a 
> later 
> stage in the boot?

I personally use

http://iki.fi/lindi/git/vtgrab-initramfs.git/

which starts rvcd (remote virtual console daemon) in the beginning of
initramfs and lets me monitor and interact with the whole boot process
over network.


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