Re: It’s time to transform the Fedora devel list into something new

[Alec Leamas]

Hi all,


On 21/04/2023 10:50, Jarek Prokop wrote:

> As a person in my early 20s, I hate how everything is becoming
> web centric and no one can convince me to feel otherwise.

hm... I thought this was kind of a generation conflict. Glad to be 
proven wrong.


I enjoyed Fedora being on mailing lists, nothing ever came close to the 
threading of emails.


Actually, Zulip [1] does. It's an interesting tool, basically something 
in between traditional forums and email threading.



--alec

[1] https://zulip.com/





___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Tenacity

[Alec Leamas]

Hi Stan,

On 09/02/2023 16:55, stan via devel wrote:


I downloaded the wxWidgets code from their site, and compiled it using
their instructions on f37.  Compiled easily, with only a warning about
missing midi support.  I installed it in /usr/local

When I tried to get tenacity to use it, though, I hit a dead end.  Even
though I set the environment variable WX_CONFIG to point to it, cmake
find_program kept finding the system version 3.0.4.  I assume it looks
there first, and once it finds it, it stops.  I tried the alternative of
building it as a subprogram with the tenacity source (the tenacity
build instructions helpfully pointed to this), but it was compiled as
3.0 compatible, and tenacity complained about too old a version of some
constructs.  I then gave up.


Using several wxWidgets version is indeed a bit painful, been there, 
done that. One quick fix is to configure alternatives to use the new 3.2 
version version of wx-config instead of the default 3.0.


There is no need to actually build, just running "wx-config --version" 
reveals the version currently selected by alternatives.


There are other options including hard-wiring wx-config to an absolute 
path. However, it's IMHO more complicated and with some traps.



HTH
--alec
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: F37 proposal: Officially Support Raspberry Pi 4 (Self-Contained Change proposal)

[Alec Leamas]

Hi,

On 07/07/2022 17:36, Onuralp SEZER wrote:


For example can you run wayland, or usage of fully supported GPU usage, 
Rs-pi's Camera usage, SPI , I2C , GPIO usages (PWM,Analog and others)



Indeed. Also, the installation process has room for some improvements...

Cheers!
--alec

PS: Please folks, no top-posting:

https://fedoraproject.org/wiki/Mailing_list_guidelines#If_You_Are_Replying_to_a_Message
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: Orphaned packages looking for new maintainers​

[Alec Leamas]

On 16/06/2022 13:40, Miro Hrončok wrote:


The following packages require above mentioned packages:



Depending on: libftdi (21), status change: 2022-06-16 (0 weeks ago)




 lirc (maintained by: hobbes1069, jwilson, leamas)
     lirc-0.10.0-34.fc36.src requires libftdi-devel = 1.5-3.fc36
     lirc-drv-ftdi-0.10.0-34.fc36.x86_64 requires 
libftdi1.so.2()(64bit)


libftdi should be fixed according to Dan earlier in this thread. While 
on it, fixed another FTBFS error in rawhide.


--alec
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Retired: java-wakeonlan

[Alec Leamas]

I have retired java-wakeonlan. I don't use this anymore, and it's not 
installable.



--alec
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Retired: system-config-repo

[Alec Leamas]

Dear list,

I have retired system-config-repo.

This is something I should have done long ago. I did the upstream as a 
basically failed experiment, and I doubt anyone will miss it. When it 
now failed to build I finally got my finger out.


--alec
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: Donate 1 minute of your time to test upgrades from F31 to F32

[Alec Leamas]

On 04/03/2020 16:24, Miroslav Suchý wrote:
> Do you want to make Fedora 32 better? Please spend 1 minute of your time and 
> try to run:
> 

Error:
 Problem 1: package VirtualBox-6.1-6.1.2_135662_fedora31-1.x86_64
requires python(abi) = 3.7, but none of the providers can be installed
  - python3-3.7.6-2.fc31.x86_64 does not belong to a distupgrade repository
  - problem with installed package
VirtualBox-6.1-6.1.2_135662_fedora31-1.x86_64
 Problem 2: problem with installed package
gimp-2:2.10.14-1.module_f31+6993+669d73be.x86_64
  - package gimp-2:2.10.14-1.module_f32+6980+20383b7e.x86_64 requires
libmypaint-1.3.so.0()(64bit), but none of the providers can be installed
  - libmypaint-1.4.0-1.fc31.x86_64 does not belong to a distupgrade
repository
  - gimp-2:2.10.14-1.module_f31+6993+669d73be.x86_64 does not belong to
a distupgrade repository


Filed gimp bug: https://bugzilla.redhat.com/show_bug.cgi?id=1810173.
VirtualBox left without any actions...

Cheers!
--alec
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: No longer supporting mailing lists:

[Alec Leamas]

On 26/08/2019 16:12, Alec Leamas wrote:

oops...



Or, perhaps Postorious/GNU Mailman.  Fedora has moved to it and seems 
happy. It offers some web-related functionality on top of a 
traditional mailing.




The evil of subscribing to both debian-devel and fedora-devel and mixing 
it up. Please disregard ;)



--alec
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: No longer supporting mailing lists:

[Alec Leamas]

On 26/08/2019 16:04, Gerald B. Cox wrote:


The best way to solve this is to create a duplicate discussion group on 
Discourse for Development and monitor it's use.  The only way people are going 
to be able to decide if it's good for them or not is to try it.
_



Or, perhaps Postorious/GNU Mailman.  Fedora has moved to it and seems 
happy. It offers some web-related functionality on top of a traditional 
mailing.



Cheers!

--alec
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: HEADS UP: /usr/bin/python is Python 3 in rawhide

[Alec Leamas]

> On 7/15/19 7:09 PM, Miro Hrončok wrote:

> Finally some light at the end of the python-transition tunnel :)
> 
>   - Panu -

If you see some light down the  tunnel, it might be the train coming...

Cheers!
--alec
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Orphaning: supybot-git, adobe-source-libraries and openerp

[Alec Leamas]

Dear list,

As heading says: I have  orphaned  the packages supybot-git,
adobe-source-libraries and openerp. This is overdue since long, I have
not maintained these packages properly.

Of course, they are all free to pick.

Cheers!

--alec
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: fedora-review — do we have a maintainer?

[Alec Leamas]

On 16/08/18 14:54, Fabio Valentini wrote:
> Thanks for your help! You are listed as the main admin for the
> fedora-review project on pagure [0] - can you give me (decathorpe),
> Miro (churchyard), and Neal (ngompa) access to the project?
> 

Done.  Welcome tto the project, you are all admins!

There is a fedora-review mailing list which might be useful.

Cheers!

--alec
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/2X7GMTEM2LGGXZHKVVFXKW2FLKMEJUGS/

Re: Prioritizing ~/.local/bin over /usr/bin on the PATH

[Alec Leamas]

On 15/06/18 19:52, Przemek Klosowski wrote:

> I have mixed feelings about that. On one hand,  I agree that this is NOT
> a serious security issue (it's essentially a local compromise requiring
> an existing local compromise), so if someone claims it'll make their
> life easier, I want to say 'just do it'.
> 
> On the other hand, I am uneasy about the whole thing: the PATH ordering
> only matters for system-provided software, so we're essentially either
> acknowledging that we can't keep up with a decently updated
> distribution, or accommodating a very small group that needs cutting
> edge stuff that is not relevant to the vast majority of users.

+1

This is now a very long thread dominated by the security questions like
"what if?". Nothing bad in that, but we need to keep some focus also on
the usecases to be able to make the inevitable trade-off between
usability and security.

The usecase represented by npm et. al. is important. To have the
platform so secure that these environments doesn't work out of the box
is probably to shoot ourselves in our feet.


Cheers!

..alec
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/VWGIFKY7E3N4KCAGGH4E5RTXC5KMFX7W/

Re: [ACTION NEEDED #2] Missing BuildRequires: gcc/gcc-c++

[Alec Leamas]

> On Wed, 07 Mar 2018 08:43:21 +0100
> Igor Gnatenko  wrote:
> This is the second iteration of my mass-scratch-rebuild without
> gcc/gcc-c++ in the buildroot[0]. Everything what was written in
> original mail still applies.
>
> Since people might have fixed their packages after I started rebuild,
> I decided to include information about commits I have used to build
> packages. Hope this helps.
>
>
> New list of packages, their commits and build logs are available:
> * https://ignatenkobrain.fedorapeople.org/gcc-removal-pkgs-2.txt
>

Fixed tonto and DecodeIR

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

Re: F27 strange rpmbuild failure

[Alec Leamas]

On 05/02/18 16:06, Petr Viktorin wrote:
> On 02/04/2018 10:08 PM, Alec Leamas wrote:

>> In other words, it's sort of a known bug with fixes under way, slowly...

> We're preparing a Change to fix this exact issue in Fedora 29. Started
> just last week, actually:
> https://fedoraproject.org/wiki/Changes/No_more_automagic_Python_bytecompilation

Right, this is what I had in mind when I wrote my reply. At that point,
lazy me couldn't find that Change page even though I was aware it
existed somewhere in space.

Cheers!

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

Re: F27 strange rpmbuild failure

[Alec Leamas]

On 04/02/18 21:36, Steve Grubb wrote:
> On Sunday, February 4, 2018 2:29:26 PM EST Alec Leamas wrote:

>> Many questions here, and a large package. Still, searching the logs I
>> cannot see any python files - are there any such at all?
> 
> None at all. Its all java, javascript, R, and ELF files.
> 
>> If not, perhaps  you could disable the byte compulation as described in
>> [1]?
> 
> Bingo! That fixed the build...which leads to the question of why is that 
> failing? 

I think the basic answer is that the byte comoilation script is using
all sorts of strange heuristics. It seems that it determined a that a
non-python file was python.

Efforts are under way to redefine things and make the byte compilation
more explicit. Until this is done, this is probably not the last error
of this sort.

In other words, it's sort of a known bug with fixes under way, slowly...


Cheers!
--alec
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: F27 strange rpmbuild failure

[Alec Leamas]

On 04/02/18 19:30, Steve Grubb wrote:
> On Sunday, February 4, 2018 12:42:56 PM EST Antonio Trande wrote:
>> Not enough information to check signature validity.  Show Details
>>
>> On 04/02/2018 18:13, Steve Grubb wrote:
>>> Hello,
>>>

>>> + /usr/lib/rpm/brp-python-bytecompile /usr/bin/python 1
>>> error: Bad exit status from /home/sgrubb/working/tmp/rpm-tmp.tz0qAN

>> Full build log, please.
> 
> It's too big for the mail list. I put it here:
> 
> http://people.redhat.com/sgrubb/files/build.log



Many questions here, and a large package. Still, searching the logs I
cannot see any python files - are there any such at all?

If not, perhaps  you could disable the byte compulation as described in [1]?

Another question: brp-python-bytecompile tries to use /usr/bin/python
which still is python2.7 (I think). So, have you a BR: python2-devel, or
is the python command just missing in the build environment?



Cheers!
--alec
[1]
https://fedoraproject.org/wiki/Packaging:Python_Appendix#Manual_byte_compilation
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Wyland is a disaster

[Alec Leamas]

On 20/01/18 19:14, Howard Howell wrote:
> Hi, guys,
>   I'm sorry, but wyland is a disaster for me.  I do work on lots
> of different software platforms, and things are just not working well. 
> They kind-of-work, which is the really worst condition one can have. 

For me, this looks more like a support issue and as such doesn't not
belong to this development list. I suggest that you:

  - Reach out for help in a support channel e. g. Ask Fedora [1]
  - When you do, divide you problems into small, well-defined ones,
giving folks a chance to help
  - Learn to spell Wayland ;)


Cheers!

--alec


[1] https://ask.fedoraproject.org/en/questions/
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: EPEL support in "master" branch (aka speeding up Fedora development)

[Alec Leamas]

On 20/01/18 13:52, Fabio Valentini wrote:
> On Jan 20, 2018 12:29, "Igor Gnatenko" > TL;DR:
>> - We need an authoritative source that tells us packagers which
>> Guidelines apply to which branch (or what has to be done differently -
>> or can be done better - in, for example, f26 when compared to the
>> current Packaging Guidelines).

Agreed, fully. But this is basically to version the GL, and that idea
was turned down when I approached the FPC with it [1]. My perspective at
that point was how to update fedora-review to match the changed GL, but
the solution was more or less the same.

It's a bit depressing to compare this very feature with Debian, which
has this Standards-Version thing in their "spec", basically a checkmark
for the last "GL" version the "spec" has been updated to.

Cheers!
--alec

[1] https://pagure.io/packaging-committee/issue/646
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Review exchange

[Alec Leamas]

Dear list,

I have submitted ddupdate [1] and need a review. I'm ready to make one
in return, preferably a python or a C/C++ package.

ddupdate is a simple, python3 application.

Cheers!

--alec

[1] https://bugzilla.redhat.com/show_bug.cgi?id=1532023
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Retiring openerp7 and openerp-client

[Alec Leamas]

Hi all,

As heading says, I'm retiring these openerp packages. They need more
love than I'm able to give them since I nowadays don't use them anymore.

The difference between being employed and running a one person company
that is...

Cheers!

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

Re: Proposed Mass Bug Filing: Renaming "python-" binary packages to "python2-"

[Alec Leamas]

On 01/07/17 01:17, Zbigniew Jędrzejewski-Szmek wrote:

On Sat, Jul 01, 2017 at 12:45:51AM +0200, Björn Persson wrote:

Spot on.

There is a Swedish proverb. I don't know whether an English version
exists, but in translation it is: One time is no time; two times is a
habit. Since the Python API has been broken twice, we can expect that
it will be broken again.


"Fool me once, shame on you; fool me twice, shame on me"?
But in this case both parties are one and the same, so "Fool myself
once, shame on me; fool myself twice, shame on me again" which does
not come quite as well ;P


On a sidenote, I think the original Swedish proverb rather is something 
like "Once is never, twice is once and three times is a habit."


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

Re: Directory permissions for games

[Alec Leamas]

On 27/06/17 14:13, Rémi Verschelde wrote:

2017-06-27 14:01 GMT+02:00 Nico Kadel-Garcia :



Where does the game save its files? Does it need to be in a shared
game repository, or does it save them in the user's home directory? If
the games need to be saved into a common space, then does the binary
need 2755 permissions in order to write to a shard directory? Not
sure, can't tell.


Although I cannot find a reference at a glance, I'd say that files under 
/usr/share are not expected to change during ordinary conditions. E. g., 
what if there are two users sharing the same data? If user needs to 
modify it, I'd think it might be better to copy the shared stuff to the 
user's home and change the private copy. Might be a problem if the data 
is big enough to make two copies unfeasible.



For what it's worth, on Mageia I have no permission problems
whatsoever with crawl. This spec file works just fine:

http://svnweb.mageia.org/packages/cauldron/crawl/current/SPECS/crawl.spec?view=markup

Files are saved in the user dir, as expected of any modern game.


Actually, the spec stores them in %_gamesdatadir a. k. a. 
/usr/share/games on mageia. IMHO, that's not a user directory.


> as expected of any modern game.

Indeed. Perhaps there is some magic copying as described above. Or, the 
game is actually sane and the game data is read-only as it should be.



Cheers!

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

Re: error: package javafx.collections does not exist

[Alec Leamas]

On 08/02/17 14:39, Martin Gansser wrote:

Hi,

I am trying to compile MSearch, a program needed by Mediathekview.
https://martinkg.fedorapeople.org/Packages/MediathekView/MSearch.spec

dependencies: openjfx, i compiled the src.rpm file from:
https://jonny.fedorapeople.org/openjfx-8.0.152-3.b00.fc25.src.rpm

When I try to compile msearch, I get the following error:
/home/martin/rpmbuild/BUILD/MSearch-3467040e54e31625425eb33dcd0f20a8da575dc4/src/main/java/mSearch/tool/SysMsg.java:22:
 error: package javafx.collections does not exist
import javafx.collections.FXCollections;



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

Cheers!

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

Re: How to build both python 2 and 3 bindings from autotools?

[Alec Leamas]

On 26/01/17 00:10, Peter Hutterer wrote:

Before I start hacking up something nasty I figured it's better to ask: how
do I build both py2 and py3 bindings from a package using autotools (i.e.
AM_PATH_PYTHON)?

So far my idea revolves around installing both python-devel packages and
overriding PYTHON in each %build , etc. But maybe there's a
simpler solution?


Just an idea, nothing tested... but what about hacking 
AM_PATH_PYTHON2/AM_PATH_PYTHON3 macros?



Just my 5 öre


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

Re: packaging problem - rm: cannot remove ... Permission denied

[Alec Leamas]

On 22/01/17 12:38, Martin Gansser wrote:

Hi,

i want o create a rpm package of a small plugin for nuvolaplayer, but this 
fails with this error:



+ cd /home/martin/rpmbuild/BUILD
+ '[' 
/home/martin/rpmbuild/BUILDROOT/nuvola-app-spotify-2.2-0.1git1828d92.fc25.x86_64
 '!=' / ']'
+ rm -rf 
/home/martin/rpmbuild/BUILDROOT/nuvola-app-spotify-2.2-0.1git1828d92.fc25.x86_64
rm: cannot remove 
'/home/martin/rpmbuild/BUILDROOT/nuvola-app-spotify-2.2-0.1git1828d92.fc25.x86_64/usr/share/nuvolaplayer3/web_apps/spotify/icons/22.png':
 Permission denied
rm: cannot remove 
'/home/martin/rpmbuild/BUILDROOT/nuvola-app-spotify-2.2-0.1git1828d92.fc25.x86_64/usr/share/nuvolaplayer3/web_apps/spotify/icons/128.png':
 Permission denied



This is the rpm spec file I use:
https://martinkg.fedorapeople.org/Packages/nuvolaplayer/nuvola-app-spotify.spec


At a glance: the usual convention is 'make DESTDIR=... install', not 
'make install DEST=---'


Cheers!

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

Re: newbie: Linking python C extensions blues

[Alec Leamas]

On 13/01/17 15:55, Alec Leamas wrote:

Still struggling with my first package. Don't know if this belong to
this list (let me know if not)


Thank you for listening... solved by a 'pip uninstall'. The beginning is 
hard.



Cheers!

-alec

PS It's Friday, 13
___
python-devel mailing list -- python-devel@lists.fedoraproject.org
To unsubscribe send an email to python-devel-le...@lists.fedoraproject.org

newbie: Linking python C extensions blues

[Alec Leamas]

Still struggling with my first package. Don't know if this belong to 
this list (let me know if not)


Anyway, I package the extension and make a 'pip install' which builds 
it. Linker command is:


gcc -pthread -shared -Wl,-z,relro 
-specs=/usr/lib/rpm/redhat/redhat-hardened-ld 
build/temp.linux-x86_64-3.5/lirc/_client.o -L/usr/lib64 -llirc_client 
-lpython3.5m -o 
build/lib.linux-x86_64-3.5/_client.cpython-35m-x86_64-linux-gnu.so


Still, this module has unresolved references. This can be seen using 
ldd. When invoked on a correctly linked variant there is a line


ldd  ../lib/.libs/_client.so
liblirc_client.so.0 => /home/mk/tmp/lirc/...

However, the variant created by setuptools misses this line, and the 
corresponding symbols are unresolved. Still, it's linked using 
-llirc_client in the linker command above.


Any clue out there?  Why isn't my _client.so linked to liblirc_client as 
it should?



Cheers!

--alec
___
python-devel mailing list -- python-devel@lists.fedoraproject.org
To unsubscribe send an email to python-devel-le...@lists.fedoraproject.org

Re: To use or not to use: packaged flask

[Alec Leamas]

On 12/01/17 11:53, Petr Viktorin wrote:


On my Fedora 25, I can import flask.cli from the system packages just
fine. But note that Fedora 24 has an older version of Flask packaged –
one that doesn't include flask.cli yet.


Ah... that sorts things out. Time to upgrade...

> Packages with native code aren't as much of a problem nowadays as 
they used to be, but if you still run into trouble, we'll be happy to help


It's "my" code, I'm upstream for an old package for which I'm about to 
add a python API. Haven't found any pointer how to make pypi package 
with linux native code... have you?



Cheers!

--a



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

To use or not to use: packaged flask

[Alec Leamas]

Hi out there!

I'm dipping my toes in flask, completely newbie. Doing so, I see a lot 
of fedora flask packages, but no-one anywhere recommends using these - 
it's all about pypi.


I "think" I prefer the packaged version, partly because I'm using 
another package with native code (which, as I understand it, isn't that 
easy to make a linux pypi package of). However, I'm stuck at the very 
beginning:


   $  ./run_flask
   ...
   ImportError: No module named 'flask.cli'

So, my question: is it possible to run a flask application using the 
packaged components similar to run_flask above, in any way? If so, how?



Cheers!

--alec
___
python-devel mailing list -- python-devel@lists.fedoraproject.org
To unsubscribe send an email to python-devel-le...@lists.fedoraproject.org

Re: SSL: CERTIFICATE_VERIFY_FAILED

[Alec Leamas]

On 08/01/17 13:30, Alexander Ploumistos wrote:

On Sun, Jan 8, 2017 at 2:10 PM, Till Maas  wrote:


~/.fedora.upn (User Principal Name)

And the problem with trying to get the FAS username from kerberos is
that it only works while the use has a valid ticket for kerberos since
MIT kerberos removes expired tickets. Therefore IMHO it would be a good
idea for all Fedora users to setup the FAS username in the file.


So we just run

echo "FAS_username" > ~/.fedora.upn



Looks so, according the the documentation [1]  ;)

Cheers!

--alec

https://pagure.io/fedora-packager/c/715483c1bbdf5cceaeb63e90410139
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Changing default "docker" storage to to Overlay2 in Fedora 26

[Alec Leamas]

Hi!

Is there a local convention that discussion about containers is using 
top-posting?


"Curious"

--alec

On 06/01/17 23:12, Vivek Goyal wrote:

There is more conversation on this issue here.

https://pagure.io/atomic-wg/issue/186

I wished there was a single thread of conversation on this instead of
separate conversation for per product variant.

Thanks
Vivek

On Fri, Jan 06, 2017 at 02:05:49PM -0500, Daniel J Walsh wrote:

Upstream docker is moving to overlay2 by default for its storage.  We
plan on following suit.  Their are some performance advantages of
overlay2 over devicemapper in memory sharing, which we would like to
take advantage of.   We now have SELinux support for Overlay  file
systems, so the security should be just as good.

Note: Overlay is not a Posix Compliant file system, so their could be
problems with your containers running on overlay, so
we want to make sure it is fairly easy to switch back to devicemapper.

Devicemapper out of the box, on Fedora Workstation, currently defaults
to loopback devices for storage, which has a performance penalty, but
this was the only way we were able to get docker to work right away.
Switching to overlay2 will cause the storage to be shared with / and
will eliminate this performance overhead.   This is the way we will ship
Fedora Workstation.

On Fedora atomic host and Fedora server we have been storing
devicemapper storage on a separate partition.  We plan on doing the same
thing with overlay2.  This means separate device will be mounted on
/var/lib/docker.  This will make it easier for someone to switch back to
devicemapper, if overlay2 has problems.

Upgraded systems will not be effected.

If you want to switch from one storage to another take a look at the
`atomic storage` commands.

We will write up release notes to cover this change. Along with a blog
explaining the commands to switch back and forth.

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


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

Re: Packages FTBFS with Python 3.6

[Alec Leamas]

On Wed, 21 Dec 2016 00:18:47 +0100
Miro Hrončok  wrote:


> python-xlwt

Fixed

Cheers!

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

Re: [Fedora-packaging] Re: Many directories without owning packages

[Alec Leamas]

On 02/11/16 17:49, Dridi Boukelmoune wrote:

I'm still curious if this elegant shell code could be used to enhance

the current tests f-r has. As noted, they are extremely expensive, in a
class of it's own besides the build and install tasks.

I don't think so, f-r works on packages built from a source rpm. This on
the other hand is a brute-force search on all installed packages.



Actually, f-r installs the built package in a a mock chroot, and this is 
accessible for tests-. E. g., f-r runs rpmlint not only on the result 
packages but also on the installed ones in the chroot.


So, I have this idea to do the same brute-force method on the chroot...


Cheers!

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

Re: [Fedora-packaging] Re: Many directories without owning packages

[Alec Leamas]

On 02/11/16 15:55, Dominik 'Rathann' Mierzejewski wrote:

On Tuesday, 01 November 2016 at 13:05, Dridi Boukelmoune wrote:



Actually, a check for this would be useful to have in both
fedora-review


Actually, f-r is testing this since long. However, the review approach 
is different: does this package use/install directories with bad 
ownerships vs the overall "are all directories sane" approach.


I'm still curious if this elegant shell code could be used to enhance 
the current tests f-r has. As noted, they are extremely expensive, in a 
class of it's own besides the build and install tasks.



Cheers!

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

Re: RPM %changelog?

[Alec Leamas]

On 25/10/16 14:56, Matthew Miller wrote:

On Mon, Oct 24, 2016 at 05:00:21PM -0400, Josh Boyer wrote:

Please, no, don't do that. RPM is a standard, the changelog is part of
that. It would be pretty crappy to just declare we're going to stop
using RPM changelogs and bake some random new idea into our distro's
packaging tools instead.

I agree with Adam here.


So do I


Well, except -- it doesn't come for free. I was just talking to David
Shea about something different and he mentioned that changelogs
comprise about 40% of RPM metadata, both on disk and in-memory for
every transaction.


Which raises another issue: How long history should be kept in the spec 
file? Can't we have some policy stating that we can purge entries older 
then X years, and tooling support for that? Trusting whatever VCS we 
have for the longer history?


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

Re: Orphaning python-lirc package

[Alec Leamas]

On 16/09/16 10:32, Ján ONDREJ (SAL) wrote:

Hello,

  I'm orphaning python-lirc package, which is long time not supported
by upstream and has no python3 support. Last release has been in 2005.

  There is an alternative python-lirc package, but with different python
import (lirc instead of pylirc) and I have also an python-ctypes
alternative, which can be updated to be compatible with current Fedora
package (py2 and py3 compatible, one .py file only).

  I think this package should retire, but if anyone interested, a new
package should be reviewed to replace this one.


Actually, the proper action might be to take whatever exists and file it 
as an  RFE bug to lirc upstream so that  lirc could ship python bindings.


BTW, I note that the existing packages does not support sending a. k. a. 
blasting, which is supported by lirc client libraries as of version 0.9.2+



Cheers!

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

Re: Versioning the Packaging Guidelines

[Alec Leamas]

On 09/09/16 14:39, Josh Boyer wrote:

On Fri, Sep 9, 2016 at 8:13 AM, Alec Leamas <leamas.a...@gmail.com> wrote:

Dear list,


There is an ongoing thread in debian-devel on their Standards-Version usage.
Reading this, it strikes me that Fedora lacks this info.




It wouldn't be that difficult to pull it out of the wiki and into a
pagure.io repo that actually publishes things, etc.  Again a topic of
conversation for the FPC.  I would really suggest opening a ticket
with them.




Done: https://fedorahosted.org/fpc/ticket/646

Cheers!

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

Versioning the Packaging Guidelines

[Alec Leamas]

Dear list,


There is an ongoing thread in debian-devel on their Standards-Version 
usage. Reading this, it strikes me that Fedora lacks this info.


The basic package lifecycle is that it is reviewed to current standards, 
and after that start lagging from the actual standards. To which extent 
depends on the maintainer.


Debian addresses this by actually versioning their guidelines, and 
tracking the last version checked in  the package. There are checklists 
how to update between each version of the standard.


Could we learn anything from this? Fedora is not a rolling distribution, 
but the guidelines are. Would it be a good idea to actually provide 
versions of the guidelines? To track the last version checked in the 
packages?


If not for anything else., it would certainly make the life of 
fedora-review maintainers easier. That said,  I'm turning a blind eye to 
the obvious technical hassles versioning a wiki.


Just my 5 öre


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

Re: Kernel 4.7 rebase plans

[Alec Leamas]

On 31/08/16 17:15, Peter Robinson wrote:

Perhaps. But this has been a common problem for me with many recent kernel
updates. But if it's only me, I presume it's the mirror.

Tried with "dnf upgrade --refresh" ?
--


I'm more the sledgehammer type, so I did dnf clean all. But to no avail.

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

Re: Kernel 4.7 rebase plans

[Alec Leamas]

On 31/08/16 16:41, Josh Boyer wrote:

On Wed, Aug 31, 2016 at 10:34 AM, Alec Leamas <leamas.a...@gmail.com> wrote:


On 29/08/16 18:25, Laura Abbott wrote:


Please test and give karma again. A reminder that if you do find
regressions please note on the bodhi update corresponding to the
kernel you tested AND file a bugzilla with information.


It's somewhat hard since the corresponding kernel-devel packages seems to be
missing. Is this on purpose?

Uh... what?  They're present in the build.  Perhaps the mirror you hit is stale?

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



Perhaps. But this has been a common problem for me with many recent 
kernel updates. But if it's only me, I presume it's the mirror.


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

Re: Kernel 4.7 rebase plans

[Alec Leamas]

On 29/08/16 18:25, Laura Abbott wrote:


Please test and give karma again. A reminder that if you do find
regressions please note on the bodhi update corresponding to the
kernel you tested AND file a bugzilla with information.



It's somewhat hard since the corresponding kernel-devel packages seems 
to be  missing. Is this on purpose?


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

Re: Alternate places to install specialized binaries

[Alec Leamas]

testing this on-line reply thing...

I guess the java tools are either scripts or java code i. e., 
architecture-independent. I just presume Rich's tools are compiled code which 
cannot live in /usr/share for that reason. But... to presume is a bad habit.

Cheers!

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

Re: Alternate places to install specialized binaries

[Alec Leamas]

On 10/06/16 14:01, Sérgio Basto wrote:

(3) Rename them and put them in %{_bindir}.  This is technically
difficult, because the binaries have manual pages which would all
have
to be patched to refer to the new names.

Rich.

What if you rename them, and instead of patching the manpages 
(admittedly hairy) adds  new, very short manpages which explains the 
renaming and refers to the original pages?


Cheers!

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

Re: F25 System Wide Change: Use /etc/distro.repos.d as default reposdir

[Alec Leamas]

On 19/05/16 21:26, Neal Gompa wrote:

On Thu, May 19, 2016 at 11:42 AM, John Florian <john.flor...@dart.biz> wrote:

From: Alec Leamas [mailto:leamas.a...@gmail.com]
Sent: Thursday, May 19, 2016 09:39
To: devel@lists.fedoraproject.org
Subject: Re: F25 System Wide Change: Use /etc/distro.repos.d as default
reposdir


I have yet to see the arguments why this really must be renamed. Of
course, there are better names than /etc/yum.repos.d. But does the
benefits of a better name really motivate the cost of change in this
case? Really?

In other words, as Mathieu Bridon pointed out, the "Benefit to Fedora"
part of the change just isn't very convincing.

I totally agree -- I too have yet to see why it should be renamed at all.  My 
point was merely that, if for some reason this does go forward (justified or 
not), it would be disappointing if this were to break the efforts of vendors 
that have been trying to cooperate in a reasonable manner.


The proposal has been revised to preserve compatibility with
/etc/yum.repos.d while supporting the new default directory.


Which is nice. However, the main point is  that to motivate all the 
obvious hassles related to the directory renaming  a better "Benefit for 
Fedora" section is needed  - IMHO the current one just doesn't motivate 
this change, the cons outweighs the pros.


Cheers!

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

Re: F25 System Wide Change: Use /etc/distro.repos.d as default reposdir

[Alec Leamas]

On 19/05/16 15:16, John Florian wrote:

From: Jonathan Wakely [mailto:jwak...@fedoraproject.org]
Sent: Wednesday, May 18, 2016 15:15

Another +1 here. There are plenty of software vendors (e.g. Google and
Adobe, to name two people might have heard of) that provide the option of
installing their software via an RPM, which installs a .repo file into
/etc/yum.repos.d. That's cool, well done software vendors, we should
applaud them, not break their stuff, or force them to provide one RPM
for Fedora and another for RHEL+CentOS etc.

Yes, please don't break their goodwill.  If this must be renamed, backwards 
compatibility is a must IMHO.


I have yet to see the arguments why this really must be renamed. Of 
course, there are better names than /etc/yum.repos.d. But does the 
benefits of a better name really motivate the cost of change in this 
case? Really?


In other words, as Mathieu Bridon pointed out, the "Benefit to Fedora" 
part of the change just isn't very convincing.


Just my 5 öre,

--alec

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

Re: is there a reason for starting zookeeper.service in background?

[Alec Leamas]

On 12/01/16 10:54, Muayyad AlSadi wrote:

the problem here is the bash script wrapped around


in the good old days of solr there used a param passed to solr.jar to
make the fork magic in java (maybe it was --daemon)
but now it's done in bash with "nohup" followed by "while true  lsof
-PniTCP:$SOLR_PORT -sTCP:LISTEN" to detect if it's up before exit


This script, right?


 nohup "$JAVA" "-Dzookeeper.log.dir=${ZOO_LOG_DIR}" 
"-Dzookeeper.root.logger=${ZOO_LOG4J_PROP}" \
-cp "$CLASSPATH" $JVMFLAGS $ZOOMAIN "$ZOOCFG" > "$_ZOO_DAEMON_OUT" 2>&1 < /dev/null 
&
if [ $? -eq 0 ]


Now, this script

 - Runs the process using nohup
 - Merges stderr with stdout
 - Forks directly on start.
 - Uses a bash parent as pid.

Nothing of this makes systemd's task simpler. Personally, I'd consider 
three routes:


 - If the socket availability doesn't matter, remove the nohup, 
redirection, fork stuff and use a "Type = simple" service. Presuming 
that the java process runs in foreground this should be fine.


 - If the java process runs in background anyway, it could be fixed by 
teaching it to write a pidfile (-> Type = forking). This should be a 
simple fix  which could be upstreamed.


 - If you need to socket(s) to be available and type = forking doesn't 
make it (exits parent to early, doesn't fork) the code should be fixed 
by teaching it to issue a sd_notify (-> Type = notify).


Just my 5 öre.


Cheers!

--alec


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

Re: is there a reason for starting zookeeper.service in background?

[Alec Leamas]

On 12/01/16 19:33, Muayyad AlSadi wrote:

Will I do agree it's a hack.
But it's better than forking in bash.

And usually I don't care about the exact time socket/port is active
because zookeeper is supposed to handle fail over.


[ the rest below..]


Please don't top-post [1]

Cheers!

--alec

[1] https://fedoraproject.org/wiki/Mailing_list_guidelines
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: is there a reason for starting zookeeper.service in background?

[Alec Leamas]

On 11/01/16 21:19, Christopher wrote:


I'm a co-maintainer for ZooKeeper, and I'd like to help get this right,
if possible. More importantly, I'm interested in setting a precedent for
Java system services in systemd. So, forgive my ignorance, but what
exactly is the generally recommended way of launching Java-based
applications as system services in systemd? Is there a good model to
follow? A Java service that gets this right?

Also, as I understand it, Java processes don't really fork in any way
that's useful here. The JVM has it's own internal threading model. So,
what's the best way for them to play nice with systemd? Should they all
be simple? Or should they all be launched by a shell script which
implements the double-forking paradigm? If the latter, wouldn't that add
a lot of complication that systemd is designed to eliminate with the
simplicity of writing units?



What about a simple JNI wrapper to sd_notify(3)? Shouldn't be hard, 
gives the process a chance to actually signal when its' ready.


Cheers!

--alec

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


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

Re: Specs using %define

[Alec Leamas]

On 24/12/15 22:01, Jason L Tibbitts III wrote:
> To satisfy my curiosity, I grepped the convenient tarball of specfiles
> (http://pkgs.fedoraproject.org/repo/rpm-specs-latest.tar.xz) for lines
> matching "(? there were more than 1900 hits.

> iguanaIR (leamas)

Fixed in git, no builds made.

Cheers!

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

Patching workflow (Was: Recommended way of proposing changes ...)

[Alec Leamas]

On Sun Oct 18 20:00:23 UTC 2015 Kevin Fenzi wrote

> On Sun, 18 Oct 2015 21:41:41 +0200
> Alec Leamas  wrote:
> 
>> Perhaps OT, but I cannot resist: Have you discussed the overall
>> workflow here? Cloning package, unpack sources, create patches, make
>> a build, revise patches, finalize the spec, perhaps upstream to
>> package owner...
> 
> Nope. As I said this has been just some "hey, it would be nice if" type
> discussions. If someone wants to commit to head up an effort around
> this that would be great, but I don't think anyone is currently. 

I think we should do something. Just to fuel the discussion, there is a
prototype at [1] in some "works occasionally" state. Would we be better
off with something like this?

Cheers!

--alec

[1] https://github.com/leamas/yab


-- 
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: Recommended way of proposing changes in someone else Fedora packages configuration

[Alec Leamas]

On 18/10/15 18:46, Kevin Fenzi wrote:
> On Sun, 18 Oct 2015 15:36:24 +0200
> Marcin Zajączkowski  wrote:
> 
>> Hi,
>>
>> I would like to propose a minor (yet important) change in one of the
>> Fedora packages configuration (a SPEC file and/or a patch). Is it
>> possible to create (something like) a pull request which could be
>> reviewed by the maintainer in some convenient way (*) and optionally
>> merged? Or the only way is to create a patch and put it into a Buzilla
>> ticket?
> 
> We have talked about such a frontend to pkgs.fedoraproject.org (most
> likely reusing code from pagure.io), but we haven't imemented anything
> yet. 

Perhaps OT, but I cannot resist: Have you discussed the overall workflow
here? Cloning package, unpack sources, create patches, make a build,
revise patches, finalize the spec, perhaps upstream to package owner...

All this is IMHO quite messy with a lot of manual steps (?). In the best
of worlds I could:

  - With a single command create an unpacked source directory with a
patch series reflecting the spec patches.
  - After creating/editing patches, just build using the new patchset.
  - When the patch(es) are finalized, have the spec updated in a single
command e. g., syncing the spec with a git or quilt series or so.
  - Of course, something like a pull request would be nice. But isn't it
the icing on the cake in this context?

Or is it perhaps already possible, I just missed how to do it?


--alec

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

Re: Packaging of PlayOnLinux

[Alec Leamas]

On 15/10/15 16:50, Michael Cronenworth wrote:
> On 10/15/2015 09:32 AM, Jiří Konečný wrote:
>> That's my backup solution. But why RPMFusion if there won't be any
>> problem with it in Fedora repository.
> 
> I just linked you the problem with it, which you snipped out.

Another precedence might be [1], where FPC deemed a framework capable of
downloading both free and non-free stuff as OK

--alec

[1] https://fedorahosted.org/fpc/ticket/362
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

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

[Alec Leamas]

On 09/10/15 21:13, Stephen Gallagher wrote:

> I completely, wholeheartedly agree with you here. However, the
> unfortunate fact of life is that we can lead a horse to water but
> cannot make them drink. Our previous policy was essentially holding
> the horse's head under the water until it drained the pond or drowned
> in it. I feel we can do better by being more moderate. The Unbundling
> SIG mentioned elsewhere in this thread is probably a more productive
> approach.

First, I generally agree that leaving the final decision to the packager
under the kind of umbrella proposed is the right thing to do.

That said, question is if we are leading the horse to the water? IMHO,
the proposed rules is more like pointing out the general direction to
the water for the poor horse (that's me, a mere mortal packager).

Perhaps Kevin K has a point in that these rules doesn't even require a
motivation from the packager when bundling. What if we required some
kind of process, still leaving the final decision to the packager? E.
g., requiring that all bundling should be at least reported to the FPC,
with a revised set of standard questions dealt with? Perhaps requiring
that FPC (or some other body) should be given the chance to give some
piece of advice before the bundled package is committed?

Whatever. But if we take bundling seriously, why not require some kind
of process? Not so complicated that it's simply avoided (as often
today), but still something which makes a packager think twice?


Cheers!

--alec

PS Sorry for not being able to match Stephens horse-drowning metaphor :) DS
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Proposal to reduce anti-bundling requirements

[Alec Leamas]

On 30/09/15 14:35, Stephen Gallagher wrote:

Just to circle around here (in case people don't read my reply to the
FESCo meeting agenda), I'm making the following revised proposal[1] to
FESCo which may or may not be discussed at today's meeting (given that
it was submitted late):


FWIW, I also find this a very balanced approach, even after taking 
Ralf's objections into consideration.


Thanks for bringing up this important issue!


Cheers!

--alec

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

Re: Packaging Icinga 2 requiring SELinux assistance

[Alec Leamas]

On 23/09/15 13:16, Petr Lautrbach wrote:

On 09/22/2015 08:46 PM, Shawn Starr wrote:



However in long terms it's better to incorporate a package policy  to
the system policy. You can either file a bug against selinux-policy or
try to contribute yourself using this [2] howto.


That howto is somewhat sketchy if you (as me) are new to this. However,
 Miroslaw has made some promises to improve it [3]

Cheers!

--alec

[3] https://github.com/fedora-selinux/selinux-policy/issues/38




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

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

[Alec Leamas]

On 15/08/15 11:21, Christopher Meng wrote:

And some people contributed a lot in the past, after this result will
you request revoking their sponsorship and wipe them out?

My thought is some of these above can be dropped since they indeed no
longer work in Fedora Project, leaving the privilege to them is
useless:


Perhaps. But the main problem is how to motivate more sponsors to 
actually do some sponsorship, right? Don't know if removing inactive 
people helps with that.


But this script (and message) might. Why not just now wait a little, and 
see if/how the situation changes after this (actually great) info is 
visible?



Cheers!

--alec

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

Re: [Fedora-packaging] Is it time to allow Chromium in Fedora?

[Alec Leamas]

On 12/08/15 17:14, Matthew Miller wrote:


It's important to note that popularity is not the sole reason for
exceptions for Firefox. Overall, everyone should review the existing
discussion in the guidelines about bundling exceptions and consider how
this might fit in (possibly including revisions if they make sense):
https://fedoraproject.org/wiki/Packaging:No_Bundled_Libraries#Some_reasons_you_might_be_granted_an_exception



Well, while true (I think), isn't  this only one side of the coin? The 
other is then the unresolved question how to make it easier to establish 
a useful set of tools which includes sw which for good reasons 
(non-free, GL breakage, etc) cannot be part of Fedora.


I wish I had some good solution, but... However, note all these 
post-install Fedora howtos out there which describes how to install 
things which is needed for many users, but cannot be part of Fedora 
repos (Chromium is one example). Is there really nothing we can do about 
this?


scratching my head

--alec

--
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: Submitting bodhi updates is very slow at the moment

[Alec Leamas]

On 12/05/15 13:36, Sérgio Basto wrote:

On Ter, 2015-05-12 at 09:39 +0100, Richard W.M. Jones wrote:



This update is currently being pushed to the Fedora 22 testing updates
repository. But isn't pushed yet (12 hours later !?) .



12 hours is nothing these days, infra seem to have problems. Currently 
waiting on 
https://admin.fedoraproject.org/updates/harctoolbox-1.1.2-4.fc21 (about 
two days); a dependency on that took four days from request to actually 
being pushed.


Patience is a virtue, isn't it :)

Cheers!

--alec

--
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: Naming packages when upstream uses dashes in the release version

[Alec Leamas]

On 06/05/15 10:21, Alexander Ploumistos wrote:


So, what would the rpm be named? foo-3.80.1-1.rpm or foo-3.80-1-1.rpm?
Is the latter a possibility?


No. The NVR is by definition foo-version-release, a thing like 
foo-3.80-1-1.rpm is basically illegal syntax.


Dashes in the name are OK since only the two rightmost dashes are parsed.

Cheers!

--alec
--
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: Naming packages when upstream uses dashes in the release version

[Alec Leamas]

On 06/05/15 10:51, Alexander Ploumistos wrote:

So basically, one could end up using foo-3.80-1.1.20150506.rpm,


No. The release part (here 1.1.2015050) should not contain any part of 
the upstream release number. The same goes for foo-3.80-1_1.rpm.


I think the reasonable options are foo-3.80_1-1.rpm or foo-3.80.1-1.rpm



Cheers!

--alec
--
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: Naming packages when upstream uses dashes in the release version

[Alec Leamas]

On 06/05/15 11:23, Alexander Ploumistos wrote:


I still think someone with more experience than me should add
something to the wiki,
https://fedoraproject.org/wiki/Packaging:NamingGuidelines#Separators
does not list such an exception (or if it does, I don't get it).



I think you are right. Also, the basic semantics that version part (i. 
e. Version: tag) is what upstream designates and release/Release: is 
what we as packagers set is not that clear.


OTOH, it does say that we should consult the list if unsure. Which 
seemingly worked for you, this time :)


Cheers!

--alec
--
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: Error with scratch build using fedora-create-review

[Alec Leamas]

On 05/05/15 20:56, Richard Shaw wrote:

That last couple of times I've used fedora-create-review I've gotten an
error:

$ fedora-create-review --user hobbes1...@gmail.com
mailto:hobbes1...@gmail.com rpmbuild/flmsg/SPECS/flmsg.spec
rpmbuild/flmsg/SRPMS/flmsg-2.0.10-1.fc21.src.rpm
Starting scratch build
Something happened while trying to build this package on koji:
  Uploading srpm: rpmbuild/flmsg/SRPMS/flmsg-2.0.10-1.fc21.src.rpm
[] 100% 00:00:01 861.74 KiB 667.20
KiB/sec
Created task: 9660851
Task info: http://koji.fedoraproject.org/koji/taskinfo?taskID=9660851
Watching tasks (this may be safely interrupted)...
9660851 build (rawhide, flmsg-2.0.10-1.fc21.src.rpm): free
SysCallError: (-1, 'Unexpected EOF')



Hm... this looks familiar... I think it *might* be a known bug in the 
infrastructure. Actually, I have encountered this also when doing plain 
koji scratch builds.


--alec

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

fedora-review karma.

[Alec Leamas]

Dear list,

We need some urgent karma for fedora-review. The reason is that an 
upcoming mock release breaks it unless this update is pushed [1].


So, karma would be very much appreciated for the current updates [2] and 
[3] so we can resolve this mess. If you need some testing done in return 
it can certainly be arranged.


Cheers!

--alec

[1] https://fedorahosted.org/FedoraReview/ticket/251
[2] https://admin.fedoraproject.org/updates/fedora-review-0.5.3-1.fc20
[3] https://admin.fedoraproject.org/updates/fedora-review-0.5.3-1.fc21
--
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-review karma.

[Alec Leamas]

On 04/05/15 18:55, Reindl Harald wrote:



Am 04.05.2015 um 18:52 schrieb Alec Leamas:

Dear list,

We need some urgent karma for fedora-review. The reason is that an
upcoming mock release breaks it unless this update is pushed [1].

So, karma would be very much appreciated for the current updates [2] and
[3] so we can resolve this mess. If you need some testing done in return
it can certainly be arranged.

Cheers!

--alec

[1] https://fedorahosted.org/FedoraReview/ticket/251
[2] https://admin.fedoraproject.org/updates/fedora-review-0.5.3-1.fc20
[3] https://admin.fedoraproject.org/updates/fedora-review-0.5.3-1.fc21


I forgot to add that these updates still are waiting tp be  pushed to 
updates-testing - you will need to download the package from the build 
manually to test it.


Cheers!

--alec

--
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] Ring-based Packaging Policies

[Alec Leamas]

On 14/02/15 01:45, Ken Dreyer wrote:


Here's the new policy that I would vote for:

1) We allow bundled libraries, and each bundled library MUST have a
virtual Provides: bundled(foo) in the RPM spec. (The packager SHOULD
provide a version number too, with the admission that it is sometimes
difficult to get this number correct.)

2) If another packager comes up with a patch to unbundle the library and files
the patch in Bugzilla, then the package maintainer MUST take the
patch.

3) If the package maintainer disagrees with the patch for whatever reason
(maybe it's a feature regression, or whatever), they MUST bring it to
the FPC for arbitration. The FPC must take into account the loss of
functionality that unbundling could imply.

This revised policy would lower the barrier to entry for newcomers,
and still leave room for more advanced contributors to do the work if
they desired to do so.


In the end, I guess this is a trade-off between doing the Right Thing 
from the overall security and distro maintenance perspective, and doing 
the Right Thing from the follow the upstream view.


My gut feeling is that this trade-off is differs in different 
communities. So, what happens if we discuss this from a language point 
of view?


What if we, as a a starter, applied such a policy to e. g., ruby 
packages?  Expanding to other languages over time in a more controlled way?



Cheers!


--
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] Ring-based Packaging Policies

[Alec Leamas]

On 12/02/15 19:32, Stephen Gallagher wrote:

(Logistical note: please keep all replies to this thread on
devel@lists.fedoraproject.org)

tl;dr Shall we consider requiring a lesser package review for packages
that are not present on Product or Spin install media?



Thanks for bringing this up. We really need to do something about this, 
and the proposal is likely to get things rolling.


This is really about two things, right? A lighter review and a general 
bundling exception for packages not in the core (?)


As for the bundling exception I more or less just agree. One detail 
might be to add some text about not having bundled libraries in system 
locations, and not exporting (filtering) them.


As for the lighter review this is not so clear to me. I agree that we 
need to relax the review, but:


  - Wouldn't it feel a little more comfortable to list the exceptions 
we allow compared to a regular review rather than starting with just 
some broad statements what the review is?


  - Shouldn't we make a distinction between 'review' and 'pass'. E. g., 
even if we allow bundled libs, we should definitely review and locate 
them. Isn't the situation similar for other things: while we still 
review them, things that are blockers in ring 0 could pass in ring 1?


Colin walters wrote:


Anyways, something I think is missing from here is more
details on how this on the install media set distinction
is maintained over time.  If it isn't separate (yum) repositories
it seems like it's going to be hard to enforce.



A virtual provides in all ring 1 packages?


Cheers!

--alec
--
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: Firefox addon signing

[Alec Leamas]

On 12/02/15 16:53, Simo Sorce wrote:


Malware can easily binary patch firefox to ignore verification, I do not
think trying to defeat sideloading with this kind of verification makes
much sense.
Of course you may decide to exempt only extensions in non-user-writable
locations, if you are on Linux and the Firefox binary is read-only for
the user.


Besides the technical issues, what does upstream permit? Since we havn't 
re-branded firefox, are we free to modify this whatever way we want? I 
can see the argument for upstream to limit such modifications without 
re-branding.


Cheers!

--alec

--
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: FESCo elections are open

[Alec Leamas]

On 03/02/15 19:19, Stephen John Smoogen wrote:


And yes, FESCO is mainly a social skills test and
workplace... all committees that have to deal with programmers and their
egos are going to be.


Amen :)

--alec

--
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: FESCo elections are open

[Alec Leamas]

On 30/01/15 16:10, Kevin Fenzi wrote:

On Fri, 30 Jan 2015 15:58:00 +0100
Alec Leamas leamas.a...@gmail.com wrote:



There were not really any questions directly related to products.
Perhaps some could be added next time?

In any case, I am in the Server working group myself, feel free to ask
the other candidates.



Fair enough. So, a  question  to all candidates: how are you related to 
the different products?


Cheers!

--alec
--
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: FESCo elections are open

[Alec Leamas]

On 30/01/15 16:24, Haïkel wrote:


If you don't trust your fellow contributor to do a good job, then,
feel free to apply to the position.


It's not like that, not at all. I think FESCo is doing a great job. I'm 
just raising the question about the balance between different interests. 
 The input so far has been encouraging at this point.


And no, I don't think I'd do a better job myself.


Cheers!

--alec


--
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: FESCo elections are open

[Alec Leamas]

On 27/01/15 01:01, Jaroslav Reznik wrote:

Greetings,
FESCo elections are now open and we're looking for five new
committee members. Elections closes promptly at 23:59 UTC
on February 3rd. Don't forget to vote!



Yes, too late, I know. But when I finally look at this I'm  bit 
confused, perhaps even troubled.


In short, with the new products and their corresponding governance, will 
not FESCo then handle a lot of coordination and sometimes even conflicts 
between those?. In this perspective, what does it mean that so many of 
the candidates seems to be Fedora Workstation people, and that no-one of 
the candidates mention any other product in their mission statement?


This is not only about products, but as a simple question I guess it's a 
starter (?)


Cheers!

--alec

--
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: Bundled libraries

[Alec Leamas]

On 08/01/15 18:07, Anshu Prateek wrote:

hi,

I am trying to package aerospike. It uses some of libraries as modules /
git sub-modules.

https://github.com/aerospike/aerospike-server/tree/master/modules

Do the jansson, jemalloc and luajit fall under the purview of bundled
libraries ?



Well, given that all of these are packaged in Fedora you need a FPC 
exception if you need to use the bundled ones.


Cheers!


--alec

--
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: Ramblings and questions regarding Fedora, but stemming from gnome-software and desktop environments

[Alec Leamas]

On 06/01/15 17:39, Bill Nottingham wrote:


- I shouldn't be searching for gcc, gcc-c++, make, etc. as separate
   promoted to GNOME Software applications; those should be treated as part
   of a development kit that's installed and updated as a unit, any more than
   I should be searching for libgweather or libdrm as part of installing a
   desktop app.


It seems like we could use DevAssistant for this. This would probably 
mean creating/polishing more toolchain-oriented separately packaged 
plugins as proposed by Bohuslav and some way to make them more visible 
as bug filed by Tomas Radej (all in this thread).




- Even searching for -devel packages implies a target == host build
   sensibility that is relevant mostly to those developing Fedora, and
   not to most of those developers that I run into on a day-to-day basis
   (and likely not the developers we're targeting.) They're interested
   in using mock along with system libraries for RHEL/CentOS, using
   pip/npm/rubygems, etc.


Indeed. Still, it seems like this boils down to that developers need a 
way to install packages, not just applications. Also, to be fair I don't 
really see if we could or should package all conceivable CLI-based tools 
into DevAssistant plugins, so also here a developer might need to be 
able to install packages. And large parts of this thread is about how 
this relates to gnome-software.


Another question is of course how things like python-pip and rubygem 
fits into the puzzle. But whatever the solution is for this, it's likely 
not gnome-software, agreed.


Cheers!

--alec


--
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: Ramblings and questions regarding Fedora, but stemming from gnome-software and desktop environments

[Alec Leamas]

On 05/01/15 10:04, Bohuslav Kabrda wrote:

- Original Message -



That said, what about describing  the developer usecase as a project,
focusing on a user using both GUI and CLI tools?

- Get the sources (if they exist).
- Install a toolchain, GUI-based or not.
- Install dependencies: -devel packages, interpreted modules, etc.
- Install project- or user-specific tools (GUI or not).
- Keeping the installed sw updated.

Installing the toolchain seems like DevAssistant to me. Besides this, I
understand your position as if users are supposed to use yum/dnf except
for GUI development tools and their dependencies (?)


Currently DevAssistant assistants (read: plugins) that we have in Fedora are more of 
kickstart a new project and install deps along rather than install a toolchain and perhaps 
do some other environment setup. This can however be easily extended by writing different plugins that 
will do just that.
E.g. I can imagine us having da prep fedora-dev c (which will BTW 
automatically gain a clickable counterpart in GUI) that will setup development 
environment for C (and similar for other languages). We can even provide some choices 
like --use-eclipse, --use-whatever-other-IDE, ... I'm willing to put my work into this, 
but I'm mostly a Python developer, so I'd need input from people working with languages.

Does that sound worth pursuing?



To my mind this looks attractive for the simple fact that multiple 
projects are more likely to share toolchain than dependencies.


But here is also questions e. g., are toolchains candidates for group 
installs or other existing mechanisms which  could be exposed in Gnome 
Software?  Would this than be an alternative and better way?


That said, what we really need here is the overall scheme, and this 
starts with the usecase. So: is the description above OK?


Given the usecase: if we use DevAssistent for the toolchain, which tool 
is then used for project dependencies in the general case? A modified 
Gnome Software or a general package manager like Gnome Packages?


Also, if we don't use Gnome Software for dependencies or the toolchain, 
what's then the role of it? A tool to keep the system updated? Isn't 
this then a rather massive overkill?


Cheers!

--alec
--
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: Ramblings and questions regarding Fedora, but stemming from gnome-software and desktop environments

[Alec Leamas]

On 05/01/15 06:25, Rahul Sundaram wrote:


That is potentially one way to address it.  I think it is somewhat
confusing to have two different interfaces for dealing with software and
it also means that the additional metadata included in GNOME Software
won't be available for command line utilities ...


And in the developer usecase, isn't this where this metadata would be 
really useful? As for tools, I think many (most?) developers already 
have strong preferences and choose them for a reason.


Dependency libraries is something different - haven't  we all been on 
thin ice with such ones and would have loved to have more input?



Cheers!


--alec
--
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: Ramblings and questions regarding Fedora, but stemming from gnome-software and desktop environments

[Alec Leamas]

On 05/01/15 10:18, Richard Hughes wrote:

On 5 January 2015 at 05:25, Rahul Sundaram methe...@gmail.com wrote:

That is potentially one way to address it.  I think it is somewhat confusing
to have two different interfaces for dealing with software


I think if we do want to re-include a package UI into the ISO by
default, we do need to do quite a bit of UI work on gnome-packagekit
as we don't want users to stumble on it and not know that another
interface that would serve them better is available.


Isn't this true also the other way around for Gnome Software: UI changes 
so that developers get a hint how to install things not covered by it 
like dependency libraries?


Cheers!

--alec

--
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: Ramblings and questions regarding Fedora, but stemming from gnome-software and desktop environments

[Alec Leamas]

On 02/01/15 21:05, Miloslav Trmač wrote:

- Original Message -

well, and that is why there are tasks you *can * do 1000 times more
better in a terminal or in a 3-liner shell script with one or two params
and others where you are much faster using the GUI

this world is grey

hence everybody start using Linux should *know* there are terminal apps
and which ones and make his own decision if they fit the usecase and in
doubt be able to use both worlds


The way I view it, there are two fairly separate cases:

A) Application development (with a wide definition of an “application” as 
“teaching the system to do something new”, i.e. all the way from simple aliases 
and pipelines through 10-line shell scripts all the way to 10k-line shell or 
Perl script monsters).

Yes, these things can’t be done in our GUIs nearly as easily, but there _really 
are_ large groups of people who never will, don’t want to, or are perhaps even 
forbidden from, doing such things (consider cashiers or bank tellers).  So it 
is quite reasonable to hide these capabilities until the user indicates some 
kind of interest in developing applications (where “indicates interest” today 
probably means a Google search, so we can get away with requiring one or two 
non-obvious but easy to do steps to get developer access).

Also note that the shell prompt is one of the worst application development 
environments still in wide use.  Very weak and inconsistent programming 
language, no module system, minimal auto-completion/intelligence, no inline 
help, horrible debugging tools even compared to 1980s Turbo Pascal.  It 
_should_ be possible to have a programming environment that is vastly easier to 
use than the shell prompt we have; but I have very little hope of this 
improving in the medium term.


B) Application usage, interacting with applications somebody else wrote.

Here, GUIs _as a category_ (not necessarily the GUIs we are currently 
providing) should always be better than CLIs _as a category_ simply because the 
GUI can in the worst case just copy the CLI layout and behavior so it will not 
be worse than a CLI; and then there are all the graphics and mouse interactions 
and shadows and animation that a GUI can do but a CLI can’t.

So to get the best sofware system possible we should 1) actually write such 
better GUIs, and 2) tell people that such better GUIs are available.


While I think you are right in some cases like cashier, isn't this 
discussion really about the Fedora Workstation?! Since for this the 
target user is a developer, can we just agree that in this case the user 
needs both CLI and GUI apps (although some developers certainly sticks 
to one of them).


Cheers!

--alec

PS: I'm not sure about all lines becoming fast. Doing remote sysadm over 
mobile connections comes to my mind. But this is *not* the workstation 
usecase... DS


--
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: Ramblings and questions regarding Fedora, but stemming from gnome-software and desktop environments

[Alec Leamas]

On 05/01/15 17:35, Stephen John Smoogen wrote:


Here in the fourth world USA, we aren't actually seeing a decrease in
slow lines but an increase as the oligarchy in control of networks is
figuring out ways to advertise faster speeds but actually only deliver
much slower ones. You can get 200 MB in a short burst and then 4.5 MB
and your upstream is most likely 128kb-256kb. I realize that Europe has
a much better infrastructure these days.. but 60% of Fedora customers
are in rural US regions which aren't as well served.

In any case, for everyone in this conversation. Please please please
don't make the assumption that because X does or does not work great for
you because of where you live etc.. that everyone else has the same
experience. Actually assume it is probably safer to assume that outside
of whatever reality bubble you live in, it is not.


I don't envy how the political climate on your continent has affected 
this for you. However, connecting to the top of this sub-thread, for the 
Fedora Workstation usecase this is not necessarily that bad - a 
developer works normally with local tools, although of course browsing 
and downloading is affected by network speed.


Cheers!

--alec
--
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: Ramblings and questions regarding Fedora, but stemming from gnome-software and desktop environments

[Alec Leamas]

On 05/01/15 19:10, Reindl Harald wrote:


Am 05.01.2015 um 17:48 schrieb Alec Leamas:

I don't envy how the political climate on your continent has affected
this for you. However, connecting to the top of this sub-thread, for the
Fedora Workstation usecase this is not necessarily that bad - a
developer works normally with local tools, although of course browsing
and downloading is affected by network speed.


no idea which sort of developers you know

where i work developemnt environments are running often on virtualized
remote machines at all because snapshots, backups and we develop network
aware applications at all

hence we have small shell scripts as commands in the PATH for common
tasks and i don't need to bother if i am at office in the same LAN, on
my home machine with a 365/24 VPN link or even on a smartphone over VPN
and can fire up basic tasks always the same way regardless of connection
speed and location


OK, what's normal clearly varies, agreed. But the conclusion in the 
Fedora Workstation context is actually the same: developers needs both 
CLI and GUI tools.


Cheers!

--alec

--
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: Ramblings and questions regarding Fedora, but stemming from gnome-software and desktop environments

[Alec Leamas]

On 02/01/15 11:42, Richard Hughes wrote:


Because as of now, gnome-software just doesn't fit the workstation bill


I think you're misunderstanding what most developers do. We probably
spend about 10 minutes installing development packages (on the command
line) when setting up a new OS instance. I then spend a year or so of
installing or removing the odd application, and a few minutes every
week applying updates. I don't think GNOME Software is hugely useful
for installing low-level developer packages, which is fine. It doesn't
mean it's not a useful application.


I don't know if most developers works with more or less just one 
toolchain and environment as you describe. At least some actually 
works in a lot of projects, with different development packages and 
sometimes also tools.


That said, what about describing  the developer usecase as a project, 
focusing on a user using both GUI and CLI tools?


- Get the sources (if they exist).
- Install a toolchain, GUI-based or not.
- Install dependencies: -devel packages, interpreted modules, etc.
- Install project- or user-specific tools (GUI or not).
- Keeping the installed sw updated.

Installing the toolchain seems like DevAssistant to me. Besides this, I 
understand your position as if users are supposed to use yum/dnf except 
for GUI development tools and their dependencies (?)


To my mind, forcing user to the prompt to this extent is less than 
ideal. A GUI installer certainly has advantages even for an occasional 
CLI user. And having to use different installers is a Bad Thing.



Rather than talking in riddles in your emails, could you also please
suggest what needs to be done? Are you in favour of ripping out
gnome-software and installing yumex in the workstation image? Do you
have an alternate application proposal with design mockups?


At this point, I'm just trying to understand the usecase. Without that, 
decisions like using yumex instead of gnome-software makes no sense, nor 
does mock-ups. It's also a question to what extent upstream is willing 
to support this usecase.


That said, my gut feeling is that the balance between simplicity and 
functionality is quite different for a novice user and a developer and 
that this needs to be handled with different modes, views or so (if 
gnome-software should handle it). Adding things like random CLI 
applications, -devel packages etc. to the search result for a  novice 
user is just not an option, agreed. But IMHO a developer probably needs 
it in some form.


Cheers!

--alec

--
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: Ramblings and questions regarding Fedora, but stemming from gnome-software and desktop environments

[Alec Leamas]

On 03/01/15 20:26, Hedayat Vatankhah wrote:



/*Luya Tshimbalanga*/ wrote on Fri, 02 Jan 2015 17:29:14 -0800:






Add-ons cannot cover development libraries, unless every library is
an add-on for all IDEs!



Then is IDE packaging issue. When it comes of using a development
applications, the software should suggest installing the missing
library. If Gnome Video is able to prompt uses to install missing
component, then why shouldn't be possible for IDE application to do
the same?
Granted I don't know well the functionality but the logic is
application should detect and suggest adding the missing function.



Hmm... that's weird, I can't understand what you mean. Gnome Video's job
is very easy: a video has a special format, and there are specific
plugins to enable playing that. However, assume that I need an XML
library for C++:
1. How can I tell the IDE that I need an XML library?
2. What should IDE do if there are 5 different XML libraries for C++?
How should I tell it which one I want, specially if I don't know what
should I use already, and want to see what is available out there?

To me, it seems like implementing a special purpose software manager
inside IDE with almost all functionality GNOME Software provides. As I
said in another post, user reviews/rating for development libraries
(like what GNOME Software provides for applications) can be really
helpful when a developer wants to choose a library for a specific purpose.


In other words: there is a difference between the toolchain and project 
dependencies.


The toolchain e. g. eclipse + gcc etc. can be probably partly be fixed 
using IDE dependencies, DevAssistant and similar setups reflecting 
general tool-set dependencies, agreed.


OTOH, the dependencies for a specific project cannot really be handled 
this way. Such libraries are specific for the code you build, not the 
tools. Making them dependencies of e. g., eclipse just doesn't make any 
sense.



Cheers!

--alec

--
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: Ramblings and questions regarding Fedora, but stemming from gnome-software and desktop environments

[Alec Leamas]

On 31/12/14 16:25, Richard Hughes wrote:

On 30 December 2014 at 23:31, Chris Murphy li...@colorremedies.com wrote:

b.) Would it be helpful, friendlier, and better emphasize the special
focus, if these group install items mentioned above were exposed in
GNOME Software with an appropriate icon?


We could do this right now, although I don't think expose the entire
comps tree makes a lot of sense.


Here is also questions whether this is the right thing to do, I guess 
many packages, notably -devel ones, doesn't belong to a group. How 
should these then be handled?


And from a user perspective, if you already *know* that you need to 
install e.g., gcc  or foo-devel first finding the proper group to 
install seems a bit awkward.


Perhaps this path also might create pressure to include all sorts of 
things into the groups, a misuse of the groups feature?


[cut]


Installing a compiler is something that *something*
needs to handle, I'm just not sure if that should be gnome-software
itself or something that *uses* gnome-software to do the correct thing
and to handle updates.


Here is a some common ground, indeed. Seems that we agree on that 
installing CLI stuff is something that should be handled in a 
developer-oriented workstation (not that you have said something else, 
but some others).


Now, in my mind installing/updating non-GUI software is not a 
corner-case for a developer - it's probably the most common installation 
done even when working with GUI tools. Because even so you need tools 
such as compilers but also libraries/-devel packages. And often lot's of 
them.


From this perspective, I guess that if gnome-software (g-s) upstream 
defines installing CLI stuff as something which should be handled by 
something else, I cannot really see the point handling updates in g-s. 
Rather, g-s would then become a nice add-on to browse and install GUI 
applications.


In the end, isn't this one hand about if gnome-software's upstream is 
willing to undertake the work to adapt also to the developer usecase? 
And on the other, which tool the workstation group should use for 
graphical software installations? Because as of now, gnome-software just 
doesn't fit the workstation bill?


Cheers!

--alec
--
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: CLI tools in Gnome Software?

[Alec Leamas]

On 01/01/15 23:25, Hedayat Vatankhah wrote:


Michael Catanzaro mcatanz...@gnome.org wrote on Tue, 23 Dec 2014 12:43:40 
-0600:



On Tue, 2014-12-23 at 17:12 +0100, Dridi Boukelmoune wrote:

Are CLI tools welcome in Gnome
Software?



No, we don't consider CLI tools to be applications, and only
applications should be displayed in GNOME Software.



I don't mind if GNOME doesn't consider console applications as
applications; but I really think that Fedora should not go that route.


Isn't this an already ongoing discussion in recent subthreads in [1] and 
[2]?


--alec

[1]https://lists.fedoraproject.org/pipermail/devel/2014-December/205820.html

[2] 
https://lists.fedoraproject.org/pipermail/devel/2014-December/205820.html


--
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: Ramblings and questions regarding Fedora, but stemming from gnome-software and desktop environments

[Alec Leamas]

On 30/12/14 13:07, Ralf Corsepius wrote:

On 12/29/2014 04:48 PM, Alec Leamas wrote:


And if walking this path, the Workstation default mode would be the one
corresponding to a developer, right?



Define Workstation. I don't know which audience the people, who
implemented it, were aiming at - It definitely wasn't my use-case scenario.


The only definition I'm aware of is [1].

Cheers!

--alec

[1]: http://fedoraproject.org/wiki/Workstation/Workstation_PRD
--
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: Ramblings and questions regarding Fedora, but stemming from gnome-software and desktop environments

[Alec Leamas]

On 30/12/14 20:57, Luya Tshimbalanga wrote:

On 29/12/14 04:33 AM, Alec Leamas wrote:


This certainly works, but is it really a reasonable trade-off  in a
developer context where things like compilers and interpreters are
part of the very core? What role does Gnome Software play here? How
fruitful is the idea to hide packages in this context?



Compiler and  interpreters i.e.Glade having GUI and implements app-data
(supposedly mandatory starting on Fedora 22)  will be displayed on Gnome
Software.


Glade is neither a compiler nor an interpreter, it's an IDE.


Gnome Software is to abstract the package concept to only
focus on applications accessible to desktop.


Agreed. And I can see some usecases where this makes a lot of sense.

But the question then becomes if this is the proper thing to do for the 
Workstation target user which is a developer. As such, she will in many 
cases want to install things like gcc, different python stacks using 
collections, text processing tools and so on. None of which with a GUI. 
She will also sometimes be interested in multiple desktops for testing 
etc., causing the MATE apps not visible problem.


Bottom line: isn't there is a mismatch between Gnome Software (GUI 
applications only) and the idea of a developer using both CLI and GUI 
tools?  And if so, how should it be handled?



Cheers!

--alec


--
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: Ramblings and questions regarding Fedora, but stemming from gnome-software and desktop environments

[Alec Leamas]

On 30/12/14 22:58, Luya Tshimbalanga wrote:

On 30/12/14 12:34 PM, Alec Leamas wrote:

On 30/12/14 20:57, Luya Tshimbalanga wrote:

On 29/12/14 04:33 AM, Alec Leamas wrote:



Gnome Software is to abstract the package concept to only
focus on applications accessible to desktop.


Agreed. And I can see some usecases where this makes a lot of sense.

But the question then becomes if this is the proper thing to do for
the Workstation target user which is a developer.


[cut]


What about DevAssistant that comes with Fedora Workstation? Have you
tried it?


No, it doesn't seem to solve any problem for me (?). That said, while 
such solutions certainly might be useful a generic installer application 
represents some kind of foundation I think all developers will need, 
sooner or later. Different devs, different ideas, different needs - not 
all can be shrink-wrapped.



MATE apps not visible means they needed app-data included on their
.desktop files hence the pleas from Richard Hughes.
The case of multiple desktop installation reaches  advanced use
territory meaning advanced tool like yumex.


Still the same question: is there a mismatch between the  GUI only Gnome 
Software (GS) and the Workstation target user presumably using both CLI 
and GUI tools + perhaps multiple desktops?


If you describe this as advanced use, should we read this as if the 
Workstation developer usecase is too advanced for GS?


And if the target usecase is too advanced for GS, what is then the role 
for GS in the Workstation product?



Cheers!

--alec
--
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: Ramblings and questions regarding Fedora, but stemming from gnome-software and desktop environments

[Alec Leamas]

On 30/12/14 22:58, Luya Tshimbalanga wrote:

On 30/12/14 12:34 PM, Alec Leamas wrote:

On 30/12/14 20:57, Luya Tshimbalanga wrote:



Bottom line: isn't there is a mismatch between Gnome Software (GUI
applications only) and the idea of a developer using both CLI and GUI
tools?  And if so, how should it be handled?



No. Fedora Workstation already provided needed tools for CLI like Gnome
Terminal included by default.


Again: this is not about Gnome (I'm an overall happy Gnome user). It's 
about Gnome Software, the installer, and only that.


--
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: Ramblings and questions regarding Fedora, but stemming from gnome-software and desktop environments

[Alec Leamas]

On 29/12/14 10:50, Richard Hughes wrote:

On 29 December 2014 at 03:28, Stephen John Smoogen smo...@gmail.com wrote:

we either are going to have to get out of the way of the
steamroller or get rolled over it.


[cut]


Linux isn't UNIX. The desktop doesn't revolve about command line tools
anymore. If you can't accept that, you probably need to change
industry. Sorry to be blunt.


2014-12-28 21:38 GMT+02:00 Michael Catanzaro mcatanz...@gnome.org:


What's important is that we want Workstation to be excellent for users who
never touch the terminal.


Great. But what if the design decisions based on this leads to a system 
which becomes needlessly complicated for other users, which also uses 
CLI tools?


Frankly, I think it's easier to alienate current devs (some of which 
using CLI tools) than to attract new ones. So, pushing this goal too 
hard might have consequences.


 On 28/12/14 10:50, Richard Hughes wrote:

on 28 December 2014 at 00:23, Alexander Ploumistos

alex.ploumis...@gmail.com wrote:

Should Fedora build another program as a package manager?


GNOME PackageKit is still available (and maintained upstream) and is
what I use for installing things like mingw packages that I need for
development.


This certainly works, but is it really a reasonable trade-off  in a 
developer context where things like compilers and interpreters are part 
of the very core? What role does Gnome Software play here? How fruitful 
is the idea to hide packages in this context?


Note that I have full respect for your goals. I use Gnome myself, and I 
didn't find 3.0 to painful :) It's just that I don't really see how the 
priorities for Gnome Software aligns with developer realities (while 
they make perfect sense for other types of users)


That said, everything is fine if the Fedora Workstation target user is a 
developer just using GUI tools. But I don't see this in the PRD.


Cheers!

--alec

--
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: Ramblings and questions regarding Fedora, but stemming from gnome-software and desktop environments

[Alec Leamas]

On 29/12/14 16:18, Richard Hughes wrote:

On 28 December 2014 at 15:48, Alec Leamas leamas.a...@gmail.com wrote:

wouldn't it raise questions about the Gnome Software application's role in
the workstation product?


I don't think it does, no. I'm a Red Hat employee, a Fedora user, but
also a GNOME developer. I'm not terribly keen pushing the tenet of
GNOME Software doesn't show MATE applications when running in GNOME
to GNOME Software isn't suitable for Fedora Workstation.


Fair enough. But to me, adding GNOME Software (GS) also cannot install 
compilers, interpreters and other CLI tools creates a more problematic 
situation.


And even the MATE applications issue is actually *very* different when 
evaluated in a developer context. A developer is both more likely to be 
 interested in using multiple desktops (testing) and also probably more 
capable of handling the complexity required.


Is GS intended to be a one size fits all solution for both novice 
users and the workstation target developer user?  If so, I cannot 
really see how this could be handled reasonably unless there is explicit 
support for the different roles e. g., some kind of modes or so.


And if walking this path, the Workstation default mode would be the one 
corresponding to a developer, right?


Cheers!

--alec

--
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: Ramblings and questions regarding Fedora, but stemming from gnome-software and desktop environments

[Alec Leamas]

On 27/12/14 23:26, Richard Hughes wrote:

On 26 December 2014 at 20:32, Alexander Ploumistos



If gnome-software aims to be novice-user-friendly, at least the latter should 
definitely be an option.


I don't see the logic there, sorry. Novice users don't understand the
fine nuances of the design choices of different desktop environments.


Possibly. But isn't there quite a difference between the novice user 
and the Fedora Workstation target user i. e., developers?


If so, it doesn't need to be bad - Gnome is is certainly not Fedora. But 
wouldn't it raise questions about the Gnome Software application's role 
in the workstation product?


Cheers!

--alec

--
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: Ramblings and questions regarding Fedora, but stemming from gnome-software and desktop environments

[Alec Leamas]

On 28/12/14 18:05, Michael Catanzaro wrote:

On Sun, Dec 28, 2014 at 9:48 AM, Alec Leamas leamas.a...@gmail.com wrote:

Possibly. But isn't there quite a difference between the novice user
and the Fedora Workstation target user i. e., developers?


Not necessarily. I wrote:

Yes, Workstation targets developers, but not exclusively, and also
developers who use fancy IDEs and who don't work with the terminal. I
just don't want this thread to degenerate into a discussion of this
lousy definition [of normal/novice users], since it's not important.
What's important is that we want Workstation to be excellent for users
who never touch the terminal.



Hm... developers which never touches the terminal?! Seems like a really 
narrow group (?)




Fedora currently suffers from the impression that it is a complicated OS
for advanced users only, and that novices (including novice developers)
should use Ubuntu instead.


I have full sympathy for this goal. Question is if it aligns with the 
developer target for the workstation?


--
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: Incorrect FSF Address error from rpmlint

[Alec Leamas]

On 2014-12-23 20:28, Gerald B. Cox wrote:

I'm getting an incorrect FSF address when I'm building a package.

I checked here:
http://fedoraproject.org/wiki/Common_Rpmlint_issues#incorrect-fsf-address

and built the package with the recommended file.  Still get the error.

I checked the address with FSF, and what is in the COPYING file matches:
http://www.fsf.org/about/contact/

I then checked bugzilla and found:
https://bugzilla.redhat.com/show_bug.cgi?id=700095

which as been open since April, 2011.

Am I missing something here?  If there is indeed an error that I'm 
missing I would
like to understand it so I can notify upstream to do the right thing.  
If this is just
a rpmlint glitch it really should be addressed - otherwise people tend 
to start ignoring

the errors and warnings.


The check is not only  applied to  COPYING but also to the license text 
in source files. Have you checked those?



Cheers!

--alec

--
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: Incorrect FSF Address error from rpmlint

[Alec Leamas]

On 23/12/14 21:55, Gerald B. Cox wrote:


On Tue, Dec 23, 2014 at 11:42 AM, Alec Leamas leamas.a...@gmail.com
mailto:leamas.a...@gmail.com wrote:

The check is not only  applied to  COPYING but also to the license
text in source files. Have you checked those?


Got it.  Thanks!



You're welcome.

BTW, in many cases I been able to fix these problems by sending patches 
rather than just complaints upstream. Basically, I think we (i. e. 
Fedora) are the which are concerned about this, and in that situation we 
are the ones motivated enough to provide a patch.


For upstream, merging such a patch is simple; it's just about comments 
and docs.



Cheers!

--alec
--
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: chromium

[Alec Leamas]

On 20/12/14 17:40, Christopher wrote:

The fact that there isn't a popular 3rd-party repo packaging Chromium
does not appear to be relevant to Fedora. I don't see anybody
discouraging it. Perhaps you should approach a popular 3rd-party to
suggestion packaging Chromium in their repos?



I  made an attempt on this, which really is about the larger issue to 
package a foreign repo in rpmfusion. However, this is stalled due to 
different views on if/how this should be handled.


--alec

PS: Please don't top-post. DS

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

License change: lirc

[Alec Leamas]

Current version in rawhide is (GPLv2 and MIT). As of 0.9.0, the license 
was plain GPLv2.

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

lirc: so-name bump

[Alec Leamas]

I have pushed a new version 0.9.2 of lirc to rawhide. It changes the 
so-name from 2:1:2  to  3:0:3 .


I'm sorry for not notifying in advance, I  just missed it.

This is  upwards-compatible change, so while there is a need to rebuild 
it can wait for some time.



The following apps are affected:

audacious-plugins
banshee-community-extensions
geeqie
gnomeradio
gxine
kradio4
lcdproc
lxdream
media-explorer
mplayer
mplayer-gui
mpv
ncmpc
pulseaudio-module-lirc
python-lirc
rhythmbox-lirc
rosegarden4
totem-lirc
vlc-core
xine-ui
xmms-lirc


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

lirc: so-name bump

[Alec Leamas]

I have pushed a new version 0.9.2 of lirc to rawhide. It changes the 
so-name from 2:1:2  to  3:0:3 .


I'm sorry for not notifying in advance, I  just missed it.

This is  upwards-compatible change, so while there is a need to rebuild 
it can wait for some time.



The following apps are affected:

audacious-plugins
banshee-community-extensions
geeqie
gnomeradio
gxine
kradio4
lcdproc
lxdream
media-explorer
mplayer
mplayer-gui
mpv
ncmpc
pulseaudio-module-lirc
python-lirc
rhythmbox-lirc
rosegarden4
totem-lirc
vlc-core
xine-ui
xmms-lirc


--
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: Workstation Product defaults to wide-open firewall

[Alec Leamas]

On 09/12/14 18:39, Stephen John Smoogen wrote:



On 9 December 2014 at 10:27, Chris Murphy li...@colorremedies.com


[cut]


OS X's firewall is disabled by default. Where's the outcry?


It was a long time ago and it basically caused it to have extra
configurations before it could be 'ok'd' for various corporate and
government sites. Not something Fedora Workstation is aiming at.


Hm... has anyone a feeling about how such entities would react to the 
current firewall defaults (open for user ports)?  Do we care?



Cheers!

--alec

--
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: Workstation Product defaults to wide-open firewall

[Alec Leamas]

On 09/12/14 18:53, Stephen John Smoogen wrote:


In the end, this is a tempest in a teapot. The release is out and it is
done. I don't like it, but my yelling and screaming and spitting in an
autistic rage did not fix it so its time to move on so that is what I am
going to do.


Amen

--alec

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