Re: DEP-11 Metadata updates

[Pirate Praveen]

On 2016, സെപ്റ്റംബർ 16 10:02:30 AM IST, Paul Wise  wrote:
>The archive doesn't yet produce pdiffs for the DEP-11 Metadata,
>so a bug report against ftp.debian.org is the way to go.

Done.

http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=837975

-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.

Re: DEP-11 Metadata updates

[Paul Wise]

On Fri, Sep 16, 2016 at 6:10 AM, Sean Whitton wrote:

> Probably best to file a wishlist bug against apt.

The archive doesn't yet produce pdiffs for the DEP-11 Metadata,
so a bug report against ftp.debian.org is the way to go.

Also, some if it isn't text (icons) so those might need some new mechanism.

Also, the debug archive needs pdiff coverage (it already has debdeltas).

-- 
bye,
pabs

https://wiki.debian.org/PaulWise

Re: Debian does not have customers

[Ben Finney]

"Jeremy T. Bouse"  writes:

> I'll start off by saying I haven't read the whole thread and only
> caught this because of the subject line change.

I direct you to Russ's message in this thread that explains exactly why
“customer” is a misleading term for the relationship being discussed, and:

> I'd have to ask how many of you actually have worked in large
> enterprise environments? I've been working in both public and private
> sector enterprise environments and the term "customer" is quite often
> used to describe those whom we serve. Whether they are internal or
> external customers and whether or not there is any payment involved.
> The term merely means the consumer of the service we provide.

and please read Russ's message for why that *is* a reasonable
implication of “customer”, and is exactly why that's *not* the
relationship the Debian project has with Debian recipients.

> Having a long winded debate over the use of a term takes away from
> the ability of actually accomplishing anything so it is better served
> to move on and address the issue rather than be pedantic about
> definitions.

If the distinction were inconsequential I would agree. It's not
inconsequential, though, so that's why this is so valuable: it draws
attention to the false and misleading idea that the Debian Project has a
“customer” relationship with anyone.

-- 
 \  “I don't want to live peacefully with difficult realities, and |
  `\ I see no virtue in savoring excuses for avoiding a search for |
_o__)real answers.” —Paul Z. Myers, 2009-09-12 |
Ben Finney

Re: Debian does not have customers

[Jeremy T. Bouse]

On 9/15/2016 10:19 PM, The Wanderer wrote:
> On 2016-09-15 at 22:03, Ben Finney wrote:
>
>> The Wanderer  writes:
>>
>>> On 2016-09-15 at 21:26, Wookey wrote:
>>>
 I reckon a lot of us would be happier if you [Russ] (and Abou)
 used the term 'users', rather than 'customers'. I know I think
 that being a customer involves payment.
>>> That was exactly my point: that although many people (including
>>> me!) think that [the term “customer” entails payment from the
>>> customer], other people do not - and, IMO, refusing or otherwise
>>> failing to understand what they mean when they use the term that
>>> way is not helpful.
>> That's a point of disagreement, then. I think Russ's drawing
>> attention to the fact Debian does not have customers is helpful: it
>> clarifies the discussion and explicitly acknowledges a fact that may
>> have been ignored by the person using that term ambiguously.
>>
>> As Russ describes so eloquently, that ambiguity glosses an essential 
>> distinction the Debian Project has from other superficially similar 
>> entities people may be more familiar with.
>>
>> Ignoring that distinction is harmful to effective communication,
>> because it fosters an unachievable expectation. Effort to expose and
>> avoid that particular ambiguity is helpful because it dispels a false
>> expectation.
> I would agree with all of that.
>
> I simply maintain that to say that "we don't sell anything, therefore we
> don't have customers" (as is the original statement to which I
> responded) is to fail to effectively communicate, by failing to respond
> to the meaning of the term which the person who used it intended.
>
> That's not to say that we have to accept and adopt that intended
> meaning of that term; providing an explanation of why it is not suitable
> for Debian (perhaps by linking to an existing explanation, for which
> purpose Russ's own might be a candidate) could well be a more suitable
> option.
>
> To see people talking past each other because they're using different
> definitions of their words and aren't acknowledging that fact, however,
> is actively unpleasant for me. Russ _is_ acknowledging that fact, and
> may well be helping bring the difference into light for others; however,
> the original comment to which I responded did not seem to be doing so.
>
> (At this point, I don't think continuing this subthread any further is
> likely to be particularly helpful...)
I'll start off by saying I haven't read the whole thread and only
caught this because of the subject line change.

I'd have to ask how many of you actually have worked in large
enterprise environments? I've been working in both public and private
sector enterprise environments and the term "customer" is quite often
used to describe those whom we serve. Whether they are internal or
external customers and whether or not there is any payment involved. The
term merely means the consumer of the service we provide.

Having a long winded debate over the use of a term takes away from
the ability of actually accomplishing anything so it is better served to
move on and address the issue rather than be pedantic about definitions.

Re: Debian does not have customers

[The Wanderer]

On 2016-09-15 at 22:03, Ben Finney wrote:

> The Wanderer  writes:
> 
>> On 2016-09-15 at 21:26, Wookey wrote:
>> 
>>> I reckon a lot of us would be happier if you [Russ] (and Abou)
>>> used the term 'users', rather than 'customers'. I know I think
>>> that being a customer involves payment.
>> 
>> That was exactly my point: that although many people (including
>> me!) think that [the term “customer” entails payment from the
>> customer], other people do not - and, IMO, refusing or otherwise
>> failing to understand what they mean when they use the term that
>> way is not helpful.
> 
> That's a point of disagreement, then. I think Russ's drawing
> attention to the fact Debian does not have customers is helpful: it
> clarifies the discussion and explicitly acknowledges a fact that may
> have been ignored by the person using that term ambiguously.
> 
> As Russ describes so eloquently, that ambiguity glosses an essential 
> distinction the Debian Project has from other superficially similar 
> entities people may be more familiar with.
> 
> Ignoring that distinction is harmful to effective communication,
> because it fosters an unachievable expectation. Effort to expose and
> avoid that particular ambiguity is helpful because it dispels a false
> expectation.

I would agree with all of that.

I simply maintain that to say that "we don't sell anything, therefore we
don't have customers" (as is the original statement to which I
responded) is to fail to effectively communicate, by failing to respond
to the meaning of the term which the person who used it intended.

That's not to say that we have to accept and adopt that intended
meaning of that term; providing an explanation of why it is not suitable
for Debian (perhaps by linking to an existing explanation, for which
purpose Russ's own might be a candidate) could well be a more suitable
option.

To see people talking past each other because they're using different
definitions of their words and aren't acknowledging that fact, however,
is actively unpleasant for me. Russ _is_ acknowledging that fact, and
may well be helping bring the difference into light for others; however,
the original comment to which I responded did not seem to be doing so.

(At this point, I don't think continuing this subthread any further is
likely to be particularly helpful...)

-- 
   The Wanderer

The reasonable man adapts himself to the world; the unreasonable one
persists in trying to adapt the world to himself. Therefore all
progress depends on the unreasonable man. -- George Bernard Shaw



signature.asc
Description: OpenPGP digital signature

Debian does not have customers (was: Bug#837606: general: system freeze)

[Ben Finney]

The Wanderer  writes:

> On 2016-09-15 at 21:26, Wookey wrote:
>
> > I reckon a lot of us would be happier if you [Russ] (and Abou) used
> > the term 'users', rather than 'customers'. I know I think that being
> > a customer involves payment.
>
> That was exactly my point: that although many people (including me!)
> think that [the term “customer” entails payment from the customer],
> other people do not - and, IMO, refusing or otherwise failing to
> understand what they mean when they use the term that way is not
> helpful.

That's a point of disagreement, then. I think Russ's drawing attention
to the fact Debian does not have customers is helpful: it clarifies the
discussion and explicitly acknowledges a fact that may have been ignored
by the person using that term ambiguously.

As Russ describes so eloquently, that ambiguity glosses an essential
distinction the Debian Project has from other superficially similar
entities people may be more familiar with.

Ignoring that distinction is harmful to effective communication, because
it fosters an unachievable expectation. Effort to expose and avoid that
particular ambiguity is helpful because it dispels a false expectation.

-- 
 \ “Faith may be defined briefly as an illogical belief in the |
  `\  occurrence of the improbable.” —Henry L. Mencken |
_o__)  |
Ben Finney

Re: Bug#837606: general: system freeze

[The Wanderer]

On 2016-09-15 at 21:26, Wookey wrote:

> On 2016-09-15 18:04 -0700, Russ Allbery wrote:
> 
>> Debian is delightfully different.  We care about market share of 
>> *volunteers*, but we don't have to care (and indeed, I personally
>> don't care at all) about market share of *customers*.
> 
> Well put, but I reckon a lot of us would be happier if you (and
> Abou) used the term 'users', rather than 'customers'. I know I think
> that being a customer involves payment.

That was exactly my point: that although many people (including me!)
think that it does, other people do not - and, IMO, refusing or
otherwise failing to understand what they mean when they use the term
that way is not helpful.

There's a seed of a colorable argument otherwise in Russ's mail,
however, so I don't intend to push that terribly hard - especially not
given that the entire discussion would be at best arguably on-topic.

-- 
   The Wanderer

The reasonable man adapts himself to the world; the unreasonable one
persists in trying to adapt the world to himself. Therefore all
progress depends on the unreasonable man. -- George Bernard Shaw



signature.asc
Description: OpenPGP digital signature

Re: Bug#837606: general: system freeze

[Wookey]

On 2016-09-15 18:04 -0700, Russ Allbery wrote:

> Debian is delightfully different.  We care about market share of
> *volunteers*, but we don't have to care (and indeed, I personally don't
> care at all) about market share of *customers*.

Well put, but I reckon a lot of us would be happier if you (and Abou)
used the term 'users', rather than 'customers'. I know I think that
being a customer involves payment.

Anyway, to the point. Yes, please kill 'general' or at least its
reflection to debian-devel. It has seemed to me to be a tiresome
anacronism for a very long time. I have always assumed that it was
some very old BTS feature from when this was a much younger and
smaller project, that no-one could be bothered to tidy up.

I just ignore those mails now, after many years of noting that they
are largely useless bug reports barely worthy of the name, that
usually get promtly closed. Seems like a waste of everyone's time to
me.

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


signature.asc
Description: Digital signature

Re: Bug#837606: general: system freeze

[Russ Allbery]

The Wanderer  writes:
> On 2016-09-15 at 16:17, gregor herrmann wrote:

>> Debian can't lose customers because we have no customers because we're
>> not selling anything.

> This is a terminology difference.

It isn't for me.

For me, this is a very foundational and freeing concept.  Debian is not
participating in the giant obligation pressure game that you're referring
to.  Our users don't threaten us with withholding money.  We don't cajole
our customers into giving us money instead of someone else, or instead of
not spending it.  All of that rat race mechanic in which one is constantly
worrying about how one is perceived, whether other people will continue to
give one money, and whether one is losing "market share" does not apply in
the same sense to Debian.

Instead, we are a community of people building something *for ourselves*,
cooperatively.  If other people in the world want to use it, great!  If we
can help them use it, great!  Even better if we can attract them to
contribute.  And if they don't like it, great!  They can use something
else.  Or make it better.  They have free choice.  But they don't have
*control*.  They can't force us to make Debian something else because they
have lots of money, and we don't have to work on anything we don't want to
in order to keep customers.

> Others think of it in terms of the provision of any service, regardless
> of whether for compensation or not. For example, in my department at my
> workplace, the people in other parts of the organization to whom we
> provide computer support are called our (and our department's)
> "customers" - even though we don't charge them for the service.

But this is still the same type of thing, and it still doesn't apply to
Debian.  They're paying you to support them, although the money moves
indirectly and is subject to controls and rules set by other people.  But
you're not volunteers.  You are paid to serve the needs of customers.

Debian is a volunteer project.  We are not paid, nor bound, to serve the
needs of *anyone*.  We're doing this for ourselves, for each other.

There is so much fear and worry and careful public relations management in
the corporate world because everyone's jobs depend on the inflow of money
from people who have to be convinced to keep spending that money, and one
has to do all sorts of things one might not want to do, or agree with, in
exchange for maintaining those customers and that market share.

Debian is delightfully different.  We care about market share of
*volunteers*, but we don't have to care (and indeed, I personally don't
care at all) about market share of *customers*.  Someone choosing not to
use a commercial product threatens (in at least a small way) the continued
viability of that commercial product by withholding resources to pay all
the people working on it.  Someone choosing not to use Debian does not
threaten the viability of the Debian project.  We are a chosen community
who can continue building our distribution regardless of what the broader
world thinks of it.

This is a HUGE part of what the Debian project means to me.  It is far,
far more important than making any individual Debian user happy.  It's
what makes working on the project a fun and delightful hobby, as opposed
to a tedious, unpaid job.  So I get quite defensive about attempts to
introduce that sort of existential pressure and hostage-taking that comes
from serving "customers" or worrying about "market share."

> I think the key elements might be something like "we are offering
> something which we want them to accept, and they are relying on that
> offer".

But I *don't* want them to accept it.  That's the whole point.  I don't
care at all whether they accept it or not.  It's a gift, given freely to
the world, for anyone to take or leave as they choose.  And, most
importantly, it is in no way an ongoing *obligation* on me to make it fit
for their purpose.  If I take on that sort of obligation, I expect to be
paid in a conventional employee or contracting relationship, to compensate
for my loss of control over my priorities and the requirement to do a lot
of unenjoyable, tedious work to achieve things I don't care about at all.

When I do volunteer work in my free time, I am not bound by any of those
restrictions.  That's *why* I do it.

-- 
Russ Allbery (r...@debian.org)   

Work-needing packages report for Sep 16, 2016

[wnpp]

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

Total number of orphaned packages: 929 (new: 6)
Total number of packages offered up for adoption: 144 (new: 1)
Total number of packages requested help for: 49 (new: 0)

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



The following packages have been orphaned:

   gtick (#837460), orphaned 4 days ago
 Description: Metronome application
 Installations reported by Popcon: 543

   libapache-htpasswd-perl (#837522), orphaned 3 days ago
 Description: Manage Unix crypt-style password file
 Installations reported by Popcon: 203

   libfcgi (#837523), orphaned 3 days ago
 Description: Header files of FastCGI
 Reverse Depends: bosixnet-webui cgi-mapserver fcgiwrap hyperestraier
   iipimage-server libfcgi-bin libfcgi-dev libopenjpip-server
   libqgis-server2.14.6 libwt-dev (13 more omitted)
 Installations reported by Popcon: 5231

   libnoise (#837954), orphaned today
 Description: Portable, coherent noise-generating library for C++
 Reverse Depends: libnoise-dev
 Installations reported by Popcon: 31

   naturaldocs (#837958), orphaned today
 Description: extensible, multi-language documentation generator
 Installations reported by Popcon: 67

   smlnj (#837735), orphaned yesterday
 Description: Standard ML of New Jersey interactive compiler
 Reverse Depends: libckit-smlnj libcml-smlnj libcmlutil-smlnj
   libexene-smlnj libmlnlffi-smlnj libmlrisctools-smlnj
   libpgraphutil-smlnj libsmlnj-smlnj ml-burg ml-lex (5 more omitted)
 Installations reported by Popcon: 204

923 older packages have been omitted from this listing, see
http://www.debian.org/devel/wnpp/orphaned for a complete list.



The following packages have been given up for adoption:

   xautolock (#837785), offered yesterday
 Description: Program launcher for idle X sessions
 Installations reported by Popcon: 653

143 older packages have been omitted from this listing, see
http://www.debian.org/devel/wnpp/rfa_bypackage for a complete list.



For the following packages help is requested:

   athcool (#278442), requested 4342 days ago
 Description: Enable powersaving mode for Athlon/Duron processors
 Installations reported by Popcon: 23

   awstats (#755797), requested 785 days ago
 Description: powerful and featureful web server log analyzer
 Installations reported by Popcon: 4120

   balsa (#642906), requested 1817 days ago
 Description: An e-mail client for GNOME
 Reverse Depends: balsa-dbg
 Installations reported by Popcon: 700

   cardstories (#624100), requested 1970 days ago
 Description: Find out a card using a sentence made up by another
   player
 Installations reported by Popcon: 8

   courier (#823807), requested 129 days ago
 Description: Courier mail server
 Reverse Depends: courier-faxmail courier-filter-perl courier-imap
   courier-imap-ssl courier-ldap courier-mlm courier-mta
   courier-mta-ssl courier-pcp courier-pop (7 more omitted)
 Installations reported by Popcon: 2176

   cups (#532097), requested 2658 days ago
 Description: Common UNIX Printing System
 Reverse Depends: bluez-cups boomaga chromium
   cinnamon-settings-daemon cloudprint cups cups-backend-bjnp
   cups-browsed cups-bsd cups-client (62 more omitted)
 Installations reported by Popcon: 168093

   cyrus-sasl2 (#799864), requested 358 days ago
 Description: authentication abstraction library
 Reverse Depends: 389-ds-base 389-ds-base-libs 389-dsgw adcli
   autofs-ldap cairo-dock-mail-plug-in claws-mail
   claws-mail-acpi-notifier claws-mail-address-keeper
   claws-mail-archiver-plugin (127 more omitted)
 Installations reported by Popcon: 187999

   dee (#831388), requested 62 days ago
 Description: model to synchronize mutiple instances over DBus
 Reverse Depends: dee-tools gir1.2-dee-1.0 libdee-1.0-4-dbg
   libdee-dev zeitgeist-core
 Installations reported by Popcon: 61478

   developers-reference (#759995), requested 747 days ago
 Description: guidelines and information for Debian developers
 Installations reported by Popcon: 18381

   devscripts (#800413), requested 352 days ago
 Description: scripts to make the life of a Debian Package maintainer
   easier
 Reverse Depends: apt-build apt-listdifferences aptfs arriero
   bzr-builddeb customdeb debci debian-builder debmake debpear (26 more
   omitted)
 Installations reported by Popcon: 12769

   ejabberd (#767874), requested 682 days ago
 Description: distributed, fault-tolerant Jabber/XMPP server 

Re: Adding version constraints in dependencies to avoid bugs

[Russ Allbery]

Santiago Vila  writes:

> I was the one who asked for these build-depends to become versioned.

> My rationale for that is in policy when it says that "it must be
> possible to build the package when the build-dependencies are met".

> If this is not the case it may be argued that the source package is
> buggy even if we do not experience the problem ourselves in testing.

Yes, there was definitely a bug.  The bug was then fixed... in the
dependency.  So now there's no longer a bug.  :)

I don't think it's the best reading of Policy to say that a package must
guarantee that none of its build dependencies are buggy in a way that
would prevent the package from being built.  This would require a lot of
awkward work, and somewhat more to the point, people *aren't* doing this
and historically *haven't* done this, so it's not a meaningful invariant
for the distribution.

In general, I recommend not worrying too much about any bug state that
occurred transiently during the development of a new stable release and
was resolved later in that same development process.  I think we can
assume that people running testing or unstable will regularly upgrade
packages and, if they hold packages at old versions that aren't in stable,
will expect some breakage from doing so.  (It's different if the breakage
was in a stable release, although even there it's better to fix the bug in
the actually broken package and then expect stable users to apply
updates.)

We make strong guarantees about stable as a coherent distribution; we do
not make such guarantees about any frozen moment of testing, let alone
unstable.

> After all, Debian-derived distros like Ubuntu, for example, could
> inherit this bug from us if they fork unstable and not testing.

If they do that, they will have to deal with problems like this.  Comes
with the territory.

-- 
Russ Allbery (r...@debian.org)   

Re: Adding version constraints in dependencies to avoid bugs

[Russ Allbery]

Thomas Goirand  writes:

> Someone is insisting that I should set the minimum version of
> python-openssl in my packages, just to avoid the bug of pyopenssl. I
> replied that if we were to do so in Debian, the work would be
> exponential, and that this is not what we should do: the bug in
> pyopenssl has been fixed (in a record time, I should also mention), and
> it is my opinion that there's no work required on my package that depend
> on python-openssl.

> Am I right that I should do nothing on my packages, or should we
> *really* modify about 54 source packages just to avoid a bug in one of
> the dependencies? What if we have a bug on a high profile package with
> hundreds of reverse dependencies?

My policy on my packages is to default to not updating any dependencies
for pure bugs in the other package.  Bugs in dependencies make packages
temporarily unusable all the time for all sorts of reasons.  If we added
version dependencies for all of them, we'd have an unmaintainable disaster
of tangled version restrictions.

The exception is when the bug is in stable and won't be fixed in stable,
if it causes serious upgrade issues that could result in apt giving up on
an upgrade instead of finding the correct solution, or if the bug breaks
the package in some invisible but dangerous way (data loss, for instance).
In those cases, I might consider a versioned dependency to as an aid.  But
I think it's something to use judiciously.

-- 
Russ Allbery (r...@debian.org)   

Re: Bug#837606: general: system freeze

[The Wanderer]

On 2016-09-15 at 16:17, gregor herrmann wrote:

> On Thu, 15 Sep 2016 16:58:03 +0200, Abou Al Montacir wrote:

>> We don't care to loose customers because of an issue faced by
>> someone,
> 
> Debian can't lose customers because we have no customers because 
> we're not selling anything.

This is a terminology difference.

Some people think of "customers" only in context of buying and selling,
including the selling of services.

Others think of it in terms of the provision of any service, regardless
of whether for compensation or not. For example, in my department at my
workplace, the people in other parts of the organization to whom we
provide computer support are called our (and our department's)
"customers" - even though we don't charge them for the service.

I think the key elements might be something like "we are offering
something which we want them to accept, and they are relying on that
offer". That doesn't quite sum it up perfectly (it doesn't account or
the fact that, as I understand this broader sense of the word, one could
argue that e.g. a DD who uploads a package that needs validation through
the NEW queue is a customer of the ftpmasters), but it's as close as
I've managed to come thus far.

> As a consequence I still think that unspecific "bug reports" to 
> 'general' don't achieve more than frustrating both the reporter and 
> the subscribers of debian-devel, and that we should try to find 
> alternative ways for channeling such support requests.

Albeit (for reasons I can't seem to pin down into verbal form) somewhat
reluctantly, I have to agree with this.

-- 
   The Wanderer

The reasonable man adapts himself to the world; the unreasonable one
persists in trying to adapt the world to himself. Therefore all
progress depends on the unreasonable man. -- George Bernard Shaw



signature.asc
Description: OpenPGP digital signature

Re: Adding version constraints in dependencies to avoid bugs

[Santiago Vila]

On Thu, Sep 15, 2016 at 06:04:54PM -0400, Scott Kitterman wrote:

> I think it would be simpler and more correct for python-cryptography to 
> declare a breaks relationship with python-openssl, e.g. (in the binary 
> control 
> stanza for python-cryptography):
> 
> Breaks: python-openssl (<< FIRST_NOT_BROKEN_VERSION~)
> 
> That should ensure python-openssl is upgraded with python-cryptography 
> without 
> having to touch an entire stack of rdepends.

Hello.

I was the one who asked for these build-depends to become versioned.

My rationale for that is in policy when it says that "it must be
possible to build the package when the build-dependencies are met".

If this is not the case it may be argued that the source package is
buggy even if we do not experience the problem ourselves in testing.

After all, Debian-derived distros like Ubuntu, for example, could
inherit this bug from us if they fork unstable and not testing.

Your proposed solution, Scott, seems indeed a lot better than updating
the build-depends of a bunch of packages, and it makes the policy
requirement to be met in a different way, namely, by not allowing
the affected packages to be built with build-dependencies which are
known to be incompatible.

Thomas: Would you take care of filing whatever bug is necessary for
this solution to be implemented?

Thanks a lot.

Re: DEP-11 Metadata updates

[Sean Whitton]

Hello Pirate,

On Thu, Sep 15, 2016 at 01:54:27PM +0530, Pirate Praveen wrote:
> I have noticed DEP-11 Metadata gets downloaded in full every time I run
> an apt-get update? Does it change so often? Can this be changed to
> download only the diffs like other index files?

Probably best to file a wishlist bug against apt.

-- 
Sean Whitton

Re: Adding version constraints in dependencies to avoid bugs

[Scott Kitterman]

On Thursday, September 15, 2016 11:50:33 PM Thomas Goirand wrote:
> Hi everyone,
> 
> Recently, the upload python-cryptography broke pyopenssl, and pyopenssl
> had to be upgraded to support the new python-cryptography (I don't have
> the exact details, but it doesn't mater much here...).
> 
> Someone is insisting that I should set the minimum version of
> python-openssl in my packages, just to avoid the bug of pyopenssl. I
> replied that if we were to do so in Debian, the work would be
> exponential, and that this is not what we should do: the bug in
> pyopenssl has been fixed (in a record time, I should also mention), and
> it is my opinion that there's no work required on my package that depend
> on python-openssl.
> 
> Am I right that I should do nothing on my packages, or should we
> *really* modify about 54 source packages just to avoid a bug in one of
> the dependencies? What if we have a bug on a high profile package with
> hundreds of reverse dependencies?
> 
> Moreover, all versions of pyopenssl are perfectly working with these
> packages. It's just if you don't select well the couple python-openssl +
> python-cryptograhy that there's such an issue. Pushing a higher version
> may potentially add work for backporting to stable (and I maintain the
> backports of 9 of these 54 packages, btw).
> 
> What's the view of my Debian buddies here?
> 
> Cheers,
> 
> Thomas Goirand (zigo)
> 
> P.S: For those not into python stuff, of course, pyopenssl is the source
> package for python-openssl...

I think it would be simpler and more correct for python-cryptography to 
declare a breaks relationship with python-openssl, e.g. (in the binary control 
stanza for python-cryptography):

Breaks: python-openssl (<< FIRST_NOT_BROKEN_VERSION~)

That should ensure python-openssl is upgraded with python-cryptography without 
having to touch an entire stack of rdepends.

Scott K

Adding version constraints in dependencies to avoid bugs

[Thomas Goirand]

Hi everyone,

Recently, the upload python-cryptography broke pyopenssl, and pyopenssl
had to be upgraded to support the new python-cryptography (I don't have
the exact details, but it doesn't mater much here...).

Someone is insisting that I should set the minimum version of
python-openssl in my packages, just to avoid the bug of pyopenssl. I
replied that if we were to do so in Debian, the work would be
exponential, and that this is not what we should do: the bug in
pyopenssl has been fixed (in a record time, I should also mention), and
it is my opinion that there's no work required on my package that depend
on python-openssl.

Am I right that I should do nothing on my packages, or should we
*really* modify about 54 source packages just to avoid a bug in one of
the dependencies? What if we have a bug on a high profile package with
hundreds of reverse dependencies?

Moreover, all versions of pyopenssl are perfectly working with these
packages. It's just if you don't select well the couple python-openssl +
python-cryptograhy that there's such an issue. Pushing a higher version
may potentially add work for backporting to stable (and I maintain the
backports of 9 of these 54 packages, btw).

What's the view of my Debian buddies here?

Cheers,

Thomas Goirand (zigo)

P.S: For those not into python stuff, of course, pyopenssl is the source
package for python-openssl...

Re: The (uncalled for) toolchain maintainers roll call for stretch

[Helge Deller]

Hi Matthias,

On 10.09.2016 00:48, Matthias Klose wrote:
> While the Debian Release team has some citation about the quality of the
> toolchain on their status page, it is not one of the release criteria 
> documented
> by the release team.  I'd like to document the status how I do understand it 
> for
> some of the toolchains available in Debian.

> Java/OpenJDK
> 
> 
> For the stretch release openjdk-8 will be fine as the default java
> implementation.  For buster, gcj (to be removed in GCC 7) won't be available
> anymore, and we'll end up with architectures without a java implementation.  
> At
> the same time I'd like to consider to stop providing OpenJDK zero builds,
> leaving powerpc and mips* without a java implementation as well (currently not
> building for openjdk-9).  armhf (not armel) and s390x have Hotspot ports 
> underway.

Can you explain the reason why you consider stopping OpenJDK zero builds?

I'm asking, because on hppa we currently use gcj and we don't have any OpenJDK 
port yet.
My hope was to fix at some point in future the old existing OpenJDK zero port 
patches to get some newer
JDK even if it's slower. With your intention to stop zero builds, we probably 
won't have any
JDK at all...

Thanks,
Helge

Bug#837953: ITP: dh-r -- Debhelper support for R packages

[Gordon Ball]

Package: wnpp
Severity: wishlist
Owner: Gordon Ball 

* Package name: dh-r
  Version : 20160901
  Upstream Author : Gordon Ball 
* URL : 
https://anonscm.debian.org/git/debian-science/packages/dh-r.git
* License : MIT
  Programming Lang: Perl, R
  Description : Debhelper support for R packages

This is a debhelper buildsystem for R packages, and a script
to generate debian/ skeletons for new R packages.

It will be maintained within the debian-science team.

Re: Bug#837606: general: system freeze

[gregor herrmann]

On Thu, 15 Sep 2016 16:58:03 +0200, Abou Al Montacir wrote:

> In my case, when I get such a report for my package, I start instructing the
> user to gather more information. 

Right, me too.
But "general" is not a package but a catchall category where mails
get distributed to thousands of subscribers to debian-devel; and
with no information beyond "my system freezes" noone can feel
responsible for doing further bug triaging.

> We don't care to loose
> customers because of an issue faced by someone, 

Debian can't lose customers because we have no customers because
we're not selling anything.

And I'm not claiming that Debian is perfect -- far from it, and I'm
times and again frustrated over what I personally and what we as a
project could do more and better. But we all have to acknowledge the
limitations that we as a volunteer project face in practice -- Russ
has explained this aspect much better than I could.

As a consequence I still think that unspecific "bug reports" to
'general' don't achieve more than frustrating both the reporter and
the subscribers of debian-devel, and that we should try to find
alternative ways for channeling such support requests.


Cheers,
gregor

-- 
 .''`.  Homepage https://info.comodo.priv.at/ - OpenPGP key 0xBB3A68018649AA06
 : :' : Debian GNU/Linux user, admin, and developer -  https://www.debian.org/
 `. `'  Member of VIBE!AT & SPI, fellow of the Free Software Foundation Europe
   `-   NP: Billy Joel: In The Middle Of The Night


signature.asc
Description: Digital Signature

Re: Exception for shipping shared libraries compiled with -fPIC for multiple packages

[Raoul Borenius]

Hello all,

On Wed, Sep 14, 2016 at 01:02:02AM +0200, Balint Reczey wrote:
> Dear People of Debian-Devel,
> 
> Current Policy (3.9.8.0) mandates discussion on debian-devel@d.o
> before changing packages to ship static libraries compiled with -fPIC:
> 
> ---
> 10.2 Libraries
> ... (paragraph about shared libs)
 
> I am hereby asking for exceptions for the following packages:
> 
>   Bug  Package Title
> #586572 libdpkg-dev   libdpkg-dev: Please provide a libdpkg 
> shared library
> #712228 src:ghc   Hardening flag -pie breaks compilation 
> with GHC
> #804254 publib-devpublib-dev: please build libpub.a with 
> -fPIC
> #837350 src:binutils  binutils: Please build libbfd.a with 
> -fPIC
> #837359 src:ocaml ocaml: Please build libasmrun.a and 
> libcamlrun.a with -fPIC
> #837363 src:cpputest  cpputest: Please build libCppUTest.a 
> with -fPIC
> #837417 src:ctn   ctn: Please build libctn.a with -fPIC
> #837423 src:jack-audio-connection-kit jack-audio-connection-kit: Please build 
> libjack.a with -fPIC
> #837424 src:portaudio19   portaudio19: Please build 
> libportaudio.a with -fPIC
> #837434 src:binpacbinpac: Please build libbinpac.a with 
> -fPIC
> #837445 src:check check: Please build libcheck.a with 
> -fPIC
> #837452 src:simgear   simgear: Please build libSimGearCore.a 
> and libSimGearScene.a with -fPIC
> #837489 src:antlr antlr: Please build libantlr.a with 
> -fPIC
> #837490 src:libpapyrus3-dev   libpapyrus3-dev: Please build 
> libPapyrus3.a with -fPIC
> #837491 src:libgadap-dev  libgadap-dev: Please build libgadap.a 
> with -fPIC

I would like to add

#837400 src:i2utillibi2util-dev: Please build libI2util.a 
with -fPIC

to the list.

Thanks,

 Raoul

Re: Bug#837606: general: system freeze

[Russ Allbery]

The Wanderer  writes:

> I suspect that he feels that closing a bug report without having first
> tried to address it equals pretending that the problem reported in the
> bug report does not exist, and thus, represents an attempt to hide the
> fact that the problem does exist.

Okay.  Well, I think this is just obviously incorrect, so I suppose we're
at an impasse.  But thank you for the explanation!

-- 
Russ Allbery (r...@debian.org)   

Re: Bug#837606: general: system freeze

[Abou Al Montacir]

Thanks The Wanderer,

You explained it better that I can ever do! It is a perception problem at the
first plane.
-- 
Cheers,
Abou Al Montacir

On Thu, 2016-09-15 at 13:39 -0400, The Wanderer wrote:
> On 2016-09-15 at 13:24, Russ Allbery wrote:
> 
> 
> 
> > > Abou Al Montacir  writes:
> 
> > 
> 
> >> Does improve distribution means hiding issues? I don't think it
> 
> >> is.
> 
> > 
> 
> > You keep using this term, but I have no idea what you mean by it.
> 
> > What information do you feel like we're hiding?
> 
> 
> 
> I suspect that he feels that closing a bug report without having first
> 
> tried to address it equals pretending that the problem reported in the
> 
> bug report does not exist, and thus, represents an attempt to hide the
> 
> fact that the problem does exist.
> 
> 
> 
> Given all the surrounding facts (some of which you've cited, quite
> 
> validly, in this thread), I'm not sure he's right, but - at least from
> 
> the outside, and as a general matter - the perception does seem to be a
> 
> reasonable one. Which only means that this represents a potential PR
> 
> problem, albeit perhaps a minor one.


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

Re: Bug#837606: general: system freeze

[The Wanderer]

On 2016-09-15 at 13:24, Russ Allbery wrote:

> Abou Al Montacir  writes:
> 
>> Does improve distribution means hiding issues? I don't think it
>> is.
> 
> You keep using this term, but I have no idea what you mean by it.
> What information do you feel like we're hiding?

I suspect that he feels that closing a bug report without having first
tried to address it equals pretending that the problem reported in the
bug report does not exist, and thus, represents an attempt to hide the
fact that the problem does exist.

Given all the surrounding facts (some of which you've cited, quite
validly, in this thread), I'm not sure he's right, but - at least from
the outside, and as a general matter - the perception does seem to be a
reasonable one. Which only means that this represents a potential PR
problem, albeit perhaps a minor one.

> Not listing that line item in a bug page basically no one looks at
> isn't "hiding information" in any meaningful sense that I can see.

In the perspective involved, it would be an attempt to hide the fact
that the problem was reported, and therefore that the problem apparently
existed.

> Basically, you're attributing to the Debian project considerably
> more resources, expertise, data management, bug classification, and
> analysis capabilities than we actually have, and then (apparently)
> getting angry and frustrated that we we're (from your perspective)
> somehow withholding those capabilities from this bug specifically.
> But that's not what's happening at all!  We have only a tiny fraction
> of the resources that you seem to think we have, and we're just
> trying to be explicit about what we can and can't do rather than
> having people's bug reports quietly disappear with no response.

I suspect that, from his perspective, closing the bug report _makes_
that report "disappear with no response" - or, at least, that it makes
it do so to a greater extent than leaving it open with no answer would
do.

"Bug report filed, remains open indefinitely with no response" comes
across as "no one cares", true - but "bug report filed, closed without
attempting to fix" comes across as rejection of the report, and
therefore, of the idea that the report represents a valid problem. It's
easy to see how the latter is a stronger negative than the former.
(Also, the former can more easily lead to "existing bug report
discovered, attempt is now made to fix it" or to "existing bug report
discovered, further information added which may be useful for a fix"
than can the latter.)


Which is probably to say that eliminating, or at the least reworking,
the 'general' package as a target for bug reports would probably be an
improvement if done properly. I'm not terribly fond of it as an idea at
first glance, but the logic behind it does seem fairly strong.

-- 
   The Wanderer

The reasonable man adapts himself to the world; the unreasonable one
persists in trying to adapt the world to himself. Therefore all
progress depends on the unreasonable man. -- George Bernard Shaw



signature.asc
Description: OpenPGP digital signature

Re: Bug#837606: general: system freeze

[Russ Allbery]

Abou Al Montacir  writes:

> Does improve distribution means hiding issues? I don't think it is.

You keep using this term, but I have no idea what you mean by it.  What
information do you feel like we're hiding?

Maybe you feel like closing a bug is always wrong unless the problem is
fully resolved?  That's a philosophy about bugs that, I'm afraid, is only
possible for small projects or projects with vast bug triage teams.  (If
you peruse the numerous articles on-line about backlog grooming, you'll
find that not closing unactionable bugs is widely considered a huge
*problem*, and experts in project management spend a lot of time telling
people to be much more aggressive about closing bugs than they want to
be.)

"My Debian system froze" is not useful information for anyone,
unfortunately, without a lot of additional work put into the problem.  You
say that you don't know how to do that work; I'm completely sympathetic,
since frequently I don't either.  However, not knowing doesn't change
anything about the situation, nor does it mean someone else is responsible
for helping you or I debug such problems.  That's just how volunteer
projects work.

Not listing that line item in a bug page basically no one looks at isn't
"hiding information" in any meaningful sense that I can see.

Basically, you're attributing to the Debian project considerably more
resources, expertise, data management, bug classification, and analysis
capabilities than we actually have, and then (apparently) getting angry
and frustrated that we we're (from your perspective) somehow withholding
those capabilities from this bug specifically.  But that's not what's
happening at all!  We have only a tiny fraction of the resources that you
seem to think we have, and we're just trying to be explicit about what we
can and can't do rather than having people's bug reports quietly disappear
with no response.

-- 
Russ Allbery (r...@debian.org)   

Re: Bug#837606: general: system freeze

[Abou Al Montacir]

On Wed, 2016-09-14 at 12:51 -0700, Russ Allbery wrote:
> > Abou Al Montacir  writes:
> 
> > Because you think people will not be frustrated if they experience a bug
> > and that we prevent them to raise bugs? Hiding reality is always
> > bad?. Look at the original reporter last message. He seems quite
> > disappointed by the project reaction. He should feel as we don't care
> > about our users. I personally sometimes feel the same.
> 
> However, this is unavoidable for that sort of bug report.  As much as
> anyone might like the situation to be different, Debian is not going to be
> able to act on a bug report with that little information complaining about
> a whole-system problem.  All that would happen if we didn't close the bug
> is that it would just be ignored forever, which I think is even worse.
There are little information because the guy reporting the bug, or the other one
suffering from it (me) does not know how to debug such a bug.

In my case, when I get such a report for my package, I start instructing the
user to gather more information. Later, if the user does not help I wait maybe
other users see the bug and help reproducing. If after several months none react
then I tag it and close it. If it happens someone reopen it I'm glad again to
hunt it.
> 
This is the reality of a volunteer project with limited time for triage of
bugs that haven't been traced technically to the faulty component.
Sometimes (rarely) someone will have the free time and desire to do that
tracing, but that can happen as easily (or more easily) on debian-user,
and isn't how we use the bug system.
bug system is meant to track issues, not to debug them. If an issue is there it
should appear, especially in an open source project. We don't care to loose
customers because of an issue faced by someone, but we are transparent enough to
tell users that someone discovered that and they may fall in it.
> 
Debian's bug system is a tool we use to improve the distribution, not a
user support channel.  We should not retain bugs that do not help us
achieve that.  It would be great if it could also be a user support
channel, but this is just unachievable for a volunteer-maintained
distribution like Debian, and we should avoid creating the impression that
we promise to do this.
Does improve distribution means hiding issues? I don't think it is.
-- 
Cheers,
Abou Al Montacir


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

Re: Bug#837606: general: system freeze

[Abou Al Montacir]

Hi Joël,

On Wed, 2016-09-14 at 15:38 +0200, Joël Krähemann wrote:
> Hi
> 
> reproducing the critical parts in a unit test would be helpful
> 
> Something like in the attachment.
> 
> install dependencies:
> 
> apt-get install libcunit1-dev
> 
> Compile with
> > gcc -g -o mutex_fail_test mutex_fail_test.c `pkg-config --cflags --libs 
> > cunit`
-pthread
> 
> launch
> ./mutex_fail_test
> 
> 
Thanks for that,

Here are the results:
$gcc -g -o mutex_fail_test mutex_fail_test.c `pkg-config --cflags --libs cunit`
-pthread
$./mutex_fail_test


 CUnit - A unit testing framework for C - Version 2.1-3
 http://cunit.sourceforge.net/


Suite: MutexFailTest
  Test: test of pthread_mutex_lock concurrently with unassigned pointer
...Segmentation fault

-- 
Cheers,
Abou Al Montacir



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

Bug#837921: ITP: emacs-deferred -- simple asynchronous functions and higher level library for concurrent tasks

[Lev Lamberov]

Package: wnpp
Severity: wishlist
Owner: Lev Lamberov 

* Package name: emacs-deferred
  Version : 0.4.0
  Upstream Author : Masashi Sakurai 
* URL : https://github.com/kiwanami/emacs-deferred
* License : GPL-3+
  Programming Lang: Emacs Lisp
  Description : simple asynchronous functions and higher level library for 
concurrent tasks

Contains two packages, deferred.el and concurrent.el

deferred.el:
It is a simple library for asynchronous tasks. The API is almost the same as
JSDeferred (by cho45) and  Mochikit.Async (by Bob Ippolito) in JavaScript.

concurrent.el:
It is a higher level library for concurrent tasks  based on deferred.el. This
library has following features:

 - Generator
 - Green thread
 - Semaphore
 - Dataflow
 - Signal/Channel

Bug#837913: ITP: qubes-utils -- Common Qubes utils for dom0 and VMs

[Holger Levsen]

Package: wnpp
Severity: wishlist
Owner: Holger Levsen 

* Package name: qubes-utils
  Upstream Author : Marek Marczykowski 
* URL : https://github.com/QubesOS/qubes-linux-utils.git
* License : GPL2+
  Programming Lang: C / several
  Description : Common Qubes utils for dom0 and VMs

Qubes OS is a security-oriented operating system (OS). The main principle
of Qubes OS is security by compartmentalization (or isolation), in which
activities are compartmentalized (or isolated) in separate qubes.

Virtualization is performed by Xen, and user environments can be based on
Fedora, Debian, Whonix, and Microsoft Windows, among other operating systems.

This package contains the common Qubes utils for dom0 and VMs.



For more information on Qubes, see
https://www.qubes-os.org/tour/#what-is-qubes-os

For more information on this packaging effort, see
https://wiki.debian.org/Qubes/Devel

-- 
cheers,
Holger


signature.asc
Description: Digital signature

Bug#837910: ITP: qubes-gui-daemon -- Qubes GUI daemon

[Holger Levsen]

Package: wnpp
Severity: wishlist
Owner: Holger Levsen 

* Package name: qubes-gui-daemon
  Upstream Author : Joanna Rutkowska 
* URL : https://github.com/QubesOS/qubes-gui-daemon.git
* License : GPL2+
  Programming Lang: C
  Description : Qubes GUI daemon

Qubes OS is a security-oriented operating system (OS). The main principle
of Qubes OS is security by compartmentalization (or isolation), in which
activities are compartmentalized (or isolated) in separate qubes.

Virtualization is performed by Xen, and user environments can be based on
Fedora, Debian, Whonix, and Microsoft Windows, among other operating systems.

This package contains the GUI daemon running on dom0.



For more information on Qubes, see
https://www.qubes-os.org/tour/#what-is-qubes-os

For more information on this packaging effort, see
https://wiki.debian.org/Qubes/Devel

-- 
cheers,
Holger


signature.asc
Description: Digital signature

Bug#837908: ITP: qubes-gui-common -- Common files for Qubes GUI - protocol headers

[Holger Levsen]

Package: wnpp
Severity: wishlist
Owner: Holger Levsen 

* Package name: qubes-gui-common
* Upstream Author : Joanna Rutkowska 
Rafal Wojtczuk  
Marek Marczykowski 
* URL : https://github.com/QubesOS/qubes-gui-common.git
* License : GPL2+
  Programming Lang: C
  Description : Common files for Qubes GUI - protocol headers

Qubes OS is a security-oriented operating system (OS). The main principle
of Qubes OS is security by compartmentalization (or isolation), in which
activities are compartmentalized (or isolated) in separate qubes.

Virtualization is performed by Xen, and user environments can be based on
Fedora, Debian, Whonix, and Microsoft Windows, among other operating systems.

This package contains the protocol description headers for Qubes GUI, needed
on both dom0 and the VMs.



For more information on Qubes, see
https://www.qubes-os.org/tour/#what-is-qubes-os

For more information on this packaging effort, see
https://wiki.debian.org/Qubes/Devel

-- 
cheers,
Holger


signature.asc
Description: Digital signature

Bug#837906: ITP: qubes-gui-agent -- Qubes GUI Agent for VMs

[Holger Levsen]

Package: wnpp
Severity: wishlist
Owner: Holger Levsen 

* Package name: qubes-gui-agent
  Upstream Author : Joanna Rutkowska 
* URL : https://github.com/QubesOS/qubes-gui-agent-linux.git
* License : GPL2+
  Programming Lang: C
  Description : Qubes GUI Agent for VMs

Qubes OS is a security-oriented operating system (OS). The main principle
of Qubes OS is security by compartmentalization (or isolation), in which
activities are compartmentalized (or isolated) in separate qubes.

Virtualization is performed by Xen, and user environments can be based on
Fedora, Debian, Whonix, and Microsoft Windows, among other operating systems.

This package contains the Qubes GUI agent that needs to be installed in VMs
in order to provide the Qubes manager GUI.



For more information on Qubes, see
https://www.qubes-os.org/tour/#what-is-qubes-os

For more information on this packaging effort, see
https://wiki.debian.org/Qubes/Devel

-- 
cheers,
Holger


signature.asc
Description: Digital signature

Bug#837905: ITP: libvchan-xen-qubes -- Qubes vchan libraries

[Holger Levsen]

Package: wnpp
Severity: wishlist
Owner: Holger Levsen 

* Package name: libvchan-xen-qubes
  Upstream Author : Joanna Rutkowska 
Rafal Wojtczuk  
Marek Marczykowski 
* URL : https://github.com/QubesOS/qubes-core-vchan-xen.git
* License : GPL2+
  Programming Lang: C
  Description : Qubes vchan libraries

Qubes OS is a security-oriented operating system (OS). The main principle
of Qubes OS is security by compartmentalization (or isolation), in which
activities are compartmentalized (or isolated) in separate qubes.

Virtualization is performed by Xen, and user environments can be based on
Fedora, Debian, Whonix, and Microsoft Windows, among other operating systems.

This package contains the Qubes vchan communication libraries for Dom0 and VMs.



For more information on Qubes, see
https://www.qubes-os.org/tour/#what-is-qubes-os

For more information on this packaging effort, see
https://wiki.debian.org/Qubes/Devel

-- 
cheers,
Holger


signature.asc
Description: Digital signature

Bug#837903: ITP: qubes-db -- Qubes OS database and tools

[Holger Levsen]

Package: wnpp
Severity: wishlist
Owner: Holger Levsen 

* Package name: qubes-db
  Upstream Author : Marek Marczykowski 
* URL : https://github.com/QubesOS/qubes-core-qubesdb.git
* License : GPL2+
  Programming Lang: C
  Description : Qubes OS database and tools

Qubes OS is a security-oriented operating system (OS). The main principle
of Qubes OS is security by compartmentalization (or isolation), in which
activities are compartmentalized (or isolated) in separate qubes.

Virtualization is performed by Xen, and user environments can be based on
Fedora, Debian, Whonix, and Microsoft Windows, among other operating systems.

This package contains the Qubes OS database and tools running on dom0 and the 
VMs.



For more information on Qubes, see
https://www.qubes-os.org/tour/#what-is-qubes-os

For more information on this packaging effort, see
https://wiki.debian.org/Qubes/Devel

-- 
cheers,
Holger


signature.asc
Description: Digital signature

Bug#837902: ITP: qubes-core-agent -- The Qubes core files for VMs

[Holger Levsen]

Package: wnpp
Severity: wishlist
Owner: Holger Levsen 

* Package name: qubes-core-agent
  Upstream Author : Joanna Rutkowska 
Rafal Wojtczuk  
* URL : https://github.com/QubesOS/qubes-core-agent-linux.git
* License : GPL2+
  Programming Lang: several
  Description : The Qubes core files for VMs

Qubes OS is a security-oriented operating system (OS). The main principle
of Qubes OS is security by compartmentalization (or isolation), in which
activities are compartmentalized (or isolated) in separate qubes.

Virtualization is performed by Xen, and user environments can be based on
Fedora, Debian, Whonix, and Microsoft Windows, among other operating systems.

This package contains the core-agent functionality running on VMs.



For more information on Qubes, see
https://www.qubes-os.org/tour/#what-is-qubes-os

For more information on this packaging effort, see
https://wiki.debian.org/Qubes/Devel

-- 
cheers,
Holger


signature.asc
Description: Digital signature

Bug#837900: ITP: qubes-core-admin-linux -- Linux-specific files for Qubes dom0

[Holger Levsen]

Package: wnpp
Severity: wishlist
Owner: Holger Levsen 

* Package name: qubes-core-admin-linux
  Upstream Author : Marek Marczykowski  
* URL : https://github.com/QubesOS/qubes-core-admin-linux.git
* License : GPL2+
  Programming Lang: several
  Description : Linux-specific files for Qubes dom0

Qubes OS is a security-oriented operating system (OS). The main principle
of Qubes OS is security by compartmentalization (or isolation), in which
activities are compartmentalized (or isolated) in separate qubes.

Virtualization is performed by Xen, and user environments can be based on
Fedora, Debian, Whonix, and Microsoft Windows, among other operating systems.

This package contains the linux specific core-admin functionality running on
dom0.


For more information on Qubes, see
https://www.qubes-os.org/tour/#what-is-qubes-os

For more information on this packaging effort, see
https://wiki.debian.org/Qubes/Devel

-- 
cheers,
Holger


signature.asc
Description: Digital signature

Re: Support for merged-/usr now in debootstrap; default for stretch?

[Marco d'Itri]

On Sep 14, Felipe Sateler  wrote:

> I agree that merging /usr is a good thing to do. We should default to 
> that, and at some point force the merge somehow (via the usrmerge package?
To be fair, I have implemented this as a switch only because I expected 
that somebody would have complained about the lack of an opt-out 
mechanism.
Since merged-/usr has significant benefits and is the scheme used 
RHEL/Centos/Fedora I think that it should be the default for us as well.

-- 
ciao,
Marco


signature.asc
Description: PGP signature

Re: Support for merged-/usr now in debootstrap; default for stretch?

[Marco d'Itri]

On Sep 15, Adam Borowski  wrote:

> I think it would be worthwhile to split up and move parts of /var as well. 
This is out of scope for this thread, so please let's discuss your 
proposals at a different time.

-- 
ciao,
Marco


signature.asc
Description: PGP signature

Bug#837896: ITP: qubes-core-admin -- The Qubes core files (Dom0-side)

[Holger Levsen]

Package: wnpp
Severity: wishlist
Owner: Holger Levsen 

* Package name: qubes-core-admin
  Upstream Author : Joanna Rutkowska 
Rafal Wojtczuk  
* URL : https://github.com/QubesOS/qubes-core-admin.git
* License : GPL2+
  Programming Lang: Python
  Description : The Qubes core files (Dom0-side)

Qubes OS is a security-oriented operating system (OS). The main principle 
of Qubes OS is security by compartmentalization (or isolation), in which
activities are compartmentalized (or isolated) in separate qubes.

Virtualization is performed by Xen, and user environments can be based on
Fedora, Debian, Whonix, and Microsoft Windows, among other operating systems.

This package contains the core-admin functionality running on dom0.



For more information on Qubes, see
https://www.qubes-os.org/tour/#what-is-qubes-os

For more information on this packaging effort, see
https://wiki.debian.org/Qubes/Devel

-- 
cheers,
Holger


signature.asc
Description: Digital signature

Re: Bug#837606: general: system freeze

[Vincent Lefevre]

On 2016-09-15 10:10:23 +0200, Abou Al Montacir wrote:
> That is very similar to the issue I'm experiencing. However I can
> reproduce this 100% when opening a page on linkedIn using epiphany
> browser.

Then I think that you should give strace information + system logs.

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Re: Use and abuse of the unreproducible tag

[Santiago Vila]

On Thu, Sep 15, 2016 at 09:05:50AM +0200, Andreas Tille wrote:
> On Wed, Sep 14, 2016 at 02:01:15PM +0100, Santiago Vila wrote:
> > On Wed, Sep 14, 2016 at 01:00:46PM +0200, Andreas Tille wrote:
> > >a) more friendly
> > 
> > Please check the facts. The "initial email" which started this
> 
> Please do
> 
> s/initial email/first email read by the majority of readers/

I reread your message and that was really the original meaning, I just
missed the word "here" in your previous email. Sorry for that.

Yes, maybe.

Bug#837891: ITP: elpa-ctable -- table component for Emacs Lisp

[Lev Lamberov]

Package: wnpp
Severity: wishlist
Owner: Lev Lamberov 

* Package name: elpa-ctable
  Version : 0.1.2
  Upstream Author : Masashi Sakurai 
* URL : https://github.com/kiwanami/emacs-ctable
* License : GPL-3+
  Programming Lang: Emacs Lisp
  Description : table component for Emacs Lisp

Table component for Emacs Lisp. Emacs Lisp programs can display a nice table
view from an abstract data model. Many Emacs programs have the code for
displaying table views, such as dired, list-process, buffer-list and so on.
This package provides functions and a table framework for the table views.

DEP-11 Metadata updates

[Pirate Praveen]

Hi,

I have noticed DEP-11 Metadata gets downloaded in full every time I run
an apt-get update? Does it change so often? Can this be changed to
download only the diffs like other index files?

Get:6 http://debian.sil.at/debian sid/main amd64 DEP-11 Metadata [2,873
kB]
0% [6 Components-amd64 1,579 kB/2,873 kB 55%]19.2 kB/s
6min 57s

Especially on a small connection, even with apt-cacher-ng, it takes a
long time to download.

Thanks
Praveen



signature.asc
Description: OpenPGP digital signature

Re: Bug#837606: general: system freeze

[Abou Al Montacir]

Hi Adam,
On Thu, 2016-09-15 at 04:07 +0200, Adam Borowski wrote:
> Even quite experienced people may have a hard time investigating a "system
> 
> freeze".
> 
> 
> 
> It just happens that I had two today; the system was working reliably before
> 
> with no unexplained crashes[1] at least in kernelly stuff.  Then out of a
> 
> sudden music gets stuck on a small buffer, screen freezes, no response
> 
> to anything, even no SysRq; ping worked for a short time then stopped. 
> 
> Half an hour later a repeat.  I've attached a serial console but it's
> 
> apparently a heisenbug -- no reproduces since.
That is very similar to the issue I'm experiencing. However I can reproduce this
100% when opening a page on linkedIn using epiphany browser.

I can send you the URL (privately), as I don't have serial port on my laptop.
But generally each time I try to accept someone's invitation or send an
invitation to someone, it happens. It works well with other browsers, but I do
prefer not changing my browser.
-- 
Cheers,
Abou Al Montacir



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

Bug#837888: ITP: libhpptools -- various C++ header tools

[Andreas Tille]

Package: wnpp
Severity: wishlist
Owner: Andreas Tille 

* Package name: libhpptools
  Version : 1.1.1
  Upstream Author : Matei David 
* URL : https://github.com/mateidavid/hpptools/
* License : expat
  Programming Lang: C++
  Description : various C++ header tools
 A collection of C++ (mostly, C++11) header-only utility libraries.
 .
  * thread-safe facility-based logging mechanism
  * ZLib wrapper
  * Collection of new and extended SL algorithms
  * Floating point additions in logarithmic space using table lookup
  * C++11-based parallel for, with optional output sorting
  * C++11-based thread pool


Remark: This header library is a precondition for some Debian Med
target (nanocall) and will be maintained at
   https://anonscm.debian.org/git/debian-med/libhpptools.git

Bug#837884: ITP: python-tmdbsimple -- Wrapper for The Movie Database API

[Michael Fladischer]

Package: wnpp
Severity: wishlist
Owner: Michael Fladischer 

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

* Package name: python-tmdbsimple
  Version : 1.4.0
  Upstream Author : Celia Oakley 
* URL : https://github.com/celiao/tmdbsimple/
* License : GPL-3+
  Programming Lang: Python
  Description : Wrapper for The Movie Database API

 tmdbsimple is a wrapper, written in Python, for The Movie Database (TMDb) API
 v3. By calling the functions available in tmdbsimple one can simplify their
 code and easily access a vast amount of movie, tv, and cast data.
 .
 Features:
  * One-to-one mapping between tmdbsimple functions and TMDb methods.
  * Implements all TMDb methods, including Accounts and Authentication.
  * Implements new TV features.
  * Easy to access data using Python class attributes.
  * Easy to experiment with tmdbsimple functions inside the Python interpreter.
 .
 An API key is required to interact with the API endpoint.

-BEGIN PGP SIGNATURE-

iQEuBAEBCgAYBQJX2kk7ERxmbGFkaUBkZWJpYW4ub3JnAAoJEP/TyIuZfdFqbjgI
ALGSTQ0X1dfJpl3PEtG1E6hjfGhE/W1hVRX8s954fkQ5Brq1SaXr9JdVzSaEuXB+
RHSN2XHm9A2ZmYmroS8IdzOB/MGgApCFI4SwWcxCUFlYvmm5IVNySebIY9DDhPuX
1g6QoyPP+5NXspP10gQeQC842aKOBD9VfAiA2EwUII+4vYBdyS0+jDDIyipGlVlv
3C7vMb0lYTxUGsHVOTdsnsQfYHKjiCSSL7crJrho0hFumItTkmlmJ8BlkcfYHLKx
9tl9XlI4eYG3J56i56jJyltXDYJa8bOg1U6cWffp+r8gza6Epv1eXuCcOxkceDKs
4R+8H0N+Db2xzZIdoLf6K/E=
=y2bL
-END PGP SIGNATURE-

Re: Use and abuse of the unreproducible tag

[Andreas Tille]

On Wed, Sep 14, 2016 at 02:01:15PM +0100, Santiago Vila wrote:
> On Wed, Sep 14, 2016 at 01:00:46PM +0200, Andreas Tille wrote:
> >a) more friendly
> 
> Please check the facts. The "initial email" which started this

Please do

s/initial email/first email read by the majority of readers/

Thanks for considering

 Andreas. 

-- 
http://fam-tille.de