Re: Bug#760167: ITP: cligh -- Command-line interface to GitHub

[Paul Wise]

On Mon, Sep 1, 2014 at 9:58 PM, Dmitry Bogatov wrote:

> PS. Is it any tool to generate ITP bug from debian/ directory?

No, because ITPs are meant to be filed *before* the debian/ directory exists.

> Source package is already available at github: kaction/deb-cligh.

This should have been done after the ITP.

-- 
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/CAKTje6GOJSk08hfwxo5s=RVL=c0kq3w8a-duxc3yywoimxn...@mail.gmail.com

Re: 2 months and no upload for pkg

[Daniel Pocock]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256



On 05/09/14 20:46, Matthias Urlichs wrote:
> Hi,
> 
> Daniel Pocock:
>> 
 c) offer a paid review service.  FTP masters and assistants
 can sell their time through an auction process.  [...]
>>> 
>>> I hope this is a joke.
>> 
>> Not entirely I was not suggesting people would pay to have their
>> packages approved. Only that there would be payment for
>> consideration.
> 
> I recall that the last time we went through this sort of argument, 
> numerous people have stated quite unequivocally that as soon as
> there is any sort of direct monetary compensation for participating
> in some Debian tasks, they're outta here.
> 
> I don't think that has changed, and thus I believe that the net
> amount of work done for Debian is most likely to *de*crease if
> somebody does that kind of thing.
> 
> TL;DR: Do Not Go There.

Well, I did give the disclaimer that this was just a list of ideas to
start discussion - it would be really helpful to have other potential
ideas too.

There is already the appearance of commercial activity in derivatives
and it can also undermine motivation for people when they upload
something to Debian and they see it in a commercially funded
derivative distribution before it passes the NEW queue and appears in
Debian itself.  In the case of one of my own uploads, this appeared to
be pure co-incidence but I can imagine cases where the packager may
get a bad impression.

One way to deal with this may be to suggest that if something is
accepted by Ubuntu while waiting in NEW and if it passes an automated
scan for binary content and blacklisted license texts, it could be
automatically accepted in Debian.

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.12 (GNU/Linux)
Comment: Using GnuPG with Icedove - http://www.enigmail.net/

iQIcBAEBCAAGBQJUCsCyAAoJEGxlgOd711bEosUQAJfL62+H0r0FsbHTuMZQ9Fbs
Lzg/umTgZ8qcS81g09EW0LqiuYiXAD+tvsF8OoktxvmBWspUEOd3xj2tA0ZstaG0
v7ZWgK6wfiXoQmWqs9viUy1nrHguM1FbNpSCsYRsM56w7jsLqwroxLJGTN/vPrjI
bRgeaw4HGGG3hY0Ln4sEAYI+ehJ3XOu2MDIqpEfsdvSOuoA6Y/FF0cH7Enk6zaQ+
5Dx2+PBLY5MP2pr0zV0zGnLsZuNSWoBFvqYHCu8qCS1mbFcfloaOLTftYTIYgAzg
ktXZL5HEM3H7HQsVup9j7JZIvU4z69v47/5UqkfK0GwmViz730G9TksJHURLDMmc
9SLOQty9Ga3m4JgK+G2vtJs4lmJ06ghUGktGIbeiTzCKYHzI6fIYOCIHYs6OGG6x
H4DrzolOPDBcibVIQSHnkSma1u2ORVP3+0kXHvdOIGmOBg+kkEXEvmIey/f8kG63
kCnISbtHa5VgPS4syA1fvAFnAruaKHL0G3QEtrMTdRp9s1vIVZSTbP0G0VlV1TKh
E8l9mr0Ol5N38uLNKjm4JXiLkte+b3QF0vUfClre7add96XeJeLOlBjJ8KBdOknF
xobrlmmhr8VkSe1cpOJJKMiHDoWVII1hKY/VPSPtMsIgz/7GkcM7J378UmNg70aI
S420ykwhPJ5TWK7BMAuR
=CPJk
-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/540ac0b2.5000...@pocock.pro

Bug#760629: ITP: qrouter -- Multi-level, over-the-cell maze router

[ruben . undheim]

Package: wnpp
Severity: wishlist
Owner: ruben.undh...@gmail.com


* Package name: qrouter
  Version : 1.1.55
  Upstream Author : Tim Edwards 
* URL : http://opencircuitdesign.com/qrouter/
* License : GPL-2
  Programming Lang: C
  Description : Multi-level, over-the-cell maze router

 Qrouter is a tool to generate metal layers and vias to physically connect
 together a netlist in a VLSI fabrication technology. It is a maze router,
 otherwise known as an "over-the-cell" router or "sea-of-gates" router. That
 is, unlike a channel router, it begins with a description of placed standard
 cells, usually packed together at minimum spacing, and places metal routes
 over the standard cells.
 .
 Qrouter uses the open standard LEF and DEF formats as file input and output.
 It takes the cell definitions from a LEF file, and analyzes the geometry for 
 each cell to determine contact points and route obstructions. It then reads
 the cell placement, pin placement, and netlist from a DEF file, performs the 
 detailed route, and writes an annotated DEF file as output.


-- 
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/20140906082539.8398.97462.reportbug@miniserver.granittvegen

Re: systemd, again (Re: Cinnamon environment now available in testing)

[Noel Torres]

On Friday, 5 de September de 2014 21:36:43 Ansgar Burchardt escribió:
> Nothing prevents you from a, installing systemd-shim from Jessie before
> running apt-get dist-upgrade or b, using "apt-get dist-upgrade upstart".
> 
> I'm fairly sure I saw this question also answered on -user@ once or
> twice times (which is also the appropriate list to ask such questions).
> 
> Ansgar

So, in your POV, forcing millions of sysadmins out there to take extra pain to 
keep their systems running as they expect is the way to go?

Do you really expect millions of users to read and understand the (sometimes 
cryptic) release notes explaining that they must perform a not straightforward 
upgrade just to jave their systems up to date?

Do you think it is realistic to expect them all reading some obscure 
documentation _before_ upgrading?

Experience shows us that most of our users just do not read the Release Notes, 
and those who do that do it mostly after havin encountered some problem.

Regards

Noel
er Envite


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

There should not be dependencies on systemd (Was: Cinnamon environment now available in testing)

[Noel Torres]

On Friday, 5 de September de 2014 18:52:44 Zack Weinberg escribió:
> Abstractly, I believe the ideal situation would be for all init systems
> in the archive to be *completely* co-installable, with /sbin/init a
> symlink under control of the administrator; under no circumstances would
> installing or upgrading any package change that symlink.  (It follows
> that systems upgraded from wheezy might wind up with systemd
> _installed_, but sysvinit would remain the active init until the local
> admin changed things manually.  Obviously this would need to be
> documented.)

I was thinking on all of this yesterday, when walking back from work to home, 
when I realized it:

It is just wrong to have dependencies on the init system.

If you need dbus, you should Depend on dbus, and systemd should Provides dbus. 
Then, if Ann programs her Own Dbus Implementation she can package it as aodi 
(Ann's Own Dbus Implementation) and have aodi Provides dbus. Same for logind 
(systemd Provides logind and random-package Depends logind), and any other 
piece of the big systemd ecosystem.

Any dependence on systemd or any other init system should be considered an RC 
bug (except only packages designed to manage the init system, like an 
imaginary systemd-tweaking-tool).

Do you need a cron system for a daily task? Just depend on timely-task, and 
have both systemd and cron provide timely-task.

This way we put the decision, and thus the power to configure their systems, 
back in sysadmins hands, instead of stealing that power for us.

Regards

Noel
er Envite


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

Re: 2 months and no upload for pkg

[Charles Plessy]

Le Fri, Sep 05, 2014 at 01:09:09PM -0400, Scott Kitterman a écrit :
> 
> grep -ir copyright * 
> 
> Do that over your source and then compare what you have in debian/copyright.  
> You might be surprised how often that turns up missing stuff.  Check your own 
> packages at least as carefully as you expect the FTP Team to check it.

Hi Scott, FTP team and everybody,

to have a perfect match between the names listed in debian/copyright and the
names found in the copyright statements in the upstream source files requires a
considerable amount of work, and in the case of some licenses this work is not
necessary for compliance.

It has been sometimes argued that this work is useful for the review process,
to prove that the source files have been inspected systematically and in
details.  However, when I reviewed some packages in the NEW queue
(), I found little value for this
information: what really matters is when license statements are missed.

I therefore propose to focus the review of the NEW queue on license compliance,
since this the point where errors can have the broadest consequences on Debian
as a whole.

In my impression from what I read on this mailing list, there is a positive
opinion in general about the fact that packages are more throuroughly checked
by the FTP team, as it increases Debian's quality, and indeed I agree that if
we could get this with little effort it would be great.  But in practice we can
see that it does not scale and the consequence is that packages need monthes
for being reviewed.  Therefore, let's not ask for the impossible; instead,
let's seek for the same level of quality through other processes.

In other distributions like Fedora, new packages are peer-reviewed in a public
issue tracker, in a way that is not unlike the "requests for sponsorship" (RFS)
on the debian-mentors mailing list.  I think that it would be reasonable to
require such reviews in Debian as well.  The existence of such a review
would not increase the work load of the FTP team if the inspections in the NEW
queue would be focused on license compliance, that can be done independantly
without reading the all the messages generated during the peer review.

In summary, a radical way to reduce the work load generated by the NEW queue
would be to split that work, leaving only licence compliance checks and
approval of new Free licenses to the queue, and transferring the checks for
DFSG compliance (missing source files, non-free licenses, ...) and quality in
general to another stage of package production.

Have a nice week-end,

-- 
Charles Plessy


-- 
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/20140906090810.gf31...@falafel.plessy.net

Re: systemd, again (Re: Cinnamon environment now available in testing)

[Marc Haber]

On Fri, 05 Sep 2014 15:12:50 +0200, Svante Signell
 wrote:
>On Fri, 2014-09-05 at 14:20 +0200, Matthias Urlichs wrote:
>> Thus, unless the user explicitly tells the apt{-get,itude} subsystem not
>> to switch to systemd (by whatever means, the details of which I personally
>> am not at all interested in), a dist-upgrade should do so.
>
>How? All efforts so far and bugs reported are being brought down
>actively.

#618862, dating back to 2011 and with no Debian maintainer reaction in
months?

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


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/e1xqbld-0005tk...@swivel.zugschlus.de

Re: systemd, again (Re: Cinnamon environment now available in testing)

[Sven Joachim]

On 2014-09-05 23:50 +0200, Russ Allbery wrote:

> Adam Borowski  writes:
>
>> systemd also pulls in a large amount of bloat (IIRC someone mentioned
>> 100ish packages in wheezy vs 146 in current jessie).  Purging those is
>> nontrivial, as some had their priority bumped up.
>
> That seems much higher than I believe is the case.  Wasn't there a
> detailed analysis of this posted a while back?  My vague recollection was
> a number more on the order of a quarter of that, and with most of those
> being quite small (such as libsystemd-daemon0, which counts as a package
> but which has an installed size of 72KB).

Here's what I get when replacing sysvinit-core with systemd-sysv in my
pbuilder chroot:

,
| The following NEW packages will be installed:
|   acl{a} (D: systemd)  adduser{a} (D: systemd)  dmsetup{a} (D: 
libdevmapper1.02.1)  
|   libcap2-bin{a} (D: systemd)  libcryptsetup4{a} (D: systemd)  
|   libdbus-1-3{a} (P: systemd, D: systemd)  
|   libdevmapper1.02.1{a} (D: dmsetup, D: libcryptsetup4)  
|   libgcrypt11{a} (P: systemd, D: libsystemd-journal0)  
|   libgcrypt20{a} (D: libcryptsetup4)  
|   libgpg-error0{a} (D: libcryptsetup4, D: libgcrypt11, D: libgcrypt20)  
|   libkmod2{a} (D: systemd, D: udev)  libprocps3{a} (D: procps)  
|   libsystemd-daemon0{a} (P: systemd)  libsystemd-journal0{a} (D: systemd)  
|   libsystemd-login0{a} (D: systemd)  
|   libudev1{a} (D: libdevmapper1.02.1, D: systemd, D: udev)  
|   libwrap0{a} (D: systemd)  procps{a} (D: udev)  
|   systemd{a} (P: systemd-sysv, D: systemd-sysv)  systemd-sysv  
|   udev{a} (D: systemd)  
| The following packages will be REMOVED:
|   sysvinit-core  
| The following packages are RECOMMENDED but will NOT be installed:
|   dbus (R: libdbus-1-3)  libpam-cap (R: libcap2-bin)  libpam-systemd (R: 
systemd)  
|   psmisc (R: initscripts, R: procps)  tcpd (R: libwrap0)  
| 0 packages upgraded, 21 newly installed, 1 to remove and 0 not upgraded.
| Need to get 0 B/4436 kB of archives. After unpacking 18.1 MB will be used.
`

Cheers,
   Sven


-- 
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/87tx4ljewq@turtle.gmx.de

Re: systemd, again (Re: Cinnamon environment now available in testing)

[Ansgar Burchardt]

Noel Torres  writes:
> On Friday, 5 de September de 2014 21:36:43 Ansgar Burchardt escribió:
>> Nothing prevents you from a, installing systemd-shim from Jessie before
>> running apt-get dist-upgrade or b, using "apt-get dist-upgrade upstart".
>> 
>> I'm fairly sure I saw this question also answered on -user@ once or
>> twice times (which is also the appropriate list to ask such questions).
>
> So, in your POV, forcing millions of sysadmins out there to take extra pain 
> to 
> keep their systems running as they expect is the way to go?

I think it's fair to expect the few hundred people[1] that want to run a
non-default init system to do so, yes.

  [1] I can also make up numbers :)

> Do you really expect millions of users to read and understand the (sometimes 
> cryptic) release notes explaining that they must perform a not 
> straightforward 
> upgrade just to jave their systems up to date?
>
> Do you think it is realistic to expect them all reading some obscure 
> documentation _before_ upgrading?

No, but that shows that it's important that people get the default init
system on upgrade by default: if they encounter problems, it is easier
to find help if you run something close to a default installation.

Ansgar


--
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/851trpcdto@tsukuyomi.43-1.org

Re: There should not be dependencies on systemd

[Ansgar Burchardt]

Noel Torres  writes:
> If you need dbus, you should Depend on dbus, and systemd should Provides 
> dbus. 
> Then, if Ann programs her Own Dbus Implementation she can package it as aodi 
> (Ann's Own Dbus Implementation) and have aodi Provides dbus. Same for logind 
> (systemd Provides logind and random-package Depends logind), and any other 
> piece of the big systemd ecosystem.
>
> Any dependence on systemd or any other init system should be considered an RC 
> bug (except only packages designed to manage the init system, like an 
> imaginary systemd-tweaking-tool).

That doesn't change anything in practice as long as systemd would be the
only package providing logind. So until someone writes an alternative
implementation, it would just be useless work.

So feel free to raise this once alternative implementations exist.

Ansgar


-- 
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/85wq9hayzv@tsukuyomi.43-1.org

Bug#760632: ITP: python-barbicanclient -- OpenStack Key Management API client

[Thomas Goirand]

Package: wnpp
Severity: wishlist
Owner: Thomas Goirand 

* Package name: python-barbicanclient
  Version : 2.2.1
  Upstream Author : Douglas Mendizabal 
* URL : https://github.com/openstack/python-barbicanclient
* License : Apache-2.0
  Programming Lang: Python
  Description : OpenStack Key Management API client

 This is a client for the Barbican Key Management API. This package includes a
 Python library for accessing the API (the barbicanclient module), and a
 command-line script (barbican).


-- 
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/20140906093545.29759.41456.report...@buzig.gplhost.com

Re: Bug#760167: ITP: cligh -- Command-line interface to GitHub

[Dmitry Bogatov]

* Paul Wise  [2014-09-06 15:48:09+0800]
> On Mon, Sep 1, 2014 at 9:58 PM, Dmitry Bogatov wrote:
>
> > PS. Is it any tool to generate ITP bug from debian/ directory?
>
> No, because ITPs are meant to be filed *before* the debian/ directory
> exists.

My reason was that I am noob, and it takes undefined amount of time for
me to find out how to package new kind. If despite of it, it is still
okay to ITP before any work done, I will.

> > Source package is already available at github: kaction/deb-cligh.
>
> This should have been done after the ITP.

Well, now we have package and it's ITP. Would you be so kind to
take a look at it?

--
Best regards, Dmitry Bogatov ,
Free Software supporter, esperantisto and netiquette guardian.
GPG: 54B7F00D


pgp_nC3cAnGvc.pgp
Description: PGP signature

Re: Bug#760167: ITP: cligh -- Command-line interface to GitHub

[Ross Gammon]

On 09/06/2014 11:56 AM, Dmitry Bogatov wrote:
> * Paul Wise  [2014-09-06 15:48:09+0800]
>> On Mon, Sep 1, 2014 at 9:58 PM, Dmitry Bogatov wrote:
>>
>>> PS. Is it any tool to generate ITP bug from debian/ directory?
>>
>> No, because ITPs are meant to be filed *before* the debian/ directory
>> exists.
> 
> My reason was that I am noob, and it takes undefined amount of time for
> me to find out how to package new kind. If despite of it, it is still
> okay to ITP before any work done, I will.
> 
>>> Source package is already available at github: kaction/deb-cligh.
>>
>> This should have been done after the ITP.
> 
> Well, now we have package and it's ITP. Would you be so kind to
> take a look at it?
> 
> --
> Best regards, Dmitry Bogatov ,
> Free Software supporter, esperantisto and netiquette guardian.
> GPG: 54B7F00D
> 
Hi Dmitri

Getting started can be tough. I can recommend the mentors mailing list
where there are many experienced developers devoting time to help new
packagers get started:
https://www.debian.org/doc/manuals/maint-guide/start.en.html#helpme
http://mentors.debian.net/intro-maintainers

Cheers,

Ross


-- 
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/540adcaa.2040...@the-gammons.net

Re: Cinnamon environment now available in testing

[Michael Biebl]

Am 06.09.2014 01:01, schrieb Steve Langasek:
> Michael, is it clear to you why this change is needed, and can you
> un-wontfix this bug please, to list systemd-shim as the first ORed
> dependency as I've asked previously?

Steve, as long as bugs like [1] are not fixed in systemd-shim, I'm not
going to make it the first alternative. Installing a half-broken logind
whould be a disservice to our users.


[1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=756076
-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?



signature.asc
Description: OpenPGP digital signature

Re: systemd, again (Re: Cinnamon environment now available in testing)

[Adam Borowski]

On Sat, Sep 06, 2014 at 11:12:35AM +0200, Ansgar Burchardt wrote:
> Noel Torres  writes:
> > So, in your POV, forcing millions of sysadmins out there to take extra pain 
> > to 
> > keep their systems running as they expect is the way to go?
> 
> I think it's fair to expect the few hundred people[1] that want to run a
> non-default init system to do so, yes.
> 
>   [1] I can also make up numbers :)

Ok, so let's quantify the view of sysadmins somehow.  This can actually
be done in a meaningful way: let's count posts on places where
technically-minded folks gather.  There's plenty of minor blogs that are
biased, but let's choose big sites where we can have a reasonable chance
of being unbiased.  I chose Slashdot and it's fork, SoylentNews.

Counting only posts above the default threshold for a non-logged-in user:


http://soylentnews.org/article.pl?sid=14/09/01/1844249
(article about "Poettering's vision")

unrelated/no clear opinion:  3
anti-poettering:10
anti-systemd in particular:  8
ambivalent:  1
pro: 0 !!!

http://soylentnews.org/article.pl?sid=14/08/19/0841221
(article about systemd)

unrelated/no opinion: 12
pro:   1
anti: 15

http://linux.slashdot.org/story/14/09/02/2037251/you-got-your-windows-in-my-linux
(article about systemd-caused schism)

unrelated/no opinion: 33
pro:   2
anti: 22
ambivalent:4


-- 
// If you believe in so-called "intellectual property", please immediately
// cease using counterfeit alphabets.  Instead, contact the nearest temple
// of Amon, whose priests will provide you with scribal services for all
// your writing needs, for Reasonable and Non-Discriminatory prices.


-- 
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/20140906123304.ga17...@angband.pl

Re: systemd, again (Re: Cinnamon environment now available in testing)

[Axel Wagner]

Hi,

Adam Borowski  writes:
> Ok, so let's quantify the view of sysadmins somehow.  This can actually
> be done in a meaningful way: let's count posts on places where
> technically-minded folks gather.

No, this is absolutely not meaningful. To deduce anything from this, you
would have to assume that the two variables "opinion about systemd" and
"likelihood to participate in flames about it" are statistically
independent. In my experience this is not the case and it certainly is
not an assumption you can "simply make".

Moreover, you would need to not count posts, but unique posters, which
will be a very hard to get, because in a lot of flames there are people
who get one spam-address after the other, when they get blocked, which
would further skew the numbers towards whichever camp has more
disrespectfull trolls.

Best,

Axel Wagner


-- 
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/87fvg4oqb5.fsf@rincewind.i-did-not-set--mail-host-address--so-tickle-me

Re: systemd, again (Re: Cinnamon environment now available in testing)

[Adam Borowski]

On Sat, Sep 06, 2014 at 03:02:06PM +0200, Axel Wagner wrote:
> Moreover, you would need to not count posts, but unique posters, which
> will be a very hard to get, because in a lot of flames there are people
> who get one spam-address after the other, when they get blocked, which
> would further skew the numbers towards whichever camp has more
> disrespectfull trolls.

That's Slashdot not 4chan.  The discussion there is mostly civil, and
spam-posters immediately get moderated into oblivion.  If you want your
posts to show up, you need an established account rather than something
newly created.  Heck, in the methodology I used, the threshold was high
enough that even an old account would require at least one up-mod to get
counted.

Thus, Slashdot post count is more meaningful than, say, counting posts
here on unmoderated debian-devel.

-- 
// If you believe in so-called "intellectual property", please immediately
// cease using counterfeit alphabets.  Instead, contact the nearest temple
// of Amon, whose priests will provide you with scribal services for all
// your writing needs, for Reasonable and Non-Discriminatory prices.


-- 
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/20140906133252.ga18...@angband.pl

Re: systemd, again (Re: Cinnamon environment now available in testing)

[Ansgar Burchardt]

Adam Borowski  writes:
> Ok, so let's quantify the view of sysadmins somehow.  This can actually
> be done in a meaningful way: let's count posts on places where
> technically-minded folks gather.  There's plenty of minor blogs that are
> biased, but let's choose big sites where we can have a reasonable chance
> of being unbiased.  I chose Slashdot and it's fork, SoylentNews.

That's not unbiased. People are more likely to write negative comments:
after all if you are happy with ${x}, why write a comment at all?

Also, given the style of the articles you selected, what kind of people
would they attract to comment? Whom would you expect to share links to
such articles with like-minded persons? Would that bias the comments
towards a certain side?

But hey, let's just do other statistics which should be more relevant to
Debian: the number of Debian developers, which also are often sysadmins
and are certainly technically-minded, that find systemd a truly horrible
choice. The last time people polled that number, it was below the small
number of developers needed to start a GR.

Ansgar


-- 
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/85fvg497wm@tsukuyomi.43-1.org

Re: systemd, again (Re: Cinnamon environment now available in testing)

[Matthias Urlichs]

Hi,

Marc Haber:
> On Fri, 05 Sep 2014 15:12:50 +0200, Svante Signell
>  wrote:
> >On Fri, 2014-09-05 at 14:20 +0200, Matthias Urlichs wrote:
> >> Thus, unless the user explicitly tells the apt{-get,itude} subsystem not
> >> to switch to systemd (by whatever means, the details of which I personally
> >> am not at all interested in), a dist-upgrade should do so.
> >
> >How? All efforts so far and bugs reported are being brought down
> >actively.
> 
> #618862, dating back to 2011 and with no Debian maintainer reaction in
> months?
> 
This bug's latest entry asks the original reporter whether the bug still
applies. In addition, there's Upstream's request for an updated patch, from
earlier this year. Both appear not to have happened yet.

The systemd transition is not simple. I do not think it's reasonable to
expect the Debian maintainer to be able to reproduce every problem, so what
else would you have them do about this bug?

-- 
-- Matthias Urlichs


signature.asc
Description: Digital signature

Re: systemd, again (Re: Cinnamon environment now available in testing)

[Matthias Urlichs]

Hi,

Adam Borowski:
> Thus, Slashdot post count is more meaningful than, say, counting posts
> here on unmoderated debian-devel.
> 
That doesn't change the fact that most people who are OK with systemd have,
to put it mildly, better things to do these days than to participate in yet
another "discussion" about how evil, overbearing, non-Unix-way-ish, buggy,
or being-driven-by-a-principal-author-who-is-a-*censored* systemd is.

-- 
-- Matthias Urlichs


signature.asc
Description: Digital signature

Re: systemd, again (Re: Cinnamon environment now available in testing)

[Matthias Urlichs]

Hi,

Noel Torres:
> Do you think it is realistic to expect them all reading some obscure 
> documentation _before_ upgrading?
> 
No. I expect them all to continue running just peachy fine and seamlessly.
I also expect the Jessie upgrade to switch to systemd. Because, frankly and
strictly IMHO, doing anything else makes no sense whatsoever.

On the other hand, I *do* expect anybody who does NOT want to switch to
systemd to already know before upgrading that they'll need to do somethink
non-standard if they really want to stay with sysVinit / switch to
[another_init] instead, simply because they already know that the default
upgrade will switch.

-- 
-- Matthias Urlichs


signature.asc
Description: Digital signature

Re: x32: a success story, and thanks to you all!

[Colin Watson]

On Fri, Sep 05, 2014 at 11:25:43PM +0100, Ben Hutchings wrote:
> On Fri, 2014-09-05 at 17:29 +0100, Colin Watson wrote:
> > On Fri, Sep 05, 2014 at 04:43:01PM +0100, Ben Hutchings wrote:
> > > No, they should add amd64 as a foreign architecture.
> > 
> > Should we do this by default for x32 in d-i?  (Yes, I know d-i doesn't
> > support x32 in other ways yet, but we might as well get started at some
> > point.)
> 
> Yes I think so.

Committed to apt-setup.

-- 
Colin Watson   [cjwat...@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/20140906145928.ga10...@riva.ucam.org

Re: systemd, again

[http]

Most people who are not OK with systemd have better things to than try to persuade debian-devel that the debian prject's 
transition to it is problematic, and at more than just the implementation level.


See how much fun it is to belittle?  See how good it feels?

More important than numbers is content.  The objections being raised seem diverse, dire and cogent, while the defenses seem to 
be mere vague reassurances expressed in tones just as dismissive as yours was just there.


Peter Rooney


On 06/09/14 07:00 AM, Matthias Urlichs wrote:
> That doesn't change the fact that most people who are OK with systemd have,
> to put it mildly, better things to do these days than to participate in yet
> another "discussion" about how evil, overbearing, non-Unix-way-ish, buggy,
> or being-driven-by-a-principal-author-who-is-a-*censored* systemd is.
>


--
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/540b2b7a.2060...@shaw.ca

Re: systemd, again (Re: Cinnamon environment now available in testing)

[Zack Weinberg]

Matthias Urlichs wrote:
>
> I also expect the Jessie upgrade to switch to systemd. Because,
> frankly and strictly IMHO, doing anything else makes no sense
> whatsoever.

This is exactly the thing I don't agree with.

I think _new installs_ of Jessie should use systemd as init (by
default, anyway), but _upgrades_ from Wheezy or prior should continue
to use whatever it is they were using before the upgrade, until the
administrator takes an additional positive action to convert to
something else.  And I also think that "additional positive action"
should NOT consist of installing or upgrading any package, but rather,
something like changing what /sbin/init is a symlink to.  (Hence the
earlier statement that all init systems in the archive should be
coinstallable, and that packages that need functionality provided by
one specific system should detect that it isn't available at runtime,
and gracefully degrade.)

I think this strategy is positively _necessary_ in order to ensure
that systems currently running Wheezy can safely be upgraded to
Jessie.  There are simply too many wacky configurations out there; it
is not reasonable to demand that the systemd maintainers test them
all; it is also not reasonable to demand that people with wacky
configurations take extra steps prior to the upgrade in order to
preserve a basically functional system afterward.  (Functional enough
to log in as root and make repairs, at least.  Ideally without having
to find another computer on which to search the interwebs for
troubleshooting advice.)

Even if you think this is not _technically_ necessary -- even if you
think the systemd team _can_ reasonably anticipate everything that
might possibly go wrong upon a forced changeover in the middle of a
dpkg run, on an arbitrarily wackily customized system -- I would argue
that it will provide tremendous _psychological_ reassurance to people
who might be _worried_ that something will break.  "Yes," Debian would
be saying, "we recognize that this is a major, disruptive change and
we have taken extra precautions to make sure it will only affect you
when you are good and ready, and if something _does_ break, you can
get back to the way it was very easily."

zw


-- 
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/20140906161746.e170824...@panix5.panix.com

Re: systemd, again

[Matthias Urlichs]

Hi,

h...@shaw.ca:
> Most people who are not OK with systemd have better things to than try to
> persuade debian-devel that the debian prject's transition to it is
> problematic, and at more than just the implementation level.
> 
By now, I would sure hope so.

> More important than numbers is content.  The objections being raised seem
> diverse, dire and cogent, while the defenses seem to be mere vague
> reassurances expressed in tones just as dismissive as yours was just there.
> 
The operative word is "seem". I quoted the word 'discussion' because,
frankly, for both sides of this argument, the other side is the one who
expresses mere vague reassurances|objections while ignoring relevant
facts.

-- 
-- 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/20140906163137.gm21...@smurf.noris.de

Bug#760661: ITP: libjs-twitter-bootstrap-wizard -- wizard using a formatted tabbable structure

[Thomas Goirand]

Package: wnpp
Severity: wishlist
Owner: Thomas Goirand 

* Package name: libjs-twitter-bootstrap-wizard
  Version : 1.0.0+dfsg1
  Upstream Author : Vincent Gabriel 
* URL : https://github.com/VinceG/twitter-bootstrap-wizard
* License : Expat & GPL-3
  Programming Lang: Javascript
  Description : wizard using a formatted tabbable structure

 This Twitter Bootstrap plugin builds a wizard using a formatted tabbable
 structure. It allows one to build a wizard functionality using buttons to go
 through the different wizard steps and using events allows one to hook into
 each step individually.
 .
 This Javascript library requires jQuery v1.3.2 or later, and supports
 Bootstrap 2.2.x, 2.3.x, 3.0.


-- 
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/20140906164654.7422.48805.report...@buzig.gplhost.com

Re: calling maintainer scripts with a clean environment?

[Evgeni Golov]

On 09/03/2014 09:40 AM, Simon McVittie wrote:
> On 02/09/14 20:09, Evgeni Golov wrote:
>> after reading #759590, I think it is time to consider calling maintainer 
>> scripts in a (slightly) cleaned environment.
> 
> Another possibility would be to guarantee that init scripts will be
> called in a cleaned environment. This seems like it will break fewer
> expectations, because systemd and (AIUI) Upstart do this anyway, sysv-rc
> does this during boot, and service(8) does this when a sysadmin uses it
> to invoke an init script explicitly; the missing piece of the puzzle is
> that invoke-rc.d(8) does not.

While pimping invoke-rc.d sounds like a good idea (and should be done),
I'd prefer the postrm pg_dump that is called from dbconfig-common not to
be executed with eatmydata either. Or with something else that is
preciously hidden in some LD_PRELEOAD.


My examples were init-specific, yeah. But IMHO this should apply for
everything called via maintainer scripts.


-- 
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/540b3613.1050...@golov.de

Re: systemd, again (Re: Cinnamon environment now available in testing)

[Russ Allbery]

Sven Joachim  writes:
> On 2014-09-05 23:50 +0200, Russ Allbery wrote:

>> That seems much higher than I believe is the case.  Wasn't there a
>> detailed analysis of this posted a while back?  My vague recollection
>> was a number more on the order of a quarter of that, and with most of
>> those being quite small (such as libsystemd-daemon0, which counts as a
>> package but which has an installed size of 72KB).

> Here's what I get when replacing sysvinit-core with systemd-sysv in my
> pbuilder chroot:

Thanks, Sven.  Yeah, that's more on the order of what I expected, and is
rather less than 100 packages.

> ,
> | The following NEW packages will be installed:
> |   acl{a} (D: systemd)  adduser{a} (D: systemd)  dmsetup{a} (D: 
> libdevmapper1.02.1)  
> |   libcap2-bin{a} (D: systemd)  libcryptsetup4{a} (D: systemd)  
> |   libdbus-1-3{a} (P: systemd, D: systemd)  
> |   libdevmapper1.02.1{a} (D: dmsetup, D: libcryptsetup4)  
> |   libgcrypt11{a} (P: systemd, D: libsystemd-journal0)  
> |   libgcrypt20{a} (D: libcryptsetup4)  
> |   libgpg-error0{a} (D: libcryptsetup4, D: libgcrypt11, D: libgcrypt20)  
> |   libkmod2{a} (D: systemd, D: udev)  libprocps3{a} (D: procps)  
> |   libsystemd-daemon0{a} (P: systemd)  libsystemd-journal0{a} (D: systemd)  
> |   libsystemd-login0{a} (D: systemd)  
> |   libudev1{a} (D: libdevmapper1.02.1, D: systemd, D: udev)  
> |   libwrap0{a} (D: systemd)  procps{a} (D: udev)  
> |   systemd{a} (P: systemd-sysv, D: systemd-sysv)  systemd-sysv  
> |   udev{a} (D: systemd)  
> | The following packages will be REMOVED:
> |   sysvinit-core  
> | The following packages are RECOMMENDED but will NOT be installed:
> |   dbus (R: libdbus-1-3)  libpam-cap (R: libcap2-bin)  libpam-systemd (R: 
> systemd)  
> |   psmisc (R: initscripts, R: procps)  tcpd (R: libwrap0)  
> | 0 packages upgraded, 21 newly installed, 1 to remove and 0 not upgraded.
> | Need to get 0 B/4436 kB of archives. After unpacking 18.1 MB will be used.
> `

Note also that a few of those things (udev, adduser, and
libdevmapper1.02.1 for example) are likely to be on any non-chroot system
already since they're either dependencies of other things (such as grub
for libdevmapper1.02.1) or are already in use regardless of the init
system (udev).  So for the case of a small embedded system that's
nonetheless running the full kernel + bootloader stack, I suspect the
delta is even smaller.

-- 
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/8761h066vq@hope.eyrie.org

Bug#760615: general: Shell scripts do not execute in gui.

[Tomas Pospisek]

Hello Kenji,

On 6.9.2014 Kenji Takashima wrote:

I have been trying to execute multiple shell scripts in gui with no 
avail. The scripts succesfully executed in a terminal, however in the 
gui, the files would not execute when clicked on, and, when 
right-clicked, did not have a "run" option. Other types of executables 
have worked, though I have not tested that many.


In my GUI scripts *can* be executed by double clicking! But maybe 
my "GUI" is not the same as your GUI? That's why o it would be good if you 
could tell us, what "GUI" that GUI of yours is? What is the name of the 
programm/application, in which you are trying to execute the script?


My GUI is XFCE and in XFCE I open the "Thunar" file browser. I double- 
click a script in Thunar, but nothing happens. That is because usually 
scripts write to the "standard out" channel. If you do not run a script in 
a terminal, then it does not have a "standard out" channel. That's why 
you will not seem anything happen when the script is executed.


In order to veryfiy that Thunar actually *does* execute a script when I 
double-click it I did the following, which you can do as well:


Open a terminal and in the terminal write the following:

cd /tmp
echo "#!/bin/sh" > foobar
echo "touch foobar.touched" >> foobar
chmod +x foobar

Now doublecklick that script. Has the file "foobar.touched" been created 
on your machine?


Greets,
*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/alpine.DEB.2.02.1409062051060.29858@hier

Bug#760683: ITP: node-mocks-http -- Mock 'http' objects for testing Express routing functions

[Joseph Bisch]

Package: wnpp
Severity: wishlist
Owner: Joseph Bisch 
X-Debbugs-CC: debian-devel@lists.debian.org

* Package name: node-node-mocks-http
  Version : 1.0.4
  Upstream Author : Howard Abrams  
(http://www.github.com/howardabrams)
* URL : http://www.github.com/howardabrams/node-mocks-http
* License : Expat
  Programming Lang: JavaScript
  Description : Mock 'http' objects for testing Express routing functions
 
 Mock 'http' objects for testing Express routing functions, but could be
 used for testing any Node.js web server applications that have code
 that requires mockups of the request and response objects.


signature.asc
Description: Digital signature

rename source package

[Jerome BENOIT]

Hello List,

I filled an ITA for guava [1]. Because it is rather a GAP package then a stand 
alone software,
it would make more sense to rename it gap-guava: how can I rename its source 
from guava to gap-guava ?
Note that the deb ball associated to it is already named gap-guava.

Thanks in advance,
Jerome



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


-- 
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/540b6d14.9070...@rezozer.net

Bug#760685: ITP: r-cran-cubature -- GNU R package for multivariate integration

[Dirk Eddelbuettel]

Package: wnpp
Owner: Dirk Eddelbuettel 
Severity: wishlist

* Package name: r-cran-cubature
  Version : 1.1-2-1
  Upstream Author : Balasubramanian Narasimhan and Steven G. Johnson
* URL or Web page : http://cran.r-project.org/web/packages/cubature/index.html
* License : GPL (>= 2)
  Description : GNU R package for multivariate integration

This is a new Build-Depends: of the existing package r-cran-fmultivar (aka
fMultivar on CRAN) which has been in Debian for many years.

The package is straightforward and just contains a few GPL-2'ed C files plus
an R wrapper.

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/87zjecxxsd@max.nulle.part

Bug#760615: marked as done (general: Shell scripts do not execute in gui.)

[Debian Bug Tracking System]

Your message dated Sat, 6 Sep 2014 23:45:58 +0200
with message-id <201409062346.06031.hol...@layer-acht.org>
and subject line Re: Bug#760615: general: Shell scripts do not execute in gui.
has caused the Debian Bug report #760615,
regarding general: Shell scripts do not execute in gui.
to be marked as done.

This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.

(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact ow...@bugs.debian.org
immediately.)


-- 
760615: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=760615
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems
--- Begin Message ---
Package: general
Severity: important

Dear Maintainer,

I have been trying to execute multiple shell scripts in gui with no avail. The
scripts succesfully executed in a terminal, however in the gui, the files would
not execute when clicked on, and, when right-clicked, did not have a "run"
option. Other types of executables have worked, though I have not tested that
many.

Thanks,

Kenji Takashima



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

Kernel: Linux 3.14-2-amd64 (SMP w/8 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
--- End Message ---
--- Begin Message ---
Hi,

On Samstag, 6. September 2014, Tomas Pospisek wrote:
> In my GUI scripts *can* be executed by double clicking!

:)

This is definitly not a general bug in Debian, thus closing. 
http://lists.debian.org/debian-user/ is the right forum for user support.


cheers,
Holger


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

Bug#760687: ITP: node-webkitgtk -- Drive webkitgtk from Node.js

[Jérémy Lal]

Package: wnpp
Severity: wishlist
Owner: "Jérémy Lal" 

* Package name: node-webkitgtk
  Version : 0.0.5
  Upstream Author : Jérémy Lal 
* URL : https://github.com/kapouer/node-webkitgtk
* License : Expat
  Programming Lang: C++, JavaScript
  Description : Drive webkitgtk from Node.js

 High-level abstraction for webkitgtk bindings.
 This module allows one to load a url into a WebView, run arbitrary
 javascript, listen for ready, load, request, response events,
 cancel requests, get responses data, and supports html, png, pdf
 output.

I am upstream of this package and plan on using it for at least three
capital services at my work.
It provides similar functionnality to phantomjs, with probably
much less options - but also without the dependency on qt, and
with a much cleaner integration as a debian package.
It is going to be pkg-javascript team-maintained.


-- 
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/20140906220638.597.18897.reportbug@imac.localdomain

Re: There should not be dependencies on systemd (Was: Cinnamon environment now available in testing)

[Marco d'Itri]

On Sep 06, Noel Torres  wrote:

> It is just wrong to have dependencies on the init system.
> If you need dbus, you should Depend on dbus, and systemd should 
> Provides dbus.
This is why most of these dependencies are on libpam-systemd, which does 
not depend on systemd.

As usual, people complain about perceived systemd problems that have 
already been solved.

-- 
ciao,
Marco


signature.asc
Description: Digital signature

Re: systemd, again (Re: Cinnamon environment now available in testing)

[Marco d'Itri]

On Sep 06, Sven Joachim  wrote:

> Here's what I get when replacing sysvinit-core with systemd-sysv in my
> pbuilder chroot:
To be fair, most of these packages (adduser, kmod, udev and their 
dependencies, for a start) would be installed anyway on a normal system 
which is not a minimal chroot.
If you ignore these then you are left with pretty much only the dmsetup 
and cryptsetup-related packages, which are quite common as well.

A good but slightly dated analisys is available at 
https://people.debian.org/~stapelberg/docs/systemd-dependencies.html .

-- 
ciao,
Marco


signature.asc
Description: Digital signature

Re: systemd, again

[gregor herrmann]

On Sun, 07 Sep 2014 00:03:29 +0200, Marco d'Itri wrote:

> On Sep 06, Sven Joachim  wrote:
> > Here's what I get when replacing sysvinit-core with systemd-sysv in my
> > pbuilder chroot:
> To be fair, most of these packages (adduser, kmod, udev and their 
> dependencies, for a start) would be installed anyway on a normal system 
> which is not a minimal chroot.
> If you ignore these then you are left with pretty much only the dmsetup 
> and cryptsetup-related packages, which are quite common as well.

Since I was curious I looked on my laptop:

# aptitude -s install systemd-sysv
The following NEW packages will be installed:
  systemd{a} systemd-sysv{b} 
The following packages are RECOMMENDED but will NOT be installed:
  libpam-systemd 
0 packages upgraded, 2 newly installed, 0 to remove and 7 not upgraded.
Need to get 1358 kB of archives. After unpacking 6129 kB will be used.
[..]

Seems quite un-intrusive indeed, dependency-wise.


Cheers,
gregor

-- 
 .''`.  Homepage: http://info.comodo.priv.at/ - OpenPGP key 0xBB3A68018649AA06
 : :' : Debian GNU/Linux user, admin, and developer  -  http://www.debian.org/
 `. `'  Member of VIBE!AT & SPI, fellow of the Free Software Foundation Europe
   `-   NP: Bettina Wegner: 's brennt!


signature.asc
Description: Digital Signature

Re: There should not be dependencies on systemd (Was: Cinnamon environment now available in testing)

[Guillem Jover]

On Sun, 2014-09-07 at 00:05:59 +0200, Marco d'Itri wrote:
> On Sep 06, Noel Torres  wrote:
> > It is just wrong to have dependencies on the init system.
> > If you need dbus, you should Depend on dbus, and systemd should 
> > Provides dbus.

> This is why most of these dependencies are on libpam-systemd, which does 
> not depend on systemd.

That's incorrect:

$ apt-cache show libpam-systemd | egrep '^(Version|Depends):'
Version: 214-1
Depends: libc6 (>= 2.17), libcap2 (>= 2.10), libpam0g (>= 0.99.7.1),
  systemd (= 214-1), libpam-runtime (>= 1.0.1-6), dbus,
  systemd-sysv | systemd-shim (>= 6-4)
Version: 208-8
Depends: libc6 (>= 2.14), libcap2 (>= 1:2.10), libdbus-1-3 (>= 1.0.2),
  libpam0g (>= 0.99.7.1), systemd (= 208-8), libpam-runtime (>= 1.0.1-6),
  dbus, systemd-sysv | systemd-shim (>= 6-4)

> As usual, people complain about perceived systemd problems that have 
> already been solved.

…

Regards,
Guillem


-- 
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/20140907002033.ga8...@gaara.hadrons.org

Re: Standardizing the layout of git packaging repositories

[Brian May]

On 28 August 2014 00:41, Paulo Tomé  wrote:

> rebasing is not an option for any branch that is published, and is very
>> ride to your downstream developers. if git-dpm requires that model of
>> software development, one would have to consider it unsuitable for non
>> trivial package development. I certainly hope that is not the case.
>>
>> I second that.
>
> See this mail from Linus Torvals mostly related with Git Rebase -
> http://www.mail-archive.com/dri-devel@lists.sourceforge.net/msg39091.html


I completely missed these emails before, sorry. My time and ability to
reply is somewhat limited.

I think you really need to understand what dpm is doing.

Also git rebase is a very general purpose tool, with different purposes.

What Linus is talking about is using rebasing as a tool to recreate past
history in order to "clean it up" in some way. This is confusing to
everything else who is using that branch, because suddenly their work is
based on a non-existant not-supported branch.

However, with git-dpm, no branch is ever destroyed. Every branch is always
merged into the Debian branch. The Debian branch itself always heads in a
single forward direction and this branch is never rebased. Furthermore,
because this is a pseudo-standard, everything can expect this is what will
happen.

See http://git-dpm.alioth.debian.org/ for details.

I think this is different from gbp-pq, and maybe the concerns for rebasing
are valid for gbp-pq - if you push the branches directory.

In another email by Manoj Srivastava:

> That is really a matter of displaying history. The diagram
displays Git history, not the patches; when B21 is committed, > there is no
patch representing B12, however, that commit is still in /.git/objects
since it is a parent of the Node D3. This > is relevant when I am trying to
trying to bisect and understand history. git-debcherry has fewer commits
being carried around, > which makes it easier on my aging brain.

Sorry, I think you have this wrong. (also nitpick: B12 is a parent of D5,
not D3).

When you commit B21, you have to replace B12 in the git history (e.g. git
commit --amend). Otherwise, when the patches are exported, you will get
both B12 and B21 appearing as separate patches debian/patches in D6. dpm
has no way of knowing that B12 and B21 are part of the same patch and
should be merged.

Maybe your point that debcherry is better still stands - it appears to work
better with your concept of "feature branches", however I find it hard to
use your document to compare the two when it contains errors like this.
-- 
Brian May 

Re: There should not be dependencies on systemd (Was: Cinnamon environment now available in testing)

[Marco d'Itri]

On Sep 07, Guillem Jover  wrote:

> > This is why most of these dependencies are on libpam-systemd, which does 
> > not depend on systemd.
> That's incorrect:
What I meant was "does not depend on systemd being PID 1".
Are you happy now?

-- 
ciao,
Marco


signature.asc
Description: Digital signature

Re: There should not be dependencies on systemd (Was: Cinnamon environment now available in testing)

[James McCoy]

On Sun, Sep 07, 2014 at 02:20:33AM +0200, Guillem Jover wrote:
> On Sun, 2014-09-07 at 00:05:59 +0200, Marco d'Itri wrote:
> > On Sep 06, Noel Torres  wrote:
> > > It is just wrong to have dependencies on the init system.
> > > If you need dbus, you should Depend on dbus, and systemd should 
> > > Provides dbus.
> 
> > This is why most of these dependencies are on libpam-systemd, which does 
> > not depend on systemd.
> 
> That's incorrect:

No, it isn't.  It was just poorly worded.

> $ apt-cache show libpam-systemd | egrep '^(Version|Depends):'
> Version: 214-1
> Depends: libc6 (>= 2.17), libcap2 (>= 2.10), libpam0g (>= 0.99.7.1),
>   systemd (= 214-1), libpam-runtime (>= 1.0.1-6), dbus,
>   systemd-sysv | systemd-shim (>= 6-4)

While libpam-systemd does Depend on the systemd binary package, that
package does not enforce systemd as the init system.  The relevant
relationship there is the ORed “systemd-sysv | systemd-shim (>= 6-4)”.

Cheers,
-- 
James
GPG Key: 4096R/331BA3DB 2011-12-05 James McCoy 


-- 
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/20140907011959.gf26...@freya.jamessan.com

Re: Standardizing the layout of git packaging repositories

[Manoj Srivastava]

On Sun, Sep 07 2014, Brian May wrote:


> In another email by Manoj Srivastava:
>
>> That is really a matter of displaying history. The diagram
> displays Git history, not the patches; when B21 is committed, > there is no
> patch representing B12, however, that commit is still in /.git/objects
> since it is a parent of the Node D3. This > is relevant when I am trying to
> trying to bisect and understand history. git-debcherry has fewer commits
> being carried around, > which makes it easier on my aging brain.

> Sorry, I think you have this wrong. (also nitpick: B12 is a parent of D5,
> not D3).

I aplogize, I  I have not conveyed  what is happening correctly,
 and you are confused by my diagrams. I shall try to do better.

> When you commit B21, you have to replace B12 in the git history (e.g. git
> commit --amend). Otherwise, when the patches are exported, you will get
> both B12 and B21 appearing as separate patches debian/patches in D6. dpm
> has no way of knowing that B12 and B21 are part of the same patch and
> should be merged.

That is the outcome I want. 

I commit B1, and later, B2. git-dpm creates ephemeral branches,

| I commit | Ephemeral gbranch contains | Master contains |
|--++-|
| A1   | A10| D2  |
| B1   | A10, B11   | D3  |
| U2   | A11. B12   | D5  |

 At this point B11 ans A10 are gone, apart from living in .git/objects.

| I commit | Ephemeral gbranch contains | Master contains |
|--++-|
| B2   | A11, B12, B21  | D6  |

There are there nodes in the ephemeral branch, and three patches
 are produced -- Corresponding to A1, B1, and B2.

| I commit | Ephemeral gbranch contains | Master contains |
|--++-|
| A2   | A11, A21,  B13, B22| D7  |


Four commits on the feature branches, and the ephemeral branch
 contains 4 commits -- the older ephemeral branches continue to live in
 .git/objects, which bothers the purist in me,

> Maybe your point that debcherry is better still stands - it appears to work
> better with your concept of "feature branches", however I find it hard to
> use your document to compare the two when it contains errors like this.


I think the errors lie in documentation of what the diagram is
 and thus the incorrect interpretation, rather than the underlying
 analysis. I'll try do document better what the diagrams mean. Has this
 helped you understand what the document is trying to say?

manoj
-- 
The sooner all the animals are extinct, the sooner we'll find their
money. Ed Bluestone
Manoj Srivastava    
4096R/C5779A1C E37E 5EC5 2A01 DA25 AD20  05B6 CF48 9438 C577 9A1C


signature.asc
Description: PGP signature

Re: Standardizing the layout of git packaging repositories

[Scott Kitterman]

On September 6, 2014 11:30:11 PM EDT, Manoj Srivastava  
wrote:
>On Sun, Sep 07 2014, Brian May wrote:
>
>
>> In another email by Manoj Srivastava:
>>
>>> That is really a matter of displaying history. The diagram
>> displays Git history, not the patches; when B21 is committed, > there
>is no
>> patch representing B12, however, that commit is still in
>/.git/objects
>> since it is a parent of the Node D3. This > is relevant when I am
>trying to
>> trying to bisect and understand history. git-debcherry has fewer
>commits
>> being carried around, > which makes it easier on my aging brain.
>
>> Sorry, I think you have this wrong. (also nitpick: B12 is a parent of
>D5,
>> not D3).
>
>   I aplogize, I  I have not conveyed  what is happening correctly,
> and you are confused by my diagrams. I shall try to do better.
>
>> When you commit B21, you have to replace B12 in the git history (e.g.
>git
>> commit --amend). Otherwise, when the patches are exported, you will
>get
>> both B12 and B21 appearing as separate patches debian/patches in D6.
>dpm
>> has no way of knowing that B12 and B21 are part of the same patch and
>> should be merged.
>
>That is the outcome I want. 
>
>I commit B1, and later, B2. git-dpm creates ephemeral branches,
>
>| I commit | Ephemeral gbranch contains | Master contains |
>|--++-|
>| A1   | A10| D2  |
>| B1   | A10, B11   | D3  |
>| U2   | A11. B12   | D5  |
>
> At this point B11 ans A10 are gone, apart from living in .git/objects.
>
>| I commit | Ephemeral gbranch contains | Master contains |
>|--++-|
>| B2   | A11, B12, B21  | D6  |
>
>   There are there nodes in the ephemeral branch, and three patches
> are produced -- Corresponding to A1, B1, and B2.
>
>| I commit | Ephemeral gbranch contains | Master contains |
>|--++-|
>| A2   | A11, A21,  B13, B22| D7  |
>
>
>Four commits on the feature branches, and the ephemeral branch
> contains 4 commits -- the older ephemeral branches continue to live in
> .git/objects, which bothers the purist in me,
>
>> Maybe your point that debcherry is better still stands - it appears
>to work
>> better with your concept of "feature branches", however I find it
>hard to
>> use your document to compare the two when it contains errors like
>this.
>
>
>I think the errors lie in documentation of what the diagram is
> and thus the incorrect interpretation, rather than the underlying
> analysis. I'll try do document better what the diagrams mean. Has this
> helped you understand what the document is trying to say?

I'll confess up front that I'm a neophyte when it comes to git.  From what I 
can tell though we've been using git-dpm for feature branches in pkg-clamav and 
it seems to me to work fine. 

I'd be curious what you'd find if you had a look at the team repository for 
clamav to see if what we're doing matches your concept of feature branches? 

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/75eaebf4-07c4-4734-b124-f1d0c6a1b...@email.android.com

Re: Bug#760167: ITP: cligh -- Command-line interface to GitHub

[Paul Wise]

It was pointed out off-list that my mail could be considered harsh.
If so I apologise for this, I certainly didn't intend that.

On Sat, 2014-09-06 at 13:56 +0400, Dmitry Bogatov wrote:

> My reason was that I am noob, and it takes undefined amount of time for
> me to find out how to package new kind. If despite of it, it is still
> okay to ITP before any work done, I will.

I see.

> Well, now we have package and it's ITP. Would you be so kind to
> take a look at it?

I would be happy to look at, sponsor and use it. Please publish the
package on mentors.debian.net and file a RFS (Request for Sponsor):

https://mentors.debian.net/intro-maintainers

-- 
bye,
pabs

http://wiki.debian.org/PaulWise


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

Re: Standardizing the layout of git packaging repositories

[Manoj Srivastava]

On Sun, Sep 07 2014, Scott Kitterman wrote:

> On September 6, 2014 11:30:11 PM EDT, Manoj Srivastava  
> wrote:

> I'll confess up front that I'm a neophyte when it comes to git.  From
> what I can tell though we've been using git-dpm for feature branches
> in pkg-clamav and it seems to me to work fine.

Oh, it works mostly fine, with some finicky handling of the
 ephemeral patched branch. I must worry about checking out the patched
 branch, sherry picking commits to it, handling conflicts, rebasing,
 squashing, rearranging -- and I did all that for a while before I
 discovered git-debcherry, It got old fast. Perhaps it is my fault, my
 feature branches sometimes have slightly overlapping changes. I never
 ever want to muck with something merely to create serialized linear
 patches for packaging.

With git-debcherry I ignore ./debian/patches and ever needing to
 worry about what lives in it. I work with pure git feature branches,
 say:
  gitpkg-build HEAD upstream

and I am done. It creates the ./debian/patches directory while
 checking out the source, knows about pristine-tar, creates the source
 package, ssh's into my build virt (starting it as needed), builds it,
 runs lintian and piuparts checks, and stuff is there for me to install,
 test, sign, and upload. All the tags are done for me.

No twiddling with stuff for 3.0 (quilt). I am too lazy to ever
 want to deal with it.

> I'd be curious what you'd find if you had a look at the team
> repository for clamav to see if what we're doing matches your concept
> of feature branches?

I'll have a look once I get back in town.

manoj
-- 
The Golden Rule of Arts and Sciences: He who has the gold makes the
rules.
Manoj Srivastava    
4096R/C5779A1C E37E 5EC5 2A01 DA25 AD20  05B6 CF48 9438 C577 9A1C


signature.asc
Description: PGP signature

Re: calling maintainer scripts with a clean environment?

[Andreas Metzler]

Evgeni Golov  wrote:
["eatmydata apt-get upgrade" propagates to daemons re-started by
maintainerscripts ]
> While pimping invoke-rc.d sounds like a good idea (and should be done),
> I'd prefer the postrm pg_dump that is called from dbconfig-common not to
> be executed with eatmydata either. Or with something else that is
> preciously hidden in some LD_PRELEOAD.

> My examples were init-specific, yeah. But IMHO this should apply for
> everything called via maintainer scripts.

Hello,

I tend to disagree here. If I use

eatmydata apt-get upgrade

I will expect that *any* IO-intensive part of the upgrade process uses
eatmydata and not just dpkg.

OTOH I only do this for chroots, without any important data and
without running daemons.

cu Andreas
-- 
`What a good friend you are to him, Dr. Maturin. His other friends are
so grateful to you.'
`I sew his ears on from time to time, sure'


-- 
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/1e8tdb-3i4@argenau.downhill.at.eu.org

Re: systemd, again (Re: Cinnamon environment now available in testing)

[Andreas Metzler]

Zack Weinberg  wrote:
> Matthias Urlichs wrote:

>> I also expect the Jessie upgrade to switch to systemd. Because,
>> frankly and strictly IMHO, doing anything else makes no sense
>> whatsoever.

> This is exactly the thing I don't agree with.

> I think _new installs_ of Jessie should use systemd as init (by
> default, anyway), but _upgrades_ from Wheezy or prior should continue
> to use whatever it is they were using before the upgrade, until the
> administrator takes an additional positive action to convert to
> something else.  And I also think that "additional positive action"
[...]

Hello,

I think that is terrible idea, because it makes us release a system
that is lot less tested than it should be. If only fresh installs were
using our default init system this part would only get very limited
testing pre-freeze. The number of systems running testing or even
unstable is going to be a lot higher than the number of people doing
fresh installs from a d-i alpha or beta version.

cu Andreas
-- 
`What a good friend you are to him, Dr. Maturin. His other friends are
so grateful to you.'
`I sew his ears on from time to time, sure'


-- 
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/p59tdb-3i4@argenau.downhill.at.eu.org