Re: Let's abandon debian-devel.

[Gergely Nagy]

> "David" == David L Craig  writes:

David> On 14Nov10:2154+0100, Gergely Nagy wrote:
>> You do realize topic lists are public too, right?

David> Yes, but most Debian users don't even know about
David> them nor do they need to since the traditional
David> lists have been doing their jobs for quite a
David> while.  If you shut them down, I expect most of
David> the public will not find the topic lists.

Most Debian users need not concern themselves with development lists,
like they usually do not subscribe to debian-devel@ either. If they do
want to find a list for a particular topic, it is not rocket science to
do so.

They will find it.

-- 
|8]


signature.asc
Description: PGP signature

Re: Let's abandon debian-devel.

[Andrey Rahmatullin]

On Tue, Nov 11, 2014 at 08:50:52AM +0100, Matthias Urlichs wrote:
> I'd be in favor of a different approach: moderate debian-devel. Not the
> content, but the list of people allowed to post. Pre-seed it with the
> email adresses in our keyring and auto-add anybody who signs their email
> with a key in our keyring.
Not all Debian contributors are DDs.
-vote should be limited to people with voting rights though.

-- 
WBR, wRAR


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/2014085158.ga25...@belkar.wrar.name

release browser-related packages to stable?

[Daniel Pocock]

Since 2013, Debian has allowed new browser versions to enter stable[1]
even though most other package versions are frozen

The security team announcement mentions that "some Xul extensions
currently packaged in the Debian archive are not compatible" and that a
solution to that is still being worked out.

There are similar consequences for some server-side content, e.g. jessie
will include various WebRTC JavaScript libraries.  The packages
asterisk, jssip, jscommunicator and sipml5 closely follow this emerging
standard.  There have already been some occasions where changing browser
technology (e.g. Chrome changing from SDES to DTLS-SRTP encryption) has
caused these other packages to become unusable for periods of time.

Has there already been any further discussion about the solution for Xul
extensions packaged in Debian?

With the freeze for jessie having just started, should the freeze
guidelines be amended to make it easier for packages closely related to
the browser to be updated to new versions at any time during the freeze
if the browser version itself changes?

Are there people who would object to such updates?


1. https://lists.debian.org/debian-security-announce/2013/msg00107.html


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/5461d85b.4020...@pocock.pro

Aw: Let's abandon debian-devel.

[Steffen Möller]

Hi Charles,
 
> after unsubscribing from debian-vote, I had a bit of a thought about
> debian-devel, which is hard to follow now, and suddenly I saw something very
> clear.  This year's freeze seems of an excellent quality and promises to be
> brief.  Is that thanks to debian-devel ?  Not much.  Excellent work is being
> done on the Installer and is that thanks to debian-devel ?  Not much.  In 2010
> when I was candidate to become DPL, I wrote that Debian was in growth crisis.
> I think that it never has been so true.  Places like debian-devel, which can 
> be
> instrumental in smaller projects, are very toxic in larger ones.
> 
> >From now on I will try to see if I can give to Debian the same quality of
> contribution without being subscribed to debian-devel.  And I invite you to
> think about it and *not* to discuss it on this list.
> 
> With most of the work done on topic mailing lists, trolls lose the lever 
> effect
> they have when feasting on debian-devel or debian-vote.  Let's make our 
> project
> stronger by reducing thr attack surface for troublemakers.

To me, the Blends of Debian and the many pkg-xyz lists are a bit of an answer.
Those are full with positive vibes, over time and with the help of sprints
we often came to know each other personally, too.

Debian-devel came to have problems. I personally found the answer in asking my
geographically local (and, admittedly, 20 years younger) hackers environment
about the issues that Debian is discussing, thinking that any vote in Debian
should also have me a bit as a representative of my surroundings whenever I
feel undecided. This was quite curative (I suggest to everyone take that
medicine yourselves) and somewhat also returns the strenghts to find the gems
in debian/devel again.

Best,

Steffen


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/trinity-fd49eeea-cf51-4c93-8402-779c4e2ce46e-1415702045107@3capp-gmx-bs59

Re: Removing duplication: Word lists of common words in languages

[Simon McVittie]

On 10/11/14 23:16, Ben Finney wrote:
> To avoid duplicating these “the N most common words, ranked by
> frequency, for language FOO”

For a password generator you ideally want the word-list to be sorted
alphabetically, so that it's trivial to verify "by eye" that there are
no duplicates. Duplicate entries would reduce the entropy of the
generated passwords, without anything being obviously wrong.

(Idea stolen from Diceware, for which it is essential, because the word
list is designed to be usable without a computer; for online password
generators it's less important, because you can compare wc -l with
sort -u | wc -l to confirm that there are no duplicates.)

It's probably also a good idea to have a power-of-2 wordlist size, to
make it trivial to pick one without bias using bytes from
/dev/[u]random. (Diceware uses a power-of-6 wordlist size for analogous
reasons, because it's based on rolling dice.)

S


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/5461e839.5030...@debian.org

Blends in D-I tasksel selection? (Was: Filed Bug#758096: tasksel: Allow to select specific packages during installation - just "DE", "Web server", "Mail server" is NOT enough)

[Andreas Tille]

Hi,

I guess the sad news that Joey Hess leaves Debian has spread also to
Debian Blends list.  The direct consequence for Blends is that Joey will
not work on this bug (#758096) and will also most probably not rise any
opinion on it any more but we somehow need to move on.

I realised that the changelog says:

...
tasksel (3.23) unstable; urgency=medium
...
  * Added a Parent field, which results in a simple nested hierarchy
display. (Currently only one level deep, and not collapsible since
debconf doesn't have an appropriate widget.)
...
 * Removed mail-server, dns-server, database-server, file-server tasks,
which were not well enough defined to be useful and whose menu
space will be better used for blends or openstack tasks.
Closes: #604100
...


which according to Git (git://git.debian.org/git/tasksel/tasksel.git)
relates to this commit.

commit 9e2290b531e414ffb16e89b50cf5c44413fa71b8
Author: Joey Hess 
Date:   Sun Sep 7 22:45:02 2014 -0400

hierarchical tasks, desktop selection, and general massive changes

...
* Added a Parent field, which results in a simple nested hierarchy
  display. (Currently only one level deep, and not collapsable since
  debconf doesn't have an appropriate widget.)
...
* Removed mail-server, dns-server, database-server, file-server tasks,
  which were not well enough defined to be useful and whose menu
  space will be better used for blends or openstack tasks.
...


This again shows Joey's great way to deal with things by simply working
at something rather than doing a lot of talk.  I really appreciate this
- another thanks to Joey.

As far as I can see without testing this means regarding the display of
Blends in D-I (#758096) that we only need to *decide* and in case we
want to do this add the needed bits of data.

Any opinions regarding a decision?

Kind regards

Andreas.

PS: I'll be AFK from 19. Nov to 3. Dez.

-- 
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: https://lists.debian.org/2014105955.gn13...@an3as.eu

Re: free choice in installer?

[Andreas Tille]

On Mon, Nov 10, 2014 at 11:15:12AM +0100, Michael Ole Olsen wrote:
> If there was a choice in the installer for Init system and boot loader there 
> would be nobody complaining.
> 
> People only complain when there isn't a choice and they are forced to use 
> something new.

>From what research are you taking this generalisation?  All non-IT
experts I know (proof by counter-example) would be really happy to have
no choice but rather one single option which works.  You might also like
to think about all those Win+OSX users who have no problem to accept
what they get.  I admit regarding init system I feel like them and
prefer also one solution that works without any need to spend time into
a decision making process (feel free to blame me about this).

So please be careful to do generalised statements about "people" by
assuming that all people are thinking like you.

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: https://lists.debian.org/2014111906.gp13...@an3as.eu

Re: Let's abandon debian-devel.

[Matthias Urlichs]

Hi,

Andrey Rahmatullin:
> On Tue, Nov 11, 2014 at 08:50:52AM +0100, Matthias Urlichs wrote:
> > I'd be in favor of a different approach: moderate debian-devel. Not the
> > content, but the list of people allowed to post. Pre-seed it with the
> > email adresses in our keyring and auto-add anybody who signs their email
> > with a key in our keyring.
> Not all Debian contributors are DDs.

I know. So? If the first email of a non-DD gets delayed for a few hours,
that's an acceptable price to pay IMHO. (We could also auto-approve if
too much time has passed without moderator activity.)

> -vote should be limited to people with voting rights though.

+1
-- 
-- Matthias Urlichs


signature.asc
Description: Digital signature

Re: Let's abandon debian-devel.

[Ben Finney]

Andrey Rahmatullin  writes:

> On Tue, Nov 11, 2014 at 08:50:52AM +0100, Matthias Urlichs wrote:
> > I'd be in favor of a different approach: moderate debian-devel. Not
> > the content, but the list of people allowed to post. Pre-seed it
> > with the email adresses in our keyring and auto-add anybody who
> > signs their email with a key in our keyring.
> Not all Debian contributors are DDs.

But all Debian Contributors have their OpenPGP key in the project's
keyring. No?

-- 
 \  “The best way to get information on Usenet is not to ask a |
  `\   question, but to post the wrong information.” —Aahz |
_o__)  |
Ben Finney


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/85oasec73i@benfinney.id.au

Re: Let's abandon debian-devel.

[Martin Bagge / brother]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On 2014-11-11 12:25, Ben Finney wrote:
> But all Debian Contributors have their OpenPGP key in the
> project's keyring. No?

Most certainly not.
Parts where many people who is not DD nor DM takes part include docs,
web, translations and graphics.

- -- 
brother
http://sis.bthstudent.se
-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQEcBAEBCAAGBQJUYfYuAAoJEJbdSEaj0jV74ZUH/3pxK2deT3jz63ZJrCCtoy8D
wXXe+5zicV+n5UNuJPgGI60fIjkvY/F/DwGzlx8FXcc08W9Ze11Xzk9H48BVLniQ
Qd/YglBOafCMlwe2WZCR+qla0IHmkLL6OqkA1r9MlB26F6KDwpndv2NMIBk6QWxf
P1QWjQs+KzvZ3obU267ArthNzbRLlTmwuu/08RE5MMRdmDv6NTouu4X4CyTctqvJ
I6VLpiYps/4vxHhG9f7v95J+VuNclYKA8yUfjIxU+M6Dc+ogIEDy3/F5zbImyng1
vWpVipZ4L3sykF3Y98XzZ4jGWeKiSqeBwFk/3UomTIQzGpURLvtNhlKsHYxCAr4=
=gh9m
-END PGP SIGNATURE-


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/5461f62e.2090...@bsnet.se

Re: Removing duplication: Word lists of common words in languages

[Ben Finney]

Simon McVittie  writes:

> On 10/11/14 23:16, Ben Finney wrote:
> > To avoid duplicating these “the N most common words, ranked by
> > frequency, for language FOO”
>
> For a password generator you ideally want the word-list to be sorted
> alphabetically, so that it's trivial to verify "by eye" that there are
> no duplicates. Duplicate entries would reduce the entropy of the
> generated passwords, without anything being obviously wrong.

It's already trivial to test a wordlist, regardless of its existing
order, to check whether it has duplicates:

$ ( sort | uniq -d | wc -l ) < /usr/share/dict/american-english
0

What's impossible is to go from an alphabetically-ordered list of unique
words to a frequency-ordered one, without introducing the frequency
information from outside.

> (Idea stolen from Diceware, for which it is essential, because the word
> list is designed to be usable without a computer

Well, I don't think we need to cater for “use without a computer” for
programs in Debian. Unless I'm misunderstanding something?

An important property of a “N most common” wordlist ordered by frequency
in the language, is that it's trivial to get a “X most common” wordlist
(where X < N) by simply truncating the list. This is a property lacking
in a wordlist not ordered by frequency.


Where is a good authoritative source of such words, by frequency, for
various natural languages, suitable for inclusion in Debian as a data
package?

-- 
 \   “Anything that we scientists can do to weaken the hold of |
  `\religion should be done and may in the end be our greatest |
_o__)  contribution to civilization.” —Steven Weinberg |
Ben Finney


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/85k332c61b@benfinney.id.au

Re: free choice in installer?

[Stephan Seitz]

On Tue, Nov 11, 2014 at 12:19:06PM +0100, Andreas Tille wrote:

From what research are you taking this generalisation?  All non-IT

experts I know (proof by counter-example) would be really happy to have
no choice but rather one single option which works.  You might also like


Of course, but the problem is that they don’t share the same opinion 
about the working solution. Or we wouldn’t have different editors, window 
managers, desktop environments, monitoring tools, etc.



to think about all those Win+OSX users who have no problem to accept
what they get.  I admit regarding init system I feel like them and


Well, that’s the reason why I’m using Linux because I don’t accept what 
I get with Windows. And if you have noticed the complains about the 
ribbon in Office or the Win8 GUI then you’ll see that Windows users don’t 
always accept what they get.



So please be careful to do generalised statements about "people" by
assuming that all people are thinking like you.


If you don’t want choices you can stay with Windows. There is no reason 
to make Linux like Windows.


Shade and sweet water!

Stephan

--
| Stephan Seitz  E-Mail: s...@fsing.rootsland.net |
| Public Keys: http://fsing.rootsland.net/~stse/keys.html |


smime.p7s
Description: S/MIME cryptographic signature

Re: Let's abandon debian-devel.

[Andrey Rahmatullin]

On Tue, Nov 11, 2014 at 10:25:05PM +1100, Ben Finney wrote:
> > > I'd be in favor of a different approach: moderate debian-devel. Not
> > > the content, but the list of people allowed to post. Pre-seed it
> > > with the email adresses in our keyring and auto-add anybody who
> > > signs their email with a key in our keyring.
> > Not all Debian contributors are DDs.
> But all Debian Contributors have their OpenPGP key in the project's
> keyring. No?
Not all Debian contributors are Debian Contributors whatever that means.
Lots of people without keys somewhere in official keyrings are doing
useful work. Some of them are even maintaining packages.

-- 
WBR, wRAR


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/2014114409.ga29...@belkar.wrar.name

Re: Let's abandon debian-devel.

[Andrey Rahmatullin]

On Tue, Nov 11, 2014 at 12:22:53PM +0100, Matthias Urlichs wrote:
> > > I'd be in favor of a different approach: moderate debian-devel. Not the
> > > content, but the list of people allowed to post. Pre-seed it with the
> > > email adresses in our keyring and auto-add anybody who signs their email
> > > with a key in our keyring.
> > Not all Debian contributors are DDs.
> I know. So? If the first email of a non-DD gets delayed for a few hours,
> that's an acceptable price to pay IMHO. 
Nothing about delays wasn't mentioned in your previous email unless I'm
misunderstanding the "anybody who signs their email with a key in our
keyring" part.

-- 
WBR, wRAR


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/2014114522.gb29...@belkar.wrar.name

Re: Let's abandon debian-devel.

[Brett Parker]

On 11 Nov 22:25, Ben Finney wrote:
> Andrey Rahmatullin  writes:
> 
> > On Tue, Nov 11, 2014 at 08:50:52AM +0100, Matthias Urlichs wrote:
> > > I'd be in favor of a different approach: moderate debian-devel. Not
> > > the content, but the list of people allowed to post. Pre-seed it
> > > with the email adresses in our keyring and auto-add anybody who
> > > signs their email with a key in our keyring.
> > Not all Debian contributors are DDs.
> 
> But all Debian Contributors have their OpenPGP key in the project's
> keyring. No?

Correct, no, they don't. Think translators, and other such
contributions.

-- 
Brett Parker


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/2014114123.GN906@miranda

Re: Let's abandon debian-devel.

[Wookey]

+++ Charles Plessy [2014-11-10 23:25 +0900]:
> Hi all,
> 
> >From now on I will try to see if I can give to Debian the same quality of
> contribution without being subscribed to debian-devel.  And I invite you to
> think about it and *not* to discuss it on this list.

Just a data-point:

I joined d-devel when I joined debian. It was noisy and after a while
I unsubscribed. And it stayed that way for several years. I did my
stuff in my little corner and that worked, but I had almost no idea
what was going in in Debian generally and was often surprised by events/changes.

At some point I tried joining up again and have since become much more
involved, at least partly due to having some feel for what is
currently going on.

So -devel is noisy and sometimes unhelpful, but at least for me being
subscribed is definitely more useful than not being subscribed. 

Possibly the same effect could be achieved by joining -project. I've
never tried that...

So if your purpose is just to work on your packages, then yes ignore
-devel - you will get a quieter life. But it does disconnect you
noticeably. Perhaps that is less true than it was, as there are more
alternatives (such as planet).

Just some (anecdotal) data.

Wookey
-- 
Principal hats:  Linaro, Emdebian, Wookware, Balloonboard, ARM
http://wookware.org/


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/2014122711.gd28...@stoneboat.aleph1.co.uk

Re: Let's abandon debian-devel.

[Matthias Urlichs]

Hi,

Andrey Rahmatullin:
> > I know. So? If the first email of a non-DD gets delayed for a few hours,
> > that's an acceptable price to pay IMHO. 
> Nothing about delays wasn't mentioned in your previous email

Moderating (some) emails to d-d implies delaying those emails until
a human moderator looks at them. To me at least. Therefore I didn't
think of explicitly mentioning that; sorry if that was unclear.
-- 
-- Matthias Urlichs


signature.asc
Description: Digital signature

Re: Let's abandon debian-devel.

[Neil McGovern]

On Tue, Nov 11, 2014 at 01:30:58PM +0100, Matthias Urlichs wrote:
> Andrey Rahmatullin:
> > > I know. So? If the first email of a non-DD gets delayed for a few hours,
> > > that's an acceptable price to pay IMHO. 
> > Nothing about delays wasn't mentioned in your previous email
> 
> Moderating (some) emails to d-d implies delaying those emails until
> a human moderator looks at them. To me at least. Therefore I didn't
> think of explicitly mentioning that; sorry if that was unclear.

My concern would be around /which/ human moderator does this. The
project passed a GR about declassifying -private, for example, and this
had never been achieved because the people who are willing to put the
work in don't exist.

Neil
-- 


signature.asc
Description: Digital signature

Re: Let's abandon debian-devel.

[Andrey Rahmatullin]

On Tue, Nov 11, 2014 at 12:42:38PM +0100, Martin Bagge / brother wrote:
> > But all Debian Contributors have their OpenPGP key in the
> > project's keyring. No?
> Most certainly not.
> Parts where many people who is not DD nor DM takes part include docs,
> web, translations and graphics.
I think there were some numbers about percentage of packages (or uploads?)
maintained by people not in keyrings.
Nobody should think they are negligible.

-- 
WBR, wRAR


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/2014122515.ga31...@belkar.wrar.name

Re: Let's abandon debian-devel.

[Andrey Rahmatullin]

On Tue, Nov 11, 2014 at 01:30:58PM +0100, Matthias Urlichs wrote:
> > > I know. So? If the first email of a non-DD gets delayed for a few hours,
> > > that's an acceptable price to pay IMHO. 
> > Nothing about delays wasn't mentioned in your previous email
> Moderating (some) emails to d-d implies delaying those emails until
> a human moderator looks at them. To me at least. Therefore I didn't
> think of explicitly mentioning that; sorry if that was unclear.
That's not the same as delaying only the first email though :)

-- 
WBR, wRAR


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/2014123410.ga31...@belkar.wrar.name

Re: Let's abandon debian-devel.

[Scott Kitterman]

On Tuesday, November 11, 2014 12:41:12 PM Neil McGovern wrote:
> On Tue, Nov 11, 2014 at 01:30:58PM +0100, Matthias Urlichs wrote:
> > Andrey Rahmatullin:
> > > > I know. So? If the first email of a non-DD gets delayed for a few
> > > > hours,
> > > > that's an acceptable price to pay IMHO.
> > > 
> > > Nothing about delays wasn't mentioned in your previous email
> > 
> > Moderating (some) emails to d-d implies delaying those emails until
> > a human moderator looks at them. To me at least. Therefore I didn't
> > think of explicitly mentioning that; sorry if that was unclear.
> 
> My concern would be around /which/ human moderator does this. The
> project passed a GR about declassifying -private, for example, and this
> had never been achieved because the people who are willing to put the
> work in don't exist.

I'd be willing to help out.

Scott K

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

Re: Let's abandon debian-devel.

[Matthias Urlichs]

Hi,

Scott Kitterman:
> On Tuesday, November 11, 2014 12:41:12 PM Neil McGovern wrote:
> > On Tue, Nov 11, 2014 at 01:30:58PM +0100, Matthias Urlichs wrote:
> > > Andrey Rahmatullin:
> > > > > I know. So? If the first email of a non-DD gets delayed for a few
> > > > > hours,
> > > > > that's an acceptable price to pay IMHO.
> > > > 
> > > > Nothing about delays wasn't mentioned in your previous email
> > > 
> > > Moderating (some) emails to d-d implies delaying those emails until
> > > a human moderator looks at them. To me at least. Therefore I didn't
> > > think of explicitly mentioning that; sorry if that was unclear.
> > 
> > My concern would be around /which/ human moderator does this. The
> > project passed a GR about declassifying -private, for example, and this
> > had never been achieved because the people who are willing to put the
> > work in don't exist.
> 
> I'd be willing to help out.
> 
So would I.

Declassifying -private is different because (apparently) nobody wants to
spend a block of time wading through old -private emails, most of which are
now irrelevant. In contrast, a quick decision about whether to whitelist an
email, when I'm scanning my mails anyway, doesn't have the same impact.

-- 
-- Matthias Urlichs


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/2014125957.gf23...@smurf.noris.de

Re: What is the policy on audio group? and, proposal of a new group for the jack audio server

[Felipe Sateler]

On Mon, 10 Nov 2014 11:08:38 +, Simon McVittie wrote:

> On 10/11/14 02:59, Christian Hofstaedtler wrote:
>> I vaguely remember PolicyKit being involved in the daemon situation,
>> when mpd tries to talk to a pulseaudio server which magically gets
>> spawned
> 
> PolicyKit is typically (only?) used when a less-privileged process,
> typically a user interface, communicates with a more-privileged service.
> It's possible that something PK-related is going on, but I can't
> immediately see any reason why either mpd or PulseAudio would want to
> interact with it: both normally run with an ordinary user's privileges.
> 
> The typical scenario is:
> 
> * I tell NetworkManager to connect to a wireless network
>   (or tell some other privileged service to do some other action)
> 
> * NetworkManager (or other privileged service) asks PolicyKit "is it OK
>   to let smcv do this?"
> 
> * PolicyKit consults its sysadmin-, distro- or upstream-supplied
>   policies, checks the facts relevant to those policies (I am in
>   some groups, I am actively logged-in locally), optionally asks me
>   for my password to confirm that I am actually present, and replies
>   "yes" or "no"

I'm not sure if it is PolicyKit or a related service (old documentation 
suggests it was ConsoleKit, nowadays it should be logind?), but /dev/snd/
* get ACLs added for the currently logged in users:

% getfacl /dev/snd/controlC0 
getfacl: Removing leading '/' from absolute path names
# file: dev/snd/controlC0
# owner: root
# group: audio
user::rw-
user:felipe:rw-
group::rw-
mask::rw-
other::---


Thus any user (not on the audio group) process will not have access to 
the audio device until that user is on a physical terminal.

AFAICT, pulseaudio does not talk directly to polkitd.

-- 
Saludos,
Felipe Sateler


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

Re: REISSUED CfV: General Resolution: Init system coupling

[Ian Jackson]

Santiago Vila writes ("Re: REISSUED CfV: General Resolution: Init system 
coupling"):
> On Mon, Nov 10, 2014 at 06:12:46PM +, Ian Jackson wrote:
> > I have a half-written series to make it cope with lettered, rather
> > than numbered, options.  Would it be worth my while finishing that off
> > (in my CFT) ?
> 
> The voting process is already complex enough. If it is going to be like this:
> 
> GR Proposal: Option A.
> Amendment A: Option B.
> Amendment B: Option C.
> 
> we might better stick with numbered options.

*rotfl*.  I'm hoping the Secretary could avoid that and that we could
instead have

  GR Proposal: Option A.
  Amendment B: Option B.
  Amendment C: Option C.

or

  GR Proposal: Option Y.
  Amendment A: Option A.
  Amendment B: Option B.

or something.


Personally I find the current arrangements extremely confusing -
particularly, the way that devotee often provides transposed
information, which is quite hard to notice.

Ian.


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/21602.2772.916501.616...@chiark.greenend.org.uk

Re: Let's abandon debian-devel.

[Holger Levsen]

Hi,

On Dienstag, 11. November 2014, Matthias Urlichs wrote:
> > I'd be willing to help out.
> So would I.

me too, should this road be chosen.


cheers,
Holger


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

Re: Removing duplication: Word lists of common words in languages

[Ian Jackson]

Ben Finney writes ("Re: Removing duplication: Word lists of common words in 
languages"):
> Where is a good authoritative source of such words, by frequency, for
> various natural languages, suitable for inclusion in Debian as a data
> package?

I had roughly this question in 2013, and found the answer.  Here is
probably the best starting point:

http://www.chiark.greenend.org.uk/ucgi/~ijackson/git?p=evade-mail-usrlocal.git;a=blob;f=lemma.al-permission.mbox

Ian.


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/21602.3533.32160.657...@chiark.greenend.org.uk

Should fast-evolving packages be backports-only?

[Rebecca N. Palmer]

It has been recently stated [0-1] that backports is enabled by default 
in Jessie.


1. Does that mean that if pkgX is in jessie-backports but not jessie, 
"apt-get install pkgX" will install it from -backports?


2. If so, when (if ever) is it appropriate to deliberately invoke that 
behaviour by removing pkgX from jessie?


Possible candidates:
a. Packages that work closely with hardware, where old versions don't 
work with new hardware (example: beignet)
b. Packages that implement fast-evolving file formats or network 
protocols, where you need the same version as the people you are 
communicating with (possible example: jscommunicator [2])
c. Packages that are generally rapidly improving, and are typically used 
where this improvement is more important than stability


The advantage of doing so (over having both the old version in jessie 
and the new one in jessie-backports) is that non-technical users (who 
may not know that backports exists) get the new version they probably 
want; the disadvantage is that users who explicitly want stability can 
no longer choose it (except by pinning or using snapshot.debian.org, 
which also block security updates of that package).


In the long run it may be a better idea to have these packages suggest 
upgrading to -backports in their "this hardware/protocol version/option 
not supported" error message, or on startup if there is no easy way to 
identify attempts to use the newer features, but it is too late to do 
this for jessie.


(Release team have already ruled that a. (#767961) and b. (#768933) are 
not valid reasons for freeze exceptions; I guess this would also forbid 
stable updates)


[0] https://lists.debian.org/debian-devel/2014/11/msg00339.html
[1] My own sources.list has
# jessie-backports, previously on backports.debian.org
# Line commented out by installer because it failed to verify:
#deb http://ftp.uk.debian.org/debian/ jessie-backports main
but https://lists.debian.org/debian-user/2014/09/msg01174.html reports 
getting one with that line uncommented

[2] https://lists.debian.org/debian-release/2014/11/msg00866.html


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/54620f78.4040...@zoho.com

Re: Let's abandon debian-devel.

[Neil McGovern]

On Tue, Nov 11, 2014 at 02:13:20PM +0100, Holger Levsen wrote:
> On Dienstag, 11. November 2014, Matthias Urlichs wrote:
> > > I'd be willing to help out.
> > So would I.
> me too, should this road be chosen.
> 

Excellent. In that case, my position is now "meh" :)

Neil
-- 


signature.asc
Description: Digital signature

Re: REISSUED CfV: General Resolution: Init system coupling

[Ansgar Burchardt]

On 11/11/2014 02:10 PM, Ian Jackson wrote:
> Santiago Vila writes ("Re: REISSUED CfV: General Resolution: Init system 
> coupling"):
>> The voting process is already complex enough. If it is going to be like this:
>>
>> GR Proposal: Option A.
>> Amendment A: Option B.
>> Amendment B: Option C.
>>
>> we might better stick with numbered options.
> 
> *rotfl*.  I'm hoping the Secretary could avoid that and that we could
> instead have
> 
>   GR Proposal: Option A.
>   Amendment B: Option B.
>   Amendment C: Option C.

Or even simpler

  Proposal A: Option A
  Proposal B: Option B
  Proposal C: Option C

I'm not sure why there is a need to treat the initial proposal and later
ones in a different way.

As a related question, I also don't understand why the proposer of the
initial proposal and of later amendments are treated differently in the
constitution, e.g. in A.1.5. Ian suggested this might just be a bug[1]?

(I'm also wondering if there is a difference between "original proposer"
as used in A.1.4 and "proposer of a resolution" in A.1.5.)

Ansgar

  [1] 


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/546216fb.1090...@debian.org

Re: Should fast-evolving packages be backports-only?

[Daniel Pocock]

On 11/11/14 14:30, Rebecca N. Palmer wrote:
> It has been recently stated [0-1] that backports is enabled by default
> in Jessie.
>
> 1. Does that mean that if pkgX is in jessie-backports but not jessie,
> "apt-get install pkgX" will install it from -backports?
>
> 2. If so, when (if ever) is it appropriate to deliberately invoke that
> behaviour by removing pkgX from jessie?
>
> Possible candidates:
> a. Packages that work closely with hardware, where old versions don't
> work with new hardware (example: beignet)
> b. Packages that implement fast-evolving file formats or network
> protocols, where you need the same version as the people you are
> communicating with (possible example: jscommunicator [2])

> c. Packages that are generally rapidly improving, and are typically
> used where this improvement is more important than stability


Maybe also

d. packages that the security team decide to support by using
upstream releases (in other words, should the browsers be distributed
through backports only?)

One big question that arises then (and what I asked in a separate thread
about the browser-related packages but it is relevant to other classes
of package too) is compatibility
- if package foo is allowed to change, do all packages broken by the
change (e.g. browser plugins) get to be uploaded again too?
- if some package hides the complexity of the change and the maintainer
has kept the API stable so that dependent packages don't break should it
be looked on more favorably and allowed to be updated in stable too?

Personally, I feel that having backports enabled by default is only part
of the solution to the challenges with volatile packages but it may be a
step in the right direction.

I also feel that this is something that impacts each maintainer and each
user differently.  Some people are working in parts of the system where
the freeze concept really is the most important thing.  Other people are
working on applications where network compatibility is the most
important thing (as it is with communications) and people simply won't
use the package or won't be able to use it successfully if is not
updated.  Ultimately, with more and more packages being in this category
as the world becomes more networked/cloudified, this impacts Debian's
relevance for whole groups of users.


>
> The advantage of doing so (over having both the old version in jessie
> and the new one in jessie-backports) is that non-technical users (who
> may not know that backports exists) get the new version they probably
> want; the disadvantage is that users who explicitly want stability can
> no longer choose it (except by pinning or using snapshot.debian.org,
> which also block security updates of that package).
>
> In the long run it may be a better idea to have these packages suggest
> upgrading to -backports in their "this hardware/protocol
> version/option not supported" error message, or on startup if there is
> no easy way to identify attempts to use the newer features, but it is
> too late to do this for jessie.
>
> (Release team have already ruled that a. (#767961) and b. (#768933)
> are not valid reasons for freeze exceptions; I guess this would also
> forbid stable updates)
>
> [0] https://lists.debian.org/debian-devel/2014/11/msg00339.html
> [1] My own sources.list has
> # jessie-backports, previously on backports.debian.org
> # Line commented out by installer because it failed to verify:
> #deb http://ftp.uk.debian.org/debian/ jessie-backports main
> but https://lists.debian.org/debian-user/2014/09/msg01174.html reports
> getting one with that line uncommented
> [2] https://lists.debian.org/debian-release/2014/11/msg00866.html
>
>


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/54621b37.4040...@pocock.pro

Re: What is the policy on audio group? and, proposal of a new group for the jack audio server

[Simon McVittie]

On 11/11/14 13:04, Felipe Sateler wrote:
> I'm not sure if it is PolicyKit or a related service (old documentation 
> suggests it was ConsoleKit, nowadays it should be logind?), but /dev/snd/
> * get ACLs added for the currently logged in users

Yes, that's exactly what I said a couple of mails ago :-)

It is indeed systemd-logind that does this now. It's a 2-stage process:
udev rules like /lib/udev/rules.d/50-udev-default.rules mark devices
that should be user-accessible with the "uaccess" tag during device
discovery (and sysadmin-written rules can presumably override the
defaults to remove that tag if necessary). Later, systemd-logind looks
for any devices with that tag and puts appropriate ACLs on them.

Older versions of udev and ConsoleKit cooperated to do something similar
with a "udev-acl" tag.

PolicyKit is not involved here.

S


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/54621ffd.4090...@debian.org

Re: Should fast-evolving packages be backports-only?

[Scott Howard]

On Tue, Nov 11, 2014 at 9:20 AM, Daniel Pocock  wrote:
> On 11/11/14 14:30, Rebecca N. Palmer wrote:
>> It has been recently stated [0-1] that backports is enabled by default
>> in Jessie.
>>
>> 1. Does that mean that if pkgX is in jessie-backports but not jessie,
>> "apt-get install pkgX" will install it from -backports?
>>
>> 2. If so, when (if ever) is it appropriate to deliberately invoke that
>> behaviour by removing pkgX from jessie?
> One big question that arises then (and what I asked in a separate thread
> about the browser-related packages but it is relevant to other classes
> of package too) is compatibility
> - if package foo is allowed to change, do all packages broken by the
> change (e.g. browser plugins) get to be uploaded again too?
> - if some package hides the complexity of the change and the maintainer
> has kept the API stable so that dependent packages don't break should it
> be looked on more favorably and allowed to be updated in stable too?

maybe a crazy idea, but maybe build in some easy way to apt-pin
package (and dependencies) to testing in apt/dpkg? This way we can
leverage all of the existing transition infrastructure and essentially
provide backports for all packages with no extra work?
possibly lots of unintended consequences, and someone will mess up
their machine by pulling in tons of libraries from the future, but it
will essentially perform the same function for those users that need
the up-to-date leaf packages while keeping the stable core. testing is
pinned by default to <100

"$ apt-get install-updated ${PACKAGE}"

where install-updated will pin ${PACKAGE} to testing and do "$ apt-get
install ${PACKAGE} -t testing" This will pull in the package from
testing and dependencies from testing that are missing from stable.
Not a good idea for jessie, maybe something to think about for future.

Either way, I think you have excellent points in your final paragraph,
thank you Rebecca and Daniel for bringing this up.

On Tue, Nov 11, 2014 at 9:20 AM, Daniel Pocock  wrote:
"I also feel that this is something that impacts each maintainer and each
user differently.  Some people are working in parts of the system where
the freeze concept really is the most important thing.  Other people are
working on applications where network compatibility is the most
important thing (as it is with communications) and people simply won't
use the package or won't be able to use it successfully if is not
updated.  Ultimately, with more and more packages being in this category
as the world becomes more networked/cloudified, this impacts Debian's
relevance for whole groups of users."


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/cang8-dbkbdzghr-vvkc7x9g0f6c1quaz9j3kgvbsdsusent...@mail.gmail.com

Re: What is the policy on audio group? and, proposal of a new group for the jack audio server

[Felipe Sateler]

On Tue, 11 Nov 2014 14:41:01 +, Simon McVittie wrote:

> On 11/11/14 13:04, Felipe Sateler wrote:
>> I'm not sure if it is PolicyKit or a related service (old documentation
>> suggests it was ConsoleKit, nowadays it should be logind?), but
>> /dev/snd/
>> * get ACLs added for the currently logged in users
> 
> Yes, that's exactly what I said a couple of mails ago :-)

Oops :)

> 
> It is indeed systemd-logind that does this now. It's a 2-stage process:
> udev rules like /lib/udev/rules.d/50-udev-default.rules mark devices
> that should be user-accessible with the "uaccess" tag during device
> discovery (and sysadmin-written rules can presumably override the
> defaults to remove that tag if necessary). Later, systemd-logind looks
> for any devices with that tag and puts appropriate ACLs on them.
> 
> Older versions of udev and ConsoleKit cooperated to do something similar
> with a "udev-acl" tag.
> 
> PolicyKit is not involved here.

Thanks for the clarification.

I'll just  that the relevant file is /lib/udev/rules.d/70-uaccess.rules 
for systemd systems, and /l/u/r/70-udev-acl.rules for consolekit systems.

-- 
Saludos,
Felipe Sateler


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

r-base-core upload to unstable does not respect freeze policy

[Andreas Tille]

Hi,

Freeze policy[1] says:


  Uploads to unstable
  ===
  
  Since many updates (hopefully, the vast majority) will be via unstable,
  changes there can be disruptive if they would be unsuitable for Jessie.
  Please be mindful of this, particularly if you maintain a library or key
  package.


which is not respected by r-base-core:

$ LC_ALL=C apt-cache policy r-base-core
r-base-core:
  Installed: 3.1.1-1
  Candidate: 3.1.1-1+b2
  Version table:
 3.1.2-2 0
 50 http://http.debian.net/debian/ unstable/main amd64 Packages
 3.1.1-1+b2 0
501 http://http.debian.net/debian/ testing/main amd64 Packages
 *** 3.1.1-1 0
100 /var/lib/dpkg/status


I was close to trap into the pitfall to uploaded an RC bug fix built in
an unstable chroot which would not be able to migrate to testing since
the R cdbs helper injects a

  Depends: r-base-core (>= )


So I used a testing chroot but I would like to issue a warning to those
who might need to fix RC bugs in R packages as well.  I remember we had
similar migration trouble in Wheezy freeze time.  Dirk, it would have
been better to upload version 3.1.2 to experimental.

Kind regards

  Andreas.

[1] https://lists.debian.org/debian-devel-announce/2014/11/msg3.html

-- 
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: https://lists.debian.org/2014153337.ga3...@an3as.eu

Re: r-base-core upload to unstable does not respect freeze policy

[Ian Jackson]

Andreas Tille writes ("r-base-core upload to unstable does not respect freeze 
policy"):
> [stuff]

I don't want to take away from what you've said, but:

> So I used a testing chroot

perhaps we should in general make more use of testing chroots for RC
bugfixes to testing during the freeze.  This is particularly relevant
if one is NMUing, and therefore might have less knowledge of the
dependency implications etc.

Ian.


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/21602.12651.670584.160...@chiark.greenend.org.uk

Re: r-base-core upload to unstable does not respect freeze policy

[Andreas Tille]

On Tue, Nov 11, 2014 at 03:55:23PM +, Ian Jackson wrote:
> > So I used a testing chroot
> 
> perhaps we should in general make more use of testing chroots for RC
> bugfixes to testing during the freeze.  This is particularly relevant
> if one is NMUing, and therefore might have less knowledge of the
> dependency implications etc.

ACK.

There was no real harm done in my case.  I just wanted to make other
people aware.  I only noticed since I wanted to install the resulting
package on a testing machine - which I'd recommend even more than to use
a testing chroot for building. 

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: https://lists.debian.org/2014160202.ga4...@an3as.eu

Re: r-base-core upload to unstable does not respect freeze policy

[Luca Falavigna]

Hi Andreas,

2014-11-11 16:33 GMT+01:00 Andreas Tille :
> I was close to trap into the pitfall to uploaded an RC bug fix built in
> an unstable chroot which would not be able to migrate to testing since
> the R cdbs helper injects a
>
>   Depends: r-base-core (>= )
>
> So I used a testing chroot

I think this is not enough, as packages being built by the buildd
network will pick up the R in unstable anyway :/

>From 
>https://buildd.debian.org/status/fetch.php?pkg=r-cran-epi&arch=i386&ver=1.1.67-3&stamp=1415721806
r-cran-epi_1.1.67-3_i386.deb

[...]
 Depends: libc6 (>= 2.4), r-base-core (>= 3.1.2-2)



Cheers,
Luca


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/cadk7b0opwvqeeaw9kmpoz2f8ys5mj0nd6ugqt0w_v7rte5r...@mail.gmail.com

Re: r-base-core upload to unstable does not respect freeze policy

[Simon McVittie]

On 11/11/14 15:55, Ian Jackson wrote:
> perhaps we should in general make more use of testing chroots for RC
> bugfixes to testing during the freeze.

For build-time dependencies, I'm not sure that actually helps very much:
the buildds for unstable take build-dependencies from unstable.

If you intend to ask the release team for permission and then upload to
testing-proposed-updates, then I think those do take build-dependencies
from unstable; but they also get virtually no testing, which is why the
release team are more restrictive about what they'll accept via t-p-u.

S


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/546233e3.7000...@debian.org

Re: r-base-core upload to unstable does not respect freeze policy

[Dirk Eddelbuettel]

On 11 November 2014 at 10:02, Dirk Eddelbuettel wrote:
| 
| There was a bug report requesting builds against tcl/tk 8.5 instead of 8.6.

Bah. Obviously wrong order: 8.6 instead of 8.5.  

D.

| No more, no less -- and I complied.
| 
| This nothing to do with wheezy transition issue.  I would have thought
| you knew better.
| 
| Dirk
| 
| -- 
| http://dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org

-- 
http://dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/21602.13514.201495.508...@max.nulle.part

Re: r-base-core upload to unstable does not respect freeze policy

[Dirk Eddelbuettel]

There was a bug report requesting builds against tcl/tk 8.5 instead of 8.6.
No more, no less -- and I complied.

This nothing to do with wheezy transition issue.  I would have thought
you knew better.

Dirk

-- 
http://dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/21602.13097.266733.759...@max.nulle.part

Re: r-base-core upload to unstable does not respect freeze policy

[Ian Jackson]

Simon McVittie writes ("Re: r-base-core upload to unstable does not respect 
freeze policy"):
> On 11/11/14 15:55, Ian Jackson wrote:
> > perhaps we should in general make more use of testing chroots for RC
> > bugfixes to testing during the freeze.
> 
> For build-time dependencies, I'm not sure that actually helps very much:
> the buildds for unstable take build-dependencies from unstable.

This is a good point.  (Although if your package has only arch:all
debs you can build them all yourself against testing.)

Perhaps the buildds should be reconfigured, during the freeze, to
build against testing ?

Ian.


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/21602.14030.572571.128...@chiark.greenend.org.uk

Re: r-base-core upload to unstable does not respect freeze policy

[Ian Jackson]

Dirk Eddelbuettel writes ("Re: r-base-core upload to unstable does not respect 
freeze policy"):
> 
> There was a bug report requesting builds against tcl/tk 8.5 instead of 8.6.
> No more, no less -- and I complied.
> 
> This nothing to do with wheezy transition issue.  I would have thought
> you knew better.

Did you see Andreas's comment about cdbs-generated dependencies ?
Is that just a bug in cdbs ?

Ian.


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/21602.14104.380204.489...@chiark.greenend.org.uk

Re: r-base-core upload to unstable does not respect freeze policy

[Adam D. Barratt]

On 2014-11-11 16:02, Dirk Eddelbuettel wrote:
There was a bug report requesting builds against tcl/tk 8.5 instead of 
8.6.

No more, no less -- and I complied.

This nothing to do with wheezy transition issue.  I would have thought
you knew better.


It's *everything* to do with transitions to testing.

r-base 3.1.2-2 does not meet the requirements for a freeze exception and 
as such will not be in jessie. Due to the way your automatic depenency 
generation works, any package building against that version of r-base 
will also not be eligible for transition.


Regards,

Adam


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/35ea6cdb01be500bfd3c1a55aac4d...@mail.adsl.funky-badger.org

Re: r-base-core upload to unstable does not respect freeze policy

[Adam D. Barratt]

On 2014-11-11 16:24, Adam D. Barratt wrote:

On 2014-11-11 16:02, Dirk Eddelbuettel wrote:
There was a bug report requesting builds against tcl/tk 8.5 instead of 
8.6.

No more, no less -- and I complied.

This nothing to do with wheezy transition issue.  I would have thought
you knew better.


It's *everything* to do with transitions to testing.

r-base 3.1.2-2 does not meet the requirements for a freeze exception
and as such will not be in jessie. Due to the way your automatic
depenency generation works, any package building against that version
of r-base will also not be eligible for transition.


I missed that the dependency generation is for CDBS-using packages. I'm 
not sure what proportion of R packages that is.


Regards,

Adam


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/d5f43cc31b2a510e0f8bb0239f4c2...@mail.adsl.funky-badger.org

Re: r-base-core upload to unstable does not respect freeze policy

[Jonas Smedegaard]

Quoting Ian Jackson (2014-11-11 17:19:36)
> Dirk Eddelbuettel writes ("Re: r-base-core upload to unstable does not 
> respect freeze policy"):
>> 
>> There was a bug report requesting builds against tcl/tk 8.5 instead of 8.6.
>> No more, no less -- and I complied.
>> 
>> This nothing to do with wheezy transition issue.  I would have thought
>> you knew better.
>
> Did you see Andreas's comment about cdbs-generated dependencies ?
> Is that just a bug in cdbs ?

A bug in some CDBS-compatible snippet, I suspect - not CDBS itself.

 - Jonas

-- 
 * Jonas Smedegaard - idealist & Internet-arkitekt
 * Tlf.: +45 40843136  Website: http://dr.jones.dk/

 [x] quote me freely  [ ] ask before reusing  [ ] keep private


signature.asc
Description: signature

Re: Should fast-evolving packages be backports-only?

[Cyril Brulebois]

Rebecca N. Palmer  (2014-11-11):
> It has been recently stated [0-1] that backports is enabled by
> default in Jessie.

Yes, and that's a bug. See #764982.

> 1. Does that mean that if pkgX is in jessie-backports but not
> jessie, "apt-get install pkgX" will install it from -backports?

Yes. And that's the reason why I'm going to disable jessie-backports
by default when I process my todo list.

Mraw,
KiBi.


signature.asc
Description: Digital signature

Re: r-base-core upload to unstable does not respect freeze policy

[James McCoy]

On Nov 11, 2014 10:34 AM, "Andreas Tille"  wrote:
> I was close to trap into the pitfall to uploaded an RC bug fix built in
> an unstable chroot which would not be able to migrate to testing since
> the R cdbs helper injects a
>
>   Depends: r-base-core (>= )

This looks like more fallout from #704805 not being fixed.  A similar
discussion happened last freeze in the thread starting at <
https://lists.debian.org/20824.26651.775823.264...@max.nulle.part>.

Re: Should fast-evolving packages be backports-only?

[Henrique de Moraes Holschuh]

On Tue, 11 Nov 2014, Rebecca N. Palmer wrote:
> Possible candidates:
> a. Packages that work closely with hardware, where old versions
> don't work with new hardware (example: beignet)
> b. Packages that implement fast-evolving file formats or network
> protocols, where you need the same version as the people you are
> communicating with (possible example: jscommunicator [2])
> c. Packages that are generally rapidly improving, and are typically
> used where this improvement is more important than stability

We used to have the volatile archive for software that absolutely needs to
be updated very often (like virus scanners).  We now have the
"stable-updates" archive for this.

https://wiki.debian.org/StableUpdates

If packages are taking too long to go from stable-proposed-updates to
stable-updates, that's something we could talk to the release managers
about.

Although, I am *sure* lack of widespread use (and therefore testing) of
stable-proposed-updates by users and developers (HINT HINT HINT HINT) is one
of the reasons.

However, candidate packages due to reason (c) above really are a problem,
IMHO they shouldn't be in stable in the first place.  backports seem like a
better solution for this case.  However, we'd need to add further
requirements:  packages not built from the same source package cannot depend
on such "never-for-stable" packages, and we must tag them somehow so that
they never get released to stable...

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


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

Re: r-base-core upload to unstable does not respect freeze policy

[Andreas Tille]

On Tue, Nov 11, 2014 at 04:28:25PM +, Adam D. Barratt wrote:
> >It's *everything* to do with transitions to testing.
> >
> >r-base 3.1.2-2 does not meet the requirements for a freeze exception
> >and as such will not be in jessie. Due to the way your automatic
> >depenency generation works, any package building against that version
> >of r-base will also not be eligible for transition.
> 
> I missed that the dependency generation is for CDBS-using packages.
> I'm not sure what proportion of R packages that is.

All R packages are building with

include /usr/share/R/debian/r-cran.mk

which contains:

rversion:= $(shell dpkg-query -W -f='$${Version}' r-base-dev)
...
## support ${R:Depends} via debian/${package}.substvars
echo "R:Depends=r-base-core (>= ${rversion})" >> 
debian/$(package).substvars


which is IMHO to strict which was discussed previously (for instance
here [1]).  The package does only require a certain API and not
necessarily the latest available r-base-core.  While the strict
dependency does not harm in general it potentially does in situations
like this specific one.  (However, even the relaxed dependency in [1]
would have not helped in the current case.)

Kind regards

Andreas.

[1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=704805#15

-- 
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: https://lists.debian.org/2014173027.gb4...@an3as.eu

Re: Should fast-evolving packages be backports-only?

[Scott Kitterman]

On November 11, 2014 12:22:57 PM EST, Cyril Brulebois  wrote:
>Rebecca N. Palmer  (2014-11-11):
>> It has been recently stated [0-1] that backports is enabled by
>> default in Jessie.
>
>Yes, and that's a bug. See #764982.
>
>> 1. Does that mean that if pkgX is in jessie-backports but not
>> jessie, "apt-get install pkgX" will install it from -backports?
>
>Yes. And that's the reason why I'm going to disable jessie-backports
>by default when I process my todo list.

As long as apt prefers a version from stable over a version from backports when 
both are available (unless instructed to install from backports) why is this a 
problem? 

It seems more user friendly to me for a package that's been specifically ask 
for to end up installed rather than not. 

Scott K


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/e8f87680-99dc-4fa5-8fc2-754d48d57...@kitterman.com

Re: r-base-core upload to unstable does not respect freeze policy

[Andreas Tille]

Hi Jonas,

On Tue, Nov 11, 2014 at 06:11:42PM +0100, Jonas Smedegaard wrote:
> Quoting Ian Jackson (2014-11-11 17:19:36)
> >
> > Did you see Andreas's comment about cdbs-generated dependencies ?
> > Is that just a bug in cdbs ?
> 
> A bug in some CDBS-compatible snippet, I suspect - not CDBS itself.

ACK.

As I wrote in my other mail it is not particularly a bug.  The resulting
dependency is IMHO a bit to strict but was choosen that way by the
maintainer.  Everything would work as expected if new upstream version
of r-base-core would have been uploaded to experimental rather than to
unstable.

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: https://lists.debian.org/2014173917.gd4...@an3as.eu

Re: release browser-related packages to stable?

[Rebecca N. Palmer]

Has there already been any further discussion about the solution for Xul
extensions packaged in Debian?
I haven't looked for the official discussion, but extensions have been 
updated in stable (to a new upstream version if necessary) when a 
browser update would otherwise break them: see e.g. #744730.


Also, clients for interacting with a single online service (eg. ttyter, 
#721921) have been updated in stable when that service changes its API.


Those cases have in common that there is a clearly-defined "right" 
version: a browser and its extensions are on the same machine so can be 
tied together by the normal dependency system, and a one-service client 
needs to match its only server.  This isn't the case for a server 
intended for public (i.e. with non-Debian clients) use.



--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/5462466c.1030...@zoho.com

Re: r-base-core upload to unstable does not respect freeze policy

[Henrique de Moraes Holschuh]

On Tue, 11 Nov 2014, Ian Jackson wrote:
> Simon McVittie writes ("Re: r-base-core upload to unstable does not respect 
> freeze policy"):
> > On 11/11/14 15:55, Ian Jackson wrote:
> > > perhaps we should in general make more use of testing chroots for RC
> > > bugfixes to testing during the freeze.
> > 
> > For build-time dependencies, I'm not sure that actually helps very much:
> > the buildds for unstable take build-dependencies from unstable.
> 
> This is a good point.  (Although if your package has only arch:all
> debs you can build them all yourself against testing.)
> 
> Perhaps the buildds should be reconfigured, during the freeze, to
> build against testing ?

That has some nasty implications as well.  If this needs to be addressed,
the likely safest answer would be to have t-p-u built on buildds with
up-to-date[1] testing chroots.

[1] If you even have to ask why something like this needs to be explicitly
stated, well, you're a lucky one...

AFAIK, the whole policy of not updating to unstable something that is not
supposed to migrate to testing during a freeze is a way to cope with the
extremely non-trivial cost of deploying and managing a fully independent
t-p-u (which is more than an entire new set of autobuilder instances).

This reminds me that, AFAIK, we still don't have a good answer to this
scenario: "what do I do when I notice the toolchain was generating broken
code", which actually means "we should binNMU everything that was built with
the broken toolchain, as well as anything that lifted code from the broken
binaries (static linking, etc)".

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


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

Re: Should fast-evolving packages be backports-only?

[Cyril Brulebois]

Scott Kitterman  (2014-11-11):
> As long as apt prefers a version from stable over a version from
> backports when both are available (unless instructed to install from
> backports) why is this a problem? 
> 
> It seems more user friendly to me for a package that's been
> specifically ask for to end up installed rather than not. 

As I probably wrote in the mentioned bug report, it seems more friendly,
safe, and honest to stick to stable packages on a stable system instead
of silently stuff from backports.

It's not like uncommenting a line in sources.list should be a huge
burden anyway (having to figure out which line to add, depending on the
target suite, wasn't too trivial when backports moved from backports.d.o
to the archive; but we're way past that now).

Mraw,
KiBi.


signature.asc
Description: Digital signature

Re: Should fast-evolving packages be backports-only?

[Daniel Pocock]

On 11/11/14 18:30, Henrique de Moraes Holschuh wrote:
> On Tue, 11 Nov 2014, Rebecca N. Palmer wrote:
>> Possible candidates:
>> a. Packages that work closely with hardware, where old versions
>> don't work with new hardware (example: beignet)
>> b. Packages that implement fast-evolving file formats or network
>> protocols, where you need the same version as the people you are
>> communicating with (possible example: jscommunicator [2])
>> c. Packages that are generally rapidly improving, and are typically
>> used where this improvement is more important than stability
> 
> We used to have the volatile archive for software that absolutely needs to
> be updated very often (like virus scanners).  We now have the
> "stable-updates" archive for this.
> 
> https://wiki.debian.org/StableUpdates
> 
> If packages are taking too long to go from stable-proposed-updates to
> stable-updates, that's something we could talk to the release managers
> about.
> 
> Although, I am *sure* lack of widespread use (and therefore testing) of
> stable-proposed-updates by users and developers (HINT HINT HINT HINT) is one
> of the reasons.
> 
> However, candidate packages due to reason (c) above really are a problem,
> IMHO they shouldn't be in stable in the first place.  backports seem like a
> better solution for this case.  However, we'd need to add further
> requirements:  packages not built from the same source package cannot depend
> on such "never-for-stable" packages, and we must tag them somehow so that
> they never get released to stable...
> 

That is not so easy though or it may have side effects

For example, if a library changes implementation details but the public
API and ABI does not change and no other dependent packages need to be
recompiled then it should be OK for those dependent packages to live in
stable.

Does that mean the maintainer has to put their libfoo-dev in stable
while keeping their volatile libfoo1 in backports?


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/54624ca0.80...@pocock.pro

Re: r-base-core upload to unstable does not respect freeze policy

[Andreas Tille]

Hi Luca,

On Tue, Nov 11, 2014 at 05:04:55PM +0100, Luca Falavigna wrote:
> Hi Andreas,
> 
> 2014-11-11 16:33 GMT+01:00 Andreas Tille :
> > I was close to trap into the pitfall to uploaded an RC bug fix built in
> > an unstable chroot which would not be able to migrate to testing since
> > the R cdbs helper injects a
> >
> >   Depends: r-base-core (>= )
> >
> > So I used a testing chroot
> 
> I think this is not enough, as packages being built by the buildd
> network will pick up the R in unstable anyway :/
> 
> >From 
> >https://buildd.debian.org/status/fetch.php?pkg=r-cran-epi&arch=i386&ver=1.1.67-3&stamp=1415721806
> r-cran-epi_1.1.67-3_i386.deb
> 
> [...]
>  Depends: libc6 (>= 2.4), r-base-core (>= 3.1.2-2)

Hmmm, this is what I missed. :-(  I guess the only chance is to upload
to t-p-u, right? 

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: https://lists.debian.org/2014181210.ge4...@an3as.eu

Re: Should fast-evolving packages be backports-only?

[Henrique de Moraes Holschuh]

On Tue, 11 Nov 2014, Daniel Pocock wrote:
> On 11/11/14 18:30, Henrique de Moraes Holschuh wrote:
> > On Tue, 11 Nov 2014, Rebecca N. Palmer wrote:
> >> Possible candidates:
> >> a. Packages that work closely with hardware, where old versions
> >> don't work with new hardware (example: beignet)
> >> b. Packages that implement fast-evolving file formats or network
> >> protocols, where you need the same version as the people you are
> >> communicating with (possible example: jscommunicator [2])
> >> c. Packages that are generally rapidly improving, and are typically
> >> used where this improvement is more important than stability
> > 
> > We used to have the volatile archive for software that absolutely needs to
> > be updated very often (like virus scanners).  We now have the
> > "stable-updates" archive for this.
> > 
> > https://wiki.debian.org/StableUpdates
> > 
> > If packages are taking too long to go from stable-proposed-updates to
> > stable-updates, that's something we could talk to the release managers
> > about.
> > 
> > Although, I am *sure* lack of widespread use (and therefore testing) of
> > stable-proposed-updates by users and developers (HINT HINT HINT HINT) is one
> > of the reasons.
> > 
> > However, candidate packages due to reason (c) above really are a problem,
> > IMHO they shouldn't be in stable in the first place.  backports seem like a
> > better solution for this case.  However, we'd need to add further
> > requirements:  packages not built from the same source package cannot depend
> > on such "never-for-stable" packages, and we must tag them somehow so that
> > they never get released to stable...
> > 
> 
> That is not so easy though or it may have side effects
> 
> For example, if a library changes implementation details but the public
> API and ABI does not change and no other dependent packages need to be
> recompiled then it should be OK for those dependent packages to live in
> stable.
> 
> Does that mean the maintainer has to put their libfoo-dev in stable
> while keeping their volatile libfoo1 in backports?

Looks like a "let's not go there" kind of deal.  Make it simple, so that it
has a non-zero chance of flying and all that.  After we have some experience
with it in practice, we revisit the issue.

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


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

Re: Should fast-evolving packages be backports-only?

[Vincent Bernat]

 ❦ 11 novembre 2014 12:29 -0500, Scott Kitterman  :

> As long as apt prefers a version from stable over a version from
> backports when both are available (unless instructed to install from
> backports) why is this a problem?

The user may expect the same characteristics than for packages in
stable, like stability (not upgrading to a new upstream version each
month).
-- 
Let the data structure the program.
- The Elements of Programming Style (Kernighan & Plauger)


signature.asc
Description: PGP signature

Re: Re: Let's abandon debian-devel.

[Joe Neal]

> On 2014-11-11 12:25, Ben Finney wrote:
> > But all Debian Contributors have their OpenPGP key in the
> > project's keyring. No?
> 
> Most certainly not.
> Parts where many people who is not DD nor DM takes part include docs,
> web, translations and graphics.

FWIW, when I first started running sid nearly ten years ago, it was
recommended that users doing so subscribe to debian-devel so as to be
aware of any breakages, etc.  While there is no reason why I should now
be able to post here without at least passing through a moderation
queue, it would probably be a good idea to make sure there are no places
left on the web instructing users to subscribe if they are going to be
discouraged from posting.




-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/1415731000.5108.1.ca...@speakeasy.net

Re: r-base-core upload to unstable does not respect freeze policy

[Luca Falavigna]

Hi Andreas,

2014-11-11 19:12 GMT+01:00 Andreas Tille :
>>  Depends: libc6 (>= 2.4), r-base-core (>= 3.1.2-2)
>
> Hmmm, this is what I missed. :-(  I guess the only chance is to upload
> to t-p-u, right?

That could be an option. You have to coordinate with Release Team,
though, as I can't speak for it.

Obviously, fixes to any R package should go through t-p-u, which could
be a pain to handle. I wonder whether the version in unstable can be
reverted to 3.1.1...

Cheers,
Luca


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/CADk7b0NKQS_VmtXreSY+e4etB6KwMc2e=Dw1FJ_=77uumpg...@mail.gmail.com

Re: Removing duplication: Word lists of common words in languages

[Ben Finney]

Ian Jackson  writes:

> I had roughly this question in 2013, and found the answer.  Here is
> probably the best starting point:
>
> http://www.chiark.greenend.org.uk/ucgi/~ijackson/git?p=evade-mail-usrlocal.git;a=blob;f=lemma.al-permission.mbox

Great! That asks for permission to redistribute the corpus under
free-software terms, and documents the response in the affirmative.
Vital for an eventual ‘debian/copyright’. Thank you.

In that exchange, you also mention you're planning to distribute the
data in a program. Is that online somewhere, and what's the URL?

-- 
 \  “Our products just aren't engineered for security.” —Brian |
  `\ Valentine, senior vice-president of Microsoft Windows |
_o__)development, 2002 |
Ben Finney


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/857fz1cxzo@benfinney.id.au

Bug#769159: ITP: citeproc-py -- Python implementation of a CSL (Citation Style Language) citation processor

[Daniel Stender]

Package: wnpp
Severity: wishlist
Owner: Daniel Stender 

* Package name: citeproc-py
  Version : 0.3.0
  Upstream Author : Brecht Machiels 
* URL : https://github.com/brechtm/citeproc-py
* License : BSD-2-Clause
  Programming Lang: Python
  Description : Python implementation of a CSL (Citation Style Language) 
citation processor

This is a Python citation processor [1] for the XML based Citation
Style Language (CSL) [2], which puts out formatted citations and bibliographies
from different bibliographical database formats, so far it supports
Json and BibTeX, according to citation styles written in CSL [3].

The latest upstream tarball appeared a couple of days ago, and there is active
development going on. The development status of citeproc-py is still "3-Alpha",
but it would like to package it already because this is very promising.

The binaries of Python modules would be python-citeproc and python3-citeproc.

Daniel Stender

[1] http://en.wikipedia.org/wiki/CiteProc
[2] http://citationstyles.org/


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/2014201234.8915.3665.report...@varuna.fritz.box

Bug#769162: ITP: aegean -- integrated genome analysis toolkit

[Sascha Steinbiss]

Package: wnpp
Severity: wishlist
Owner: Sascha Steinbiss 

* Package name: aegean
  Version : 0.10.2 
  Upstream Author : Daniel Standage 
* URL : http://standage.github.io/AEGeAn/
* License : ISC
  Programming Lang: C
  Description : integrated genome analysis toolkit

The AEGeAn Toolkit is designed for the Analysis and Evaluation of Genome 
Annotations. The toolkit includes a variety of analysis programs, e.g. for
comparing distinct sets of gene structure annotations (ParsEval), computation
of gene loci (LocusPocus) and more. In particular, the ParsEval software tool 
is very fast and convenient and highly useful for bioinformaticians working 
on the task of genome annotation, allowing for easy evaluation of results
e.g. compared against a reference. The ParsEval publication was quickly marked 
as being highly accessed (http://www.biomedcentral.com/1471-2105/13/187),
confirming its usefulness for the bioinformatics community.


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/2014195125.7264.38007.reportbug@renard

Re: r-base-core upload to unstable does not respect freeze policy

[Henrique de Moraes Holschuh]

On Tue, 11 Nov 2014, Luca Falavigna wrote:
> 2014-11-11 19:12 GMT+01:00 Andreas Tille :
> >>  Depends: libc6 (>= 2.4), r-base-core (>= 3.1.2-2)
> >
> > Hmmm, this is what I missed. :-(  I guess the only chance is to upload
> > to t-p-u, right?
> 
> That could be an option. You have to coordinate with Release Team,
> though, as I can't speak for it.
> 
> Obviously, fixes to any R package should go through t-p-u, which could
> be a pain to handle. I wonder whether the version in unstable can be
> reverted to 3.1.1...

No, you cannot revert anything once installed, but you can supersede it.

If this issue can be fixed through build-depends/conflicts, a new upload to
unstable with those changes would be a way to address the issue.

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


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

RFC: DEP-14: Recommended layout for Git packaging repositories

[Raphael Hertzog]

Hello,

following the initial discussion we had in August
(https://lists.debian.org/debian-devel/2014/08/thrd2.html#00499), I have
written a first draft of the Debian Enhancement Proposal that I suggested.
It's now online at http://dep.debian.net/deps/dep14 and also attached
below so that you can easily reply and comment.

I have left one question where I have had conflicting feedback
and I'm not sure what's best. Thus I will welcome a larger set of
opinions on this specific question (search for "QUESTION" in the
text).

Are there things that are missing?

Here's the draft:


Title: Recommended layout for Git packaging repositories
DEP: 14
State: DRAFT
Date: 2014-11-04
Drivers: Raphael Hertzog 
URL: http://dep.debian.net/deps/dep14
Source: http://anonscm.debian.org/viewvc/dep/web/deps/dep14.mdwn
Abstract:
 Recommended naming conventions in Git repositories used
 to maintain Debian packages


Introduction


This is a proposal to harmonize the layout of Git repositories
used to maintain Debian packages. The goals are multiple:

 * making it easier for Debian and its derivatives to build upon
   their respective Git repositories (with the possibility
   to share a common one in some cases)

 * make it easier to switch between various git packaging helper
   tools. Even if all the tools don't implement the same worflow, they
   could at least use the same naming conventions for the same things
   (Debian/upstream release tags, default packaging branch, etc.).

Scope
=

This proposal defines naming conventions for various Git branches
and Git tags that can be useful when doing Debian packaging work.
The hope is that maintainers of git packaging helper tools will adopt
those naming conventions (in the default configuration of their tools).

Generic principles
==

Vendor namespaces
-

Each "vendor" uses its own namespace for its packaging related 
Git branches and tags: `debian/*` for Debian, `ubuntu/*` for Ubuntu, and
so on.

Helper tools should usually rely on the output of `dpkg-vendor --query vendor`
to find out the name of the current vendor. The retrieved string must be
converted to lower case. This allows users to override the current vendor
by setting `DEB_VENDOR` in their environment (provided that the vendor
information does exist in `/etc/dpkg/origins/`).

If `dpkg-vendor` is not available, then they should assume "debian" is the
current vendor. Helper tools can also offer a command-line option to
override the current vendor if they desire.

Version mangling


When a Git tag needs to refer to a specific version of a Debian package,
the Debian version needs to be mangled to cope with Git's restrictions.
The colon (`:`) needs to be replaced with a percent (`%`), and the tilde
(`~`) needs to be replaced with an underscore (`_`).

Packaging branches and tags
===

Packaging branches should be named according to the codename of the
target distribution. In the case of Debian, that means for example
`debian/sid`, `debian/jessie`, `debian/experimental`,
`debian/wheezy`, `debian/wheezy-backports`, etc. We specifically avoid
"suite" names because those tend to evolve over time ("stable" becomes
"oldstable" and so on).

The Git repository listed in debian/control's `Vcs-Git` field should
usually have its HEAD point to the branch corresponding to the
distribution where new upstream versions are usually sent. For Debian,
it will usually be `debian/sid` (or sometimes `debian/experimental`).

  QUESTION: some people have argued to use debian/master as the latest
  packaging targets sometimes sid and sometimes experimental. Should we
  standardize on this? Or should we explicitly allow this as an alternative?

The helper tools that do create those repositories should use a command
like `git symbolic-ref HEAD refs/heads/debian/sid` to update HEAD
to point to the desired branch.

When releasing a Debian package, the packager should create and push
a signed tag named `/`. For example, a Debian maintainer
releasing a package with version 2:1.2~rc1-1 would create a tag named
`debian/2%1.2_rc1-1` whereas an Ubuntu packager releasing a package with
version 1.3-0ubuntu1 would use `ubuntu/1.3-0ubuntu1`. The tags should
point to the exact commit that was used to build the corresponding upload.

Managing upstream sources
=

Importing upstream release tarballs in Git
--

If the Git workflow in use imports the upstream sources from released
tarballs, this should be done under the "upstream" namespace. By default,
the latest upstream version should be imported in the `upstream/latest`
branch and when packages for multiple upstream versions are maintained
concurrently, one should create as many upstream branches as required.

Their name should be based on the major upstream version tracked:
for example when upstream maintains a stable 1.2 branch

Bug#769173: RFA: libmusicbrainz5 -- Library to access the MusicBrainz.org database

[Daniel Pocock]

Package: wnpp
X-Debbugs-CC: debian-devel@lists.debian.org,
pkg-multimedia-maintain...@lists.alioth.debian.org, a...@gently.org.uk,
tjaal...@ubuntu.com

https://tracker.debian.org/pkg/libmusicbrainz5

libmusicbrainz5 is pulled into many GNOME desktops as a dependency,
hence the high popcon stats:
https://qa.debian.org/popcon.php?package=libmusicbrainz5

There is currently an RC bug, a couple of non-free files crept in at
some point, upstream has removed them but had to make API changes.
Somebody adopting the package may need to consider a transition.

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=749698

This package relies on a web service API from MusicBrainz and somebody
familiar with that may be able to support the package more easily.

I think this is a very worthwhile package, it is part of the eco-system
of open source alternatives to cloud-based music services.  I originally
helped with this package to support the packaging of flactag.  However,
I have a large portfolio of other packages where I have more in-depth
experience and ongoing development work hence I'm putting this one
up for adoption in the hope that somebody will focus on it.


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/5462804c.5090...@pocock.pro

Re: r-base-core upload to unstable does not respect freeze policy

[Santiago Vila]

On Tue, 11 Nov 2014, Andreas Tille wrote:

> All R packages are building with
> 
> include /usr/share/R/debian/r-cran.mk
> 
> which contains:
> 
> rversion:= $(shell dpkg-query -W -f='$${Version}' r-base-dev)
> ...
> ## support ${R:Depends} via debian/${package}.substvars
> echo "R:Depends=r-base-core (>= ${rversion})" >> 
> debian/$(package).substvars

So, would this patch to the current r-base package improve things if
applied to the version in unstable?

diff --git a/debian/r-cran.mk b/debian/r-cran.mk
index e366f6b..0550173 100644
--- a/debian/r-cran.mk
+++ b/debian/r-cran.mk
@@ -60,7 +60,7 @@ endif
 #rversion  := $(shell zcat /usr/share/doc/r-base-dev/changelog.Debian.gz | 
\
 #  dpkg-parsechangelog -l- --count 1  | \
 #  awk '/^Version/ {print $$2}')
-rversion   := $(shell dpkg-query -W -f='$${Version}' r-base-dev)
+rversion   := $(shell dpkg-query -W -f='$${Version}' r-base-dev | perl -ne 
'print /([0-9]\.[0-9])/')
 
 ## we use these results for the to-be-installed-in directory
 debRlib:= $(CURDIR)/debian/$(package)/$(debRdir)


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/alpine.deb.2.11.142217280.11...@cantor.unex.es

Re: RFC: DEP-14: Recommended layout for Git packaging repositories

[Iustin Pop]

On Tue, Nov 11, 2014 at 10:26:24PM +0100, Raphael Hertzog wrote:
> Hello,
> 
> following the initial discussion we had in August
> (https://lists.debian.org/debian-devel/2014/08/thrd2.html#00499), I have
> written a first draft of the Debian Enhancement Proposal that I suggested.
> It's now online at http://dep.debian.net/deps/dep14 and also attached
> below so that you can easily reply and comment.
> 
> I have left one question where I have had conflicting feedback
> and I'm not sure what's best. Thus I will welcome a larger set of
> opinions on this specific question (search for "QUESTION" in the
> text).

[…]

> Packaging branches and tags
> ===
> 
> Packaging branches should be named according to the codename of the
> target distribution. In the case of Debian, that means for example
> `debian/sid`, `debian/jessie`, `debian/experimental`,
> `debian/wheezy`, `debian/wheezy-backports`, etc. We specifically avoid
> "suite" names because those tend to evolve over time ("stable" becomes
> "oldstable" and so on).
> 
> The Git repository listed in debian/control's `Vcs-Git` field should
> usually have its HEAD point to the branch corresponding to the
> distribution where new upstream versions are usually sent. For Debian,
> it will usually be `debian/sid` (or sometimes `debian/experimental`).

I find this paragraph confusing. With gbp, this is where new Debian
developments are made, and new upstream versions are sent to
upstream/xxx. Or do you mean something else here?

>   QUESTION: some people have argued to use debian/master as the latest
>   packaging targets sometimes sid and sometimes experimental. Should we
>   standardize on this? Or should we explicitly allow this as an alternative?

Interesting. Assuming a normal Debian package that has just a few
backports (as opposed to every sid release being backported), and which
imports only upstream tarballs/snapshots (not the whole history), I
expect that a high proportion of the commits would happen on this
branch. In which case, why not make it 'master', without debian/ ? Is it
(only) in order to cleanly support multiple vendors?

thanks,
iustin


signature.asc
Description: Digital signature

Re: RFC: DEP-14: Recommended layout for Git packaging repositories

[Henrique de Moraes Holschuh]

On Tue, 11 Nov 2014, Raphael Hertzog wrote:
> following the initial discussion we had in August
> (https://lists.debian.org/debian-devel/2014/08/thrd2.html#00499), I have
> written a first draft of the Debian Enhancement Proposal that I suggested.
> It's now online at http://dep.debian.net/deps/dep14 and also attached
> below so that you can easily reply and comment.
> 
> I have left one question where I have had conflicting feedback
> and I'm not sure what's best. Thus I will welcome a larger set of
> opinions on this specific question (search for "QUESTION" in the
> text).

...

> The Git repository listed in debian/control's `Vcs-Git` field should
> usually have its HEAD point to the branch corresponding to the
> distribution where new upstream versions are usually sent. For Debian,
> it will usually be `debian/sid` (or sometimes `debian/experimental`).
> 
>   QUESTION: some people have argued to use debian/master as the latest
>   packaging targets sometimes sid and sometimes experimental. Should we
>   standardize on this? Or should we explicitly allow this as an alternative?

Please allow debian/master as an alternative.  It fits with the general git
usage of "master", it fits with the workflow of several packages, where you
do experimental->unstable, and it is not going to surprise anyone that has
even a passing knowledge of the usual git conventions.

In fact, I was quite non-amused by the initial versions of this idea, but
reading this latest version, I must say I *like* it.  Well done!  I am
especially happy about the way it respects the usual git usage conventions,
this will ease its adoption a lot.

It does fail to mention security, and stable-proposed branches.  We can just
leave those to maintainer's discretion, of course.

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


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

Re: RFC: DEP-14: Recommended layout for Git packaging repositories

[Henrique de Moraes Holschuh]

On Tue, 11 Nov 2014, Iustin Pop wrote:
> >   QUESTION: some people have argued to use debian/master as the latest
> >   packaging targets sometimes sid and sometimes experimental. Should we
> >   standardize on this? Or should we explicitly allow this as an alternative?
> 
> Interesting. Assuming a normal Debian package that has just a few
> backports (as opposed to every sid release being backported), and which
> imports only upstream tarballs/snapshots (not the whole history), I
> expect that a high proportion of the commits would happen on this
> branch. In which case, why not make it 'master', without debian/ ? Is it
> (only) in order to cleanly support multiple vendors?

This way DEP-14 can support upstream work being done in the main namespace
(master branch, unprefixed or "v"-prefixed release tags, etc), while
downstream/distro/vendor work is done on the vendor branches.

Which is the natural way it will happen when you have upstream and
downstream packaging being done by the same person, or by the same team.

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


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

Re: RFC: DEP-14: Recommended layout for Git packaging repositories

[Barry Warsaw]

On Nov 11, 2014, at 10:26 PM, Raphael Hertzog wrote:

>Here's the draft:

Thanks for getting this started.  I think it will help considerably to get
some standardization here.  I would think that as more teams adopt git, they
will eventually just refer to DEP 14, perhaps with some additional team-based
deviations if necessary.

One question: when this gets adopted, will individual maintainers or teams
have to know which of the git packaging helpers a particular repository is
using?  IOW, what happens if I were to use gbp-pq on a package that someone
else had used git-dpm on?  Do we need some kind of convention to detect which
helper is being used?  I wouldn't want to restrict choice by defining a
standard Debian-wide (but it's okay within the context of a team).  I just
want someone who walks up to a git repo to at least easily know which tools to
use.

>Vendor namespaces
>-
>
>Each "vendor" uses its own namespace for its packaging related 
>Git branches and tags: `debian/*` for Debian, `ubuntu/*` for Ubuntu, and
>so on.

My question is whether the vendor namespaces are overkill for the majority of
packages, where there probably will be just one vendor (i.e. Debian).  Should
DEP 14 allow for a simplified layout such as master, pristine-tar, upstream
when there is no other vendor involved?  Allowing for master as an alternative
to debian/sid or debian/master might simplify the common case.

However, I'll also note that for pycurl, I'm currently using master to be the
Debian unstable branch, and ubuntu to be a small set of deltas on top of that,
for the current Ubuntu development series.  If I needed to support older
releases in either distro, then debian/wheezy or ubuntu/utopic would be good
branches to use.  (Or IOW, what's the equivalent of debian/sid for Ubuntu?)

>  QUESTION: some people have argued to use debian/master as the latest
>  packaging targets sometimes sid and sometimes experimental. Should we
>  standardize on this? Or should we explicitly allow this as an alternative?

It makes some sense to allow this as an alternative, but then my question
about using 'master' as an even simpler alternative for the common case should
also be asked.

>When releasing a Debian package, the packager should create and push
>a signed tag named `/`. For example, a Debian maintainer
>releasing a package with version 2:1.2~rc1-1 would create a tag named
>`debian/2%1.2_rc1-1` whereas an Ubuntu packager releasing a package with
>version 1.3-0ubuntu1 would use `ubuntu/1.3-0ubuntu1`. The tags should
>point to the exact commit that was used to build the corresponding upload.

Agreed.  Tag namespaces certainly make a lot of sense.

>If the Git workflow in use imports the upstream sources from released
>tarballs, this should be done under the "upstream" namespace. By default,
>the latest upstream version should be imported in the `upstream/latest`
>branch and when packages for multiple upstream versions are maintained
>concurrently, one should create as many upstream branches as required.

Similarly, is 'upstream' okay for the upstream branch?  It's a little simpler
than upstream/latest, especially if you don't anticipate importing an other
upstream branches.

Again thanks.  After Jessie is released, I hope to restart this discussion
over in Debian Python, for that team's transition to git.

Cheers,
-Barry


signature.asc
Description: PGP signature

Re: RFC: DEP-14: Recommended layout for Git packaging repositories

[Matthias Urlichs]

Hi,

Raphael Hertzog:
> 
> Title: Recommended layout for Git packaging repositories
> DEP: 14

Thank you!

>   QUESTION: some people have argued to use debian/master as the latest
>   packaging targets sometimes sid and sometimes experimental. Should we
>   standardize on this? Or should we explicitly allow this as an alternative?
> 
Personally I'd prefer `debian/master`.

> About pristine-tar
> --
> 
> If the package maintainers use the pristine-tar tool to efficiently store
> a byte-for-byte copy of the upstream tarballs, this should be done in the
> `pristine-tar` branch.
> 
Please discourage the use of pristine-tar. The format is fragile and can
suffer from bit rot.

-- 
-- Matthias Urlichs


signature.asc
Description: Digital signature

Re: RFC: DEP-14: Recommended layout for Git packaging repositories

[Scott Kitterman]

On Tuesday, November 11, 2014 22:26:24 Raphael Hertzog wrote:
> Hello,
> 
> following the initial discussion we had in August
> (https://lists.debian.org/debian-devel/2014/08/thrd2.html#00499), I have
> written a first draft of the Debian Enhancement Proposal that I suggested.
> It's now online at http://dep.debian.net/deps/dep14 and also attached
> below so that you can easily reply and comment.
> 
> I have left one question where I have had conflicting feedback
> and I'm not sure what's best. Thus I will welcome a larger set of
> opinions on this specific question (search for "QUESTION" in the
> text).
> 
> Are there things that are missing?

Who's going to do patches to existing tools (e.g. git-dpm is the one I use and 
care about) so they comply with this and similarly scripts to convert existing 
git repos to match this recommendation?

It doesn't make much sense to have an standard unless there's also a plan to 
implement using it.

Scott K


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

Re: RFC: DEP-14: Recommended layout for Git packaging repositories

[Russ Allbery]

Matthias Urlichs  writes:
> Raphael Hertzog:

>> About pristine-tar
>> --

>> If the package maintainers use the pristine-tar tool to efficiently
>> store a byte-for-byte copy of the upstream tarballs, this should be
>> done in the `pristine-tar` branch.

> Please discourage the use of pristine-tar. The format is fragile and can
> suffer from bit rot.

I strongly disagree with this advice.  pristine-tar is hugely helpful, and
is something we should continue to support, advocate, maintain, and use.

-- 
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: https://lists.debian.org/87egt91d6c@hope.eyrie.org

Bug#769187: general: Entries in system log for failed services refer to FreeDesktop.ORG for support

[Tomas Fasth]

Package: general
Severity: normal

I use Virtualbox to run test environments for the packages I maintain
(just a few really). I install virtualbox-guest-utils in my guest
installations to adjust system clock after hibernation.

In Jessie, there seem to be a problem with the virtualbox guest service.
It fails to start and, as usual, I look in the system log for clues.

Now, as a DD I am of course very much aware of the highly debated
change in Jessie to a new default init process. I have had no strong
feelings about this so far, other than that in general, as a user, I
very much value the freedom of choice. That is why I choose to use free
and open source software when available in the first place.

Any way, back to the failed start of the virtualbox service. I went to
the system log for clues, in this case using 'journalctl -x'. To my
surprise, where ever there was a problem reported, there was also a
reference to systemd-devel mailing list at FreeDesktop.ORG for support.

In my particular case it looked like this:

// log extract begins
nov 10 01:36:47 debian-systemd sudo[1429]: tomfa : TTY=pts/0 ; PWD=/home/tomfa 
; USER=root ; COMMAND=/usr/sbin/service virtualbox-guest-utils start
nov 10 01:36:47 debian-systemd sudo[1429]: pam_unix(sudo:session): session 
opened for user root by tomfa(uid=0)
nov 10 01:36:47 debian-systemd virtualbox-guest-utils[1447]: Starting 
VirtualBox AdditionsNo suitable module for running kernel found ... failed!
nov 10 01:36:47 debian-systemd virtualbox-guest-utils[1447]: failed!
nov 10 01:36:47 debian-systemd sudo[1429]: pam_unix(sudo:session): session 
closed for user root
nov 10 01:36:47 debian-systemd systemd[1]: virtualbox-guest-utils.service: 
control process exited, code=exited status=1
nov 10 01:36:47 debian-systemd systemd[1]: Failed to start LSB: VirtualBox 
Linux Additions.
-- Subject: Unit virtualbox-guest-utils.service has failed
-- Defined-By: systemd
-- Support: http://lists.freedesktop.org/mailman/listinfo/systemd-devel
-- 
-- Unit virtualbox-guest-utils.service has failed.
-- 
-- The result is failed.
nov 10 01:36:47 debian-systemd systemd[1]: Unit virtualbox-guest-utils.service 
entered failed state.
// log extract ends

I don't understand why there should be a reference to an external support
entity when the issue obviously is Debian related and should be reported
as such in Debian-related forums. My specific issue has nothing to do
with systemd or FreeDesktop.ORG. I want the external reference removed.
If it stays it will only create confusion and misunderstanding.

Thank you,

Tomas Fasth

-- System Information:
Debian Release: jessie/sid
  APT prefers testing-updates
  APT policy: (500, 'testing-updates'), (500, 'testing')
Architecture: amd64 (x86_64)

Kernel: Linux 3.16-3-amd64 (SMP w/1 CPU core)
Locale: LANG=sv_SE.UTF-8, LC_CTYPE=sv_SE.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/20141110011332.1314.27239.report...@debian-systemd.malforsdata.se

Re: RFC: DEP-14: Recommended layout for Git packaging repositories

[Norbert Preining]

On Tue, 11 Nov 2014, Russ Allbery wrote:
> > Please discourage the use of pristine-tar. The format is fragile and can
> > suffer from bit rot.
> 
> I strongly disagree with this advice.  pristine-tar is hugely helpful, and
> is something we should continue to support, advocate, maintain, and use.

Unfortunately it is so broken, that too often orig tarballs cannot
be recreated. Especially with pristinetar data generated in a stable
system one is often lost.

I used pristinetar for years, and now try to move away from it,
as it turned out to be too unstable, and too dependent on tar's
internalities.

But I agree, that the *idea* of pristinetar is great, only that it
does not work as it is now.

Norbert


PREINING, Norbert   http://www.preining.info
JAIST, Japan TeX Live & Debian Developer
GPG: 0x860CDC13   fp: F7D8 A928 26E3 16A1 9FA0  ACF0 6CAC A448 860C DC13



-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20141112003120.gd19...@auth.logic.tuwien.ac.at

Re: A concerned user -- debian Guidelines

[Noel Torres]

On Monday, 10 de November de 2014 08:57:50 Nathael Pajani escribió:
[...]
> You certainly heard about "debianfork" (http://debianfork.org/) and from a
> user point of view this is a tragedy.

A derivative and a fork are different things. A Derivative happens when a 
different project is started using the codebase of the first, with different 
goals, and both projects cross-pollinize each other. Both become stronger, if 
nough manpower is available. A fork happens when angry developers start a copy 
of the first project and abandon it, because it is unworkable. Ubuntu is a 
derivative. XOrg is a fork (and XFee86 was almost abandoned).

If Debianfork is a fork, it will be sad, as you say. But it seems to me that 
(if realized) it will become a derivative. Maybe an angry derivative with 
small cross-help, but a derivative anyway.
> 
> >From my point of view (or from a user's point of view) what is about to
> >happen is a breach
> 
> in Debian Social Contract.
> 
> 
> Debian Social Contract states as point 4 : Our priorities are our users and
> free software
> 
> >From my point of view, users are ignored, and what we can read here and
> >there is that the
> 
> decision is up to (put bluntly) "those who spend time in the project" (the
> Debian developers).

Agreed. But since Debian is a volunteer's project, it makes sense that the 
people who works on it (not *for* it) works on the topics they prefer. In my 
view, forcing systemd is a bad election, while choosing it as default for new 
installs is a good one. And that second decision was taken with the users as a 
priority, since it improves the user experience for our less technically 
suited users which just want "to install that Linux thing and have Word and a 
browser", since systemd makes Gnome work better. The first decision is the one 
we are actually discussing (or arguing about): whether to force init switch on 
upgrade. Ability to install a different than default init system has been 
raised as a concern as well. But systemd IS our default.
> 
> But the project exists because thousands of other people use it and
> contribute to other free software - those 20K free software which makes
> Debian such a rich Distribution.

Not necesarily. The project exists because some people devotes time on it. 
Systemd itself, as an example at hand, was developed mainly at Red Hat 
quarters. And we use it. It does not depend on Debian in order to contribute 
to Debian. Same for tons of other projects.
> 
> Even, some users contribute directly to Debian, by filling bug reports,
> speaking about Debian, buying goodies,  and many many other ways.

True. Some of them will enjoy systemd, some actually hate it with no reason, 
and some want systemd-free systems for good reasons. And still some do not 
care. And the hard point is to give figures for those sets.
> 
> 
> When a (big ?) pool of users is not happy to the point of suggesting to
> fork because of a decision taken (or about to be taken) by the project
> developers, then (I think) that the Debian developers are not doing their
> job right.
> 
> You'll notice that the fork has not been started yet, as (I think) many
> still hope this can end the right way, with USERS taken into account. All
> of them.

Agreed that all users must be taken into account, by our Constitution. But 
somebody must do the work.

Remember that the issue is not about the default. That wave passed time ago. 
It is about exact meaning of some words like "default" itself.

AND, if the worst thing happens here and Debianfork starts in the most hateing 
way, Debian will still be a great community (not so big, but still great) with 
the best non-company Linux distribution available. And with time hate will 
disappear and most probably Debianfork will become some kind of Debian Blend.
> 
[...]
> 
> Remember Ian Murdock's intention : " Ian intended Debian to be a
> distribution which would be made openly, in the spirit of Linux and GNU".

And it is. This very thread and the GRs and the CTTE decisions are proof that 
it is made openly. It just happens that some developers have excess of love 
for their init system project, and that that project is engulfing other things 
and that it has binary logs and a lot of other issues... but the decision was 
taken openly.
> 
> Still from my point of view, this means that the user can choose between
> alternatives for almost everything when there is a choice. Let's cite a
> few to make it evident : Vim/emacs, KDE/Gnome/All/the/others/ones, Debian
> kernel/custom kernel, 

There is option to use other init systems on Jessie. It has been shown how to 
install them. Maybe Release Notes need extra work. Do you volunteer? Surely 
Debian Installer needs a lot of extra work and testing. Do you volunteer? Sure 
as hell Debian will benefit for a new, shiny, well-designed init system in the 
UNIX principles tradition. Will you write it?

[...]
> 
> Especially when this breaks so many of my systems. Of course I coul

Processed: Re: Bug#769187: general: Entries in system log for failed services refer to FreeDesktop.ORG for support

[Debian Bug Tracking System]

Processing control commands:

> reassign -1 src:systemd
Bug #769187 [general] general: Entries in system log for failed services refer 
to FreeDesktop.ORG for support
Bug reassigned from package 'general' to 'src:systemd'.
Ignoring request to alter found versions of bug #769187 to the same values 
previously set
Ignoring request to alter fixed versions of bug #769187 to the same values 
previously set

-- 
769187: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=769187
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/handler.s.b769187.14157524452863.transcr...@bugs.debian.org

Bug#769187: general: Entries in system log for failed services refer to FreeDesktop.ORG for support

[Ben Hutchings]

Control: reassign -1 src:systemd

On Mon, 2014-11-10 at 02:13 +0100, Tomas Fasth wrote:
> Package: general
> Severity: normal
> 
> I use Virtualbox to run test environments for the packages I maintain
> (just a few really). I install virtualbox-guest-utils in my guest
> installations to adjust system clock after hibernation.
> 
> In Jessie, there seem to be a problem with the virtualbox guest service.
> It fails to start and, as usual, I look in the system log for clues.
[...]
> // log extract begins
> nov 10 01:36:47 debian-systemd sudo[1429]: tomfa : TTY=pts/0 ; 
> PWD=/home/tomfa ; USER=root ; COMMAND=/usr/sbin/service 
> virtualbox-guest-utils start
> nov 10 01:36:47 debian-systemd sudo[1429]: pam_unix(sudo:session): session 
> opened for user root by tomfa(uid=0)
> nov 10 01:36:47 debian-systemd virtualbox-guest-utils[1447]: Starting 
> VirtualBox AdditionsNo suitable module for running kernel found ... failed!
> nov 10 01:36:47 debian-systemd virtualbox-guest-utils[1447]: failed!
> nov 10 01:36:47 debian-systemd sudo[1429]: pam_unix(sudo:session): session 
> closed for user root
> nov 10 01:36:47 debian-systemd systemd[1]: virtualbox-guest-utils.service: 
> control process exited, code=exited status=1
> nov 10 01:36:47 debian-systemd systemd[1]: Failed to start LSB: VirtualBox 
> Linux Additions.
> -- Subject: Unit virtualbox-guest-utils.service has failed
> -- Defined-By: systemd
> -- Support: http://lists.freedesktop.org/mailman/listinfo/systemd-devel

The 'LSB:' prefix indicates the systemd unit was defined by an init
script with LSB headers.  The support URL is generated by systemd's
generic support for init scripts, which could easily be changed.

However, native systemd unit definitions can and probably will also
specify their own uptream support URL.

> -- Unit virtualbox-guest-utils.service has failed.
> -- 
> -- The result is failed.
> nov 10 01:36:47 debian-systemd systemd[1]: Unit 
> virtualbox-guest-utils.service entered failed state.
> // log extract ends
> 
> I don't understand why there should be a reference to an external support
> entity when the issue obviously is Debian related and should be reported
> as such in Debian-related forums. My specific issue has nothing to do
> with systemd or FreeDesktop.ORG. I want the external reference removed.
> If it stays it will only create confusion and misunderstanding.

This is useful for third-party packages and unpackaged software but I
agree that for packaged software systemd error logging should clearly
refer to both Debian and upstream sources for support.

Ben.

-- 
Ben Hutchings
Experience is directly proportional to the value of equipment destroyed.
 - Carolyn Scheppner


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

Beersigning in Zürich/SH/Winti? Meeting other local Debianistas? Bugfixing?

[Tomas Pospisek]

Hello all,

since

1. I need signatures on my all new fresh key 0x29774B39 and
2. I would love to meet all the local Debianistas

would any of you come and sign my key when in Zürich/SH/Winti?

Anybody interested in going out for a beer? We could also have a
bugfixing evening.

Wink,
*t


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/5462c30f.3090...@sourcepole.ch

Re: Should fast-evolving packages be backports-only?

[Rogério Brito]

On 2014-11-11 15:30, Henrique de Moraes Holschuh wrote:
> However, candidate packages due to reason (c) above really are a problem,
> IMHO they shouldn't be in stable in the first place.

Does this mean that I should ask for the removal of youtube-dl from testing?

It will certainly bitrot in a stable release, as it supports downloading
from many sites, the target sites are moving too fast (that's the nature
of the web) and there's no chance that I will be hunting minimal patches
to fix breakage of multiple sites, as upstream generally refactors the
whole thing constantly and as multiple sites may get broken, the pile of
patches would sometimes be larger than the code to extract data from
some simpler sites.

I am, though, very happy to upload newer upstream versions.


Cheers,

-- 
Rogério Brito : rbrito@{ime.usp.br,gmail.com} : GPG key 4096R/BCFC
http://cynic.cc/blog/ : github.com/rbrito : profiles.google.com/rbrito
DebianQA: http://qa.debian.org/developer.php?login=rbrito%40ime.usp.br


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

Re: RFC: DEP-14: Recommended layout for Git packaging repositories

[Marco d'Itri]

On Nov 11, Raphael Hertzog  wrote:

>   QUESTION: some people have argued to use debian/master as the latest
>   packaging targets sometimes sid and sometimes experimental. Should we
>   standardize on this? Or should we explicitly allow this as an alternative?
Whatever the decision will be on debian/master, I think that master 
should be at the very least an option.

> When releasing a Debian package, the packager should create and push
> a signed tag named `/`. For example, a Debian maintainer
I am attaching the simple "git debtag" command that I use on my 
packages, in the hope that somebody will find a good home for it. :-)

> If the Git workflow in use imports the upstream sources from released
> tarballs, this should be done under the "upstream" namespace. By default,
> the latest upstream version should be imported in the `upstream/latest`
> branch and when packages for multiple upstream versions are maintained
> concurrently, one should create as many upstream branches as required.
I do not think that concurrently importing multiple upstream versions is 
the common case, so just the simple "upstream" that many packages are 
currently using should be allowed as well.

-- 
ciao,
Marco
#!/bin/sh -e

VER="$(dpkg-parsechangelog --show-field Version)"

if [ -z "$VER" ]; then
  echo "Could not parse the changelog!" >&2
  exit 1
fi

VER="$(echo "$VER" | sed -e 's/~/_/g' -e 's/:/%/g')"

# is there a simple and reliable way to determine if a package is native?
if git tag | grep -q '^debian/'; then
  TAG="debian/$VER"
else
  TAG="v$VER"
fi

exec git tag -s -m "version $VER" $TAG



pgpkZQ01qZCZ0.pgp
Description: PGP signature

Re: RFC: DEP-14: Recommended layout for Git packaging repositories

[Mathieu Parent]

2014-11-11 22:26 GMT+01:00 Raphael Hertzog :
> Hello,

Hello Raphael,

> following the initial discussion we had in August
> (https://lists.debian.org/debian-devel/2014/08/thrd2.html#00499), I have
> written a first draft of the Debian Enhancement Proposal that I suggested.
> It's now online at http://dep.debian.net/deps/dep14 and also attached
> below so that you can easily reply and comment.

Thanks for this much-needed DEP!

[...]
>   QUESTION: some people have argued to use debian/master as the latest
>   packaging targets sometimes sid and sometimes experimental. Should we
>   standardize on this? Or should we explicitly allow this as an alternative?

I prefer as much standardization as possible. debian/sid should not be
a particular case.

[...]

A paragraph about repacked upstream is needed. A lot of packages are
currently stripped for minified JS, non-free additions, included RFCs,
... What would the upstream/1.x branch be then? Maybe add an
upstream/1.x+debian branch?

Also, the vendor/* branches heads should be at a descendent commit of
the corresponding upstream branch, diffing only by the debian dir.

Regards
-- 
Mathieu


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/CAFX5sbzieQ75nT8xBa3GMw-gzd-uGFy2fzSmx5A=R=1uzfs...@mail.gmail.com

Re: Beersigning in Zürich/SH/Winti? Meeting other local Debianistas? Bugfixing?

[Paul Wise]

On Wed, Nov 12, 2014 at 10:16 AM, Tomas Pospisek wrote:

> would any of you come and sign my key when in Zürich/SH/Winti?

In case folks from these places aren't reading this list, some possibilities:

https://db.debian.org/search.cgi?country=ch&dosearch=Search
https://wiki.debian.org/Keysigning/Offers#CH
https://wiki.debian.org/LocalGroups#Switzerland
http://debian.ch/

This info brought to you by DebianLocations:

https://wiki.debian.org/DebianLocations

-- 
bye,
pabs

https://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: 
https://lists.debian.org/CAKTje6HDv4oZ8=9gxxBJDSYrqjkgmj=q1vaoaeyccaky6xn...@mail.gmail.com

Re: r-base-core upload to unstable does not respect freeze policy

[Andreas Tille]

Hi Santiago,

On Tue, Nov 11, 2014 at 10:24:11PM +0100, Santiago Vila wrote:
> > include /usr/share/R/debian/r-cran.mk
> > 
> > which contains:
> > 
> > rversion:= $(shell dpkg-query -W -f='$${Version}' r-base-dev)
> > ...
> > ## support ${R:Depends} via debian/${package}.substvars
> > echo "R:Depends=r-base-core (>= ${rversion})" >> 
> > debian/$(package).substvars
> 
> So, would this patch to the current r-base package improve things if
> applied to the version in unstable?
> 
> diff --git a/debian/r-cran.mk b/debian/r-cran.mk
> index e366f6b..0550173 100644
> --- a/debian/r-cran.mk
> +++ b/debian/r-cran.mk
> @@ -60,7 +60,7 @@ endif
>  #rversion:= $(shell zcat /usr/share/doc/r-base-dev/changelog.Debian.gz | 
> \
>  #dpkg-parsechangelog -l- --count 1  | \
>  #awk '/^Version/ {print $$2}')
> -rversion := $(shell dpkg-query -W -f='$${Version}' r-base-dev)
> +rversion := $(shell dpkg-query -W -f='$${Version}' r-base-dev | perl -ne 
> 'print /([0-9]\.[0-9])/')
>  
>  ## we use these results for the to-be-installed-in directory
>  debRlib  := $(CURDIR)/debian/$(package)/$(debRdir)

While this would create a versioned dependency relation which would
allow to migrate r-cran-epi to testing I'm personally lacking the
technical knowledge whether this is the correct solution.  From my point
of view the correct approach would be to create an r-base-core package
which declares a stable ABI and packages should depend from the ABI
version.  However, its way to late for implementing this in Jessie and
the R maintainer is not willing to do this anyway (at least he was not
when we discussed this in Wheezy freeze time[1]).

Kind regards

   Andreas.

[1] https://lists.debian.org/debian-devel/2013/04/msg00074.html
https://lists.debian.org/debian-devel/2013/04/msg00281.html
(and more in this thread and the according bug reports)

-- 
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: https://lists.debian.org/20141112061758.ga22...@an3as.eu

Re: Beersigning in Zürich/SH/Winti? Meeting other local Debianistas? Bugfixing?

[Daniel Pocock]

On 12/11/14 06:59, Paul Wise wrote:
> On Wed, Nov 12, 2014 at 10:16 AM, Tomas Pospisek wrote:
> 
>> would any of you come and sign my key when in Zürich/SH/Winti?
> 
> In case folks from these places aren't reading this list, some possibilities:
> 
> https://db.debian.org/search.cgi?country=ch&dosearch=Search
> https://wiki.debian.org/Keysigning/Offers#CH
> https://wiki.debian.org/LocalGroups#Switzerland
> http://debian.ch/
> 
> This info brought to you by DebianLocations:
> 
> https://wiki.debian.org/DebianLocations
> 


Even better - there is monthly beersigning near the main railway station
Zurich HB, look for the Debian Treff:

http://www.lugs.ch/lugs/termine/

I'm not far from Zurich myself, may be up there again Saturday, please
email on the debian.ch list or try #debian.ch


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/54630469.9040...@pocock.pro

Re: RFC: DEP-14: Recommended layout for Git packaging repositories

[Gergely Nagy]

> "Raphael" == Raphael Hertzog  writes:

Raphael> Packaging branches and tags
Raphael> ===

[...]

Raphael> The Git repository listed in debian/control's `Vcs-Git` field 
should
Raphael> usually have its HEAD point to the branch corresponding to the
Raphael> distribution where new upstream versions are usually sent. For 
Debian,
Raphael> it will usually be `debian/sid` (or sometimes 
`debian/experimental`).

Raphael> QUESTION: some people have argued to use debian/master as the 
latest
Raphael> packaging targets sometimes sid and sometimes experimental. Should 
we
Raphael> standardize on this? Or should we explicitly allow this as an 
alternative?

I'd suggest not standardizing on this, but having a list of
recommendations instead, without naming one single name as THE
recommended one. For different use cases, different HEAD makes sense.

Also, I like to name my branches according to the distribution that it
will target, which means I prefer debian/unstable over debian/sid. For
me, that makes more sense, at least in the case of unstable and
experimental. For anything else, codenames it is.

Raphael> When releasing a Debian package, the packager should create and 
push
Raphael> a signed tag named `/`. For example, a Debian 
maintainer
Raphael> releasing a package with version 2:1.2~rc1-1 would create a tag 
named
Raphael> `debian/2%1.2_rc1-1` whereas an Ubuntu packager releasing a 
package with
Raphael> version 1.3-0ubuntu1 would use `ubuntu/1.3-0ubuntu1`. The tags 
should
Raphael> point to the exact commit that was used to build the corresponding 
upload.

Mmm... I disagree here too. I think following upstream tagging
conventions would be the way to go here. So if upstream uses
`-` tags, then debian releases would be tagged like
`debian/foo-2%1.2_rc1-1`, if upstream is `foo-1.2rc1`.

Raphael> Other recommendations
Raphael> =

[...]

Raphael> What to store in the Git repository
Raphael> ---

Raphael> It is recommended that the packaging branches contain both the 
upstream
Raphael> sources and the Debian packaging. Users who have cloned the 
repository
Raphael> should be able to run `dpkg-buildpackage -b -us -uc` without doing
Raphael> anything else (assuming they have the required build dependencies).

Raphael> It is also important so that contributors are able to use the tool 
of their
Raphael> choice to update the debian/patches quilt series: multiple helper 
tools
Raphael> need the upstream sources in Git to manage this patch series as a 
Git
Raphael> branch.

I'd like to note that there are very good reasons for a debian-only,
overlay-style packaging repository too. This section should, in my
opinion, at least acknowledge that, and briefly mention it as an option.
I find it a bit sad that it was outright discouraged.

For the record, I used to hate that style, and was an advocate for
storing upstream sources in the repo too. Then I started maintaining ~6
packaging branches: three upstream versions, two packaging branch
variants of each. The overlay style proved to be far superior in this
case.

In short, I'd suggest having the DEP document both layouts, and
recommend using one of them, while also recommending to document it in
debian/README.source.

-- 
|8]


signature.asc
Description: PGP signature

Re: RFC: DEP-14: Recommended layout for Git packaging repositories

[Paul Wise]

On Wed, Nov 12, 2014 at 3:34 PM, Gergely Nagy wrote:

> I'd like to note that there are very good reasons for a debian-only,
> overlay-style packaging repository too. This section should, in my
> opinion, at least acknowledge that, and briefly mention it as an option.
> I find it a bit sad that it was outright discouraged.

Personally I wouldn't use anything other than debian-only repos, at
least for those where I have a choice. I also actively avoid
contributing to packages that don't use such repos.

-- 
bye,
pabs

https://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: 
https://lists.debian.org/CAKTje6EyPLx+zdfbKwhfEescL=ynqSfZ4ANfAqGX=4pkiv+...@mail.gmail.com

Re: RFC: DEP-14: Recommended layout for Git packaging repositories

[Vincent Cheng]

On Tue, Nov 11, 2014 at 11:38 PM, Paul Wise  wrote:
> On Wed, Nov 12, 2014 at 3:34 PM, Gergely Nagy wrote:
>
>> I'd like to note that there are very good reasons for a debian-only,
>> overlay-style packaging repository too. This section should, in my
>> opinion, at least acknowledge that, and briefly mention it as an option.
>> I find it a bit sad that it was outright discouraged.
>
> Personally I wouldn't use anything other than debian-only repos, at
> least for those where I have a choice. I also actively avoid
> contributing to packages that don't use such repos.

+1

Most of my collab-maint repos still use svn largely because svn
encourages debian-only repos (and also because of inertia, I guess),
not because I don't want to use git.

Regards,
Vincent


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/CACZd_tDnwCHxScaqGqKarT=pd5qaxkyodtcto3uklec9rhv...@mail.gmail.com