Re: Lintian auto-reject changes

[Matthias Klose]

On 06/17/2015 11:17 PM, Joerg Jaspert wrote:
> Hi,
> 
> we got one more lintian auto-reject active on ftp-master, in dak.git 
> commit e0364a10b4a8ab37dd6527bbd1ba67a2f43da9cc
> 
> Everything hitting "empty-binary-package" is a *nonfatal* reject now.

How does this make packages better?

Is there any documented criteria for these auto-rejects?

> Thanks to Jakub Wilk. Eventual tarring and feathering too please, but
> for common amusement do it where the DebConf Video Team can record it. :)

thanks for the advance notice about this activation.

Matthias



-- 
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/55829ac2.3050...@debian.org

Re: Lintian auto-reject changes

[Michael Biebl]

Am 18.06.2015 um 12:17 schrieb Matthias Klose:
> On 06/17/2015 11:17 PM, Joerg Jaspert wrote:
>> Hi,
>>
>> we got one more lintian auto-reject active on ftp-master, in dak.git 
>> commit e0364a10b4a8ab37dd6527bbd1ba67a2f43da9cc
>>
>> Everything hitting "empty-binary-package" is a *nonfatal* reject now.
> 
> How does this make packages better?

I would assume, the intention here is to catch broken packages, which
have not been tested by the maintainer and ended up empty.




-- 
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: Lintian auto-reject changes

[Simon McVittie]

On 18/06/15 11:17, Matthias Klose wrote:
> On 06/17/2015 11:17 PM, Joerg Jaspert wrote:
>> Everything hitting "empty-binary-package" is a *nonfatal* reject now.
> 
> How does this make packages better?

By avoiding bugs like . Most packagers
meant to package something (and it's non-fatal so that metapackages that
have no documentation beyond the standard changelog, copyright etc. can
override it).

S


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

Re: Lintian auto-reject changes

[Jakub Wilk]

* Simon McVittie , 2015-06-18, 11:26:

Everything hitting "empty-binary-package" is a *nonfatal* reject now.

How does this make packages better?
By avoiding bugs like . Most packagers 
meant to package something (and it's non-fatal so that metapackages 
that have no documentation beyond the standard changelog, copyright 
etc. can override it).


To clarify, majority of metapackages don't even need overrides for this, 
because Lintian is smart enough to guess from the package description or 
section that it's okay that this package is empty.


--
Jakub Wilk


--
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/20150618110036.ga1...@jwilk.net

Re: Lintian auto-reject changes

[Emilio Pozuelo Monfort]

On 18/06/15 13:00, Jakub Wilk wrote:
> * Simon McVittie , 2015-06-18, 11:26:
 Everything hitting "empty-binary-package" is a *nonfatal* reject now.
>>> How does this make packages better?
>> By avoiding bugs like . Most packagers meant
>> to package something (and it's non-fatal so that metapackages that have no
>> documentation beyond the standard changelog, copyright etc. can override it).
> 
> To clarify, majority of metapackages don't even need overrides for this, 
> because
> Lintian is smart enough to guess from the package description or section that
> it's okay that this package is empty.

Same applies to transitional packages.

Emilio


-- 
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/5582a691.6010...@debian.org

Re: RFH: dropbear initramfs support

[Gerrit Pape]

On Sat, May 30, 2015 at 02:09:16AM +0200, Guilhem Moulin wrote:
> On Fri, 01 Aug 2014 at 20:29:41 +, Gerrit Pape wrote:
> > Generally I'm with upstream who wrote in bug#692932:
> >> As Dropbear upstream I'm keen to see this fixed. Given how
> >> many Debian Dropbear bugs are in the initramfs portion,
> >> perhaps the initramfs setup of Dropbear should go into its
> >> own package for people who want it?
> > 
> > So here again my call for help, or better a new maintainer for the
> > initramfs functionality, prabably in a separate package.  I'd be happy
> > to split this out.
> 
> I rely heavily on that feature on many of my machines, and I see (quite
> late, sorry for that) that it's now in need of love ;-)  I have now
> started to fix some of the initramfs-related bugs, and would be happy to
> take over the maintenance of the new package should you split it out.
> (Which IMHO makes sense, as I don't think many dropbear users use that
> feature.)
> 
> However I'm am only a DM not a DD yet, so I would need a sponsor (at the
> beginning at least).  I've also got a few questions regarding the new
> package.
> 
>   - Should it be included in src:dropbear?
>   - I guess it should be depending on dropbear.  However only the
> dropbear binary is interesting, not the configuration files or init
> scripts.  Is there a recommended way to proceed in that kind of
> situation?  (For instance “NO_START=1” in /etc/default/dropbear is
> probably only useful for people that put dropbear in the initramfs.)

Hi Guilhem, sorry for the delayed reply, I'm not really active in Debian
development currently.

Thanks for the help.  I'd be happy to have the initramfs functionality
split out and maintained separately.  If a binary/service split is
necessary, I'd prefer to have a "dropbear" package with the binaries,
and a "dropbear-run" package with the service.

Unfortunately I cannot support you, but don't hesitate to NMU the
dropbear package to be able to proceed.

Best Regards, Gerrit.


-- 
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/20150618112304.403.qm...@e5f139fa48b675.315fe32.mid.smarden.org

Re: preparing for GCC 5, especially libstdc++6

[Matthias Klose]

On 06/17/2015 09:42 PM, Lisandro Damián Nicanor Pérez Meyer wrote:
> On Tuesday 16 June 2015 23:37:41 Matthias Klose wrote:
>> Hi,
>>
>> it's time to prepare for GCC 5 as the default compiler in unstable. 
>> Compared to earlier version bumps, the switch to GCC 5 is a bit more
>> complicated because libstdc++6 sees a few ABI incompatibilities, partially
>> depending on the C++ standard version used for the builds.  libstdc++6 will
>> support two ABI's, the classic cxx98 ABI (currently in testing/unstable)
>> and the new cxx11 ABI (currently enabled in experimental as the default
>> ABI).
> 
> Hi Matthias!
> 
> [snip]
> 
>> My goal is to make the GCC version bump in early July, and use the time
>> until then to prepare libstdc++6 depending packages to get ready for GCC 5,
>> and avoiding version bumps for C++ libraries until this time.
> 
> As you already know we the Qt/KDE team, in order to avoid an ABI break, need 
> to either:
> 
> a) Push Qt 5.4.2 to unstable before gcc5 becomes the default compiler. This 
> is 
> currently not an option due to #787689.
> 
> b) Push Qt 5.4.2 to unstable at the same time as gcc5 becomes the default 
> (well, one or two dinstalls later maybe). If some package gets compiled with 
> gcc5 and Qt < 5.4.2 in the meantime we can binNMU it.
> 
> c) Push Qt 5.4.2 to unstable a couple of days before gcc5 becomes the 
> default. 
> Once gcc5 becomes the default ask for a give back in armhf.
> 
> d) Push Qt 5.4.2 to unstable either by forcing gcc5 as default at build time 
> or working around the bug. I would definitely would like to avoid this option 
> as:
>   - The current Qt stack is comprised of 25 source packages. I don't think me
> or my teammates will have the time to hack all of them before beginnings
> of July.
>   - I don't know if some other lib/app that build depends on qt5 will still
> have the issue on armhf if we workaround it.
>   - I don't know what happens if Qt5 gets built against gcc5 but apps against
> gcc4.9. Possibly and hopefully nothing, but I just don't know.
> 
> My current preference would be acb (totally discarding d), but I'm open to 
> suggestions too.

I would prefer b), and preparing the packages to build with the gcc-5 from
experimental (not unstable).  Does Qt 5.4.2 change sonames? If not, please
prepare to change the library package names, if new cxx11 symbols are 
introduced.

Matthias


-- 
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/5582c0bb.7010...@debian.org

Re: Is the Debian dependency system broken? (wget vs libgnutls-deb0-28)

[Jonathan Dowland]

On Sun, Jun 14, 2015 at 06:43:33PM +0200, Marc Haber wrote:
> btw, please read up on bug severities. I consider filing this bug as
> "grave" quite short of being offensive.

If you're genuinely offended by a bug submitter's choice of severity, it's time
to take a step back from the computer and get a cup of tea.


-- 
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/20150618130738.gb21...@chew.redmars.org

Re: RFH: dropbear initramfs support

[Guilhem Moulin]

Hi Gerrit,

On Thu, 18 Jun 2015 at 11:23:04 +, Gerrit Pape wrote:
> Thanks for the help.  I'd be happy to have the initramfs functionality
> split out and maintained separately.  If a binary/service split is
> necessary, I'd prefer to have a "dropbear" package with the binaries,
> and a "dropbear-run" package with the service.

As I mentioned when answering [0] Simon earlier in this thread, the
downside of reusing the “dropbear” name (without an explicit Depends:
dropbear-initramfs) is that users might brick their system when
upgrading.  Would you find Adam's solution [1] acceptable, i.e. make
“dropbear” a transitional package depending on both “dropbear-run”
(service) and “dropbear-initramfs”, which both in turn depend on
“dropbear-bin” (binaries).  As Adam noted, the “dropbear” name would be
available again in Buster.
 
> Unfortunately I cannot support you, but don't hesitate to NMU the
> dropbear package to be able to proceed.

Will do, thanks.  This will also be the occasion to upgrade to 2015.67
[2] :-)

-- 
Guilhem.

[0] https://lists.debian.org/debian-devel/2015/06/msg0.html
[1] https://lists.debian.org/debian-devel/2015/06/msg1.html
[2] https://matt.ucc.asn.au/dropbear/CHANGES


signature.asc
Description: Digital signature

Re: Lintian auto-reject changes

[Joerg Jaspert]

On 13976 March 1977, Matthias Klose wrote:
> On 06/17/2015 11:17 PM, Joerg Jaspert wrote:
>> Everything hitting "empty-binary-package" is a *nonfatal* reject now.
> How does this make packages better?

It does not "make packages better". No lintian check (or reject based on
one) does it. It helps catch mistakes. Example for this one has been
elsewhere in the thread. Most cases of empty packages that are hit by
this check are uploads that shouldn't happen, and for the few ones where
it should be empty - thats why it is nonfatal.

-- 
bye, Joerg
You know, boys, a nuclear reactor is a lot like a woman. You just have
to read the manual and press the right buttons.


-- 
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/87381pyvy6@gkar.ganneff.de

Re: RFH: dropbear initramfs support

[Gerrit Pape]

On Thu, Jun 18, 2015 at 03:09:26PM +0200, Guilhem Moulin wrote:
> Hi Gerrit,
> 
> On Thu, 18 Jun 2015 at 11:23:04 +, Gerrit Pape wrote:
> > Thanks for the help.  I'd be happy to have the initramfs functionality
> > split out and maintained separately.  If a binary/service split is
> > necessary, I'd prefer to have a "dropbear" package with the binaries,
> > and a "dropbear-run" package with the service.
> 
> As I mentioned when answering [0] Simon earlier in this thread, the
> downside of reusing the “dropbear” name (without an explicit Depends:
> dropbear-initramfs) is that users might brick their system when
> upgrading.  Would you find Adam's solution [1] acceptable, i.e. make
> “dropbear” a transitional package depending on both “dropbear-run”
> (service) and “dropbear-initramfs”, which both in turn depend on
> “dropbear-bin” (binaries).  As Adam noted, the “dropbear” name would be
> available again in Buster.

Sounds good, yes, I find it acceptable.  Thanks again for your work on
the packages!

Regards, Gerrit.


-- 
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/20150618133821.6905.qm...@a53e6efeb2828f.315fe32.mid.smarden.org

RFH: os-autoinst and make test script for d-i

[Hideki Yamane]

Hi,

 As Bug#690244 I've filed ITP some years ago... and now I've done it ;)
 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=690244

 os-autoinst is automated testing tool for low-level, such as bootloader,
 kernel and installer using kvm. So, we can test installer automatically,
 probably some of your are interested in it.
 https://github.com/os-autoinst/os-autoinst

 You can get deb package from
 dget http://www.ma-aya.net/~henrich/debian/package/temp/os-autoinst_4.1-1.dsc
 or wget 
http://www.ma-aya.net/~henrich/debian/package/temp/os-autoinst_4.1-1_amd64.deb


 And, it's just a tool, we should make our own test script for our d-i
 like https://github.com/os-autoinst/os-autoinst-distri-opensuse
 Then, I'll ask you to try it (I just package it, not heavily use it).

 This package is not uploaded yet (since copyright issue is not solved),
 but it's better to tell you before it since we don't waste a time for
 waiting it.


-- 
Regards,

 Hideki Yamane henrich @ debian.or.jp/org
 http://wiki.debian.org/HidekiYamane


-- 
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/20150618230135.0331d3740461065baf7ed...@debian.or.jp

Re: preparing for GCC 5, especially libstdc++6

[Lisandro Damián Nicanor Pérez Meyer]

On Thursday 18 June 2015 14:59:39 Matthias Klose wrote:
[snip] 
> I would prefer b), and preparing the packages to build with the gcc-5 from
> experimental (not unstable).

OK.

> Does Qt 5.4.2 change sonames? If not, please
> prepare to change the library package names, if new cxx11 symbols are
> introduced.

No and no std symbols are exposed. We are not expecting breakage in that 
front, counting from the experience of other distros.

So far the only "breakage" I have seen are constructors/destructors 
[dis]appearing, which is just normal stuff and can be fixed by a simple 
symbols fix.For that we just need for all archs to build the packages and then 
fix them.

-- 
Lisandro Damián Nicanor Pérez Meyer
http://perezmeyer.com.ar/
http://perezmeyer.blogspot.com/


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

Re: Adding support for LZIP to dpkg, using that instead of xz, archive wide

[Jeremy Stanley]

On 2015-06-18 02:31:57 + (+), Clint Adams wrote:
> No, in this particular case, upstream IS releasing source tarballs
> and the packagers are refusing to use them for reasons I find
> incomprehensible.

Well, for some of the packages in question where I'm involved
upstream, we still aren't providing PGP-signatures for some of those
tarballs (not even PGP-signed checksum lists). Some are uploaded to
Launchpad and a release manager uploads a signature along with it,
some are auto-published to other places by our build systems and
sometimes a release manager sends a signed release announcement to a
few mailing lists hopefully including strong checksums of the
tarballs, but there are plenty where CI automation is building the
tarballs (based on signed tags in a VCS of course) and uploading
them without a corresponding signature.

I'm planning to rectify that to some extent by having trusted
systems in our build infrastructure create and upload signatures
with them, but depending on a package maintainers trust preferences
that may not be seen as a strong enough attestation. On the other
hand, I run Debian testing and unstable on a lot of systems and have
a fairly strong degree of faith in the automatic archive signing
keys... we'd definitely be following similar measures to cross-sign,
secure and rotate our automatic tarball signing keys.
-- 
Jeremy Stanley


signature.asc
Description: Digital signature

Bug#789171: ITP: libxmlbird -- XML parser written in Vala

[Hideki Yamane]

Package: wnpp
Severity: wishlist
Owner: Hideki Yamane 
X-Debbugs-CC: debian-devel@lists.debian.org, 
pkg-fonts-de...@lists.alioth.debian.org, johan.mattsso...@gmail.com

   Package name: libxmlbird
Version: 1.0.4
Upstream Author: Johan Mattsson 
URL: http://birdfont.org/xmlbird-releases.php 
License: LGPL-3.0+

Description: XML parser written in Vala

 XML Bird is a library for parsing documents written in the Exensible Markup 
 Language (XML). This parser is written in Vala and has support for Vala
 iterators. This makes it possible to loop over all tags and attributes in
 the document using the foreach statement. 

 It's necessary for birdfont build.

-- 
Regards,

 Hideki Yamane henrich @ debian.or.jp/org
 http://wiki.debian.org/HidekiYamane


-- 
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/20150618235641.799ad4ba2bbd3ca746821...@debian.or.jp

Clarifications about the alleged transition to FFmpeg

[Alessio Treglia]

Hello everybody,

I am afraid that I have to inform you that Bálint's blog post [1]
about the current status of libav's provided is untrue as there's
still a discussion ongoing on the Debian Multimedia Maintainers' team
mailing list, and a clear outcome is yet to come.
We'll eventually get in touch with the release team once we've taken a
final decision on the matter.

Last but not least, just a small memo for Bálint: please refrain from
playing dirty, we have had quite enough of your behaviour.


Cheers.

[1] http://balintreczey.hu/blog/debian-is-preparing-the-transition-to-ffmpeg/

-- 
Alessio Treglia  | www.alessiotreglia.com
Debian Developer | ales...@debian.org
Ubuntu Core Developer|  quadris...@ubuntu.com
0416 0004 A827 6E40 BB98 90FB E8A4 8AE5 311D 765A


--
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/CAMHuwow-yGVD_2+VQL7VGK9+v=_bsfdrz13h-zx2bh1so62...@mail.gmail.com

Re: Clarifications about the alleged transition to FFmpeg

[Bálint Réczey]

Hi Alessio,

2015-06-18 18:00 GMT+02:00 Alessio Treglia :
> Hello everybody,
>
> I am afraid that I have to inform you that Bálint's blog post [1]
> about the current status of libav's provided is untrue as there's
> still a discussion ongoing on the Debian Multimedia Maintainers' team
> mailing list, and a clear outcome is yet to come.
> We'll eventually get in touch with the release team once we've taken a
> final decision on the matter.
Untrue is a nice word, but AFAIK the Multimedia Team which I'm member
of at the moment is really working out the details of the transition.
While the team has not announced a formal decision the majority of the
team supports FFmpeg (which you don't ;-).
It also not clear how the team can make a formal decision since there
is no official leader, just members,not all listed members
participated in the discussion.
From: https://wiki.debian.org/DebianMultimedia :

 Currently there are no strict roles defined. All members can work
 on all packages, although there is some sort of split. A list of
 people actively involved in the packaging effort can be found here

>
> Last but not least, just a small memo for Bálint: please refrain from
> playing dirty, we have had quite enough of your behaviour.
If those 'we' could find me via private email we could discuss that.
Note that in my very short blog post I invited people to the
discussion which had no new comment for 9 days.

Cheers,
Balint

>
>
> Cheers.
>
> [1] http://balintreczey.hu/blog/debian-is-preparing-the-transition-to-ffmpeg/


--
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/cak0odpwqfnckavus3+be8wsi27euwcf2yz3fpb+917fosvm...@mail.gmail.com

Re: Clarifications about the alleged transition to FFmpeg

[Bálint Réczey]

2015-06-18 18:30 GMT+02:00 Bálint Réczey :
> Hi Alessio,
>
> 2015-06-18 18:00 GMT+02:00 Alessio Treglia :
>> Hello everybody,
>>
>> I am afraid that I have to inform you that Bálint's blog post [1]
>> about the current status of libav's provided is untrue as there's
>> still a discussion ongoing on the Debian Multimedia Maintainers' team
>> mailing list, and a clear outcome is yet to come.
>> We'll eventually get in touch with the release team once we've taken a
>> final decision on the matter.
> Untrue is a nice word, but AFAIK the Multimedia Team which I'm member
> of at the moment is really working out the details of the transition.
> While the team has not announced a formal decision the majority of the
> team supports FFmpeg (which you don't ;-).
> It also not clear how the team can make a formal decision since there
> is no official leader, just members,not all listed members
> participated in the discussion.
> From: https://wiki.debian.org/DebianMultimedia :
>
>  Currently there are no strict roles defined. All members can work
>  on all packages, although there is some sort of split. A list of
>  people actively involved in the packaging effort can be found here
Regarding contacting the Release Team we surely have to and will contact them
after the decision is made somehow  _and the transition plan is finalized_ .

Cheers,
Balint


--
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/CAK0Odpwx3CgXmnnsHOo7Hmw9q6B8A8dDz78aO-obyRMgKx=r...@mail.gmail.com

Re: Clarifications about the alleged transition to FFmpeg

[Alessio Treglia]

On Thu, Jun 18, 2015 at 5:30 PM, Bálint Réczey  wrote:
> While the team has not announced a formal decision the majority of the
> team supports FFmpeg (which you don't ;-).

I've never denied that: [1]
However you have to give people enough time to ***think***,
***review*** things, and ***speak up*** if they wish to.

> It also not clear how the team can make a formal decision since there
> is no official leader, just members,not all listed members
> participated in the discussion.

No one claims the leadership here, so you can't either I am afraid.

> From: https://wiki.debian.org/DebianMultimedia :
>  Currently there are no strict roles defined. All members can work
>  on all packages, although there is some sort of split. A list of
>  people actively involved in the packaging effort can be found here

Correct, nevertheless other members of the team on IRC expressed some
doubts about the subtle message conveyed by your blog post's title:
"Debian is preparing the transition to FFmpeg!" - not to mention other
parts of the contents ("Ending an era of shipping Libav" [...] "the
Debian Multimedia Team is working out the last details of switching to
FFmpeg").
I do believe that a different wording wouldn't have caused the same reactions.

Cheers.

(I won't reply again, I'm pretty fed up with all this and hope it will
come to an end soon)

[1] 
http://lists.alioth.debian.org/pipermail/pkg-multimedia-maintainers/2015-June/044671.html

-- 
Alessio Treglia  | www.alessiotreglia.com
Debian Developer | ales...@debian.org
Ubuntu Core Developer|  quadris...@ubuntu.com
0416 0004 A827 6E40 BB98 90FB E8A4 8AE5 311D 765A


--
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/CAMHuwozTKncitJqdN_bFXsk_H4TZ=njf3PidtsAtH=jpmnt...@mail.gmail.com

Re: Clarifications about the alleged transition to FFmpeg

[Bálint Réczey]

Hi Alessio,

2015-06-18 19:25 GMT+02:00 Alessio Treglia :
> On Thu, Jun 18, 2015 at 5:30 PM, Bálint Réczey  wrote:
>> While the team has not announced a formal decision the majority of the
>> team supports FFmpeg (which you don't ;-).
>
> I've never denied that: [1]
> However you have to give people enough time to ***think***,
> ***review*** things, and ***speak up*** if they wish to.
>
>> It also not clear how the team can make a formal decision since there
>> is no official leader, just members,not all listed members
>> participated in the discussion.
>
> No one claims the leadership here, so you can't either I am afraid.
I think a team of this size would need at least a secretary who can set
schedules with deadlines for votes at least when someone delegates
a decision to us. I'm not interested in claiming leadership and if we
ever elect one leader/secretary I won't run and will vote for you in
the first period.

I'm interested in working teams where the rules of making formal
decisions are known and time-limited and I hope when we are
asked to make a decision next time we will have those rules in place.

>
>> From: https://wiki.debian.org/DebianMultimedia :
>>  Currently there are no strict roles defined. All members can work
>>  on all packages, although there is some sort of split. A list of
>>  people actively involved in the packaging effort can be found here
>
> Correct, nevertheless other members of the team on IRC expressed some
> doubts about the subtle message conveyed by your blog post's title:
> "Debian is preparing the transition to FFmpeg!" - not to mention other
> parts of the contents ("Ending an era of shipping Libav" [...] "the
> Debian Multimedia Team is working out the last details of switching to
> FFmpeg").
> I do believe that a different wording wouldn't have caused the same reactions.
I'm sorry if some people felt bad due to the wording. I think it is
fairly neutral.
Copying the original short blog entry:
---
 Debian is preparing the transition to FFmpeg!

Ending an era of shipping Libav as default the Debian Multimedia Team
is working out the last details of switching to FFmpeg. If you would
like to read more about the reasons please read the rationale behind
the change on the dedicated wiki page. If you feel so be welcome to
test the new ffmpeg packages or join the discussion starting here.
(Warning, the thread is lng!)
---
I don't know if the IRC logs are available somewhere, but I can update
the post if there are better suggestions for wording.

Cheers,
Balint

>
> Cheers.
>
> (I won't reply again, I'm pretty fed up with all this and hope it will
> come to an end soon)
>
> [1] 
> http://lists.alioth.debian.org/pipermail/pkg-multimedia-maintainers/2015-June/044671.html
>
> --
> Alessio Treglia  | www.alessiotreglia.com
> Debian Developer | ales...@debian.org
> Ubuntu Core Developer|  quadris...@ubuntu.com
> 0416 0004 A827 6E40 BB98 90FB E8A4 8AE5 311D 765A


--
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/CAK0Odpw2PbWazC4=E_W=5pjalqej0mkg2jwcvph4kjkzz7d...@mail.gmail.com

Please stop (was: Bug#786909: chromium: unconditionally downloads binary blob)

[Michael Gilbert]

On Thu, Jun 18, 2015 at 8:23 PM, Christoph Anton Mitterer wrote:

> - still no DSA (or something like that)

See previous message.

> - still no concentrated effort at the Debian level to pro-actively work
> against such sources that include or more or less secretly download
> blobs

If you have an itch, please by all means go scratch it.  You will get
absolutely nowhere continuing to tell people that they need to drop
everything to scratch your particular itches.  No one gets to tell
anyone else how they should spend their Debian time.  That is an
incredibly obtrusive affront to personal freedom and self
actualization.  Please stop.

Best wishes,
Mike


-- 
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/CANTw=MPY5FvB-jo8WUOuQ9sV=ooymqz40wnso_0nnbzb9le...@mail.gmail.com

Work-needing packages report for Jun 19, 2015

[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: 664 (new: 1)
Total number of packages offered up for adoption: 177 (new: 1)
Total number of packages requested help for: 53 (new: 0)

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



The following packages have been orphaned:

   pidgin-twitter (#788623), orphaned 5 days ago
 Description: Pidgin plugin for Twitter
 Installations reported by Popcon: 485

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

   mythes-it (#789145), offered today
 Description: Italian Thesaurus for OpenOffice.org 2
 Installations reported by Popcon: 2793

176 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 1963 days ago
 Description: maintenance tools for a Xapian index of Debian packages
 Reverse Depends: ept-cache goplay packagesearch
 Installations reported by Popcon: 57625

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

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

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

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

   cups (#532097), requested 2203 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 (64 more omitted)
 Installations reported by Popcon: 145007

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

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

   ejabberd (#767874), requested 227 days ago
 Description: distributed, fault-tolerant Jabber/XMPP server written
   in Erlang
 Reverse Depends: ejabberd-contrib
 Installations reported by Popcon: 795

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

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

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

   gnokii (#677750), requested 1097 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: 1380

   gradle (#683666), requested 1050 days ago
 Description: Groovy based build system
 Reverse Depends: gradle libgradle-plugins-java
 Installations reported by Popcon: 308

   gridengine (#703256), requested 823 days ago
 Description: Distributed resource management
 Reverse Depends: gridengine-client gridengine-drmaa-dev
   gridengine-exec gridengine-master gridengine-qmon logol
 Installations reported by Popcon: 1091

   grub2 (#248397), requested 4056 days ago
 Description: GRand Unified Bootloader
 Reverse Depends: grml-rescueboot grml2usb grub-coreboot
   grub-coreboot-bin grub-coreboot-dbg grub-disk grub-efi
   grub-efi-amd64 grub-efi-amd64-bin grub-efi-amd64-dbg (37 more
   omitted)
 Installations reported by Popcon: 166030

   guake (#755928), requested 329 days ago
 Description: Drop-down terminal for GNOME Desktop Environment
 Reverse Depends: guake-indicator
 Installation

Re: Please stop (was: Bug#786909: chromium: unconditionally downloads binary blob)

[Christoph Anton Mitterer]

On Thu, 2015-06-18 at 20:36 -0400, Michael Gilbert wrote:
> See previous message.
I've had read that only afterwards, as well as this message.


> You will get
> absolutely nowhere continuing to tell people that they need to drop
> everything to scratch your particular itches.
I don't think I've asked you to drop everything.


> No one gets to tell
> anyone else how they should spend their Debian time.  That is an
> incredibly obtrusive affront to personal freedom and self
> actualization.
I haven't said that you personally would be required to do anything,
have I?

Cheers,
Chris.

smime.p7s
Description: S/MIME cryptographic signature

Re: Please stop (was: Bug#786909: chromium: unconditionally downloads binary blob)

[Michael Gilbert]

On Thu, Jun 18, 2015 at 8:57 PM, Christoph Anton Mitterer wrote:
> On Thu, 2015-06-18 at 20:36 -0400, Michael Gilbert wrote:
>> See previous message.
> I've had read that only afterwards, as well as this message.
>
>
>> You will get
>> absolutely nowhere continuing to tell people that they need to drop
>> everything to scratch your particular itches.
> I don't think I've asked you to drop everything.
>
>
>> No one gets to tell
>> anyone else how they should spend their Debian time.  That is an
>> incredibly obtrusive affront to personal freedom and self
>> actualization.
> I haven't said that you personally would be required to do anything,
> have I?

And so the obtusion continues...

That statement was not solely about this particular encounter at all.
It is a fundamental observation about the nature of almost all
incoming discussion from calye...@scientia.net.

Coupled with the yet to be seen ability to read or write code
(accounting only for the calyesto discussions I've personally
encountered, which have been far too many), and the continuing trend
to resort to bullying and unjustified personal attack, the totality of
calyesto contributions to the Debian corpus have very likely in sum
been a net negative.

Maybe that can change?  Please?

Best wishes,
Mike


-- 
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/CANTw=mmqnrt5namu-4y5rnhxqxmyytcm2l4shbmpor5fbhk...@mail.gmail.com