date:20140213

On 2/14/14, Paul Tagliamonte  wrote:
> On Fri, Feb 14, 2014 at 04:44:21AM +, Jacob Appelbaum wrote:
>> Heya Sam,
>>
>> On 2/14/14, Sam Hartman  wrote:
>> > All rants aside, I believe there's a fairly wide agreement that we
>> > should throw away binaries from builds.
>>
>> I'd encourage something slightly different and then I'd expand on it a
>> bit.
>>
>> I think it would be useful to have an historical archive of each
>> binary, as uploaded by a developer or produced by a build server.
>
> Perhaps you're interested in helping with http://snapshot.debian.org/
> then? :)
>

I'm glad to see that the really hard part of the process is already
done! Amazing!

> (I've got tons of these links!)
>

I'm enjoying reading them all. Thank you! :)

All the best,
Jacob


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

Re: when will we finally throw away binary uploads (Re: Please upgrade your build environment when you are affected by transition

On Fri, Feb 14, 2014 at 04:44:21AM +, Jacob Appelbaum wrote:
> Heya Sam,
> 
> On 2/14/14, Sam Hartman  wrote:
> > All rants aside, I believe there's a fairly wide agreement that we
> > should throw away binaries from builds.
> 
> I'd encourage something slightly different and then I'd expand on it a bit.
> 
> I think it would be useful to have an historical archive of each
> binary, as uploaded by a developer or produced by a build server.

Perhaps you're interested in helping with http://snapshot.debian.org/
then? :)

(I've got tons of these links!)

Cheers,
  Paul

-- 
 .''`.  Paul Tagliamonte   |   Proud Debian Developer
: :'  : 4096R / 8F04 9AD8 2C92 066C 7352  D28A 7B58 5B30 807C 2A87
`. `'`  http://people.debian.org/~paultag
 `- http://people.debian.org/~paultag/conduct-statement.txt


signature.asc
Description: Digital signature

Re: when will we finally throw away binary uploads (Re: Please upgrade your build environment when you are affected by transition

Heya Sam,

On 2/14/14, Sam Hartman  wrote:
> All rants aside, I believe there's a fairly wide agreement that we
> should throw away binaries from builds.

I'd encourage something slightly different and then I'd expand on it a bit.

I think it would be useful to have an historical archive of each
binary, as uploaded by a developer or produced by a build server. In
the event that a binary is imperfect, storing a copy of each binary
may be useful for later analysis. This could help us spot bugs for a
compiler specific problem (such as optimizing something out of the
binary that was otherwise in the source) or when the binary is simply
malicious (such as a backdoor inserted by a compiler or build
process).

I'd say that we might consider *using* that uploaded binary as an
assertion by a given developer. In general it is the expected correct
output binary and it is signed by that developer.

As we move into the deterministic/reproducible world, the archive will
serve an interesting purpose. Each developer would upload their
respective binary and signature per architecture for a given source
package. Their output may be represented as GnuPG signatures over
hashes of source code packages and binary packages. In theory, we
could have an assertion from another developer with another upload and
so on.

Even though we should have matching hashes, in some cases, we may not
learn that we have mismatching hashes for hours or days. Thus keeping
a copy of all the built binary parts is useful for later analysis.

This will allow us to verify that the sources correspond to a specific
binary output, we could also ensure that very important packages
require a threshold of signatures before the binaries are consider
properly built.

Those that upload a binary should not be able to delete the uploaded
binary - thus when a build server or developer builds a *different*
version, we'll be able to inspect *all files* for differences. So for
each developer uploading, we'd keep a copy. We could discard identical
binaries and ensure that a copy is only kept in the long run when
there are no strange events.

If a developer is compromised, we're able to detect it and ensure that
the developer's system cannot be used to erase evidence of such a
compromise. If the build system is compromised, it will be useful to
download the binary from the archive and to inspect it. Similarly the
build system may not erase items from the archive.

This could add to the overall security of the process and to begin to
give us some semblance of a review process for binaries served to
users.

Until something like that happens, I think we should probably not
*ship* the developer built binaries to users. We will however ship
some binary parts to the user and hopefully those will be built by the
build servers, as well as archived somewhere for all time, in case
we're already compromised.

( Append only data store ideas like Chisel may have a non-evil use, hooray! )

>
> I seem to recall ftp-master sending out mail to debian-devel-announce
> describing the steps along that process a while ago.
>
> I think it's fine to ask where that project is, and to volunteer
> resources to help.
> However, I'd hope we're all agreed that we need to get there.
>

I've been reading the deterministic build page and I think it could
use some further discussions.

All the best,
Jacob

-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/CAFggDF0kOQsNbdQ-5-LSuHr0z0zTnOWDnSXV+H5qA1khMKF=w...@mail.gmail.com

Re: Need advice on building a package

2014-02-13 Thread Chris Bannister

On Thu, Feb 13, 2014 at 12:06:10PM +0100, Jonas Smedegaard wrote:
> This mailinglist is, after all, a list about developing Debian.  If your 
> interest is only in *using* Debian e.g. for own package development, 
> then our debian-user lists are more appropriate for that: 
> https://lists.debian.org/users.html

People asking on debian-user about packaging normally get referred to
debian-mentors, after all that's where the expertise is.

-- 
"If you're not careful, the newspapers will have you hating the people
who are being oppressed, and loving the people who are doing the 
oppressing." --- Malcolm X


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20140214041005.GA20059@tal

Re: Bug#738850: ITP: iniparser -- a stand-alone INI file reading/writing library

2014-02-13 Thread Paul Wise

On Thu, Feb 13, 2014 at 9:12 PM, Klee Dienes wrote:

> Regarding #2, my goal is to package the psmoveapi code for Debian,
> which uses the write support of iniparser (not supported by inih).  I
> also note that Samba seems to include an internal version of
> iniParser.

Please report any embedded code copies or forks to the security team:

https://wiki.debian.org/EmbeddedCodeCopies

-- 
bye,
pabs

http://wiki.debian.org/PaulWise


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/CAKTje6F9+SB8mNfYz7_zETO03_uqSHp=9kgnesnhssfmnhj...@mail.gmail.com

Work-needing packages report for Feb 14, 2014

2014-02-13 Thread 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: 559 (new: 55)
Total number of packages offered up for adoption: 151 (new: 6)
Total number of packages requested help for: 55 (new: 1)

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



The following packages have been orphaned:

   2vcard (#738910), orphaned today
 Description: perl script to convert an addressbook to VCARD file
   format
 Installations reported by Popcon: 168

   anon-proxy (#738926), orphaned today
 Description: Proxy to surf the web anonymously
 Installations reported by Popcon: 100

   bustle (#738308), orphaned 4 days ago
 Description: D-Bus activity visualiser
 Installations reported by Popcon: 98

   cadubi (#738912), orphaned today
 Description: Creative ASCII Drawing Utility By Ian
 Installations reported by Popcon: 71

   cakephp (#738289), orphaned 5 days ago
 Description: MVC rapid application development framework for PHP
 Reverse Depends: cakephp-instaweb cakephp-scripts
 Installations reported by Popcon: 127

   criticalmass (#738892), orphaned today
 Description: Shoot-em-up a la galaxian
 Reverse Depends: criticalmass
 Installations reported by Popcon: 319

   cwidget (#738893), orphaned today
 Description: high-level terminal interface library for C++ (runtime
   files)
 Reverse Depends: aptitude libcwidget-dev libcwidget3-dbg
 Installations reported by Popcon: 162819

   dangen (#738876), orphaned today
 Description: shoot 'em up game where accurate shooting matters
 Installations reported by Popcon: 84

   dpkg-www (#738903), orphaned today
 Description: Web based Debian package browser
 Installations reported by Popcon: 389

   exifprobe (#738911), orphaned today
 Description: Read metadata from digital pictures
 Installations reported by Popcon: 593

   flpsed (#738473), orphaned 4 days ago
 Description: a WYSIWYG pseudo PostScript editor
 Installations reported by Popcon: 488

   giftrans (#738293), orphaned 5 days ago
 Description: Convert any GIF file into a GIF89a
 Installations reported by Popcon: 178

   grun (#738098), orphaned 6 days ago
 Description: GTK based run dialog
 Installations reported by Popcon: 665

   haildb (#738177), orphaned 5 days ago
 Description: Library implementing InnoDB-like database
 Reverse Depends: libhaildb-dbg libhaildb-dev
 Installations reported by Popcon: 10

   heroes (#738894), orphaned today
 Description: Collect powerups and avoid your opponents' trails
 Reverse Depends: heroes-sdl
 Installations reported by Popcon: 302

   heroes-data (#738895), orphaned today
 Description: Required data files for heroes
 Reverse Depends: heroes-sdl
 Installations reported by Popcon: 305

   heroes-sound-effects (#738896), orphaned today
 Description: Optional sound files for heroes
 Installations reported by Popcon: 294

   heroes-sound-tracks (#738898), orphaned today
 Description: Optional sound files for heroes
 Installations reported by Popcon: 291

   icon (#738875), orphaned today
 Description: Interpreter for Icon, a high-level programming language
 Reverse Depends: noweb
 Installations reported by Popcon: 767

   libidl (#738870), orphaned today
 Description: library for parsing CORBA IDL files
 Reverse Depends: libidl-dev liborbit2 liborbit2-dev orbit2
   python-pyorbit
 Installations reported by Popcon: 96330

   libnbio (#73), orphaned today
 Description: non-blocking IO library development files
 Reverse Depends: libnbio-dev timps
 Installations reported by Popcon: 10

   librep (#738097), orphaned 6 days ago
 Description: lisp command interpreter
 Reverse Depends: librep-dbg librep-dev rep rep-gtk sawfish
 Installations reported by Popcon: 1145

   libsigc++-1.2 (#738897), orphaned today
 Description: type-safe Signal Framework for C++ - development files
 Reverse Depends: asc freqtweak libsigc++-1.2-dev sooperlooper
 Installations reported by Popcon: 1909

   libsigc++-2.0 (#738899), orphaned today
 Description: type-safe Signal Framework for C++ - runtime
 Reverse Depends: abgate aeskulap agave amsynth aptitude
   arc-gui-clients ardour ardour-altivec ardour-i686 ardour3 (157 more
   omitted)
 Installations reported by Popcon: 165869

   libsocket6-perl (#738885), orphaned today
 Description: Perl extensions for IPv6
 Reverse Depends: ldirectord libio-socket-inet6-perl
   libio-socket-multicast6-perl libnet-frame-perl libnet-patricia-perl
   libnet-server-perl libnet-subnet-perl libnet-write-perl
   libsocket-multicast6-perl qpsmtpd (2 more omitted)
 Installati

Re: when will we finally throw away binary uploads (Re: Please upgrade your build environment when you are affected by transition

2014-02-13 Thread Sam Hartman

All rants aside, I believe there's a fairly wide agreement that we
should throw away binaries from builds.

I seem to recall ftp-master sending out mail to debian-devel-announce
describing the steps along that process a while ago.

I think it's fine to ask where that project is, and to volunteer
resources to help.
However, I'd hope we're all agreed that we need to get there.

--Sam


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/01442dcab45a-f088c559-58fa-4337-adef-4a28964e06c5-000...@email.amazonses.com

Re: when will we finally throw away binary uploads (Re: Please upgrade your build environment when you are affected by transition

2014-02-13 Thread Brian May

On 14 February 2014 05:46, Jakub Wilk  wrote:

> How many uploaded binaries might include malware?
>>
>
> *shrug* It's not like it's difficult to hide malicious code in source
> packages.
>

After the damage is done, probably easier to find the malware that did it
if you can rely on the source code being an accurate representation of what
was running (not that this would be any easy task).
-- 
Brian May

Re: when will we finally throw away binary uploads (Re: Please upgrade your build environment when you are affected by transition

2014-02-13 Thread Dimitri John Ledkov

On 13 February 2014 21:17, Holger Levsen  wrote:
> Hi,
>
> On Donnerstag, 13. Februar 2014, Dimitri John Ledkov wrote:
>> All that's needed, I guess, is for someone to write a patch to dak /
>> wanna-build ... and schedule _all.deb builds on amd64 ?
>> Or if arch-restricted package, on one of the arches it will build on?
>
> nope, it's worse than you think: the arch specific package built on the
> developers machine (in a "random"^wnon predicatable environment) will not be
> rebuild, there are also no build logs available.
>
> See https://buildd.debian.org/status/package.php?p=html2text - you can only
> hope that I've build it in a clean environment and there aint a logfile for
> the amd64 build of that arch:any package.
>

My understanding is that arch:any binary debs will be discouraged from
uploading, and hence not a problem. (And/or eventually rejected, or
binary uploads must go through binary upload queue and/or some such.)

This got me thinking, given the problem of "where should arch:all
build happen", would it be easier to enable source-only uploads for
src+arch:any [!arch:all] packages?
(similar how currently mixed src+any+all, can be uploaded as src+all)

That would solve most of the uploads, given how boring arch:all binary
packages are.

-- 
Regards,

Dimitri.

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

Re: Re: FFmpeg vs. libav packaging

2014-02-13 Thread Adrian Bunk

On Thu, Feb 13, 2014 at 11:14:39PM +0100, Petr Baudis wrote:
>   Hi!
> 
> > Do you have a good idea how to avoid all the problems of mixing both 
> > libraries while also creating a sufficient usage of the FFmpeg libraries 
> > in a way that both libraries can be in testing at the same time, or are 
> > you just setting a hurdle intended to be impossible to pass for FFmpeg?
> 
>   I'm pretty sure Debian already had to deal with multiple situations
> like that.  I can't think of the examples off the top of my head, but
> what about for example the two sets of Kerberos libraries, krb5 vs.
> heimdal?  I think others could point out other examples.  Is the
> situation here fundamentally more difficult?

Half a dozen libraries.

Some have different sonames, some have the same soname.

soname changes are frequent (the next libav soname change is already in 
experimental).

Having both libraries in the archive at the same time would be a 
horrible mess to sort out.

And here we have a maintainer requiring to have all that mess of having 
both in testing at the same time sorted out - just for allowing him to
"sensibly compare them" and then pick the one he prefers.

>   Petr "Pasky" Baudis

cu
Adrian

-- 

   "Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
   "Only a promise," Lao Er said.
   Pearl S. Buck - Dragon Seed

-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20140213235409.gd4...@bunk.dyndns.info

Re: when will we finally throw away binary uploads (Re: Please upgrade your build environment when you are affected by transition

2014-02-13 Thread Colin Watson

On Thu, Feb 13, 2014 at 10:17:46PM +0100, Holger Levsen wrote:
> See https://buildd.debian.org/status/package.php?p=html2text - you can only 
> hope that I've build it in a clean environment and there aint a logfile for 
> the amd64 build of that arch:any package.

I'm told there's at least some magic address you can mail the logs to,
but I never remember what it is.  (It's all a workaround anyway.)

-- 
Colin Watson   [cjwat...@debian.org]


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20140213235201.ga2...@riva.ucam.org

Bug#738939: ITP: php-date-holidays -- Driver based class to calculate holidays.

2014-02-13 Thread Francois-Regis Vuillemin

Package: wnpp
Severity: wishlist
Owner: "Francois-Regis Vuillemin" 

* Package name: php-date-holidays
  Version : 0.21.8
  Upstream Author : Carsten Lucke 
* URL : http://pear.php.net/package/Date_Holidays
* License : PHP
  Programming Lang: PHP
  Description : Driver based class to calculate holidays.
Date_Holidays helps you calculate the dates and titles of holidays and other
special celebrations. The calculation is driver-based so it is easy to add new
drivers that calculate a country's holidays. The methods of the class can be
used to get a holiday's date and title in various languages.

This is a recommend for horde


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/20140213234828.6937.40604.report...@graves.miradou.com

Re: FFmpeg vs. libav packaging (was Re: Proposal: SystemD.pushers/forcers, et cetera)

2014-02-13 Thread Jonas Smedegaard

Quoting Adrian Bunk (2014-02-13 22:40:23)
> On Thu, Feb 13, 2014 at 09:21:02PM +0100, Jonas Smedegaard wrote:
>> Quoting Adrian Bunk (2014-02-13 20:37:47)
>>> Are you as Debian Multimedia Maintainer willing to discuss which 
>>> option (libav, FFmpeg, some solution of shipping both) will be best 
>>> for jessie based on the information that is available today?
>> 
>> It will certainly be best for Jessie to have a library included which 
>> exist and has had reasonable testing as official Debian package.
>> 
>> Someone needs to do the work of packaging FFmpeg and get it into 
>> Debian testing - then we can sensibly compare them in the context of 
>> an upcoming stable Debian release.
>
> Having both sets of libraries in the archive at the same time is what 
> I called "insane" in the RFP and where I expect additional probems due 
> to:
> - programs compiled with libav using FFmpeg and
> - programs ending up using a mix of both libraries, in some cases
>   even both versions of the same library
>
> And for a fair comparison in testing, one would e.g. need one package 
> of VLC compiled against libav and one package of VLC compiled against 
> FFmpeg at the same time in testing.
>
> Do you have a good idea how to avoid all the problems of mixing both 
> libraries while also creating a sufficient usage of the FFmpeg 
> libraries in a way that both libraries can be in testing at the same 
> time,

No, unfortunately I see no way around a substantive amount of real work 
to prove FFmpeg relevant for consideration.

> or are you just setting a hurdle intended to be impossible to pass for 
> FFmpeg?

No, I do not "set a hurdle", just point out that I find it reasonable.
Nor do I consider it impossible - just hard work.

...just as it has been hard work for those getting LibAV into shape.

Actually, I expect it to be *less* work, because the situation is 
arguably now less of a mess than when the LibAV fork was started.  Not 
that I expect you to agree on that - I just point it out, to emphasize 
that I do *not* consider it an imposible task like you seem to put in my 
mouth.


 - Jonas

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

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


signature.asc
Description: signature

Re: Re: FFmpeg vs. libav packaging

2014-02-13 Thread Petr Baudis

  Hi!

> Do you have a good idea how to avoid all the problems of mixing both 
> libraries while also creating a sufficient usage of the FFmpeg libraries 
> in a way that both libraries can be in testing at the same time, or are 
> you just setting a hurdle intended to be impossible to pass for FFmpeg?

  I'm pretty sure Debian already had to deal with multiple situations
like that.  I can't think of the examples off the top of my head, but
what about for example the two sets of Kerberos libraries, krb5 vs.
heimdal?  I think others could point out other examples.  Is the
situation here fundamentally more difficult?

Petr "Pasky" Baudis


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20140213221439.gq19...@machine.or.cz

Re: FFmpeg vs. libav packaging (was Re: Proposal: SystemD.pushers/forcers, et cetera)

2014-02-13 Thread Adrian Bunk

On Thu, Feb 13, 2014 at 09:21:02PM +0100, Jonas Smedegaard wrote:
> Quoting Adrian Bunk (2014-02-13 20:37:47)
> > Are you as Debian Multimedia Maintainer willing to discuss which 
> > option (libav, FFmpeg, some solution of shipping both) will be best 
> > for jessie based on the information that is available today?
> 
> It will certainly be best for Jessie to have a library included which 
> exist and has had reasonable testing as official Debian package.
> 
> Someone needs to do the work of packaging FFmpeg and get it into Debian 
> testing - then we can sensibly compare them in the context of an 
> upcoming stable Debian release.

Having both sets of libraries in the archive at the same time is what
I called "insane" in the RFP and where I expect additional probems 
due to:
- programs compiled with libav using FFmpeg and
- programs ending up using a mix of both libraries, in some cases
  even both versions of the same library

And for a fair comparison in testing, one would e.g. need one package
of VLC compiled against libav and one package of VLC compiled against 
FFmpeg at the same time in testing.

Do you have a good idea how to avoid all the problems of mixing both 
libraries while also creating a sufficient usage of the FFmpeg libraries 
in a way that both libraries can be in testing at the same time, or are 
you just setting a hurdle intended to be impossible to pass for FFmpeg?

> I am part of the Debian Multimedia team, if that matters to you.
> 
>  - Jonas

cu
Adrian

-- 

   "Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
   "Only a promise," Lao Er said.
   Pearl S. Buck - Dragon Seed

-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20140213214023.gb4...@bunk.dyndns.info

Re: when will we finally throw away binary uploads (Re: Please upgrade your build environment when you are affected by transition

2014-02-13 Thread Sam Hartman

> "Colin" == Colin Watson  writes:

Colin> On Thu, Feb 13, 2014 at 07:46:53PM +0100, Jakub Wilk wrote:
>> *shrug* It's not like it's difficult to hide malicious code in
>> source packages.
>> 
>> How many configure scripts that we never rebuild from source
>> contains trojans?

Colin> Just like my favourite Russ quote:

Colin>   Basically, people got tired of portability problems in
Colin> building shared libraries so they hid them all inside a
Colin> multi-thousand line shell script where no one can ever find
Colin> them because everyone who tries goes blind.  -- Russ Allbery

I assure you, that even if you get past the being blind bit, it's still
impossible to figure out what's going on.

-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/01442d2fdd79-9235a03c-59d2-426a-9e7f-767912027c43-000...@email.amazonses.com

Re: when will we finally throw away binary uploads (Re: Please upgrade your build environment when you are affected by transition

On 2/13/14, Jakub Wilk  wrote:
> * Jacob Appelbaum , 2014-02-13, 18:36:
>>How many uploaded binaries might include malware?
>
> *shrug* It's not like it's difficult to hide malicious code in source
> packages.
>

It is much harder for you to hide source code changes as a third party
than binary changes.

Many projects have code review processes with people who read each
commit and reason about the contents of each code change. Very few
public projects have a similar process for reverse engineering
binaries or understanding the output of a compiler for releases. Those
few projects generally aim for deterministic or reproducible builds -
this still has the problem of missing a solid understanding of the
output, by the way.

> How many configure scripts that we never rebuild from source contains
> trojans?

There are several serious problems involved in this topic. One expects
that we at least have processes for finding malicious configure
scripts, as we find buffer overflows in C programs or as we find
portability problems in assembler code - no such (Debian) process
currently exists for inspecting binaries that are uploaded by
developers. Perhaps I'm mistaken? Perhaps there is a project for
actively inspecting and reverse engineering binaries that are uploaded
by developers?

A key problem here is not the badly behaving developer - it is the
developer that is compromised and unwittingly becomes party to harming
others. Minimizing this exposure is an important goal and worth
consideration.

All the best,
Jacob

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

Re: when will we finally throw away binary uploads (Re: Please upgrade your build environment when you are affected by transition

2014-02-13 Thread William Grant

On 14/02/14 08:13, Paul Tagliamonte wrote:
> On Thu, Feb 13, 2014 at 09:10:15PM +, Dimitri John Ledkov wrote:
>> On 13 February 2014 16:13, Holger Levsen  wrote:
>>> Hi,
>>>
>>> On Donnerstag, 13. Februar 2014, Ondřej Surý wrote:
 this is just a pledge to you all fellow debian developers to update your
 build environment before you build a package.
>>>
>>> I want all binary packages to be rebuild on *.debian.org hosts. Everything
>>> else is just an ugly workaround.
>>>
>>
>> All that's needed, I guess, is for someone to write a patch to dak /
>> wanna-build ... and schedule _all.deb builds on amd64 ?
>> Or if arch-restricted package, on one of the arches it will build on?
> 
> The LP folks wanted to sync on this. I also wrote this for Debile, I
> called it arch affinity (I think LP uses the same name). We should pick
> a name and use it for all 3.
> 
> I also think it should be a static arch (rather then any arch that
> can build it), so that things are a bit easier to duplicate and debug.
> Might as well.

Right, "arch affinity" is the term we use for the desirable feature of
being able to override the architecture that by default builds
architecture-independent packages ("nominated arch-indep" in LP
parlance). We have https://bugs.launchpad.net/launchpad/+bug/217427
about supporting that. It's simple to fix, but has mostly been blocked
on needing to decide on a field name with other interested parties. It
sounds like we should really just work something out together -- this
has been going on long enough :)

(There are still some cases for which the semantics of the Architecture
field are unclear, even with arch affinity.
https://bugs.launchpad.net/launchpad/+bug/1063188 is one such example:
hhsuite is "Architecture: amd64 all", our nominated arch-indep is i386,
so the arch-indep bits don't get built. Presumably once we have an arch
affinity field we can assume that its absence means we can just pick one
of the buildable archs and do indep there, but wanna-build, LP and other
implementations should probably decide on the same behaviour here. Other
than that it all seems like mostly a naming thing.)

William.

signature.asc
Description: OpenPGP digital signature

Re: when will we finally throw away binary uploads (Re: Please upgrade your build environment when you are affected by transition

On Thu, Feb 13, 2014 at 4:13 PM, Paul Tagliamonte wrote:

> On Thu, Feb 13, 2014 at 09:10:15PM +, Dimitri John Ledkov wrote:
> > On 13 February 2014 16:13, Holger Levsen  wrote:
> > > Hi,
> > >
> > > On Donnerstag, 13. Februar 2014, Ondřej Surý wrote:
> > >> this is just a pledge to you all fellow debian developers to update
> your
> > >> build environment before you build a package.
> > >
> > > I want all binary packages to be rebuild on *.debian.org hosts.
> Everything
> > > else is just an ugly workaround.
> > >
> >
> > All that's needed, I guess, is for someone to write a patch to dak /
> > wanna-build ... and schedule _all.deb builds on amd64 ?
> > Or if arch-restricted package, on one of the arches it will build on?
>
> The LP folks wanted to sync on this. I also wrote this for Debile, I
> called it arch affinity (I think LP uses the same name). We should pick
> a name and use it for all 3.
>

(to be clear, "a name" in this case is a name for the field
in d/control, sorry, damn you anaphora)


>
> I also think it should be a static arch (rather then any arch that
> can build it), so that things are a bit easier to duplicate and debug.
> Might as well.
>
> > --
> > Regards,
> >
> > Dimitri.
>
> Cheers,
>   Paul
>
> --
>  .''`.  Paul Tagliamonte   |   Proud Debian Developer
> : :'  : 4096R / 8F04 9AD8 2C92 066C 7352  D28A 7B58 5B30 807C 2A87
> `. `'`  http://people.debian.org/~paultag
>  `- http://people.debian.org/~paultag/conduct-statement.txt
>



-- 
:wq

Re: when will we finally throw away binary uploads (Re: Please upgrade your build environment when you are affected by transition

Hi,

On Donnerstag, 13. Februar 2014, Dimitri John Ledkov wrote:
> All that's needed, I guess, is for someone to write a patch to dak /
> wanna-build ... and schedule _all.deb builds on amd64 ?
> Or if arch-restricted package, on one of the arches it will build on?

nope, it's worse than you think: the arch specific package built on the 
developers machine (in a "random"^wnon predicatable environment) will not be 
rebuild, there are also no build logs available.

See https://buildd.debian.org/status/package.php?p=html2text - you can only 
hope that I've build it in a clean environment and there aint a logfile for 
the amd64 build of that arch:any package.

cheers,
Holger

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

Re: when will we finally throw away binary uploads (Re: Please upgrade your build environment when you are affected by transition

On Thu, Feb 13, 2014 at 09:10:15PM +, Dimitri John Ledkov wrote:
> On 13 February 2014 16:13, Holger Levsen  wrote:
> > Hi,
> >
> > On Donnerstag, 13. Februar 2014, Ondřej Surý wrote:
> >> this is just a pledge to you all fellow debian developers to update your
> >> build environment before you build a package.
> >
> > I want all binary packages to be rebuild on *.debian.org hosts. Everything
> > else is just an ugly workaround.
> >
> 
> All that's needed, I guess, is for someone to write a patch to dak /
> wanna-build ... and schedule _all.deb builds on amd64 ?
> Or if arch-restricted package, on one of the arches it will build on?

The LP folks wanted to sync on this. I also wrote this for Debile, I
called it arch affinity (I think LP uses the same name). We should pick
a name and use it for all 3.

I also think it should be a static arch (rather then any arch that
can build it), so that things are a bit easier to duplicate and debug.
Might as well.

> -- 
> Regards,
> 
> Dimitri.

Cheers,
  Paul

-- 
 .''`.  Paul Tagliamonte   |   Proud Debian Developer
: :'  : 4096R / 8F04 9AD8 2C92 066C 7352  D28A 7B58 5B30 807C 2A87
`. `'`  http://people.debian.org/~paultag
 `- http://people.debian.org/~paultag/conduct-statement.txt


signature.asc
Description: Digital signature

Re: when will we finally throw away binary uploads (Re: Please upgrade your build environment when you are affected by transition

2014-02-13 Thread Colin Watson

On Thu, Feb 13, 2014 at 07:46:53PM +0100, Jakub Wilk wrote:
> *shrug* It's not like it's difficult to hide malicious code in
> source packages.
> 
> How many configure scripts that we never rebuild from source
> contains trojans?

Just like my favourite Russ quote:

  Basically, people got tired of portability problems in building shared
  libraries so they hid them all inside a multi-thousand line shell script
  where no one can ever find them because everyone who tries goes blind.
   -- Russ Allbery

-- 
Colin Watson   [cjwat...@debian.org]


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20140213211244.ga31...@riva.ucam.org

Re: when will we finally throw away binary uploads (Re: Please upgrade your build environment when you are affected by transition

2014-02-13 Thread Dimitri John Ledkov

On 13 February 2014 16:13, Holger Levsen  wrote:
> Hi,
>
> On Donnerstag, 13. Februar 2014, Ondřej Surý wrote:
>> this is just a pledge to you all fellow debian developers to update your
>> build environment before you build a package.
>
> I want all binary packages to be rebuild on *.debian.org hosts. Everything
> else is just an ugly workaround.
>

All that's needed, I guess, is for someone to write a patch to dak /
wanna-build ... and schedule _all.deb builds on amd64 ?
Or if arch-restricted package, on one of the arches it will build on?

-- 
Regards,

Dimitri.


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/canbhluizs-yu8-nnojv7z7fyyxsdmrl-6ff2zgeskqv8jc4...@mail.gmail.com

Bug#738908: RFH: how-can-i-help -- show opportunities for contributing to Debian

2014-02-13 Thread Lucas Nussbaum

Package: wnpp
Severity: normal

Hi,

I like this package a lot, but I don't have the bandwidth required to
maintain it on my own.

I would love to get some help with it.

The package is quite simple, and is maintained in collab-maint.

Feel free to get in touch with me if you want to help.
Please also feel free to commit non-controversial changes to Git (using
branches, if you are not sure).

Thanks,

Lucas


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

Re: FFmpeg vs. libav packaging (was Re: Proposal: SystemD.pushers/forcers, et cetera)

2014-02-13 Thread Jonas Smedegaard

Quoting Adrian Bunk (2014-02-13 20:37:47)
> Are you as Debian Multimedia Maintainer willing to discuss which 
> option (libav, FFmpeg, some solution of shipping both) will be best 
> for jessie based on the information that is available today?

It will certainly be best for Jessie to have a library included which 
exist and has had reasonable testing as official Debian package.

Someone needs to do the work of packaging FFmpeg and get it into Debian 
testing - then we can sensibly compare them in the context of an 
upcoming stable Debian release.

I am part of the Debian Multimedia team, if that matters to you.


 - Jonas

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

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


signature.asc
Description: signature

Re: Please upgrade your build environment when you are affected by transition

2014-02-13 Thread David Kalnischkies

(note to myself: you sound really grumpy after reading bikesheds)

On Thu, Feb 13, 2014 at 04:31:36PM +0100, Andreas Beckmann wrote:
> On 2014-02-13 15:37, Ondřej Surý wrote:
> > On Thu, Feb 13, 2014, at 15:00, David Kalnischkies wrote:
> >> On Thu, Feb 13, 2014 at 01:38:51PM +0100, Ondřej Surý wrote:
> 
> >> Broken libdb5.3-dev:amd64 Conflicts on libdb5.1-dev [ amd64 ] < 5.1.29-7
> >>> ( libdevel )
> >>   Considering libdb5.1-dev:amd64 -1 as a solution to libdb5.3-dev:amd64
> >>   -1
> >>   Holding Back libdb5.3-dev:amd64 rather than change libdb5.1-dev:amd64
> >>  Try to Re-Instate (1) libdb-dev:amd64
> 
> >> If you care for an explanation of the output:
> >> https://lists.debian.org/deity/2014/01/msg00133.html
> > 
> > This really doesn't explain how to solve this problem and get the
> > apt-get to upgrade libdb-dev.
> 
> > So any ideas how to force the libdb-dev upgrade? I am going to remove
> > libdb5.1*-dev in couple of days, but I just want to make sure that
> 
> That might be sufficient to change scores to make the upgrade work
> smoothly. Right now libdb5.1-dev gets a bonus point for being installed
> and being installable/upgradable, but it won't get that any longer if it
> is an obsolete package (no installation candidate available any more),
> so libdb5.3-dev might win the "fight" instead of making a tie.
> 
> I think the current scores of -1 are the result of
> 
> 5.1: priority:extra = -2
>  installed,installable = +1
>  rdepends: 0
>  ==> -1
> 5.3: priority:extra = -2
>  installed,installable = 0
>  rdepends: +1
>  ==> -1

Indeed, that is the scoring with s/installable/downloadable/.
And it is indeed fixing itself if 5.1 is no longer downloadable.

The thing is that libdb-dev has basically no depends (it has some, but
 based on the popcon, most people must have it installed "standalone"),
so it isn't in a good position to force other packages away aka everyone
who has it "standalone" will have it autokept until the previous version
is gone from the archieve. piuparts e.g. has the same problem, even
through it isn't reporting it as an error as it seems (Andreas?).

I am pretty sure we had talked about the libdb-dev depends libdb?.?-dev
already a few times with the outcome that it is somehow needed to have
multiple non-coinstallable libdb?.?-dev's around instead of doing the
usual unversioned -dev package dance, so I considered it futile to do it
once again and just commented on effect instead of cause.
Or maybe I have mixed that up with boost and/or the other "offenders".

Best regards

David Kalnischkies

signature.asc
Description: Digital signature

Pulseaudio and alsa and accessibility

2014-02-13 Thread Sam Hartman

> "Mario" == Mario Lang writes:

Mario> That is what I was thinking as well, but just recently I had
Mario> to killall pulseaudio to be able to access my ALSA device
Mario> again.

Pulseaudio explicitly bypasses the dmix plugin and opens the alsa
hardware directly.

There's kind of a mess in accessibility land:

* speech-dispatcher holds the audio stream open even when it's not using
it. This prevents pulseaudio from suspending. That sucks both for
battery and because you'll never be able to use a non-pulse interface
to your alsa devices.

* The pulse alsa plugin interacts differently than raw alsa especially
with short audio as produced by a single character from a speech
synthesizer. Raw espeak kind of gives depressing results depending on
what application is driving it and depending on whether you're going
through pulse+alsa or just alsa.

* speech-dispatcher never recovers from a pulse failure.

* Sadly, pulse fails. Sometimes it gives you completely garbled audio,
sometimes it just fails.

* speech-dispatcher and gdm and pulse interact amazingly badly;
generally you get speech for the first login session but the gdm login
window doesn't talk after that.

I've mostly gotten to be happier with pulse than without it.
I've filed some of these as bugs.
I'd definitely be happier if there were an easy way to convince pulse to
go through dmix even if it introduces latency or decreases audio
quality.

--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive:
http://lists.debian.org/01442cede518-3d88583a-0703-4df4-aa83-69915294ac2f-000...@email.amazonses.com

Re: Bug#738839: ITP: mps -- Poor Man's Spotify - Search and stream music

2014-02-13 Thread Zlatan Todoric

Can we just drop it :D I have a good upstream and we were today doing new
description of it :)
latest and probably final - Terminal based MP3 search, playback and
download.

Cheers,

zlatan


On Thu, Feb 13, 2014 at 9:05 PM, Tiago Bortoletto Vaz wrote:

> On Thu, Feb 13, 2014 at 07:57:53PM +0100, Holger Levsen wrote:
> > On Donnerstag, 13. Februar 2014, Matt Zagrabelny wrote:
> > > Packager is using upstream description.
> >
> > upstream has changed the description to "terminal Music Player/Streamer"
> after
> > some private conversation with Zlatan.
>
> plus we don't need to use upstream's description for Debian packages.
> For instance, I've just ITP'ed a "lib to connect things" (according the
> upstream's short description) and of course I'm not going to use it.
>
> > I won't comment on the rest.
>
> I will :)
>
> Regards,
>
> --
>
> 
>   .''`.  Tiago Bortoletto Vaz GPG  :
>  4096R/E4B6813D
>  : :' :  http://acaia.ca/~tiago   XMPP : tiago at
> jabber.org
>  `. `'   tiago _at_ {acaia.ca, debian.org}IRC  :   tiago
> at OFTC
>`-Debian GNU/Linux - The Universal OS
> http://www.debian.org
>
> 
>
>
> --
> To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
> with a subject of "unsubscribe". Trouble? Contact
> listmas...@lists.debian.org
> Archive: http://lists.debian.org/20140213200507.GC31680@gnudaw
>
>


-- 
Please while sending me text documents pay attention that they are by ISO
standard that is in .odt format (For sending other types of documents
please also refer to ISO/Open standars).
Its not the COST, its the VALUE!

Re: Bug#738839: ITP: mps -- Poor Man's Spotify - Search and stream music

2014-02-13 Thread Tiago Bortoletto Vaz

Hi,

On Thu, Feb 13, 2014 at 12:38:55PM -0600, Matt Zagrabelny wrote:
> On Thu, Feb 13, 2014 at 12:31 PM, Holger Levsen  wrote:
> > Hi,
> >
> > On Donnerstag, 13. Februar 2014, Jakub Wilk wrote:
> >> https://en.wiktionary.org/wiki/poor_man%27s
> >
> > I knew that :) I still don't think it's appropriate nor helpful to describe
> > software with these attributes. (Hints: free software is always free as in
> > gratis, and men, well, men^wmeh.)
> 
> Packager is using upstream description. From their website,
> https://github.com/np1/mps
> 
>Poor Man's Spotify - Search and stream music
> 
> In English, the phrase doesn't carry a negative connotation. It is a
> clever way to replace something expensive with something less
> expensive.

It doesn't mean we should use gender-specific words in package
descriptions. Also, there're too many non-english people in Debian
world, so avoiding such expressions we avoid annoying emails coming from
annoying non-english people like me.

Regards,

-- 

  .''`.  Tiago Bortoletto Vaz GPG  :  4096R/E4B6813D
 : :' :  http://acaia.ca/~tiago   XMPP : tiago at jabber.org
 `. `'   tiago _at_ {acaia.ca, debian.org}IRC  :   tiago at OFTC
   `-Debian GNU/Linux - The Universal OS   http://www.debian.org



-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20140213202539.GD31680@gnudaw

Re: Bug#738839: ITP: mps -- Poor Man's Spotify - Search and stream music

2014-02-13 Thread Tiago Bortoletto Vaz

On Thu, Feb 13, 2014 at 07:57:53PM +0100, Holger Levsen wrote:
> On Donnerstag, 13. Februar 2014, Matt Zagrabelny wrote:
> > Packager is using upstream description. 
> 
> upstream has changed the description to "terminal Music Player/Streamer" 
> after  
> some private conversation with Zlatan.

plus we don't need to use upstream's description for Debian packages.
For instance, I've just ITP'ed a "lib to connect things" (according the
upstream's short description) and of course I'm not going to use it.

> I won't comment on the rest.

I will :)

Regards,

-- 

  .''`.  Tiago Bortoletto Vaz GPG  :  4096R/E4B6813D
 : :' :  http://acaia.ca/~tiago   XMPP : tiago at jabber.org
 `. `'   tiago _at_ {acaia.ca, debian.org}IRC  :   tiago at OFTC
   `-Debian GNU/Linux - The Universal OS   http://www.debian.org



-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20140213200507.GC31680@gnudaw

FFmpeg vs. libav packaging (was Re: Proposal: SystemD.pushers/forcers, et cetera)

2014-02-13 Thread Adrian Bunk

On Thu, Feb 13, 2014 at 10:48:52AM +0100, Fabian Greffrath wrote:
> 
> > After ***forcing*** users to use libav instead of ffmpeg in debian
> > therefore making it to stuck with outdated fork istead of rapidly
> > developing original it's too late to talk about freedom.. 
> 
> Gosh, we are not forcing you to use libav, we just considered it better
> at the time a decision had to be made. If you care that much about
> ffmpeg, then get your lazy ass up and help getting it packaged instead
> of spamming on debian-devel.

Hi Fabian,

I fully agree with you that it is not helpful to discuss whether
a decision that was considered better at the time it was made is
also the best in hindsight.

Are you as Debian Multimedia Maintainer willing to discuss which option 
(libav, FFmpeg, some solution of shipping both) will be best for jessie 
based on the information that is available today?

> As long as you don't actively contribute to Debian yourself and try to
> introduce changes to your liking, you will have to deal with other
> people's preferences. It's like that and that's the way it is...
> 
> - Fabian

cu
Adrian

-- 

   "Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
   "Only a promise," Lao Er said.
   Pearl S. Buck - Dragon Seed

-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20140213193747.ga4...@bunk.dyndns.info

Re: Bug#738839: ITP: mps -- Poor Man's Spotify - Search and stream music

On Donnerstag, 13. Februar 2014, Matt Zagrabelny wrote:
> Packager is using upstream description. 

upstream has changed the description to "terminal Music Player/Streamer" after  
some private conversation with Zlatan.



I won't comment on the rest.


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

Re: when will we finally throw away binary uploads (Re: Please upgrade your build environment when you are affected by transition

2014-02-13 Thread Jakub Wilk


* Jacob Appelbaum , 2014-02-13, 18:36:

How many uploaded binaries might include malware?


*shrug* It's not like it's difficult to hide malicious code in source 
packages.


How many configure scripts that we never rebuild from source contains 
trojans?


--
Jakub Wilk


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20140213184653.ga5...@jwilk.net

Re: when will we finally throw away binary uploads (Re: Please upgrade your build environment when you are affected by transition

On Thu, Feb 13, 2014 at 06:36:15PM +, Jacob Appelbaum wrote:
> No kidding!
> 
> How many uploaded binaries might include malware?
> 
> A lack of binary determinism in the build process basically ensures
> that it isn't feasible to discover an answer to this question. :(
> 
> All the best,
> Jacob

I'm sure the https://wiki.debian.org/ReproducibleBuilds team would love
some help!

Cheers,
  Paul

-- 
 .''`.  Paul Tagliamonte   |   Proud Debian Developer
: :'  : 4096R / 8F04 9AD8 2C92 066C 7352  D28A 7B58 5B30 807C 2A87
`. `'`  http://people.debian.org/~paultag
 `- http://people.debian.org/~paultag/conduct-statement.txt


signature.asc
Description: Digital signature

Re: when will we finally throw away binary uploads (Re: Please upgrade your build environment when you are affected by transition

No kidding!

How many uploaded binaries might include malware?

A lack of binary determinism in the build process basically ensures
that it isn't feasible to discover an answer to this question. :(

All the best,
Jacob

On 2/13/14, Holger Levsen  wrote:
> Hi,
>
> On Donnerstag, 13. Februar 2014, Ondřej Surý wrote:
>> this is just a pledge to you all fellow debian developers to update your
>> build environment before you build a package.
>
> I want all binary packages to be rebuild on *.debian.org hosts. Everything
> else is just an ugly workaround.
>
>
> amen,
>   Holger
>
> P.S.: and reproducible builds after that, then...
>


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

Re: Bug#738839: ITP: mps -- Poor Man's Spotify - Search and stream music

2014-02-13 Thread Matt Zagrabelny

On Thu, Feb 13, 2014 at 12:31 PM, Holger Levsen  wrote:
> Hi,
>
> On Donnerstag, 13. Februar 2014, Jakub Wilk wrote:
>> https://en.wiktionary.org/wiki/poor_man%27s
>
> I knew that :) I still don't think it's appropriate nor helpful to describe
> software with these attributes. (Hints: free software is always free as in
> gratis, and men, well, men^wmeh.)

Packager is using upstream description. From their website,
https://github.com/np1/mps

   Poor Man's Spotify - Search and stream music

In English, the phrase doesn't carry a negative connotation. It is a
clever way to replace something expensive with something less
expensive.

-mz


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

Re: Bug#738839: ITP: mps -- Poor Man's Spotify - Search and stream music

Hi,

On Donnerstag, 13. Februar 2014, Jakub Wilk wrote:
> https://en.wiktionary.org/wiki/poor_man%27s

I knew that :) I still don't think it's appropriate nor helpful to describe 
software with these attributes. (Hints: free software is always free as in 
gratis, and men, well, men^wmeh.)


cheers,
Holger


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

Re: Bug#738839: ITP: mps -- Poor Man's Spotify - Search and stream music

2014-02-13 Thread Jakub Wilk


* Holger Levsen , 2014-02-13, 13:11:

  Description : Poor Man's Spotify - Search and stream music


so how is this related to Spotify? Not at all, it's just streaming 
music? (And what has it to do with poverty? And with poor men 
especially?)


https://en.wiktionary.org/wiki/poor_man%27s

--
Jakub Wilk


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20140213180034.ga3...@jwilk.net

when will we finally throw away binary uploads (Re: Please upgrade your build environment when you are affected by transition

Hi,

On Donnerstag, 13. Februar 2014, Ondřej Surý wrote:
> this is just a pledge to you all fellow debian developers to update your
> build environment before you build a package.

I want all binary packages to be rebuild on *.debian.org hosts. Everything 
else is just an ugly workaround.

amen,
Holger

P.S.: and reproducible builds after that, then...

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

Bug#738860: ITP: idba -- iterative De Bruijn Graph De Novo short read assembler for transcriptome

2014-02-13 Thread Andreas Tille

Package: wnpp
Severity: wishlist
Owner: Andreas Tille 

* Package name: idba
  Version : 1.1.1
  Upstream Author : Yu Peng 
* URL : http://i.cs.hku.hk/~alse/hkubrg/projects/idba_tran/
* License : GPL
  Programming Lang: C
  Description : iterative De Bruijn Graph De Novo short read assembler for 
transcriptome
 IDBA-Tran is an iterative De Bruijn Graph De Novo short read assembler
 for transcriptome. It is purely de novo assembler based on only RNA
 sequencing reads. IDBA-Tran uses local assembly to reconstructing
 missing k-mers in low-expressed transcripts and then employs progressive
 cutoff on contigs to separate the graph into components. Each component
 corresponds to one gene in most cases and contains not many transcripts.
 A heuristic algorithm based on pair-end reads is then used to find the
 isoforms.


Remark: This package is maintained by the Debian Med team and the packaging
is available at

   svn://anonscm.debian.org/debian-med/trunk/packages/idba/trunk/


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/20140213153806.31308.86901.report...@mail.an3as.eu

Re: Please upgrade your build environment when you are affected by transition

2014-02-13 Thread Andreas Beckmann

On 2014-02-13 15:37, Ondřej Surý wrote:
> On Thu, Feb 13, 2014, at 15:00, David Kalnischkies wrote:
>> On Thu, Feb 13, 2014 at 01:38:51PM +0100, Ondřej Surý wrote:

>> Broken libdb5.3-dev:amd64 Conflicts on libdb5.1-dev [ amd64 ] < 5.1.29-7
>>> ( libdevel )
>>   Considering libdb5.1-dev:amd64 -1 as a solution to libdb5.3-dev:amd64
>>   -1
>>   Holding Back libdb5.3-dev:amd64 rather than change libdb5.1-dev:amd64
>>  Try to Re-Instate (1) libdb-dev:amd64

>> If you care for an explanation of the output:
>> https://lists.debian.org/deity/2014/01/msg00133.html
> 
> This really doesn't explain how to solve this problem and get the
> apt-get to upgrade libdb-dev.

> So any ideas how to force the libdb-dev upgrade? I am going to remove
> libdb5.1*-dev in couple of days, but I just want to make sure that

That might be sufficient to change scores to make the upgrade work
smoothly. Right now libdb5.1-dev gets a bonus point for being installed
and being installable/upgradable, but it won't get that any longer if it
is an obsolete package (no installation candidate available any more),
so libdb5.3-dev might win the "fight" instead of making a tie.

I think the current scores of -1 are the result of

5.1: priority:extra = -2
 installed,installable = +1
 rdepends: 0
 ==> -1
5.3: priority:extra = -2
 installed,installable = 0
 rdepends: +1
 ==> -1

Andreas


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/52fce558.6000...@debian.org

Re: Bug#738839: ITP: mps -- Poor Man's Spotify - Search and stream music

2014-02-13 Thread Jonathan Dowland

On 13/02/2014 12:11, Holger Levsen wrote:
> so how is this related to Spotify? Not at all, it's just streaming music?
> (And what has it to do with poverty? And with poor men especially?)

You're right that the description needs updating, but "Poor Man's
Spotify" is the upstream name of the software.

(it was renamed from pms to mps to avoid aclash with something else;
however internally it still uses pms a lot and creates e.g. .pms-config,
pms-playlist, pms-debug...)

It does look a bit dodgy though. It appears to use http://pleer.com/ as
a source which looks like a copyright-violation website at first glance.

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

Re: FFmpeg vs. libav packaging (was Re: Proposal: SystemD.pushers/forcers, et cetera)

2014-02-13 Thread Martin Bagge / brother

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On 2014-02-13 14:43, The Wanderer wrote:
> I was not aware that the decision of whether to go with libav or
> with FFmpeg had involved any consideration at all of which one was
> better, only consideration of which one had someone available who
> was willing to do the packaging work.
> 
> Specifically, it was my impression at the time that Reinhard
> Tartler had been the primary person packaging FFmpeg for Debian,
> that he was part of the group that chose to fork FFmpeg into libav,
> that he naturally chose to switch to packaging the forked version
> because he was aligned with that fork, and that no one else stepped
> up to be willing to package FFmpeg in his place.

To me this pretty much qualifies as "libav is better than ffmpeg
because libav is maintained in debian and ffmpeg is not".
If both branches would have been maintained in more or less equal
spirit I don't think we would have dropped one of them. And probably
would have had a wider discussion on which of the two to provide in
the archive based on merits and differences.
I see connections to the MySQL vs MariaDB package effort in this. Just
that we didn't jump to MariaDB - it has been brought in later because
people are doing the ground work to have it in the archive.

- -- 
brother
http://sis.bthstudent.se
-BEGIN PGP SIGNATURE-
Version: GnuPG v1
Comment: Using GnuPG with Icedove - http://www.enigmail.net/

iQEcBAEBCAAGBQJS/NtEAAoJEJbdSEaj0jV7I6oH/2c7tBcoMe+zr4JHvOi8owsK
VHPfwYYr+d389dZEko7SFb8gYp9YJUEXyAnrzAmrRGw/s3552a1p/91qhzCd+a+W
j8X/rjqmK3wXK1+59hiR2rNaHh1tcZOKafbqRgGilmkMBK02xt81QMGTGKBfKjbx
Gl3vXKFmeqbTz53UIpencga0l5wfRCi95bjqiBwFGBiZ1rKDsx0EKzKbF+4RZbb3
HjzTsDJNsKf65YPrkcabDMNI9abog2oWb9u2790Pee8QAY7fgLK5pLZcnHGz0j4c
kG9S2QzAKhNujDCFf4cw6ZWCiZxqWCz8JYUB7u0clvEpiuciLtV3FTr3YVo/BGY=
=C9E4
-END PGP SIGNATURE-


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/52fcdb44.2000...@bsnet.se

Re: Please upgrade your build environment when you are affected by transition

On Thu, Feb 13, 2014, at 15:00, David Kalnischkies wrote:
> 
> On Thu, Feb 13, 2014 at 01:38:51PM +0100, Ondřej Surý wrote:
> > this is just a pledge to you all fellow debian developers to update your
> > build environment before you build a package.
> > 
> > This mostly affects transitions, f.e.:
> > 
> > https://release.debian.org/transitions/html/db5.3.html
> 
> The problem is "just" that apt isn't following your transition.
> In fact, on all my machines libdb-dev is on autohold…
> 
> $ LANG=C apt-get dist-upgrade -s -o Debug::pkgProblemResolver=1
> Reading package lists... Done
> Building dependency tree
> Reading state information... Done
> Calculating upgrade... Starting pkgProblemResolver with broken count: 2
> Starting 2 pkgProblemResolver with broken count: 2
> Investigating (0) libdb-dev [ amd64 ] < 5.1.7 -> 5.3.0 > ( libdevel )
> Broken libdb-dev:amd64 Conflicts on libdb5.1-dev [ amd64 ] < 5.1.29-7 > (
> libdevel )
>   Considering libdb5.1-dev:amd64 -1 as a solution to libdb-dev:amd64 -1
>   Holding Back libdb-dev:amd64 rather than change libdb5.1-dev:amd64
> Investigating (0) libdb5.3-dev [ amd64 ] < none -> 5.3.28-3 > ( libdevel
> )
> Broken libdb5.3-dev:amd64 Conflicts on libdb5.1-dev [ amd64 ] < 5.1.29-7
> > ( libdevel )
>   Considering libdb5.1-dev:amd64 -1 as a solution to libdb5.3-dev:amd64
>   -1
>   Holding Back libdb5.3-dev:amd64 rather than change libdb5.1-dev:amd64
>  Try to Re-Instate (1) libdb-dev:amd64
> Done
> Done
> Starting pkgProblemResolver with broken count: 0
> Starting 2 pkgProblemResolver with broken count: 0
> Done
> The following packages have been kept back:
>   libdb-dev
> 0 upgraded, 0 newly installed, 0 to remove and 1 not upgraded.

JFTR This is first time I have ever heard of this. There's no bug report
related to this, so I can hardly do anything about that if I am not
aware of the issue.

> If you care for an explanation of the output:
> https://lists.debian.org/deity/2014/01/msg00133.html

This really doesn't explain how to solve this problem and get the
apt-get to upgrade libdb-dev.

And no I am not going to allow simultaneous installation of libdb5.1-dev
and libdb5.3-dev. I have seen too much broken builds related to
compiling with X.Y headers and linking with X.Z headers. This would be a
way to enter the madness (Berkeley DB is very close to DLL hell).

So any ideas how to force the libdb-dev upgrade? I am going to remove
libdb5.1*-dev in couple of days, but I just want to make sure that
maintainers directly depending on libdb5.1*dev (and not the generic
package) have a time to fix their packages, e.g.:

https://bugs.debian.org/738645
https://bugs.debian.org/738641
https://bugs.debian.org/738650

spamprobe has been NMUed by me since it's orphaned and gridengine has
been uploaded to DELAYED/10.

exim4 was promptly fixed by it's maintainers (and thank you for that
very quick response).

I am going to wait for openldap folks to react, and then I will stop
building -dev packages out of src:db (same thing that has happened with
db4.7 and db4.8 in wheezy).

> So, while I am not a DD and therefore completely unresponsible for your
> transition not working as you wish, I would suggest that you might not
> want to point out the faults of your fellow DDs if you don't work on
> your own as this is hardly the first time that this happens and isn't
> resolved by using a pristine environment…

I wasn't pointing to anybody's faults, I was merely asking them to
please upgrade their build environment, when they are responsible for
packages under transition.

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: 
http://lists.debian.org/139230.17282.82981781.6e443...@webmail.messagingengine.com

Re: Bug#727708: Fsck SystemD and its developers and its users. GR to override this please.

2014-02-13 Thread Jeff Epler

For software that is incompatible with pulseaudio, prefix the command
with 'pasuspender':
 $ pasuspender oss-or-alsa-only-program args...

Jeff


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20140213140127.gb85...@unpythonic.net

Re: Please upgrade your build environment when you are affected by transition

2014-02-13 Thread David Kalnischkies


On Thu, Feb 13, 2014 at 01:38:51PM +0100, Ondřej Surý wrote:
> this is just a pledge to you all fellow debian developers to update your
> build environment before you build a package.
> 
> This mostly affects transitions, f.e.:
> 
> https://release.debian.org/transitions/html/db5.3.html

The problem is "just" that apt isn't following your transition.
In fact, on all my machines libdb-dev is on autohold…

$ LANG=C apt-get dist-upgrade -s -o Debug::pkgProblemResolver=1
Reading package lists... Done
Building dependency tree
Reading state information... Done
Calculating upgrade... Starting pkgProblemResolver with broken count: 2
Starting 2 pkgProblemResolver with broken count: 2
Investigating (0) libdb-dev [ amd64 ] < 5.1.7 -> 5.3.0 > ( libdevel )
Broken libdb-dev:amd64 Conflicts on libdb5.1-dev [ amd64 ] < 5.1.29-7 > ( 
libdevel )
  Considering libdb5.1-dev:amd64 -1 as a solution to libdb-dev:amd64 -1
  Holding Back libdb-dev:amd64 rather than change libdb5.1-dev:amd64
Investigating (0) libdb5.3-dev [ amd64 ] < none -> 5.3.28-3 > ( libdevel )
Broken libdb5.3-dev:amd64 Conflicts on libdb5.1-dev [ amd64 ] < 5.1.29-7 > ( 
libdevel )
  Considering libdb5.1-dev:amd64 -1 as a solution to libdb5.3-dev:amd64 -1
  Holding Back libdb5.3-dev:amd64 rather than change libdb5.1-dev:amd64
 Try to Re-Instate (1) libdb-dev:amd64
Done
Done
Starting pkgProblemResolver with broken count: 0
Starting 2 pkgProblemResolver with broken count: 0
Done
The following packages have been kept back:
  libdb-dev
0 upgraded, 0 newly installed, 0 to remove and 1 not upgraded.

If you care for an explanation of the output:
https://lists.debian.org/deity/2014/01/msg00133.html

So, while I am not a DD and therefore completely unresponsible for your
transition not working as you wish, I would suggest that you might not
want to point out the faults of your fellow DDs if you don't work on
your own as this is hardly the first time that this happens and isn't
resolved by using a pristine environment…
(or it is, but most of the 3678 popcon users will not have one)


(The only thing I am responsible for is trying out my own idea so far,
 but regardless of the outcome of such a try, it wouldn't help you
 here as your transition has to work with apt in *wheezy* and not
 with the "broken" version ending up in jessie …)

Best regards

David Kalnischkies


signature.asc
Description: Digital signature

FFmpeg vs. libav packaging (was Re: Proposal: SystemD.pushers/forcers, et cetera)

2014-02-13 Thread The Wanderer

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

On 02/13/2014 04:48 AM, Fabian Greffrath wrote:

>> After ***forcing*** users to use libav instead of ffmpeg in debian
>> therefore making it to stuck with outdated fork istead of rapidly
>> developing original it's too late to talk about freedom..
> 
> Gosh, we are not forcing you to use libav, we just considered it
> better at the time a decision had to be made.

I was not aware that the decision of whether to go with libav or with
FFmpeg had involved any consideration at all of which one was better,
only consideration of which one had someone available who was willing to
do the packaging work.

Specifically, it was my impression at the time that Reinhard Tartler had
been the primary person packaging FFmpeg for Debian, that he was part of
the group that chose to fork FFmpeg into libav, that he naturally chose
to switch to packaging the forked version because he was aligned with
that fork, and that no one else stepped up to be willing to package
FFmpeg in his place.

If the decision was in fact not made entirely by Reinhard, and there was
actual discussion internal to Debian which would confirm the fact, I'd
be interested to see it.

> If you care that much about ffmpeg, then get your lazy ass up and
> help getting it packaged instead of spamming on debian-devel.

While I agree that "spamming" debian-devel about it is likely not
helpful (at least not at this stage, and especially not in the terms
which were used), if you read the current RFP/ITP (hybrid) bug which was
linked elsewhere in this branch of the thread, it doesn't seem to be
that simple.

> As long as you don't actively contribute to Debian yourself and try
> to introduce changes to your liking, you will have to deal with other
> people's preferences. It's like that and that's the way it is...

Quite true, which is at least one-third of the reason I didn't speak up
against the switch to libav at the time when it happened. Reinhard
preferred it, and he was the one doing the work.

- --
   The Wanderer

Secrecy is the beginning of tyranny.

A government exists to serve its citizens, not to control them.
-BEGIN PGP SIGNATURE-
Version: GnuPG v1
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQIcBAEBCgAGBQJS/Mv/AAoJEASpNY00KDJrxwYP/i/MmRV3mzl3vVfSFTndP12l
E3XVizeAvl0g5gLBsQ26spuOHFW1KOpmTYBHGOu2pa1JdbeMh+lsOIIn6RZods6O
lNaQuMCMdSSYl52HvfZV/YM0k6wsYpBotkeU1xy7LeqTBYw52ILEhYtG+ZRK65jF
Nt+ipqeb2pseG+z0qPFtB0QSW/LTaENQosPLky2xOZpC/WdHwXPGegY1UJCq7zCU
/R7SEx8+yPXW3siC97ZFzo39xfap+6OtFRr2QXxSb3MM1QdRg+ZFG2uPgDlnf9wq
XMqzjl4vfjqu290zjmJXSo8tgd/utjs9UNGCNqm3FrOXqDufgZ3ZAyOf6NhkKB59
V5mOvRIb83aWm7c+mqscQYFeuPVrcpnrobxVUzwmzwMv68EIHN3VBhnXVHMuamwZ
w2e+e/saMZhgBuNf91mkxGizn+3UOxcqYY5BaoBpOmvndUQa2+pBIQDGiVHq99Rd
23GzfXV5Jx7kOoCH5lp9CwRyVVpdaRYC5GzSbwqUncN1bF1wQImJImoJNuIzEFQA
UwFaGKa2hRiAqPeTISll4B6zuCrnWZBFAieAdS9xBU5vhgjuyNJTQueuXUVVKDkN
bj2fvGlG3yDTGXL16eJCO8A2bBlVrPmF7+tZRqMXEHMR/DDv2TlMZTg+eW99tboj
+JhRTfwpwwVKcGQDpHqM
=1gRX
-END PGP SIGNATURE-

-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/52fccbff.7000...@fastmail.fm

Re: Bug#727708: Fsck SystemD and its developers and its users. GR to override this please.

2014-02-13 Thread Mario Lang

Stephan Seitz  writes:

> On Wed, Feb 12, 2014 at 11:39:06AM +, Darac Marjal wrote:
>>> But the normal case is that uninstalling a software you also stop
>>> getting the functionality it provides, with pulseaudio you START
>>> getting the functionality it claims to provide by uninstalling it.
>>Really? Uninstalling Pulseaudio gives you a graphical interface for
>>moving streams of audio between devices? Uninstalling Pulseaudio gives
>>you software mixing of audio streams? Uninstalling Pulseaudio gives you
>
> Alsa is using the DMIX plugin for years, and before that I always had
> soundcards with hardware mixing. Simply buy the proper tools.

That is what I was thinking as well, but just recently I had
to killall pulseaudio to be able to access my ALSA device again.

For me, pulseaudio falls into the same category as network-manager.
Whenever I had to deal with it, it didnt do what I expected.

-- 
CYa,
  ⡍⠁⠗⠊⠕


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/87lhxfrvk8@fx.delysid.org

Bug#738851: ITP: php-file-fstab -- Read and write fstab files

2014-02-13 Thread Francois-Regis Vuillemin

Package: wnpp
Severity: wishlist
Owner: "Francois-Regis Vuillemin" 

* Package name: php-file-fstab
  Version : 2.0.3
  Upstream Author : Ian Eure 
* URL : http://pear.php.net/package/File_Fstab
* License : PHP
  Programming Lang: PHP
  Description : Read and write fstab files

File_Fstab is an easy-to-use package which can read & write UNIX fstab files.
It presents a pleasant object-oriented interface to the fstab.
Features:
* Supports blockdev, label, and UUID specification of mount device.
* Extendable to parse non-standard fstab formats by defining a new Entry class
for that format.
* Easily examine and set mount options for an entry.
* Stable, functional interface.
* Fully documented with PHPDoc.

It is a dependency for horde3


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/20140213131654.15741.19953.report...@graves.miradou.com

Bug#738850: ITP: iniparser -- a stand-alone INI file reading/writing library

2014-02-13 Thread Klee Dienes

Package: wnpp
Severity: wishlist
Owner: Klee Dienes 

* Package name: iniparser
  Version : 3.1-1
  Upstream Author : Nicolas Devillard 
* URL : http://ndevilla.free.fr/iniparser
* License : Expat
  Programming Lang: C
  Description : a stand-alone INI file reading/writing library

The iniParser library is a simple C library offering INI file parsing
services (both reading and writing).

---

Note that there have been two previous ITPs posted for iniParser:

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

There was concern in the discussion for #678142 about:

 1) Lack of a well-formed build/install system (iniParser includes only
a bare-bones Makefile).

 2) Complexity ("Does anything depend on this, any potential users that
couldn't use something simpler?")

I have addressed #1 by providing a CMake build environment for use by
the Debian package.

Regarding #2, my goal is to package the psmoveapi code for Debian,
which uses the write support of iniparser (not supported by inih).  I
also note that Samba seems to include an internal version of
iniParser.


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/20140213131252.21930.21878.report...@router.dienesfamily.org

Re: Need advice on building a package

2014-02-13 Thread Matthias Urlichs

Hi,

John Holland:
> I set up my repo with debarchiver. Is mini-dinstall a better way to go?
> Maybe I should redo it that way?
> 
You might also want to look into reprepro.

-- 
-- Matthias Urlichs


signature.asc
Description: Digital signature

Re: Bug#727708: Fsck SystemD and its developers and its users. GR to override this please.

2014-02-13 Thread Oleg

On Thu, Feb 13, 2014 at 01:16:22PM +0100, Ond??ej Sur?? wrote:
> So if you want to have Debian installation without systemd, then go help
> him with OpenRC, help writing new openrc init scripts to replace old
> rusty sysv-rc script, etc. That's the way to go forward. Just don't
> expect other people to do it for you.

You are right. I already spent my free time in various projects, but i can't
do everything.

About OpenRC, it looks very good in contrast of systemd.


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20140213123350.GA11303@localhost

Re: Please upgrade your build environment when you are affected by transition

On Thu, Feb 13, 2014, at 13:45, Andrey Rahmatullin wrote:
> On Thu, Feb 13, 2014 at 01:38:51PM +0100, Ondřej Surý wrote:
> > Hi,
> > 
> > this is just a pledge to you all fellow debian developers to update your
> > build environment before you build a package.
> > 
> > This mostly affects transitions, f.e.:
> > 
> > https://release.debian.org/transitions/html/db5.3.html
> > 
> > apt, heimdal, jack-audio-connection-kit, python3.3, python3.4 and
> > squidguard could have already finished the transition if they haven't
> > been built with libdb5.1.
> Isn't that one of problems fixed by rebuilding everything on buildds?

Yes, but since we don't have that (yet)... :)

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: 
http://lists.debian.org/1392295865.26725.82947937.3642e...@webmail.messagingengine.com

Re: Please upgrade your build environment when you are affected by transition

2014-02-13 Thread Andrey Rahmatullin

On Thu, Feb 13, 2014 at 01:38:51PM +0100, Ondřej Surý wrote:
> Hi,
> 
> this is just a pledge to you all fellow debian developers to update your
> build environment before you build a package.
> 
> This mostly affects transitions, f.e.:
> 
> https://release.debian.org/transitions/html/db5.3.html
> 
> apt, heimdal, jack-audio-connection-kit, python3.3, python3.4 and
> squidguard could have already finished the transition if they haven't
> been built with libdb5.1.
Isn't that one of problems fixed by rebuilding everything on buildds?

-- 
WBR, wRAR


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

Please upgrade your build environment when you are affected by transition

Hi,

this is just a pledge to you all fellow debian developers to update your
build environment before you build a package.

This mostly affects transitions, f.e.:

https://release.debian.org/transitions/html/db5.3.html

apt, heimdal, jack-audio-connection-kit, python3.3, python3.4 and
squidguard could have already finished the transition if they haven't
been built with libdb5.1.

Thanks for caring about that,
-- 
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: 
http://lists.debian.org/1392295131.23481.82943513.2a802...@webmail.messagingengine.com

Re: Bug#727708: Fsck SystemD and its developers and its users. GR to override this please.

On Wed, Feb 12, 2014, at 11:28, Oleg wrote:
>   I'm using debian and i don't want to use systemd in any form (with
>   gnome3,  etc).

So what? Should we stand in awe that you are Debian user?

I certainly care about (well most of) the users of my packages, but this
attitude makes me really angry and frustrated. Debian is a community
project and we all have invested enormous amounts of our free time,
employer time, etc.

If you _WANT_ something to happen, you _HAVE TO_ invest _YOUR TIME_ (or
money, I am quite sure that you would be able to get several DD on your
paycheck, etc.). If you don't want to use systemd, then it's YOUR burden
to make it happen. Expecting things to happen your way by just bitching
around^W^Wcomplaining on the mailing list is so selfish from you that
you should be ashamed of yourself.

Just to give you an example. Although I think that the systemd is the
best choice for Debian, I really admire Thomas Goirand for putting his
money where his mouth is. He believes in OpenRC and he invested his own
time to make it work on Debian (and kFreeBSD and Hurd). And I quite
happy to support his effort within my packages with init scripts to make
my packages work with alternative init systems (just no more of sysv-rc
please).

So if you want to have Debian installation without systemd, then go help
him with OpenRC, help writing new openrc init scripts to replace old
rusty sysv-rc script, etc. That's the way to go forward. Just don't
expect other people to do it for you.

And if you don't want to invest energy in something you believe in and
you want just to complain, then with all due respect just shut up,
please.

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: 
http://lists.debian.org/1392293782.19499.82933453.0de66...@webmail.messagingengine.com

Re: Bug#738839: ITP: mps -- Poor Man's Spotify - Search and stream music