Re: cme and stylistic changes in team uploads

[Afif Elghraoui]

Hello,

على السبت 24 كانون الأول 2016 ‫22:51، كتب Andreas Tille:
> Hi,
> 
> On Sat, Dec 24, 2016 at 10:00:07PM -0800, Afif Elghraoui wrote:
>>> On 24/12/16 15:41, Afif Elghraoui wrote:
 I'm admittedly no fan of cme's styling. While I have my own style that I
 prefer to use in d/control,
> 
> I admit before I started cme I had a different style as well.  I decided
> that the advantages cme had regarding content are way superior over
> keeping my own style.  Moreover I consider it a feature to have a common
> style inside a team.
>  There is another "styling" tool with different
> formating style (I always forget its name since I'm not using it).

I think you mean devscripts' `wrap-and-sort`.

>  I
> know that style is something (like color of web pages, names of
> projects) people can be quite opinionated about.  I personally try to
> save my own time and adapt to something that could be potentionally a
> common agreement since I'm convinced that some common style has some
> value.  Its not really necessary but helps others to step in.


I think it's enough consistency that people are either using dh_make,
debmake, or the debian-med packaging template and just adding to that.
If people were writing these packaging files from scratch, there would
be real consistency issues.


> 
 I don't impose this on anyone--I would not
 force people requesting sponsorship to use it, nor would I change it
 while making a team upload.
> 
> I'd definitely not request the cme style while I'm recommending it to
> newcommers for the said reasons.  I'm usually doing it in team uploads
> since up to now nobody expressed that its not wanted.  I'd not use it
> for instance on packages where you are Uploader and I know that you do
> not like it.
> 
>>> cme introduces some consistency in the formatting that is definitely 
>>> welcome.
> 
> Its not *only* the formatting its also a defined sequence of fields
> which I consider a helpful standard.
> 
>>> It also helps you flag things like non-secure VCS URIs and 
>>> out-of-date standards fairly easily.
> 
> Its not just flagging it - its fixing it and by doing so it saves
> time.
>  
>> Flagging is what lintian does.
> 
> Yes, lintian is *only* flagging and I need to rebuild the package
> after manual work.  Cme does things in advance and saves me another
> build which is very convenient.


I agree that can be helpful, but to me it's outweighed by the problems I
have with it.


> 
>> While cme also makes those changes for
>> you, it removes trailing commas from listings (making for noisier diffs)
> 
> I admit I was considering a bug report against cme about this but
> somehow never took the time.  In the past I learned that cme authors are
> quite sensible and if you have good reasons are responsive about this.
> So if this really concerns you I'd try a bug report if I would be in
> your shoes.
> 
>> and misaligns all itemized lists.
> 
> I never observed this.  Could you please give an example?  That could
> also be a topic for a bug report.

This is really not a big deal, but I was referring to something like:

Build-Depends: A,
   B,
   C
...
Depends: D,
 E,

versus

Build-Depends:
A,
B,
C
...
Depends:
D,
E

where in the latter case, both lists are aligned. Again, not a very big
deal.

>  
>> I'm not trying to convince anyone because I'm not really interested in
>> disputing style; all I'm saying is that if someone wants to make a team
>> upload, I don't think that making stylistic changes should be part of it.
> 
> It depends.  If I know that the team member does not like it I agree.
> However, in the past I touched so many packages of team members who in
> the beginning were not aware about cme and its features and who were
> happy about the change or team members who somehow stopped caring for
> the package in question or left the team at all that the overall style
> consistence became a feature of the Debian Med packages which I do not
> want to miss today.  That's the reason we have even put
> 
>... simply call
> 
>cme fix dpkg-control
> 
>to get a properly formated, sanity checked debian/control file.
> 
> in our team policy[1].
> 

Although in the case of someone leaving the team or stopping work on a
package, presumably someone else has joined the uploaders list, in which
case subsequent changes are no longer Team uploads. My suggestion was
only to not change style as part of Team uploads.


>>> That being said, like any other tools, it should not be used blindly and 
>>> whoever messed with your comment should have inspected the diff before.
> 
> I confirm that messing up comments is a bug (which I also was to lazy to
> report - which I always regret if I touch a package with comments in
> d/control).
> 
 Is there a reason to apply cme systematically to packages as part of any
 upload? Besides my dislike for what it does to the file, it has in one
 case moved a Depends line a

Re: Sponsoring request: security fix in dcmtk for CVE2015-8979

[Sébastien Delafond]

On Dec/25, Gert Wollny wrote:
> because of #796095  I can not upload
> to security-master as a DM, therefore I ask for sponsering of package
> dcmtk-3.6.0 in jessie fixing CVE-2015-8979
> (#848830). 
> 
> Because the git packaging history doesn't go back to the version to be
> fixed I've prepared the new upload on mentors:
> 
>   https://mentors.debian.net/package/dcmtk
> 
> Alternatively, one can download the package with dget using this command:
> 
> dget -x
> 
> https://mentors.debian.net/debian/pool/main/d/dcmtk/dcmtk_3.6.0-15+deb8u1.dsc
> 
> Please prepare a binary upload with source code included (-sa) and
> upload it to security-master.  Also note that the package as is
> doesn't support parallel builds.

I will take care of building and uploading this.

Cheers,

--Seb

Sponsoring request: security fix in dcmtk for CVE2015-8979

[Gert Wollny]

Dear all,

because of #796095  I can not upload to 
security-master as a DM, therefore I ask for 
sponsering of package dcmtk-3.6.0 in jessie fixing CVE-2015-8979 (#848830). 


Because the git packaging history doesn't go back to the version to be 
fixed I've prepared the new upload on mentors: 

  https://mentors.debian.net/package/dcmtk

Alternatively, one can download the package with dget using this command:

dget -x 
https://mentors.debian.net/debian/pool/main/d/dcmtk/dcmtk_3.6.0-15+deb8u1.dsc

Please prepare a binary upload with source code included (-sa) and upload it to 
security-master. 
Also note that the package as is doesn't support parallel builds.  

Many thanks, 
Gert

On 24.12.2016 09:30, Sébastien Delafond wrote:
> as much as I'd have loved to have to review only the actual minimal
> patch from upstream[1], it seems after close examination that the
> additional stuff here is only about extra tests. Those are not going to
> cause any regression at runtime anyway, so you can build with -sa, and
> upload to security-master (no source-only).
>
> Cheers,
>
> --Seb




signature.asc
Description: OpenPGP digital signature