[EPEL-devel] Re: Current state of dual repository packages.

[Simone Caronni]

On Tue, Aug 15, 2017 at 12:01 PM, Simone Caronni <negativ...@gmail.com>
wrote:
>
> If I trigger the rebuild in Koji, we will get again the same version as
> the first one.
>

What will the CentOS folks do for these rebuilds?

Regards,
--Simone



-- 
You cannot discover new oceans unless you have the courage to lose sight of
the shore (R. W. Emerson).

http://xkcd.com/229/
http://negativo17.org/
___
epel-devel mailing list -- epel-devel@lists.fedoraproject.org
To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org

[EPEL-devel] Re: Current state of dual repository packages.

[Simone Caronni]

On Tue, Aug 15, 2017 at 11:38 AM, Simone Caronni <negativ...@gmail.com>
wrote:

> On Fri, Aug 11, 2017 at 8:00 PM, Stephen John Smoogen <smo...@gmail.com>
> wrote:
>>
>> The remaining packages which are not in all architectures BUT are very
>> old (and may break other things). These need some sort of update/rebuild I
>> expect.
>>
>> libssh
>> libtomcrypt
>> libtommath
>> libvncserver
>>
>
Just a note on the %{dist} tag, it seems that it has now changed. Up until
now, the release of libvncserver was like this:

libvncserver-0.9.9-9.el7.1.src.rpm

Starting from RHEL 7.4, they changed the %{dist} tag to contain the minor
version where the package was introduced, so the SAME package, with the
SAME changelog is now:

libvncserver-0.9.9-9.el7_0.1.src.rpm

If I trigger the rebuild in Koji, we will get again the same version as the
first one.
Should I override the %{dist} tag with el7_0 in the spec file? Does not
seem very clean to me. I would rather leave the builds as they are.

Regards,
--Simone


-- 
You cannot discover new oceans unless you have the courage to lose sight of
the shore (R. W. Emerson).

http://xkcd.com/229/
http://negativo17.org/
___
epel-devel mailing list -- epel-devel@lists.fedoraproject.org
To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org

[EPEL-devel] Re: Current state of dual repository packages.

[Simone Caronni]

On Fri, Aug 11, 2017 at 8:00 PM, Stephen John Smoogen 
wrote:
>
> The remaining packages which are not in all architectures BUT are very old
> (and may break other things). These need some sort of update/rebuild I
> expect.
>
> libssh
> libtomcrypt
> libtommath
> libvncserver
>

Will check those for the subarchitectures affected.

Do we have a Pagure ticket to track these architecture specific packages?

Thanks,
--Simone

-- 
You cannot discover new oceans unless you have the courage to lose sight of
the shore (R. W. Emerson).

http://xkcd.com/229/
http://negativo17.org/
___
epel-devel mailing list -- epel-devel@lists.fedoraproject.org
To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org

Re: Mass rebuild failures only on ppc64le: glibc problem?

[Simone Caronni]

Hello,

On Thu, Jul 27, 2017 at 6:07 AM, Josh Stone  wrote:

> On 07/26/2017 06:23 PM, Josh Stone wrote:
> >> I did some other random checks and found a few other packages with
> >> ppc64le-only build failures: freeipa, gammu, gap-pkg-float, gambas3,
> >> getdp (and I stopped looking after that).  These all failed in their
> >> test suites with an error from the linker containing "expected
> >> localentry:0".


Same same. Trying to fix the latest reported CVEs on FreeRDP:

/usr/bin/cmake: error while loading shared libraries: /lib64/libcurl.so.4:
expected localentry:0 `pthread_mutex_destroy'



-- 
You cannot discover new oceans unless you have the courage to lose sight of
the shore (R. W. Emerson).

http://xkcd.com/229/
http://negativo17.org/
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: mp3 encoding now ok

[Simone Caronni]

Hello,

On Thu, May 18, 2017 at 6:24 PM, Matthew Miller 
wrote:

> On Thu, May 18, 2017 at 05:13:14PM +0100, Daniel P. Berrange wrote:
> > For clarity someone with authority presumably ought to remove "MP3
> Support"
> > from the list of Forbidden items that package reviewers are required to
> > check submissions against:
>
> Done.
>

Sorry to reiterate, I'm just rewriting it here so it doesn't get lost in
the thread again:

- Status about MPEG-1 Layer I/II (e.g. twolame) and video decoding (e.g.
smpeg). Is it allowed?
- Status about branches. Ex. asking branches for mpg123 is fine, toolame
gets this answer:

"Blocked: Even mp3 decoding was not imported to F24, and any decision to do
so should be coordinated with the repo currently providing said package."

Cheers,
--Simone

-- 
You cannot discover new oceans unless you have the courage to lose sight of
the shore (R. W. Emerson).

http://xkcd.com/229/
http://negativo17.org/
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: mp3 encoding now ok

[Simone Caronni]

On Sun, May 14, 2017 at 9:37 PM, Simone Caronni <negativ...@gmail.com>
wrote:

> Hello,
>
> On Thu, May 4, 2017 at 6:17 PM, Yaakov Selkowitz <yselk...@redhat.com>
> wrote:
>
>> On 2017-05-03 12:44, Christian Schaller wrote:
>>
>>> So just wanted everyone to know that we now have the go ahead to ship
>>> mp3 encoding in Fedora too. So anyone involved with packaging
>>> mp3 encoders can now start migrating them to the Fedora repositories. We
>>> are still in the process of evaluating other codecs.
>>>
>>
>> What about the rest of MPEG-1, namely Layer II audio (MP2) encoding (e.g.
>> twolame) and video decoding (e.g. smpeg)?
>
>
> Any chance to have this question answered? For "decoding ok" in November
> last year, it was implied that MPEG-1 Layer I/II/III was fine (libmad
> etc.), but for "encoding ok" this does not seem as clear.
>

Also these pages should be updated, I guess:

https://fedoraproject.org/wiki/Multimedia
https://fedoraproject.org/wiki/Multimedia/MP3

I'm not sure I have the correct information for making the edit myself.

Can someone also point me to a page about the other restricted formats that
are not yet allowed? Like H.265/HEVC, H.264 (not OpenH264), etc.

Thanks,
--Simone

-- 
You cannot discover new oceans unless you have the courage to lose sight of
the shore (R. W. Emerson).

http://xkcd.com/229/
http://negativo17.org/
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: mp3 encoding now ok

[Simone Caronni]

Hello,

On Thu, May 4, 2017 at 6:17 PM, Yaakov Selkowitz 
wrote:

> On 2017-05-03 12:44, Christian Schaller wrote:
>
>> So just wanted everyone to know that we now have the go ahead to ship mp3
>> encoding in Fedora too. So anyone involved with packaging
>> mp3 encoders can now start migrating them to the Fedora repositories. We
>> are still in the process of evaluating other codecs.
>>
>
> What about the rest of MPEG-1, namely Layer II audio (MP2) encoding (e.g.
> twolame) and video decoding (e.g. smpeg)?


Any chance to have this question answered? For "decoding ok" in November
last year, it was implied that MPEG-1 Layer I/II/III was fine (libmad
etc.), but for "encoding ok" this does not seem as clear.

Thanks,
--Simone



-- 
You cannot discover new oceans unless you have the courage to lose sight of
the shore (R. W. Emerson).

http://xkcd.com/229/
http://negativo17.org/
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: [review-swap] swatchbooker

[Simone Caronni]

Hi Luya,

On Tue, Apr 11, 2017 at 8:19 AM, Luya Tshimbalanga 
wrote:

> I am looking for swaping review with swatchbooker:
>
> https://bugzilla.redhat.com/show_bug.cgi?id=1441046


> An odd issue is the startup of the application with the correct path
> within the binary leaving baffled. Improvement welcome.
>

Taken. Will look into it.

Regards,
--Simone



-- 
You cannot discover new oceans unless you have the courage to lose sight of
the shore (R. W. Emerson).

http://xkcd.com/229/
http://negativo17.org/
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: libdbusmenu upgrade in Fedora rawhide (and eventually in Fedora 26, 25)

[Simone Caronni]

On Sun, Apr 16, 2017 at 10:06 PM, Sérgio Basto  wrote:

> I agree , IMHO it should go also to Fedora 25, because it is a bug that
> could be fixed before F25 release ...
>
> Refining your query:
> dnf --releasever=rawhide --disablerepo='*' --enablerepo=rawhide
> repoquery --available  --whatrequires "libdbusmenu-glib.so*" --alldeps
> --qf "%{sourcerpm}"
>
> appcenter-0.1.4-1.fc27.src.rpm
> cairo-dock-plug-ins-3.4.1-14.fc27.src.rpm
> dayjournal-23.0.6-1.fc26.src.rpm
> gnome-shell-extension-pomodoro-0.13.1-1.fc26.src.rpm
> libappindicator-12.10.0-14.fc26.src.rpm
> libdbusmenu-12.10.2-11.fc26.src.rpm
> libunity-7.1.4-6.20151002.fc26.src.rpm
> lxsession-0.5.3-2.fc26.1.src.rpm
> pantheon-files-0.3.3-1.fc27.src.rpm
> pantheon-photos-0.2.2-1.fc27.src.rpm
> perl-Gtk2-AppIndicator-0.15-10.fc26.src.rpm
> pidgin-indicator-1.0-2.fc26.src.rpm
> plank-0.11.3-3.fc26.src.rpm
> slingshot-launcher-2.1.1-1.fc26.src.rpm
> switchboard-2.2.1-2.fc26.src.rpm
> uget-2.1.5-1.fc27.src.rpm
> workrave-1.10.16-2.fc26.src.rpm
>

Oh well, I've made a test build of 16.10 and it does not seem even to be
the need for a rebuild, as there is no ABI change.
It seems an update it's just what's necessary. I'll wait for the package
maintainer answer and then proceed.

Regards.
--Simone


-- 
You cannot discover new oceans unless you have the courage to lose sight of
the shore (R. W. Emerson).

http://xkcd.com/229/
http://negativo17.org/
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

libdbusmenu upgrade in Fedora rawhide (and eventually in Fedora 26, 25)

[Simone Caronni]

Hello,

it seems that libdbusmenu has been mostly neglected since Fedora 20:

http://pkgs.fedoraproject.org/cgit/rpms/libdbusmenu.git/

There is a bug affecting Steam on most platforms due to the version of
libdbusmenu being too old:

https://bugzilla.rpmfusion.org/show_bug.cgi?id=4449

That could be fixed by updating libdbusmenu to a recent version and
rebuilding all the associated components:

$ sudo dnf repoquery --whatrequires "libdbusmenu-glib.so.4()(64bit)"
Last metadata expiration check: 2:05:45 ago on Sun Apr 16 19:22:55 2017.
appcenter-0:0.1.4-1.fc25.x86_64
cairo-dock-plug-ins-base-0:3.4.1-9.fc25.x86_64
cairo-dock-plug-ins-dbus-0:3.4.1-9.fc25.x86_64
cairo-dock-plug-ins-unstable-0:3.4.1-9.fc25.x86_64
dayjournal-0:23.0.6-1.fc25.x86_64
diodon-0:1.5.0-4.fc25.x86_64
gnome-shell-extension-pomodoro-0:0.13.1-1.fc25.x86_64
libappindicator-0:12.10.0-12.fc25.x86_64
libappindicator-gtk3-0:12.10.0-12.fc25.x86_64
libdbusmenu-devel-0:12.10.2-10.fc24.x86_64
libdbusmenu-gtk2-0:12.10.2-10.fc24.x86_64
libdbusmenu-gtk3-0:12.10.2-10.fc24.x86_64
libdbusmenu-jsonloader-0:12.10.2-10.fc24.x86_64
libdbusmenu-tools-0:12.10.2-10.fc24.x86_64
libunity-0:7.1.4-4.20151002.fc25.x86_64
lxsession-0:0.5.2-11.D20160817git699c1695c2.fc25.x86_64
lxsession-0:0.5.3-2.fc25.x86_64
pantheon-files-0:0.3.2-1.fc25.x86_64
pantheon-photos-0:0.2.2-1.fc25.x86_64
perl-Gtk2-AppIndicator-0:0.15-9.fc25.x86_64
pidgin-indicator-0:0.9-2.fc25.x86_64
pidgin-indicator-0:1.0-1.fc25.x86_64
plank-0:0.11.2-1.fc25.x86_64
plank-0:0.11.3-1.fc25.x86_64
python-appindicator-0:12.10.0-12.fc25.x86_64
slingshot-launcher-0:2.1.1-1.fc25.x86_64
switchboard-0:2.2.1-2.fc25.x86_64
uget-0:2.1.4-1.fc25.x86_64
uget-0:2.1.5-1.fc25.x86_64
workrave-0:1.10.16-1.fc25.x86_64

I've asked co-maintainership for libdbusmenu already, so I can at least fix
it for Fedora 27. If that works, I would like to attempt to rebuild all
associated components in previous Fedora releases.

At a minimum it would be nice to have at least the rebuilds in place for
Fedora 26.

Does anybody have any opinion on this?

Thanks & regards,
--Simone


-- 
You cannot discover new oceans unless you have the courage to lose sight of
the shore (R. W. Emerson).

http://xkcd.com/229/
http://negativo17.org/
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Move Fedora 25 Vinagre / Weston dependency to FreeRDP 1.2 compatiblity package

[Simone Caronni]

On Thu, Mar 16, 2017 at 1:47 PM, Simone Caronni <negativ...@gmail.com>
wrote:
>
> Ah, I missed that guidelines. I would need a re-review of it.
>

Re-review for the rename created:

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

Dominik, I've added you in CC.

Regards,
--Simone

-- 
You cannot discover new oceans unless you have the courage to lose sight of
the shore (R. W. Emerson).

http://xkcd.com/229/
http://negativo17.org/
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Move Fedora 25 Vinagre / Weston dependency to FreeRDP 1.2 compatiblity package

[Simone Caronni]

On Thu, Mar 16, 2017 at 12:54 PM, Dominik 'Rathann' Mierzejewski <
domi...@greysector.net> wrote:

> Hello, Simone.
>
> On Thursday, 16 March 2017 at 10:27, Simone Caronni wrote:
> [...]
> > Guacamole / Vinagre / Weston: latest 1.2 release (compat-freerdp12)
> > Remmina: latest snapshot (freerdp) - usually the same date as the FreeRDP
> > snapshot.
> >
> > This would also allow me to close a lot of bugs related to Remmina &
> > Vinagre in Fedora 25. Example:
> >
> > https://bugzilla.redhat.com/show_bug.cgi?id=1404771
> >
> > If you have any opinions, please express yourself. I'm the maintainer for
> > Guacamole, Remmina and FreeRDP, so most of the stuff is already done
> > (compat-freerdp12 is in Fedora 25 updates-testing at the moment).
>
> That seems fine, but compat-freerdp12 should've been named freerdp1.2,
> according to current naming guidelines:
> https://fedoraproject.org/wiki/Packaging:Naming#
> Multiple_packages_with_the_same_base_name
>
> Please rename it before pushing to stable.
>

Ah, I missed that guidelines. I would need a re-review of it.
Would you mind doing the re-review of freerdp1.2? Considering it has just
been done there should be nothing wrong.

Also in Fedora there are plenty of those with a compat-* prefix:

https://koji.fedoraproject.org/koji/search?match=glob=package=compat-*

Shall we file a bug for all of them?

Regards,
--Simone


-- 
You cannot discover new oceans unless you have the courage to lose sight of
the shore (R. W. Emerson).

http://xkcd.com/229/
http://negativo17.org/
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Move Fedora 25 Vinagre / Weston dependency to FreeRDP 1.2 compatiblity package

[Simone Caronni]

Hi all,

I would like to move Vinagre / Weston in Fedora 25 to use the new FreeRDP
1.2 compatibility package that I created. This would allow me to update
FreeRDP and Remmina to the same snapshot that is in Fedora 26/rawhide. Both
of these things have been done already in Fedora 26/rawhide.

FreeRDP had no releases for more than 2 years and there is absolutely no
guarantee of any stability towards API/ABI. So the best that it can happen
is that in a given moment in time all components relying on FreeRDP work
fine. Just by saying that it makes me shiver.

I've been trying to push on a new release along with a lot of other people
to no avail so far.

The end result will be the same:

Guacamole / Vinagre / Weston: latest 1.2 release (compat-freerdp12)
Remmina: latest snapshot (freerdp) - usually the same date as the FreeRDP
snapshot.

This would also allow me to close a lot of bugs related to Remmina &
Vinagre in Fedora 25. Example:

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

If you have any opinions, please express yourself. I'm the maintainer for
Guacamole, Remmina and FreeRDP, so most of the stuff is already done
(compat-freerdp12 is in Fedora 25 updates-testing at the moment).

Regards,
--Simone


-- 
You cannot discover new oceans unless you have the courage to lose sight of
the shore (R. W. Emerson).

http://xkcd.com/229/
http://negativo17.org/
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Offering to co maintain lv2 related packages (lv2, lilv, suil, serd, sord, sratom...)

[Simone Caronni]

Hello,

On Wed, Jan 25, 2017 at 9:36 AM, Guido Aulisi 
wrote:

> Hello,
> I recently joined the packager group and I made 2 audio related
> packages (setBfree and lv2-ir-plugins).
> I noticed that lv2 related packages are behind upstream releases, and I
> know there are important bug fixes in these new releases, so I'm
> proposing myself as a co-maintainer of lv2 related packages (from
> drobilla.net) to try to package the latest versions (in rawhide).
> The packages are:
>
> lv2
> sratom
> serd
> sord
> suil
> lilv
>

I'm requiring the epel7 ones, so I requested branches for some of them a
few months ago. Count me in if you need additional maintainership, would be
nice to make sure the packages build also on el7 so we can just merge the
commits in the various branches.

Thanks,
--Simone




>
> Ciao
> Guido
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
>
>


-- 
You cannot discover new oceans unless you have the courage to lose sight of
the shore (R. W. Emerson).

http://xkcd.com/229/
http://negativo17.org/
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

[EPEL-devel] speexdsp update overwrites part of a RHEL 7 package

[Simone Caronni]

Hello,

a package entered stable that overwrites part of a RHEL 7 package.

The bug is here:

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

As originally reported, the contributor has not replied in 10 days so
I'm reporting the thing here. I would consider this an urgent bug; as
it's impossible to compile against RHEL 7 speex/speexdsp packages
anymore. For example VLC 2.2 does not compile, you need to exclude the
updated speexdsp packages.

What is the next step here?

Thanks & regards,
--Simone







-- 
You cannot discover new oceans unless you have the courage to lose
sight of the shore (R. W. Emerson).

http://xkcd.com/229/
http://negativo17.org/
___
epel-devel mailing list -- epel-devel@lists.fedoraproject.org
To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org

Re: EL7 update stuck in pending/testing for a week

[Simone Caronni]

On Tue, Oct 18, 2016 at 9:49 PM, Peter Robinson 
wrote:

> No, it's paused while I've been boot strapping aarch64, it should
> start moving again shortly.
>

Ah ok, thanks.

--Simone


-- 
You cannot discover new oceans unless you have the courage to lose sight of
the shore (R. W. Emerson).

http://xkcd.com/229/
http://negativo17.org/
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

EL7 update stuck in pending/testing for a week

[Simone Caronni]

Hello,

I've tried to push a couple of new libraries in epel-7, but the update did
not reach the testing repository in 7 days:

https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2016-e4793acdf5

Is there anything wrong with it? It doesn't seem any different than the
other updates.
Can someone look at it?

Thanks & regards,
--Simone

-- 
You cannot discover new oceans unless you have the courage to lose sight of
the shore (R. W. Emerson).

http://xkcd.com/229/
http://negativo17.org/
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Freerdp update with bundle in guacamole-server

[Simone Caronni]

On Tue, Dec 1, 2015 at 12:20 AM, Neal Gompa  wrote:

> Simone,
>
> Could the old version of FreeRDP be temporarily bundled into guacamole
> server for F23 so that everything else can be updated and rebuilt?
>

We can, but it's not up to me to decide. I can change the spec file and
make a %global variable at the top to enable use of a bundled FreeRDP
tarball or not.

If you make the request, plese put me in CC.
--Simone


-- 
You cannot discover new oceans unless you have the courage to lose sight of
the shore (R. W. Emerson).

http://xkcd.com/229/
http://negativo17.org/
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: Freerdp update with bundle in guacamole-server

[Simone Caronni]

On Mon, Nov 30, 2015 at 4:29 PM, Josh Boyer 
wrote:

> No.  I want to suggest that continuing to say things like "It is ok to
> leave it disabled/Broken in Fedora 24..." is bad.  People read text
> like that and continue to think Rawhide is a dumping ground.  Disabled
> is one thing, but broken is never "ok".
>

My bad, is exactly as Nael said, will phrase it more correctly in the
future.
I've opened a bug to Guacamole, they confirmed they will update support for
new FreeRDP API as soon as the tarball is released.

Regards,
--Simone


-- 
You cannot discover new oceans unless you have the courage to lose sight of
the shore (R. W. Emerson).

http://xkcd.com/229/
http://negativo17.org/
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: Freerdp update with bundle in guacamole-server

[Simone Caronni]

On Sat, Nov 28, 2015 at 3:55 PM, Pavel Alexeev 
wrote:

> And yes, as current version of Remmina has much errors in Fedora 23 I want
> update it to 1.2.0-rcgit.5 in that branch too.
>

Please make sure that for Fedora 23 you are not breaking Guacamole though.
It is ok to leave it disabled/Broken in Fedora 24 until FreeRDP releases
the 2.0 snapshot but not in Fedora 23 where this is up and running.

Please also note that David Woodhouse backported a lot of patches to the
1.2.0 branch to get the new functionality without breaking the API.

Regards,
--Simone

-- 
You cannot discover new oceans unless you have the courage to lose sight of
the shore (R. W. Emerson).

http://xkcd.com/229/
http://negativo17.org/
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: Freerdp update with bundle in guacamole-server

[Simone Caronni]

Hello,

as you've said, after continuous issues, the Guacamole developers are not
willing to update to unreleased versions/tarballs.

I've briefly talked with David Woodhouse offlist a few days ago and I've
pushed a 15th november 2015 build of both FreeRDP [1] and Remmina [2] at
the same time in rawhide (f24). For the moment I've basically ignored
guacamole-server at all and I'm waiting on the (promised) 2.0 snapshot of
FreeRDP before updating it.

@Pavel, I suppose you are refferring to update directly in Fedora 23 and
you were not referring to rawhide. I would be more than happy to push an
update to Fedora 23 considering the amount of crashes that Remmina has, but
I would wait for the tarball and the Guacamole patch. Otherwise disabled
RDP support in Guacamole means chunking away a big part of its features;
and I would like to avoid it.

Regards,
--Simone

[1] http://koji.fedoraproject.org/koji/buildinfo?buildID=699433
[2] http://koji.fedoraproject.org/koji/buildinfo?buildID=699494



On Sun, Nov 22, 2015 at 7:27 PM, Pavel Alexeev <fo...@hubbitus.com.ru>
wrote:

> Thanks Neal.
>
> Simone, what you think? I really want move forward and find way. Remmina
> have many bugs which should be fixed upstream, but I still can't update.
>
>
> 14.11.2015 22:20, Neal Gompa wrote:
>
>> I am not the maintainer of guacamole-server. That is Simone Caronni
>> (who I cc'd to this email) according to PkgDB[0]. Simone is the one
>> you want to ask, really.
>>
>> [0]: https://admin.fedoraproject.org/pkgdb/package/guacamole-server/
>>
>> On Sat, Nov 14, 2015 at 2:15 PM, Pavel Alexeev <fo...@hubbitus.com.ru>
>> wrote:
>>
>>> Hello Neal.
>>> If I right understand you are maintainer of guacamole? Do you wish
>>> proceed
>>> with freerdp-compat package only?
>>>
>>> 09.11.2015 13:11, Pavel Alexeev пишет:
>>>
>>> 08.11.2015 23:38, Neal Gompa пишет:
>>>
>>> On Sun, Nov 8, 2015 at 2:31 PM, Pavel Alexeev <fo...@hubbitus.com.ru>
>>> wrote:
>>>
>>>> Hello.
>>>>
>>>> More than half year in the past freerdp was updated and then reverted
>>>> version to current present [1], mostly to allow built guacamole-server
>>>> [2].
>>>>
>>>> As I see it still stick with that version.
>>>> Meantime freerdp move forward. Remmina, which require fresh versions of
>>>> freerdp also can't be updated.
>>>>
>>>> Recently our bundling policy changed [3].
>>>>
>>>>  From freerdp depends:
>>>> $ dnf repoquery --source --alldeps --whatrequires freerdp-libs
>>>> ...
>>>> freerdp-1.2.0-0.9.git.24a752a.fc23.src.rpm
>>>> guacamole-server-0.9.7-1.fc23.src.rpm
>>>> medusa-2.2-0.rc1.2.fc23.1.src.rpm
>>>> remmina-1.2.0-0.8.git.b3237e8.fc23.src.rpm
>>>> vinagre-3.18.1-1.fc23.src.rpm
>>>> vlc-2.2.2-0.1.fc23.src.rpm (rpmfusion.org)
>>>> weston-1.9.0-1.fc23.src.rpm
>>>>
>>>> $ dnf repoquery --source --alldeps --whatrequires freerdp
>>>> ...
>>>> krdc-15.04.2-2.fc23.src.rpm
>>>>
>>>> Today I have try build freerdp [4] from master and all dependencies
>>>> against it.
>>>>
>>>> And again, *only* guacamole-server fails to build with:
>>>> In file included from rdp_stream.h:29:0,
>>>>   from rdp_fs.c:27:
>>>> rdp_svc.h:28:38: fatal error: freerdp/utils/svc_plugin.h: No such file
>>>> or
>>>> directory
>>>> compilation terminated.
>>>>
>>>> It relied on old svc_plugin which has been rid in 2013 year [5].
>>>>
>>>> Main question. Is it a good reason to bundle copy of current version
>>>> freerdp into guacamole-server (at least until someone do not willing
>>>> port
>>>> it) and update it for rest of Fedora?
>>>>
>>>> I have not tried to do such bundle yet, but if no one argue I could try
>>>> do
>>>> that with update freerdp and rebuild all other deps too.
>>>>
>>>> [1]
>>>> https://lists.fedoraproject.org/pipermail/devel/2015-March/209140.html
>>>> [2]
>>>> https://lists.fedoraproject.org/pipermail/devel/2015-March/209181.html
>>>> [3] https://fedorahosted.org/fpc/ticket/575
>>>> [4] https://github.com/FreeRDP/FreeRDP
>>>> [5] https://github.com/FreeRDP/FreeRDP/pull/1574
>>>>
>>>> --
>>>> With best wishes, Pavel Alexeev.
>>>> Yes, I'm a fool - I 

Re: Freerdp update with bundle in guacamole-server

[Simone Caronni]

On Tue, Nov 24, 2015 at 2:54 PM, Simone Caronni <negativ...@gmail.com>
wrote:

> Hello,
>
> as you've said, after continuous issues, the Guacamole developers are not
> willing to update to unreleased versions/tarballs.
>
> I've briefly talked with David Woodhouse offlist a few days ago and I've
> pushed a 15th november 2015 build of both FreeRDP [1] and Remmina [2] at
> the same time in rawhide (f24). For the moment I've basically ignored
> guacamole-server at all and I'm waiting on the (promised) 2.0 snapshot of
> FreeRDP before updating it.
>
> @Pavel, I suppose you are refferring to update directly in Fedora 23 and
> you were not referring to rawhide. I would be more than happy to push an
> update to Fedora 23 considering the amount of crashes that Remmina has, but
> I would wait for the tarball and the Guacamole patch. Otherwise disabled
> RDP support in Guacamole means chunking away a big part of its features;
> and I would like to avoid it.
>
> Regards,
> --Simone
>
> [1] http://koji.fedoraproject.org/koji/buildinfo?buildID=699433
> [2] http://koji.fedoraproject.org/koji/buildinfo?buildID=699494
>

FYI: https://glyptodon.org/jira/browse/GUAC-1413

Regards,
--Simone


-- 
You cannot discover new oceans unless you have the courage to lose sight of
the shore (R. W. Emerson).

http://xkcd.com/229/
http://negativo17.org/
-- 
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: virt-manager - libappindicator-gtk3 - remmina

[Simone Caronni]

On 4 June 2015 at 03:24, Kevin Kofler kevin.kof...@chello.at wrote:

 ndeed, you missed:
 https://lists.fedoraproject.org/pipermail/devel/2014-March/196343.html

 libappindicator is now (since Fedora 22) also REQUIRED for GTK+ system tray
 applets to work under KDE Plasma. (Plasma 5 no longer supports the legacy
 XEmbed-based system tray protocol that the builtin GTK+ classes implement.)

 Please DO NOT REMOVE libappindicator support from your packages. Instead,
 actually ADD it where upstream supports it and it is not yet enabled in
 Fedora.


Ok, sounds fair, thanks for clarification. In that thread on -devel (i've
read it yesterday) there's the note that it would be eventually introduced
somewhere around Fedora 22. Is there anything official written somewhere?
Wiki, etc.

I'm reverting the change in remmina.git. Can I just delete the update in
Bodhi?

Thanks  regards,
--Simone


-- 
You cannot discover new oceans unless you have the courage to lose sight of
the shore (R. W. Emerson).

http://xkcd.com/229/
http://negativo17.org/
-- 
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: virt-manager - libappindicator-gtk3 - remmina

[Simone Caronni]

On 3 June 2015 at 11:28, Pavel Alexeev pa...@hubbitus.info wrote:

  Hi,
Is not it virt-manager problem or libappindicator? Shouldn't it be
 addressed there?


If I remember correctly there was a time when people were discussing about
bringing Unity in Fedora. This did not happen, and actually the library is
pretty useless as there is no libappindicator consumer right now. I'm not
sure it's worth investigating.

Regards,
--Simone


-- 
You cannot discover new oceans unless you have the courage to lose sight of
the shore (R. W. Emerson).

http://xkcd.com/229/
http://negativo17.org/
-- 
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: virt-manager - libappindicator-gtk3 - remmina

[Simone Caronni]

In Fedora 21 it was already disabled.
Disabled it also on f22 and master branches.

https://admin.fedoraproject.org/updates/remmina-1.2.0-0.6.git.b3237e8.fc22

Regards,
--Simone


On 1 June 2015 at 11:20, poma pomidorabelis...@gmail.com wrote:


 libappindicator-gtk3 breaks virt-manager's systray functionality,
 precisely:
 click on virt-manager's systray icon via left mice button -should- quickly
 show or hide Virtual Machine Manager window.

 If remember correctly, I have already mentioned this problemo at least
 twice, right mister Robinson.

 Did I really missed something important in this respect, or in a parallel
 universe you guys use Unity on Fedora?

 Related:
 Try enable APPINDICATOR by suggestion of Giovanni Panozzo.
 http://pkgs.fedoraproject.org/cgit/remmina.git/commit/?id=2ef81fd


 # dnf install remmina
 Fatal Python error: Failed to open /dev/urandom
 Aborted

 # yum install remmina
 Resolving Dependencies
 -- Running transaction check
 --- Package remmina.x86_64 0:1.2.0-0.5.git.b3237e8.fc23 will be installed
 -- Processing Dependency: libappindicator3.so.1()(64bit) for package:
 remmina-1.2.0-0.5.git.b3237e8.fc23.x86_64
 -- Running transaction check
 --- Package libappindicator-gtk3.x86_64 0:12.10.0-9.fc23 will be installed
 -- Processing Dependency: libindicator3.so.7()(64bit) for package:
 libappindicator-gtk3-12.10.0-9.fc23.x86_64
 -- Running transaction check
 --- Package libindicator-gtk3.x86_64 0:12.10.1-4.fc22 will be installed
 -- Finished Dependency Resolution

 Dependencies Resolved


 
  PackageArch VersionRepository

  Size

 
 Installing:
  remminax86_64   1.2.0-0.5.git.b3237e8.fc23 rawhide
  384 k
 Installing for dependencies:
  libappindicator-gtk3   x86_64   12.10.0-9.fc23 rawhide
 40 k
  libindicator-gtk3  x86_64   12.10.1-4.fc22 rawhide
 67 k

 Transaction Summary

 
 Install  1 Package (+2 Dependent packages)

 Total download size: 491 k
 Installed size: 1.9 M
 Is this ok [y/d/N]: N
 Exiting on user command
 ...


 $ rpm -q virt-manager
 virt-manager-1.2.0-1.fc23.noarch


 $ rpm -q --qf '\n%{url}\n\n%{summary}\n\n%{description}\n'
 libappindicator-gtk3

 https://launchpad.net/libappindicator

 Application indicators library - GTK 3

 A library to allow applications to export a menu into the Unity Menu bar.
 Based
 on KSNI it also works in KDE and will fallback to generic Systray support
 if
 none of those are available.

 This package contains the GTK 3 version of this library.




-- 
You cannot discover new oceans unless you have the courage to lose sight of
the shore (R. W. Emerson).

http://xkcd.com/229/
http://negativo17.org/
-- 
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: virt-manager - libappindicator-gtk3 - remmina

[Simone Caronni]

On 3 June 2015 at 14:28, Giovanni Panozzo giova...@panozzo.it wrote:


 Adding Antenore to this thread, the other Remmina developer left on the
 whole earth :)

 My small contribution: Remmina can survive without libappindicators. It
 will fallback to use GtkStatusIcon to show its icon under Xfce/Lxde/Kde
 (note that GtkStatusIcon is deprecated now, with no alternatives).

 My original suggestion was intended for Gnome Shell users: link remmina
 with libappindicators AND also add this extension
 https://extensions.gnome.org/extension/615/appindicator-support/
 The result under Gnome Shell is a very nice system tray menu for remmina.

 But currently is almost impossible to have a coherent and working on all
 desktop environment systemtray icon + menu.
 I started to collect informations on this page:
 https://github.com/FreeRDP/Remmina/wiki/Systray-menu
 but it's almost impossible to come to a simple solution.

 And in our reasoning (this morning!) we discussed also if we should just
 remove the systray icon+menu. Your opinion on the removal are welcome :)

 So, feel free to remove libappindicators on fedora: Gnome Shell users
 which did not install the appindicator extension will not notice any
 difference without libappindicators.
 Users of xfce/kde/lxde will get a GtkStatusIcon menu, if the apposite
 panel applet is loaded.

 Giovanni


Thanks for the explanation!

The total absence of any FreeRDP release (i.e. you always need the latest
git commit) makes packaging this along with all the other software using
FreeRDP a real nightmare.

Regards,
--Simone

-- 
You cannot discover new oceans unless you have the courage to lose sight of
the shore (R. W. Emerson).

http://xkcd.com/229/
http://negativo17.org/
-- 
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: virt-manager - libappindicator-gtk3 - remmina

[Simone Caronni]

On 3 June 2015 at 12:09, Jaroslav Reznik jrez...@redhat.com wrote:

  If I remember correctly there was a time when people were discussing
 about
  bringing Unity in Fedora. This did not happen, and actually the library
 is
  pretty useless as there is no libappindicator consumer right now. I'm not
  sure it's worth investigating.

 There is consumer - Plasma 5, one of two blocking desktops :).

 For more info
 https://lists.fedoraproject.org/pipermail/devel/2014-March/196343.html

 So it would be nice to have GTK apps that still offers systray built
 against
 it too.


Was Remmina the only program built against libappindicator (not sure I got
all cases in the repoquery)?

libappindicator.so.1:

libappindicator-devel-0:12.10.0-8.fc22.x86_64
perl-Gtk2-AppIndicator-0:0.15-5.fc22.x86_64
python-appindicator-0:12.10.0-8.fc22.x86_64

libappindicator3.so.1:

libappindicator-gtk3-devel-0:12.10.0-8.fc22.x86_64
remmina-0:1.2.0-0.5.git.b3237e8.fc22.x86_64
uget-0:2.0-1.fc22.x86_64

Regards,
--Simone


-- 
You cannot discover new oceans unless you have the courage to lose sight of
the shore (R. W. Emerson).

http://xkcd.com/229/
http://negativo17.org/
-- 
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: Testing request: gdm-on-Wayland on hybrid graphics laptops (esp. Macbooks)

[Simone Caronni]

Hello,

On 14/05/2015 20:01:21 GMT, Adam Williamson adamw...@fedoraproject.org
 wrote:

 Hi folks!

 We have a somewhat-worrying proposed blocker for F22:

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


I have some issues with two different laptops, one with an Intel/Nvidia
combo and one with an Intel/Radeon combo. Although not strictly related to
have a gdm login on Wayland I think it's worth describing.

Intel/Nvidia (binary driver):

The Nvidia one (intel + nvidia blob) is working perfectly with Fedora 21
but not on Fedora 22 with the Optimus offloading configuration as
depicted in Nvidia's README [1]. The X server simply crashes, and there is
no way to have a GDM login screen with this method. I was using the X
configuration file described in the docs plus the script /etc/gdm/Init/:0
for running the xrandr commands at login. Also, glamor is loaded even
though its loading is explicitly disabled in xorg.conf.

Unfortunately the laptop can only work with such configuration, the
included GTX 860m does not work with nouveau reliably (lot of console
errors and some crashes, no 3d) and there's no way to disable one of the
cards through the bios.

I've tried updating xorg with some 1.18 patches [2], removing glamor,
forcing root access for everybody in Xwrapper.config to no avail, I always
got the same crash. I'm considering this a regression... should I open a
bug or it will be simply closed because there is the Nvidia binary involved?

Intel/Nouveau and Intel/Radeon:

When using wayland, there's no way to use the second card (DRI_PRIME), it
will simply use the first card for GL programs or crash directly (nothing
useful in the logs). Is prime supported on Wayland? The server is also
always started as root, wasn't it supposed to start inside a user session
by default on Open KMS drivers?

Thanks  regards,
--Simone



[1]
http://us.download.nvidia.com/XFree86/Linux-x86/352.09/README/randr14.html
[2] http://lists.x.org/archives/xorg-devel/2014-December/045050.html

-- 
You cannot discover new oceans unless you have the courage to lose sight of
the shore (R. W. Emerson).

http://xkcd.com/229/
http://negativo17.org/
-- 
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: [EPEL-devel] Koji build errors (all releases - el5/6/7)

[Simone Caronni]

On 15 May 2015 at 10:42, Simone Caronni negativ...@gmail.com wrote:

 Hello,

 don't know if it has been reported already, but I have 3 weird errors on
 Koji while scratch building some packages. Please note that last time the
 same packages built fine.

 - el5 ignores debug files and does not assemble the debuginfo package (?):
   http://koji.fedoraproject.org/koji/taskinfo?taskID=9749773

 http://koji.fedoraproject.org/koji/getfile?taskID=9749773name=build.logoffset=-4000

 - el6 built succesfully, but it just says failed without any log (??):
   http://koji.fedoraproject.org/koji/taskinfo?taskID=9749758

 - el7 has some dependency issues:
   http://koji.fedoraproject.org/koji/taskinfo?taskID=9749761

 http://koji.fedoraproject.org/koji/getfile?taskID=9749761name=root.logoffset=-4000


Ok, it's a general issue... same thing happening in el6 also happening in
fc21, fc22 and rawhide:

http://koji.fedoraproject.org/koji/packageinfo?packageID=4820

Regards,
--Simone



-- 
You cannot discover new oceans unless you have the courage to lose sight of
the shore (R. W. Emerson).

http://xkcd.com/229/
http://negativo17.org/
___
epel-devel mailing list
epel-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/epel-devel

[EPEL-devel] Koji build errors (all releases - el5/6/7)

[Simone Caronni]

Hello,

don't know if it has been reported already, but I have 3 weird errors on
Koji while scratch building some packages. Please note that last time the
same packages built fine.

- el5 ignores debug files and does not assemble the debuginfo package (?):
  http://koji.fedoraproject.org/koji/taskinfo?taskID=9749773

http://koji.fedoraproject.org/koji/getfile?taskID=9749773name=build.logoffset=-4000

- el6 built succesfully, but it just says failed without any log (??):
  http://koji.fedoraproject.org/koji/taskinfo?taskID=9749758

- el7 has some dependency issues:
  http://koji.fedoraproject.org/koji/taskinfo?taskID=9749761

http://koji.fedoraproject.org/koji/getfile?taskID=9749761name=root.logoffset=-4000

Thanks  regards,
--Simone


-- 
You cannot discover new oceans unless you have the courage to lose sight of
the shore (R. W. Emerson).

http://xkcd.com/229/
http://negativo17.org/
___
epel-devel mailing list
epel-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/epel-devel

Re: [EPEL-devel] Koji build errors (all releases - el5/6/7)

[Simone Caronni]

On 15 May 2015 at 12:03, Paul Howarth p...@city-fan.org wrote:


 Looks to me like that sub-package has an arch-specific dependency but it's
 a noarch sub-package.


Gotcha. Thanks for spotting!!

Does not create any problem if you install from the same mock build as the
dependency will be stuck on the same arch as the build. I did not spot it
locally. The error is not very clear in Koji, though.

Also, the el5 issue is due to the fact that there can be no noarch
subpackage in an x86_64/i686 package. Now I just need a fix for the el7
dependencies.

Thanks  regards,
--Simone







-- 
You cannot discover new oceans unless you have the courage to lose sight of
the shore (R. W. Emerson).

http://xkcd.com/229/
http://negativo17.org/
___
epel-devel mailing list
epel-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/epel-devel

Re: [EPEL-devel] Fwd: [Fedora-packaging] %license for EPEL6

[Simone Caronni]

On 17 March 2015 at 20:08, Paul Howarth p...@city-fan.org wrote:

 On Tue, 17 Mar 2015 11:34:10 -0600
 Stephen John Smoogen smo...@gmail.com wrote:

  This was on the packaging list but effects EPEL. Any suggestions?
 
  -- Forwarded message --
  From: Thomas Moschny thomas.mosc...@gmail.com
  Date: 17 March 2015 at 10:59
  Subject: [Fedora-packaging] %license for EPEL6
  To: Fedora Packaging list packag...@lists.fedoraproject.org
 
 
  I have a package that can be build on all Fedora branches and on EPEL
  6 and 7 with the same spec file. It uses
 

 Basically, I copy the license file into %_pkgdocdir like for any other
 documentation on systems where %_licensedir isn't defined.


I'm using this really nice trick (it was posted by someone here in the list
in the past months):

http://pkgs.fedoraproject.org/cgit/bacula.git/tree/bacula.spec#n583

I'm building the same SPEC file on all RHEL/CentOS/Fedora releases.


Regards,
--Simone

-- 
You cannot discover new oceans unless you have the courage to lose sight of
the shore (R. W. Emerson).

http://xkcd.com/229/
http://negativo17.org/
___
epel-devel mailing list
epel-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/epel-devel

Re: Orphaning iscan-firmware (Firmware for Epson flatbed scanners)

[Simone Caronni]

Hello,

On 13 January 2015 at 14:55, Dominik 'Rathann' Mierzejewski 
domi...@greysector.net wrote:

 Dear Fedora Community,
 I'm orphaning the iscan-firmware package since I no longer have even
 one Epson scanner which would require it. Hopefully someone else
 with one of the supported scanners can take it.


I will take it, as I'm one of those users!

Thanks,
--Simone


-- 
You cannot discover new oceans unless you have the courage to lose sight of
the shore (R. W. Emerson).

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

FreeRDP rawhide rebuild

[Simone Caronni]

FreeRDP is dropping monolithic builds in the latest release:

https://github.com/FreeRDP/FreeRDP/commit/0313ca3622baec53425b749e65caa202015894de

All these libraries are no longer available.

libfreerdp-cache.so.1.2()(64bit)
libfreerdp-codec.so.1.2()(64bit)
libfreerdp-common.so.1.2.0()(64bit)
libfreerdp-core.so.1.2()(64bit)
libfreerdp-crypto.so.1.2()(64bit)
libfreerdp-gdi.so.1.2()(64bit)
libfreerdp-locale.so.1.2()(64bit)
libfreerdp-primitives.so.1.2()(64bit)
libfreerdp-rail.so.1.2()(64bit)
libfreerdp-utils.so.1.2()(64bit)

I will rebuild Remmina and Guacamole; but a a rebuild of Weston and Vinagre
is required.

Thanks,
--Simone

-- 
You cannot discover new oceans unless you have the courage to lose sight of
the shore (R. W. Emerson).

http://xkcd.com/229/
http://negativo17.org/
-- 
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: Are we rebasing xorg-x11 packages in F20?

[Simone Caronni]

On 25 November 2014 at 13:20, Lukas Zapletal l...@redhat.com wrote:

 I don't understand why I noticed this today, it looks like the latest
 update was a Critical Path one (???) when Fedora 20 was stable for six
 months.


 https://admin.fedoraproject.org/updates/FEDORA-2014-7331/xorg-x11-server-utils-7.7-6.fc20


from what I've seen xorg packages are always marked as Critical Path.

The update you are referring to is six months old, are you sure the xrandr
command is the culprit and not something else? Did you skip updates for six
months?

There's an intel driver from 18th november, for example:

https://admin.fedoraproject.org/updates/FEDORA-2014-15384/xorg-x11-drv-intel-2.21.15-9.fc20

This seems to be much more related to your issues. I don't had any output
renaming recently in the past year (Nouveau here).

Regards,
--Simone



-- 
You cannot discover new oceans unless you have the courage to lose sight of
the shore (R. W. Emerson).

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

File system error in Koji

[Simone Caronni]

Hello,

there seems to be some issue in the builders:

freerdp-1.2.0-0.3.beta.1.fc22 (592521) failed on
arm04-builder03.arm.fedoraproject.org (noarch),
arm02-builder21.arm.fedoraproject.org (armhfp):
  Traceback (most recent call last):
  File /usr/lib/python2.7/site-
packages/koji/daemon.py, line 1161, in runTask
response = (handler.run(),)
  File /usr/lib/python2.7/site-packages/koji/tasks.py, line 155, in run
self.createWorkdir()
  File /usr/lib/python2.7/site-packages/koji/tasks.py, line 181, in
createWorkdir
os.makedirs(self.workdir)
  File /usr/lib/python2.7/os.py, line 150, in makedirs
makedirs(head, mode)
  File /usr/lib/python2.7/os.py, line 157, in makedirs
mkdir(name, mode)
OSError: [Errno 30] Read-only file system: '/var/tmp/koji/tasks/9262'
SRPMS:
  freerdp-1.2.0-0.3.beta.1.fc22.src.rpm

Sorry if I missed this and the outage was already announced.

Regards,
--Simone


-- 
You cannot discover new oceans unless you have the courage to lose sight of
the shore (R. W. Emerson).

http://xkcd.com/229/
http://negativo17.org/
-- 
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: Mass reassign and orphan: steve

[Simone Caronni]

Hello,

On 11 November 2014 01:03, Pierre-Yves Chibon pin...@pingoured.fr wrote:

 openvpn -- A full-featured SSL VPN solution ( master f21 f20 f19 epel7 el6
 el5 )


is this still available? It seems is not:

https://admin.fedoraproject.org/pkgdb/package/openvpn/

As a user I would like to take it.

Regards,
--Simone


-- 
You cannot discover new oceans unless you have the courage to lose sight of
the shore (R. W. Emerson).

http://xkcd.com/229/
http://negativo17.org/
-- 
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: Make AppData files mandatory for applications shown in the software center

[Simone Caronni]

Hello,

first of all sorry if I missed this earlier, I can't hardly cope with all
mails received on devel. I tried to read them all when I can.
As the maintainer of these:

bacula-console-bat
 bacula-traymonitor


I would suggest them to be removed from the software center, they are far
from being awesome.

First of all, they don't work without a specific infrastructure in place;
they require a fully functional director, storage daemon and something to
backup. All of this is configured only through the command line with
additional packages not in the software center, and as all enterprise
software requires a good time to master it.

Second, since the inception of the commercial Bacula Enterprise variant,
the open source edition of these components has not seen a single commit in
years, there is almost no change in the source except for the ones required
to make it compile. All changes are now in the closed source commercial
edition. This is not the case with the complicated server/client and
command line based tools, which are regularly updated and receive new
features.

Thanks  regards,
--Simone



-- 
You cannot discover new oceans unless you have the courage to lose sight of
the shore (R. W. Emerson).

http://xkcd.com/229/
http://negativo17.org/
-- 
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: Looking for xorg-x11-* package co-maintainers

[Simone Caronni]

On 22 October 2014 11:25, Hans de Goede hdego...@redhat.com wrote:

 You do not need to be a hardcore X hacker to help here. 2 things
 with which I really could use help is keeping all the various bits
 and pieces up2date with upstream releases, and taking care of
 simple (packaging) bugs were possible.

 To give you an idea, currently I've this list of packages which
 still need to be synced with upstream for rawhide and Fedora-21 :

  -xcb-proto 1.11
  -libxcb 1.11
  -xrandr 1.4.3
  -libXfont 1.5.0
  -twm-1.0.8
  -imake 1.0.7, gccmakedep 1.0.3 (imake)
  -libICE 1.0.9
  -libXft 2.3.2
  -intel-gpu-tools 1.8
  -xkeyboard-config 2.13
  -xcb-util 0.4.0

 Note these are the upstream package names, the Fedora package
 names are not always the same. Also in some cases someone else
 may have updated them since I noticed that they were out of date,
 I've not rechecked the list recently.

 If you want to help out with maintaining these, please let me
 know!


I'm no hacker, but I can help with packaging. Some packages of those need
also to be put on par with recent packaging guidelines.
What's the policy here? Always have the latest pushed to rawhide and follow
the usual rules for releases in freeze (i.e. no big jumps)?

Regards,
--Simone


-- 
You cannot discover new oceans unless you have the courage to lose sight of
the shore (R. W. Emerson).

http://xkcd.com/229/
http://negativo17.org/
-- 
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: Looking for xorg-x11-* package co-maintainers

[Simone Caronni]

Out of the previous list, the only ones that have not been updated yet are:

-intel-gpu-tools 1.8 (1.7 in rawhide/f21)
-xkeyboard-config 2.13 (2.12 in rawhide/f21)
-xcb-util 0.4.0 (0.3.9 in rawhide/f21)
-libxcb 1.11 (1.10 in f21)
-xrandr 1.4.3 (1.4.2 in f21)
-twm-1.0.8 (1.0.7 in f21)
-imake 1.0.7 (1.0.6 in f21)
-gccmakedep 1.0.3 (1.0.2 in f21)

On 22 October 2014 12:17, Hans de Goede hdego...@redhat.com wrote:

  I'm no hacker, but I can help with packaging.

 Great! Note I'm still sorting out getting admin rights on these
 packages myself, so that I can grant others access. If you're a
 proven packager, just use your proven packager rights for now,
 if not just get everything ready, do a commit, followed by:

 git format-patch HEAD~

 And then send me the resulting patch, and I'll apply it for now.
 If we go this route, please also let me know if I should apply
 this only to rawhide, or also to older releases (see below).


I'm no provenpackager, will send the patches for those later.


   Some packages of those need
  also to be put on par with recent packaging guidelines.

 Yes, cleaning up the specfiles would very much be welcome too.


Will send a separate patch for those components above. After that, maybe I
can ask request for commit on the other packages.


 Yes, more or less, mostly just look at the changelog and apply common
 sense,
 also depends on the package a bit, e.g. intel-gpu-tools is part of
 xorg-x11-drv-intel bumping the actual driver needs to be done somewhat
 carefully,
 but bumping the tools is more or less always safe, as they are not that
 important. twm also is probably best just kept fully up2date with upstream
 in F-21. lib... OTOH may cause breakage (they should not but you never
 know),
 etc.


I will not be touching the intel driver :)

All those libraries can be added to Upstream Tracker, I find it very handy.
I've requested some components already in the past and I find the service
very handy:

http://upstream-tracker.org/

Regards,
--Simone

-- 
You cannot discover new oceans unless you have the courage to lose sight of
the shore (R. W. Emerson).

http://xkcd.com/229/
http://negativo17.org/
-- 
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: EPEL guacd package broken

[Simone Caronni]

Hello,

I'm going to fix this ASAP. Had a busy week and catched up with mails just
now.
Please leave some karma feedback after testing.

BTW, this list is not the correct place to post this kind of requests,
please open a bug on the selected component.

Regards,
--Simone


On 9 October 2014 01:00, Konstantin Kozhin kkoz...@gmail.com wrote:

 Hi!

 I've found that I can't install guacd on CentOS 7 from Epel repo:

 Error: Package: 1:guacd-0.8.4-3.el7.x86_64 (epel)
 Requires: libguac(x86-64) = 0.8.4-3.el7
 Available: 1:libguac-0.8.4-3.el7.x86_64 (epel)
 libguac(x86-64) = 1:0.8.4-3.el7
 Error: Package: 1:guacd-0.8.4-3.el7.x86_64 (epel)
 Requires: libguac(x86-64) = 0.8.4-3.el7
 Installing: 1:libguac-0.8.4-3.el7.x86_64 (epel)
 libguac(x86-64) = 1:0.8.4-3.el7

 Tried this on a clean fresh installed system.

 Can anyone advice a solution for this?

 Thanks!


 --
 Best regards,
 Konstantin Kozhin

 ___
 epel-devel mailing list
 epel-devel@lists.fedoraproject.org
 https://admin.fedoraproject.org/mailman/listinfo/epel-devel




-- 
You cannot discover new oceans unless you have the courage to lose sight of
the shore (R. W. Emerson).

http://xkcd.com/229/
http://negativo17.org/
___
epel-devel mailing list
epel-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/epel-devel

Re: Samba as AD DC

[Simone Caronni]

Hello,

2014-09-07 14:58 GMT-03:00 Simo Sorce s...@redhat.com:

 On Sun, 2014-09-07 at 01:12 -0300, Sergio Belkin wrote:
  Is (Samba) Fedora 20 still not capable of being Active Directory Domain
  Controller?

 It is current, and Samba in F20 will never have the AD bits.
 Maybe F22, or perhaps even F21, the work to replace Heimdal with MIT is
 proceeding well enough.


if you're interested, I've written a blog post on how to enable Samba 4 AD
functionality on a Fedora / RHEL system. All the bits are there, you simply
need to rebuild the Samba package with domain controller support and create
a service file for it:

http://negativo17.org/samba-4-active-directory-with-bind-dlz-zones-dynamic-dns-updates-windows-static-rpc/

Of course this re-enables the bundled Heimdal Kerberos implementation, but
it's rock stable. Simo Sorce also promptly fixed an issue in the Kerberos
libraries after I wrote it (thanks again!):

http://negativo17.org/samba-4-active-directory-with-bind-dlz-zones-dynamic-dns-updates-windows-static-rpc-update/

I've had it running for the past year without issues.

Regards,
--Simone


-- 
You cannot discover new oceans unless you have the courage to lose sight of
the shore (R. W. Emerson).

The Stone Age came to an end not for a lack of stones; and the oil age will
end, but not for a lack of oil. (Ahmed Zaki Yamani, former Saudi Minister
of Oil)

http://xkcd.com/229/
http://negativo17.org/
-- 
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: FreeRDP bump in rawhide

[Simone Caronni]

On 23 June 2014 08:39, Simone Caronni negativ...@gmail.com wrote:

 I'm about to bump FreeRDP in Rawhide to the newly released version 1.2.0
 beta 1. This allows us to build Remmina that is currently FTBFS.

 Of all the packages that are using FreeRDP, only Weston is the one for
 which I don't have any commit access, so it needs to be rebuilt. I've
 tested a mock build of it on my system and it builds fine against it (only
 tested that the package rebuilds fine).


This has now happened for both F21 and rawhide, sorry for the delay.

Regards,
--Simone

-- 
You cannot discover new oceans unless you have the courage to lose sight of
the shore (R. W. Emerson).

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

Looking for co-maintainers

[Simone Caronni]

Hello,

I'm looking for co-maintainers for the Guacamole [1] stack packages. It is
an HTML 5 plugin-less remote desktop for VNC, RDP, SSH, Telnet and Spice
(WIP). Upstream is really responsive, software is updated frequently and
it's really amazing.

I've been able to throw a bunch of Citrix XenApp servers, Terminal servers
and all the corollary tools away with it.

The software is split in the native server (guacamole-server) with relevant
plugins and a Java web application (guacamole-client) for the main
interface.

The software is fantastic, but the Java part gives me a lof of headaches
everytime there is a Java packaging guidelines change or a Maven bug. If
any Java guru would like to step in as co-maintainer of Guacamole it's
really welcome.

Currently guacamole-client is in FTBFS in rawhide [2] and I couldn't find
any help for fixing it due to a Maven bug [3], that requires a specific
Fedora workaround that I frankly don't understand [4]. On RHEL 7, and
Fedora 19/20 the same packages build fine.

[1] http://guac-dev.org/
[2] https://bugzilla.redhat.com/show_bug.cgi?id=1106740
[3] http://jira.codehaus.org/browse/MSHARED-325
[4]
https://lists.fedoraproject.org/pipermail/java-devel/2014-June/005273.html

I would like to fix it before the Alpha freeze, as there are a lot of users
out there using the stack with RHEL/Fedora.

Thanks  regards,
--Simone



-- 
You cannot discover new oceans unless you have the courage to lose sight of
the shore (R. W. Emerson).

http://xkcd.com/229/
http://negativo17.org/
-- 
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: Looking for co-maintainers

[Simone Caronni]

Hello,

On 27 June 2014 12:52, Mikolaj Izdebski mizde...@redhat.com wrote:
Currently guacamole-client is in FTBFS in rawhide [2] and I couldn't find

  any help for fixing it due to a Maven bug [3], that requires a specific
  Fedora workaround that I frankly don't understand [4]. On RHEL 7, and
  Fedora 19/20 the same packages build fine.

 I told you what to do on the mailing list. I've just tried the
 workaround and it worked.


Well, the problem is that I did not figure out what I had to do, and my
fix was not working because it was totally different than what you just
pushed :)

It's my mistake that I didn't reply to your second email, I probably
 missed it or forgot.  In this case please just ping me, I'm always happy
 to help!


No problem, thank you very much!

Still looking for co-maintainers, if anyone volounteers.

Thanks  regards,
--Simone


-- 
You cannot discover new oceans unless you have the courage to lose sight of
the shore (R. W. Emerson).

http://xkcd.com/229/
http://negativo17.org/
-- 
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: Patches for trivial bugs sitting in bugzilla - trivial patch policy?

[Simone Caronni]

+1 from me!
On Jun 26, 2014 5:51 PM, Sandro Mani manisan...@gmail.com wrote:

 Hi,

 From time to time, I see trivial patches posted in bugzilla which end up
 sitting there because the maintainer is too busy / gets bombarded with tons
 of bugzilla mails and misses that particular one / whatever reason. As a
 packager, sometimes it seems very hard to get such trivial patches applied.
 What you can do is

 - You can keep pinging bugzilla
 - You can apply for commit rights, which might be excessive for just this
 one patch, and still requires the maintainer to answer.
 - You can start the non-responsive maintainer procedure, even if you know
 perfectly well that the maintainer is still active. Or you might suspect
 that the maintainer is inactive, but you'd rather not have to wait for an
 entire month, because this one bug is blocking your work.
 - You can start asking on irc for a proven packager to jump in and hope a
 proven packager is online and has time at that moment.
 - You can post on -devel, though again, unless someone has time right now
 it gets forgotten an people move on.
 - Repeat the above n times until someone shouts at you and flags your
 email as spam :)

 So wondering, if there is a way we can improve the situation. One idea
 which comes to mind would be something like trivial patch policy
 - after i.e. one week of inactivity one can flag such a bug as a trivial
 bug. You can only do so if you are a packager and post a patch (which also
 updates the SPEC, so just a matter of apply patch, fedpkg commit  build).
 - for anything else than packaging issues, the patch may only be a well
 justified upstream commit backport
 - a proven packagers gets notified about the issue, validates the patch
 and if ok fires the update. The entire thing might work similar to how a
 New Package / Package Change request works, by posting something like this
 to the bug:
   Trivial Patch Request
   =
   Patch[branch]:
   Patch[other_branch]:
   Reason:
   Upstream commit:
   Submitter:


 From my experience such situations do not occur too frequently, but when
 they happen, they can be hard to deal with.

 Comments?

 Thanks,
 Sandro

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

FreeRDP bump in rawhide

[Simone Caronni]

Hello,

I'm about to bump FreeRDP in Rawhide to the newly released version 1.2.0
beta 1. This allows us to build Remmina that is currently FTBFS.

Of all the packages that are using FreeRDP, only Weston is the one for
which I don't have any commit access, so it needs to be rebuilt. I've
tested a mock build of it on my system and it builds fine against it (only
tested that the package rebuilds fine).

The libwinpr subpackage has underwent a major restructuring and now
provides its separate set of CMake / include files so it has been changed
accordingly, but as far as I know nothing else except FreeRDP itself is
using it.

Regards,
--Simone

-- 
You cannot discover new oceans unless you have the courage to lose sight of
the shore (R. W. Emerson).

http://xkcd.com/229/
http://negativo17.org/
-- 
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: EPEL quick epel7 update

[Simone Caronni]

Hello,

thanks for your answers.

On 17 June 2014 00:59, Jim Perrin jper...@centos.org wrote:

  By using CentOS as the basis and not RHEL 7 we could have all the
 channels
  that are not used at the moment for building.


 As much as I'd like to see CentOS as the basis for *everything* (I may
 be a bit biased here), I don't think this is a good idea.

 RHEL packages by their very nature will come out first. This puts EPEL
 in a position to work with them immediately, and to remain impartial
 across the rebuilding community (springdale/puias, centos, SL, that
 database company, etc). If CentOS lags behind for some unforseen reason,
 why put everyone else out until we get our act together? Same with every
 other rebuild. We know RHEL packages will be out on time every time
 because they're the ones delivering them.



Aren't we already using CentOS for EPEL 5 and 6 in the koji/mock
buildroots? 32 bit aside, what is the difference for 7?
This has been dealt nicely so far.


 To me, the only current time it would make sense for CentOS to be the
 base repo would be for something RHEL doesn't ship, such as x86 or other
 arch.


Considering we had CentOS in the buildroots, how have updates been managed
up to now? From my experience I can see CentOS package updates come almost
immediately after RHEL ones.

Regards,
--Simone

-- 
You cannot discover new oceans unless you have the courage to lose sight of
the shore (R. W. Emerson).

http://xkcd.com/229/
http://negativo17.org/
___
epel-devel mailing list
epel-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/epel-devel

Re: EPEL quick epel7 update

[Simone Caronni]

On 17 June 2014 16:07, Jeff Sheltren j...@tag1consulting.com wrote:

 On Tue, Jun 17, 2014 at 12:23 AM, Simone Caronni negativ...@gmail.com
 wrote:



 Aren't we already using CentOS for EPEL 5 and 6 in the koji/mock
 buildroots? 32 bit aside, what is the difference for 7?
 This has been dealt nicely so far.


 No, EPEL has always used RHEL for builds.


Mock is using CentOS:

$ pwd
/var/cache/mock/epel-6-x86_64/yum_cache/updates/packages
$ ls -al *centos*
-rw-rw-r--. 1 root mock  20960 May 20 15:33
centos-release-6-5.el6.centos.11.2.x86_64.rpm
-rw-rw-r--. 1 root mock 962780 May 20 15:33
initscripts-9.03.40-2.el6.centos.1.x86_64.rpm
$ cat /etc/mock/epel-6-x86_64.cfg | grep -i centos
mirrorlist=http://mirrorlist.centos.org/?release=6arch=x86_64repo=os
mirrorlist=http://mirrorlist.centos.org/?release=6arch=x86_64repo=updates

Don't know for Koji, but probably it's the same. No?

--Simone

-- 
You cannot discover new oceans unless you have the courage to lose sight of
the shore (R. W. Emerson).

http://xkcd.com/229/
http://negativo17.org/
___
epel-devel mailing list
epel-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/epel-devel

Re: rfc: xserver rebase in F20 (was Re: Slipping F21)

[Simone Caronni]

Hello,

On 11 June 2014 19:11, Sérgio Basto ser...@serjux.com wrote:

   Hi, why not begin by a xserver rebase in copr ?
 
  Personally, because I don't feel like doing the work twice.  But if
  someone else wants to, sure, go for it.

 I could do it, also think about do it for eclipse-swt , but my problem
 is I don't know what packages I have to update , is not just
 xorg-x11-server , have you a list what we should update for
 xorg-x11-server 15.x ?


Isn't this a rebuild already?

http://copr.fedoraproject.org/coprs/jujuxiii/testing-fc20/
http://copr-be.cloud.fedoraproject.org/results/jujuxiii/testing-fc20/fedora-20-x86_64/

Also, any chance to see this applied in the rebuild?

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

Thanks,
--Simone



-- 
You cannot discover new oceans unless you have the courage to lose sight of
the shore (R. W. Emerson).

http://xkcd.com/229/
http://negativo17.org/
-- 
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: EPEL Maintaining libntlm for ppc64

[Simone Caronni]

On 4 June 2014 18:18, Till Maas opensou...@till.name wrote:

 On Wed, Jun 04, 2014 at 08:47:27AM -0600, Kevin Fenzi wrote:

  We might want to hold off on limited arch packages until rhel7 is
  actually released... since we don't really know whats in the final set
  until it's there.

 Unless RHEL will not publish packages with a lower EVR than before, it
 is easy to go on, because the EPEL package can either be retired or its
 version/release can be bumped.


+1

Yesterday I requested libvncserver for ppc64:

http://koji.fedoraproject.org/koji/buildinfo?buildID=521113

Regards,
--Simone


-- 
You cannot discover new oceans unless you have the courage to lose sight of
the shore (R. W. Emerson).

http://xkcd.com/229/
http://negativo17.org/
___
epel-devel mailing list
epel-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/epel-devel

Re: EPEL RHEL 7 Workstation optional channel in Fedora's Koji

[Simone Caronni]

On 2 June 2014 16:46, T.C. Hollingsworth tchollingswo...@gmail.com wrote:

 On Mon, Jun 2, 2014 at 1:59 AM, Simone Caronni negativ...@gmail.com
 wrote:
  Hello,
 
  I was looking to build a package on epel7 that is relying on
 jansson-devel.
 
  The -devel subpackage is generated as normally from the main jansson
  package, but in case of epel7 the resulting rpm is included in the
  Workstation-optional channel:
 
 
 http://ftp.redhat.com/redhat/rhel/rc/7/Workstation-optional/x86_64/os/Packages/
 
  Have these packages being left out intentionally or not?
  Is there any chance to see these packages added in Koji? Otherwise
 building
  for epel7 can get really complicated.

 I'd suggest filing a bug in bugzilla first, explaining the pain this
 causes downstream addon repositories like EPEL.  For all we know the
 -devel subpackage is only missing in Server due to some oversight.


Opened this one, hope it's correct:

https://fedorahosted.org/rel-eng/ticket/5915

Thanks  regards,
--Simone




-- 
You cannot discover new oceans unless you have the courage to lose sight of
the shore (R. W. Emerson).

http://xkcd.com/229/
http://negativo17.org/
___
epel-devel mailing list
epel-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/epel-devel

Re: EPEL RHEL 7 Workstation optional channel in Fedora's Koji

[Simone Caronni]

On 3 June 2014 11:29, T.C. Hollingsworth tchollingswo...@gmail.com wrote:

 You can file a bug with RHEL rel-eng here:

 https://bugzilla.redhat.com/enter_bug.cgi?product=Red%20Hat%20Enterprise%20Linux%207component=relengversion=7.0

 Of course, supporting Workstation in general would be very nice, so
 your other ticket is warranted, but I think getting this particular
 problem fixed on the RHEL side would still be a good idea regardless
 of the outcome of that.


Bug filed with an edited text from the releng one.

Regards,
--Simone

-- 
You cannot discover new oceans unless you have the courage to lose sight of
the shore (R. W. Emerson).

http://xkcd.com/229/
http://negativo17.org/
___
epel-devel mailing list
epel-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/epel-devel

EPEL RHEL 7 Workstation optional channel in Fedora's Koji

[Simone Caronni]

Hello,

I was looking to build a package on epel7 that is relying on jansson-devel.

The -devel subpackage is generated as normally from the main jansson
package, but in case of epel7 the resulting rpm is included in the
Workstation-optional channel:

http://ftp.redhat.com/redhat/rhel/rc/7/Workstation-optional/x86_64/os/Packages/

Have these packages being left out intentionally or not?
Is there any chance to see these packages added in Koji? Otherwise building
for epel7 can get really complicated.

Thanks  regards,
--Simone


-- 
You cannot discover new oceans unless you have the courage to lose sight of
the shore (R. W. Emerson).

http://xkcd.com/229/
http://negativo17.org/
___
epel-devel mailing list
epel-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/epel-devel

Re: EPEL RHEL 7 Workstation optional channel in Fedora's Koji

[Simone Caronni]

On 2 June 2014 11:04, Dan Horák d...@danny.cz wrote:

 EPEL builds against the Server + Server-optional variant of RHEL -
 http://koji.fedoraproject.org/koji/taginfo?tagID=258


Is this the final setup of EPEL for RHEL 7 that will be available for all
the time the distribution is supported by Redhat?

Thanks,
--Simone

-- 
You cannot discover new oceans unless you have the courage to lose sight of
the shore (R. W. Emerson).

http://xkcd.com/229/
http://negativo17.org/
___
epel-devel mailing list
epel-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/epel-devel

Re: EPEL RHEL 7 Workstation optional channel in Fedora's Koji

[Simone Caronni]

On 2 June 2014 11:09, Simone Caronni negativ...@gmail.com wrote:

 On 2 June 2014 11:04, Dan Horák d...@danny.cz wrote:

 EPEL builds against the Server + Server-optional variant of RHEL -
 http://koji.fedoraproject.org/koji/taginfo?tagID=258


 Is this the final setup of EPEL for RHEL 7 that will be available for
 all the time the distribution is supported by Redhat?


It is quite strange actually. Normally, if a package is not included in the
base distribution, we can add it. If it is already included we never
replace the upstream package.

By using only server and server-optional we have the weird case where only
half of the package can be used. Jansson specific, I cannot add jansson to
epel because it is already included, but I cannot use it because the
jansson-devel is omitted and only half of the resulting binary rpms are
used.

I hope this gets reviewed in the future.

--Simone



-- 
You cannot discover new oceans unless you have the courage to lose sight of
the shore (R. W. Emerson).

http://xkcd.com/229/
http://negativo17.org/
___
epel-devel mailing list
epel-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/epel-devel

Fedora GIT error (access denied)

[Simone Caronni]

Hello,

I'm unable to commit to the newly unretired ndoutils package in the fedora
branches (I'm the owner). This is the error I get:

$ git push
Counting objects: 10, done.
Delta compression using up to 4 threads.
Compressing objects: 100% (2/2), done.
Writing objects: 100% (2/2), 270 bytes | 0 bytes/s, done.
Total 2 (delta 1), reused 0 (delta 0)
remote: W refs/heads/master ndoutils slaanesh DENIED by fallthru
remote: error: hook declined to update refs/heads/master
To ssh://slaan...@pkgs.fedoraproject.org/ndoutils
 ! [remote rejected] master - master (hook declined)
error: failed to push some refs to 'ssh://
slaan...@pkgs.fedoraproject.org/ndoutils'

Was also happening immediately after receiving the email that the GIT
request was processed, but I wanted to see if it was just temporary.

If this is not the place for notifying such things, please redirect me
where appropriate.

Thanks  regards,
--Simone


-- 
You cannot discover new oceans unless you have the courage to lose sight of
the shore (R. W. Emerson).

http://xkcd.com/229/
http://negativo17.org/
-- 
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 GIT error (access denied)

[Simone Caronni]

On 27 May 2014 15:31, Kevin Fenzi ke...@scrye.com wrote:

 On Tue, 27 May 2014 09:05:21 +0200
 Simone Caronni negativ...@gmail.com wrote:
  If this is not the place for notifying such things, please redirect me
  where appropriate.

 Usually a releng or infrastructure ticket or #fedora-admin /
 #fedora-releng on irc. ;)


Thanks, will do next time.
I filed a ticket anyway on infrastructure as I also have issues building
(tasks exit after assembling src.rpm).

Regards,
--Simone


-- 
You cannot discover new oceans unless you have the courage to lose sight of
the shore (R. W. Emerson).

http://xkcd.com/229/
http://negativo17.org/
-- 
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: F21 System Wide Change: Workstation: Disable firewall

[Simone Caronni]

On 15 April 2014 14:35, Christopher ctubb...@apache.org wrote:

 Whoa, the fact that the Firewall is on by default in Fedora (along
 with SELinux) is one of the reasons I choose Fedora over alternatives.


Same thing here, It was really surprising to see it as a proposed feature.
How can it be that after years we are disabling the firewall by default?
I personally find it a big, big step backwards.

Instead of disabiling it, wouldn't be a better approach to have a more
relaxed firewall policy for the workstation product that opens the
additional ports for DAAP, UPnp, etc.?

Regards,
--Simone


-- 
You cannot discover new oceans unless you have the courage to lose sight of
the shore (R. W. Emerson).

http://xkcd.com/229/
http://negativo17.org/
-- 
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: bumblebee reviewer needed (Was: Re: Heads up: retiring xorg-x11-drv-mouse and xorg-x11-drv-keyboard)

[Simone Caronni]

On 3 April 2014 06:50, Christopher Meng cicku...@gmail.com wrote:

 Just another note that due to my knowledge on optimus I decide to drop
 the review of bumblebee[1], and someone told me it's just a dirty
 hack.


I personally think it as a hack as well.
Problems with Nouveau performance and power managment aside, current Prime
with open drivers is a much better and elegant solution.

Regards,
--Simone


-- 
You cannot discover new oceans unless you have the courage to lose sight of
the shore (R. W. Emerson).

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

EPEL texlive in 7

[Simone Caronni]

Hello,

is there any plan to have texlive in EPEL 7?

I need it but wouldn't dare asking for the branch myself... looks
complicated and I don't have any direct experience with it.

Thanks  regards,
--Simone

-- 
You cannot discover new oceans unless you have the courage to lose sight of
the shore (R. W. Emerson).

http://xkcd.com/229/
http://negativo17.org/
___
epel-devel mailing list
epel-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/epel-devel

Re: EPEL texlive in 7

[Simone Caronni]

On 1 April 2014 12:58, Susi Lehtola jussileht...@fedoraproject.org wrote:

 Uhm, so this is just about a virtual Provides?

 TeXLive *does* have latex. Just install texlive-latex.


Ok, I confirm is related to the texlive version in RHEL 7.
I reworked all the BuildRequires in the SPEC file with the new texlive
syntax (i.e. tex(xcolor.sty)) but the RHEL 7 packages do not contain all
the required files; I'm missing tex(keyva.sty).

Regards,
--Simone

-- 
You cannot discover new oceans unless you have the courage to lose sight of
the shore (R. W. Emerson).

http://xkcd.com/229/
http://negativo17.org/
___
epel-devel mailing list
epel-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/epel-devel

Re: EPEL texlive in 7

[Simone Caronni]

On 1 April 2014 13:55, Simone Caronni negativ...@gmail.com wrote:

 On 1 April 2014 12:58, Susi Lehtola jussileht...@fedoraproject.orgwrote:

 Uhm, so this is just about a virtual Provides?

 TeXLive *does* have latex. Just install texlive-latex.


 Ok, I confirm is related to the texlive version in RHEL 7.
 I reworked all the BuildRequires in the SPEC file with the new texlive
 syntax (i.e. tex(xcolor.sty)) but the RHEL 7 packages do not contain all
 the required files; I'm missing tex(keyva.sty).


keyval.sty, not keyva.sty damn typo.
Ok, it's now working, I simply had to adjust the spec file to two separate
build requirements, one for Fedora and RHEL 7 with the new texlive syntax,
one with RHEL 5/ that simply requires tetex/tetex-latex.

Regards,
--Simone


-- 
You cannot discover new oceans unless you have the courage to lose sight of
the shore (R. W. Emerson).

http://xkcd.com/229/
http://negativo17.org/
___
epel-devel mailing list
epel-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/epel-devel

EPEL 7 i686 libraries

[Simone Caronni]

Hello,

maybe I missed this, but I would like to know what's the status of EPEL 7
32 bit (i686) support.
I see that in Koji all libraries are x86_64 or ppc64. Shouldn't we have
i686 libraries as well, much like in Fedora?

Also considering that the system itself has many 32 bit libraries:

https://fedoraproject.org/wiki/EPEL/epel7

Thanks  regards,
--Simone

-- 
You cannot discover new oceans unless you have the courage to lose sight of
the shore (R. W. Emerson).

http://xkcd.com/229/
http://negativo17.org/
___
epel-devel mailing list
epel-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/epel-devel

Re: Retired update still showing in updates-testing

[Simone Caronni]

On 14 March 2014 00:00, Jon jdisn...@gmail.com wrote:

 Done!

 $ koji untag-build --force f19-updates-testing
 guacamole-client-0.8.3-5.fc19
 $ koji untag-build --force f20-updates-testing
 guacamole-client-0.8.3-5.fc20


Thanks,
--Simone


-- 
You cannot discover new oceans unless you have the courage to lose sight of
the shore (R. W. Emerson).

http://xkcd.com/229/
http://negativo17.org/
-- 
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: Retired update still showing in updates-testing

[Simone Caronni]

On 13 March 2014 20:01, Rex Dieter rdie...@math.unl.edu wrote:

 Did you delete the bodhi updates too?  If so, (in short), don't do that.


To tell the truth I don't remember, but I think I did.

So updates that are retired should be left as they are without deleting
them so they still appear listed in Bodhi? Is this the intended procedure?
What is the purpose of the delete button?

Thanks  regards,
--Simone



-- 
You cannot discover new oceans unless you have the courage to lose sight of
the shore (R. W. Emerson).

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

Retired update still showing in updates-testing

[Simone Caronni]

Hello,

I pushed two packages as updates in bodhi a few weeks ago, but even before
they reached updates-testing I revoked them.

Now, after some weeks, I see that both are available from updates-testing
but I don't see them in Bodhi. They are not in my list of updates or the
generic updates-testing queue. It seems they have been removed from Bodhi
but somehow they reached the repository anyway.

The packages are these two:

guacamole-client-0.8.3-5.fc20
guacamole-client-0.8.3-5.fc19

Can someone explain what has happened? Should I file a ticket somewhere?

Thanks,
--Simone



-- 
You cannot discover new oceans unless you have the courage to lose sight of
the shore (R. W. Emerson).

http://xkcd.com/229/
http://negativo17.org/
-- 
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: Retired update still showing in updates-testing

[Simone Caronni]

On 13 March 2014 09:33, Mathieu Bridon boche...@fedoraproject.org wrote:

 The solution is for you to untag the builds:

 $ koji untag-pkg f19-updates-testing guacamole-client-0.8.3-5.fc19
 $ koji untag-pkg f20-updates-testing guacamole-client-0.8.3-5.fc20

 Then at the next mash, they will be gone.

 I have no idea why they are still tagged, though. Maybe you removed the
 updates while the builds were being pushed, which tends to trip Bodhi
 up.

 Or maybe you hit a Bodhi bug.


Thanks, I've already tried it but I can't tag/untag packages in Bodhi:

$ koji untag-pkg f19-updates-testing guacamole-client-0.8.3-5.fc19
ActionNotAllowed: tag requires admin permission

I think some admin intervention is needed.

Regards,
--Simone



-- 
You cannot discover new oceans unless you have the courage to lose sight of
the shore (R. W. Emerson).

http://xkcd.com/229/
http://negativo17.org/
-- 
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: Orphaning simple scan

[Simone Caronni]

Hello,

On 9 March 2014 13:34, David King amigad...@amigadave.com wrote:

 I would like to be a co-maintainer, as I use Simple Scan on a regular
 basis, and as a GNOME contributor I am also familiar with the GNOME
 schedule that Kalev mentioned.

 I have requested commit privileges in pkgdb.


permissions granted. Actually we've been updating the package at the same
time :)

Mind if I also make some cosmetic changes to the spec file? Formatting,
removal of the Group tag, etc.?

Thanks,
--Simone


-- 
You cannot discover new oceans unless you have the courage to lose sight of
the shore (R. W. Emerson).

http://xkcd.com/229/
http://negativo17.org/
-- 
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: Orphaning simple scan

[Simone Caronni]

On 8 March 2014 18:24, Rahul Sundaram methe...@gmail.com wrote:

 I don't have direct access to a personal scanner anymore and don't have
 the time to handle bug reports without a device to test.   I have orphaned
 simple scan now.  Please feel free to take it.


Thanks for maintaining this so far, I've taken it as I use it every once in
a while.

Co-maintainers welcome.

Regards,
--Simone

-- 
You cannot discover new oceans unless you have the courage to lose sight of
the shore (R. W. Emerson).

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

EPEL Updating NDOUtils to 1.5.2

[Simone Caronni]

Hello,

I would like to update the current NDOUtils 1.4b9 (2009-10-27) to the
latest 1.5.2 (2012-06-08) in both epel 5 and 6.

The former maintainer was not using the package, no one volunteered for it
so it was retired in Fedora in 2012. As it could not be retired from
released branches, this is the reason why we still have the package in
epel5/epel6.

I have the updated 1.5.2 packages in production on RHEL systems, there is
no change required for updating (database schema, etc. are all the same as
in 1.4b9) so the package could be considered a safe upgrade (only the
binary is different).

Here is the changelog for 1.5.2:

http://sourceforge.net/p/nagios/ndoutils/ci/master/tree/Changelog

Here are el5 and el6 builds; If I don't hear any comment about it I will
push the update in Bodhi next week:

http://koji.fedoraproject.org/koji/taskinfo?taskID=6579973
http://koji.fedoraproject.org/koji/taskinfo?taskID=6579986

If anyone volunteers (taking any review in return), here is the re-review
for adding back the package in Fedora:

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

Thanks,
--Simone


-- 
You cannot discover new oceans unless you have the courage to lose sight of
the shore (R. W. Emerson).

http://xkcd.com/229/
http://negativo17.org/
___
epel-devel mailing list
epel-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/epel-devel

Unretiring NDOUtils

[Simone Caronni]

Hello,

I would like to unretire NDOUtils in Fedora, I'm currently using it at work.

NDOUtils was orphaned in Fedora in 2012 [1], but since the EPEL 5  6
branches cannot be retired, those branches were still there. The previous
owner gave the branch ownership to me, so I'm missing only the Fedora
branches.

Following the procedure for unretiring packages [2] I've created a review
for the package:

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

Thanks  regards,
--Simone

[1]
https://lists.fedoraproject.org/pipermail/devel/2012-February/162171.html
[2]
https://fedoraproject.org/wiki/Orphaned_package_that_need_new_maintainers

https://lists.fedoraproject.org/pipermail/devel/2012-February/162171.html


-- 
You cannot discover new oceans unless you have the courage to lose sight of
the shore (R. W. Emerson).

http://xkcd.com/229/
http://negativo17.org/
-- 
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: libxnvctrl status?

[Simone Caronni]

On 4 February 2014 11:03, Ralf Corsepius rc040...@freenet.de wrote:

 Correct, we could - Similar things are being done at several places in
 Fedora.

 Somewhat oversimplified, the basic requirement is all shipped binaries
 must be built from OSI-compiliant sources-code and no closed-sources be
 used.


Well, the tools are totally opensource and can be built standalone,
libXNVCtrl will interface with the Nvidia X.org driver; but what is the
benefit of having them in Fedora if they can't be used without the
proprietary blobs?
Currently there's a policy that game engines cannot be shipped in Fedora if
the content is not free as well; shouldn't the policy be the same (i.e.
allow the engines without content or remove the tools as well)?

Thanks,
--Simone


-- 
You cannot discover new oceans unless you have the courage to lose sight of
the shore (R. W. Emerson).

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

Retiring mod_auth_xradius

[Simone Caronni]

Hello,

I'm planning to retire mod_auth_xradius from Fedora.

The module in its source form is really buggy:

- It has been patched to avoid a library bundling.
- Some patches have been added to restore some basic functionality that was
not otherwise working.
- Upstream asked me to update and file bugs but nothing happened and it's
effectively dead (last update in 2006!).
- Does not work with Apache 2.4.

Mantaining it would effectively mean forking it, so unless someone is
willing to step in as a mantainer also for a new upstream I'm going to
retire it.

Considering that Fedora ships Apache 2.4 in all recent releases and the
module does not work with it, my guess is there is no userbase for it at
all.

Having said that, the module works fine in EPEL 5/6 with Apache 2.2 (I use
it in production) and I have no plan to retire it from these branches.

Thanks  regards,
--Simone



-- 
You cannot discover new oceans unless you have the courage to lose sight of
the shore (R. W. Emerson).

http://xkcd.com/229/
http://negativo17.org/
-- 
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: libxnvctrl status?

[Simone Caronni]

Hello,

On 4 February 2014 04:58, Christopher Meng cicku...@gmail.com wrote:

 Is this library disallowed now because it's from nvidia? Or it should be
 retired?


In my opinion it should be removed from Fedora. Currently it is used by
very few packages:

mate-sensors-applet
hwloc
nvclock
oyranos

The current 169.12 library works only with very old GeForce 5/6 class
hardware [1]; and the main consumer is nvclock. Its functionality has been
integrated in the main nvidia-settings control panel, upstream is dead and
there's no way to make it work on recent hardware. On my (old) system it
just crashes with proprietary or open source drivers.

The source code comes from the nvidia-settings tarball; and following the
same logic we should allow all the relevant open source components of the
Nvidia driver [2] in Fedora, that is:

nvidia-settings
nvidia-xconfig
nvidia-persistenced

Considering this is nonsense advertising of proprietary software and in the
end is totally useless (as the most useful parts of the driver are closed
source) it should be removed entirely from the distribution. Nvidia is also
planning to split libXNVCtrl out of nvidia-settings [3], but again, when
installing proprietary drivers it will be overwritten anyway, making it
again really useless to keep.

Should I file an FPC bug for asking removal of it?

Regards,
--Simone

[1] http://www.nvidia.com/Download/driverResults.aspx/71302/en-us
[2] https://github.com/NVIDIA/
[3] https://github.com/NVIDIA/nvidia-settings/pull/1


-- 
You cannot discover new oceans unless you have the courage to lose sight of
the shore (R. W. Emerson).

http://xkcd.com/229/
http://negativo17.org/
-- 
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: Source file audit - 2014-01-05

[Simone Caronni]

On 7 January 2014 19:31, Toshio Kuratomi a.bad...@gmail.com wrote:

 Looking at the lookaside cache directly, it looks like that file has been
 uploaded previously (in lookaside, there's currently two tarballs for
 dkms-2.2.0.3.tar.gz with two separate md5sums).


Thanks, who was mantaining it before me uploaded both tarballs on the same
day, without updating the source file on the second upload.
Fixed in git.

Thanks  regards,
--Simone

-- 
You cannot discover new oceans unless you have the courage to lose sight of
the shore (R. W. Emerson).

http://xkcd.com/229/
http://negativo17.org/
-- 
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: Source file audit - 2014-01-05

[Simone Caronni]

On 6 January 2014 20:53, Kevin Fenzi ke...@scrye.com wrote:

 slaanesh:BADSOURCE:dkms-2.2.0.3.tar.gz:dkms


Downloading the file again gives a different md5sum, but the release
tarball is the same, so probably the archive has been regenerated.

What's the procedure to update the source files in the lookaside cache when
the file name has not changed? fedpkg new-sources does not allow me to do
it:

$ fedpkg new-sources dkms-2.2.0.3.tar.gz
Uploading: 11a8aaade2ebec2803653837c7593030  dkms-2.2.0.3.tar.gz
File already uploaded: dkms-2.2.0.3.tar.gz
Uploaded and added to .gitignore:
Source upload succeeded. Don't forget to commit the sources file

Thanks  regards,
--Simone


-- 
You cannot discover new oceans unless you have the courage to lose sight of
the shore (R. W. Emerson).

http://xkcd.com/229/
http://negativo17.org/
-- 
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: Retiring gksu-polkit

[Simone Caronni]

On 5 December 2013 00:26, Dan Mashal dan.mas...@gmail.com wrote:

 It seems that this package is no longer needed. Please let me know
 there is a reason that we should keep it. Will retire on all Fedora
 releases next week.


I think it's still used by Wireshark; last time I've build it was to close
some bugs upon request of Wireshark mantainers; but I don't know if it's
still the case.
The project is abandoned upstream, so +1 for me.

Thanks,
--Simone

-- 
You cannot discover new oceans unless you have the courage to lose sight of
the shore (R. W. Emerson).

http://xkcd.com/229/
http://negativo17.org/
-- 
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: F21 Self Contained Change: Replace Bacula with Bareos

[Simone Caronni]

Hello,

On 16 November 2013 02:09, Kevin Kofler kevin.kof...@chello.at wrote:

 Simone Caronni wrote:
  Bareos is currently in standby following some legal issues:
 
  https://fedoraproject.org/wiki/Forbidden_items#Bareos

 Can we know what the issues are? Switching would look like a no-brainer
 (old
 unmaintained crippleware vs. new community fork), but of course, if there
 are legal issues with the fork… :-(


sorry for the delay, but some news have been posted today regarding this
issue:

http://www.mail-archive.com/bacula-users@lists.sourceforge.net/msg57308.html
https://www.bareos.org/en/faq/items/copyright_bacula_bareos.html

Regards,
--Simone


-- 
You cannot discover new oceans unless you have the courage to lose sight of
the shore (R. W. Emerson).

http://xkcd.com/229/
http://negativo17.org/
-- 
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: Enabling -Werror=format-security by default

[Simone Caronni]

On 20 November 2013 17:25, Kevin Fenzi ke...@scrye.com wrote:

 First... I'd suggest posting the list of packages and give maintainers
 a week or two to just fix them. Then before filing anything you can run
 a quick check to see which packages are still needing fixing.


Yes please, sometimes the automated bug reports are a bit confusing and/or
misleading.

Thanks,
--Simone


-- 
You cannot discover new oceans unless you have the courage to lose sight of
the shore (R. W. Emerson).

http://xkcd.com/229/
http://negativo17.org/
-- 
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: F21 Self Contained Change: Replace Bacula with Bareos

[Simone Caronni]

Hello,

Bareos is currently in standby following some legal issues:

https://fedoraproject.org/wiki/Forbidden_items#Bareos

It was added to the Forbidden Items list after I wrote the feature page.
Until those are solved, the feature can't simply happen.

Regards,
--Simone





On 15 November 2013 13:03, Jaroslav Reznik jrez...@redhat.com wrote:

 = Proposed Self Contained Change: Replace Bacula with Bareos =
 https://fedoraproject.org/wiki/Changes/Bareos

 Change Owner(s): Simone Caronni negativo17 at gmail.com

 The powerful Bacula network backup solution has switched from being Open
 Source friendly to being almost closed source. Originally the project was
 conceived totally as Open Source, but since the creation of Bacula Systems
 and
 its proprietary Bacula Enterprise Edition product, the Open Source (now
 called
 Community Edition) has received less and less updates and is mostly
 abandoned.

 == Detailed description ==
 The most important points that are left abandoned are the following:

 * Installation scripts and updates to makefiles are not updated anymore.
 * New plugins and functionalities are not added anymore, except those in
 the
 core daemons.
 * Gaphical (and buggy) console has not received any update in almost two
 years.
 * Patches and bugs opened in the bug tracker are mostly left abandoned.
 Even
 trivial fixes are not imported in the source.
 * Windows binaries are no longer provided, nor the source for the clients
 has
 been updated. Even if compiled with difficulties, there is no support for
 recent
 Windows versions.

 A former Bacula developer, frustrated by the situation created the fork
 Bareos
 a long time ago from Bacula 5.2.x (the current Fedora and RHEL 7 version).
 This version has now received '''a lot of bugfixes''' compared to the
 original
 Bacula source. This makes compilation and installation a lot easier than it
 was with Bacula.

 On top of this, a '''lot of new features''' have been added; some unique to
 Bareos but many available only in the closed source Bacula Enterprise.

 Here is the list of new features compared to the current Bacula 5.2.13:

 * http://www.bareos.org/en/whats_new.html

 Some highlights include NDMP support for enterprise class storage (NetApp,
 etc.), support for enterprise class tape libraries and Windows support
 (including Windows Server 2012) with Bareos generated binaries.

 For further details on why a Bacula fork was created please look at the
 following links:

 * http://www.bareos.org/en/faq/items/why_fork.html

 Bareos can also be '''fully compatible with Bacula''' by setting a specific
 configuration directive in the Daemon configuration files; thus providing
 the
 option for RHEL 6/7 users to interoperate with Fedora systems.

 * http://www.bareos.org/en/faq/items/bareos_bacula_compatibility.html

 == Scope ==
 To accomplish the goal, the following Bacula packages need to be replaced
 with
 Bareos equivalents:

  bacula
  bacula-docs

 Currently, the same Fedora packages can be rebuilt as they are, to work
 also
 on CentOS/RHEL 5 and 6, upgrading the EPEL or official Bacula packages in
 the
 distributions. This is to have a consistent backup infrastructure across
 all
 the Fedora/CentOS/RHEL ecosystem.

 To ease installation, a repository for installing those packages on a
 CentOS/RHEL system do exist:

 http://repos.fedorapeople.org/repos/slaanesh/bacula/README.txt

 The idea is the same for Bareos: import into Fedora 21 packages that can be
 rebuilt for all supported Fedora/RHEL/CentOS releases and provide a
 repository
 that can upgrade any Bacula release currently installed in the system with
 the
 new one. In detail; the upgrade scenarios supported when going from Bacula
 to
 Bareos would be:

 From Bacula 2.4:
 * RHEL/CentOS 5 with EPEL repository

 From Bacula 5.0:
 * RHEL/CentOS 6

 From Bacula 5.2.13:

 * Fedora 18+
 * RHEL/CentOS 5
 * RHEL/CentOS 6

 As written before, the change is impacting only Fedora 21, the list of
 upgrades supported are only for users who want a consistent backup solution
 across the enterprise.

 === External activities ===
 Proposal owners: I'm the current Bacula mantainer in Fedora and will
 complete
 the transition in time for the release.

 Other developers: N/A (not a System Wide Change)

 Release engineering: the release engineering team should make sure the new
 Bareos packages are in place instead of the current Bacula packages for the
 new release.

 Policies and guidelines: N/A (not a System Wide Change)
 ___
 devel-announce mailing list
 devel-annou...@lists.fedoraproject.org
 https://admin.fedoraproject.org/mailman/listinfo/devel-announce




-- 
You cannot discover new oceans unless you have the courage to lose sight of
the shore (R. W. Emerson).

http://xkcd.com/229/
http://negativo17.org/
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http

Re: What is support status of PowerVR GPUs in Fedora? (Intel D2500 and gma500_gfx)

[Simone Caronni]

On 14 November 2013 16:19, valent.turko...@gmail.com 
valent.turko...@gmail.com wrote:

 Here are all logs I captured:

 cpuinfo: http://pastebin.com/raw.php?i=7M7uKBA5
 lspci: http://pastebin.com/raw.php?i=2JFb3EnQ
 dmesg: http://pastebin.com/raw.php?i=8pQ5C8wJ
 Xorg.0.log.gma500: http://pastebin.com/raw.php?i=7L6n7QAc


Intel PowerVR poulsbo devices do not have a free driver; their
functionality is really limited and there's no DDX driver.

They're totalling different than normal Intel chips driven by the intel
driver; you have to use VESA for it in X.

Regards,
--Simone



-- 
You cannot discover new oceans unless you have the courage to lose sight of
the shore (R. W. Emerson).

http://xkcd.com/229/
http://negativo17.org/
-- 
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: User/Group ID assignment

[Simone Caronni]

Hello,

On 22 October 2013 13:25, Mateusz Marzantowicz mmarzantow...@osdf.com.plwrote:

 Are there any guidelines regarding user and group id number assignment
 on Fedora?


please read the packaging guidelines regarding user creation at rpm install
time:

http://fedoraproject.org/wiki/Packaging:UsersAndGroups

As a rule of thumb, your user must be dynamically allocated and not deleted
after rpm uninstallation.
If you need a static UID you need to open a ticket to FPC.

Details in the wiki page.

Regards,
--Simone


-- 
You cannot discover new oceans unless you have the courage to lose sight of
the shore (R. W. Emerson).

http://xkcd.com/229/
http://negativo17.org/
-- 
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: Source file audit - 2013-09-30

[Simone Caronni]

Check ok on my side:

$ wget http://linux.dell.com/dkms/permalink/dkms-2.2.0.3.tar.gz
--2013-10-04 08:54:36--
http://linux.dell.com/dkms/permalink/dkms-2.2.0.3.tar.gz
Resolving linux.dell.com (linux.dell.com)... 143.166.224.62
Connecting to linux.dell.com (linux.dell.com)|143.166.224.62|:80...
connected.
HTTP request sent, awaiting response... 200 OK
Length: 86053 (84K) [application/x-gzip]
Saving to: ‘dkms-2.2.0.3.tar.gz’

100%[==] 86,053  96.3KB/s   in
0.9s

2013-10-04 08:54:42 (96.3 KB/s) - ‘dkms-2.2.0.3.tar.gz’ saved [86053/86053]

Regards,
--Simone

-- 
You cannot discover new oceans unless you have the courage to lose sight of
the shore (R. W. Emerson).

http://xkcd.com/229/
http://negativo17.org/
-- 
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: Koji build fails because source package is not found.

[Simone Caronni]

Hello,

On 30 August 2013 09:05, Erwin Waterlander water...@xs4all.nl wrote:

 error: File /builddir/build/SOURCES/wcd-5.**2.4-src.tar.gz: No such file
 or directory

 What should I do to fix this error? I was in the assumption that the
 source package is automatically downloaded via the info in the spec file.


it is not. You have to issue fedpkg new-sources tarball.tar.gz in the git
repository after you have downloaded the source tarball.
This way it gets uploaded.

After uploading do a git commit to update the sources file.

Please see:

https://fedoraproject.org/wiki/Package_update_HOWTO
http://fedoraproject.org/wiki/Using_Fedora_GIT

Regards,
--Simone

-- 
You cannot discover new oceans unless you have the courage to lose sight of
the shore (R. W. Emerson).

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

Builds using latex2html gets stuck infinitely (#994883)

[Simone Caronni]

Hello,

can someone please check this latex2html bug [1]? I've reported it many
times on this list on a different thread but somehow it went unnoticed.

I know user jnovy has left Redhat, but the package is still owned by him
[2] and is blocking my builds since the beginning of August. Shouldn't the
package be orphaned?

Thanks,
--Simone

[1] https://bugzilla.redhat.com/show_bug.cgi?id=994883
[2] https://admin.fedoraproject.org/pkgdb/acls/name/latex2html



-- 
You cannot discover new oceans unless you have the courage to lose sight of
the shore (R. W. Emerson).

http://xkcd.com/229/
http://negativo17.org/
-- 
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: Problem with mass rebuild / latex2html errors

[Simone Caronni]

On 5 August 2013 12:14, Simone Caronni negativ...@gmail.com wrote:

 I have a problem on the bacula-docs package in Fedora 20. Build was stuck
 for 15 hours and then killed by Koji:

 http://koji.fedoraproject.org/koji/taskinfo?taskID=5698742

 I was able to reproduce it locally with mock; all the latex2html
 commands get stuck indefinitely.


[snip]


 The moment I stopped my mock build that was running for 3 minutes I
 already had an 18 mb file; 90% of it filled with dots in the last line.


I'm not still able to build in rawhide, I still get an infinite line of
dots from the latex2html command and builds get stuck in Koji (15 hiours
last time). Current stuck build is here:

https://koji.fedoraproject.org/koji/taskinfo?taskID=5792896

I'm opening a bug in a few minutes; if this is already a known issue please
let me know.

Thanks,
--Simone







-- 
You cannot discover new oceans unless you have the courage to lose sight of
the shore (R. W. Emerson).

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

Koji 404 errors on el6

[Simone Caronni]

Hello,

I get the following when building for el6/ppc:

DEBUG util.py:264:
http://kojipkgs.fedoraproject.org/repo/rhel/rhel-ppc64-server-6/getPackage/nss-softokn-3.12.9-11.el6.ppc64.rpm:
[Errno 14] PYCURL ERROR 22 - The requested URL returned error: 404
Not Found
DEBUG util.py:264:  Trying other mirror.
DEBUG util.py:264:
http://kojipkgs.fedoraproject.org/repo/rhel/rhel-ppc64-server-6/getPackage/nss-softokn-freebl-3.12.9-11.el6.ppc64.rpm:
[Errno 14] PYCURL ERROR 22 - The requested URL returned error: 404
Not Found
DEBUG util.py:264:  Trying other mirror.
DEBUG util.py:264:  Error Downloading Packages:
DEBUG util.py:264:nss-softokn-3.12.9-11.el6.ppc64: failed to
retrieve nss-softokn-3.12.9-11.el6.ppc64.rpm from build
DEBUG util.py:264:  error was [Errno 14] PYCURL ERROR 22 - The
requested URL returned error: 404 Not Found
DEBUG util.py:264:nss-softokn-freebl-3.12.9-11.el6.ppc64: failed
to retrieve nss-softokn-freebl-3.12.9-11.el6.ppc64.rpm from build
DEBUG util.py:264:  error was [Errno 14] PYCURL ERROR 22 - The
requested URL returned error: 404 Not Found
DEBUG util.py:354:  Child return code was: 1

I've already tried 2 builds and I got the same result. Full log here:

http://koji.fedoraproject.org/koji/getfile?taskID=5793165name=root.log

Should I just wait that this settles down on its own (updates, etc.)?

Thanks,
--Simone



-- 
You cannot discover new oceans unless you have the courage to lose sight of
the shore (R. W. Emerson).

http://xkcd.com/229/
http://negativo17.org/
-- 
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: Excludearch/Exclusivearch reminder

[Simone Caronni]

On 8 August 2013 10:44, Petr Pisar ppi...@redhat.com wrote:

 And the canonical RPM architecture name is what? arm or armv7hl or some
 macro like %{ix86}?


Yep. At the moment for my local builds I use armv7hl because the package
I build works only on armv7 with hfp; but would be good to know if there is
a generic macro like %{ix86}.

-- 
You cannot discover new oceans unless you have the courage to lose sight of
the shore (R. W. Emerson).

http://xkcd.com/229/
http://negativo17.org/
-- 
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: Koji 404 errors on el6

[Simone Caronni]

Thanks very much!

--Simone


On 8 August 2013 13:48, Kevin Fenzi ke...@scrye.com wrote:

 On Thu, 8 Aug 2013 10:58:48 +0200
 Simone Caronni negativ...@gmail.com wrote:

  Hello,
 
  I get the following when building for el6/ppc:

 ...snip...

  I've already tried 2 builds and I got the same result. Full log here:
 
  http://koji.fedoraproject.org/koji/getfile?taskID=5793165name=root.log
 
  Should I just wait that this settles down on its own (updates, etc.)?

 yes. Usually you should just wait for the next newrepo to finish.

 This occurs when updates show up in the build repos. The old versions
 are removed and the updated versions land, and until the next newrepo
 the buildroot isn't happy. It should only be a short wait.

 kevin

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




-- 
You cannot discover new oceans unless you have the courage to lose sight of
the shore (R. W. Emerson).

http://xkcd.com/229/
http://negativo17.org/
-- 
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: latex not working in F20: I can't find the format file `latex.fmt'!

[Simone Caronni]

Hello Than,

On 8 August 2013 14:47, Than Ngo t...@redhat.com wrote:

 the buildrequirement is not correct, please replace your BR with these:

 BuildRequires:  ghostscript
 BuildRequires:  texlive-collection-latexrecommended texlive-preprint


can you please check this bug?

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

I don't know if it's related or not. My builds go timeout in Koji after 15
hours.

Thanks,
--Simone


-- 
You cannot discover new oceans unless you have the courage to lose sight of
the shore (R. W. Emerson).

http://xkcd.com/229/
http://negativo17.org/
-- 
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: Doc dir related changes coming up

[Simone Caronni]

On 8 August 2013 16:03, Michael J Gruber 
michaeljgruber+fedora-li...@gmail.com wrote:

 Building an F20 (master) package on F18 does not work, then, even with
 the proposed conditional %{_pkgdocdir}. Wouldn't a conditional based on
 the Fedora version be a much more robust suggestion to deal with this?


I've personally changed my packages to always pull docs with the %doc
directive in the %files section, but I don't know if that's feasible enough
for all cases. So far it worked for me; the same spec file works across
el6, f18, f19 and f20.

Regards,
--Simone

-- 
You cannot discover new oceans unless you have the courage to lose sight of
the shore (R. W. Emerson).

http://xkcd.com/229/
http://negativo17.org/
-- 
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: latex not working in F20: I can't find the format file `latex.fmt'!

[Simone Caronni]

On 5 August 2013 15:43, punto...@libero.it punto...@libero.it wrote:

  Il 05/08/2013 15:32, Richard W.M. Jones ha scritto:

 On Mon, Aug 05, 2013 at 03:16:15PM +0200, Than Ngo wrote:

  have you built it localy or in koji? could you please give me the url if it 
 fails in koji?

  Both.  I can easily reproduce the problem on my F20 box.

 Here is a Koji build which failed:

   http://koji.fedoraproject.org/koji/buildinfo?buildID=453922

  which package is it?

  ocaml-res

 Note I have now removed the latex/PDF documentation from this package,
 thus bypassing the problem.

 Rich.


  i apologized if this comment is OT
 there is also this problem

 This is pdfTeX, Version 3.1415926-2.5-1.40.14 (TeX Live 2013) restricted
 \write18 enabled. kpathsea: Running mktexfmt pdflatex.fmt I can't find the
 format file `pdflatex.fmt'! make: *** [spec.pdf] Error 1

 related to

 http://pkgs.fedoraproject.org/cgit/glassfish-jax-rs-api.git/tree/glassfish-jax-rs-api.spec


Is there a bug for the recent latex breakage in Fedora 20 that I can depend
on for my FTBFS rawhide bugs?

Thanks,
--Simone



-- 
You cannot discover new oceans unless you have the courage to lose sight of
the shore (R. W. Emerson).

http://xkcd.com/229/
http://negativo17.org/
-- 
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: gdcm FTBFS: texlive broken in rawhide?

[Simone Caronni]

On 6 August 2013 17:38, Jan Kratochvil jan.kratoch...@redhat.com wrote:

 Package owner Jindrich Novy is no longer in Red Hat so I am not sure how
 quickly it may get fixed.


I really hope the next mantainer can manage a 14 mb spec file :)

Regards,
--Simone




-- 
You cannot discover new oceans unless you have the courage to lose sight of
the shore (R. W. Emerson).

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

Problem with mass rebuild / latex2html errors

[Simone Caronni]

Hello,

I have a problem on the bacula-docs package in Fedora 20. Build was stuck
for 15 hours and then killed by Koji:

http://koji.fedoraproject.org/koji/taskinfo?taskID=5698742

I was able to reproduce it locally with mock; all the latex2html commands
get stuck indefinitely. An example command from the Koji build:


make[1]: Entering directory
`/builddir/build/BUILD/bacula-docs-5.2.13/manuals/en/developers'
[...]
latex2html -split 4 -local_icons -t Developer's Guide -long_titles 4 \
-toc_stars -contents_in_nav -init_file latex2html-init.pl \
-no_antialias -no_antialias_text \
-white -notransparent developers tex.out 21
make[1]: *** [web] Error 1


If I look into the tex.out log file I can see that the command gets stuck
creating an infinite line of dots. Example:


$ tail 2 tex.out | less
== tex.out ==
;...;..

120/213:subsection:Minimal Code in Console Program for General.html
;..;...

121/213:subsection:GUI Interface is Difficult for General.html
;..,,,...;...
...
122/213:section:Bvfs API for Bvfs_API.html
;...,.. [...]


The moment I stopped my mock build that was running for 3 minutes I already
had an 18 mb file; 90% of it filled with dots in the last line.

Any idea / insight on where to look for clues / fixes?

Thanks,
--Simone



--
You cannot discover new oceans unless you have the courage to lose sight of
the shore (R. W. Emerson).

http://xkcd.com/229/
http://negativo17.org/
-- 
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: Problem with mass rebuild / latex2html errors

[Simone Caronni]

On 5 August 2013 12:14, Simone Caronni negativ...@gmail.com wrote:

 I have a problem on the bacula-docs package in Fedora 20. Build was stuck
 for 15 hours and then killed by Koji:

 http://koji.fedoraproject.org/koji/taskinfo?taskID=5698742/http://negativo17.org/


Would like to point out that previous Fedora 20 build from April was
successful:

http://koji.fedoraproject.org/koji/buildinfo?buildID=413039

Regards,
--Simone



-- 
You cannot discover new oceans unless you have the courage to lose sight of
the shore (R. W. Emerson).

http://xkcd.com/229/
http://negativo17.org/
-- 
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: latex not working in F20: I can't find the format file `latex.fmt'!

[Simone Caronni]

On 5 August 2013 15:32, Richard W.M. Jones rjo...@redhat.com wrote:

 On Mon, Aug 05, 2013 at 03:16:15PM +0200, Than Ngo wrote:
 
  have you built it localy or in koji? could you please give me the url if
 it fails in koji? http://fedoraproject.org/code-of-conduct


Mine was in the first mail:

http://koji.fedoraproject.org/koji/taskinfo?taskID=5698742

Thanks,
--Simone

-- 
You cannot discover new oceans unless you have the courage to lose sight of
the shore (R. W. Emerson).

http://xkcd.com/229/
http://negativo17.org/
-- 
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: latex not working in F20: I can't find the format file `latex.fmt'!

[Simone Caronni]

It took me a really long time to get package ownership from Andreas
Thienemann. He would reply only to mails to avoid losing package ownership
and nothing else. I had to file an fpc ticket as well.
On Aug 5, 2013 8:44 PM, Richard W.M. Jones rjo...@redhat.com wrote:

 On Mon, Aug 05, 2013 at 05:59:34PM +0100, Richard W.M. Jones wrote:
  Yeah, I can (still) comaintain hevea if someone pushes the right button.

 Thanks to (whoever) pushed that.

 Rich.

 --
 Richard Jones, Virtualization Group, Red Hat
 http://people.redhat.com/~rjones
 virt-df lists disk usage of guests without needing to install any
 software inside the virtual machine.  Supports Linux and Windows.
 http://people.redhat.com/~rjones/virt-df/
 --
 devel mailing list
 devel@lists.fedoraproject.org
 https://admin.fedoraproject.org/mailman/listinfo/devel
 Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
-- 
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: Rename Review Request swap

[Simone Caronni]

On 22 July 2013 07:03, Mikolaj Izdebski mizde...@redhat.com wrote:

 For Java-related reviews you are welcome to block Java SIG tracker bug
 (FE-JAVASIG, rhbz #652183).  This way members of Java SIG can easily see
 that there is a new review and take care of it.


Good to know, thanks, I will do next time!

Regards,
--Simone


-- 
You cannot discover new oceans unless you have the courage to lose sight of
the shore (R. W. Emerson).

http://xkcd.com/229/
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Rename Review Request swap

[Simone Caronni]

Anyone willing to review these 2 packages?

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

They are a rename of older packages; upstream has consolidated multiple
source tarballs into one thus simplifying building:

http://koji.fedoraproject.org/koji/search?match=globtype=packageterms=*guac*

Taking anything in return.

Thanks  regards,
--Simone


-- 
You cannot discover new oceans unless you have the courage to lose sight of
the shore (R. W. Emerson).

http://xkcd.com/229/
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel