on bootstrapping ports (was: Re: Bits from the Release Team (Jessie freeze info))

2013-10-27 Thread Johannes Schauer 
Hi Peter,

Quoting peter green (2013-10-27 01:11:24)
> Johannes Schauer wrote:
> > Until these two issues are fixed we will not be able to get an algorithmic
> > answer to the question of what constitutes the minimum required set of
> > packages.
> >   
> There is also the complication of what I will call "non-key self 
> building compilers". fpc is an example

Yes, this is also an issue and the two issues I mentioned are only a necessity
but not a sufficiency for the whole bootstrap problem. In practice, it is of
course not only needed to know that one must be able to build src:fpc without
all the fp-* binaries (that's what my algorithms do right now) but also that
this is really possible in practice. Since I only work with the algorithmic
side of things I often forget to mention that one naturally needs more than
correct meta data (dependency relationships) to make everything work :)

You will find your example (fpc) in the section of "Type 1 Self-Cycles" on

http://mister-muffin.de/bootstrap/stats/

together with other compilers like for haskell, sml or lisp.

We call Type 1 Self-Cycles those where the source package directly build
depends on a binary package it builds. Those are the most obvious self cycles
and they are mostly made up of the "non-key self building compilers" as you
call them.

> These are not needed to bootstrap the core of debian but if one wants to
> bootstrap all of debian they will need to be built.

Indeed, none of the Type 1 Self-Cycles are needed to bootstrap the core of
Debian. Unfortunately though, most of the Type 2 Self-Cycles are. You will find
many surprising (at least to me) examples in the section of "Type 2
Self-Cycles" under the above link.

We call Type 2 Self-Cycles those where the source package indirectly and
strongly [1] build depends on a binary package it builds. They are hard to find
because the only tool which is able to compute strong dependencies (afaik) is
dose3 which is used by botch to do the required computations.

[1] www.mancoosi.org/papers/esem-2009.pdf

Surely every maintainer of source packages involved in a Type 1 Self-Cycle
knows about this issue. Because Type 2 Self-Cycles are non-obvious we could in
the future (once build profiles are available) embed this information in the
pts for the relevant packages. On the other hand, there only exist a small
number (26 for amd64) source packages involved in Type 2 Self-Cycles so it
might be enough to just post priority wishlist bug reports for each of them.

> Since the only way to build them is with themselves they cannot be
> bootstrapped natively even with the help of build profiles. So the only way
> to bootstrap them is to either cross-build them or start with a binary from
> upstream.

And even compilers which allow some way of bootstrapping them, do not have this
process automated (ghc [2], mlton [3]). This is fine under the assumption that
initial porting is rarely done and once it's done does not have to be repeated.
But it does not allow continuous testing of bootstrappability of the whole
archive.

[2] http://ghc.haskell.org/trac/ghc/wiki/Building/Porting
[3] http://mlton.org/PortingMLton

cheers, josch


--
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/20131027083354.16796.89806@hoothoot

Re: Proposal: s have a GR about the init system

2013-10-27 Thread Andrew Shadura 
Hello,

On Oct 26, 2013 7:15 AM, "Uoti Urpala"  wrote:
> I am no longer willing to assume that Steve Langasek would act in good
> faith in evaluating init systems; he has posted false claims about
> systemd too many times for me to believe they would all be honest
> mistakes, and has posted what has clearly been deliberate FUD. This
> independently of and in addition to any conflict of interest.

He hasn't done so, you lie. Therefore I think your arguments should be
disregarded.

-- 
WBR, Andrew

Re: let's split the systemd binary package

2013-10-27 Thread Florian Weimer 
* Simon McVittie:

> On 26/10/13 21:23, Florian Weimer wrote:
>>> "Session tracking" includes suspending/hibernating, because logind has
>>> a mechanism to let apps delay suspend, which is necessary for things
>>> like closing the inherent race condition in "lock the screensaver when
>>> we suspend... oh, oops, it didn't get scheduled until after we
>>> resumed, so the old screen contents are still visible for a moment
>>> when you open your laptop".
>> 
>> Has this finally been fixed?  Locking and suspend is not synchronized
>> in GNOME 3.8.
>
> My understanding is that this was finally fixed in the GNOME 3.8 cycle:
> if you have GNOME Shell 3.8 and logind, and something suspends *via
> logind* (including hotkeys, lid-close events and Shell itself), suspend
> will be delayed until either the Shell has locked the screen, or some
> reasonably long timeout has elapsed. I could be wrong there, though.

Interesting, thanks.  It's definitely not completely fixed in GNOME
3.8 with systemd 204:



I didn't know it's supposed to work.  Two monitors appear to be
required for reproducing the issue, the same system doesn't show this
behavior if the external monitor is unplugged.


-- 
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/87d2mrx80d@mid.deneb.enyo.de

Re: Please assume good faith (was Re: systemd effectively mandatory now due to GNOME)

2013-10-27 Thread Thomas Goirand 
On 10/26/2013 09:17 PM, Olav Vitters wrote:
> On Sat, Oct 26, 2013 at 12:02:00AM +0100, Kevin Chadwick wrote:
>>> I'm fed up with repeated attempts to force components on the rest of the
>>> system, but that's mostly a fault of Gnome's upstream
>>
>> There seems to be a trend emanating from packages involving RedHat devs.
>> I actually went to the RedHat site a few weeks ago to try and get some
>> sort of oversight on this but there seemed to be no appropriate contact
>> point (bookmarked).
> 
> There are various maintainers+developers who would love to see GNOME
> support Wayland and nothing more. This due to code complexity and test
> matrix (too many different options and it becomes difficult to test
> things). And we do do continuous integration, plus I had to deal with
> the bugs caused by the introduction of Wayland support.
> 
> Various of above mentioned maintainers/developers are sponsored by Red
> Hat. I say sponsored because they pretty much do what they think is
> good. I have not seen any corporate agenda (I also fail to understand
> why we have so many of them). Anyway, they just don't want code
> complexity.
> 
> The *main* reason that GNOME will keep Wayland + X compatibility for a
> long time, thus introducing more bugs and slowing down full Wayland
> support, is the same GNOME release team person who urged to support
> Wayland. He's sponsored by Red Hat.
> 
> In brief: The person mainly responsible for allowing people to rely on
> our X support for a much longer time is one of those Red Hat people.
> 
> Not sure if you like Wayland or not, but something to keep in mind, if
> it wasn't up to this Red Hat person, X support would be die much more
> quickly. And this decision is not made due to forcing, it is to due
> supporting one thing well, not multiple things a bit with various
> degrees of testing and buggyness.

If you don't mind that I ask: are you a GNOME developer?

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/526d1a43.40...@debian.org

Re: Please assume good faith (was Re: systemd effectively mandatory now due to GNOME)

2013-10-27 Thread Paul Tagliamonte 
Can this be taken off-list? I don't care either way, I'd still take his
points even if he wasn't.


On Sun, Oct 27, 2013 at 9:50 AM, Thomas Goirand  wrote:

> On 10/26/2013 09:17 PM, Olav Vitters wrote:
> > On Sat, Oct 26, 2013 at 12:02:00AM +0100, Kevin Chadwick wrote:
> >>> I'm fed up with repeated attempts to force components on the rest of
> the
> >>> system, but that's mostly a fault of Gnome's upstream
> >>
> >> There seems to be a trend emanating from packages involving RedHat devs.
> >> I actually went to the RedHat site a few weeks ago to try and get some
> >> sort of oversight on this but there seemed to be no appropriate contact
> >> point (bookmarked).
> >
> > There are various maintainers+developers who would love to see GNOME
> > support Wayland and nothing more. This due to code complexity and test
> > matrix (too many different options and it becomes difficult to test
> > things). And we do do continuous integration, plus I had to deal with
> > the bugs caused by the introduction of Wayland support.
> >
> > Various of above mentioned maintainers/developers are sponsored by Red
> > Hat. I say sponsored because they pretty much do what they think is
> > good. I have not seen any corporate agenda (I also fail to understand
> > why we have so many of them). Anyway, they just don't want code
> > complexity.
> >
> > The *main* reason that GNOME will keep Wayland + X compatibility for a
> > long time, thus introducing more bugs and slowing down full Wayland
> > support, is the same GNOME release team person who urged to support
> > Wayland. He's sponsored by Red Hat.
> >
> > In brief: The person mainly responsible for allowing people to rely on
> > our X support for a much longer time is one of those Red Hat people.
> >
> > Not sure if you like Wayland or not, but something to keep in mind, if
> > it wasn't up to this Red Hat person, X support would be die much more
> > quickly. And this decision is not made due to forcing, it is to due
> > supporting one thing well, not multiple things a bit with various
> > degrees of testing and buggyness.
>
> If you don't mind that I ask: are you a GNOME developer?
>
> 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/526d1a43.40...@debian.org
>
>


-- 
All programmers are playwrights, and all computers are lousy actors.

#define sizeof(x) rand()
:wq

Re: [debian-mysql] MySQL.. no.. _I_ need your help!

2013-10-27 Thread Clint Byrum 
Excerpts from Jonathan Aquilina's message of 2013-10-25 23:36:22 -0700:
> I would like to help in some capacity. Would working in a chrooted
> environment or would one need a fully fledged os?
> 

These days I have no standing machines of Debian. I do spin up cloud
instances often that I use to do smoke testing.

Basically all of my packaging work is done using sbuild/schroot on Ubuntu.


-- 
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/1382883557-sup-8381@clint-HP

Bug#727833: ITP: node-bytes -- Byte string parser and formatter - Node.js module

2013-10-27 Thread Jérémy Lal 
Package: wnpp
Severity: wishlist
Owner: "Jérémy Lal" 

* Package name: node-bytes
  Version : 0.2.1
  Upstream Author : TJ Holowaychuk 
* URL : https://github.com/visionmedia/bytes.js
* License : Expat
  Programming Lang: JavaScript
  Description : Byte string parser and formatter - Node.js module

This module parses strings representing an amount of bytes, like
1kb, 2mb, 1gb; and inversely converts positive integers to a readable
format representing an amount of bytes.
It is useful for parsing or writing log files.
.
Node.js is an event-based server-side javascript engine.


-- 
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/20131027143753.32273.78642.reportbug@imac.chaumes

Re: Please assume good faith (was Re: systemd effectively mandatory now due to GNOME)

2013-10-27 Thread Cyril Brulebois 
Thomas Goirand  (2013-10-27):
> If you don't mind that I ask: are you a GNOME developer?

That comes to mind:
  http://lmgtfy.com/?q=Olav+Vitters+Gnome
  https://lists.debian.org/20131024192452.ga29...@bkor.dhs.org

KiBi.


signature.asc
Description: Digital signature

Re: Please assume good faith (was Re: systemd effectively mandatory now due to GNOME)

2013-10-27 Thread Sune Vuorela 
On 2013-10-27, Thomas Goirand  wrote:
> If you don't mind that I ask: are you a GNOME developer?

Olav is a gnome developer, yes.

/Sune


-- 
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/slrnl6q96e.j8.nos...@sshway.ssh.pusling.com

Re: on bootstrapping ports (was: Re: Bits from the Release Team (Jessie freeze info))

2013-10-27 Thread Paul Wise 
On Sun, Oct 27, 2013 at 4:33 PM, Johannes Schauer wrote:

> Surely every maintainer of source packages involved in a Type 1 Self-Cycle
> knows about this issue. Because Type 2 Self-Cycles are non-obvious we could in
> the future (once build profiles are available) embed this information in the
> pts for the relevant packages. On the other hand, there only exist a small
> number (26 for amd64) source packages involved in Type 2 Self-Cycles so it
> might be enough to just post priority wishlist bug reports for each of them.

Please do file a bug on the PTS (qa.debian.org, usertag pts) about
this when the appropriate machine-readable package list and
human-readable explanations are available.

> But it does not allow continuous testing of bootstrappability of the whole
> archive.

This might be interesting information to have on edos.debian.net or
elsewhere on Debian QA infrastructure.

-- 
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/caktje6edwqggqxw7ks2jwft83eo-ct0un6s2gyzuqcdpb-y...@mail.gmail.com

Re: Jessie release goal: DNSSEC as default recursive resolver

2013-10-27 Thread Kevin Chadwick 
> On Sat, Oct 26, 2013, at 18:58, Kevin Chadwick wrote:
> > I believe the reliability (DOS) issues that DNSSEC imposes coupled with
> 
> Please, not this again. If you say DNSSEC DOS issue, you must state all
> the other issues that DNS has.
> 

Not really, the security issues are already catered for and not such a
problem. DNSSEC would be great if it was all good but it isn't. Having
people being far more easily prevented from even accessing the internet
is a far more serious issue which needs to be considered for a default
stance of enforced if the AD bit is set.

> > the low level of adoption
> 
> It's certainly more adopted than IPv6 and we do support IPv6.
> 

Of course I am not saying don't support it, it already is by certain
packages but enabled by default without fallback many would disagree and
with fallback, what do you gain. An easy switch on and off in
resolv.conf for example is another matter entirely that would be cool.


> > would make it very unlikely that DNSSEC would
> > be enabled for certainly default resolving on OpenBSD without DNSCURVE
> > protection or some significant DNSSEC re-development.
> 
> How is the DNSSEC adoption by OpenBSD relevant to Debian decisions?
> 

I never said it was, just responding to the OPs post, please re-read
that. The point is OpenBSD having unbound in base is akin to debian
having unbound in the repo, the only difference being that the code was
audited and configured with a chroot by default etc. first and you
don;t need to download it to use it. NSD upstream for example received
some useful patches and other help upstream as a direct result of it's
incorporation into base.


-- 
___

'Write programs that do one thing and do it well. Write programs to work
together. Write programs to handle text streams, because that is a
universal interface'

(Doug McIlroy)

In Other Words - Don't design like polkit or systemd
___


-- 
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/396880.55305...@smtp144.mail.ir2.yahoo.com

Re: Jessie release goal: DNSSEC as default recursive resolver

2013-10-27 Thread Thomas Goirand 
On 10/27/2013 01:52 AM, Ondřej Surý wrote:
> I still think that the Debian should be a technology leader.
> Conservative, but technology leader. And DNSSEC adoption would help the
> case.
> 
> Also the DSA has already enabled DANE (DNSSEC validated TLS certs) on
> Debian's MTAs, the postfix 2.11 will have DANE support.
> 
> I think this goal is very reasonable and I thank Thomas for proposing
> it.
> 
> O.

Hi Ondrej,

A release goal with nobody working on it would be pointless. Since you
are involved in packaging DNS software in Debian, do you think you would
have time to work on that? How about the other package maintainers? Not
trying to put pressure on you, since I know you do a lot for Debian
already (including maintaining php, among other stuff...).

On 10/27/2013 02:57 AM, Marco d'Itri wrote:
> On Oct 26, Thomas Goirand  wrote:
>> I'd find it very nice if we had, by default, DNSSEC resolving in
>> Debian, at least in the "default" configuration (whatever that
>> means). By this,
> I agree with the general principle, but I do not think that a
> recursive resolver should be installed by default on every system.
> This would  violate a lot of reasonable expectations...

Like what expectation?

I don't mind if we don't have a recursive resolver installed by default
on every system, if we have DNSSEC in another way. If that another way
is possible, could you tell how?

Cheers,

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/526d2f04.9060...@debian.org

Re: on bootstrapping ports (was: Re: Bits from the Release Team (Jessie freeze info))

2013-10-27 Thread Daniel Schepler 
Johannes Schauer wrote:
> Indeed, none of the Type 1 Self-Cycles are needed to bootstrap the core of
> Debian. Unfortunately though, most of the Type 2 Self-Cycles are. You will 
find
> many surprising (at least to me) examples in the section of "Type 2
> Self-Cycles" under the above link.

On the other hand, if you count Build-Depends-Indep and Architecture: all 
packages as part of what you want to bootstrap, then gnat-4.6 does get pulled 
in...

gzip Build-Depends-Indep: mingw-w64
mingw-w64 Build-Depends: gcc-mingw-w64-{i686,x86_64}
gcc-mingw-w64 Build-Depends: gnat-4.6

(And also, you have the issue that gcc-4.8 Build-Depends on libantlr-java and 
libecj-java, whose builds require either gcj-4.8 from the same source package, 
or openjdk-7-jdk which also Build-Depends on ecj.)

I realize that these sorts of issues aren't as important for the practical 
problem of bootstrapping a new port; but ideally, from a philosophical point 
of view we should be able to bootstrap all our packages.  (To be honest, the 
Java packages are such a tangled mess that I've given up on trying to 
bootstrap that part of the archive for now -- and many of those do get pulled 
into the minimal set of ca. 1473 source packages I get with my criteria.)
-- 
Daniel Schepler


-- 
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/2085384.4n0ClPvkx6@frobozz

Re: on bootstrapping ports (was: Re: Bits from the Release Team (Jessie freeze info))

2013-10-27 Thread Johannes Schauer 
Hi Daniel,

Quoting Daniel Schepler (2013-10-27 16:06:43)
> Johannes Schauer wrote:
> > Indeed, none of the Type 1 Self-Cycles are needed to bootstrap the core of
> > Debian. Unfortunately though, most of the Type 2 Self-Cycles are. You will 
> find
> > many surprising (at least to me) examples in the section of "Type 2
> > Self-Cycles" under the above link.
> 
> On the other hand, if you count Build-Depends-Indep and Architecture: all 
> packages as part of what you want to bootstrap, then gnat-4.6 does get pulled 
> in...
> 
> gzip Build-Depends-Indep: mingw-w64
> mingw-w64 Build-Depends: gcc-mingw-w64-{i686,x86_64}
> gcc-mingw-w64 Build-Depends: gnat-4.6
> 
> (And also, you have the issue that gcc-4.8 Build-Depends on libantlr-java and 
> libecj-java, whose builds require either gcj-4.8 from the same source 
> package, 
> or openjdk-7-jdk which also Build-Depends on ecj.)
> 
> I realize that these sorts of issues aren't as important for the practical 
> problem of bootstrapping a new port; but ideally, from a philosophical point 
> of view we should be able to bootstrap all our packages.  (To be honest, the 
> Java packages are such a tangled mess that I've given up on trying to 
> bootstrap that part of the archive for now -- and many of those do get pulled 
> into the minimal set of ca. 1473 source packages I get with my criteria.)

you can easily use botch for an analysis of dependency cycles under your
conditions as well. Botch is a collection of tools doing some mangling with
sets of binary and source package metadata and creating and analyzing a graph
build from them. By calling the involved tools a bit differently than it is
done in the example shell script (which is to demonstrate the practical
bootstrap scenario and thus drops B-D-I and arch:all) you can also analyze the
situation you are talking about.

More specifically, you want to change how the "create_graph" binary is called.
The --available option expects a filename of a file containing the list of
packages which is expected to be "available" in the bootstrapping sense [1].
This file is currently compiled containing all arch:all and all cross compiled
binary packages. You are free to not add any arch:all packages or only some to
that list.

Secondly, per default B-D-I dependencies are ignored but you can pass the
--keep-indep argument to the "create_graph" binary to let them be considered
nevertheless.

cheers, josch

[1] https://gitorious.org/debian-bootstrap/pages/Terminology#Availability


--
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/20131027152758.16796.78747@hoothoot

Re: Jessie release goal: DNSSEC as default recursive resolver

2013-10-27 Thread Bastian Blank 
On Sat, Oct 26, 2013 at 08:57:54PM +0200, Marco d'Itri wrote:
> On Oct 26, Thomas Goirand  wrote:
> > I'd find it very nice if we had, by default, DNSSEC resolving in Debian,
> > at least in the "default" configuration (whatever that means). By this,
> I agree with the general principle, but I do not think that a recursive 
> resolver should be installed by default on every system. This would 
> violate a lot of reasonable expectations...

How would you do "secure" DNSSEC resolution without a recursive
resolver?  Right now there is no possibility to ask the resolver for all
security related records beginning from . to check it yourself.

Bastian

-- 
Youth doesn't excuse everything.
-- Dr. Janice Lester (in Kirk's body), "Turnabout Intruder",
   stardate 5928.5.


-- 
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/20131027151611.ga13...@mail.waldi.eu.org

Bug#728016: ITP: node-send -- Static file server with ranges and negotiation support for Node.js

2013-10-27 Thread Jérémy Lal 
Package: wnpp
Severity: wishlist
Owner: "Jérémy Lal" 

* Package name: node-send
  Version : 0.1.4
  Upstream Author : TJ Holowaychuk 
* URL : https://github.com/visionmedia/send
* License : Expat
  Programming Lang: JavaScript
  Description : Static file server with ranges and negotiation support for 
Node.js

This module offers a streaming static file server supporting partial
responses (Ranges), conditional-GET negotiation, high test coverage,
and granular events allowing middlewares to plug easily into it.
.
Node.js is an event-based server-side javascript engine.


-- 
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/20131027163304.13127.78147.reportbug@imac.chaumes

Re: Proposal: switch default desktop to xfce

2013-10-27 Thread Svante Signell 
On Sat, 2013-10-26 at 22:14 +0200, Marco d'Itri wrote:
> On Oct 26, Svante Signell  wrote:
> 
> > This really pinpoints the whole problem: What happened to the Unix
> > philosophy, with freedom of choice?
> We killed it for good in 2008:
> http://www.redhat.com/archives/rhl-devel-list/2008-January/msg00861.html

I asked about Unix philosophy, this in not the same as Linux philosophy,
fortunately. There are other OSes out there, like *BSD, Solaris, etc,
see
http://en.wikipedia.org/wiki/Operating_system#UNIX_and_UNIX-like_operating_systems



-- 
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/1382891804.4094.15.camel@PackardBell-PC

Re: [debian-mysql] MySQL.. no.. _I_ need your help!

2013-10-27 Thread Jonathan Aquilina 
i do have a testing vps i can setup for you an account on to do tetsting
etc of mysql and maria db if it helps. I will also want to use it for my
own testing purposes along side.


On Sun, Oct 27, 2013 at 3:21 PM, Clint Byrum  wrote:

> Excerpts from Jonathan Aquilina's message of 2013-10-25 23:36:22 -0700:
> > I would like to help in some capacity. Would working in a chrooted
> > environment or would one need a fully fledged os?
> >
>
> These days I have no standing machines of Debian. I do spin up cloud
> instances often that I use to do smoke testing.
>
> Basically all of my packaging work is done using sbuild/schroot on Ubuntu.
>



-- 
Jonathan Aquilina

Re: on bootstrapping ports (was: Re: Bits from the Release Team (Jessie freeze info))

2013-10-27 Thread Matthias Klose 
Am 27.10.2013 16:06, schrieb Daniel Schepler:
> Johannes Schauer wrote:
>> Indeed, none of the Type 1 Self-Cycles are needed to bootstrap the core of
>> Debian. Unfortunately though, most of the Type 2 Self-Cycles are. You will 
> find
>> many surprising (at least to me) examples in the section of "Type 2
>> Self-Cycles" under the above link.
> 
> On the other hand, if you count Build-Depends-Indep and Architecture: all 
> packages as part of what you want to bootstrap, then gnat-4.6 does get pulled 
> in...
> 
> gzip Build-Depends-Indep: mingw-w64
> mingw-w64 Build-Depends: gcc-mingw-w64-{i686,x86_64}
> gcc-mingw-w64 Build-Depends: gnat-4.6
> 
> (And also, you have the issue that gcc-4.8 Build-Depends on libantlr-java and 
> libecj-java, whose builds require either gcj-4.8 from the same source 
> package, 
> or openjdk-7-jdk which also Build-Depends on ecj.)
> 
> I realize that these sorts of issues aren't as important for the practical 
> problem of bootstrapping a new port; but ideally, from a philosophical point 
> of view we should be able to bootstrap all our packages.  (To be honest, the 
> Java packages are such a tangled mess that I've given up on trying to 
> bootstrap that part of the archive for now -- and many of those do get pulled 
> into the minimal set of ca. 1473 source packages I get with my criteria.)

well, please can we concentrate on practical issues first, then come back to the
philosopicals again?   With recent binary-indep packages you just cross-build
gcc-4.8 including java.  Problem solved.  I never did see a bug report about the
"tangled mess" in the java packages, so I'll just ignore that.  gcj and openjdk
were one of the easier parts for the AArch64 bootstrap.

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

Re: Two new DNS virtual packages (authoritative-name-server & recursive-name-server)

2013-10-27 Thread Octavio Alvarez 
On 10/24/2013 12:30 AM, Ondřej Surý wrote:
> On Tue, Oct 22, 2013, at 20:16, Octavio Alvarez wrote:
>> On 22/10/13 09:18, Arturo Borrero Gonzalez wrote:
>>> I would suggest: caching-name-server
>>
>> *-dns-server would be better, as it is specific enough to avoid name 
>> collision in the future.
> 
> JFTR that should not be any name collisions as the "name server" is term
> defined in RFC1034 and used in all DNS standards out there. Not that it
> matters now when the idea was those was rejected (see my other
> proposal).

RFC1034 and all DNS standards define "name server" within their own
scope. Debian has a lot of software that do not belong to the IETF scope.


-- 
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/526d509a.5050...@alvarezp.ods.org

AST ksh alpha: compilation failure related to multiarch

2013-10-27 Thread Giovanni Rapagnani 
Hi, I am trying to build the alpha release of AST ksh on debian testing
but the compilation fails because it cannot find header files under
/usr/include/x86_64-linux-gnu/sys.

Actually, if I create the symlink /usr/include/sys ->
/usr/include/x86_64-linux-gnu/sys the compilation succeeds.

I have the same behavior (i.e compilation failure solved with the
symlink) under debian wheezy and ubuntu 12.04.

So I think ksh does not handle correctly the implementation of multiarch
in debian. Am I right?

If ksh source code does not handle multiarch correctly, which document
should I ask upstream to look into in order to understand how multiarch
is implemented in debian? I have the feeling the people on
ast-developpers ml are not familiar with debian or ubuntu. Actually,
they asked me if "my test machine was broken"; and "how could I have
such a weird header files setup".

I think to submit them a summary of
https://wiki.debian.org/Multiarch/TheCaseForMultiarch for the reason of
such a header files setup in debian/ubuntu and
https://wiki.debian.org/Multiarch/LibraryPathOverview for the way their
source code should handle it.

Am I right this issue is related to multiarch in debian?
Do you have any advices to make my point against the ksh developers?

Thanks for any advices.
Best regards.

-- 
Giovanni Rapagnani


-- 
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/526d5d1f.2050...@ideanet.be

Re: Proposal: switch default desktop to xfce

2013-10-27 Thread Olav Vitters 
On Sat, Oct 26, 2013 at 02:12:11AM +0300, Jukka Ruohonen wrote:
> Indeed. And given the train wreck of contemporary Gnome, I fully welcome the
> discussion on alternative default desktops. Some people are keen to rule out
> the stakeholder issues, but a fact on the so-called agenda remains.

I suggest you never try to do any stakeholder management with above
trolling.

-- 
Regards,
Olav


-- 
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/20131027183237.ga18...@bkor.dhs.org

Re: Proposal: let’s have a GR about the init system

2013-10-27 Thread Olav Vitters 
On Sat, Oct 26, 2013 at 05:37:50PM +0100, Kevin Chadwick wrote:
> I don't mean to be rude but please read up on systemd and see the pros
> of cons such as on LWN.net comments or any distro mailing list as many
> are tired of systemd discussion and this wide ranging and much of the
> stolen/borrowed/existing functionality is what many don't want
> mandated on all systems by default for various reasons.

I only saw that in the beginning. As soon as people had systemd as their
init system, all those discussions died. I see loads of really pro
statements.

Could you point me to these comments?

>From what I have seen, most people on LWN.net are *very* pro-systemd. I
mean, so much pro that it is getting a bit strange. What you said I have
not seen *at all*.

-- 
Regards,
Olav


-- 
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/20131027191906.gc18...@bkor.dhs.org

Re: AST ksh alpha: compilation failure related to multiarch

2013-10-27 Thread Steve Langasek 
Hi Giovanni,

On Sun, Oct 27, 2013 at 07:36:15PM +0100, Giovanni Rapagnani wrote:
> Hi, I am trying to build the alpha release of AST ksh on debian testing
> but the compilation fails because it cannot find header files under
> /usr/include/x86_64-linux-gnu/sys.

> Actually, if I create the symlink /usr/include/sys ->
> /usr/include/x86_64-linux-gnu/sys the compilation succeeds.

> I have the same behavior (i.e compilation failure solved with the
> symlink) under debian wheezy and ubuntu 12.04.

> So I think ksh does not handle correctly the implementation of multiarch
> in debian. Am I right?

I would say, rather, than AST ksh doesn't correctly handle using the
compiler's default include path.  If you are using any of the compilers
included in Debian to build this software, the include path should be set up
transparently for you; so for AST ksh to not find these headers means that
it's doing something nonstandard.  Perhaps you can post a build log?

> If ksh source code does not handle multiarch correctly, which document
> should I ask upstream to look into in order to understand how multiarch
> is implemented in debian? I have the feeling the people on
> ast-developpers ml are not familiar with debian or ubuntu. Actually,
> they asked me if "my test machine was broken"; and "how could I have
> such a weird header files setup".

> I think to submit them a summary of
> https://wiki.debian.org/Multiarch/TheCaseForMultiarch for the reason of
> such a header files setup in debian/ubuntu and
> https://wiki.debian.org/Multiarch/LibraryPathOverview for the way their
> source code should handle it.

Those seem like good starting points for discussion, with upstream, yeah.

> Am I right this issue is related to multiarch in debian?
> Do you have any advices to make my point against the ksh developers?

"Stop second-guessing the compiler" :)

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

Re: Proposal: switch default desktop to xfce

2013-10-27 Thread Jonathan Dowland 
On Fri, Oct 25, 2013 at 02:23:42PM -0700, Steve Langasek wrote:
> Thanks, I hadn't seen that team mentioned before anywhere.  It looks
> like the right place for this work to happen.  Unfortunately it seems
> rather dormant, as the packages they do have in place date back to
> Ubuntu 12.04 (i.e., before any of the work on touch began in earnest).

Yes, I was interested in helping out at one point but for whatever
reason I don't seem to have followed through, but it seemed fairly
dormant at the time. (Oh, I was probably put off by bzr, but that
is a fairly good fit for these packages I must admit)


-- 
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/20131027200742.ga6...@bryant.redmars.org

Re: Proposal: switch default desktop to xfce

2013-10-27 Thread Tollef Fog Heen 
]] Steve Langasek

> In the short term, this could be a committment from the systemd
> maintainers to hold the package at version 204 until the dust settles
> around cgroup manager interfaces[1].

With some time limit (3 months?  6 months?) I think I'd be ok with this.

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

Re: systemd effectively mandatory now due to GNOME

2013-10-27 Thread Tollef Fog Heen 
]] Steve Langasek 

> Formally, it only requires that the dbus services be available, which is
> given by installing the systemd package, not by running it as init.

That's actually due to a missing feature in the dbus daemon: it should
either have a way to key off init/file system features (so I can say
«this service can only start if $dir exists»), or it should have a dir
in /run where upstart can generate the .service files for dbus-daemon so
logind actually is only startable with systemd as pid 1.

> But there are several issues with having this all in one package the way it
> is currently.  In addition to the dbus services, the systemd package ships:
> 
>  - /lib/lsb/init-functions.d/40-systemd - functions which permute the
>behavior of LSB init scripts

.. if you're running systemd, sure.

>  - /lib/udev/rules.d/99-systemd.rules - udev rules that will be active on
>any system with /sys/fs/cgroup/systemd present (because of logind, this
>directory is not a good proxy for whether pid1 == systemd).

That's a bug that it checks for the wrong directory.  That's a trivial
bugfix to change.

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

Re: systemd effectively mandatory now due to GNOME

2013-10-27 Thread Brian May 
On 28 October 2013 07:52, Tollef Fog Heen  wrote:

> >  - /lib/udev/rules.d/99-systemd.rules - udev rules that will be active on
> >any system with /sys/fs/cgroup/systemd present (because of logind,
> this
> >directory is not a good proxy for whether pid1 == systemd).
>
> That's a bug that it checks for the wrong directory.  That's a trivial
> bugfix to change.
>

Has a bug been reported? Does a bug need to be reported for this to get
fixed?
-- 
Brian May

Re: systemd effectively mandatory now due to GNOME

2013-10-27 Thread Brian May 
So my current understanding:

* Gnome use to depend on ConsoleKit.

* ConsoleKit is no longer maintained, and no one is interested in
maintaining it.

* As a result, Gnome switched to using the implementation from systemd
instead, as it has needed features and is actively being maintained.

* Some people say this means it needs systemd running as pid=1, same say it
doesn't. Am still confused here.

* Some people say that the parts of systemd that Gnome uses should be split
into a separate package, so, in theory, it should be possible to install
just those parts without installing all of systemd. However the systemd
object to doing this (I missed the reasons behind this).

* Gnome is said to work fine even on platforms that don't have systemd
installed. Does this mean that systemd is optional?

* For reasons I don't properly understand, some people seem to think a
decision is needed to make or not make systemd the default in Debian.

Have I missed anything or got anything wrong?
-- 
Brian May

Re: systemd effectively mandatory now due to GNOME

2013-10-27 Thread The Wanderer 

On 10/27/2013 06:41 PM, Brian May wrote:


So my current understanding:

* Gnome use to depend on ConsoleKit.

* ConsoleKit is no longer maintained, and no one is interested in
maintaining it.

* As a result, Gnome switched to using the implementation from
systemd instead, as it has needed features and is actively being
maintained.

* Some people say this means it needs systemd running as pid=1, same
say it doesn't. Am still confused here.

* Some people say that the parts of systemd that Gnome uses should be
split into a separate package, so, in theory, it should be possible
to install just those parts without installing all of systemd.
However the systemd object to doing this (I missed the reasons behind
this).


One missing point: the systemd-project-derived component in question,
logind, used to work fine without systemd itself but now apparently no
longer does.

(As far as I can tell this is the actual root of the problem, at least
for this iteration of the argument: the fact that logind now requires
systemd.)


* Gnome is said to work fine even on platforms that don't have
systemd installed. Does this mean that systemd is optional?


My understanding from what I've read is that it "works fine" except in
that the features which the ConsoleKit-or-logind dependency provides
aren't available. That's derived from indirect statements from several
people in various parts of the discussion; if I'm wrong on that, someone
please correct me.


* For reasons I don't properly understand, some people seem to think
a decision is needed to make or not make systemd the default in
Debian.

Have I missed anything or got anything wrong?


With the above modifications, looks about accurate to me, for whatever
that may be worth.

--
   The Wanderer

Warning: Simply because I argue an issue does not mean I agree with any
side of it.

Every time you let somebody set a limit they start moving it.
  - LiveJournal user antonia_tiger


--
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/526d9dd5.20...@fastmail.fm

Re: systemd effectively mandatory now due to GNOME

2013-10-27 Thread Kevin Chadwick 
> > * Gnome is said to work fine even on platforms that don't have
> > systemd installed. 

> My understanding from what I've read is that it "works fine" except in
> that the features which the ConsoleKit-or-logind dependency provides
> aren't available. That's derived from indirect statements from several
> people in various parts of the discussion; if I'm wrong on that, someone
> please correct me.

Yeah it works fine, some things needlessly break but can easily be
fixed (if you happen to still want to use Gnome). Session tracking will
also break but only a fraction of desktop users actually need that
although I guess it is of use to RedHat's cloud services and the like.

Looking into and defining if anything else breaks may be a good idea?

> > Does this mean that systemd is optional?

Apparently not if you want to use Gnome and who knows what next.
Antoine who has been doing the patching and negotiating with Gnome devs
for his OpenBSD port seems to be losing hope when he was fairly happy
not too long ago stating patching out pulseaudio for sndio wasn't hard,
unless the comment of his posted here was old (cc'd apparently so I
don't think so).

-- 
___

'Write programs that do one thing and do it well. Write programs to work
together. Write programs to handle text streams, because that is a
universal interface'

(Doug McIlroy)

In Other Words - Don't design like polkit or systemd
___


-- 
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/947360.61879...@smtp129.mail.ir2.yahoo.com

Re: [debian-mysql] MySQL.. no.. _I_ need your help!

2013-10-27 Thread Stewart Smith 
Clint Byrum  writes:
> I am asking you, the Debian developers, to step up and help. I am
> basically unable to contribute more than an hour a month now. There is a
> new round of secret CVE bugs to fix, and some old bugs that need to be
> handled. I think my October hour is about to be available, so I might
> be able to address those, but after that, if I don't get any more help,
> I'm done.
>
> What can you do to help?
>
> - Raise your hand and say you'll help

I'm currently putting effort into getting Percona Server packages able
to be included and after that work is done, will be focusing on having
less variation between them and the MySQL packages, hopefully improving
everything as part of that effort. So this is a somewhat raised hand :)

-- 
Stewart Smith


pgphYjRKjv0J5.pgp
Description: PGP signature

Re: Proposal: switch default desktop to xfce

2013-10-27 Thread Paul Wise 
On Sat, Oct 26, 2013 at 2:15 AM, Joey Hess wrote:

> I do wish that some of the .. energy .. seen in these threads could be
> used for something more interesting. For example, find a way to detect
> touch screen systems, on which xfce is *not* pleasant, and don't install
> a desktop task there, but a separate task with whichever UI is currently
> best suited for tablets.

The situation with touch screen systems is a bit more complicated than
just "install a tablet UI".

By way of example; my primary computer is a Lenovo Thinkpad X201
Tablet. This is a normal Thinkpad laptop with a touchscreen where the
screen can be rotated and therefore hide the keyboard with or without
the touchscreen being hidden. Right now I'm using it as a desktop
though, with external monitor, keyboard and mouse. For this particular
machine, installing a normal desktop is the probably right way to go.
Unfortunately none of them appear to have sane touch interaction; the
touchscreen selects text instead of scrolling or buttons are tiny. I
rarely use this device in tablet mode but I imagine the many artists
using it would do that quite often.

I seem to remember that with Windows 8 coming out and having pervasive
support for touchscreens, there are even external monitors with touch
support. Clearly on tower machines with a touch-screen monitor you
aren't going to want a tablet OS.

Another example; a while ago I installed Debian on a Samsung Galaxy S
smartphone. While at the time the touchscreen didn't work in Debian
due to Linux and Xorg driver issues, installing a tablet UI is clearly
not the right choice there either; you need something with big buttons
that is finger-friendly, at the time enlightenment had a UI that was
designed for smartphones. I also have had an OpenMoko with Debian on
it. For OpenMoko devices the enlightenment UI has issues due to the
OpenMoko's screen inset meaning that UI elements close to the edge are
unusable. The QtMoko UI however avoids that issue but isn't in Debian
yet.

http://bonedaddy.net/pabs3/log/2012/12/03/debian-mobile/

My conclusion is that the right UI to choose is quite machine-specific
and also user-specific.

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

Re: Proposal: switch default desktop to xfce

2013-10-27 Thread Paul Wise 
On Sat, Oct 26, 2013 at 3:19 AM, Joey Hess wrote:

> I also wonder why unity is not being packaged in Debian..

Based on the logs for #609278 it appears there is a lot of interest
and some people working on packaging it but it sounds like it is hard
to build and requires patches in external components.

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