Re: [gentoo-dev] metadata.xml GLEP for review

[Michał Górny]

On Wed, 16 Mar 2016 20:37:30 +0100
Dirkjan Ochtman  wrote:

> On Wed, Mar 16, 2016 at 7:43 PM, Michał Górny  wrote:
> > Therefore, I've been slowly writing a proper GLEP that would describe
> > all of metadata.xml in detail. Here's the current draft for review:  
> 
> Sounds like a good idea!
> 
> > https://wiki.gentoo.org/wiki/User:MGorny/GLEP:68  
> 
> I reviewed your spec based on my experience from trying to create a
> RELAX NG schema for all metadata.xml files that were in the tree at
> the time. I assume you've also validated your spec against what's
> actually being used? I have a few questions:

Small update here:

> - I had the upstream maintainer's email element pegged as mandatory.
> Don't you think that makes sense? A name-only maintainer element seems
> relatively low-value to me.

I've re-read the spec today and confirmed this with one of the authors.
For upstream, name is mandatory, e-mail is not.

> - You list a number of the upstream child elements (changelog, doc,
> bug-to) as "zero or more". Doesn't it make sense to make (some of)
> these zero or one?

dev-zero explained this to me. The original intent was that each of
those elements could be used at most once, however DTD limitations
prevented this from happening.

After thinking some, I've figured out how to force 'at most one' with
XML Schema without losing readability, and I'll update the spec to
conform to the original meaning.

-- 
Best regards,
Michał Górny



pgpmz9HyhSGPE.pgp
Description: OpenPGP digital signature

[gentoo-dev] Packages up for grab

[Christian Ruppert]

app-forensics/lynis
dev-libs/log4cplus
dev-vcs/colorsvn
dev-vcs/git-deploy
dev-vcs/topgit
sci-electronics/fritzing
sys-auth/libnss-cache
media-video/nvidia-settings

Feel free. If you need some more info please poke me on IRC.

-- 
Regards,
Christian Ruppert
Gentoo Linux developer, Bugzilla administrator and Infrastructure member
Fingerprint: EEB1 C341 7C84 B274 6C59 F243 5EAB 0C62 B427 ABC8


signature.asc
Description: PGP signature

[gentoo-dev] Last rites: net-im/qtwitter

[Michael Palimaka]

# Michael Palimaka  (17 Mar 2016)
# Dead upstream. Doesn't work with new Twitter API.
# Masked for removal in 30 days.
net-im/qtwitter

Re: [gentoo-dev] metadata.xml GLEP for review

[Michał Górny]

On Wed, 16 Mar 2016 20:37:30 +0100
Dirkjan Ochtman  wrote:

> On Wed, Mar 16, 2016 at 7:43 PM, Michał Górny  wrote:
> > Therefore, I've been slowly writing a proper GLEP that would describe
> > all of metadata.xml in detail. Here's the current draft for review:  
> 
> Sounds like a good idea!
> 
> > https://wiki.gentoo.org/wiki/User:MGorny/GLEP:68  
> 
> I reviewed your spec based on my experience from trying to create a
> RELAX NG schema for all metadata.xml files that were in the tree at
> the time. I assume you've also validated your spec against what's
> actually being used?

I've validated my XML Schema which conforms to the spec (but isn't 100%
strict on everything). You can see the numeric results in 'backwards
compat' section, also attaching failures.txt with specific list in
case you wanted to look through it.

> I have a few questions:
> 
> - I had the upstream maintainer's email element pegged as mandatory.
> Don't you think that makes sense? A name-only maintainer element seems
> relatively low-value to me.

As for upstream stuff, I tried to keep it as GLEP 46 says. In this
case, it's unclear whether it's supposed to be mandatory. There's no
explicit notion either way. However, as I pointed out, there are 4
packages which list maintainers with empty e-mail address. If we are to
consider email obligatory, we should drop maintainer entries from them.

> - You list a number of the upstream child elements (changelog, doc,
> bug-to) as "zero or more". Doesn't it make sense to make (some of)
> these zero or one?

This is another problem with GLEP 46 -- I have no clue. After
discussing this with ulm, he suggested we use the same number for all
elements to reduce possible confusion.

Maybe it would be useful to query GLEP 46 authors but sadly I don't
have time to do that right now.

-- 
Best regards,
Michał Górny

/var/db/repos/gentoo/app-admin/conky/metadata.xml:12: element description: 
Schemas validity error : Element 'description': This element is not expected.
/var/db/repos/gentoo/app-admin/conky/metadata.xml fails to validate

/var/db/repos/gentoo/app-admin/mktwpol/metadata.xml:12: element description: 
Schemas validity error : Element 'description': This element is not expected.
/var/db/repos/gentoo/app-admin/mktwpol/metadata.xml fails to validate

/var/db/repos/gentoo/app-cdr/bashburn/metadata.xml:13: element maintainer: 
Schemas validity error : Element 'maintainer', attribute 'type': The attribute 
'type' is not allowed.
/var/db/repos/gentoo/app-cdr/bashburn/metadata.xml fails to validate

/var/db/repos/gentoo/app-cdr/cdrtools/metadata.xml:11: element description: 
Schemas validity error : Element 'description': This element is not expected.
/var/db/repos/gentoo/app-cdr/cdrtools/metadata.xml fails to validate

/var/db/repos/gentoo/app-crypt/eid-mw/metadata.xml:26: element pkg: Schemas 
validity error : Element 'pkg': [facet 'pattern'] The value 'x11-libs/gtk+:*' 
is not accepted by the pattern 
'[A-Za-z0-9_][A-Za-z0-9+_.-]*/[A-Za-z0-9_][A-Za-z0-9+_-]*'.
/var/db/repos/gentoo/app-crypt/eid-mw/metadata.xml:26: element pkg: Schemas 
validity error : Element 'pkg': 'x11-libs/gtk+:*' is not a valid value of the 
atomic type 'pkgType'.
/var/db/repos/gentoo/app-crypt/eid-mw/metadata.xml:29: element pkg: Schemas 
validity error : Element 'pkg': [facet 'pattern'] The value 'x11-libs/gtk+:*' 
is not accepted by the pattern 
'[A-Za-z0-9_][A-Za-z0-9+_.-]*/[A-Za-z0-9_][A-Za-z0-9+_-]*'.
/var/db/repos/gentoo/app-crypt/eid-mw/metadata.xml:29: element pkg: Schemas 
validity error : Element 'pkg': 'x11-libs/gtk+:*' is not a valid value of the 
atomic type 'pkgType'.
/var/db/repos/gentoo/app-crypt/eid-mw/metadata.xml fails to validate

/var/db/repos/gentoo/app-dicts/gwaei/metadata.xml:20: element use: Schemas 
validity error : Element 'use': Duplicate key-sequence ['en'] in unique 
identity-constraint 'useUniquityConstraint'.
/var/db/repos/gentoo/app-dicts/gwaei/metadata.xml:25: element use: Schemas 
validity error : Element 'use': Duplicate key-sequence ['en'] in unique 
identity-constraint 'useUniquityConstraint'.
/var/db/repos/gentoo/app-dicts/gwaei/metadata.xml fails to validate

/var/db/repos/gentoo/app-emacs/ebuild-mode/metadata.xml:9: element maintainer: 
Schemas validity error : Element 'maintainer', attribute 'type': The attribute 
'type' is not allowed.
/var/db/repos/gentoo/app-emacs/ebuild-mode/metadata.xml fails to validate

/var/db/repos/gentoo/app-emacs/eselect-mode/metadata.xml:9: element maintainer: 
Schemas validity error : Element 'maintainer', attribute 'type': The attribute 
'type' is not allowed.
/var/db/repos/gentoo/app-emacs/eselect-mode/metadata.xml fails to validate

/var/db/repos/gentoo/app-emulation/docker/metadata.xml:11: element maintainer: 
Schemas validity error : Element 'maintainer', attribute 'status': The 
attribute 'status' is not allowed.
/var/db/repos/gentoo/app-emulation/docker/metadata.xml fails to validate

/var/db/repos/gentoo/app-emulatio

[gentoo-dev] Re: [gentoo-dev-announce] Last rites: app-forensics/chkrootkit

[Andrew Savchenko]

On Sat, 19 Mar 2016 22:43:27 +0300 Andrew Savchenko wrote:
> On Sat, 19 Mar 2016 16:24:32 +0900 Aaron Bauman wrote:
> > # Aaron Bauman  (19 Mar 2016)
> > # Unpatched security vulnerability per bug #512356.
> > # Masked for removal in 30 days.
> > app-forensics/chkrootkit
> 
> Hey! This is a great tool and new version with fix for this bug is
> available. It looks like forensics project doesn't have resources
> to fix this package, so I'm joining in in its maintenance :)

Oops, Michael already claimed this package, sorry I somehow missed
that e-mail on the first glance. So please, kensington, go ahead :)

Best regards,
Andrew Savchenko


pgpmFzhMl7XYH.pgp
Description: PGP signature

[gentoo-dev] Re: [gentoo-dev-announce] Last rites: app-forensics/chkrootkit

[Andrew Savchenko]

On Sat, 19 Mar 2016 16:24:32 +0900 Aaron Bauman wrote:
> # Aaron Bauman  (19 Mar 2016)
> # Unpatched security vulnerability per bug #512356.
> # Masked for removal in 30 days.
> app-forensics/chkrootkit

Hey! This is a great tool and new version with fix for this bug is
available. It looks like forensics project doesn't have resources
to fix this package, so I'm joining in in its maintenance :)

Best regards,
Andrew Savchenko


pgpDXThE7gKK2.pgp
Description: PGP signature

[gentoo-dev] metadata.xml GLEP for review

[Michał Górny]

Hello, all.

Long story short: while working on various metadata.xml-related
aspects, it bite us pretty hard that we lack proper spec for
metadata.xml file. What we have is pretty much the DTD, some partial
GLEPs (that sometimes provide incorrect info) and random bugs. ml
posts...

Therefore, I've been slowly writing a proper GLEP that would describe
all of metadata.xml in detail. Here's the current draft for review:

https://wiki.gentoo.org/wiki/User:MGorny/GLEP:68

-- 
Best regards,
Michał Górny



pgp17_vdnjr44.pgp
Description: OpenPGP digital signature

[gentoo-dev] Last rites x11-libs/libview

[Andreas K. Hüttel]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

# Andreas K. Huettel  (19 Mar 2016)
# Dead upstream since 2010, new VMware uses new incompatible
# proprietary libview. No other consumers. Removal in 30 days.
# Bug 569930
x11-libs/libview

- -- 
Andreas K. Hüttel
Gentoo Linux developer (council, perl, libreoffice)
dilfri...@gentoo.org
http://www.akhuettel.de/
-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQIcBAEBCgAGBQJW7ZA8AAoJEHRrah2soMK+m6oQAJjwn8HtkdnKSIE1R4BqbLUd
6oJ4GeOD8Pbae2VzLEMc4xe/NiV11xyh1n/bGVf5v3x0OS3E4gMZarBHTRxkuETk
XzxXkY7ZhoD1tFZX0sTmbShLMccRNPjwjc7pgc/Uq+G9atAT/KsX4WtsygGm341m
GcNpcdHro0XVcFa1cPUZjJ4DyBIIEvRBgNhuXBKWPE62TRveF4NUBraU0BLRUFDw
zrgGnXAc8Q7UUTV6DoO4VEOPGKSo43fpnrRziSkYw/PE4RtNqffsBtO2udozpKh/
gpQT355kAG/U9cuhj46eDq3bJMsuUdhlBOhyfLkYFACzd3KdwkKzW8cjKVzffjfW
z+1R5IRvFkeInUhKPDv+TVPJJ4tmL9tkESidIESRaLbRmLN1/t1MHypk/MUPZVmE
QKzUvfYUYuz2V+gNPd8Vdc65Ee84VenHstGlhfmSvzGbrL8FptxKAxaXLBcW7j60
R9C6O/BfYAvPEfenIY8e9T9Lb0zPJZIiNQMwrn7RCWXjFIRxwGIiuFBW6An8jee5
fIqdt+ZYzRj1AmFvdrIIDTzgLvQ/irKuZa5oif91T2MlKjtdBW7ys7lcI8duUADG
pWo0X3vJDkg9qOsj/4rj/Ckw/JUA8ytJ+J1+NTr+By255jZHvQxwWNPQDiTdf9nk
8+wBF1N58L1WHzZwjXz0
=XyFP
-END PGP SIGNATURE-

[gentoo-dev] Re: Last rites: app-forensics/chkrootkit

[Michael Palimaka]

On 19/03/16 18:24, Aaron Bauman wrote:
> # Aaron Bauman  (19 Mar 2016)
> # Unpatched security vulnerability per bug #512356.
> # Masked for removal in 30 days.
> app-forensics/chkrootkit
> 

I can look at taking care of this package if nobody else is keen.

[gentoo-dev] [RFC] metadata.xml changes related to improved checks

[Michał Górny]

Hello, everyone.

Since the GLEP 68 mail didn't bring much discussion, I would like to
point out explicitly a few things that might require some. They are
mostly listed in backwards compatibility section of the GLEP [1],
and they were caught by XML Schemas [2].

I would like to know your opinion on the problems and suggested
solutions. If there is agreement, I will proceed with either fixing
metadata.xml files whenever fixing it myself will be possible, or file
a bug whenever it will require maintainer's attention.


The most important issues are:

1. Upstream  entries were never allowed to use
. DTD wasn't able to enforce this but XML Schema is,
and so I'd like to officially start requiring this.

1a. In some cases, this is used to request CC-ing upstream maintainers
on bugs. I think that's a bad idea since people don't usually look at
upstream tags for such an information, and any automated assignment
tool will not even consider them. As an alternative, I'd copy upstream
maintainers to downstream maintainer entries with appropriate
description. This way, both bug-wranglers and any automated tool would
CC them reliably.

2. There are some  elements being used along with slot
specifiers, USE dependencies and some more other weird stuff.
The  element was intended to be used to allow cross-linking
descriptions to packages.gentoo.org, and as such supports only plain
qualified package name (to link to p.g.o page about the package
in question).

2a. For  elements with slots specified, USE dependencies
and versions, I'd like to move the extra bits out of . For
example, x11-libs/gtk+:3 -> x11-libs/gtk+:3,
=app-foo/bar-1 -> =app-foo/bar-1.

2b. There's one case when  contains wildcard like app-foo/bar-*
to reference multiple packages. Since this won't really work, I'd
remove  tag there and leave it as plain text.

3. There are a few restrict="" uses along with USE dependencies
and slot dependencies. Since metadata.xml is not properly
EAPI-versioned, the most correct way would be to assume EAPI=0. I don't
see an obvious fix for most of the packages, so I guess I will file
bugs for all of them.

3a. Furthermore, USE dependencies depend on configuration, and as such
have limited machine processing capabilities (i.e. when assigning bugs
for ebuilds).

4. The  element is being removed. Over 1.5yr of its
existence, it was used only in 4 packages, and only to copy over PN in
different capitalization.

5. A few packages use multiple  URLs. This element was
intended to be used at most once, e.g. to provide a 'file bug upstream'
link. Having multiple URLs is confusing, as we provide no clear
annotation on which to use. I will file bugs about packages that do
that.


Please let me know what you think about this.


[1]:https://wiki.gentoo.org/wiki/User:MGorny/GLEP:68#Known_incompatibilities
[2]:https://github.com/mgorny/gentoo-xml-schema

-- 
Best regards,
Michał Górny



pgptYSrfifYjx.pgp
Description: OpenPGP digital signature

Re: [gentoo-dev] metadata.xml GLEP for review

[Dirkjan Ochtman]

On Wed, Mar 16, 2016 at 7:43 PM, Michał Górny  wrote:
> Therefore, I've been slowly writing a proper GLEP that would describe
> all of metadata.xml in detail. Here's the current draft for review:

Sounds like a good idea!

> https://wiki.gentoo.org/wiki/User:MGorny/GLEP:68

I reviewed your spec based on my experience from trying to create a
RELAX NG schema for all metadata.xml files that were in the tree at
the time. I assume you've also validated your spec against what's
actually being used? I have a few questions:

- I had the upstream maintainer's email element pegged as mandatory.
Don't you think that makes sense? A name-only maintainer element seems
relatively low-value to me.
- You list a number of the upstream child elements (changelog, doc,
bug-to) as "zero or more". Doesn't it make sense to make (some of)
these zero or one?

Cheers,

Dirkjan

[gentoo-dev] Last rites: app-forensics/chkrootkit

[Aaron Bauman]

# Aaron Bauman  (19 Mar 2016)
# Unpatched security vulnerability per bug #512356.
# Masked for removal in 30 days.
app-forensics/chkrootkit

-- 
Cheers,
Aaron Bauman
Gentoo Linux Developer
GnuPG FP: 1536 F4B3 72EB 9C54 11F5  5C43 246D 23A2 10FB 0F3E

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