Re: Reintroducing FFmpeg to Debian

[Thorsten Glaser]

On Thu, 28 Aug 2014, Vittorio Giovara wrote:

> On 17/08/2014 18:15, Clément Bœsch wrote:
> > > - you leeching my work by leveraging git merge daily
> > Welcome to the wonderful world of Open Source Luca.
> Sorry but no, definitely no.
> 
> While technically what ffmpeg does is allowed by the (L)GPL, it fundamentally
> goes against the spirit of Open Source. Open source is sharing a common goal,

No. You’re wrong.

The right to fork, and to continue importing from the forked work,
is fundamental to OSS.

bye,
//mirabilos
-- 
Sometimes they [people] care too much: pretty printers [and syntax highligh-
ting, d.A.] mechanically produce pretty output that accentuates irrelevant
detail in the program, which is as sensible as putting all the prepositions
in English text in bold font.   -- Rob Pike in "Notes on Programming in C"


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/alpine.deb.2.11.1408281225080.28...@tglase.lan.tarent.de

Re: Reverting to GNOME for jessie's default desktop

[Thorsten Glaser]

On Thu, 21 Aug 2014, Paul van der Vlis wrote:

> There is something called LLVMpipe, it's a software fallback when there

Hm, but LLVM is not available for all Debian (CPU) architectures.

bye,
//mirabilos (let’s make IceWM the default desktop and good is.)
-- 
[16:04:33] bkix: "veni vidi violini"
[16:04:45] bkix: "ich kam, sah und vergeigte"...


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/alpine.deb.2.11.1408281233310.28...@tglase.lan.tarent.de

Re: daemon user naming scheme

[Thorsten Glaser]

On Mon, 25 Aug 2014, Jerome BENOIT wrote:
> > On 25/08/14 16:53, Simon McVittie wrote:

> >> * Debian-foo
> >> * Dfoo

Uppercase may have problems dealing with eMail.
Sometimes, dæmon users may want that. I strongly suggest
to not use uppercase letters in usernames, system or not.

> >> I think I slightly prefer _foo, which originated in *BSD.
>
> Moreover, _foo is not accepted by adduser, the option --force-badname
> must be used.

This is probably good, because the chances of it conflicting
with admin-provided users are less, then.

(Personally preferring _foo as well, but then, I’m biased.)

bye,
//mirabilos
-- 
15:41⎜ Somebody write a testsuite for helloworld :-)


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/alpine.deb.2.11.1408281237160.28...@tglase.lan.tarent.de

Re: Help request: intel-microcode and old Intel processors

[Thorsten Glaser]

On Tue, 26 Aug 2014, Henrique de Moraes Holschuh wrote:

> If you happen to run Debian or Ubuntu on a computer with an old Intel
> processor (Pentium M, Celeron M, Pentium 4 Mobile, Mobile Celeron, Pentium

I’ve got an IBM X40. I can boot Grml off a USB stick, dist-upgrade
and run these commands, if that helps. (Maybe next time I’ll
reinstall, which is pending anyway, I’ll make space for a small
Debian partition.)

bye,
//mirabilos
-- 
15:41⎜ Somebody write a testsuite for helloworld :-)


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/alpine.deb.2.11.1408281239290.28...@tglase.lan.tarent.de

Re: Standardizing the layout of git packaging repositories

[Thorsten Glaser]

On Wed, 20 Aug 2014, Jeremy Stanley wrote:

> There still seems to be some legal contention around Apache License
> 2.0 expecting an authors list for a project. And I agree copyright

Not just that one, there are other licences with weird
terms like that.

> significant enough to amend the years/holders there (also in many
> cases the authors are not the copyright holders, but rather their
> employers are, so the authors list can be essentially irrelevant
> where copyright is concerned).

Depends. In German law, the individuals are still the copyright
owners, but their employers have the exclusive right to exercise
the exploitation rights, iff written under employment contract.
So this is highly legislation-dependent (and: whose legislation?
Author? Employer? Project lead? Distributor? Maintainer? etc.)…

bye,
//mirabilos
-- 
tarent solutions GmbH
Rochusstraße 2-4, D-53123 Bonn • http://www.tarent.de/
Tel: +49 228 54881-393 • Fax: +49 228 54881-235
HRB 5168 (AG Bonn) • USt-ID (VAT): DE122264941
Geschäftsführer: Dr. Stefan Barth, Kai Ebenrett, Boris Esser, Alexander Steeg


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/alpine.deb.2.11.1408281250340.28...@tglase.lan.tarent.de

logcheck rules for systemd

[Ondřej Surý]

Hey all,

I have started to collect logcheck/ignore.d.server/systemd rules for
systemd:

https://wiki.debian.org/systemd/logcheck

I think it might be a good idea to fine tune the rules before submitting
them
for inclusion into logcheck default ruleset...

O.
-- 
Ondřej Surý 
Knot DNS (https://www.knot-dns.cz/) – a high-performance DNS server


--
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/1409225828.1356518.157744133.5c919...@webmail.messagingengine.com

Bug#759549: ITP: libclipboard-perl -- Perl module to copy and paste from Perl code

[Salvatore Bonaccorso]

Package: wnpp
Owner: Salvatore Bonaccorso 
Severity: wishlist
X-Debbugs-CC: debian-devel@lists.debian.org,debian-p...@lists.debian.org

* Package name: libclipboard-perl
  Version : 0.13
  Upstream Author : Ryan King 
* URL : https://metacpan.org/release/Clipboard
* License : Artistic or GPL-1+
  Programming Lang: Perl
  Description : Perl module to copy and paste from Perl code

Clipboard is a module for accessing the system's clipboard. It allows
retrieval/setting and works under X, Windows and MacOS


-- 
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/1409226756.138498.2214@lorien

Re: logcheck rules for systemd

[Michael Biebl]

Am 28.08.2014 13:52, schrieb Chris Boot:
> On 28/08/14 12:37, Ondřej Surý wrote:
>> Hey all,
>>
>> I have started to collect logcheck/ignore.d.server/systemd rules for
>> systemd:
>>
>> https://wiki.debian.org/systemd/logcheck
>>
>> I think it might be a good idea to fine tune the rules before submitting
>> them
>> for inclusion into logcheck default ruleset...
> 
> Hi Ondřej,
> 
> You may find it easier to bundle the logcheck rules with systemd itself
> rather than as part of logcheck-database. Debhelper has a
> dh_installlogcheck tool that you may find useful. In my opinion,
> packaging the logcheck rules with the program that generates the log
> messages makes more sense, as the rules can be more easily kept up to
> date with the generating program.

I'm not sure if anyone in the systemd team is actively using logcheck, I
don't. So from my pov I'd prefer if it was maintained by someone who
actually does.

And do we really want to install those logcheck rules files (conffiles)
on everyones system, if only a small percentage of users actually
install logcheck.


Michael


-- 
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: logcheck rules for systemd

[Chris Boot]

On 28/08/14 12:37, Ondřej Surý wrote:
> Hey all,
> 
> I have started to collect logcheck/ignore.d.server/systemd rules for
> systemd:
> 
> https://wiki.debian.org/systemd/logcheck
> 
> I think it might be a good idea to fine tune the rules before submitting
> them
> for inclusion into logcheck default ruleset...

Hi Ondřej,

You may find it easier to bundle the logcheck rules with systemd itself
rather than as part of logcheck-database. Debhelper has a
dh_installlogcheck tool that you may find useful. In my opinion,
packaging the logcheck rules with the program that generates the log
messages makes more sense, as the rules can be more easily kept up to
date with the generating program.

HTH,
Chris

-- 
Chris Boot
deb...@bootc.net
GPG: 8467 53CB 1921 3142 C56D  C918 F5C8 3C05 D9CE 


-- 
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/53ff17f5.8010...@bootc.net

Re: logcheck rules for systemd

[Ondřej Surý]

On Thu, Aug 28, 2014, at 13:52, Chris Boot wrote:
> On 28/08/14 12:37, Ondřej Surý wrote:
> > Hey all,
> > 
> > I have started to collect logcheck/ignore.d.server/systemd rules for
> > systemd:
> > 
> > https://wiki.debian.org/systemd/logcheck
> > 
> > I think it might be a good idea to fine tune the rules before submitting
> > them
> > for inclusion into logcheck default ruleset...
> 
> Hi Ondřej,
> 
> You may find it easier to bundle the logcheck rules with systemd itself
> rather than as part of logcheck-database.

I don't care - that's up to the respective maintainers to decide.

But generally I concur with Michael - the systemd is a default init and
we probably don't want to ship the logcheck file from withing default
init package, so logcheck-database might be a better place.

I will be happy with collaboratively updated wiki page for the moment.

Ondrej
-- 
Ondřej Surý 
Knot DNS (https://www.knot-dns.cz/) – a high-performance DNS server


--
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/1409229013.1369405.157762653.1513a...@webmail.messagingengine.com

Re: logcheck rules for systemd

[Russ Allbery]

Michael Biebl  writes:
> Am 28.08.2014 13:52, schrieb Chris Boot:

>> You may find it easier to bundle the logcheck rules with systemd itself
>> rather than as part of logcheck-database. Debhelper has a
>> dh_installlogcheck tool that you may find useful. In my opinion,
>> packaging the logcheck rules with the program that generates the log
>> messages makes more sense, as the rules can be more easily kept up to
>> date with the generating program.

+1.  Usually this makes more sense.

> I'm not sure if anyone in the systemd team is actively using logcheck, I
> don't. So from my pov I'd prefer if it was maintained by someone who
> actually does.

I use logcheck, and I'm happy to submit wishlist bugs when things change
that I notice.  That still requires that you all apply new filter rules,
but hopefully that shouldn't be too much work.

> And do we really want to install those logcheck rules files (conffiles)
> on everyones system, if only a small percentage of users actually
> install logcheck.

Lots of other packages already do, and the logcheck maintainers had been
pushing that as best practices.  The files aren't particularly large.

-- 
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/87iolcismu@hope.eyrie.org

Re: logcheck rules for systemd

[Russ Allbery]

Ondřej Surý  writes:

> I have started to collect logcheck/ignore.d.server/systemd rules for
> systemd:

> https://wiki.debian.org/systemd/logcheck

> I think it might be a good idea to fine tune the rules before submitting
> them for inclusion into logcheck default ruleset...

Should we include rules that match lines like:

Aug 28 07:30:01 lothlorien systemd[1]: Starting Run anacron jobs...
Aug 28 07:30:01 lothlorien systemd[1]: Started Run anacron jobs.

or should those be in the anacron package / rule set?  I could see an
argument either way.

-- 
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/87d2bkiqpy@hope.eyrie.org

Re: Reverting to GNOME for jessie's default desktop

[Tollef Fog Heen]

]] Thorsten Glaser 

> On Thu, 21 Aug 2014, Paul van der Vlis wrote:
> 
> > There is something called LLVMpipe, it's a software fallback when there
> 
> Hm, but LLVM is not available for all Debian (CPU) architectures.

Given we're talking about jessie's default and it's available for all of
jessie's release architectures that should be fine.

-- 
Tollef Fog Heen
UNIX is user friendly, it's just picky about who its friends are


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/87wq9shaay@aexonyam.err.no

Re: Reverting to GNOME for jessie's default desktop

[Julien Cristau]

On Thu, Aug 28, 2014 at 18:02:29 +0200, Tollef Fog Heen wrote:

> ]] Thorsten Glaser 
> 
> > On Thu, 21 Aug 2014, Paul van der Vlis wrote:
> > 
> > > There is something called LLVMpipe, it's a software fallback when there
> > 
> > Hm, but LLVM is not available for all Debian (CPU) architectures.
> 
> Given we're talking about jessie's default and it's available for all of
> jessie's release architectures that should be fine.
> 
So far we only build llvmpipe on amd64 and i386 (both linux and
kfreebsd), though.  The other architectures get the old swrast driver.

Cheers,
Julien


signature.asc
Description: Digital signature

Bug#759570: ITP: crsx-java -- Higher Order Rewriting Engine with Extensions for Compiler Generation

[Kristoffer Rose]

Package: wnpp
Severity: wishlist
Owner: Kristoffer Rose 

* Package name: crsx-java
  Version : 3.1.0.1
  Upstream Author : Kristoffer Rose 
* URL : http://crsx.org/
* License : EPL-1.0
  Programming Lang: Java, C
  Description : Higher Order Rewriting Engine with Extensions for Compiler 
Generation

The purpose of CRSX is to implement an extended higher-order rewriting 
formalism to facilitate writing compilers
and other syntax-directed transformation systems, specifically:

* Special notations for using embedded syntax, even higher order abstract 
syntax.
* Special support for symbol tables, environments, and attributes, as used in 
compilers.
* A polymorphic sort system (which in practice means that CRSX systems are 
contraction schemes).
* CRSX systems can be compiled directly to native code (so far in C or Java 
(experimental)) for effective execution.

The system is used in IBM for production use and is the basis for the HACS 
compiler generator
used for teaching compilers at NYU by the author.


-- 
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/20140828034654.7850.94605.report...@krisx1.krisrose.net

Bug#759571: ITP: hacs -- Pedagogic Compiler Generator

[Kristoffer Rose]

Package: wnpp
Severity: wishlist
Owner: Kristoffer Rose 

* Package name: hacs
  Version : 0.9
  Upstream Author : Kristoffer Rose 
* URL : http://crsx.org/
* License : EPL-1.0
  Programming Lang: Java, C
  Description : Pedagogic Compiler Generator

High-Level Compiler Generator based on the
"Higher-order Attribute Contraction Schemes"
formalism based on the CRSX rewrite engine
combined with other tools.


-- 
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/20140828042311.8783.22821.report...@krisx1.krisrose.net

Bug#759578: ITP: google-cloud-sdk -- easily create and manage resources on Google Cloud

[Thomas Goirand]

Package: wnpp
Severity: wishlist
Owner: Thomas Goirand 

* Package name: google-cloud-sdk
  Version : 0.9.30+debian1
  Upstream Author : Google INC.
* URL : https://developers.google.com/cloud/sdk/
* License : Apache-2.0
  Programming Lang: Python
  Description : easily create and manage resources on Google Cloud

 Google Cloud SDK contains tools and libraries that enable you to easily create
 and manage resources on Google Cloud Platform, including App Engine, Compute
 Engine, Cloud Storage, BigQuery, Cloud SQL, and Cloud DNS.


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

Re: Standardizing the layout of git packaging repositories

[Manoj Srivastava]

On 08/26/2014 10:53 PM, Brian May wrote:

On 26 August 2014 16:12, Manoj Srivastava 
wrote:


http://people.debian.org/~srivasta/Serializing_Git_Branches.pdf has a
demonstration of the differences in history given an upstream and two
feature branches with two commits each, using git-dpm and git-debcherry.



Interesting review.

However, I think there might be some errors.

I don't think you should use normally be feature branches with git-dpm.
Rather you edit the commit directly (whether by rebase or --amend).


	As I have commented elsewhere in this thread, that restriction makes 
git-dpm a less viable alternative for complex packages.



Also I think there is an error in the way you have done the git-dpm, e.g.
when committing B21, you have added to the existing B12 patch instead of
replacing it. Similarly when adding A31, you haven't replaced A11.

	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.


   Manoj


--
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/53ff7a8d.5080...@golden-gryphon.com

Bug#759587: ITP: r-cran-rcmdrmisc -- GNU R Commander miscellaneous functions

[Dirk Eddelbuettel]

Package: wnpp
Owner: Dirk Eddelbuettel 
Severity: wishlist

* Package name: r-cran-rcmdrmisc
  Version : 1.0-1
  Upstream Author : John Fox
* URL or Web page : http://cran.r-project.org/web/packages/RcmdrMisc/index.html
* License : GPL (>= 2)
  Description : GNU R Commander miscellaneous functions

This is a new Build-Depends of, and spin-off from, the Rcmdr (== r-cran-rcmdr) 
GUI for R. Rcmdr has been in Debian for a decade, and is a pretty widely-used
beginner's GUI for R with the added advantage of being cross-platform.

This package added one Build-Depends of its own: the r-cran-e1071 package
which reached unstable today.  

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/8738cge8yb@max.nulle.part

Re: Help request: intel-microcode and old Intel processors

[Andrea Bolognani]

On Tue, Aug 26, 2014 at 03:49:06PM -0300, Henrique de Moraes Holschuh wrote:

> I'd like to know whether the kernel microcode update is working well on some
> of the older Intel 32-bit processors or not.  These computers were sold
> between years 2000 and 2010.
> 
> This information will be used to decide the level of microcode update
> support for these processors on the next non-free release (Jessie).

I have a couple of laptops that could probably qualify, but they're both
running Wheezy and I can't update them to testing / unstable.

Would running the above commands on Wheezy be of any help to you?

Have a nice day.

-- 
Andrea Bolognani 
Resistance is futile, you will be garbage collected.


signature.asc
Description: Digital signature

Bug#759598: ITP: moment.js -- lightweight Javascript date library

[Tim Retout]

Package: wnpp
Severity: wishlist
Owner: Tim Retout 

* Package name: moment.js
  Version : 2.8.1
  Upstream Author : Tim Wood, Iskren Chernev, others.
* URL : http://momentjs.com
* License : Expat
  Programming Lang: JavaScript
  Description : lightweight Javascript date library

 This library provides functions for parsing, validating, manipulating
 and displaying dates in Javascript.
 .
 It can be run in either a browser or a Node.js environment.

The actual package description will differ slightly depending on whether
it's libjs-moment or node-moment.

I will maintain this as part of the Javascript team.

It is an indirect dependency of Pump.io via node-emailjs, see:
https://wiki.debian.org/Javascript/Nodejs/Tasks/Pump.io

Moment.js has lots of downloads according to npm, and is a dependency of
many other Javascript libraries:
https://www.npmjs.org/package/moment


-- 
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/20140828205124.27746.9895.reportbug@thinkpad

raising an issue about static linking policy

[Salvo Tomaselli]

Hello,

I've recently packaged subsurface 4.2 for experimental, because it depends on 
libgit2 which is in experimental…

I think you might want to read these posts:
http://lists.hohndel.org/pipermail/subsurface/2014-August/014520.html
http://lists.hohndel.org/pipermail/subsurface/2014-August/014524.html


> And this is just one reason why distributions should not do the whole
> insane "dynamic linking only" strategy.

> Dynamic linking should be for core distro packages only. Not for random
> other stuff. That's *particularly* true for random oddball libraries (is
> libgit2 but also libdivecomputer or even things like libxml).

> The advantages of dynamic linking are totally negated by (a) versioning
> issues and (b) lack of wide sharing.

> Just look at what all external entities end up *having* to do (ie think
> valve etc). Debian should rethink its policies wrt dynamic libraries,
> because the current one is wrong for users, and wrong for developers.  But
> also wrong for purely technical reasons.

> Could someone involved with Debian please try to take this issue up? I'm
> fed up with how the kernel makes binary compatibility such a priority, only
> to have distributions throw all that sanity and effort away.

> Linus


I have no opinion on the topic at the moment, except that it is no ideal to 
have the new version stuck in experimental, but I thought it is worth to relay 
and have some discussion about this.

Best


-- 
Salvo Tomaselli

"Io non mi sento obbligato a credere che lo stesso Dio che ci ha dotato di
senso, ragione ed intelletto intendesse che noi ne facessimo a meno."
-- Galileo Galilei

http://ltworf.github.io/ltworf/


--
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/1574687.GHilZWckv4@hal9000

Re: raising an issue about static linking policy

[Reinhard Tartler]

On Thu, Aug 28, 2014 at 5:38 PM, Salvo Tomaselli  wrote:
> Hello,
>
> I've recently packaged subsurface 4.2 for experimental, because it depends on
> libgit2 which is in experimental…
>
> I think you might want to read these posts:
> http://lists.hohndel.org/pipermail/subsurface/2014-August/014520.html
> http://lists.hohndel.org/pipermail/subsurface/2014-August/014524.html
>
>
>> And this is just one reason why distributions should not do the whole
>> insane "dynamic linking only" strategy.
>
>> Dynamic linking should be for core distro packages only. Not for random
>> other stuff. That's *particularly* true for random oddball libraries (is
>> libgit2 but also libdivecomputer or even things like libxml).
>
>> The advantages of dynamic linking are totally negated by (a) versioning
>> issues and (b) lack of wide sharing.
>
>> Just look at what all external entities end up *having* to do (ie think
>> valve etc). Debian should rethink its policies wrt dynamic libraries,
>> because the current one is wrong for users, and wrong for developers.  But
>> also wrong for purely technical reasons.
>
>> Could someone involved with Debian please try to take this issue up? I'm
>> fed up with how the kernel makes binary compatibility such a priority, only
>> to have distributions throw all that sanity and effort away.
>
>> Linus
>
>
> I have no opinion on the topic at the moment, except that it is no ideal to
> have the new version stuck in experimental, but I thought it is worth to relay
> and have some discussion about this.

Since libgit seems to be rather volatile (API wise), what's the
problem with following upstream's advice and make the package povide a
static library only? Two reasons come to my mind:

 1.) A security fix need to requires compilation in many other packages
 2.) An API break will silently break other packages, and will
surprise silently on the next package upload, which may or may not be
urgent

Both can be handled by the maintainer when dealt with care and he is
willing to actively (!) ensure that both points are not a problem (for
instance, by tracking the exported symbols on each upstream release
and/or recompile all application packages that link against libgit -
again on each and every upload of a new upstream release). The number
of packages that link against the static library is an important
metric to take into consideration here: If we are only talking about
two or three applications that are maintained by the same maintainer
or even team, then it may be OK, however if we are talking about
dozens applications and maintainers involved, then I as maintainer
would refuse to engage this mess.

-- 
regards,
Reinhard


--
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/CAJ0cceaWKxtU+2BS+no-XStvqk9BnjX-JAU8RfW=hkclquf...@mail.gmail.com

Re: Two new architectures bootstrapping in unstable - MBF coming soon

[Manuel A. Fernandez Montecelo]

2014-08-28 01:55 Wookey:

+++ Manuel A. Fernandez Montecelo [2014-08-27 20:25 +0100]:


Congrats!  The sooner that you graduate out of debian-ports, the
better for other architectures that want to get into ;-) -- although
arm64 is still there, for some reasons.


We are using the binaries in debian-ports to help bootstrap debian
proper (cycle breaking), so will keep debian-ports running until
everything there is also built in debian-proper, then we can turn it
off, and as you observe, 'free up' a slot. That should be within the
month judging by current rates of progress.


Ah, OK, thanks for the explanation.  I thought that it was just a
pending task that was not carried out for some reason, or not
reflected yet in the website.

The part of freeing up a slot was meant as a joke though, no hurry :-)

I am very happy to see these new arches progress so quickly!


Cheers.
--
Manuel A. Fernandez Montecelo 


--
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/20140828231949.ga2...@lugh.itsari.org

Re: Help request: intel-microcode and old Intel processors

[Henrique de Moraes Holschuh]

On Thu, 28 Aug 2014, Andrea Bolognani wrote:
> On Tue, Aug 26, 2014 at 03:49:06PM -0300, Henrique de Moraes Holschuh wrote:
> > I'd like to know whether the kernel microcode update is working well on some
> > of the older Intel 32-bit processors or not.  These computers were sold
> > between years 2000 and 2010.
> > 
> > This information will be used to decide the level of microcode update
> > support for these processors on the next non-free release (Jessie).
> 
> I have a couple of laptops that could probably qualify, but they're both
> running Wheezy and I can't update them to testing / unstable.
> 
> Would running the above commands on Wheezy be of any help to you?

Yes, wheezy is fine (as long as it is up-to-date).

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


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

Work-needing packages report for Aug 29, 2014

[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: 589 (new: 5)
Total number of packages offered up for adoption: 140 (new: 1)
Total number of packages requested help for: 60 (new: 0)

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



The following packages have been orphaned:

   extrema (#759143), orphaned 4 days ago
 Description: powerful visualization and data analysis tool
 Installations reported by Popcon: 204

   gquilt (#759142), orphaned 4 days ago
 Description: graphical wrapper for quilt and/or mercurial queues
 Installations reported by Popcon: 97

   html2ps (#759016), orphaned 5 days ago
 Description: HTML to PostScript converter
 Reverse Depends: graphicsmagick-imagemagick-compat xhtml2ps
 Installations reported by Popcon: 2063

   pipenightdreams (#759603), orphaned today
 Description: connect pipes to get the water flowing from inlet to
   outlet
 Reverse Depends: pipenightdreams
 Installations reported by Popcon: 198

   sng (#759601), orphaned today
 Description: a specialized markup language for representing PNG
   contents
 Installations reported by Popcon: 105

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

   gthumb (#759600), offered today
 Description: image viewer and browser
 Reverse Depends: gthumb gthumb-dbg gthumb-dev
 Installations reported by Popcon: 7068

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

   apt-xapian-index (#567955), requested 1669 days ago
 Description: maintenance tools for a Xapian index of Debian packages
 Reverse Depends: ept-cache goplay packagesearch
 Installations reported by Popcon: 74020

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

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

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

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

   chromium-browser (#583826), requested 1551 days ago
 Description: Chromium browser
 Reverse Depends: chromedriver chromium chromium-dbg chromium-l10n
   mozplugger
 Installations reported by Popcon: 24518

   code-saturne (#754477), requested 48 days ago
 Description: General purpose Computational Fluid Dynamics (CFD)
   software
 Reverse Depends: code-saturne
 Installations reported by Popcon: 172

   csv2latex (#746158), requested 123 days ago
 Description: a CSV to LaTeX file converter
 Installations reported by Popcon: 147

   cups (#532097), requested 1909 days ago
 Description: Common UNIX Printing System
 Reverse Depends: bluez-cups chromium cinnamon-settings-daemon
   cloudprint cups cups-backend-bjnp cups-browsed cups-bsd cups-client
   cups-core-drivers (63 more omitted)
 Installations reported by Popcon: 135896

   debtags (#567954), requested 1669 days ago
 Description: Enables support for package tags
 Reverse Depends: goplay packagesearch
 Installations reported by Popcon: 2303

   fbcat (#565156), requested 1688 days ago
 Description: framebuffer grabber
 Installations reported by Popcon: 153

   freeipmi (#628062), requested 1190 days ago
 Description: GNU implementation of the IPMI protocol
 Reverse Depends: freeipmi freeipmi-bmc-watchdog freeipmi-ipmidetect
   freeipmi-ipmiseld freeipmi-tools libfreeipmi-dev libfreeipmi12
   libfreeipmi16 libipmiconsole-dev libipmiconsole2 (6 more omitted)
 Installations reported by Popcon: 5411

   gnat-gps (#496905), requested 2191 days ago
 Description: co-maintainer needed
 Reverse Depends: gnat-gps gnat-gps-dbg
 Installations reported by Popcon: 512

   gnokii (#677750), requested 803 days ago
 Description: Datasuite for mobile phone management
 Reverse Depends: gnokii gnokii-cli gnokii-smsd gnokii-smsd-mysql
   gnokii-smsd-pgsql gnome-phone-manager libgnokii-dev libgnokii6
   xgnokii
 Installations reported by Popcon: 

Bug#759379: general: Mouse resp. touchpad cursor is flickering, disapearing and jumping

[Tomasz Nitecki]

tags 759379 + moreinfo
thanks


Hey,

In order to help you with your problem we need some more information.

1. Can you please provide us with the output of 'dmesg', 'lspci' and
'lsusb' commands? It would be great if you could attach those as
separate text files.

2. What do you mean by 'Mouse resp. touchpad'? Does the problem occur
with your touchpad or mouse (or both)?

3. If it only occurs with touchpad, did try to use external mouse with
your laptop? Did it change anything?

3. Did you try adjusting your mouse/touchpad settings in configuration
menu (speed, sensitivity, etc.)? Did it change anything?

4. Did you try using any other desktop environment (like KDE or XFCE)?
Was your cursor also broken?


When responding, please cc your response to 759...@bugs.debian.org
Thanks for your report!


Regards,
T.



signature.asc
Description: OpenPGP digital signature

Processed: Re: Bug#759379: general: Mouse resp. touchpad cursor is flickering, disapearing and jumping

[Debian Bug Tracking System]

Processing commands for cont...@bugs.debian.org:

> tags 759379 + moreinfo
Bug #759379 [general] general: Mouse resp. touchpad cursor is flickering, 
disapearing and jumping
Added tag(s) moreinfo.
> thanks
Stopping processing here.

Please contact me if you need assistance.
-- 
759379: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=759379
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems


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

Processed: Re: Stripped black and white background on activites page in Gnome after coming out of suspend.

[Debian Bug Tracking System]

Processing commands for cont...@bugs.debian.org:

> tags 756966 + wontfix
Bug #756966 [general] general: Stripped black and white background on activites 
page in Gnome after coming out of suspend.
Added tag(s) wontfix.
> thanks
Stopping processing here.

Please contact me if you need assistance.
-- 
756966: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=756966
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems


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

Bug#756966: marked as done (general: Stripped black and white background on activites page in Gnome after coming out of suspend.)

[Debian Bug Tracking System]

Your message dated Fri, 29 Aug 2014 04:51:00 +0200
with message-id <53ffea94.1080...@tnnn.pl>
and subject line Re: Stripped black and white background on activites page in 
Gnome after coming out of suspend.
has caused the Debian Bug report #756966,
regarding general: Stripped black and white background on activites page in 
Gnome after coming out of suspend.
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.)


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

Dear Maintainer,
I have the gnome front end ran by the radeon hd 5770 graphics card.
I installed the radeon catalyst drivers and my graphics card has been doing 
great.
The problem is after I come out of suspend mode and move my cursor to the 
activities 
tab to open my programsand do my usual activites, a problem occurs. The 
background of 
the activities page presents me with black and white horizontal stripped lines. 
I can still open my apps and choose new desktops, but I know these stripped 
lines
should not exist. I reboot the computer and the problem disappears. 
I have a nice opaque/translusant background on the activites page as I should.
Sorry for the spelling! 

-jkpieka



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

Kernel: Linux 3.2.0-4-amd64 (SMP w/4 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 ---
tags 756966 + wontfix
thanks


Hey,

On 08/08/14 04:33, Jk Pieka wrote:
> Before I do a reinstall. I will try the other catalyst driver that
> AMD offers. They also offer a 14.6 beta. I will give it a go this
> weekend and report back.

On 09/08/14 04:48, Jk Pieka wrote:
> I found the fix to the problem. I ran the command..
> 
> $ find /dev -group video
> 
> Apparently this loads the kernel driver. I am not sure what this
> means to be honest. This fixes all of the graphics issues after
> coming out of suspend. Would you know where commands can be placed to
> be ran when coming out of suspend?


Hey,

We didn't hear back from you for almost three weeks. Based on your last
message, I assume that your problem is resolved so I'm closing your bug
report. Of course, I may be wrong or you might have been simply unable
to respond. If so, feel free to reopen it and provide us with updated
information.


If you would like to reopen it:

First, send an email to cont...@bugs.debian.org with following two lines
(you can read more about doing this at [1]):

reopen 756966
thanks

Then, email required information to 756...@bugs.debian.org


Regards,
T.



signature.asc
Description: OpenPGP digital signature
--- End Message ---

Re: raising an issue about static linking policy

[Kurt Roeckx]

On Thu, Aug 28, 2014 at 11:38:49PM +0200, Salvo Tomaselli wrote:
> Hello,
> 
> I've recently packaged subsurface 4.2 for experimental, because it depends on 
> libgit2 which is in experimental...
> 
> I think you might want to read these posts:
> http://lists.hohndel.org/pipermail/subsurface/2014-August/014520.html
> http://lists.hohndel.org/pipermail/subsurface/2014-August/014524.html
> 
> 
> > And this is just one reason why distributions should not do the whole
> > insane "dynamic linking only" strategy.
> 
> > Dynamic linking should be for core distro packages only. Not for random
> > other stuff. That's *particularly* true for random oddball libraries (is
> > libgit2 but also libdivecomputer or even things like libxml).
> 
> > The advantages of dynamic linking are totally negated by (a) versioning
> > issues and (b) lack of wide sharing.
> 
> > Just look at what all external entities end up *having* to do (ie think
> > valve etc). Debian should rethink its policies wrt dynamic libraries,
> > because the current one is wrong for users, and wrong for developers.  But
> > also wrong for purely technical reasons.
> 
> > Could someone involved with Debian please try to take this issue up? I'm
> > fed up with how the kernel makes binary compatibility such a priority, only
> > to have distributions throw all that sanity and effort away.
> 
> > Linus

I really don't understand some of the point that Linus is trying
to make.

Some random comments:
- We have a policy that says we want shared libaries, except in a
  few cases, and it might apply to libgit.
- I except all library packages to ship a static library even when
  there is a shared version, but policy doesn't really require this.
- Their is an open bug against policy about applications linking
  staticly to libraries. We don't discourage linking staticly
  (yet).
- I really don't understand Linus' comment about the binary
  compatibility.  The problem is that libgit does not provide
  binary compatibility, while most libraries do try to provide
  the ABI compatible and that we have various ways of dealing
  with the problem if the ABI gets changed. *We* are not throwing
  sanity away, we are trying to bring sanity.
- I don't see how dynamic linking negates versioning issues.  In
  fact I think because we have dynamic linking people actually
  care about the ABI and so we have less problems.
- I can't see how libxml wouldn't be a core package.  Maybe he
  should check how many copies of that he has open.
- Static linking is a security nightmare, as are embedded copies
  of libraries.  It creates additional work and it's not clear
  which applications are all affected.


Kurt


-- 
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/20140829031805.ga2...@roeckx.be

Bug#759639: ITP: direwolf -- Soundcard TNC for APRS

[Iain R. Learmonth]

Package: wnpp
Severity: wishlist
Owner: "Iain R. Learmonth" 

* Package name: direwolf
  Version : 1.0
  Upstream Author : John W Langner
* URL : http://home.comcast.net/~wb2osz/site/
* License : GPL-2
  Programming Lang: C
  Description : Soundcard TNC for APRS

Dire Wolf is a software "soundcard" modem/TNC and APRS encoder/decoder.
It can be used stand-alone to receive APRS messages, as a digipeater,
APRStt gateway, or Internet Gateway (IGate).It can also be used as
a virtual TNC for other applications such as APRSIS32, UI-View32,
Xastir, APRS-TW, YAAC, UISS, Linux AX25, SARTrack, and many others.


-- 
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/20140829033302.24504.70086.report...@lepton.shiftout.net

While we're at it... (keys)

[Nick Phillips]

I've been putting off generating a new key because I want to make sure I
know how I'm going to manage the new one before I generate it (i.e.
avoiding leaving it sitting on my desktop machine, not typing the
passphrase on that machine, etc.).

Has anyone written up "key management for Debian developers"? - how does
everybody else do it?

I'm sure I've heard a wide variety of answers when I've asked in the
past - e.g. "I keep it on a USB key and only plug it in when needed", "I
keep it on a separate machine that has no network connection and
transfer everything to and from signing by sneakernet", "I use some kind
of hardware dongle to hold it" etc.


Cheers,


Nick
-- 
Nick Phillips / nick.phill...@otago.ac.nz / 03 479 4195
# These statements are mine, not those of the University of Otago

Re: logcheck rules for systemd

[Hannes von Haugwitz]

On Thu, Aug 28, 2014 at 12:52:21PM +0100, Chris Boot wrote:
> You may find it easier to bundle the logcheck rules with systemd itself
> rather than as part of logcheck-database. Debhelper has a
> dh_installlogcheck tool that you may find useful. In my opinion,
> packaging the logcheck rules with the program that generates the log
> messages makes more sense, as the rules can be more easily kept up to
> date with the generating program.

With my logcheck maintainer hat on, I strongly support this (I'd be glad
to drop the logcheck-database package some day…).

The maintainer of a package knows best which log lines can and should be
filtered out by default for all logcheck users. If someone needs help
with the rules, don't hesitate to ask on logcheck-devel[0].

Best regards

Hannes

[0] logcheck-de...@lists.alioth.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/20140829052333.gd12...@carbon.vonhaugwitz.com