Re: Needless use of %defattr (in 4464 packages)

2016-01-29 Thread Ralf Corsepius

On 01/29/2016 03:30 PM, Zbigniew Jędrzejewski-Szmek wrote:

On Fri, Jan 29, 2016 at 12:36:24PM +0100, Petr Šabata wrote:

On Mon, Jan 25, 2016 at 04:34:55PM -0600, Jason L Tibbitts III wrote:
perl-Affix-Infix2Postfix (steve, psabata)
perl-Algorithm-IncludeExclude (iarnell, psabata)
perl-Algorithm-Merge (iarnell, psabata)
perl-Authen-PAM (steve, psabata)
perl-Carp-Clan-Share (iarnell, psabata)
perl-Class-Container (steve, psabata)
perl-Class-DBI-Plugin-DeepAbstractSearch (iarnell, mmaslano, ppisar, psabata, 
jplesnik)
perl-Context-Preserve (iarnell, mmaslano, ppisar, psabata, jplesnik)
perl-Convert-ASCII-Armour (steve, psabata)
perl-Convert-Bencode (iarnell, psabata)
perl-Convert-Bencode_XS (iarnell, psabata)
perl-Crypt-CAST5_PP (iarnell, psabata)
perl-Crypt-DES_EDE3 (steve, psabata)
perl-Data-Denter (iarnell, mmaslano, ppisar, psabata, jplesnik)
perl-Data-FormValidator-Constraints-DateTime (iarnell, psabata)
perl-Data-Taxi (iarnell, psabata)
perl-DateTime-Format-ICal (steve, xavierb, psabata)
perl-DateTime-Format-SQLite (iarnell, ppisar, psabata, mmaslano, jplesnik)
perl-DBIx-Class-TimeStamp (iarnell, psabata)
perl-Devel-Caller (steve, psabata)
perl-Devel-FastProf (iarnell, psabata)
perl-Expect-Simple (iarnell, mmaslano, ppisar, psabata, jplesnik)
perl-File-ChangeNotify (psabata, ppisar, mmaslano, jplesnik)
perl-File-Pid (iarnell, psabata)
perl-File-Read (iarnell, psabata)
perl-File-Type (steve, psabata)
perl-File-Type-WebImages (iarnell, psabata)

Cleaned and modernized these.  More next week.
P


Can you estimate how much time you spent on this?


Though I am not Petr, I can tell how much time I spent to change this 
for my perl-packages. Ca. 20-30 per day.


However this figure is misleading, because
- I used this occasion as an opportunity to clean up my specs an to get 
rid of rpm-anachronisms (many of my perl package had not been touched 
for years).

- I used this occasion as an opportunity to experiment with rpm.
- this was done as a side-job in parallel to other tasks.

Basically, wrt. perl-packages, I believe a more or less 
mechanical/scripted remover of "%defattr" would be possible, if that's 
what you're aiming at.


However, I do not see much reason in such kind of undertaking, because I 
don't see any reason why %defattr needs to away in the next couple of years.


Ralf
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: Needless use of %defattr (in 4464 packages)

2016-01-27 Thread Ralf Corsepius

On 01/27/2016 09:37 PM, Dominik 'Rathann' Mierzejewski wrote:

On Wednesday, 27 January 2016 at 12:51, Ralf Corsepius wrote:

On 01/27/2016 11:32 AM, Dominik 'Rathann' Mierzejewski wrote:

Hi, Ralf.

On Wednesday, 27 January 2016 at 09:28, Ralf Corsepius wrote:

On 01/25/2016 11:34 PM, Jason L Tibbitts III wrote:


fakeroot (athimm, rathann, corsepiu, moceap)


Are you sure the owners list you used is current? I stepped down as
fakeroot maintainer and removed myself many months ago.


While you're not listed as POC anymore, you're still listed as committer
for rawhide, F23 and F22 branches of fakeroot, so the list above is
correct.

Crap, I wish fedora had a usable pkgdb UI ;)

While we're at it: Did you notice that this package is completely messed up?
I guess, I am going to BZ it.


To be honest, I haven't. It works well enough for me. I only has two
open bugs, one of which is a missing upstream feature. By all means,
file a bug report if there is something else wrong with it.


For reasons I do not understand, the package contains 0-sized files, 
files with permission 0 (non-exec, non-readable). Even rpmlint loudly 
complains about them.


Bug filed: https://bugzilla.redhat.com/show_bug.cgi?id=1302526

Ralf
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: Needless use of %defattr (in 4464 packages)

2016-01-27 Thread Ralf Corsepius

On 01/27/2016 01:22 PM, Pierre-Yves Chibon wrote:

On Wed, Jan 27, 2016 at 12:51:03PM +0100, Ralf Corsepius wrote:

On 01/27/2016 11:32 AM, Dominik 'Rathann' Mierzejewski wrote:

Hi, Ralf.

On Wednesday, 27 January 2016 at 09:28, Ralf Corsepius wrote:

On 01/25/2016 11:34 PM, Jason L Tibbitts III wrote:


fakeroot (athimm, rathann, corsepiu, moceap)


Are you sure the owners list you used is current? I stepped down as
fakeroot maintainer and removed myself many months ago.


While you're not listed as POC anymore, you're still listed as committer
for rawhide, F23 and F22 branches of fakeroot, so the list above is
correct.

Crap, I wish fedora had a usable pkgdb UI ;)


Upstream must have missed all the tickets you filled to improve things...


Do you think this behavior of yours fair?  I don't.
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: Needless use of %defattr (in 4464 packages)

2016-01-27 Thread Ralf Corsepius

On 01/27/2016 10:13 PM, Jason L Tibbitts III wrote:

"RC" == Ralf Corsepius <rc040...@freenet.de> writes:


RC> Are you sure the owners list you used is current?

I pulled them directly from pkgdb at the time I generated the list.
There's no way that they could have been any more current when I sent
the mail.


I realize, the pkgdb doesn't reflect reality. It seems to contain lots 
of "zombie maintainers". At least, I see people listed of whom I know to 
have left Fedora years ago, some of them even after a FESCO AWOL.


Looks seems to me as if Fedora doesn't have a proper "checkout from 
Fedora" process, which is gradually turning pkgdb into a "zombie 
maintainer" graveyard.


Ralf

--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: Needless use of %defattr (in 4464 packages)

2016-01-27 Thread Ralf Corsepius

On 01/27/2016 11:32 AM, Dominik 'Rathann' Mierzejewski wrote:

Hi, Ralf.

On Wednesday, 27 January 2016 at 09:28, Ralf Corsepius wrote:

On 01/25/2016 11:34 PM, Jason L Tibbitts III wrote:


fakeroot (athimm, rathann, corsepiu, moceap)


Are you sure the owners list you used is current? I stepped down as
fakeroot maintainer and removed myself many months ago.


While you're not listed as POC anymore, you're still listed as committer
for rawhide, F23 and F22 branches of fakeroot, so the list above is
correct.

Crap, I wish fedora had a usable pkgdb UI ;)

While we're at it: Did you notice that this package is completely messed 
up? I guess, I am going to BZ it.



Also, I noticed a number of maintainers on your list, whose accounts
should have been closed down (AWOL) and their package ownership
probably be removed (athimm is one example of such case, chitlesh
would be another one). What's going on here?


The list is correct according to PackageDB. I don't rememeber if anyone
ever initiated the non-responsive packager process for athimm or
chitlesh.


I don't know if somebody filed one against athimm (I had thought so), 
but I am the one who filed one against chitlesh 
(https://fedorahosted.org/fesco/ticket/1484).



Ralf

--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: Needless use of %defattr (in 4464 packages)

2016-01-27 Thread Ralf Corsepius

On 01/25/2016 11:34 PM, Jason L Tibbitts III wrote:


fakeroot (athimm, rathann, corsepiu, moceap)


Are you sure the owners list you used is current? I stepped down as 
fakeroot maintainer and removed myself many months ago.


Also, I noticed a number of maintainers on your list, whose accounts 
should have been closed down (AWOL) and their package ownership probably 
be removed (athimm is one example of such case, chitlesh would be 
another one). What's going on here?


Ralf


--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: Should 'dnf install gtk3-devel.i686' work?

2016-01-21 Thread Ralf Corsepius

On 01/20/2016 05:59 PM, Michael Schwendt wrote:

On Wed, 20 Jan 2016 17:32:52 +0100, Ralf Corsepius wrote:


IMO, this is supposed to work => Bug

The big question would be: Where?


It cannot work as long as gtk3-devel relies on pkgconfig(foo) dependencies
instead of arch-specific explicit Requires.


AFAIU,the problem behind this is, in case of multilibs, there are 
several providers providing non-arched rpm tags:


Example:

# rpm -q -provides -p libXt-devel-1.1.5-2.fc23.i686.rpm
libXt-devel = 1.1.5-2.fc23
libXt-devel(x86-32) = 1.1.5-2.fc23
pkgconfig(xt) = 1.1.5

# rpm -q -provides -p libXt-devel-1.1.5-2.fc23.x86_64.rpm
libXt-devel = 1.1.5-2.fc23
libXt-devel(x86-64) = 1.1.5-2.fc23
pkgconfig(xt) = 1.1.5


Apparently, dnf doesn't resolve such deps correctly, but seem to try to 
resolve such deps either by a "first match" or "primary arch" strategy 
and doesn't take a depchains an "inherited arch" into account:


# dnf remove libICE-devel libSM-devel libX11-devel libXt-devel

# dnf install libXt-devel.i686
...
Installing:
 libICE-devel  x86_64  1.0.9-3.fc23   fedora   54 k
 libSM-devel   x86_64  1.2.2-3.fc23   fedora   17 k
 libX11i6861.6.3-2.fc23   fedora  616 k
 libX11-devel  x86_64  1.6.3-2.fc23   fedora  984 k
 libXt i6861.1.5-2.fc23   fedora  174 k
 libXt-devel   i6861.1.5-2.fc23   fedora  450 k

[note: libICE-devel.i686, libSM-devel.i686 are missing]

Seems to me as if history is repeating - IIRC, we've had this issue in 
early stage of yum, as well ;)


Ralf



--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: Should 'dnf install gtk3-devel.i686' work?

2016-01-21 Thread Ralf Corsepius

On 01/21/2016 09:27 AM, Richard W.M. Jones wrote:

On Thu, Jan 21, 2016 at 04:10:00AM +0100, Ralf Corsepius wrote:

On 01/20/2016 08:23 PM, Richard W.M. Jones wrote:


I have filed a bug (against gtk3 for now) about this issue:

   https://bugzilla.redhat.com/show_bug.cgi?id=1300432


I still don't know the cause of this issue, I don't think this is
gtk3's fault (alone). It's possible to generate similar breakdowns
for many packages (My gut feeling is, this culprit is dnf).

Example:
# dnf install usbguard-devel.i686


I don't know about this package, but for gtk3-devel.i686
No prob. This was just a random package with fewer deps than gtk3, I 
picked up for testing.



I also
tried yum-deprecated with the same results.
I also tried - same result. I guess, investigating this any further will 
require pre-dnf Fedora.


Ralf
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: Should 'dnf install gtk3-devel.i686' work?

2016-01-20 Thread Ralf Corsepius

On 01/20/2016 08:23 PM, Richard W.M. Jones wrote:


I have filed a bug (against gtk3 for now) about this issue:

   https://bugzilla.redhat.com/show_bug.cgi?id=1300432


I still don't know the cause of this issue, I don't think this is gtk3's 
fault (alone). It's possible to generate similar breakdowns for many 
packages (My gut feeling is, this culprit is dnf).


Example:
# dnf install usbguard-devel.i686

Ralf

--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: Should 'dnf install gtk3-devel.i686' work?

2016-01-20 Thread Ralf Corsepius

On 01/21/2016 12:45 AM, Neal Gompa wrote:


We don't store libraries and headers in such a way that the different
arches can coexist without clobbering.
Headers being installed to /usr/include must be multilib capable. I.e. 
they either must be arch-independent or contain sufficient magic 
(conditionals) to cope with all fedora archs.



That would be possible if we
have something like this:
/usr/lib/
/usr/include/


Current practice is
/usr/include/ ... for nonarch headers.

/usr/{lib,lib64}/... for arched parts of a package, comprising arched 
headers.



For example, a 32-bit x86 platform would probably use
"i686-redhat-linux-gnu", whereas a 64-bit x86 platform would use
"x86_64-redhat-linux-gnu".

Without that, it would be tough to guarantee that installing the
32-bit version of a devel package would produce a consistent and sane
build compared to an actual 32-bit chroot.

No, cf. above.

Does anybody still have a non yum-only based x86_64 system? I suspecting 
and am pretty sure this issue is caused by yet another brokenness in dnf.


Ralf
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: Should 'dnf install gtk3-devel.i686' work?

2016-01-20 Thread Ralf Corsepius

On 01/20/2016 04:50 PM, Richard W.M. Jones wrote:

If you're on freshly installed Fedora 23 (x86-64), then

   dnf install gtk3-devel.x86_64

gets you everything you need to compile a simple Gtk3 application[1].

However on the same host if you do:

   dnf install gtk3-devel.i686

then there's a lot missing before you can compile a 32 bit Gtk3
application[2].  I had to install the following dependencies (found by
tedious trial-and-error) before I could compile it:

   dnf -y install 
{pango,pixman,zlib,libpng,expat,mesa-libEGL,libX11,libdrm,libxcb,libXau,libXdamage,libXfixes,libXxf86vm,libXext,mesa-libGL,libXrender,harfbuzz,graphite2,gdk-pixbuf2,atk,cairo-gobject,libXinerama,libXi,libXrandr,libXcursor,libXcomposite,wayland,libwayland-client,libxkbcommon,libwayland-cursor,mesa-libwayland-egl,libepoxy,at-spi2-atk,at-spi2-core,dbus,glib2,glibc}-devel.i686

Is this a bug or is it not expected this would work or I am doing it wrong?


IMO, this is supposed to work => Bug

The big question would be: Where?

Ralf

--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: F24 System Wide Change: Default Local DNS Resolver

2015-12-11 Thread Ralf Corsepius

On 12/11/2015 05:25 PM, Jiri Eischmann wrote:


So my worry is that we would be an OS which is more secure than others,
but doesn't work in many networks.
If something doesn't work reliably, the logical consequence to me would 
be to keep it strictly optional (opt-in) and not to make it default.



You can bet what the users would
decide for...
Exactly ... take into account the "user experience" some 
Fedora-"novelties" communicated over the years ;)


Ralf

--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org


Re: How to collect "bundled" virtual provide

2015-12-02 Thread Ralf Corsepius

On 12/02/2015 03:46 PM, Vít Ondruch wrote:


-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Dne 2.12.2015 v 15:30 Stephen Gallagher napsal(a):



In accordance with the bundling policy, it *is* carrying a virtual
Provides to allow us to identify whether it is affected by discovered
CVEs.



This brings me to interesting question, how to actually know that one
should be looking for some bundled library? I don't think this was ever
addressed,


c.f. the section
"Bundling and Duplication of system libraries"
in https://fedoraproject.org/wiki/Packaging:Guidelines


but I believe it'd be useful to have some page where we can
see what is bundled and where is it bundled. I don't think that
"repoquery" is the answer, since this does not give good enough overview
nor statistics, etc.

repoquery has been rendered widely unusable by dnf.


Ralf

--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: where is mariadb-10.0.21-1.fc23 ?

2015-11-11 Thread Ralf Corsepius

On 11/11/2015 09:29 AM, Adam Williamson wrote:

On Wed, 2015-11-11 at 07:02 +0100, Ralf Corsepius wrote:

Other strange case is the package perl-Event-RPC-1.06-1.fc21  [2]

even more strange [3] comment 16 says that push
perl-Event-RPC-1.07-1.fc23 and one minute later comment 17 says
perl-Event-RPC-1.06-1.fc23 has been pushed to the Fedora 23 ...


[2] https://bodhi.fedoraproject.org/updates/FEDORA-2015-16392
[3] https://bugzilla.redhat.com/show_bug.cgi?id=1264882


Similar - broken upgrade path:

dl.fedoraproject.org/pub/fedora/linux/updates/22/x86_64/p/perl-Event-RPC-1.07-1.fc22.noarch.rpm
dl.fedoraproject.org/pub/fedora/linux/development/23/x86_64/os/Packages/p/perl-Event-RPC-1.06-1.fc23.noarch.rpm


No, the OP had it right. In some cases, we can wind up with older
updates being pushed over newer ones.  That is, if an update 'foo-2.0-1'
is submitted, then an update 'foo-2.0-2' is submitted, then 'foo-2.0-2'
is pushed stable, then 'foo-2.0-1' is pushed stable *later* (which can
happen with auto-karma if the foo-2.0-1 update is never withdrawn),
2.0-1 can be pushed over the top of 2.0-2.


NVRs in later fedora release/updates *must* be greater than those in 
older release, at all times.


This is a defect of the release process, which needs to be fixed.

Ralf

--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: where is mariadb-10.0.21-1.fc23 ?

2015-11-10 Thread Ralf Corsepius

On 11/11/2015 03:26 AM, Sérgio Basto wrote:

Hi,

Where is mariadb-10.0.21-1.fc23 ? [1] says that have been push to stable
but upgrading my system, mariadb is downgraded from mariadb-10.0.21 to
mariadb-10.0.20 !

[1] https://bodhi.fedoraproject.org/updates/FEDORA-2015-13442


Broken upgrade path.

The NEVR of mariadb in fc23 is less than that in fc22:

dl.fedoraproject.org/pub/fedora/linux/updates/22/x86_64/m/mariadb-common-10.0.21-1.fc22.x86_64.rpm
dl.fedoraproject.org/pub/fedora/linux/development/23/x86_64/os/Packages/m/mariadb-common-10.0.20-3.fc23.x86_64.rpm


Other strange case is the package perl-Event-RPC-1.06-1.fc21  [2]
even more strange [3] comment 16 says that push
perl-Event-RPC-1.07-1.fc23 and one minute later comment 17 says
perl-Event-RPC-1.06-1.fc23 has been pushed to the Fedora 23 ...


[2] https://bodhi.fedoraproject.org/updates/FEDORA-2015-16392
[3] https://bugzilla.redhat.com/show_bug.cgi?id=1264882


Similar - broken upgrade path:

dl.fedoraproject.org/pub/fedora/linux/updates/22/x86_64/p/perl-Event-RPC-1.07-1.fc22.noarch.rpm
dl.fedoraproject.org/pub/fedora/linux/development/23/x86_64/os/Packages/p/perl-Event-RPC-1.06-1.fc23.noarch.rpm



Ralf

--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Retire a package from Fedora i686 (not x86_64)

2015-11-06 Thread Ralf Corsepius

On 11/07/2015 04:55 AM, Reindl Harald wrote:



Am 06.11.2015 um 20:11 schrieb Germano Massullo:

For example, SSE3 instructions set is one of the minimum requirements
and 99% of 32 bit only CPUs do not support it. Only Pentium 4 >=
Prescott architecture supports it


seriously?


Probably.


with that argumentation Fedora would drop i686 at all
No. darktable handles the situation on sse3-less CPUs gracefully at 
run-time.


The actually problem is darktable wanting to be compiled with -msse3, 
which means being compiled with a Fedora incompatible instruction set, 
on both i386 and x86_64.



well, i don't have any non x86_64 machien but the argumentation is bous
You are right, these days in professional PC-usage, i686ers likely are 
rare and hard to find.


But in personal (private) PC-usage, the situation is different. There, 
5/6-year old 32bit PCs are still wide spread and will be supported by 
Windows for many years. Also consider, people are using Linux on such 
machines to extend these machines life time.


Feel free to drop the i386, if you want drop the end-user/desktop market 
and to leave this market to Ubuntu, Debian and other distributions.


Ralf

--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Retire a package from Fedora i686 (not x86_64)

2015-11-06 Thread Ralf Corsepius

On 11/07/2015 05:03 AM, Reindl Harald wrote:



Am 07.11.2015 um 05:00 schrieb Luya Tshimbalanga:

On 06/11/15 07:29 PM, Ralf Corsepius wrote:

But if upstream doesn't care, it's going to be a problem. :-(

Exactly - That's the actual problem. Upstream does not care and Fedora
seems unable to address this issue.

Ralf


According to my system, it has SSSE3. Is it SSE3?

That's what my question actually was about.

I see ssse3 on all my x86_64ers, I see sse3 on my 32bit atoms, but I 
don't know if ssse3 implies sse3 and I don't know what -msse3 actually 
does to the instruction set when being used on x86_64ers and which 
impact it has (-msse3 is not part of Fedora's gcc implicit CFLAGS).



any system not older than 10 years has SSE3  and frankly systems older
than 10 years are hardly a traget for Fedora at all


So, Fedora or Linux as a resort to escape Windows on old HW is not a 
Fedora target anymore?


Ralf

--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Retire a package from Fedora i686 (not x86_64)

2015-11-06 Thread Ralf Corsepius

On 11/06/2015 09:50 PM, Stuart Gathman wrote:

On 11/06/2015 02:11 PM, Germano Massullo wrote:


For example, SSE3 instructions set is one of the minimum requirements
and 99% of 32 bit only CPUs do not support it. Only Pentium 4 >=
Prescott architecture supports it.


For that kind of thing, add a runtime test for required CPU features at
startup.

That's what they actually do.

cf. https://bugzilla.redhat.com/show_bug.cgi?id=1278064#c14
$ darktable
[dt_init] unfortunately we depend on SSE3 instructions at this time.
[dt_init] please contribute a backport patch (or buy a newer processor).



That may not be necessary if the app already fails in a friendly way on
old CPUs (as opposed to hanging or mysterious crashes).


Ralf

--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Retire a package from Fedora i686 (not x86_64)

2015-11-06 Thread Ralf Corsepius

On 11/06/2015 10:00 PM, Kevin Kofler wrote:

Germano Massullo wrote:

For example, SSE3 instructions set is one of the minimum requirements and
99% of 32 bit only CPUs do not support it. Only Pentium 4 >= Prescott
architecture supports it.


I think building it with SSE3 is better than excluding the architecture
entirely. And FYI, requiring SSE3 is not really allowed even for x86_64 (you
are allowed to assume only SSE2), so by that argument, there is no
architecture left.
ACK. Does anybody know if there are any x86_64/64bit-CPUs which do not 
support sse3?


I don't see sse3 in /proc/cpuinfo of any machine I have, but I also 
don't see any runtime error/warning from darktable.



Of course, a better solution would be to fix the package to work on all CPUs
you support.

ACK.


But if upstream doesn't care, it's going to be a problem. :-(
Exactly - That's the actual problem. Upstream does not care and Fedora 
seems unable to address this issue.


Ralf

--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: make unmaintained ??

2015-10-26 Thread Ralf Corsepius

On 10/26/2015 05:21 PM, drago01 wrote:

On Sun, Oct 25, 2015 at 8:24 PM, Stephen John Smoogen  wrote:


On Oct 25, 2015 12:53, "Jan Kratochvil"  wrote:


On Sun, 25 Oct 2015 01:07:47 +0200, Zbigniew Jędrzejewski-Szmek wrote:

I built 4.1 for rawhide. If that checks out to be OK, I can push
an update for F23 also.


I do not understand why a major rebase could be permitted after all the
F-23
freezing stages?  It may cause FTBFSes or even broken builds.  What is
then
all the release engineering good for?  Why not to just run Rawhide then?



I have to agree. I have been bitten too many times by minor tweaks breaking
builds in the OS. However the rules where a completely frozen build system
was causing problems in the past so I am expecting make is considered less
important than gcc?


We have been shipping gcc bugfix updates all the time ... there is no
reason why we shouldn't do the same for make.


I do not agree with you. Make has a long history and has been known to 
be notorious of introducing subtile bugs and behavioral changes in minor 
releases.


IMO, this should be sufficient reason to apply maximal prudence and 
caution to any update to make.


In other words, I consider it reasonable apply make updates to rawhide 
only and to watch for what will happen during the next mass-rebuild.


Ralf





--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: dnf and file provides

2015-10-24 Thread Ralf Corsepius

On 10/24/2015 03:55 AM, Adam Williamson wrote:

On Fri, 2015-10-23 at 18:19 -0600, Orion Poplawski wrote:

Got this is a resent koji rawhide build:

DEBUG util.py:393:  No matching package to install: '/bin/csh'

I'm assuming this is a quirk of dnf now being the default, but needs
to
get fixed.


There is no /bin/csh in the package, only /usr/bin/csh


/bin/csh is an explicit provides of the tcsh package

The fact certain versions of dnf don't handle them correctly is yet 
another bug in dnf and/or it's infrastructure.



. /bin is a
symlink to /usr/bin , so you can call /bin/csh and it'll work, but
/bin/csh does not exist in the package. Thus it does not provide it.
Requires should always use /usr/bin or /usr/sbin .


/bin/csh is similar to /bin/sh.

They are being used in "#!" shebangs and therefore must stay in packages 
and must be handles correctly, independently of what the proponents of 
UsrMov believe.




--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: dnf and file provides

2015-10-24 Thread Ralf Corsepius

On 10/24/2015 02:19 AM, Orion Poplawski wrote:

Got this is a resent koji rawhide build:

DEBUG util.py:393:  No matching package to install: '/bin/csh'

I'm assuming this is a quirk of dnf now being the default, but needs to
get fixed.


This is dnf bug https://bugzilla.redhat.com/show_bug.cgi?id=1271053

which has broken f24's builders.

Ralf

--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: jehane pushed to fusioninventory-agent (f23). "new version (..more)"

2015-10-15 Thread Ralf Corsepius

On 10/15/2015 07:46 PM, notificati...@fedoraproject.org wrote:

 From c7493300b75beeed3980723ecddc68185438a0a8 Mon Sep 17 00:00:00 2001
From: jehane 
Date: Sun, 11 Oct 2015 17:01:09 +0200
Subject: new version

- Upstream switch to github, minor spec adaptation
---
  .gitignore |  1 +
  fusioninventory-agent.spec | 16 ++--
  sources|  2 +-
  3 files changed, 12 insertions(+), 7 deletions(-)

diff --git a/.gitignore b/.gitignore
index c55cab8..5bdc389 100644
--- a/.gitignore
+++ b/.gitignore
@@ -1,2 +1,3 @@
  /FusionInventory-Agent-2.3.15.tar.gz
  /FusionInventory-Agent-2.3.16.tar.gz
+/2.3.17.tar.gz
diff --git a/fusioninventory-agent.spec b/fusioninventory-agent.spec
index 75572f2..a8de963 100644
--- a/fusioninventory-agent.spec
+++ b/fusioninventory-agent.spec
@@ -9,11 +9,11 @@ Group:   Applications/System
  License: GPLv2+
  URL: http://fusioninventory.org/

-Version: 2.3.16
-Release: 5%{?dist}
+Version: 2.3.17
+Release: 1%{?dist}
  #BuildArch:   noarch
-Source0: 
http://search.cpan.org/CPAN/authors/id/G/GR/GROUSSE/FusionInventory-Agent-%{version}%{?prever}.tar.gz
-Source1:   %{name}.cron
+Source0: 
https://github.com/fusioninventory/fusioninventory-agent/archive/%{version}.tar.gz
+Source1: %{name}.cron
  #Source2:   %{name}.init
  #Source3:   %{name}.service

@@ -163,7 +163,7 @@ Requires:   perl(Parse::EDID)
  %description task-inventory
  fusioninventory-task-inventory
  %prep
-%setup -q -n FusionInventory-Agent-%{version}%{?prever}
+%setup -q -n %{name}-%{version}%{?prever}

  # This work only on older version, and is ignored on recent
  cat < - 2.3.17
+- new version
+- Upstream switch to github, minor spec adaptation


Please reconsider the change and pick up tarballs from cpan.org.

Ralf


--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel

Re: Proposal: retire lesstif in f24 and beyond

2015-10-11 Thread Ralf Corsepius

On 10/10/2015 07:39 PM, Zbigniew Jędrzejewski-Szmek wrote:

On Sat, Oct 10, 2015 at 07:20:22AM +0200, Ralf Corsepius wrote:



I know, we are late in the release schedule, but I am considering to
switching at least Inventor to motif on fc23, as well - It's
unimportant enough to most users, but is important to me ;)


I think that in a case of leaf package like that it totally makes
sense to switch even this late before release. Removal of
a dependency on lesstif seems important enough.


Rebuilding Inventor against motif requires switching
mesa-libGLw and Inventor to motif, i.e. a chain build consisting of
mesa-libGLw and Inventor.

As Inventor seems to be the only user of mesa-libGLw, this should be 
pretty harmless.


Unless somebody objects, I am going to rebuild these 2 packages for fc23 
tomorrow.


Ralf

PS.: derelict-GL3-devel also claims to require mesa-libGLw, but I can
not spot any actual source-code nor object dependency beween GLw nor
Xm. I therefore am inclined to believe this to be a packaging bug in
derelict.





--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Proposal: retire lesstif in f24 and beyond

2015-10-09 Thread Ralf Corsepius

On 10/09/2015 09:17 PM, Stephen John Smoogen wrote:

On 8 October 2015 at 17:04, Kevin Kofler  wrote:

Christopher Meng wrote:

IMO motif should 'Obsoletes' lesstif in Fedora since motif is free now.


The reason we kept lesstif even after OpenMotif was finally freed is because
OpenMotif only implements the Motif 2 API, whereas lesstif implemented the
Motif 1 API. Back then, a lot of Motif applications did not compile with
Motif 2.



A lot of applications still do not mainly because by the time
OpenMotif was out.. "Motif" was dead except for legacy computer code
that a lot of research institutes still use. It looks from the amount
of porting that has been done in this thread that a lot of those
problems are easier to fix now?

 From the people who did the porting was it a quick fix or a bunch of patches?


As far as the packages I touched are concerned, the "porting effort" was 
very low.


The effort basically was reflecting the packaging dep-naming changes 
into the specs.


I did not have to apply any changes to the packages' source code. My 
guess is, on the code-level, today's "Motif" is sufficiently backward 
compatible, the packages already saw testing against Motif or even been 
developed on Motif (and then ported to lesstif)[1]. I point, I which 
makes me wonder, is Fedora seemingly being late in the switch to Motif 
in comparison to other distros.


A problem hiding is package installation conflicts between the *-devel 
package of different versions of the lesstif, openmotif and motif 
packages. Therefore, I tried to stay with lesstif on fedora < 24 and 
switch to motif only on fedora >= 24.


I know, we are late in the release schedule, but I am considering to 
switching at least Inventor to motif on fc23, as well - It's unimportant 
enough to most users, but is important to me ;)


Ralf

[1] In the ole' days, lesstif almost always had been the troublesome 
part, which required app-code to me modified, because of missing 
features or incompatibilities ;)


--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Summary/Minutes from today's FESCo Meeting (2015-10-07)

2015-10-09 Thread Ralf Corsepius

On 10/09/2015 12:08 AM, Dominik 'Rathann' Mierzejewski wrote:

On Wednesday, 07 October 2015 at 21:17, Stephen Gallagher wrote:

Meeting summary
---

[...]

* #1483 Decision on bundling policy in the Fedora Package Collection
   (sgallagh, 18:11:40)
   * LINK: http://paste.fedoraproject.org/276064/44243383/ is sgallaghs
 proposal without the critpath distinction  (nirik, 18:43:49)
   * AGREED: Adjust the packaging policy as described in
 http://paste.fedoraproject.org/276064/44243383/ (+5, 3, -1)
 (sgallagh, 18:57:44)
   * ACTION: tibbs|w to inform FPC and work on removing the anti-bundling
 stuff from the guidelines  (sgallagh, 18:59:17)


This was handled far too quickly and without considering the full
consequences of the change that was passed. Also, the way you handled
this caused a lot of resentment among the FPC members (or at least
that's the impression I have).


Seconded.

What FESCO did was such kind of utterly disrespectful and rude toward FPC.

ATM, I consider it to be a matter politeness not furtherly pronounce my 
opinion because I would have to be personal.





--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Summary/Minutes from today's FESCo Meeting (2015-10-07)

2015-10-09 Thread Ralf Corsepius

On 10/09/2015 03:51 PM, Matthew Miller wrote:

On Fri, Oct 09, 2015 at 01:50:27PM +0100, Richard W.M. Jones wrote:

This opens the door to all kinds of duplication, waste of disk space, waste
of RAM, symbol conflicts and unfixed security issues!

I agree - the new wording does appear to give in to poor programming
practices.


Do you have suggestions for improvements?


Do I have to pronouce the obivious? FESCO to revert their faulty decision.

--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Proposal: retire lesstif in f24 and beyond

2015-10-08 Thread Ralf Corsepius

On 10/08/2015 12:24 PM, Marcin Juszkiewicz wrote:

W dniu 08.10.2015 o 12:06, Marcin Juszkiewicz pisze:

W dniu 02.10.2015 o 13:33, Jon Ciesla pisze:

Lesstif being basically dead upstream and motif being available, I think
it's probably time to retire lesstif.



If anyone knows of other packages using it, please let me know and I can
migrate them.


dinotrace
fbb
xastir
xmbdfed
xvarstar

Those are blocking aarch64. Will dig for more.


alliance
polyml

That's all I found.
I believe to have taken care about all of these (but alliance) 
throughout today and rebuilt them against motif on rawhide.


alliance seems multiply pretty broken independently of motif/lesstif.
I would consider it to be a candidate for retirement.

Ralf

--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: XSD on EPEL7

2015-10-08 Thread Ralf Corsepius

On 10/08/2015 05:30 PM, Antonio Trande wrote:

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On 10/08/2015 05:19 PM, Jakub Jelen wrote:

On 10/08/2015 03:13 PM, Antonio Trande wrote:

On 10/01/2015 05:35 PM, Antonio Trande wrote:

-BEGIN PGP SIGNED MESSAGE- Hash: SHA256

Hi all.

I need XSD on EPEL7. Is it possible a build?

Package: https://admin.fedoraproject.org/pkgdb/package/xsd/
Bugzilla request:
https://bugzilla.redhat.com/show_bug.cgi?id=1251682

Thanks.

- -- Antonio Trande


Please, can anyone contact the XSD maintainer or co-maintainers?
Bug: https://bugzilla.redhat.com/show_bug.cgi?id=1251682


The main contact was informed about your bug (if his mail is still
working), since the bug is assigned to him. Not sure how active he
is he at this point. Last build he issued in koji is from 2013.
This means 2 years of inactivity.


cf. http://koji.fedoraproject.org/koji/builds?userID=anttix
His last activity on koji seems to date back to 2013-10-23

Ralf

--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Orphaned Packages in rawhide (2015-10-07)

2015-10-07 Thread Ralf Corsepius

On 10/08/2015 07:11 AM, Tomasz Torcz wrote:

On Wed, Oct 07, 2015 at 09:56:53PM +, opensou...@till.name wrote:

Note: If you received this mail directly you (co)maintain one of the affected
packages or a package that depends on one. Please adopt the affected package or
retire your depending package to avoid broken dependencies, otherwise your
package will be retired when the affected package gets retired.




iipsrv (maintained by: trasher)
iipsrv-1.0.0-4.0.git2431b45.fc23.i686 requires /sbin/restorecon

ipsilon (maintained by: puiterwijk, simo)
ipsilon-base-1.1.0-1.fc24.noarch requires /usr/sbin/restorecon

ladvd (maintained by: ixs, ttorcz)
ladvd-selinux-1.1.0-4.fc24.i686 requires /sbin/restorecon, 
/usr/sbin/semodule

ocp (maintained by: cra)
ocp-0.1.22-0.6.20150224gita07bf5d.fc23.i686 requires 
/sbin/restorecon

ocsinventory (maintained by: remi, xavierb)
ocsinventory-reports-2.1.2-6.fc23.noarch requires 
/sbin/restorecon
ocsinventory-server-2.1.2-6.fc23.noarch requires 
/sbin/restorecon


   So what is correct requires nowadays? /usr/sbin/restorecon? Something else?

Both should work.

/usr/sbin/restorecon is a file-provides of the policycoreutils package
and
/sbin/restorecon is an explicit provides of the policycoreutils package

# rpm -qlp policycoreutils-2.4-13.fc24.x86_64.rpm \
 | grep sbin/restorecon
...
/usr/sbin/restorecon

# rpm -q --provides -p policycoreutils-2.4-13.fc24.x86_64.rpm \
 | grep sbin/restorecon
...
/sbin/restorecon

=> Likely, something is broken with the depchecker used to generated the 
reports above.


Ralf

--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Proposal to reduce anti-bundling requirements

2015-10-02 Thread Ralf Corsepius

On 10/02/2015 01:46 PM, Tomas Mraz wrote:

On Pá, 2015-10-02 at 13:18 +0200, Vít Ondruch wrote:

Dne 30.9.2015 v 16:52 Ralf Corsepius napsal(a):


Like I've said many times before, I feel Fedora needs a serious
vulnerability in a widespread bundled or static library, such that
people finally comprehend the harm of bundling.


This harms Fedora but not the upstream project which bundles. If there
is discovered security issue in the bundled library, they fix it and
release new version, they are in users view the good guys who cares
about security. If we fix the same issue in unbundled library, it is
invisible for users and at the end they demand updated version of the
upstream project, since they believe that the issues is not fixed in
Fedora yet.

I am afraid that no matter how much education you'd like to apply to
this issue, you will never reduce it, since honestly, most of the
development is done on different platforms then Linux, where bundlind of
various kinds is a norm.

And TBH, as much as I hate this reduction of anti-budnling requirements,
I also hate to hear from upstream that they don't wish their SW to be
included in Fedora, since we break it due to unbundling policies.


This seems like a strong argument for the current case where the
bundling exception is provided by FPC. The question is only whether it
needs to be FPC or some another body. The bundling should be approved
only for projects where upstream is fully active and cares about the
security vulnerabilities in the bundled copies of software well.
Correct. That's one of the criteria, FPC is trying to consider when 
granting bundling exceptions. Openly said, these are the easy cases, we 
often grant bundling exceptions.


The problematic ones are those cases, when it's obvious upstream lacks 
experience and/or technical skills to understand "unbundling" 
/"bundling" and resources to take care about "upstreams of their bundled 
sources. These often are smaller projects - in many cases - one-man shows.


Ralf

--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Proposal: retire lesstif in f24 and beyond

2015-10-02 Thread Ralf Corsepius

On 10/02/2015 01:33 PM, Jon Ciesla wrote:

Lesstif being basically dead upstream and motif being available, I think
it's probably time to retire lesstif.  I've migrated the remaining
packages still using it I could find in rawhide:



Inventor


[Inventor maintainer speaking]

Migrating Inventor to motif should not be much of a problem, however in 
past, this wasn't possible, because Fedora's lesstif-devel and 
motif-devel clashed and could not be installed in parallel.


I'll try to investigate.

Ralf



--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Proposal to reduce anti-bundling requirements

2015-10-02 Thread Ralf Corsepius

On 10/02/2015 01:18 PM, Vít Ondruch wrote:

Dne 30.9.2015 v 16:52 Ralf Corsepius napsal(a):

Like I've said many times before, I feel Fedora needs a serious
vulnerability in a widespread bundled or static library, such that
people finally comprehend the harm of bundling.


This harms Fedora but not the upstream project which bundles.
Exactly. This "bundling everything" is upstream-centric. It's convenient 
to them, but it's harmful to wider system integration.



If there
is discovered security issue in the bundled library, they fix it and
release new version, they are in users view the good guys who cares
about security.
Only if there is an active upstream, who actively works on its bundled 
sources. This applies to bigger projects such as Firefox and Chromium, 
but often doesn't apply to smaller projects.


There, bundled sources often pretty soon don't get much attention and 
simply rot. Worse, when such upstream goes AWOL.



I am afraid that no matter how much education you'd like to apply to
this issue, you will never reduce it, since honestly, most of the
development is done on different platforms then Linux, where bundlind of
various kinds is a norm.
Sure, but IMO, this shouldn't be reason for us to follow these system's 
mistakes.


When you have a look at these systems, you'll soon notice bundling is 
one of the primary causes for vulnerabilities on these systems.



And TBH, as much as I hate this reduction of anti-budnling requirements,
I also hate to hear from upstream that they don't wish their SW to be
included in Fedora, since we break it due to unbundling policies.
So be it. It's their decision - I don't want Fedora to be taken hostage 
by short sighted upstreams and their non-system-integratible designs.


Also, if there's  sufficient interested in a piece of SW and if their 
design isn't too crappy, it should not be much of a problem for Fedora 
to properly integrate a SW into Fedora.


Ralf


--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Proposal to reduce anti-bundling requirements

2015-10-01 Thread Ralf Corsepius

On 09/30/2015 06:32 PM, Matthew Miller wrote:

On Wed, Sep 30, 2015 at 04:52:48PM +0200, Ralf Corsepius wrote:

people not declaring their bundles and not care about policies did the
same before: not declare it and not ask for exceptions - there is a
logical flow in "now that i don't need to ask FPC i don't declare it"

Exactly, that's what I would consider a serious regression.


But re-read what you're just replying to. The thing is, there's all
sorts of bundling going on all throughout Fedora under the radar.
I know - while Fedora is doing pretty good job on unbundling in many 
cases, there are case where Fedora is doing a missable job.


IMO, this should be reason to encourage fighting bundling and not to 
weaken unbundling and weaken enforcing unbundling.  Which is - as I feel 
- what you are currently doing.


Ralf




--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Proposal to reduce anti-bundling requirements

2015-10-01 Thread Ralf Corsepius

On 10/02/2015 12:09 AM, Adam Williamson wrote:

On Thu, 2015-10-01 at 23:54 +0200, Ralf Corsepius wrote:


Seems to me, as if today's generation of fedora users and esp.
current
Fedora leaders need to go through the lessons people who had been
using
Linux then were tought the cruel way.


I know you always think you're the ONLY ONE WHO UNDERSTANDS, but the
people proposing this have been doing it just as long as you.
I'm long enough in open source to ignore this rude offensive tone of 
yours for now.



They know
the issues. You can't successfully argue against them by pretending
they don't, and should just yield to your unquestionably superior
wisdom.


Their words and action speak a clear and misunderstandable language. 
Their proposal is just populist and against common sense.

--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Proposal to reduce anti-bundling requirements

2015-10-01 Thread Ralf Corsepius

On 09/30/2015 05:20 PM, Neal Gompa wrote:

On Wed, Sep 30, 2015 at 10:52 AM, Ralf Corsepius <rc040...@freenet.de
<mailto:rc040...@freenet.de>>wrote:

On 09/30/2015 04:25 PM, Reindl Harald wrote:

the opposite is more likely: people trying to avoid the FPC
burden now

can declare it without fearing somebody takes notice and points
out a
violation

If they don't care or are not aware about the consequences of their
bundling?

Like I've said many times before, I feel Fedora needs a serious
vulnerability in a widespread bundled or static library, such that
people finally comprehend the harm of bundling.

Ralf


​Are you saying ​we're doing our job too well, so people don't see the
advantages of the effort anymore?


No. I am saying actively fighting bundling has prevented cases like the 
zlib disaster 15+ years to return.


Seems to me, as if today's generation of fedora users and esp. current 
Fedora leaders need to go through the lessons people who had been using 
Linux then were tought the cruel way.


Ralf


--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Proposal to reduce anti-bundling requirements

2015-09-30 Thread Ralf Corsepius

On 09/30/2015 04:25 PM, Reindl Harald wrote:



Am 30.09.2015 um 16:13 schrieb Orion Poplawski:

On 09/30/2015 07:45 AM, Fabian Deutsch wrote:

Yes, I also see this as a good compromise.
We then have the ability to at least track bundling.


I'd just like to point out that we have always had the requirement for
package that bundled libraries to carry the "Provides: bundled(libname)"
metadata.  What's new here is not needing to go through the FPC to get
an exception.  Which perhaps leads to people not declaring their
packages bundled libraries.


how do you come to that conclusion?

people not declaring their bundles and not care about policies did the
same before: not declare it and not ask for exceptions - there is a
logical flow in "now that i don't need to ask FPC i don't declare it"

Exactly, that's what I would consider a serious regression.

This proposal effectively is a carte-blanche to bundling and 
carelessness, which I would expect to seriously impact the quality of 
Fedora.



the opposite is more likely: people trying to avoid the FPC burden now
can declare it without fearing somebody takes notice and points out a
violation
If they don't care or are not aware about the consequences of their 
bundling?


Like I've said many times before, I feel Fedora needs a serious 
vulnerability in a widespread bundled or static library, such that 
people finally comprehend the harm of bundling.


Ralf

--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: redhat bugzilla probs

2015-09-28 Thread Ralf Corsepius

On 09/21/2015 03:38 PM, Ralf Corsepius wrote:

Hi,

When trying to file a BZ, bugzilla just greeter me with this:


Proxy Error

The proxy server received an invalid response from an upstream server.
The proxy server could not handle the request POST /post_bug.cgi.

Reason: Error reading from remote server

Apache Server at bugzilla.redhat.com Port 443



Right now, it is happening, again - Same error as last week:


Proxy Error

The proxy server received an invalid response from an upstream server.
The proxy server could not handle the request POST /show_bug.cgi.

Reason: Error reading from remote server

Apache Server at bugzilla.redhat.com Port 443


Ralf


--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Announcing the release of Fedora 23 Beta!

2015-09-22 Thread Ralf Corsepius

On 09/22/2015 07:33 PM, Matthew Miller wrote:

On Tue, Sep 22, 2015 at 06:21:00PM +0100, Pádraig Brady wrote:

I just used dnf distro-sync as per:
https://fedoraproject.org/wiki/Upgrading_Fedora_using_yum#Fedora_22_-.3E_Fedora_23

This went fine, and I'm now typing this on F23 beta.
What are the main advantages of system-upgrade?
Should the above wiki mention the system-uprade instructions?


There's actually a "fedup" script as part of the package. I think we
should update the dnf-plugin-system-upgrade to Provide: fedup, and keep
the instructions the same. Rationale:


IMO, this discussion is moot.

Because ppckaging-wise, the dnf-plugin-system-upgrade situation 
currently is broken [1]:


dnf-plugin-system-upgrade Obsoletes: fedup, but lacks the corresponding 
Provides.


The result is
- "dnf install fedup" installs fedup
- subsequent "dnf update" kicks out fedup and replaces it with 
dnf-plugin-system-upgrade.


Ralf

[1] https://bugzilla.redhat.com/show_bug.cgi?id=1264937
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

redhat bugzilla probs

2015-09-21 Thread Ralf Corsepius

Hi,

When trying to file a BZ, bugzilla just greeter me with this:


Proxy Error

The proxy server received an invalid response from an upstream server.
The proxy server could not handle the request POST /post_bug.cgi.

Reason: Error reading from remote server

Apache Server at bugzilla.redhat.com Port 443


Ralf
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Proposal to reduce anti-bundling requirements

2015-09-15 Thread Ralf Corsepius

On 09/14/2015 01:56 PM, Haïkel wrote:

2015-09-14 13:17 GMT+02:00 Andrew Haley :

On 09/13/2015 09:23 PM, Haïkel wrote:

I'm not speaking about PHP, most of the upstream I deal with
are python developers. Bad habits are rather spreading than
regressing.


We're not going to solve that problem by adopting bad habits
ourselves.

Andrew.



Did I request somewhere to *drop* unbundling?
I'm more concerned by the current habit to let bundled libraries sneak
in the repositories without being properly tracked rather than a
non-existing one.


a) We don't have any such tracking system.
b) So far, this has not been a problem.

In the past, this these issues were commonly worked around by Fedora 
maintainers forking in private and them feeding them into Fedora as set 
of patches.



Our role is mitigate bad habits and educate upstream, not ignoring them.
Right, but you're underestimating the stubbornness and 
non-cooperativeness of some upstream and fedora maintainer.
They usually believe to have an "ultra-clever design" and the FPC to be 
dumb idiots who are unable to comprehend their cleverness.


Ralf


--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Packaging guidelines for documentation clairfication needed

2015-09-14 Thread Ralf Corsepius

On 09/14/2015 04:13 PM, Richard Shaw wrote:

While working through a package review[1] this excerpt from the
documentation section[2] was brought to my attention:

"Marking a /relative/ path with |%doc| in the |%files| section will
cause RPM to copy the referenced file or directory from |%_builddir| to
the proper location for documentation. Files can also be placed in
|%_pkgdocdir|, and the build scripts of the software being packaged may
do this automatically when called in |%install|. However, mixing these
methods is problematic and may result in duplicated or conflicting
files, so use of |%doc| with /relative/ paths and installation of files
directly into |%_pkgdocdir| in the same source package is forbidden."

In my case the project is installing html documentation during "make
install". Reading this pedantically, it would appear that would prevent
me from using %doc to install the obligatory COPYING, README, ChangeLog,
NEWS, etc...

This doesn't seem to be very practical and I'm not sure that's what was
intended by the guidelines.


Older versions of rpm allowed mixing relative %doc and direct installs 
into %_pkgdocdir.


rpm - as upstream calls it - "fixed it" (IMHO, they broke rpm - of 
course upstreams disagrees with me).


As a consequence of this, rpm now often errors out, when mixing  both 
styles. The only reliable way, now seems to be to either manually 
install everything to %_pkgdocdir directly or only use relative %doc.


ATM, I am recommending against using relative %doc and recommend to 
directly install docs into %_pkgdocdir.


You typically end up with something similar to:

%install
make install DESTDIR=${RPM_BUILD_ROOT}

install ... COPYING README ... ${RPM_BUILD_ROOT}%{_pkgdocdir}

%files
%{_pkgdocdir}
...


Ralf




--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Proposal to reduce anti-bundling requirements

2015-09-10 Thread Ralf Corsepius

On 09/10/2015 03:53 PM, Stephen Gallagher wrote:

I assume that subject line got your attention.



The reason for this proposal is relatively simple: we know the
advantages to unbundling, particularly with security and resource-
usage. However, the world's developer community largely *does not
care*. We fought the good fight, we tried to bring people around to
seeing our reasoning and we failed.


My view: It's an ongoing struggle and fight against upstream 
incompetence, carelessness, sloppiness and low-quality crap software. 
It's a fight we should not give up to, because it would cause damage the 
quality of Fedora.


In that sense, I feel you are undermining and torpedoing Fedora.

Ralf



--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: [Fedora-packaging] Proposal to reduce anti-bundling requirements

2015-09-10 Thread Ralf Corsepius

On 09/10/2015 04:06 PM, Stephen Gallagher wrote:

On Thu, 2015-09-10 at 09:03 -0500, Jon Ciesla wrote:



On Thu, Sep 10, 2015 at 8:53 AM, Stephen Gallagher  wrote:

I assume that subject line got your attention.


Most definitely. :)

So it's basically the same but without FPC as a gatekeeper?  Do you
have any proposals for enforcement?  A periodic query of Provides
(bundled-foo) and a BZ requesting a review?  Sometime projects
enable unbundling over time.




I don't know that enforcement is strictly necessary. Maintainers that
care will self-enforce. Maintainers that don't care won't be aided by
this.


Are you talking about upstream maintainers of fedora maintainers?

The cause of the majority of cases of bundling is upstream maintainers 
who violently refuse to comprehend the evilness of bundling and who use 
bundling because "it's so convenient" to them.



"Enforcement" implies adding more heavy process, which is part of the
problem this is trying to avoid.
You don't seem to be aware about the fact FPC already tries to enforce 
unbundling. Yes, this is a heavy and time-consuming process, esp. on 
occasions upstream's behave stubborn and refuse to listen.


Ralf

--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Proposal to reduce anti-bundling requirements

2015-09-10 Thread Ralf Corsepius

On 09/10/2015 04:08 PM, Josh Boyer wrote:

On Thu, Sep 10, 2015 at 9:53 AM, Stephen Gallagher  wrote:



Is the intention of your proposal to also allow Chromium into the main
Fedora repos?  I honestly can't tell where it draws the line.


We have a long list of bundling exceptions in Fedora. I do not see much 
reasons why Chromium (or parts of it) could not be on this list.


Ralf

--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: bodhi2: ACL validation mechanism was unable to determine ACLs

2015-08-29 Thread Ralf Corsepius

On 08/29/2015 05:40 PM, Rex Dieter wrote:

Ralf Corsepius wrote:


On 08/28/2015 01:00 PM, Rex Dieter wrote:

Ralf Corsepius wrote:



This morning, bodhi2 doesn't allow me to submit an update. After a
seemingly successful login-in, when trying to submit an update, a popup
pops up telling me:

ACL validation mechanism was unable to determine ACLs


Known issue, I hit it yesterday and filed a bug.

bodhi upstream has been fixed, not sure when the fix will be rolled out
into production.


Does this mean my hung job locks up submissions issue is unrelated or
doesn't exist at all?


I don't know what hung job locks up submissions means, so I don't know.


I had build a package for fc24, fc23 and fc22. The fc24 and fc23-builds 
succeeded, the fc22-build[1] hung in koji until the build-jobs timed out 
24 hours later.


During these 24 hours, I wasn't able to submit the fc23-built package 
for update in bodhi2.


Ralf

[1] https://koji.fedoraproject.org/koji/taskinfo?taskID=10843003

--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: bodhi2: ACL validation mechanism was unable to determine ACLs

2015-08-28 Thread Ralf Corsepius

On 08/28/2015 11:58 AM, Kevin Kofler wrote:

Ralf Corsepius wrote:

Also, I have not found any means to kill this job in bodhi/koji,


Had you tried koji cancel-task 10843003? (It's too late to try it now, now
that the build has timed out.)


No, I wasn't aware this option exits.

It's not mentioned in koji --help nor is there a man-page for koji.

Ralf



--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: bodhi2: ACL validation mechanism was unable to determine ACLs

2015-08-28 Thread Ralf Corsepius

On 08/28/2015 01:00 PM, Rex Dieter wrote:

Ralf Corsepius wrote:


Hi,

This morning, bodhi2 doesn't allow me to submit an update. After a
seemingly successful login-in, when trying to submit an update, a popup
pops up telling me:

ACL validation mechanism was unable to determine ACLs


Known issue, I hit it yesterday and filed a bug.

bodhi upstream has been fixed, not sure when the fix will be rolled out into
production.


Does this mean my hung job locks up submissions issue is unrelated or 
doesn't exist at all?


Ralf

--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Undefined %epoch problem (Re: rawhide report: 20150730 changes)

2015-08-28 Thread Ralf Corsepius

On 08/28/2015 01:15 PM, Michael Schwendt wrote:

The version tags ver and rel attributes may also be non-numerical.
Why not epoch, too?


I haven't looked into the sources, but IIRC, inside of rpm, while rel, 
ver etc. are strings, epoch is an integer.


AFAIR, there are APIs which return the epoch as a *int, which may be 
NULL or a valid pointer. I.e. callers will have to special case 
accessing these pointers.


Seems to me as if something doesn't get this right.
(FWIW: All this was an FAQ  10 years ago :) )

Ralf


--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: bodhi2: ACL validation mechanism was unable to determine ACLs

2015-08-28 Thread Ralf Corsepius

On 08/28/2015 12:56 PM, Kalev Lember wrote:

On 08/28/2015 12:45 PM, Ralf Corsepius wrote:

On 08/28/2015 11:58 AM, Kevin Kofler wrote:

Ralf Corsepius wrote:

Also, I have not found any means to kill this job in bodhi/koji,


Had you tried koji cancel-task 10843003? (It's too late to try it
now, now
that the build has timed out.)


No, I wasn't aware this option exits.

It's not mentioned in koji --help nor is there a man-page for koji.


It is mentioned in koji enter.


That's what I'd call room for improvement.

Ralf


--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Undefined %epoch problem (Re: rawhide report: 20150730 changes)

2015-08-28 Thread Ralf Corsepius

On 08/28/2015 02:18 PM, Michael Schwendt wrote:

On Fri, 28 Aug 2015 13:59:12 +0200, Ralf Corsepius wrote:


The version tags ver and rel attributes may also be non-numerical.
Why not epoch, too?


I haven't looked into the sources, but IIRC, inside of rpm, while rel,
ver etc. are strings, epoch is an integer.


See:

   https://lists.fedoraproject.org/pipermail/devel/2015-August/213209.html
   https://lists.fedoraproject.org/pipermail/devel/2015-August/213208.html


Bugs ... an undefined epoch is supposed to be treated as 0.

I guess you also recall - the ability of some tools not to be able to 
cope with this was the origin why Fedora.us and early Fedoras once 
mandated Epoch: 0.



Plus, RPM would not get to see repository metadata, but only downloaded
packages, which contain the same bad Epoch values.


Ralf

--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Undefined %epoch problem (Re: rawhide report: 20150730 changes)

2015-08-28 Thread Ralf Corsepius

On 08/28/2015 05:32 PM, Michael Schwendt wrote:

On Fri, 28 Aug 2015 16:36:51 +0200, Ralf Corsepius wrote:


See:

https://lists.fedoraproject.org/pipermail/devel/2015-August/213209.html
https://lists.fedoraproject.org/pipermail/devel/2015-August/213208.html


Bugs ... an undefined epoch is supposed to be treated as 0.


No, that's the old case. No Epoch = Epoch 0.


Both cases are equal on the rpm level.

All tools which use rpm need to set their internal representation of an 
epoch to 0 if rpm returns an undefined epoch.


Ralf

--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: bodhi2: ACL validation mechanism was unable to determine ACLs

2015-08-27 Thread Ralf Corsepius

On 08/27/2015 07:55 AM, Ralf Corsepius wrote:

Hi,

This morning, bodhi2 doesn't allow me to submit an update. After a
seemingly successful login-in, when trying to submit an update, a popup
pops up telling me:

ACL validation mechanism was unable to determine ACLs


This whole incident is bizarre. What I assume to have happened is:
- A fc22 build job hung for unknown reasons [1].

This seems to have locked out package update submissions of this package 
for other fedora releases in bodhi. E.g.. bodhi rejected all attempts to 
submit an fc23 built.


Also, I have not found any means to kill this job in bodhi/koji,


- 24 hours later, the hung build job was automatically terminated/killed[2].

This seems to have unlocked package update submissions in bodhi.
I finally was able to rebuild the fc22 package in koji and subsequently 
was able to submit the package's updates for other fedora-releases.


Ralf

[1] This package's test suite is suspected to suffer from dead-lock 
issues on highly parallel systems. I have never been able to locally 
reproduce these issues. Upstream so far ignored allproposals, which were 
claiming to fix this issue, probably because upstream also can't 
reproduce the problems.


[2] https://koji.fedoraproject.org/koji/taskinfo?taskID=10843003
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: bodhi2: ACL validation mechanism was unable to determine ACLs

2015-08-27 Thread Ralf Corsepius

On 08/27/2015 11:15 AM, Christopher Meng wrote:



On Thursday, August 27, 2015, Ralf Corsepius rc040...@freenet.de
mailto:rc040...@freenet.de wrote:

Hi,

This morning, bodhi2 doesn't allow me to submit an update. After a
seemingly successful login-in, when trying to submit an update, a
popup pops up telling me:

ACL validation mechanism was unable to determine ACLs


I met this as well when I edited updates. Then I manually typed the
build in the field and pressed enter instead of selecting them with
checkbox pulled after entering the package name.
I don't think this applies here. I've tried several ways to submit the 
package, but no success so far. Also, meanwhile I've successfully 
requested a update for a different package, i.e. it's not a general 
issue with my account.


I'd guess on a bodhi-koji interaction/sync issues (fc23), because 
another build of this package for a different fedora release (fc22) 
seems to be stuck in koji and doesn't want to finish for more than 12 hours.


May-be, it'll once will time out or may-be I can find a way to kill it.

We'll see if this changes something.

Ralf


--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

bodhi2: ACL validation mechanism was unable to determine ACLs

2015-08-26 Thread Ralf Corsepius

Hi,

This morning, bodhi2 doesn't allow me to submit an update. After a 
seemingly successful login-in, when trying to submit an update, a popup 
pops up telling me:


ACL validation mechanism was unable to determine ACLs


Ralf

--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Unable to submit update for F22 (was Re: bodhi 2 now live)

2015-08-22 Thread Ralf Corsepius

On 08/21/2015 06:02 PM, Kevin Fenzi wrote:

On Fri, 21 Aug 2015 05:27:37 +0200
Ralf Corsepius rc040...@freenet.de wrote:


Upstreams, yes, but not Fedora. Fedora should be self-hosted.


Can you please define Fedora and self-hosted as you use them above?


A domain 100 operated and owned by Fedora (rsp. RH) and covered by the 
Fedora CLA. Whether github is popular does not matter all. It's third 
party out of Fedora's control.


What you are doing, means pushing Fedora users around, in what I 
consider very rude ways.



Fedora is part of the larger open source comunity.
Fedora Infrastructure uses 100% open source software.

All irrelevant.

Bohdi is just a tool used by Fedora, like any other arbitrary tool.

I.e. I am not interested in getting involved in bodhi, I am just using 
the bodhi instance Fedora has deployed and I am expecting to have a way 
to contact the Fedora personnel to report bugs.




Anyhow, for the last time:

github is currently the perferred way to report bodhi2 bugs.


And for illiterate: github a legitimate way for upstream, but is not a 
way, which is acceptable to Fedora users.
You guys, need to learn to distinguish your roles as upstream and as 
maintainers of an installation - These are *not* identical.



If you have some objection to them, you can file a fedorahosted ticket
or infrastructure fedorahosted ticket. Also, I have been trying to file
tickets on issues I see in mailing lists that aren't filed.


I am close to filing a ticket to FESCO and/or the Board/Council, to 
request to revert to bodhi one - bodhi2 has proven to suffer from very 
ugly bugs and to be close to being unusable.



Ralf


--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: bodhi 2 now live

2015-08-21 Thread Ralf Corsepius

On 08/20/2015 07:40 PM, Stephen John Smoogen wrote:

On 19 August 2015 at 22:24, Ralf Corsepius rc040...@freenet.de wrote:

On 08/20/2015 06:08 AM, Christopher Meng wrote:


On 8/20/15, Kevin Fenzi ke...@scrye.com wrote:


Thanks for your patience as we roll out this new bodhi version.



This update has reached 3 days in testing and can be pushed to stable
now if the maintainer wishes

This update has reached 14 days in testing and can be pushed to
stable now if the maintainer wishes

uh, can someone tell me where to push the updates?



I am having the same issue. I am unable to find a way to push packages in
the GUI.


Also, there seem to be pretty nasty connectivity/accessibility issues.
Accessibility to bodhi has never been overwhelming, but they now seem to
have worsend. I am experiencing page loading times are in the order of
several minutes and occasional time outs.



FYI: I just submitted a new update trough bodhi. Wrist-watch measured, 
this update took 2 minutes+ GUI-turn-around time (Probably 2:30 min).


Ralf

--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: bodhi 2 now live

2015-08-21 Thread Ralf Corsepius

On 08/21/2015 04:03 PM, Michael Schwendt wrote:

On Fri, 21 Aug 2015 09:00:29 +0200, Ralf Corsepius wrote:


On 08/21/2015 08:34 AM, Till Hofmann wrote:

Also, it seems like I can revoke other people's updates. At least I
could press the 'Revoke' button and I received a confirmation
notification. Also, instead of the Revoke button, there is now a Push
to Testing and a Push to Stable button. But there is no comment that
the update has been revoked, so I'm not sure if it was revoked or not.


The start page confirms that I revoked the torch-3.1-12.fc23 update:
https://thofmann.fedorapeople.org/Screenshot%20from%202015-08-21%2008-42-52.png

Ralf, sorry for messing with your update.


Interesting - May be it's still in the process queue somewhere, but so
far, I haven't been notified about this, neither in BZ nor per email.
If you hadn't mentioned it, I'd not know about this incident.


Fedora Notifications web site finds a notification about it:

   7 hours ago thofmann revoked torch-3.1-12.fc23

Yes. This was the incident Till was referring to.


Though, given that you are not the owner of the package,  I guess
this has not been forwarded to you.
Correct - I acted as provenpackager, who stepped in to keep alive a 
package, whose maintainer likely is AWOL[1].



It would be bodhi's responsibility
to submit a notification that refers to the update ticket owner, too.
Exactly. IMO, this is a bug in bodhi. I would expect the update 
submitter and the bugzilla-ticket owner, an update is referring to be 
notified (In this case: both me).



And perhaps you're also affected by issues with the default Fedora
Notifications filters I've encountered. This thread:
https://lists.fedoraproject.org/pipermail/devel/2015-August/213609.html


I don't know - Possible. Due to the mass of notifications, I am 
receiving (100s - 1000s per day), I am filtering notifications and am 
moving most notifications to trash unread ;)


Ralf

[1] https://bugzilla.redhat.com/show_bug.cgi?id=1240072
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Unable to submit update for F22 (was Re: bodhi 2 now live)

2015-08-21 Thread Ralf Corsepius

On 08/20/2015 07:39 PM, Adam Williamson wrote:


Well, I don't know if there was a Big Philosophical Discussion, but in
practice all kinds of Fedora-ish stuff has its upstream in github these
days, so yes, clearly times have changed.


That's not the point. I am talking about separating Fedora 
web-infrastructure from the web-infrastructure's upstreams.


In this case, I am talking about Fedora's infrastructure 
deployment/installation (A Fedora product - Responsible: Fedora) of 
bodhi to demand reporting bugs on Fedora's infrastructure to upstream (A 
bodhi-project product - Responsible: Upstream).


In other words: Nobody with a sane mind would ask users of web shop's 
installation to file bugs at Oracle/MySQL etc - This is what is 
happening here.


It's a classical case where people with multiple roles are unable to 
distinguish their roles.


Ralf



--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: bodhi 2 now live

2015-08-21 Thread Ralf Corsepius

On 08/21/2015 08:47 AM, Till Hofmann wrote:



On 08/21/2015 08:34 AM, Till Hofmann wrote:

Also, it seems like I can revoke other people's updates. At least I
could press the 'Revoke' button and I received a confirmation
notification. Also, instead of the Revoke button, there is now a Push
to Testing and a Push to Stable button. But there is no comment that
the update has been revoked, so I'm not sure if it was revoked or not.


The start page confirms that I revoked the torch-3.1-12.fc23 update:
https://thofmann.fedorapeople.org/Screenshot%20from%202015-08-21%2008-42-52.png

Ralf, sorry for messing with your update.


Interesting - May be it's still in the process queue somewhere, but so 
far, I haven't been notified about this, neither in BZ nor per email.

If you hadn't mentioned it, I'd not know about this incident.

Anywas, this time bodhi offered me a push to testing and push to 
stable (!) button (Note: push to stable)


I used pushed to testing to re-push it.


BTW (I mentioned it before), Timestamps are still screwed up:
...
Submitted   31 minutes ago, 2015-08-21 06:22:21.364583
Automated Test Results
rpmlint torch-3.1-12.fc23   3 hours ago
...


Ralf

--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Unable to submit update for F22 (was Re: bodhi 2 now live)

2015-08-20 Thread Ralf Corsepius

On 08/20/2015 06:00 PM, Kevin Fenzi wrote:

On Thu, 20 Aug 2015 17:55:01 +0200
Kevin Kofler kevin.kof...@chello.at wrote:


Ralf Corsepius wrote:

I share this view. I refuse to create a github account and do not
consider using any external account resources for Fedora to be
acceptable.


While I do have a GitHub account (no way for me to eschew it, sadly),
I also do not understand why (and am sad that) Bodhi development
moved off Fedora Hosted, where there is an issue tracker that works
with Fedora accounts, and where we are not reliant on third-party
proprietary software as a service.


The fedorahosted instance is still there, you can use it if you like.

Likely it will be migrated to pagure.io before too long, we just didn't
have time to do so before this deployment.


To me any non fedora/redhat supplied account system is inacceptable,

This applies to github, sourceforge, farcebook, nitter, goggle, or else 
- period.


Ralf



--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Unable to submit update for F22 (was Re: bodhi 2 now live)

2015-08-20 Thread Ralf Corsepius

On 08/20/2015 09:51 AM, Milan Crha wrote:

On Wed, 2015-08-19 at 21:45 -0600, Kevin Fenzi wrote:

There will likely be oddities and bugs. Please file them in github so
we can prioritize them and get them fixed up.

https://github.com/fedora-infra/bodhi/issues


Hi,
I do not have a github account, and I'm currently not going to create
any (github is not my favorite site), thus I'm writing here instead
(after all, Fedora infrastructure issue = Fedora bugzilla, no?).
I share this view. I refuse to create a github account and do not 
consider using any external account resources for Fedora to be acceptable.



I tried to submit an update for Fedora 22 and it just tells me that it
wasn't able to submit it with absolutely no reason. My values are:


And this as well. I just tried to create an update for F23 and was just 
told unable to create update.


So be it, ... give me a ping when you think bodhi is ready for public 
usage. ATM it definitely is not.


Ralf


--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Sponsors - who does (not) work on FE-NEEDSPONSOR tickets

2015-08-20 Thread Ralf Corsepius

On 08/18/2015 12:04 PM, Miroslav Suchý wrote:

BTW this report reveals that we have just 39 active sponsors (during past year).

If you are sponsors, please consider sponsoring somebody from the queue:
   http://fedoraproject.org/PackageReviewStatus/NEEDSPONSOR.html


You should understand that sponsoring someone in reality is a tedious 
and challenging task. Why?


1. You need to find a package submission your feel sufficiently 
motivated to review.


The packages, I am interested already in are in Fedora, which means I am 
having difficulties to find any more



2. You need to find a package you technically feel qualified to get 
involved to.


Most recent submissions were out of my technical domains.


3. You need to find a non occupied package.
Provided we have sponsors; whom I perceive as keen on collecting 
badges, this has become an ugly rat-race.



4. Reviews take time, esp. on those with NEEDSPONSORS.
In recent times, I perceived a lot of low quality submissions, I am not 
interested in wasting my time on, any more.



5. You cannot push around sponsors.
The ability to sponsor packagers is a privilege and not a duty. It's not 
going to fly to make a volunteer privilege a burdon.



That said, I considering your ongoing campaign to be harmful to Fedora.

All you are going to achieve is to collect more hyperactive kids and 
to drive away more of the old and experienced hares.


Ralf



--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Unable to submit update for F22 (was Re: bodhi 2 now live)

2015-08-20 Thread Ralf Corsepius

On 08/20/2015 07:51 PM, Kevin Fenzi wrote:

On Thu, 20 Aug 2015 12:33:37 -0500
Michael Cronenworth m...@cchtml.com wrote:


On 08/20/2015 12:02 PM, Ralf Corsepius wrote:


To me any non fedora/redhat supplied account system is inacceptable,

This applies to github, sourceforge, farcebook, nitter, goggle, or
else - period.


The last time a non-Fedora hosted / closed source service was
suggested it was shot down.

https://lists.fedoraproject.org/pipermail/devel/2013-October/191012.html

Have times changed? Using github is acceptable?


For what? :)

IMHO, I think projects should be free to choose whatever tools they
wish to build their project.


Upstreams, yes, but not Fedora. Fedora should be self-hosted.

That said, Fedora should not start being rude and push people around to 
get accounts on other commercial entities and to expose themselves to 
the risks implied by this.


Ralf

--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Unable to submit update for F22 (was Re: bodhi 2 now live)

2015-08-20 Thread Ralf Corsepius

On 08/20/2015 12:00 PM, Paul Howarth wrote:

On 20/08/15 10:28, Ralf Corsepius wrote:

On 08/20/2015 09:51 AM, Milan Crha wrote:

On Wed, 2015-08-19 at 21:45 -0600, Kevin Fenzi wrote:

There will likely be oddities and bugs. Please file them in github so
we can prioritize them and get them fixed up.

https://github.com/fedora-infra/bodhi/issues


Hi,
I do not have a github account, and I'm currently not going to create
any (github is not my favorite site), thus I'm writing here instead
(after all, Fedora infrastructure issue = Fedora bugzilla, no?).

I share this view. I refuse to create a github account and do not
consider using any external account resources for Fedora to be
acceptable.


I tried to submit an update for Fedora 22 and it just tells me that it
wasn't able to submit it with absolutely no reason. My values are:


And this as well. I just tried to create an update for F23 and was just
told unable to create update.

So be it, ... give me a ping when you think bodhi is ready for public
usage. ATM it definitely is not.


I had the same issue trying to create an update for F23. I was able to
manage it eventually by using fedpkg update, once I'd updated
python-fedora from F21 updates-testing.

However, I later needed to edit that update to change the build, and the
result is an update with no builds that I can't even access any more.

https://github.com/fedora-infra/bodhi/issues/202

Looks like you need to hit enter after typing/pasting in the package
NVR into the Candidate Builds field, which was not at all obvious to me.

Aha ;()

I just somehow managed to push an update - No idea how.

While filling out the update form for a second time (The first try had 
failed with the error above), out of a sudden a large number of popups 
with checkboxes inside popped up.


After checking some of them, the update was reported to have been 
pushed, except that the BZ, I had added manually seems to have been 
ignored - Seems to me, as is this popup is not offering BZ's which have 
been closed rawhide but require further action for fc23.


BTW: Something with time stamps of the rpmlint/taskotron checks seem to 
be wrong, as well. I my case rpmlint reported to have checked the 
package hours ago, while I had commited the package into git ca. 1/2 
hour ago and submitted it minutes ago.


Ralf

--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Rawhide plans

2015-08-20 Thread Ralf Corsepius

On 08/20/2015 03:13 PM, Eric Griffith wrote:

If you have a bad experience that experience stays
with you. Maybe you can get over it, maybe you can't. But a name does
have history.


I guess, you guys are not aware that other names related to 
RH/CentOS/Fedora also have ambivalent and polarizing connotations?


Actually, I believe rawhide is the least one to worry about, because 
it doesn't have any connotation to many people, because most users don't 
even know what rawhide is.


Openly said, I wonder where this fuzz about rawhide originates from and 
which insect might have bitten the folks making this fuzz? IMHO, Fedora 
has many more serious and urgent problems than to the name rawhide.


Ralf


--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Rawhide plans

2015-08-20 Thread Ralf Corsepius

On 08/20/2015 03:42 PM, Zach Villers wrote:

Le Mer 19 août 2015 18:22, Rex Dieter a écrit :
  Kevin Fenzi wrote:
 
  * Matt opened a thread on the marketing list about renaming rawhide. It
  sounds like most people would prefer us to make the changes first,
  then and only then look at renaming.
 
  s/renaming/rebranding/
 
  I personally would prefer the name be preserved if at all possible,
but if
  the marketing gurus feel otherwise, so be it.

/I doubt anyone will be fooled by a name change, what matters is the actual
state of the repository not naming tricks.
No. rawhide is the package pool, dumping ground or what ever wording you 
prefer, distros are derived from.


There is no point in considering a release nor a rolling release. It 
simply isn't a release, it's just a truck load of packages.


Ralf



--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: bodhi 2 now live

2015-08-20 Thread Ralf Corsepius

On 08/20/2015 06:24 AM, Ralf Corsepius wrote:

On 08/20/2015 06:08 AM, Christopher Meng wrote:

On 8/20/15, Kevin Fenzi ke...@scrye.com wrote:

Thanks for your patience as we roll out this new bodhi version.


This update has reached 3 days in testing and can be pushed to stable
now if the maintainer wishes

This update has reached 14 days in testing and can be pushed to
stable now if the maintainer wishes

uh, can someone tell me where to push the updates?


I am having the same issue. I am unable to find a way to push packages
in the GUI.


AFAIS, this morning, the situation seems to have improved.

Unlike yesterday, I am now seeing green push to stable buttons for 
packages which have been in testing for longer times (weeks, months).


However, I am not seeing these buttons for packages, which I had 
submitted in recent past and which received a This update ... if the 
maintainer wishes notification, dated ~2-3 days ago.


E.g.:
https://bodhi.fedoraproject.org/updates/libcmpiutil-0.5.7-6.fc23
https://bodhi.fedoraproject.org/updates/spacechart-0.9.5-17.fc23

Could it be the old bodhi was using a 3 days delay time for fc23, 
while the new bodhi uses 7 days?
Could it be that the corresponding bodhi internals have been lost during 
the transition?


Ralf

--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Rawhide plans

2015-08-20 Thread Ralf Corsepius

On 08/20/2015 09:23 AM, Reindl Harald wrote:


Am 20.08.2015 um 06:01 schrieb Ralf Corsepius:

On 08/20/2015 01:07 AM, Eric Griffith wrote:

Personally, if it weren't for the confusion, I think Fedora Next would
be the perfect name for this.


May-be, you guys are too young to know, but to me Fedora Next, would be
a Fedora distribution addressing Steve Job/Apple's NeXt and advertising
for Apple.

That said, I would not be surprised, if Fedora Next would be subject
to trademark conflicts and disputes.


the word next in the context what Rawhide is?
seriously?


Well, I am just trying to raise awareness on a potential problem.

A brief and quick of the DPMA's (Deutsches Patent und Markenamt - German 
Patent and Trademark Authority) on-line database tells NeXT is still a 
registered trademark, registered for Nice Class 9, by NeXT Computer, 
Inc., Redwood City Calif., US [1]


In other words, there is a potential problem lurking, IMHO.

Ralf

[1]
https://register.dpma.de/DPMAregister/marke/register/2026842/DE
https://register.dpma.de/DPMAregister/marke/register/2063015/DE
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: bodhi 2 now live

2015-08-20 Thread Ralf Corsepius

On 08/20/2015 06:05 PM, Tomasz Torcz wrote:

On Thu, Aug 20, 2015 at 10:02:44AM -0600, Kevin Fenzi wrote:


Are things like redhat bugzilla, koji and fedocal also slow?


   Bugzilla is always slow, it's not a good reference ;-)


Definitely. But bodhi2 seemed worse :-)

What might have interfered this morning, was my ISP. It was reported to 
have major networking issues, affecting several million customers, but 
... I didn't notice any and did not have any networking problems but to 
fedoraproject.org ;)


Ralf

--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Rawhide plans

2015-08-19 Thread Ralf Corsepius

On 08/20/2015 01:07 AM, Eric Griffith wrote:

Personally, if it weren't for the confusion, I think Fedora Next would
be the perfect name for this.


May-be, you guys are too young to know, but to me Fedora Next, would be 
a Fedora distribution addressing Steve Job/Apple's NeXt and advertising 
for Apple.


That said, I would not be surprised, if Fedora Next would be subject 
to trademark conflicts and disputes.


Ralf


--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: bodhi 2 now live

2015-08-19 Thread Ralf Corsepius

On 08/20/2015 06:08 AM, Christopher Meng wrote:

On 8/20/15, Kevin Fenzi ke...@scrye.com wrote:

Thanks for your patience as we roll out this new bodhi version.


This update has reached 3 days in testing and can be pushed to stable
now if the maintainer wishes

This update has reached 14 days in testing and can be pushed to
stable now if the maintainer wishes

uh, can someone tell me where to push the updates?


I am having the same issue. I am unable to find a way to push packages 
in the GUI.



Also, there seem to be pretty nasty connectivity/accessibility issues. 
Accessibility to bodhi has never been overwhelming, but they now seem 
to have worsend. I am experiencing page loading times are in the order 
of several minutes and occasional time outs.


Ralf

--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Rawhide plans

2015-08-19 Thread Ralf Corsepius

On 08/19/2015 06:59 PM, Zach Villers wrote:


 On Wed, 19 Aug 2015 11:18:04 -0400 *Kevin Fenzi ke...@scrye.com*
wrote 

Greetings.

We had some nice discussions about rawhide in my friday workshop at
flock. I thought I would post here to get input from folks not there,
and also allow people who were there to comment more now that it's not
after 5pm on a friday of the 3rd day of flock. ;)

snip

Finally there was mention of the baggage associated with the name
rawhide. To this day I see people telling others that rawhide will
eat your babies or rawhide is a methlab and will blow up in your face
every day.


As a relative newcomer (using Fedora since ~F20) the name rawhide does
seem to have some implied broken-ness, if that's a word. I would be in
favor of a name change/rebrand that makes it a little more approachable.


I do not see any sense in changing the name.

rawhide is a well established, well-known name, almost a 
trademark-like, for RH/CentOS/Fedora's unstable package set/repository.


Admitted, the name rawhide has some negative connotation, because of 
the permanent brokenness of its contents, but that's in the nature this 
repository. Changing the name won't change anything about this.


That said, renaming rawhide, to me, doesn't serve anything useful 
purpose. It only causes confusion and - on the technical side - causes 
(avoidable) churn.


Ralf


--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Validity of i686 as a release blocker

2015-08-14 Thread Ralf Corsepius

On 08/14/2015 12:00 PM, Richard Z wrote:


I regularly use i686 and have not done a fresh install since years so
would not detect this. Maybe fresh installs aren't such a deal for i686
users
Well, from my experience, fresh installs on i686 are a major problem w/ 
Fedora, because Fedora's SW demands have grown, which render it quite 
likely for i686-users to hit the HW-limitations of their systems, esp. 
on older i686ers.



and the apparent stability is the reason why it gets less testing.

Agreed.


The hardware is not changing so if fresh bugs appear there is a good
chance that something else than just i686 is broken?
Definitely. 10/15 years+ ago, devs were working on 32bit platforms, 
which had caused packages to have problems on 64bit platforms. Since 
then, the situation has turned into the converse.


Also, in those days, devs cared about efficiency. Nowadays, they don't 
care as much, which causes additional problems on i686ers and other low 
end archs.


Ralf

--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Validity of i686 as a release blocker

2015-08-05 Thread Ralf Corsepius

On 08/04/2015 05:12 PM, Bill Nottingham wrote:

Paul W. Frields (sticks...@gmail.com) said:




Here's my perspective as an i686 Fedora user...

I have a box (2009-ish) that's in use as a file/backup server.

I have 3 i686 boxen.

2 are 2009-ish atom-netbook, one is a 2000-ish PIII-desktop.


As such, I don't
spend a lot of time futzing with it - it doesn't run rawhide, it rarely runs
the prereleases until beta or later time.  If something breaks, I'll look at
it, send some feedback, update it as necessary, and back off to a working
version.  And historically, it *hasn't* broken.

But, if it did break that hard... would I spend a month digging into the
kernel source and bisecting to try and find a fix? Or would I spend the
$100-120 to slap a new motherboard in it and install the x86_64 version?

I'd like to say I'd do the former. But realisitically it's the latter. And I
wonder how much of the i686 Fedora-using community is in the same boat.


ACK. I would switch the 2009-atoms to Windows (They are dual boot with 
Win) and the PIII to a different Linux distro.


Ralf




--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: [PATCH] Update to 2.0.2

2015-08-03 Thread Ralf Corsepius

On 08/03/2015 04:37 PM, Kevin Fenzi wrote:

On Mon, 3 Aug 2015 01:13:52 +0200



I think posting patches or other issues here is fine as long as theres
some reason to involve the larger development community.


... like in this case.

Broken upgrade paths and disinterest in fixing them have a long history. 
They therefore need a wider audience.


Ralf



--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Question about profile.d scripts definition in Spec file

2015-08-02 Thread Ralf Corsepius

On 08/02/2015 08:39 AM, Marcin Haba wrote:

Hello,

I am trying to make informal review following feature request:

https://bugzilla.redhat.com/show_bug.cgi?id=1244353

One from warnings returned by rpmlint is:

ossim-data.x86_64: W: non-conffile-in-etc /etc/profile.d/ossim.sh

Because ossim.sh is not configuration file but shell script (as usual in
profile.d/) I had a doubt about treating this warning.


Well, I sense a misinterpretation of %config.

In the context of the /etc file hierarchy %config means 
user-customizable, which means rpm/yum/dnf updates must not destroy 
any changes a user may have applied and should backup instead.



So I asked on fedora-review IRC channel and there I received answer that
this warning is acceptable.

Well, it's a minor issue, but it definitely is arguable.


In the bugzilla task I received answer that for the ossim.sh file should
be used %config macro.

My question is: what is valid answer for this case?


My recommendation is to use %config.

Ralf

--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: How to make .spec Requires for libXXX.so.VER

2015-08-02 Thread Ralf Corsepius

On 08/01/2015 09:25 PM, Jan Kratochvil wrote:

Hi,

https://bugzilla.redhat.com/show_bug.cgi?id=1249325

GDB requires some library libXXX.so.3 by dlopen().  Therefore it is not found
by rpm automatic requires/provides from DT_NEEDED.  Therefore one has to add
the libXXX.so.3 by specific BuildRequires and Requires to the .spec file.

libXXX is librpm here but that is just a coincidence, it could be libz for
example.

(1) How to make a dependency on librpm.so.7?

librpm.so.7 is in rpm-libs-4.12.90-3.fc24.x86_64 which --provides:
librpm.so.7()(64bit)
librpmio.so.7()(64bit)
rpm-libs = 4.12.90-3.fc24
rpm-libs(x86-64) = 4.12.90-3.fc24
So there is no easy way to Requires: rpm-libs = NVRA


How about:

R: rpm-libs%{?_isa} = NVRA



(2) The other possibility does work:

BuildRequires: %{_libdir}/librpm.so.7


I guess you mean Requires: and not BuildRequires: ?

That's what I have been using on similar occasions.

Actually it's the only way I've found to handle situations, where 
packages dlopen libs from non-standard (often hard-coded) paths[1]:


R: %{_libdir}/somewhere/lib.so.y


Ralf

[1] IMO, dlopen'ing libs from standard paths is a very questionable 
design, IMO, because it doesn't provide many advantages over ordinary 
shared linkage.


--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: How to make .spec Requires for libXXX.so.VER

2015-08-02 Thread Ralf Corsepius

On 08/02/2015 09:33 AM, Jan Kratochvil wrote:


It was reworked from ordinary DT_NEEDED to this dlopen() approach because
librpm.so is (was) the only incompatible shared library dependency between
various versions of RHELs/CentOSes and Fedoras.  So with dlopen()ed librpm one
can take latest Fedora Rawhide rpm build and run the GDB binary in
RHEL/CentOS.  This makes sense for non-x86* archs where a rebuild of new GDB
from sources would take too much time.


I still don't get it. If librpm's SONAME changes between Fedora 
releases, these libs will be call incompatible, no matter if they will 
be dlopen'ed or linked directly.


Ralf


--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Help needed: F23 32-bit kernel issue

2015-07-30 Thread Ralf Corsepius

On 07/29/2015 11:12 PM, Josh Boyer wrote:

On Wed, Jul 29, 2015 at 4:55 PM, Richard W.M. Jones rjo...@redhat.com wrote:

On Wed, Jul 29, 2015 at 10:36:07AM -0400, Josh Boyer wrote:

Secondly, it would be excellent if someone could commit to spinning
test ISOs when requested.  Turn around time on bugs like this are
quite lengthy given that they often require building a new kernel
package, and then spinning a custom ISO with that package included.
Ideally the ISO content would not change from spin to spin other than
the kernel, to eliminate variables.


Could qemu-sanity-check[1] help here?  It's designed so that you can
test if a kernel boots on qemu, in a very simple manner (it was
actually designed to be run from kernel.spec so we'd never build and
ship a non-working kernel again).


No, because the environment on the boot.iso/DVD image is what is
triggering the bug.  You need a full compose with the kernel.

I already mentioned we autotest the kernel in VMs and it doesn't hit
this bug.  Running it there (or even moreso from kernel.spec) cannot
possibly cover all scenarios, so claiming it would prevent shipping a
non-working kernel again is inaccurate given that setup didn't catch
this.  More testing always helps, but nothing will provide the claim
you make.


FWIW: I locally rebuilt 4.2.0-0.rc4.git2.1 for fc22 and gave the 
resulting kernel-4.2.0-0.rc4.git2.1.fc22.i686+PAE*rpm a real-world try 
on my fc22 netbook (w/ Atom N270).


AFAICT, so far, it seems to boot (and work) without any apparent 
immediate issues. So, my wild guess would be on an iso/boot-image 
composition or tooling issue.


Ralf


--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Updates push status - 20150725

2015-07-28 Thread Ralf Corsepius

On 07/28/2015 07:57 AM, Alexander Ploumistos wrote:

Has the issue been resolved? I have pushed three new packages to f22
and f21 updates-testing, but they have yet to appear in my usual local
mirrors.


I guess no.

I am waiting for my updates to get for weeks and am already withholding 
other followup updates.


Folks, please think about the implications this kind of unreliability 
has on Fedora.


Ralf

--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: About making noarch package arch specific, when contents differ.

2015-07-28 Thread Ralf Corsepius

On 07/28/2015 10:58 AM, Florian Weimer wrote:

On 07/26/2015 04:05 PM, Paulo César Pereira de Andrade wrote:


Should I make the doc packages arch specific?


No, this is not a reason to make them arch-specific.  A lot of packages
give different results when built twice in a row, on the *same*
architecture.

There is an effort under way to change that, called “reproducible
builds”.


Actually, reproducable builds wrt. docs have been subject to Fedora 
Packaging since Fedora day #1 and repeatedly have been subject to 
discussions of details (e.g. doxygen repeatedly had introduced docs 
breakages)


Packages which do not comply to this rule are broken.

Ralf


--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: About making noarch package arch specific, when contents differ.

2015-07-27 Thread Ralf Corsepius

On 07/28/2015 03:34 AM, Dan Callaghan wrote:

Excerpts from paulo.cesar.pereira.de.andrade's message of 2015-07-27 00:05 
+10:00:

Should I make the doc packages arch specific?


Rather than trying to make Sphinx spit out bitwise-identical output on
every arch (which sounds like fighting a losing battle), could you just
build the doc subpackage on only one arch?


This is a blatant hack.

Packages builds must be reproducable on any supported architecture.

Ralf


--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Proposal: Drop comps

2015-07-15 Thread Ralf Corsepius

On 07/15/2015 10:20 AM, Vít Ondruch wrote:


Description and Summary can be localized in .spec file [1], where
supposedly names in comps terminology refers to summary in .spec
terminology. Including translations is encouraged in guidelines as well
[2, 3], unfortunately without any further details :/


I don't think localized summaries and descriptions are applicable in 
distributions like Fedora, where packages are maintained by individuals.


IMO, making localized summaries/descrs. helpful would require a 
multilingal team of translators/packagers, whose sole task it would have 
to be to add translations for a predefined set of languages to maintain 
them.


That said, I don't consider random packagers adding random translations 
to packages to be useful and to cause more problems than they solve.


Ralf

--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Improving our processes for new contributors.

2015-07-15 Thread Ralf Corsepius

On 07/15/2015 07:03 PM, Przemek Klosowski wrote:

On 07/15/2015 12:05 PM, Michael Schwendt wrote:

On Wed, 15 Jul 2015 11:05:40 -0400, Przemek Klosowski wrote:


I do understand where you're coming from: the Fedora workflow is quite
complicated

What exactly do you find quite complicated?
https://fedoraproject.org/wiki/Package_Review_Process

I was responding to Les' comment about the tools that one needs to use
in order to package something: RPM, VCS, i18n, lib/autotool, COPR,
Bodhi, mock, etc.  Don't get me wrong---I am not saying that there's
anything wrong with the tools, just that they seem easy to those who
already mastered them, but may be intimidating to the uninitiated.


Well, I consider knowledge about rpm, VCS, programming language to be 
elementary basic prerequistes to join as Fedora packager. Of course you 
don't need to be familiar with everything, but you should understand 
what you are doing - Assuring this is the aim of package-sponsors process.


I agree with you that the Fedora specifics koji, bodhi, Fedora's 
git, Fedora's web sites leaves much to be desired. Getting into these is 
a steep entry hurdle.


However, making new packagers familiar with this to an extend, which 
enables them to self-aid then, used to be the job of a new packager's 
*sponsor* (I prefer to call them mentors).


It seems to me as if this aspect has almost be forgotten and 
packager-sponsors become a passport rubber-stamping duty.



This is my point, actually, that it's hard for a packaging pro to
appreciate the confusion of a newbie. Some kid-glove treatment, and ELI5
tutoring/mentoring might help.


Well, I agree with you wrt tutoring/mentoring, but ... this has always 
been part of job of the sponsor - seriously, really.


Ralf


--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Bizarre koji error

2015-07-15 Thread Ralf Corsepius

Hi

I am facing a bizarre f23-koji build breakdown:
http://koji.fedoraproject.org/koji/taskinfo?taskID=10366596

The interesting part seems to be hidden in this file:
https://kojipkgs.fedoraproject.org//work/tasks/6598/10366598/checkout.log:

$ git clone -n git://pkgs.fedoraproject.org/ht 
/var/lib/mock/f23-build-3655660-501262/root/tmp/scmroot/ht

Cloning into '/var/lib/mock/f23-build-3655660-501262/root/tmp/scmroot/ht'...
fatal: read error: Connection reset by peer


Same result, when retrying:
http://koji.fedoraproject.org/koji/taskinfo?taskID=10366729

An f24-build succeeded ca. 1/2 hour ago:
http://koji.fedoraproject.org/koji/taskinfo?taskID=10366109

WTH?

Ralf
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Bizarre koji error

2015-07-15 Thread Ralf Corsepius

On 07/15/2015 04:51 PM, Pierre-Yves Chibon wrote:

On Wed, Jul 15, 2015 at 04:07:31PM +0200, Ralf Corsepius wrote:

Hi

I am facing a bizarre f23-koji build breakdown:
http://koji.fedoraproject.org/koji/taskinfo?taskID=10366596

The interesting part seems to be hidden in this file:
https://kojipkgs.fedoraproject.org//work/tasks/6598/10366598/checkout.log:

$ git clone -n git://pkgs.fedoraproject.org/ht
/var/lib/mock/f23-build-3655660-501262/root/tmp/scmroot/ht
Cloning into '/var/lib/mock/f23-build-3655660-501262/root/tmp/scmroot/ht'...
fatal: read error: Connection reset by peer


Same result, when retrying:
http://koji.fedoraproject.org/koji/taskinfo?taskID=10366729

An f24-build succeeded ca. 1/2 hour ago:
http://koji.fedoraproject.org/koji/taskinfo?taskID=10366109


We had a weird SELinux issue that I fixed this morning and that has apparently
surfaced again this afternoon.
So I re-labeled the tree again and it should be working again.


I don't know, whether this SELinux issue was the culprit ;)

All I can say, another 3rd build attempt (ca. yet another 1/2 hour 
later) succeeded: 
http://koji.fedoraproject.org/koji/taskinfo?taskID=10367098



Let us know if that's not the case

Well, ... I really don't know the cause.

Ralf

--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Improving our processes for new contributors.

2015-07-15 Thread Ralf Corsepius

On 07/15/2015 06:05 PM, Michael Schwendt wrote:

On Wed, 15 Jul 2015 11:05:40 -0400, Przemek Klosowski wrote:



Well, watching all the people that somehow manage to submit new
packages into the review queue, the process up to that point can't be
too bad, and one can safely assume they would be perfectly capable of
submitting them into Copr, too. But do they want that?

At least I do not want that, because I do not see much sense in this.


Do they want to
create a personal repository where users likely don't find the packages?
Or do they prefer inclusion of the packages in the official Fedora
package collection?

The latter.

Ralf



--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Summary/Minutes from today's FESCo Meeting (2015-07-01)

2015-07-07 Thread Ralf Corsepius

On 07/07/2015 03:54 PM, Chris Adams wrote:

Once upon a time, Michael Catanzaro mcatanz...@gnome.org said:

For Fedora 24, we've proposed trimming down Anaconda much more, since
most of Anaconda's functionality is redundant with our initial setup
tool that already handles language, keyboard, and timezone selection: h
ttps://listman.redhat.com/archives/anaconda-devel-list/2015
-June/msg7.html


Unless the installer is not going to ask any questions or give any
information, language and keyboard are needed for input/output during
install.


It also needs to ask for all kind of installation partitions, where to 
make room if disk is full, where to install the bootloader and ... 
should not blindly install a waggon load of packages, a user doesn't 
want and will have to uninstall manually ;)


Ralf


--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Discontinuing perl-Mail-GnuPG

2015-06-25 Thread Ralf Corsepius

Hi,

I indent to discontinue and remove perl-Mail-GnuPG from Fedora.

It FTBFS on rawhide, because it seem to suffer from compatibility issues 
with gnupg2 = 2.1.5 [1].


AFAIS, nothing in Fedora uses it, so this step probably won't do much harm.

Should gnupg2 in Fedora  23 be updated, perl-Mail-GnuPG will rendered 
dysfunctional there. I could add Requires: gnupg2  2.1.5 there but 
this is something I'd rather not do.


Ralf

[1] https://bugzilla.redhat.com/show_bug.cgi?id=1234738
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Discontinuing perl-Mail-GnuPG

2015-06-25 Thread Ralf Corsepius

Hi,

I indent to discontinue and remove perl-Mail-GnuPG from Fedora.

It FTBFS on rawhide, because it seem to suffer from compatibility issues 
with gnupg2 = 2.1.5 [1].


AFAIS, nothing in Fedora uses it, so this step probably won't do much harm.

Should gnupg2 in Fedora  23 be updated, perl-Mail-GnuPG will rendered 
dysfunctional there. I could add Requires: gnupg2  2.1.5 there but 
this is something I'd rather not do.


Ralf

[1] https://bugzilla.redhat.com/show_bug.cgi?id=1234738
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel

dnf Failed to synchronize cache for repo 'updates'

2015-06-19 Thread Ralf Corsepius

Hi,

seems to me, as if fedora 22 updates is down:

# dnf --refresh update
RPM Fusion for Fedora 22 - Free - Updates 
12 kB/s | 395  B 00:00
RPM Fusion for Fedora 22 - Nonfree - Updates 
   552  B/s | 395  B 00:00
RPM Fusion for Fedora 22 - Free 
   3.5 MB/s | 461 kB 00:00
Error: Failed to synchronize cache for repo 'updates' from 
'https://mirrors.fedoraproject.org/metalink?repo=updates-released-f22arch=i386': 
Cannot download repomd.xml: Cannot download repodata/repomd.xml: All 
mirrors were tried



Sorry, if this is the wrong list, but I don't know where to report this.

Ralf
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: dnf Failed to synchronize cache for repo 'updates'

2015-06-19 Thread Ralf Corsepius

On 06/19/2015 04:53 PM, Reindl Harald wrote:



Am 19.06.2015 um 16:40 schrieb Ralf Corsepius:

seems to me, as if fedora 22 updates is down:

# dnf --refresh update
RPM Fusion for Fedora 22 - Free - Updates
 12 kB/s | 395  B 00:00
RPM Fusion for Fedora 22 - Nonfree - Updates
552  B/s | 395  B 00:00
RPM Fusion for Fedora 22 - Free
3.5 MB/s | 461 kB 00:00
Error: Failed to synchronize cache for repo 'updates' from
'https://mirrors.fedoraproject.org/metalink?repo=updates-released-f22arch=i386':

Cannot download repomd.xml: Cannot download repodata/repomd.xml: All
mirrors were tried

Sorry, if this is the wrong list, but I don't know where to report this


that's likely not a DNF issue


Who knows? ;-)

Of course, you're right, it's likely a master repository, mirrormanager 
or mirroring issue, or similar.



FWIW: I am now also observing a similar issue with yum and f21/updates:

# yum update
...
Could not get metalink 
https://mirrors.fedoraproject.org/metalink?repo=fedora-21arch=i386 
error was

14: HTTPS Error 502 - Bad Gateway
updates/21/i386/metalink 
|  18 kB  00:00:29
updates 
| 4.9 kB  00:00:00
http://mirror2.hs-esslingen.de/fedora/linux/updates/21/i386/repodata/repomd.xml: 
[Errno -1] repomd.xml does not match metalink for updates

Trying other mirror.

[traversing all EU-mirror but finding one in the end]


Ralf

--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Fedora 23 mass rebuild

2015-06-17 Thread Ralf Corsepius

On 06/17/2015 04:14 PM, Sérgio Basto wrote:

The Perl 5.22 mass rebuild broke po4a


I checked in a patch which hopefully fixes po4a, earlier today.
(https://bugzilla.redhat.com/show_bug.cgi?id=1230977)

It doesn't seem to be on the rawhide mirrors yet, but it's already in 
Fedora's builders. So, I'd recommend to try rebuilding the po4a-caused 
failed builds in scratch-builds and to really rebuild them, if the 
scratch-builds work (I already noticed some po4a-failed packages have 
further issues).


Ralf



--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Can soft dependencies help to get the proper kernel-devel packages? (Was: Soft- Re: DKMS is not installing the right kernel-devel package)

2015-06-12 Thread Ralf Corsepius

On 06/12/2015 02:48 PM, Neal Gompa wrote:


​Soft/weak dependencies are allowed, according to FESCo

It doesn't matter much what FESCO says of believes in this case.

ATM, neither is the technical infrastructure is in place (it is 
evolving) nor are impact/consequences clear not are the prototypical 
use-cases of soft/weak-deps clear.


@Thorsten: I do not think, weak/soft-deps are of use in your case. 
Unfortunatley, I do not have solution, either.


Ralf

--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Can soft dependencies help to get the proper kernel-devel packages? (Was: Soft- Re: DKMS is not installing the right kernel-devel package)

2015-06-12 Thread Ralf Corsepius

On 06/12/2015 03:23 PM, Neal Gompa wrote:

On Fri, Jun 12, 2015 at 9:18 AM, Ralf Corsepius rc040...@freenet.de wrote:

On 06/12/2015 02:48 PM, Neal Gompa wrote:


Soft/weak dependencies are allowed, according to FESCo


It doesn't matter much what FESCO says of believes in this case.

ATM, neither is the technical infrastructure is in place (it is evolving)
nor are impact/consequences clear not are the prototypical use-cases of
soft/weak-deps clear.

@Thorsten: I do not think, weak/soft-deps are of use in your case.
Unfortunatley, I do not have solution, either.



What do you mean by the technical infrastructure for it is lacking?


E.g. /usr/bin/rpm still lacks the --what* command-line options 
corresponding to soft/weak deps.


This issue was mentioned the rpm maintainer in an FPC meeting (IIRC, 3 
weeks ago), when we were discussing soft/weak-deps but nothing seems to 
have happened since.


Therefore I just (I could have done so earlier, but have been on 
vacation) filed an RFE against rpm:

https://bugzilla.redhat.com/show_bug.cgi?id=1231247

Ralf



--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: f22 screensaver/lockout issue requiring reboot :/

2015-06-10 Thread Ralf Corsepius

On 06/10/2015 03:45 PM, Przemek Klosowski wrote:

On 06/10/2015 09:04 AM, Paul Wouters wrote:

Am I the only one who is constantly locked out of their X session on
fedora 22? Once the screen locks, it refuses my actual password to
unlock. Even killing X with ctrl-alt-backspace doesn't help because
it will just startup again in locked screen mode. I basically have
to reboot every time my screen locks. And yes, the screensaver
preferences even have lock screen after unselected but my screen
gets locked anyway.

I've seen a similar thing happen in a recent Ubuntu install. Try to
'select other user' and select yourself again. Does the password work then?


Not sure if this is the same issue or related to your issues, but I 
couldn't ssh into machines which were upgraded from f21 to f22.


In my case, touch /.autorelabel and rebooting to force an 
SELinux-relabel helped, which makes me believe SELinux was to blame.


Ralf




--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Rapid release for security updates

2015-05-27 Thread Ralf Corsepius

On 05/26/2015 06:22 PM, Stephen Gallagher wrote:

On Tue, 2015-05-26 at 15:33 +0200, Ralf Corsepius wrote:

On 05/26/2015 12:10 PM, Andrew Haley wrote:

  Something needs to be done, but I'm not sure
exactly what.


IMO, all this should not be a problem, if collaborative maintenance
works.

What I mean, IMO, critical packages should have a sufficient number
of
co-maintainers, who should be presumed to be sufficiently familiar
with
a package to provide enough karma, which would allow such packages to

pass quickly.




That might work for comparatively simple packages, but what about the
kernel? Kernel updates have the potential to completely break things
(particularly if the security patch comes along with a point release).

Well, admitted the kernel is a special case :-)

Therefore, I wrote co-maintainers, who should be sufficiently familiar 
with a package above, and did not write arbitrary packagers or 
arbitrary users. I am presuming knowledgeable people, who at least 
are able to estimate the impact of a set of changes in cases of urgent 
security updates.


IMO, arbitrary users' karma are mostly worthless - in general. In most 
cases, all these karma-votes are telling is update doesn't immediately 
let my system go up in flames.



I'm not trying to disparage the kernel maintainers, but there's
absolutely no way they can test all possible hardware before releasing
an update.

There's still value to the updates-testing repo, even for security
updates.


Definitely. May-be I wasn't clear enough. I do not want to circumvent 
updates-testing, but wanted to sketch a route to utilize updates-testing 
even for urgent security updates.



I agree we need to figure out ways to grease the wheels so that
important updates get out faster, though.
The aspect I was referring to is urgency. In this cases, IMO, it's 
more than appropriate to ask those people who can be assumed to be best 
knowledgeable (e.g. co-maintainers and/or a dedicated security team) 
to team up.


Of course, this all presumes critical packages (firefox, thunderbird, 
kernel, glibc, ssh/ssl etc,) and updates have a team behind and aren't 
soloist efforts.


Ralf


--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Fedora 22 Dispplay with stripes

2015-05-27 Thread Ralf Corsepius

On 05/27/2015 05:27 PM, Sergio Belkin wrote:


Video card:

Slot:   00:02.0
Class:  VGA compatible controller
Vendor: Intel Corporation
Device: 82945G/GZ Integrated Graphics Controller
SVendor:Elitegroup Computer Systems
SDevice:Device 1b76
Rev:02
Driver: i915
Module: i915



What did you use to get this list?  It's different than the lspci output.  
lspci identifies mine as:
Intel Corporation 82865G Integrated Graphics Controller (rev 02)




lspci -v -mm -k ;) Nice, isn't it?

It's a bit weird I've reenabled the composite in KDE and problem it went away...





Hi,

any news, ideas, with about this topic, driver is working terrible, I
thought that was a KDE issue, but in MATE it happens either...


Today, a similar issue happened to me with the Fedora installer, when 
installing F22 on my old netbook.


When the installation started, initially a couple of horizontal strips 
appeared, which gradually accumulated until the display was entirely 
unreadable and distorted.


Video card:
Slot:   00:02.0
Class:  VGA compatible controller
Vendor: Intel Corporation
Device: Mobile 945GSE Express Integrated Graphics Controller
SVendor:Micro-Star International Co., Ltd. [MSI]
SDevice:Device 0110
Rev:03
Driver: i915
Module: i915

Ralf

--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Rapid release for security updates

2015-05-26 Thread Ralf Corsepius

On 05/26/2015 12:10 PM, Andrew Haley wrote:

 Something needs to be done, but I'm not sure
exactly what.


IMO, all this should not be a problem, if collaborative maintenance works.

What I mean, IMO, critical packages should have a sufficient number of 
co-maintainers, who should be presumed to be sufficiently familiar with 
a package to provide enough karma, which would allow such packages to 
pass quickly.


Ralf




--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

<    1   2   3   4   5   6   7   8   9   10   >