[gentoo-dev] Last rites: dev-vcs/blogc-git-receiver, www-server/blogc-runserver

[Rafael Goncalves Martins]

# Rafael G. Martins  (30 Apr 2016)
# Packages merged upstream with app-text/blogc. Please install
# app-text/blogc with USE=git and USE=httpd instead. Removal in 30 days.
dev-vcs/blogc-git-receiver
www-server/blogc-runserver

-- 
Rafael Goncalves Martins
Gentoo Linux developer
http://rafaelmartins.eng.br/

Re: [gentoo-dev] Is X86 uclibc environment supported?

[waltdnes]

On Fri, Apr 29, 2016 at 08:19:53PM -0400, Anthony G. Basile wrote

> 1) i support uclibc across many arches. see
> 
> https://wiki.gentoo.org/wiki/Project:Hardened_uClibc
> 
> 
> 2) you can file uclibc bugs and i will look at them.  i know about that
> one and i've got the fix upstream.  its going slowly because the bug was
> in libcheck which is bundled with gstreamer and so there's layers of
> backporting.  see
> 
> https://bugs.gentoo.org/show_bug.cgi?id=577312

  Thanks.  For the time-being, I'll try building Pale Moon without HTML5
video support.  It may turn up other problems.

-- 
Walter Dnes 
I don't run "desktop environments"; I run useful applications

Re: [gentoo-dev] Is X86 uclibc environment supported?

[Anthony G. Basile]

On 4/29/16 8:02 PM, waltd...@waltdnes.org wrote:
>   I'm currently trying to get a 32 uclibc environment working in a QEMU
> VM.  My eventual goal is to get my ancient 32-bit-only Atom netbook
> working under uclibc.  Is it worth bothering to file bugs for stuff that
> builds under glibc, but fails under uclibc?  Or should I forget it?  If
> it's not supported, there's no point in bugging the developers.
> 
>   E.g. gstreamer-1.6.3 builds under glibc, but under uclibc...
> 
> In file included from 
> /var/tmp/portage/media-libs/gstreamer-1.6.3/work/gstreamer-1.6.3/libs/gst/check/libcheck/check_error.c:25:0:
> /usr/include/string.h:386:14: error: conflicting types for 'strsignal'
>  extern char *strsignal (int __sig) __THROW;
>   ^
> In file included from 
> /var/tmp/portage/media-libs/gstreamer-1.6.3/work/gstreamer-1.6.3/libs/gst/check/libcheck/check_error.c:21:0:
> /var/tmp/portage/media-libs/gstreamer-1.6.3/work/gstreamer-1.6.3/libs/gst/check/libcheck/libcompat.h:104:24:
>  note: previous declaration of 'strsignal' was here
>  CK_DLL_EXP const char *strsignal (int sig);
> ^
> Makefile:672: recipe for target 'libcheckinternal_la-check_error.lo' failed
> make[5]: *** [libcheckinternal_la-check_error.lo] Error 1
> make[5]: *** Waiting for unfinished jobs
> In file included from 
> /var/tmp/portage/media-libs/gstreamer-1.6.3/work/gstreamer-1.6.3/libs/gst/check/libcheck/check.c:23:0:
> /usr/include/string.h:386:14: error: conflicting types for 'strsignal'
>  extern char *strsignal (int __sig) __THROW;
>   ^
> In file included from 
> /var/tmp/portage/media-libs/gstreamer-1.6.3/work/gstreamer-1.6.3/libs/gst/check/libcheck/check.c:21:0:
> /var/tmp/portage/media-libs/gstreamer-1.6.3/work/gstreamer-1.6.3/libs/gst/check/libcheck/libcompat.h:104:24:
>  note: previous declaration of 'strsignal' was here
>  CK_DLL_EXP const char *strsignal (int sig);
> ^
> 
> 

1) i support uclibc across many arches. see

https://wiki.gentoo.org/wiki/Project:Hardened_uClibc


2) you can file uclibc bugs and i will look at them.  i know about that
one and i've got the fix upstream.  its going slowly because the bug was
in libcheck which is bundled with gstreamer and so there's layers of
backporting.  see

https://bugs.gentoo.org/show_bug.cgi?id=577312



-- 
Anthony G. Basile, Ph.D.
Gentoo Linux Developer [Hardened]
E-Mail: bluen...@gentoo.org
GnuPG FP  : 1FED FAD9 D82C 52A5 3BAB  DC79 9384 FA6E F52D 4BBA
GnuPG ID  : F52D4BBA

[gentoo-dev] Is X86 uclibc environment supported?

[waltdnes]

  I'm currently trying to get a 32 uclibc environment working in a QEMU
VM.  My eventual goal is to get my ancient 32-bit-only Atom netbook
working under uclibc.  Is it worth bothering to file bugs for stuff that
builds under glibc, but fails under uclibc?  Or should I forget it?  If
it's not supported, there's no point in bugging the developers.

  E.g. gstreamer-1.6.3 builds under glibc, but under uclibc...

In file included from 
/var/tmp/portage/media-libs/gstreamer-1.6.3/work/gstreamer-1.6.3/libs/gst/check/libcheck/check_error.c:25:0:
/usr/include/string.h:386:14: error: conflicting types for 'strsignal'
 extern char *strsignal (int __sig) __THROW;
  ^
In file included from 
/var/tmp/portage/media-libs/gstreamer-1.6.3/work/gstreamer-1.6.3/libs/gst/check/libcheck/check_error.c:21:0:
/var/tmp/portage/media-libs/gstreamer-1.6.3/work/gstreamer-1.6.3/libs/gst/check/libcheck/libcompat.h:104:24:
 note: previous declaration of 'strsignal' was here
 CK_DLL_EXP const char *strsignal (int sig);
^
Makefile:672: recipe for target 'libcheckinternal_la-check_error.lo' failed
make[5]: *** [libcheckinternal_la-check_error.lo] Error 1
make[5]: *** Waiting for unfinished jobs
In file included from 
/var/tmp/portage/media-libs/gstreamer-1.6.3/work/gstreamer-1.6.3/libs/gst/check/libcheck/check.c:23:0:
/usr/include/string.h:386:14: error: conflicting types for 'strsignal'
 extern char *strsignal (int __sig) __THROW;
  ^
In file included from 
/var/tmp/portage/media-libs/gstreamer-1.6.3/work/gstreamer-1.6.3/libs/gst/check/libcheck/check.c:21:0:
/var/tmp/portage/media-libs/gstreamer-1.6.3/work/gstreamer-1.6.3/libs/gst/check/libcheck/libcompat.h:104:24:
 note: previous declaration of 'strsignal' was here
 CK_DLL_EXP const char *strsignal (int sig);
^


-- 
Walter Dnes 
I don't run "desktop environments"; I run useful applications

Re: [gentoo-dev] [PATCH] metadata.dtd: Remove obsolete element per GLEP 68

[Michał Górny]

On Thu, 28 Apr 2016 19:41:06 -0400
Göktürk Yüksek  wrote:

> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA512
> 
> Brian Dolbec:
> > On Thu, 28 Apr 2016 15:39:05 -0400 Göktürk Yüksek
> >  wrote:
> >   
> >> --- metadata.dtd | 5 + 1 file changed, 1 insertion(+), 4
> >> deletions(-)
> >> 
> >> diff --git a/metadata.dtd b/metadata.dtd index 7626a57..b608852
> >> 100644 --- a/metadata.dtd +++ b/metadata.dtd @@ -3,7 +3,7 @@ 
> >> 
> >> 
> >>  - >> (maintainer|natural-name|longdescription|slots|use|upstream)* )> 
> >> + >> (maintainer|longdescription|slots|use|upstream)* )>  >> pkgmetadata pkgname CDATA "">  @@ -13,9 +13,6 @@ explicit type)
> >> for Gentoo maintainers is prohibited. -->  >> type (person|project|unknown) "unknown">
> >> 
> >> -   -   >> > -
> >> 
> > 
> > Isn't this almost obsolete?  it's now xmlschema...  And I hope to
> > have the new repoman with it out this weekend :)
> 
> Does GLEP 68 explicitly declare metadata.dtd obsolete? I see that the
> example metadata.xml on the GLEP is missing DOCTYPE, are we getting
> rid of those too?

No, and I don't know.

metadata.dtd is still required by many tools, and as such it makes
sense to keep it. However, we may want to put some warning that it's
not very strict, and allows major structural violations due to
technical limitations.

As for DOCTYPE, there was no formal decision on that. It's not
technically required, so the GLEP doesn't enforce it. However, I don't
expect it being gone anytime soon. One of the reasons behind it is that
repoman enforces it as part of metadata.xml validation. If it is to be
gone, stable repoman needs to accept it missing at least for some time.

There was a proposal to link new/additional schemas in metadata.xml
files. However, I personally don't think we should go this way. DOCTYPE
already proved troublesome (when we switched to https),
and maintaining any kind of schema reference in XML files doesn't give
us any real benefit (we don't enforce any hard defaults besides
languages there, and I don't think many XML parsers would respect that
anyway).

> I understand that the DTD is more like a super-set, so anything that
> complies with GLEP 68 will comply with the DTD as well. However, there
> is a caveat here: for example the GLEP dismisses the list of possible
> values for  by saying "The list of available trackers and
> their specific identifiers are outside scope of this specification."
> but does not mention where these values shall be kept either. The
> moment we add a new remote-id, the xmlschema diverges from the DTD and
> stops being a subset.

Well, there is good reason for not hardcoding the list in the GLEP,
and this obviously is to avoid updating the GLEP for every single
change. And yes, as you can see, I didn't point out a specific location
where remote-ids are to be defined to avoid problems like the one noted
below.

As I see it, we can defer it to some project / wiki page, or simply
keep it in either of the schemas. Either way, we should keep both
schemas reasonably up-to-date.

> Besides, the PMS says the format of metadata.xml is described in DTD.
> Even if we move to something else, doesn't metadata.dtd need to be
> kept around until the PMS is amended?

The key point PMS is making is 'outside the scope'. The specific
location is just a minor problem, and it should be updated. I'll take
a look at it.

Oh, and +1 for the patch. If nobody complains and nobody beats me up to
it, I'll commit it this weekend.

-- 
Best regards,
Michał Górny



pgpV7EOiFf6bO.pgp
Description: OpenPGP digital signature