Re: Maven tycho Plugin and Reproducible Version Qualifiers

[Michal Srb]

On 11/08/2013 08:18 AM, Manuel Faux wrote:

I'm trying to create a package of a maven project. The project uses the
tycho-packaging maven plugin with reproducible version qualifiers.

I am not checking out the git repository of the project, but a tgz
bundle. Therefore tycho cannot do any git operations and fails with the
following error:

[ERROR] Failed to execute goal
org.eclipse.tycho:tycho-packaging-plugin:0.18.1:build-qualifier
(default-build-qualifier) on project org.eclipse.osgi: Execution
default-build-qualifier of goal
org.eclipse.tycho:tycho-packaging-plugin:0.18.1:build-qualifier failed:
One of setGitDir or setWorkTree must be called. -> [Help 1]

Does anyone have a suggestion how to ether disable the reproducible
version qualifiers functionality of tycho, or how else to circumvent
this error?

Manuel
I am not familiar with tycho enough, but I would recommend asking this 
question on java-devel mailing list.


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

[Bug 989982] perl-SOAP-Lite-1.06 is available

[bugzilla]

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



--- Comment #6 from Petr Šabata  ---
The new release also no longer ships with several other modules which should be
packaged before the update, namely UDDI::Lite, XML::Parser::Lite, and
XMLRPC::*.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
Unsubscribe from this bug 
https://bugzilla.redhat.com/token.cgi?t=A0PdzIuWZC&a=cc_unsubscribe
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-de...@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel

Re: What user and password to use in cloud images?

[Juan Orti Alcaine]

El 2013-11-08 08:05, Kushal Das escribió:
On Fri, Nov 8, 2013 at 10:44 AM, Daniel P. Berrange 
 wrote:



I actually thought that logins were locked by default and required
the cloud host to provide the metadata service for cloud-init to
run and inject SSH keys.


You are correct, to login into the instance one has to run the metadata 
service.

Just now tested the RC5 image on an Openstack installation, login
works fine for "fedora" user.



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

Maven tycho Plugin and Reproducible Version Qualifiers

[Manuel Faux]

I'm trying to create a package of a maven project. The project uses the
tycho-packaging maven plugin with reproducible version qualifiers.

I am not checking out the git repository of the project, but a tgz
bundle. Therefore tycho cannot do any git operations and fails with the
following error:

[ERROR] Failed to execute goal
org.eclipse.tycho:tycho-packaging-plugin:0.18.1:build-qualifier
(default-build-qualifier) on project org.eclipse.osgi: Execution
default-build-qualifier of goal
org.eclipse.tycho:tycho-packaging-plugin:0.18.1:build-qualifier failed:
One of setGitDir or setWorkTree must be called. -> [Help 1]

Does anyone have a suggestion how to ether disable the reproducible
version qualifiers functionality of tycho, or how else to circumvent
this error?

Manuel
-- 
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: What user and password to use in cloud images?

[Kushal Das]

On Fri, Nov 8, 2013 at 10:44 AM, Daniel P. Berrange  wrote:

> I actually thought that logins were locked by default and required
> the cloud host to provide the metadata service for cloud-init to
> run and inject SSH keys.

You are correct, to login into the instance one has to run the metadata service.
Just now tested the RC5 image on an Openstack installation, login
works fine for "fedora" user.

Kushal
-- 
http://fedoraproject.org
http://kushaldas.in
-- 
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: What user and password to use in cloud images?

[Daniel P. Berrange]

On Thu, Nov 07, 2013 at 11:16:08PM +0100, Juan Orti Alcaine wrote:
> El Jueves, 7 de noviembre de 2013 14:55:57 Kevin Fenzi escribió:
> > On Thu, 07 Nov 2013 21:56:54 +0100
> > 
> > Juan Orti Alcaine  wrote:
> > > Hello, I've deployed a Fedora20 Beta qcow2 image in a VM, but I'm
> > > unable to login.
> > > 
> > > What is the default user and password?
> > 
> > user 'fedora' and no password (which you will be unable to login to via
> > ssh since sshd defaults to not allowing empy passwords). You should be
> > able to login on console tho.
> > 
> 
> I cannot login with the user 'fedora'. I'm connected to the console (it is a 
> CloudStack  cloud), and have tried all combinations of ec2-user/fedora 
> /passwords/without-passwords.
> 
> I also have tried in a local KVM vm, but cannot login.
> These are the images I have used:
> 
> Fedora-x86_64-20-Beta-TC6-20131026-sda.qcow2
> Fedora-x86_64-20-Beta-20131106-sda.qcow2
> 
> Should I report a bug or I am missing something?

I actually thought that logins were locked by default and required
the cloud host to provide the metadata service for cloud-init to
run and inject SSH keys.

Daniel
-- 
|: http://berrange.com  -o-http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org  -o- http://virt-manager.org :|
|: http://autobuild.org   -o- http://search.cpan.org/~danberr/ :|
|: http://entangle-photo.org   -o-   http://live.gnome.org/gtk-vnc :|
-- 
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: OpenH264 in Fedora

[Michael Catanzaro]

On Sat, 2013-11-02 at 08:11 -0700, Gregory Maxwell wrote:
> The rtcweb WG session which will discuss MTI video codec will be on
> Thursday the 7th at 13:00 pacific. As usual the meeting will be
> streamed and anyone can participate remotely via Jabber
> (rtc...@jabber.ietf.org), but feedback can be provided at any time via
> the mailing list (and it's probably best to comment earlier rather
> than later, links at http://tools.ietf.org/wg/rtcweb/).

Results can be found at [1] but the summary is: no consensus on an MTI
codec. I guess they're pursuing "alternative consensus" now: agreeing on
how to decide despite disagreement.

It's worth calling out thanks to Florian and Toshio for representing our
community on the WebRTC mailing list.

[1]
http://blog.webrtc.is/2013/11/07/live-blogging-ietf-88-mti-video-codecs/:



signature.asc
Description: This is a digitally signed message part
-- 
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: AppData questions

[Rex Dieter]

Richard Hughes wrote:

> On 6 November 2013 10:41, Michael Schwendt  wrote:
>>   # rpm -qf /usr/share/app-info/xmls/fedora-20.xml.gz
>>   gnome-software-3.10.3-1.fc20.x86_64
>> does.
> 
> It's AppStream metadata.

Similarly, in order to make apper/kde work, it needs appstream,
https://bugzilla.redhat.com/show_bug.cgi?id=appstream

which claims to be a (the?) tool to create some necessary database, how does 
this fit in (if at all)?

-- Rex

-- 
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: unaccessability

[Rahul Sundaram]

HI


On Thu, Nov 7, 2013 at 6:51 PM, Adam Williamson  wrote:

> Honestly, I don't think Software is really aimed at your use case, and
> you may as well just keep using yum. It's meant to be a cool way to find
> neat software, not a comprehensive package catalog.
>

Part of the problem that I have with that response is that Fedora will
provide no gui for a package catalog by default and finding new software is
often interconnected with installing known software.  You go in looking for
say openarena and decide to check out what fun new games are available.
You want to read about reviews on tmux and screen and decide which one to
install.   Yum doesn't provide me with a convenient view and yumex isn't
provide me with any screenshots or reviews.   It would be awfully
convenient to have a single place for all these related tasks.

Rahul
-- 
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: unaccessability

[Adam Williamson]

On Thu, 2013-11-07 at 16:37 -0500, Christian Schaller wrote:
> Ok, so I guess the solution would be for the launcher to do something like 
> this:
> 
> gnome-terminal --geometry 80x37 --disable-factory --role=bitchx 
> --class=bitchx --name "bitchX IRC" --title "BitchX IRC"
> 
> That said Ray mentioned that this is probably not supported yet in the Shell 
> launcher. 
> 
> Anyway, as Richard says, we should have a proper design discussion around 
> this and not just add a ton of .desktop files without thinking through the 
> presentation
> and how it will work. But feel free to file some bug reports to kick of a 
> discussion.

Right, I'm a bit worried about tail-wagging-dog here. Please, no-one go
around throwing .desktop files in terminal apps just to try and get them
to show up in Software. Your package should have a .desktop file only if
it actually makes some sense that someone would want to launch it from a
desktop environment's menus / launcher thingy.
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net

-- 
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: unaccessability

[Adam Williamson]

On Thu, 2013-11-07 at 13:09 -0500, Rahul Sundaram wrote:
> Hi
> 
> 
> On Thu, Nov 7, 2013 at 12:56 PM, Florian Müllner 
> wrote:
> 
> 
> I guess the main obstacle here is that there isn't really a
> good
> criterion which is as clear-cut as "installs a (non-NoDisplay)
> .desktop file" => "this is a user-visible gui application" for
> gui
> applications - mutt certainly is a user application, sshd
> clearly is
> not, zsh ... maybe?
> 
> 
> Why do you want to differentiate between Mutt and sshd?  If a user
> wants to install a specific piece of software, they search for it
> within a gui and if it matches, they install it and move on.  If you
> really need some way to differentiate, you can have some form of
> tagging via fedora tagger or appdata which you can include in more
> than just gui packages.  
> 
> When I want some software,  say Epiphany and Mutt, if I can only use
> the installer for the Epiphany but I have to use yum for Mutt, I
> rather just use yum for both where I don't have to switch between two
> different ways of getting it.   I don't mind the focus on gui
> applications but leaving out command line tools altogether forces me
> to think about whether say htop would be considered a application by
> the installer or not which is not the level I want to differentiate at
> all.  When I search for something within the installer and it returns
> nothing, is it because there is genuinely nothing that matches what I
> want within the repositories or is the installer just excluding it
> based on implementation level details like desktop files and appdata?
> How would I know?  It is just too complex. 

Honestly, I don't think Software is really aimed at your use case, and
you may as well just keep using yum. It's meant to be a cool way to find
neat software, not a comprehensive package catalog.
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net

-- 
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: Draft Product Description for Fedora Workstation

[Adam Williamson]

On Thu, 2013-11-07 at 16:58 +0100, Kevin Kofler wrote:
> Bastien Nocera wrote:
> 
> > - [Florian Weimer wrote:] -
> >> "Wayland" and "systemd" strongly suggest no Ubuntu interoperability
> >> whatsoever.  Shouldn't this be a top priority for bundled applications?
> > 
> > If we get any traction on this, their customers/users will ask them for it
> > themselves.
> 
> Hahaha, you really think you can force Canonical into adopting your 
> technologies that way? LOL! This is going to backfire spectacularly! (My 
> guess: Canonical will come up with their own Ubuntu App model requiring 
> Ubuntu technologies and all the third-party developers you are trying to 
> attract will target only that one.)

They already *have* one:

http://shop.canonical.com/index.php?cPath=19

I have no idea how it works or where it's documented, but it exists.
Given that it's there and working and people are using it, the
obligation would seem to be on any group that comes along later to try
and implement something similar to:

i) evaluate Ubuntu's system for its potential to be used outside of
Ubuntu
ii) If it's not ready to be used outside of Ubuntu as-is, propose a
future development path which would result in interoperability and ask
the developers of the Ubuntu system if they're willing to work down such
lines, and make a genuine effort to have that come about, even at the
cost of short-term inconvenience in development
iii) If that proves impossible, communicate the situation and the
attempts that were made clearly and publicly

I'd therefore suggest anyone trying to invent a new app-level
distribution mechanism go and look at and produce a formal evaluation of
all the existing efforts in the space, including this one, before
inventing something else new.
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net

-- 
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: Draft Product Description for Fedora Workstation

[Adam Williamson]

On Thu, 2013-11-07 at 16:15 +0100, Lennart Poettering wrote:
> On Thu, 07.11.13 03:53, Kevin Kofler (kevin.kof...@chello.at) wrote:
> 
> > Olav Vitters wrote:
> > > AFAIK (not sure), it should come somewhat easy once you the distribution
> > > is based upon systemd.
> > 
> > That means it will exclude the most popular distribution out there.
> 
> If you are referring to Ubuntu, then yes. But then again, they already
> have their own app packaging format based around .debs and
> AppArmor. So yeah, we might be dicks by not supporting non-systemd
> systems, but they were dicks first, by not supporting non-Ubuntu systems
> for their app images. And that's quite some consolation, no? ;-)

The implementation of some kind of 'app level packaging system' divorced
from distros' historic package formats seems like a fairly valuable
opportunity to finally improve the level of interoperability between
Debian-derived and non-Debian-derived distros.

If, instead, we turn it into an opportunity to argue about who was being
a dick first and then cheerfully prolong the existing, needless divides
without even making a serious attempt at working together, that...seems
like something of a waste. And an invitation to a system that _does_
work across distros, like OH SAY STEAM, to eat everyone's lunch.
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net

-- 
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: unaccessability

[Richard Vickery]

On Thu, Nov 7, 2013 at 1:02 PM, Richard Hughes  wrote:

>
> On 7 Nov 2013 17:13, "Richard Vickery"  wrote
>
> > Is / was a rather political decision to make BitchX unavailable through
> this app-market / Software GUI thing?
>
> How do you launch bitchx from gnome-shell? If it's just a random binary
> without any desktop or appdata file, it isn't an application as far as
> gnome-software is concerned. If that needs to change, it needs to be
> discussed and properly designed in #gnome-design.
>
> Richard
>
You may have to install it. Remember to capitalise both the B and the X.
-- 
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: What user and password to use in cloud images?

[Juan Orti Alcaine]

El Jueves, 7 de noviembre de 2013 14:55:57 Kevin Fenzi escribió:
> On Thu, 07 Nov 2013 21:56:54 +0100
> 
> Juan Orti Alcaine  wrote:
> > Hello, I've deployed a Fedora20 Beta qcow2 image in a VM, but I'm
> > unable to login.
> > 
> > What is the default user and password?
> 
> user 'fedora' and no password (which you will be unable to login to via
> ssh since sshd defaults to not allowing empy passwords). You should be
> able to login on console tho.
> 

I cannot login with the user 'fedora'. I'm connected to the console (it is a 
CloudStack  cloud), and have tried all combinations of ec2-user/fedora 
/passwords/without-passwords.

I also have tried in a local KVM vm, but cannot login.
These are the images I have used:

Fedora-x86_64-20-Beta-TC6-20131026-sda.qcow2
Fedora-x86_64-20-Beta-20131106-sda.qcow2

Should I report a bug or I am missing something?

-- 
Juan Orti
GPG Key: DEEBD08B - https://www.miceliux.com/~juan/pubkey.asc
Blog: https://apuntesderoot.wordpress.com/

signature.asc
Description: This is a digitally signed message part.
-- 
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: unaccessability

[Rahul Sundaram]

On Thu, Nov 7, 2013 at 4:37 PM, Christian Schaller  wrote:

>
> Anyway, as Richard says, we should have a proper design discussion around
> this and not just add a ton of .desktop files without thinking through the
> presentation
> and how it will work. But feel free to file some bug reports to kick of a
> discussion.


I have filed one now at https://bugzilla.gnome.org/show_bug.cgi?id=711638.
Let me know if anything further needs to be done here.

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

Workstation PRD summary and next steps

[Christian Schaller]

Hi everyone,
So on behalf of the Workstation Working Group I would like to say thank you to 
everyone who has taken the time so far to chime in. There has been a lot of 
passionate discussion happening
and that is the way we like it. So while we might not have been able to respond 
to each and every message, myself and the other working group members have read 
every message sent so far.

We will now take that feedback with us into the next working group meeting and 
come up with a second PRD draft, trying to incorporate the suggestions we have 
gotten so far when possible.

The next update of the PRD will be posted to the fedora-desktop list as that is 
the designated 'home' of the working group and product and we want to avoid 
cluttering up the general 
Fedora-devel list with product specific further discussion. The other product 
working groups have mostly kept themselves to their own mailing list so we will 
try to do the same, and leave the
general devel list to the -base group.

Also for those of you who might end up feeling that the updated PRD do not 
address you raised concerns, all I can say is that we do take all feedback 
seriously, and will try to keep the points 
made in mind as we go forward, but of course there is no perfect solutions here 
that will make absolutely everyone 110% content.

Christian


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

[389-devel] Please review lib389 ticket 47584 (take #4): CI tests: add backup/restore of an instance

[thierry bordaz]

This review takes into account the following recommendations

 * skip verbose option (use of log.level).
 * use glob.glob to retrieve files matching rather that os.walk
 * fix a bug in instanceBackupFS that did not return an already
   existing backup
 * add two functions to handle instance backup: clearInstanceBackupFS
   (to remove one or all backups of an instance), _infoInstanceBackupFS
   (just to keep path/pattern info of backup into a single routine)
 * do not hard code '/tmp' as directory to store the backups. A new
   optional argument 'backupdir' for createInstance, sets the attribute
   'dirsrv.backupdir'. By default it takes '/tmp'. The caller of
   createInstance (the test case), may provide 'backupdir' from an
   environment variable (like it was done with $PREFIX)

https://fedorahosted.org/389/attachment/ticket/47584/0004-Ticket-47584-CI-tests-add-backup-restore-of-an-insta.patch


--
389-devel mailing list
389-de...@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/389-devel

Re: Draft Product Description for Fedora Workstation

[Kevin Fenzi]

On Thu, 07 Nov 2013 13:47:34 -0600
Michael Cronenworth  wrote:

> Kevin Fenzi wrote:
> > Like repos.fedorapeople.org ?
> 
> I don't have a beef with r.f.o. They're no different from hosting a
> repo on a personal server. The top of the root page even contains a
> disclaimer.
> 
> > How on earth do you get to 'does away with them' ?
> 
> It's a Fedora infrastructure server building non-Fedora packages. Why
> is it considered part of Fedora? Plus there is no disclaimer.

Like koji? (which you can make scratch builds of 'non fedora
packages'). 

It's 'part of fedora' in the sense that it's running in our private
openstack cloud. You're welcome to run your own (see the copr packages
available in fedora/epel). 

We could add a disclaimer... can you file a copr ticket asking for one?

> > The copr maintainers? along with anyone who looks at them who
> > wishes to report something non distributable. Just like
> > repos.fedorapeople.org
> 
> Good. I see that feature.
> 
> > Sure they can. This just allows them a place to publish them and not
> > use local computing resources to build them.
> 
> I don't have anything wrong with creating a useful service if it
> respects Fedora's principles.

I don't see anything against fedora's principals here... but if you see
something feel free to let me know. 

kevin


signature.asc
Description: PGP signature
-- 
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: python-setuptools update in F20

[Toshio Kuratomi]

On Mon, Nov 4, 2013 at 12:44 PM, Toshio Kuratomi  wrote:
> A new setuptools upstream release (1.2) was made last week that adds support 
> for
> subversion 1.7 and 1.8.  Subversion 1.7 shipped in Fedora 19 so the
> subversion support in setuptools is currently broken in both F19 and F20.
> Unless there's objections I'm definitely going to update setuptools in F20.
> I'm quite hesitant about updating in F19 due to potential incompatibilities.
> In particular, pip, buildout, and virtualenv would likely all need to update
> (these were things that we found had minimum versions to work with the F20
> setuptools package as per:
> https://fedoraproject.org/wiki/Changes/Python_setuptools_0.7
> )
>
> Backwards incompatible changes were introduced between 0.9.8 and 1.0:
> https://pypi.python.org/pypi/setuptools#id145 but these changes are unlikely
> to affect any code that's currently in the wild.
>
> Please speak now if you don't want this update to hit F20 or do want the
> update to hit F19.  My plan is to update the python-setuptools package in
> F20 to 1.3 near the end of this week.
>
This update has now been submitted:
https://admin.fedoraproject.org/updates/python-setuptools-1.3.1-1.fc20
___
python-devel mailing list
python-de...@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/python-devel

Re: unaccessability

[Christian Schaller]

Ok, so I guess the solution would be for the launcher to do something like this:

gnome-terminal --geometry 80x37 --disable-factory --role=bitchx --class=bitchx 
--name "bitchX IRC" --title "BitchX IRC"

That said Ray mentioned that this is probably not supported yet in the Shell 
launcher. 

Anyway, as Richard says, we should have a proper design discussion around this 
and not just add a ton of .desktop files without thinking through the 
presentation
and how it will work. But feel free to file some bug reports to kick of a 
discussion.

Christian

- Original Message -
From: "Richard Hughes" 
To: "Development discussions related to Fedora" 
Sent: Thursday, November 7, 2013 4:02:07 PM
Subject: Re: unaccessability




On 7 Nov 2013 17:13, "Richard Vickery" < richard.vicker...@gmail.com > wrote 
> Is / was a rather political decision to make BitchX unavailable through this 
> app-market / Software GUI thing? 

How do you launch bitchx from gnome-shell? If it's just a random binary without 
any desktop or appdata file, it isn't an application as far as gnome-software 
is concerned. If that needs to change, it needs to be discussed and properly 
designed in #gnome-design. 

Richard 

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

OpenCL comps group

[Fabian Deutsch]

Hey,

with this change [0] we try to bring some basic OpenCL support to Fedora
21.
To make the user (or developer) experience even better I'd like to add a
group which contain a set of opencl packages to enable basic OpenCL
support on a host - for usage and development.
According to [1] this mailinglist shall be contacted to discuss this.
So let us discuss if it's sensible to add a group called "OpenCL
Support" or alike (suggestions are welcome!), which contain the
following (incomplete) list of packages:
* opencl-headers - Khronos OpenCL headers
* opencl-filesystem - Ownership for shared dirs
* ocl-icd - OpenCL ICD loader
* pocl - CPU only OpenCL implementation
* clinfo - Tool to query OpenCL informations
* mesa-opencl - Mesa's OpenCL support (NEW, needs mesa 10)
* beignet - Intel OpenCL implementation for _some_ CPUs (NEW,
volunteers to package this?

Does it make sense to have such a group? And how shall this be
displayed? Using the OpenCL icon within gnome-software?

Thoughts, ideas and criticism?

- fabian

--
[0] http://fedoraproject.org/wiki/Changes/OpenCL
[1]
https://fedoraproject.org/wiki/How_to_use_and_edit_comps.xml_for_package_groups#New_groups

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

[389-devel] please review: Ticket 47582 - replication agreement count can go negative

[Mark Reynolds]

https://fedorahosted.org/389/ticket/47582/

https://fedorahosted.org/389/attachment/ticket/47582/0001-Ticket-47582-agmt_count-in-Replica-could-become-PRUi.patch

--
Mark Reynolds
389 Development Team
Red Hat, Inc
mreyno...@redhat.com

--
389-devel mailing list
389-de...@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/389-devel

Re: unaccessability

[Richard Hughes]

On 7 Nov 2013 17:13, "Richard Vickery"  wrote
> Is / was a rather political decision to make BitchX unavailable through
this app-market / Software GUI thing?

How do you launch bitchx from gnome-shell? If it's just a random binary
without any desktop or appdata file, it isn't an application as far as
gnome-software is concerned. If that needs to change, it needs to be
discussed and properly designed in #gnome-design.

Richard
-- 
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: Draft Product Description for Fedora Workstation

[Miloslav Trmač]

On Thu, Nov 7, 2013 at 9:48 PM, Lennart Poettering  wrote:
> On Thu, 07.11.13 20:09, Miloslav Trmač (m...@volny.cz) wrote:
>> Is there a technical reason why we can't use their packaging format,
>> interpreting it with our technologies but staying compatible?
>
> Well, the most relevant bit is that they use apparmor for
> sandboxing. Nobody else uses that.

Are the packages expected to ship their own apparmor policy?  That
would appear to be at odds with the idea of protecting against
malicious packages.  If they aren't expected to ship their own, could
we implement the same sandboxing policy using SELinux?
(https://wiki.ubuntu.com/AppDevUploadProcess seems to suggest Ubuntu
will be using some higher-level "profile" format, not raw AppArmor.)

> And I don't think it is a good idea to use .deb as an image format.
.deb is just an ar archive; if this were the only difference, it would
not be worth fragmenting the ecosystem over IMHO.  (Especially if the
GNOME apps alternative is a "compressed disk image", which saves disk
space and costs extra CPU time and memory, making exactly the wrong
tradeoff in most situations AFAICS.)
Mire
-- 
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: Draft Product Description for Fedora Workstation

[Lennart Poettering]

On Thu, 07.11.13 20:09, Miloslav Trmač (m...@volny.cz) wrote:

> On Thu, Nov 7, 2013 at 4:15 PM, Lennart Poettering  
> wrote:
> > On Thu, 07.11.13 03:53, Kevin Kofler (kevin.kof...@chello.at) wrote:
> >
> >> Olav Vitters wrote:
> >> > AFAIK (not sure), it should come somewhat easy once you the distribution
> >> > is based upon systemd.
> >>
> >> That means it will exclude the most popular distribution out there.
> >
> > If you are referring to Ubuntu, then yes. But then again, they already
> > have their own app packaging format based around .debs and
> > AppArmor. So yeah, we might be dicks by not supporting non-systemd
> > systems, but they were dicks first, by not supporting non-Ubuntu systems
> > for their app images. And that's quite some consolation, no? ;-)
> 
> No, calling each other dicks is overall not at all consoling.
> 
> Is there a technical reason why we can't use their packaging format,
> interpreting it with our technologies but staying compatible?

Well, the most relevant bit is that they use apparmor for
sandboxing. Nobody else uses that.

And I don't think it is a good idea to use .deb as an image format.

So if the format on disk, and the execution runtime is totally different
for us and for them, there's little to share.

Lennart

-- 
Lennart Poettering, Red Hat
-- 
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: rpm macro magic help

[Sandro Mani]

For some time I am looking for a reason to test the Lua RPM feature:

http://rpm.org/wiki/PackagerDocs/RpmLua

Can you point me to the .spec in the question and a few more words 
which is the desired result.


Kind Regards,
Alek


Hi Alek,

I've uploaded the spec here [1]. About the scenario and the desired 
result: when creating mingw packages for projects with buildsystems for 
which no pretty rpm macros (such as %mingw_configure) exist, on 
basically needs to write near identical portions of the spec file for 
mingw32 and mingw64. Here, I additionally experimented with supporting 
both qt4 and qt5 builds, so I ended up with four nearly identical spec 
blocks. (Note: lots of the messy stuff in the spec is because the qmake 
support for "make install" isn't that great, plus the fact that the 
naming of dynamic, import and static library as done by qmake is 
incorrect. Possibly there is a better way to fix those things.)


As a general note: I ended up using this "macro magic" mostly out of 
curiosity, so I wouldn't take this case too seriously (though I must say 
that I like the compactness of the resulting spec file). Anyhow, if you 
are looking for a good test case, I guess this should do just fine ;)


Best,
Sandro

[1] http://smani.fedorapeople.org/mingw-quazip.spec
--
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 Base Design WG] Committee FESCO approved, next steps

[Miloslav Trmač]

On Wed, Nov 6, 2013 at 6:31 PM, Jaroslav Reznik  wrote:
> And with that conflict - resources to backport stuff or do updates (that's
> the reason why we have so many updates - no resources to backport fixes,
> more hope that upstream fixed it and it's regression free :D).

Note that it's not strictly necessary for all groups to have the same,
or even a compatible, release cadence, as long as their stability
promises are compatible.

It might be possible for Base to release every 3 months, and to apply
the Base update to all Server installations, even with an 18-month
Server lifetime; in the same way as we currently are rebasing the
kernel during the lifetime of a single Fedora release.

Of course this is only possible when the shorter-lifetime project is
explicitly tasked with keeping $somehow_defined stability (and the
kernel is one of the cases where they've been fairly public about this
being the goal; I have my doubts about the larger Base deliverable).
Mirek
-- 
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: Draft Product Description for Fedora Workstation

[Kevin Fenzi]

On Thu, 7 Nov 2013 20:50:28 +0100
Olav Vitters  wrote:

> On Thu, Nov 07, 2013 at 08:57:06AM -0700, Kevin Fenzi wrote:
> > Which basically says that the working group is going to work on
> > that. There's actually 0 technical details on how the implemetation
> > will work out, or even if it will. 
> 
> http://www.superlectures.com/guadec2013/sandboxed-applications-for-gnome
> 
> So there have been lots of thought and work going into this. But maybe
> more needs to be written down in the proposal as you mentioned.

Thats one possible implementation sure.

Yeah, ideally a write up with pros/cons, work outstanding that needs to
still be done, what things are acceptable for shipping this way and
what isn't, how they are exposed to users, how users can manage them,
how they interact with other containers that the other working groups
might be working on to meet their needs for server applications, etc. 

I think it's premature to yell about something where there's not even a
detailed proposal to look at. 

kevin


signature.asc
Description: PGP signature
-- 
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: Draft Product Description for Fedora Workstation

[Olav Vitters]

On Thu, Nov 07, 2013 at 03:45:13PM +0100, Nicolas Mailhot wrote:
> Maybe that's because Coprs were never announced with huge rants about
> market-share and how Fedora packaging sucked and was irrelevant?

I'm pretty sure you're misunderstanding what people are saying if you
think above. What I wrote might be understood like above, but that's not
what I meant at all. Suggest to reread what people wrote.

A few comments to make it easier: I was talking about the *review
process*. That can take *ages*. Secondly, this is not meant to replace
packages, no packages are not at all irrelevant.

-- 
Regards,
Olav
-- 
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: Draft Product Description for Fedora Workstation

[Olav Vitters]

On Thu, Nov 07, 2013 at 04:06:04PM +0100, Kevin Kofler wrote:
> Peter Robinson wrote:
> > I don't see many people forcing things through, I believe that the vast
> > majority of contributors either like the change or aren't bothered by it.
> 
> Ah, the "silent majority" hypothesis, always a fun argument to bring (with 
> no evidence whatsoever) when one is clearly losing a discussion.

Ok, you're against "silent majority" hypothesis

> Can't you just admit that the consensus is AGAINST Apple-like apps?

Wait, I thought you were against "silent majority" hypothesis?

-- 
Regards,
Olav
-- 
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: Draft Product Description for Fedora Workstation

[Olav Vitters]

On Thu, Nov 07, 2013 at 08:57:06AM -0700, Kevin Fenzi wrote:
> Which basically says that the working group is going to work on that.
> There's actually 0 technical details on how the implemetation will work
> out, or even if it will. 

http://www.superlectures.com/guadec2013/sandboxed-applications-for-gnome

So there have been lots of thought and work going into this. But maybe
more needs to be written down in the proposal as you mentioned.

-- 
Regards,
Olav
-- 
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: unaccessability

[Rahul Sundaram]

Hi


On Thu, Nov 7, 2013 at 2:39 PM, Christian Schaller wrote:

>
> Maybe long term we want to filter terminal applications into a separate
> 'tab' or similar, but regardless of
> long term presentation if you maintain a package with a terminal
> application and want it to show up in the installer
> the solution is to create a .desktop file and a appdata file for it.
>

Fair enough but if you want all the applications (including command line
ones) to include a appdata and desktop file, you would need a lot more time
to get package maintainers and upstream to do that and filtering apps based
on appdata for Fedora 21 would be premature until there is a public roadmap
that gives enough time to get everyone on board.  Thanks!

Rahul
-- 
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: Draft Product Description for Fedora Workstation

[Michael Cronenworth]

Kevin Fenzi wrote:

Like repos.fedorapeople.org ?


I don't have a beef with r.f.o. They're no different from hosting a repo on a 
personal server. The top of the root page even contains a disclaimer.



How on earth do you get to 'does away with them' ?


It's a Fedora infrastructure server building non-Fedora packages. Why is it 
considered part of Fedora? Plus there is no disclaimer.



The copr maintainers? along with anyone who looks at them who wishes to
report something non distributable. Just like repos.fedorapeople.org


Good. I see that feature.


Sure they can. This just allows them a place to publish them and not
use local computing resources to build them.


I don't have anything wrong with creating a useful service if it respects 
Fedora's principles.


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

[Test-Announce] Fedora 20 Beta status is Go, ongoing release schedule adjustments!

[Jaroslav Reznik]

At the Fedora 20 Beta Go/No-Go Meeting that just occurred, it was
agreed to Go with the Fedora 20 Beta by Fedora QA and Fedora
Development (with silent approval from me ;-).

Fedora 20 Beta will be publicly available on Tuesday, November 12,
2013.

!!!Schedule adjustment!!! 
Due to possible collision with holidays, FESCo approved [1] one
week shorter Beta to Final period with Final Change Deadline on
Nov 26. Be aware of this change and queue your updates on time!

Many thanks to everyone who helped with this release and fixing
all (heisen)bugs!

Meeting details can be seen here:
Minutes: http://bit.ly/1dQmqdr
Log: http://bit.ly/1bdSrZ3

Jaroslav

___
test-announce mailing list
test-annou...@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/test-announce
-- 
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: unaccessability

[Bill Nottingham]

Richard Vickery (richard.vicker...@gmail.com) said: 
> A thought as we move into the future: if we continue with the installer,
> end users may one day forget about the yum command and all the awesome
> packages out there; they may forget about the command line altogether.

We've been shipping a graphical package install tool since before we shipped
yum.  (As awesome as glint and glitter were) I, for one, am not going to
worry about this particular slippery slope.

Bill
-- 
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: unaccessability

[Christian Schaller]

Well the installer is work in progress and there are a lot of features missing 
still, and
there are still questions that we need to figure out the answer to in terms of 
installing various things.

We are trying to nail down the core design first before adding support for 
'everything', 
but there will be the need for a .desktop file and an appdata file for anything 
that wants to be in.
Maybe long term we want to filter terminal applications into a separate 'tab' 
or similar, but regardless of 
long term presentation if you maintain a package with a terminal application 
and want it to show up in the installer 
the solution is to create a .desktop file and a appdata file for it.

Christian



- Original Message -
> From: "Rahul Sundaram" 
> To: "Development discussions related to Fedora" 
> 
> Sent: Thursday, November 7, 2013 1:09:19 PM
> Subject: Re: unaccessability
> 
> Hi
> 
> 
> On Thu, Nov 7, 2013 at 12:56 PM, Florian Müllner < fmuell...@gnome.org >
> wrote:
> 
> 
> 
> 
> I guess the main obstacle here is that there isn't really a good
> criterion which is as clear-cut as "installs a (non-NoDisplay)
> .desktop file" => "this is a user-visible gui application" for gui
> applications - mutt certainly is a user application, sshd clearly is
> not, zsh ... maybe?
> 
> Why do you want to differentiate between Mutt and sshd? If a user wants to
> install a specific piece of software, they search for it within a gui and if
> it matches, they install it and move on. If you really need some way to
> differentiate, you can have some form of tagging via fedora tagger or
> appdata which you can include in more than just gui packages.
> 
> When I want some software, say Epiphany and Mutt, if I can only use the
> installer for the Epiphany but I have to use yum for Mutt, I rather just use
> yum for both where I don't have to switch between two different ways of
> getting it. I don't mind the focus on gui applications but leaving out
> command line tools altogether forces me to think about whether say htop
> would be considered a application by the installer or not which is not the
> level I want to differentiate at all. When I search for something within the
> installer and it returns nothing, is it because there is genuinely nothing
> that matches what I want within the repositories or is the installer just
> excluding it based on implementation level details like desktop files and
> appdata? How would I know? It is just too complex.
> 
> Rahul
> 
> --
> devel mailing list
> devel@lists.fedoraproject.org
> https://admin.fedoraproject.org/mailman/listinfo/devel
> Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: unaccessability

[Bill Nottingham]

Rahul Sundaram (methe...@gmail.com) said: 
> > I guess the main obstacle here is that there isn't really a good
> > criterion which is as clear-cut as "installs a (non-NoDisplay)
> > .desktop file" => "this is a user-visible gui application" for gui
> > applications - mutt certainly is a user application, sshd clearly is
> > not, zsh ... maybe?
> 
> Why do you want to differentiate between Mutt and sshd?

Because the purpose it was designed for was to install *applications*.

sshd is not an application, at least not in the terms that the software was
designed to handle.

Bill
-- 
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: Draft Product Description for Fedora Workstation

[Markus Mayer]

On 11/05/2013 10:33 PM, Adam Williamson wrote:

On Tue, 2013-11-05 at 16:32 -0500, Josh Boyer wrote:

On Tue, Nov 5, 2013 at 4:29 PM, Adam Williamson  wrote:

On Tue, 2013-11-05 at 15:23 -0500, Josh Boyer wrote:

On Tue, Nov 5, 2013 at 2:58 PM, Adam Williamson  wrote:

On Fri, 2013-11-01 at 14:22 -0400, Josh Boyer wrote:


- What about watching films, listening to music? I think it is a basic
requirement for students (at least for me).

Maybe we should add a that a student should be able to play videos and
listen to music. It should be easy to install required codes
(free/nonfree/patente) if they are available in the repositories (yes, I
mean rpmfusion)


This would require approval beyond the WG, as it goes against Fedora's
policies.  Note, I am not saying you are incorrect, just that it's a
conversation to be had elsewhere first.


Ensuring that it's possible/easy to install plugins from third party
repositories when appropriate if those third party repositories are
defined is not, I don't believe, against any policies, or we could not
have the automatic codec installation mechanisms in Totem and Rhythmbox.
(Which, as I read it, is the kind of thing this comment was about).


The codec search only works if you have repositories configured that
have packages that match the Provides (as far as I understand).
Fedora policy says that we do not promote or install such
repositories.  This is the "don't talk about RPMFusion" rule.

So sure, we can have software that will pull things in if the user has
done some manual intervention.  We just cant, currently, do that thing
for them.


Right, that's exactly what I was saying. I just think this is all the
_original poster_ was talking about, not any kind of automatic
configuration of such repositories. (Or at least, you can read it that
way).


OK.  I guess that's fine, but it seems like a non-goal to me.  I mean,
it already works that way.  All adding it to the PRD would do would
make an easy thing to check off the list as "met".


I suppose we should go back to the OP and ask for clarification of
exactly what the idea was, at this point :)



All I was asking for is the status quo. 3rd party repositories must be 
installed manually, but once they are installed automated codec 
installation should work.

--
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: Draft Product Description for Fedora Workstation

[Miloslav Trmač]

On Thu, Nov 7, 2013 at 4:15 PM, Lennart Poettering  wrote:
> On Thu, 07.11.13 03:53, Kevin Kofler (kevin.kof...@chello.at) wrote:
>
>> Olav Vitters wrote:
>> > AFAIK (not sure), it should come somewhat easy once you the distribution
>> > is based upon systemd.
>>
>> That means it will exclude the most popular distribution out there.
>
> If you are referring to Ubuntu, then yes. But then again, they already
> have their own app packaging format based around .debs and
> AppArmor. So yeah, we might be dicks by not supporting non-systemd
> systems, but they were dicks first, by not supporting non-Ubuntu systems
> for their app images. And that's quite some consolation, no? ;-)

No, calling each other dicks is overall not at all consoling.

Is there a technical reason why we can't use their packaging format,
interpreting it with our technologies but staying compatible?
Mirek
-- 
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: rpm macro magic help

[Alek Paunov]

Hi Sandro,

On 07.11.2013 15:10, Sandro Mani wrote:

Uhm, how can one this be done? Shell variables are substituted after
macro expansion, so i.e.

function do_build {
arch=$1
qt_version=$2
%{mingw${arch}_qmake_${qt_version}}
}

would hardly work? Or are you suggesting passing the entire macros as
arguments? I.e.

function do_build {
qmake=$1
make=$2
${qmake} 
${make} %{?_smp_mflags}}
[...]
do_build "%{mingw32_qmake_qt4}" "%{mingw32_make}"


For some time I am looking for a reason to test the Lua RPM feature:

http://rpm.org/wiki/PackagerDocs/RpmLua

Can you point me to the .spec in the question and a few more words which 
is the desired result.


Kind Regards,
Alek

--
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: unaccessability

[Rahul Sundaram]

Hi


On Thu, Nov 7, 2013 at 12:56 PM, Florian Müllner wrote:

>
> I guess the main obstacle here is that there isn't really a good
> criterion which is as clear-cut as "installs a (non-NoDisplay)
> .desktop file" => "this is a user-visible gui application" for gui
> applications - mutt certainly is a user application, sshd clearly is
> not, zsh ... maybe?
>

Why do you want to differentiate between Mutt and sshd?  If a user wants to
install a specific piece of software, they search for it within a gui and
if it matches, they install it and move on.  If you really need some way to
differentiate, you can have some form of tagging via fedora tagger or
appdata which you can include in more than just gui packages.

When I want some software,  say Epiphany and Mutt, if I can only use the
installer for the Epiphany but I have to use yum for Mutt, I rather just
use yum for both where I don't have to switch between two different ways of
getting it.   I don't mind the focus on gui applications but leaving out
command line tools altogether forces me to think about whether say htop
would be considered a application by the installer or not which is not the
level I want to differentiate at all.  When I search for something within
the installer and it returns nothing, is it because there is genuinely
nothing that matches what I want within the repositories or is the
installer just excluding it based on implementation level details like
desktop files and appdata?  How would I know?  It is just too complex.

Rahul
-- 
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: unaccessability

[Richard Vickery]

On Thu, Nov 7, 2013 at 9:36 AM, Rahul Sundaram  wrote:

> Hi
>
>
> On Thu, Nov 7, 2013 at 12:28 PM, Christian Schaller  wrote:
>
>> Hi,
>> The core principle of the installer is that it operates on an application
>> level and not a package level. The current way it determines if something
>> is an application
>>  is by looking for a .desktop file. So in theory you could put a
>> bitchx.desktop file  into the bitchx package and it would appear in the
>> installer. That said I don't
>> think it is generally a bad idea if command line/terminal applications
>> are installed from the command line, but there is no hard policy blocking
>> such applications from making themselves available in the installer.
>>
>
> It might be a good idea to rethink this strategy.  I don't have a problem
> with using yum but I am not going to fire up the installer just for gui
> packages and fall back to command line to install command line
> applications.  It is a confusing approach.   Perhaps instead of ignoring
> them entirely, you can just sort the results or having a secondary view
> "Click here for command line applications that match your search results"
> etc can be considered.
>
> Rahul
>
>

A thought as we move into the future: if we continue with the installer,
end users may one day forget about the yum command and all the awesome
packages out there; they may forget about the command line altogether.

Richard
-- 
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: unaccessability

[Florian Müllner]

On Thu, Nov 7, 2013 at 6:36 PM, Rahul Sundaram  wrote:
> Perhaps instead of ignoring them entirely, you can just sort the results or 
> having
> a secondary view "Click here for command line applications that match your 
> search
> results"  etc can be considered.

I guess the main obstacle here is that there isn't really a good
criterion which is as clear-cut as "installs a (non-NoDisplay)
.desktop file" => "this is a user-visible gui application" for gui
applications - mutt certainly is a user application, sshd clearly is
not, zsh ... maybe?
"installs an executable in PATH (no libraries, libexec helpers) and
does not install a .service file (no system services)" would still
consider /usr/bin/X a command line application ...
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

[389-devel] please review: Ticket 47541 - Replication of the schema may overwrite consumer 'attributetypes' even if consumer definition is a superset

[Mark Reynolds]

https://fedorahosted.org/389//ticket/47541

https://fedorahosted.org/389/attachment/ticket/47541/0001-Ticket-47541-Replication-of-the-schema-may-overwrite.patch

--
Mark Reynolds
389 Development Team
Red Hat, Inc
mreyno...@redhat.com

--
389-devel mailing list
389-de...@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/389-devel

Re: OpenH264 in Fedora

[Rahul Sundaram]

Hi


On Thu, Nov 7, 2013 at 12:28 PM, Nicolas Mailhot wrote:

>
> > You're proposing a continuation of the adolescent state of Linux on the
> > Desktop with its barriers to growing the market. Yes, let's build
> > artificial walls keeping out new users and developers who don't agree
> > with the existing community worldview who might, duh, change the platform
> > to meet their needs.
>
> And so on
>

So, not an exact quote.  Using quote marks in this case is confusing.  I
see all of this as advocacy for more than one approach.  Not replacing one
with another.  If you want technical details, you can watch the
presentation or talk to the developers involved including Lennart and Alex
or wait till those details are flushed out before arguing against it.

Rahul
-- 
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: unaccessability

[Rahul Sundaram]

Hi


On Thu, Nov 7, 2013 at 12:28 PM, Christian Schaller  wrote:

> Hi,
> The core principle of the installer is that it operates on an application
> level and not a package level. The current way it determines if something
> is an application
>  is by looking for a .desktop file. So in theory you could put a
> bitchx.desktop file  into the bitchx package and it would appear in the
> installer. That said I don't
> think it is generally a bad idea if command line/terminal applications are
> installed from the command line, but there is no hard policy blocking such
> applications from making themselves available in the installer.
>

It might be a good idea to rethink this strategy.  I don't have a problem
with using yum but I am not going to fire up the installer just for gui
packages and fall back to command line to install command line
applications.  It is a confusing approach.   Perhaps instead of ignoring
them entirely, you can just sort the results or having a secondary view
"Click here for command line applications that match your search results"
etc can be considered.

Rahul
-- 
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: OpenH264 in Fedora

[Nicolas Mailhot]

Le Jeu 7 novembre 2013 16:29, Rahul Sundaram a écrit :
> Hi
>
>
> On Thu, Nov 7, 2013 at 8:58 AM, Nicolas Mailhot wrote:
>
>>
>>
>> I can only react to what has been published, which so far is "we'll do
>> better because you suck"
>>
>
> Where has anyone said that?

For example:

> You're proposing a continuation of the adolescent state of Linux on the
> Desktop with its barriers to growing the market. Yes, let's build
> artificial walls keeping out new users and developers who don't agree
> with the existing community worldview who might, duh, change the platform
> to meet their needs.

> I want upstream to control their
> distribution of software and not be reliant on distributions shipping
> this or that update

> It is outrageous that it's 2013 and I still have to upgrade my whole
> system just to get the latest LibreOffice version to name an example.

> The flaw IMO is within
> the distribution method. It takes a long time and currently there is
> nothing that makes it easy. Luckily there is no other method at the
> moment to archive that.

And so on

-- 
Nicolas Mailhot

-- 
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: unaccessability

[Christian Schaller]

Hi,
The core principle of the installer is that it operates on an application level 
and not a package level. The current way it determines if something is an 
application
 is by looking for a .desktop file. So in theory you could put a bitchx.desktop 
file  into the bitchx package and it would appear in the installer. That said I 
don't 
think it is generally a bad idea if command line/terminal applications are 
installed from the command line, but there is no hard policy blocking such 
applications from making themselves available in the installer.

Christian 

- Original Message -
From: "Richard Vickery" 
To: "Development discussions related to Fedora" 
, "Community support for Fedora users" 

Sent: Thursday, November 7, 2013 12:13:25 PM
Subject: unaccessability

Is / was a rather political decision to make BitchX unavailable through this 
app-market / Software GUI thing? Since having to yum install it, I am beginning 
to have a negative feeling toward the app market idea; the thought being: what 
else is being left out? 

Regards, 
Richard 

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

Re: unaccessability

[Bastien Nocera]

It's only for GUI applications, which BitchX isn't, and if it has
become a GUI application in the ten years since I last looked at it,
it's probably lacking AppData files.

- Original Message -
> Is / was a rather political decision to make BitchX unavailable through
> this app-market / Software GUI thing? Since having to yum install it, I am
> beginning to have a negative feeling toward the app market idea; the
> thought being: what else is being left out?
> 
> Regards,
> Richard
> 
> --
> devel mailing list
> devel@lists.fedoraproject.org
> https://admin.fedoraproject.org/mailman/listinfo/devel
> Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

unaccessability

[Richard Vickery]

Is / was a rather political decision to make BitchX unavailable through
this app-market / Software GUI thing? Since having to yum install it, I am
beginning to have a negative feeling toward the app market idea; the
thought being: what else is being left out?

Regards,
Richard
-- 
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: Draft Product Description for Fedora Workstation

[Kevin Kofler]

Josh Boyer wrote:
> So if we call containerized apps "Appers"

The name "Apper" is already taken!

Kevin Kofler

-- 
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: OpenH264 in Fedora

[Ralf Corsepius]

On 11/07/2013 02:41 PM, Nicolas Mailhot wrote:

Le Mer 6 novembre 2013 20:52, Adam Jackson a écrit :


Don't throw your hands up in resignation.  Write code.  Fix problems.

Isn't that exactly what this proposal does?

People claim packaging process is broken and needs to be replaced.
Who? I'd agree that the packaging workflow (review, QA, release etc.) 
would be in need of improvements, but that's it.

  But
they've not even identified the problem parts, nor tried to fix them, let
alone shown they can not be fixed. It's a grounds-up rewrite that people
who didn't even bother to understand the current process.

Agreed.

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

Re: Draft Product Description for Fedora Workstation

[Florian Müllner]

On Thu, Nov 7, 2013 at 4:58 PM, Kevin Kofler  wrote:
> (My guess: Canonical will come up with their own Ubuntu App model requiring
> Ubuntu technologies

If you had read Lennart's previous reply to this thread, you'd be
aware that they already did.
-- 
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: Draft Product Description for Fedora Workstation

[Kevin Kofler]

Bastien Nocera wrote:

> - [Florian Weimer wrote:] -
>> "Wayland" and "systemd" strongly suggest no Ubuntu interoperability
>> whatsoever.  Shouldn't this be a top priority for bundled applications?
> 
> If we get any traction on this, their customers/users will ask them for it
> themselves.

Hahaha, you really think you can force Canonical into adopting your 
technologies that way? LOL! This is going to backfire spectacularly! (My 
guess: Canonical will come up with their own Ubuntu App model requiring 
Ubuntu technologies and all the third-party developers you are trying to 
attract will target only that one.)

Kevin Kofler

-- 
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: Draft Product Description for Fedora Workstation

[Kevin Fenzi]

On Thu, 07 Nov 2013 09:06:43 -0600
Michael Cronenworth  wrote:

> Josh Boyer wrote:
> > Everyone seems to think Coprs are
> > awesome, but they can be used for the same things you deride
> > containerized apps for.
> 
> Please don't count me as "everyone."
> 
> How is Coprs a benefit?
> -Allows easy Fedora fragmentation. Why bother with package reviews
> ever again? Were Ubuntu's PPAs seen as such an advantage because they
> allowed every John Doe and Jane Smith to release packages put
> together with duct tape? I highly value Fedora's packaging guidelines
> and now to provide a service that does away with them is insulting.

Like repos.fedorapeople.org ?

How on earth do you get to 'does away with them' ?

> -Who is going to police it? People will attempt at uploading binary
> packages. (steam, NVIDIA, skype, etc)

The copr maintainers? along with anyone who looks at them who wishes to
report something non distributable. Just like repos.fedorapeople.org 

> -What's this do over running mock on your local system? Anyone can
> generate RPMs on their own system the same way Koji/Coprs do.

Sure they can. This just allows them a place to publish them and not
use local computing resources to build them. 

kevin



signature.asc
Description: PGP signature
-- 
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: Draft Product Description for Fedora Workstation

[Kevin Fenzi]

On Thu, 7 Nov 2013 15:45:13 +0100
"Nicolas Mailhot"  wrote:
...snip...

> 
> It's not blinders it's the natural reaction of people to tactless
> pronouncements and dismissals. I do wish the people complaining about
> this list focused more on technical aspects and less on hype or
> we-ll-decide-somewhere-else-even-though-it-concerns-you.

Thats one thing that puzzles me about this thread... this is all from: 

"Work towards a system where applications can be installed inside a
container to improve security and simplify compatibility through
library bundling"

Which basically says that the working group is going to work on that.
There's actually 0 technical details on how the implemetation will work
out, or even if it will. 

Perhaps we could move this back to productive and suggest that the
working group amend their PRD to have something like: 

"Investigate the implementation and usage for application containers"
and then we can discuss details when there actually are some? 

kevin



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

Summary/Minutes for Wednesday's FESCo Meeting (2013-11-06)

[Toshio Kuratomi]

==
#fedora-meeting: fesco
==


Meeting started by abadger1999 at 18:02:39 UTC. The full logs are
available at
http://meetbot.fedoraproject.org/fedora-meeting/2013-11-06/fedora-meeting.2013-11-06-18.02.log.html
.



Meeting summary
---
* Roll Call  (abadger1999, 18:02:59)

* #1185 Enable "-Werror=format-security" by default  (abadger1999,
  18:04:46)
  * Adding to gcc's -Wall as a local Fedora patch was rejected
(abadger1999, 18:08:12)
  * Deferred another week awaiting results of mass rebuild
(abadger1999, 18:08:45)

* #1192 OpenH264 as an automatic download by firefox/Statement to the
  ietf WebRTC working group  (abadger1999, 18:08:58)
  * LINK: https://fedorahosted.org/fesco/ticket/1192#comment:8
(abadger1999, 18:12:45)
  * additional text from pjones approved (+1:7, 0:0, -1:0)
(abadger1999, 18:39:05)
  * ACTION: abadger1999 to take care of sending the statement to the
ietf.  (abadger1999, 18:40:38)

* #1191 Fedora 20 schedule adjustment  (abadger1999, 18:42:00)
  * Move up the final freeze by one week passed (+1:7, 0:0, -1:1)
(abadger1999, 18:51:11)

* #1194 Ratify Server Working Group governance charter  (abadger1999,
  18:51:54)
  * Server working group governance charter approved (+1:8, 0:0, -1:0)
(abadger1999, 18:55:37)

* #1193 reboots for all updates -- are we ready for this?  (abadger1999,
  18:55:56)
  * Change owners are trusted to, _and dependent upon_, highlight all
relevant changes.  Not noting important changes (whether due to
oversight or intentionally) breaks the Change process, and would
sadly motivate FESCo to institute a more heavy-handed and
higher-overhead process, which nobody wants to have.  (mitr,
19:22:54)
  * LINK: https://bugzilla.redhat.com/show_bug.cgi?id=1001335
(jreznik, 19:23:51)
  * mitr's proposal to update change policy passed (+1:5, 0:0, -1:1)
(abadger1999, 19:40:45)
  * Proposal to Keep F20 behavior as-is (all offline updates for gnome).
Update Change page to reflect current implementation, update docs
and release notes to match.  Passed (+1:5, 0:2, -1:0)  (abadger1999,
19:43:30)

* #1189 Stalled bug 758826 -- requesting intervention  (abadger1999,
  19:46:21)
  * twoerner working on an update.  Will update the bug report.
(abadger1999, 19:50:39)

* Open floor  (abadger1999, 19:50:45)

* F21 Change Process  (abadger1999, 19:51:20)
  * F21 Change Process is open for submissions  (abadger1999, 19:52:15)

* Elections  (abadger1999, 19:52:23)
  * jreznik will send an announcement that we're seeking an Election
Wrangler.  (abadger1999, 19:53:56)

* Next week's Chair  (abadger1999, 19:54:05)
  * nirik to chair next week's meeting  (abadger1999, 19:55:03)

* Open Floor  (abadger1999, 19:55:10)
  * Regarding the earlier discussion on OpenH264, if Fedora community
members have a project in Fedora that is intending to use OpenH264
in some way, please talk to FESCo before integrating code to use it.
(notting, 20:02:39)

Meeting ended at 20:06:34 UTC.




Action Items

* abadger1999 to take care of sending the statement to the ietf.




Action Items, by person
---
* abadger1999
  * abadger1999 to take care of sending the statement to the ietf.
* **UNASSIGNED**
  * (none)




People Present (lines said)
---
* abadger1999 (159)
* nirik (70)
* mattdm (60)
* sgallagh (57)
* pjones (48)
* notting (47)
* mitr (46)
* adamw (38)
* mclasen (33)
* jreznik (24)
* t8m (21)
* drago01 (13)
* zodbot (10)
* twoerner (7)
* jwb (7)
* mmaslano (6)
* jreznik2 (2)
* masta (1)
* Southern_Gentlem (1)




Generated by `MeetBot`_ 0.1.4

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

introducing myself

[Nikos Mavrogiannopoulos]

Hello,

I have recently joined the Red Hat Security Technologies Team,
and will help co-maintain the gnutls and nettle packages.

My primary area of focus is security and cryptography and I'm
working on few such projects (e.g. gnutls).

I'd also like to bring in ocserv [0], an SSL VPN server. I hope there
will be someone interested in reviewing and give feedback. 

[0]. https://bugzilla.redhat.com/show_bug.cgi?id=1027770

Best regards,
Nikos


-- 
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: Draft Product Description for Fedora Workstation

[Kevin Kofler]

Olav Vitters wrote:

> On Thu, Nov 07, 2013 at 11:33:57AM +0100, Sergio Pascual wrote:
>> 2013/11/7 Olav Vitters 
>> 
>> > On Thu, Nov 07, 2013 at 03:53:48AM +0100, Kevin Kofler wrote:
>> > > Olav Vitters wrote:
>> > > > AFAIK (not sure), it should come somewhat easy once you the
>> > distribution
>> > > > is based upon systemd.
>> > >
>> > > That means it will exclude the most popular distribution out there.
>> >
>> > I fail to see the point of discussing non-Fedora distributions on
>> > Fedora devel mailing list.
>> 
>> I fail to see the point of discussing a feature that is meant to allow
>> upstreams to provide installable bundles that work in all linuxes if it
>> is only to work in Fedora.
> 
> I already talked about other distributions so your concern has been
> addressed already.

But I pointed out that you are leaving out the most popular one, and you 
responded by labeling me as off-topic when actually YOU were the one who 
started talking about other distributions.

You advertise distribution-independent packages, so your packages really 
need to work on ALL distributions. Assuming systemd is already a non-
starter.

IMHO, trying to support cross-distro packages is a failed endeavour from the 
outstart, Fedora RPMs are the way to go.

Kevin Kofler

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

[perl-Fedora-Rebuild/f18] 0.10.0 bump

[Petr Pisar]

commit 9476c47d0a44c0123fb8246f2ff406b0dc07fffa
Author: Petr Písař 
Date:   Thu Nov 7 16:46:17 2013 +0100

0.10.0 bump

 .gitignore   |1 +
 perl-Fedora-Rebuild.spec |   32 
 sources  |2 +-
 3 files changed, 22 insertions(+), 13 deletions(-)
---
diff --git a/.gitignore b/.gitignore
index 8a6a58d..29e5646 100644
--- a/.gitignore
+++ b/.gitignore
@@ -8,3 +8,4 @@
 /Fedora-Rebuild-v0.8.0.tar.gz
 /Fedora-Rebuild-v0.9.0.tar.gz
 /Fedora-Rebuild-v0.9.1.tar.gz
+/Fedora-Rebuild-v0.10.0.tar.gz
diff --git a/perl-Fedora-Rebuild.spec b/perl-Fedora-Rebuild.spec
index 0dd3555..fc491e3 100644
--- a/perl-Fedora-Rebuild.spec
+++ b/perl-Fedora-Rebuild.spec
@@ -1,24 +1,26 @@
 # This file is lincensed under the terms of GPLv2+.
 Name:   perl-Fedora-Rebuild
-Version:0.9.1
-Release:3%{?dist}
+Version:0.10.0
+Release:1%{?dist}
 Summary:Rebuilds Fedora packages from scratch
 License:GPLv3+
 Group:  Development/Libraries
 URL:http://ppisar.fedorapeople.org/Fedora-Rebuild/
 Source0:
http://ppisar.fedorapeople.org/Fedora-Rebuild/Fedora-Rebuild-v%{version}.tar.gz
 BuildArch:  noarch
+BuildRequires:  perl
 BuildRequires:  perl(ExtUtils::MakeMaker)
-# Tests:
-BuildRequires:  perl(Config::Tiny)
-BuildRequires:  perl(Data::Compare)
+# Run-time:
+BuildRequires:  perl(Carp)
+BuildRequires:  perl(constant)
 BuildRequires:  perl(Data::Dumper)
 BuildRequires:  perl(DateTime)
 BuildRequires:  perl(File::Copy)
 BuildRequires:  perl(File::Path)
 BuildRequires:  perl(File::Spec)
-BuildRequires:  perl(HTTP::Daemon)
-BuildRequires:  perl(HTTP::Status)
+# File::Temp not used at tests
+# HTTP::Daemon not used at tests
+# HTTP::Status not used at tests
 BuildRequires:  perl(IO::Handle)
 BuildRequires:  perl(Moose)
 BuildRequires:  perl(Moose::Util::TypeConstraints)
@@ -31,14 +33,18 @@ BuildRequires:  perl(RPM2)
 BuildRequires:  perl(RPM::VersionCompare)
 BuildRequires:  perl(Scalar::Util)
 BuildRequires:  perl(Storable)
+BuildRequires:  perl(strict)
 BuildRequires:  perl(Term::ProgressBar)
-BuildRequires:  perl(Test::Simple)
 BuildRequires:  perl(Thread::Semaphore)
 BuildRequires:  perl(threads)
 BuildRequires:  perl(threads::shared)
 BuildRequires:  perl(URI)
 BuildRequires:  perl(version) >= 0.77
-Requires:   perl(:MODULE_COMPAT_%(eval "`%{__perl} -V:version`"; echo 
$version))
+BuildRequires:  perl(warnings)
+# Tests:
+BuildRequires:  perl(Data::Compare)
+BuildRequires:  perl(Test::Simple)
+Requires:   perl(:MODULE_COMPAT_%(eval "`perl -V:version`"; echo $version))
 Requires:   fedpkg
 Requires:   git
 Requires:   koji
@@ -56,13 +62,12 @@ new interpreter.
 %setup -q -n Fedora-Rebuild-v%{version}
 
 %build
-%{__perl} Makefile.PL INSTALLDIRS=vendor
+perl Makefile.PL INSTALLDIRS=vendor
 make %{?_smp_mflags}
 
 %install
-make pure_install PERL_INSTALL_ROOT=$RPM_BUILD_ROOT
+make pure_install DESTDIR=$RPM_BUILD_ROOT
 find $RPM_BUILD_ROOT -type f -name .packlist -exec rm -f {} \;
-find $RPM_BUILD_ROOT -depth -type d -exec rmdir {} 2>/dev/null \;
 %{_fixperms} $RPM_BUILD_ROOT/*
 
 %check
@@ -76,6 +81,9 @@ make test
 %{_mandir}/man3/*
 
 %changelog
+* Thu Nov 07 2013 Petr Pisar  - 0.10.0-1
+- 0.10.0 bump
+
 * Fri Jul 20 2012 Fedora Release Engineering  
- 0.9.1-3
 - Rebuilt for https://fedoraproject.org/wiki/Fedora_18_Mass_Rebuild
 
diff --git a/sources b/sources
index 0518a91..f161634 100644
--- a/sources
+++ b/sources
@@ -1 +1 @@
-7e3a504fafde3cc77dc3d242157ed4d0  Fedora-Rebuild-v0.9.1.tar.gz
+651705dd3754fe2574843da5e67f2c52  Fedora-Rebuild-v0.10.0.tar.gz
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-de...@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel

[perl-Fedora-Rebuild/f19] 0.10.0 bump

[Petr Pisar]

commit 347b470af7ae759736263592c0e4dba9ae67c7ce
Author: Petr Písař 
Date:   Thu Nov 7 16:46:17 2013 +0100

0.10.0 bump

 .gitignore   |1 +
 perl-Fedora-Rebuild.spec |   32 
 sources  |2 +-
 3 files changed, 22 insertions(+), 13 deletions(-)
---
diff --git a/.gitignore b/.gitignore
index 8a6a58d..29e5646 100644
--- a/.gitignore
+++ b/.gitignore
@@ -8,3 +8,4 @@
 /Fedora-Rebuild-v0.8.0.tar.gz
 /Fedora-Rebuild-v0.9.0.tar.gz
 /Fedora-Rebuild-v0.9.1.tar.gz
+/Fedora-Rebuild-v0.10.0.tar.gz
diff --git a/perl-Fedora-Rebuild.spec b/perl-Fedora-Rebuild.spec
index 6a078dc..8b7e3bf 100644
--- a/perl-Fedora-Rebuild.spec
+++ b/perl-Fedora-Rebuild.spec
@@ -1,24 +1,26 @@
 # This file is lincensed under the terms of GPLv2+.
 Name:   perl-Fedora-Rebuild
-Version:0.9.1
-Release:4%{?dist}
+Version:0.10.0
+Release:1%{?dist}
 Summary:Rebuilds Fedora packages from scratch
 License:GPLv3+
 Group:  Development/Libraries
 URL:http://ppisar.fedorapeople.org/Fedora-Rebuild/
 Source0:
http://ppisar.fedorapeople.org/Fedora-Rebuild/Fedora-Rebuild-v%{version}.tar.gz
 BuildArch:  noarch
+BuildRequires:  perl
 BuildRequires:  perl(ExtUtils::MakeMaker)
-# Tests:
-BuildRequires:  perl(Config::Tiny)
-BuildRequires:  perl(Data::Compare)
+# Run-time:
+BuildRequires:  perl(Carp)
+BuildRequires:  perl(constant)
 BuildRequires:  perl(Data::Dumper)
 BuildRequires:  perl(DateTime)
 BuildRequires:  perl(File::Copy)
 BuildRequires:  perl(File::Path)
 BuildRequires:  perl(File::Spec)
-BuildRequires:  perl(HTTP::Daemon)
-BuildRequires:  perl(HTTP::Status)
+# File::Temp not used at tests
+# HTTP::Daemon not used at tests
+# HTTP::Status not used at tests
 BuildRequires:  perl(IO::Handle)
 BuildRequires:  perl(Moose)
 BuildRequires:  perl(Moose::Util::TypeConstraints)
@@ -31,14 +33,18 @@ BuildRequires:  perl(RPM2)
 BuildRequires:  perl(RPM::VersionCompare)
 BuildRequires:  perl(Scalar::Util)
 BuildRequires:  perl(Storable)
+BuildRequires:  perl(strict)
 BuildRequires:  perl(Term::ProgressBar)
-BuildRequires:  perl(Test::Simple)
 BuildRequires:  perl(Thread::Semaphore)
 BuildRequires:  perl(threads)
 BuildRequires:  perl(threads::shared)
 BuildRequires:  perl(URI)
 BuildRequires:  perl(version) >= 0.77
-Requires:   perl(:MODULE_COMPAT_%(eval "`%{__perl} -V:version`"; echo 
$version))
+BuildRequires:  perl(warnings)
+# Tests:
+BuildRequires:  perl(Data::Compare)
+BuildRequires:  perl(Test::Simple)
+Requires:   perl(:MODULE_COMPAT_%(eval "`perl -V:version`"; echo $version))
 Requires:   fedpkg
 Requires:   git
 Requires:   koji
@@ -56,13 +62,12 @@ new interpreter.
 %setup -q -n Fedora-Rebuild-v%{version}
 
 %build
-%{__perl} Makefile.PL INSTALLDIRS=vendor
+perl Makefile.PL INSTALLDIRS=vendor
 make %{?_smp_mflags}
 
 %install
-make pure_install PERL_INSTALL_ROOT=$RPM_BUILD_ROOT
+make pure_install DESTDIR=$RPM_BUILD_ROOT
 find $RPM_BUILD_ROOT -type f -name .packlist -exec rm -f {} \;
-find $RPM_BUILD_ROOT -depth -type d -exec rmdir {} 2>/dev/null \;
 %{_fixperms} $RPM_BUILD_ROOT/*
 
 %check
@@ -76,6 +81,9 @@ make test
 %{_mandir}/man3/*
 
 %changelog
+* Thu Nov 07 2013 Petr Pisar  - 0.10.0-1
+- 0.10.0 bump
+
 * Thu Feb 14 2013 Fedora Release Engineering  
- 0.9.1-4
 - Rebuilt for https://fedoraproject.org/wiki/Fedora_19_Mass_Rebuild
 
diff --git a/sources b/sources
index 0518a91..f161634 100644
--- a/sources
+++ b/sources
@@ -1 +1 @@
-7e3a504fafde3cc77dc3d242157ed4d0  Fedora-Rebuild-v0.9.1.tar.gz
+651705dd3754fe2574843da5e67f2c52  Fedora-Rebuild-v0.10.0.tar.gz
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-de...@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel

[perl-Fedora-Rebuild/f20] 0.10.0 bump

[Petr Pisar]

Summary of changes:

  3c67235... 0.10.0 bump (*)

(*) This commit already existed in another branch; no separate mail sent
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-de...@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel

[perl-Fedora-Rebuild] 0.10.0 bump

[Petr Pisar]

commit 3c67235b6d5fa21b80b62062e5c43a947d75bfa3
Author: Petr Písař 
Date:   Thu Nov 7 16:46:17 2013 +0100

0.10.0 bump

 .gitignore   |1 +
 perl-Fedora-Rebuild.spec |   32 
 sources  |2 +-
 3 files changed, 22 insertions(+), 13 deletions(-)
---
diff --git a/.gitignore b/.gitignore
index 8a6a58d..29e5646 100644
--- a/.gitignore
+++ b/.gitignore
@@ -8,3 +8,4 @@
 /Fedora-Rebuild-v0.8.0.tar.gz
 /Fedora-Rebuild-v0.9.0.tar.gz
 /Fedora-Rebuild-v0.9.1.tar.gz
+/Fedora-Rebuild-v0.10.0.tar.gz
diff --git a/perl-Fedora-Rebuild.spec b/perl-Fedora-Rebuild.spec
index c41ad0f..97ed8ed 100644
--- a/perl-Fedora-Rebuild.spec
+++ b/perl-Fedora-Rebuild.spec
@@ -1,24 +1,26 @@
 # This file is lincensed under the terms of GPLv2+.
 Name:   perl-Fedora-Rebuild
-Version:0.9.1
-Release:6%{?dist}
+Version:0.10.0
+Release:1%{?dist}
 Summary:Rebuilds Fedora packages from scratch
 License:GPLv3+
 Group:  Development/Libraries
 URL:http://ppisar.fedorapeople.org/Fedora-Rebuild/
 Source0:
http://ppisar.fedorapeople.org/Fedora-Rebuild/Fedora-Rebuild-v%{version}.tar.gz
 BuildArch:  noarch
+BuildRequires:  perl
 BuildRequires:  perl(ExtUtils::MakeMaker)
-# Tests:
-BuildRequires:  perl(Config::Tiny)
-BuildRequires:  perl(Data::Compare)
+# Run-time:
+BuildRequires:  perl(Carp)
+BuildRequires:  perl(constant)
 BuildRequires:  perl(Data::Dumper)
 BuildRequires:  perl(DateTime)
 BuildRequires:  perl(File::Copy)
 BuildRequires:  perl(File::Path)
 BuildRequires:  perl(File::Spec)
-BuildRequires:  perl(HTTP::Daemon)
-BuildRequires:  perl(HTTP::Status)
+# File::Temp not used at tests
+# HTTP::Daemon not used at tests
+# HTTP::Status not used at tests
 BuildRequires:  perl(IO::Handle)
 BuildRequires:  perl(Moose)
 BuildRequires:  perl(Moose::Util::TypeConstraints)
@@ -31,14 +33,18 @@ BuildRequires:  perl(RPM2)
 BuildRequires:  perl(RPM::VersionCompare)
 BuildRequires:  perl(Scalar::Util)
 BuildRequires:  perl(Storable)
+BuildRequires:  perl(strict)
 BuildRequires:  perl(Term::ProgressBar)
-BuildRequires:  perl(Test::Simple)
 BuildRequires:  perl(Thread::Semaphore)
 BuildRequires:  perl(threads)
 BuildRequires:  perl(threads::shared)
 BuildRequires:  perl(URI)
 BuildRequires:  perl(version) >= 0.77
-Requires:   perl(:MODULE_COMPAT_%(eval "`%{__perl} -V:version`"; echo 
$version))
+BuildRequires:  perl(warnings)
+# Tests:
+BuildRequires:  perl(Data::Compare)
+BuildRequires:  perl(Test::Simple)
+Requires:   perl(:MODULE_COMPAT_%(eval "`perl -V:version`"; echo $version))
 Requires:   fedpkg
 Requires:   git
 Requires:   koji
@@ -56,13 +62,12 @@ new interpreter.
 %setup -q -n Fedora-Rebuild-v%{version}
 
 %build
-%{__perl} Makefile.PL INSTALLDIRS=vendor
+perl Makefile.PL INSTALLDIRS=vendor
 make %{?_smp_mflags}
 
 %install
-make pure_install PERL_INSTALL_ROOT=$RPM_BUILD_ROOT
+make pure_install DESTDIR=$RPM_BUILD_ROOT
 find $RPM_BUILD_ROOT -type f -name .packlist -exec rm -f {} \;
-find $RPM_BUILD_ROOT -depth -type d -exec rmdir {} 2>/dev/null \;
 %{_fixperms} $RPM_BUILD_ROOT/*
 
 %check
@@ -76,6 +81,9 @@ make test
 %{_mandir}/man3/*
 
 %changelog
+* Thu Nov 07 2013 Petr Pisar  - 0.10.0-1
+- 0.10.0 bump
+
 * Sun Aug 04 2013 Petr Pisar  - 0.9.1-6
 - Perl 5.18 rebuild
 
diff --git a/sources b/sources
index 0518a91..f161634 100644
--- a/sources
+++ b/sources
@@ -1 +1 @@
-7e3a504fafde3cc77dc3d242157ed4d0  Fedora-Rebuild-v0.9.1.tar.gz
+651705dd3754fe2574843da5e67f2c52  Fedora-Rebuild-v0.10.0.tar.gz
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-de...@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel

Re: EPEL Retire from maintainership duties

[Dario Landazuri]

Sam,


Message: 2
Date: Wed, 6 Nov 2013 17:23:05 -0500 (EST)
From: Sam Kottler 
To: EPEL Development List 
Subject: Re: EPEL Retire from maintainership duties
- Original Message -

I'll take over nagios-plugins, nagios-plugins-check_sip, and nrpe.

Can you orphan those packages so I can become the owner?

-S


Do you know if we should be looking for an update to Nagios 4 anywhere 
in the near future?  I'd like to do some testing on my end before that 
happens to see if my setup will "seamlessly" handle that upgrade.


Thanks,
Dario

--

Dario Landazuri   da...@ots.utsystem.edu
Senior Systems Administrator  (512) 471-2427
Office of Telecommunications Services

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

File Fedora-Rebuild-v0.10.0.tar.gz uploaded to lookaside cache by ppisar

[Petr Pisar]

A file has been added to the lookaside cache for perl-Fedora-Rebuild:

651705dd3754fe2574843da5e67f2c52  Fedora-Rebuild-v0.10.0.tar.gz
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-de...@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel

[389-devel] Please review: ticket 47521 Complex filter in a search request doen't work as expected.

[Ludwig Krispenz]

https://fedorahosted.org/389/ticket/47521

https://fedorahosted.org/389/attachment/ticket/47521/0001-Ticket-47521-Complex-filter-in-a-search-request-doen.patch
--
389-devel mailing list
389-de...@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/389-devel

Re: OpenH264 in Fedora

[Rahul Sundaram]

Hi


On Thu, Nov 7, 2013 at 8:58 AM, Nicolas Mailhot wrote:

>
>
> I can only react to what has been published, which so far is "we'll do
> better because you suck"
>

Where has anyone said that?

Rahul
-- 
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: Draft Product Description for Fedora Workstation

[Lennart Poettering]

On Thu, 07.11.13 03:53, Kevin Kofler (kevin.kof...@chello.at) wrote:

> Olav Vitters wrote:
> > AFAIK (not sure), it should come somewhat easy once you the distribution
> > is based upon systemd.
> 
> That means it will exclude the most popular distribution out there.

If you are referring to Ubuntu, then yes. But then again, they already
have their own app packaging format based around .debs and
AppArmor. So yeah, we might be dicks by not supporting non-systemd
systems, but they were dicks first, by not supporting non-Ubuntu systems
for their app images. And that's quite some consolation, no? ;-)

Lennart

-- 
Lennart Poettering, Red Hat
-- 
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: Draft Product Description for Fedora Workstation

[Rahul Sundaram]

Hi


On Thu, Nov 7, 2013 at 10:06 AM, Kevin Kofler  wrote:

> Peter Robinson wrote:
> > I don't see many people forcing things through, I believe that the vast
> > majority of contributors either like the change or aren't bothered by it.
>
> Ah, the "silent majority" hypothesis, always a fun argument to bring (with
> no evidence whatsoever) when one is clearly losing a discussion.
>
> Can't you just admit that the consensus is AGAINST Apple-like apps?
>

You haven't established any such consensus at all.  On the contrary, I see
a number of people on both sides.

Rahul
-- 
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: Draft Product Description for Fedora Workstation

[Michael Cronenworth]

Josh Boyer wrote:

Everyone seems to think Coprs are
awesome, but they can be used for the same things you deride
containerized apps for.


Please don't count me as "everyone."

How is Coprs a benefit?
-Allows easy Fedora fragmentation. Why bother with package reviews ever again? 
Were Ubuntu's PPAs seen as such an advantage because they allowed every John Doe 
and Jane Smith to release packages put together with duct tape? I highly value 
Fedora's packaging guidelines and now to provide a service that does away with 
them is insulting.
-Who is going to police it? People will attempt at uploading binary packages. 
(steam, NVIDIA, skype, etc)
-What's this do over running mock on your local system? Anyone can generate RPMs 
on their own system the same way Koji/Coprs do.


--
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: Draft Product Description for Fedora Workstation

[Kevin Kofler]

Peter Robinson wrote:
> I don't see many people forcing things through, I believe that the vast
> majority of contributors either like the change or aren't bothered by it.

Ah, the "silent majority" hypothesis, always a fun argument to bring (with 
no evidence whatsoever) when one is clearly losing a discussion.

Can't you just admit that the consensus is AGAINST Apple-like apps?

Kevin Kofler

-- 
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: Draft Product Description for Fedora Workstation

[Christian Schaller]

Hi Frank,
They will, although in some sense I am the wrong person to ask this question as 
it
will be up to the people developing and packaging these DE's just like it is 
now.

The difference from today here though will be that there will be some 
requirements for being available
for the workstation as the PRD states. The main one here that I foresee is that 
you can't conflict in 
terms of library requirements or binary names with the standard desktop of the 
workstation. I don't think
that has been a big problem historically so it will likely have minimal impact, 
but it is now going to 
be a formal requirement as the PRD currently stands.

I expect there will be other requirements defined too, but I want to make it 
clear that the goals of 
these requirements is not to make it impossible or even hard to package 
alternative DEs for the workstation.
But what it will mean is that for instance it will be 100% clear that the 
responsibility to stay available rests on the 
alternative DEs packagers and developers and not on the core product 
developers. Of course with this also comes extra 
responsibility of the Workstation working group to ensure that development 
plans are shared as early as possible, to give 
everyone a chance to port over in time (ref. the recent Bluez discussion).

But it all comes back to what I mentioned in an earlier email. The 3 products 
is a attempt at moving from primarily packaging
upstream projects, to having concrete independent development targets for each 
product and to have engineers work on those 
independently of upstream priorities. So in some sense when people install 
alternative DEs that will to some degree mean that 
they are no longer using the Workstation as at least a subset of the features 
developed and announced as the big new features of a given 
release will not be available simply because they where features implemented or 
bugs fixed in the primary desktop. That is of course not
specific to the Workstation product. 

Christian


- Original Message -
> From: "Frank Murphy" 
> To: devel@lists.fedoraproject.org
> Sent: Thursday, November 7, 2013 4:16:58 AM
> Subject: Re: Draft Product Description for Fedora Workstation
> 
> On Fri, 01 Nov 2013 10:24:20 -0400
> Christian Fredrik Kalager Schaller  wrote:
> 
> Will the other DE's still exist after "workstation"
> Will a dev be able to use Xfce, Lxde as graphical choice.
> 
> What would encourage say an xubuntu dev  //* devs are still users */
> working on foo, to switch to "Fedora Workstation"?
> 
> 
> --
> Regards,
> Frank
> www.frankly3d.com
> 
> --
> devel mailing list
> devel@lists.fedoraproject.org
> https://admin.fedoraproject.org/mailman/listinfo/devel
> Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Draft Product Description for Fedora Workstation

[Kevin Kofler]

Peter Robinson wrote:
> Just because you can't see a way to fix it doesn't mean its either
> unfixable or that there aren't people willing to step up to do so.

It's not that I can't see a way to fix it, it's that I can see that there is 
no way! The whole system relies on bundling, so it is provably impossible to 
implement it without getting the nasty drawbacks of bundling.

Kevin Kofler

-- 
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: Draft Product Description for Fedora Workstation

[Michael Cronenworth]

Peter Robinson wrote:

I don't see many people forcing things through, I believe that the vast majority
of contributors either like the change or aren't bothered by it. There's
certainly no proof that it'll make anything worse. That doesn't mean its going
to be perfect or without teething problems as the changes are made and things
settle down.


There's plenty of reasons why you haven't seen any negative feedback. I'll share 
my views on this subject since I'm in the "not sure" ballpark of this new process.


Where's the benefit of creating a handful of workgroups that now have some sort 
of power over the distribution? After reading all of the emails in the past week 
I have yet to see any benefits of this "Fedora.next" process. I agree Fedora 
needs to continue to evolve, but this process appears to shake the foundations 
of Fedora. Specifics: Different kernels per "product", app sandboxing (lib 
bundling). Will the DVD/Live ISOs currently created cease to exist F21+? 
Fragmentation of Fedora into Cloud/Workstation/Server "products"? I'm just 
randomly spitting out ideas in my head that come to mind, but you cannot expect 
that silence equates to agreement in your favor.


It strikes me as odd at the large number of @redhat accounts and small number of 
non-@redhat accounts in favor of this new process. Who is in charge of evolving 
Fedora at this point? I do value Red Hat involvement, but I don't want the 
common myth of "Fedora = Red Hat beta" to become a fact.


I'm still going to keep my ears open and attempt at digesting what this new idea 
is bringing to the table, but it hasn't sit well on my stomach so far.


--
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: Draft Product Description for Fedora Workstation

[Nicolas Mailhot]

Le Jeu 7 novembre 2013 15:19, Josh Boyer a écrit :

> So if we call containerized apps "Appers" and host it somewhere on
> Fedora infrastructure and tell people about it, you'd be totally OK
> with that?

I think that would remove a lot of the emotion in this thread.

>  People seem to already be jumping to conclusions that
> Appers are going to somehow magically be THE WAY we deliver software,
> but yet nobody had the same thoughts around Coprs.

Maybe that's because Coprs were never announced with huge rants about
market-share and how Fedora packaging sucked and was irrelevant?

> The blinders involved here are pretty large.

It's not blinders it's the natural reaction of people to tactless
pronouncements and dismissals. I do wish the people complaining about this
list focused more on technical aspects and less on hype or
we-ll-decide-somewhere-else-even-though-it-concerns-you.

-- 
Nicolas Mailhot

-- 
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: Draft Product Description for Fedora Workstation

[Josh Boyer]

On Thu, Nov 7, 2013 at 9:10 AM, Nicolas Mailhot
 wrote:
>
> Le Jeu 7 novembre 2013 14:57, Josh Boyer a écrit :
>
>> And yet, now we have Coprs.  Which lets people easily upload
>> unreviewed, possibly bundled application SRPMs for easy distribution
>> outside of the main Fedora repos.  Everyone seems to think Coprs are
>> awesome, but they can be used for the same things you deride
>> containerized apps for.
>
> And Coprs have their own name. So they're doing exactly what I proposed.
> You didn't read my message

Oh, I read it.  I find it odd that we can have a tool with a name
(Copr) that is officially part of the Fedora project and a tool
without a name (containerized apps) that doesn't even exit yet that
both solve similar issues and can be used in similar ways and somehow
have the name being the only thing that makes it acceptable.

So if we call containerized apps "Appers" and host it somewhere on
Fedora infrastructure and tell people about it, you'd be totally OK
with that?  People seem to already be jumping to conclusions that
Appers are going to somehow magically be THE WAY we deliver software,
but yet nobody had the same thoughts around Coprs.  The blinders
involved here are pretty large.

These things are tools.  They aren't the end-all-be-all solution to
software delivery.  I just wish people would calm down and stop
wasting so much energy fighting against something on grounds that
aren't even with existing tools and before anyone even sees what it
looks like.

josh
-- 
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: Copr

[Tim Lauridsen]

On Thu, Nov 7, 2013 at 1:54 PM, Miroslav Suchý  wrote:

> Dear developers and Fedora contributors,
>
> let me introduce Copr:
>
> http://copr-fe.cloud.fedoraproject.org/
>
> Copr is a build system for third party repositories. It is intended for:
>  * upstream teams - to make nightly and test builds
>  * layered applications - if you build on top of Fedora, but you are not
> part of Fedora
>  * packages not yet ready to be included in official Fedora repositories
>
> How it works? You provide src.rpm, we will provide resulting yum repo for
> RHEL 5,6 and Fedora 18, 19, 20... But see
> WARNING on bottom of this mail.
>
> I prepared quick tutorial for you:
>  https://fedorahosted.org/copr/wiki/ScreenshotsTutorial
> and FAQ:
> https://fedorahosted.org/copr/wiki/UserDocs#FAQ
>
> Everybody with FAS account can build there. If you want to use command
> line client, you should install copr-cli from
> updates-testing.
>
> If you have ideas, questions, comments feel free to use one of our
> communication channels
> https://fedorahosted.org/copr/#Communications
> (mailing list is prefered)
>
> WARNING:
> Please do not rely on this service in production. This is very early
> release (following "release early, release often").
> First of all, this service works in simple set-up, where resulting yum
> repos are *not* backed up. Yet. This is not yet
> officially part of Fedora infrastructure, so when Copr fails, it can take
> several hours to be restored.
> And yes, our WebUI is not perfect. It's work in progress. And since Copr
> can build packages already, I decided to
> publicly announce it, so you can experiment with it.
>
> We are working on Copr on full steam and in upcoming days you can expect:
> * improvements in WebUI
> * ability to build Software Collections there
>
> --
> Miroslav Suchy, RHCE, RHCDS
> Red Hat, Software Engineer, #brno, #devexp, #fedora-buildsys
> --
> devel mailing list
> devel@lists.fedoraproject.org
> https://admin.fedoraproject.org/mailman/listinfo/devel
> Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct



Thanks a lot, a great tool, just what i have been looking for

Tim
-- 
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: Draft Product Description for Fedora Workstation

[Nicolas Mailhot]

Le Jeu 7 novembre 2013 14:57, Josh Boyer a écrit :

> And yet, now we have Coprs.  Which lets people easily upload
> unreviewed, possibly bundled application SRPMs for easy distribution
> outside of the main Fedora repos.  Everyone seems to think Coprs are
> awesome, but they can be used for the same things you deride
> containerized apps for.

And Coprs have their own name. So they're doing exactly what I proposed.
You didn't read my message

-- 
Nicolas Mailhot

-- 
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-gooey-karma is looking for sponsor

[Branislav Blaskovic]

Hi,

my little utility for easier karma submitting into bodhi is looking for sponsor.

Package review [1] is in progress right now.

I would really appreciate any comments and sponsoring.

Thank you

[1] https://bugzilla.redhat.com/show_bug.cgi?id=1020839

Branislav Blaškovič
www.blaskovic.sk
-- 
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: OpenH264 in Fedora

[Nicolas Mailhot]

Le Jeu 7 novembre 2013 14:46, Simo Sorce a écrit :
> On Thu, 2013-11-07 at 14:41 +0100, Nicolas Mailhot wrote:
>> Le Mer 6 novembre 2013 20:52, Adam Jackson a écrit :
>>
>> > Don't throw your hands up in resignation.  Write code.  Fix problems.
>>
>> Isn't that exactly what this proposal does?
>>
>> People claim packaging process is broken and needs to be replaced. But
>> they've not even identified the problem parts, nor tried to fix them,
>> let
>> alone shown they can not be fixed. It's a grounds-up rewrite that people
>> who didn't even bother to understand the current process.
>
> I wouldn't make that assumption only because some people came to a
> conclusion you do not like.

I can only react to what has been published, which so far is "we'll do
better because you suck". I'd be delighted to see an actual analysis,
based on substantiated facts and not appeals to emotion.


-- 
Nicolas Mailhot

-- 
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: Draft Product Description for Fedora Workstation

[Josh Boyer]

On Thu, Nov 7, 2013 at 8:20 AM, Nicolas Mailhot
 wrote:
>
> Le Mer 6 novembre 2013 19:24, Josh Boyer a écrit :
>
>> I'm just having trouble wrapping my head around the intense focus on a
>> new app packaging technology when the entire distro is making massive
>> changes to how it's produced.
>
> Because all distributions can and do ship the same software and the main
> thing that differences distributions is attention to packaging. What build
> the Fedora brand is in huge part the hard work of packagers over the years
> and careful definition of packaging guidelines.

I think you missed the point of my question.  It might have been too
subtle.  It wasn't "what is wrong with sandboxed/containerized apps?".
 See the follow ups.

> There have been many people that claimed this process was awful in the
> past and their alternatives all sank. Mainly because they were addressing
> developer problems (freedom to take all the shortcuts that make
> integration hard and users miserable) and thought they would win
> marketshare this way (hint: you do not win marketshare by solving
> developer problems you win marketshare by solving user problems. Users
> always voted with their feet and rejected the developer-friendly solutions
> that made their own life harder).

Users want apps.  Developers are increasingly not caring at all about
distros.  I think there's a middle ground to be had here.  As I've
said before, just saying this is bad without even thinking about if it
has some positives and how it could work just seems shortsighted.

> So what makes this initiative different? I guess that's because it
> promotes itself as making it possible to get software in Fedora, competing
> with and disparaging the work of packagers while hijacking the brand they
> helped building.
>
> Get this thing its own name. Let it win or lose user confidence on its own
> merit, and don't confuse users with "in Fedora" claims when you're
> absolutely *not* offering the same thing "in Fedora" means now.

And yet, now we have Coprs.  Which lets people easily upload
unreviewed, possibly bundled application SRPMs for easy distribution
outside of the main Fedora repos.  Everyone seems to think Coprs are
awesome, but they can be used for the same things you deride
containerized apps for.

> Right now this proposal has the potential to ruin user trust and become
> the same thorn nvidia drivers are for xorg and kernel people now. Of
> course people who build this trust do not like it.
>
> Is that clearer?

No.

josh
-- 
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: Draft Product Description for Fedora Workstation

[Olav Vitters]

On Thu, Nov 07, 2013 at 12:58:37PM +0100, Florian Weimer wrote:
> On 11/06/2013 11:30 PM, Olav Vitters wrote:
> >On Wed, Nov 06, 2013 at 10:55:30PM +0100, Sergio Pascual wrote:
> >>Has this "sanboxed-bundled-from-upstream"  proposal been discussed with
> >>other distributions? If the final result is that the "Universal Linux
> >>Package" only works in Fedora we are not gaining anything.
> >
> >A lot of this is being based on technology that's not really available
> >yet such as kdbus, Wayland, systemd bits. This has been discussed at
> >GUADEC (GNOME conference):
> >http://www.superlectures.com/guadec2013/sandboxed-applications-for-gnome
> 
> "Wayland" and "systemd" strongly suggest no Ubuntu interoperability
> whatsoever.  Shouldn't this be a top priority for bundled
> applications?

Canonical does what Canonical wants to do. They already have their own
solution for something like this. It is just very distribution specific
and not as secure as what this is proposing AFAIK.

-- 
Regards,
Olav
-- 
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: Draft Product Description for Fedora Workstation

[Olav Vitters]

On Thu, Nov 07, 2013 at 10:45:29AM +, Frank Murphy wrote:
> On Thu, 7 Nov 2013 11:17:28 +0100
> Olav Vitters  wrote:
> 
> > On Thu, Nov 07, 2013 at 03:53:48AM +0100, Kevin Kofler wrote:
> > > Olav Vitters wrote:
> > > > AFAIK (not sure), it should come somewhat easy once you the
> > > > distribution is based upon systemd.
> > > 
> > > That means it will exclude the most popular distribution out
> > > there.
> > 
> > I fail to see the point of discussing non-Fedora distributions on
> > Fedora devel mailing list. If you want to discuss GNOME, we also
> > have a development list, see
> > https://mail.gnome.org/mailman/listinfo/desktop-devel-list.
> 
> To be fair you introduced Guadec, aka Gnome developemt.
> (I'm not pro\anti Gnome)

I explained that this thought has been discussed and introduced at a
conference.

If people cannot the mention of GNOME: not my problem.

-- 
Regards,
Olav
-- 
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: Draft Product Description for Fedora Workstation

[Olav Vitters]

On Thu, Nov 07, 2013 at 02:28:09PM +0100, Nicolas Mailhot wrote:
> I fail to see the point of discussing non-GNOME-specific problems on a
> GNOME development list. A bit more logical to include people who actually
> work on non-GNOME software and don't want to discuss non-GNOME app
> distribution on a GNOME list.

As mentioned, I said the interested people are on that mailing list.
Anyway, if you want to discuss another distribution on Fedora mailing
list, I think it is stupid and pointless, but that is just my opinion.

-- 
Regards,
Olav
-- 
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: AppData questions

[Richard Hughes]

On 7 November 2013 13:36, Felix Kaechele  wrote:
> A little off-topic but I was wondering:
> The spec states "Screenshots should be taken with US English as the display
> language.".

You can actually localize the screenshots if you want; I don't know of
any project that wants to do that yet.

> However the spec also defines the tag for the software license to be
> "" (UK English). Is this a mistake or just a matter of
> habit/preference?

It's a mistake on my part. I'm from the UK, and but I suppose it
should really be  -- too late now :)

Richard.
-- 
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: Draft Product Description for Fedora Workstation

[Olav Vitters]

On Thu, Nov 07, 2013 at 11:33:57AM +0100, Sergio Pascual wrote:
> 2013/11/7 Olav Vitters 
> 
> > On Thu, Nov 07, 2013 at 03:53:48AM +0100, Kevin Kofler wrote:
> > > Olav Vitters wrote:
> > > > AFAIK (not sure), it should come somewhat easy once you the
> > distribution
> > > > is based upon systemd.
> > >
> > > That means it will exclude the most popular distribution out there.
> >
> > I fail to see the point of discussing non-Fedora distributions on Fedora
> > devel mailing list.
> 
> I fail to see the point of discussing a feature that is meant to allow
> upstreams to provide installable bundles that work in all linuxes if it is
> only to work in Fedora.

I already talked about other distributions so your concern has been
addressed already.

-- 
Regards,
Olav
-- 
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: Copr

[Remi Collet]

Le 07/11/2013 13:54, Miroslav Suchý a écrit :
> Dear developers and Fedora contributors,
> 
> let me introduce Copr:
> 
> http://copr-fe.cloud.fedoraproject.org/

Very nice tool (from a Copr tester)
Thanks a lot.

Remi.

-- 
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: OpenH264 in Fedora

[Simo Sorce]

On Thu, 2013-11-07 at 14:41 +0100, Nicolas Mailhot wrote:
> Le Mer 6 novembre 2013 20:52, Adam Jackson a écrit :
> 
> > Don't throw your hands up in resignation.  Write code.  Fix problems.
> 
> Isn't that exactly what this proposal does?
> 
> People claim packaging process is broken and needs to be replaced. But
> they've not even identified the problem parts, nor tried to fix them, let
> alone shown they can not be fixed. It's a grounds-up rewrite that people
> who didn't even bother to understand the current process.

I wouldn't make that assumption only because some people came to a
conclusion you do not like.

Simo.

-- 
Simo Sorce * Red Hat, Inc * New York

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

Broken dependencies: perl-SOAP-Lite

[buildsys]

perl-SOAP-Lite has broken dependencies in the rawhide tree:
On x86_64:
perl-SOAP-Lite-0.716-3.fc20.noarch requires perl(SOAP::Transport::TCP)
On i386:
perl-SOAP-Lite-0.716-3.fc20.noarch requires perl(SOAP::Transport::TCP)
On armhfp:
perl-SOAP-Lite-0.716-3.fc20.noarch requires perl(SOAP::Transport::TCP)
Please resolve this as soon as possible.


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

Broken dependencies: perl-Language-Expr

[buildsys]

perl-Language-Expr has broken dependencies in the rawhide tree:
On x86_64:
perl-Language-Expr-0.19-4.fc19.noarch requires 
perl(:MODULE_COMPAT_5.16.2)
On i386:
perl-Language-Expr-0.19-4.fc19.noarch requires 
perl(:MODULE_COMPAT_5.16.2)
On armhfp:
perl-Language-Expr-0.19-4.fc19.noarch requires 
perl(:MODULE_COMPAT_5.16.2)
Please resolve this as soon as possible.


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

Re: OpenH264 in Fedora

[Nicolas Mailhot]

Le Mer 6 novembre 2013 20:52, Adam Jackson a écrit :

> Don't throw your hands up in resignation.  Write code.  Fix problems.

Isn't that exactly what this proposal does?

People claim packaging process is broken and needs to be replaced. But
they've not even identified the problem parts, nor tried to fix them, let
alone shown they can not be fixed. It's a grounds-up rewrite that people
who didn't even bother to understand the current process.

-- 
Nicolas Mailhot

-- 
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: Copr

[Simo Sorce]

On Thu, 2013-11-07 at 13:54 +0100, Miroslav Suchý wrote:
> Dear developers and Fedora contributors,
> 
> let me introduce Copr:
> 
> http://copr-fe.cloud.fedoraproject.org/
> 
> Copr is a build system for third party repositories. It is intended for:
>   * upstream teams - to make nightly and test builds
>   * layered applications - if you build on top of Fedora, but you are not 
> part of Fedora
>   * packages not yet ready to be included in official Fedora repositories
> 
> How it works? You provide src.rpm, we will provide resulting yum repo for 
> RHEL 5,6 and Fedora 18, 19, 20... But see
> WARNING on bottom of this mail.
> 
> I prepared quick tutorial for you:
>   https://fedorahosted.org/copr/wiki/ScreenshotsTutorial
> and FAQ:
>  https://fedorahosted.org/copr/wiki/UserDocs#FAQ
> 
> Everybody with FAS account can build there. If you want to use command line 
> client, you should install copr-cli from
> updates-testing.
> 
> If you have ideas, questions, comments feel free to use one of our 
> communication channels
>  https://fedorahosted.org/copr/#Communications
>  (mailing list is prefered)
> 
> WARNING:
> Please do not rely on this service in production. This is very early release 
> (following "release early, release often").
> First of all, this service works in simple set-up, where resulting yum repos 
> are *not* backed up. Yet. This is not yet
> officially part of Fedora infrastructure, so when Copr fails, it can take 
> several hours to be restored.
> And yes, our WebUI is not perfect. It's work in progress. And since Copr can 
> build packages already, I decided to
> publicly announce it, so you can experiment with it.
> 
> We are working on Copr on full steam and in upcoming days you can expect:
>  * improvements in WebUI
>  * ability to build Software Collections there
> 

Miroslav,
let me congratulate you and all the people working on Copr, this is an
awesome tool that I have already used in the past for development.

It makes developing changes to packages and letting other users test
them very easy, thanks a lot!

Simo.

-- 
Simo Sorce * Red Hat, Inc * New York

-- 
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: AppData questions

[Felix Kaechele]

Richard Hughes wrote:

It's not mandatory, but highly reccomended. See
http://people.freedesktop.org/~hughsient/appdata/#screenshots for
details.


A little off-topic but I was wondering:
The spec states "Screenshots should be taken with US English as the 
display language.".
However the spec also defines the tag for the software license to be 
"" (UK English). Is this a mistake or just a matter of 
habit/preference?


- Felix

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

F21 Self Contained Change: OpenCL

[Jaroslav Reznik]

= Proposed Self Contained Change: OpenCL =
https://fedoraproject.org/wiki/Changes/OpenCL

Change Owner(s): Fabian Deutsch 

This change will bring basic OpenCL support to Fedora to support the 
development of OpenCL enabled software and the development of OpenCL 
implementations itself. The change includes enabling Mesa's OpenCL state-
tracker (in 9.3 with ICD support), packaging pocl - an CPU only OpenCL 
implementation - and the introduction of several other OpenCL related 
packages.

== Detailed description ==
The change is intended to give developers a starting point to be able to use 
OpenCL and to improve existing OpenCL implementations.

The change will include the following sub changes:

Add OpenCL implementations
* Enable OpenCL state-tracker in Mesa NEW
* Package pocl - CPU-only OpenCL implementation DONE
* Package beignet - Intel Ivy Bridge 1 only

Package implementation dependencies:
* Package libclc - needed by Mesa's state-tracker DONE
* Fix OpenCL path owenrship - Who owns /etc/OpenCL DONE
* Review Request: opencl-filesystem - OpenCL filesystem layout - A package 
owning shared paths DONE

 Package related packages
* Review Request: gocl - GLib/GObject based library for OpenCL - glib based 
OpenCL library DONE
* Review Request: clinfo - Enumerate OpenCL platforms and devices - A tool to 
query informations about the available OpenCL platforms DONE
* Review Request: erlang-cl - OpenCL binding for Erlang DONE
* Package ViennaCL - A math library whcih can utilize CPU (OpenMP) and GPU 
(OpenCL/CUDA) WIP
* Package pyopencl - A python library for accessing OpenCL BLOCKED BY rhbz 
#1002898
* Package ocltoys - A couple of OpenCL examples for testing NEW

* Update existing packages if needed
** gegl (to be investigated)
** ocl-icd (done)

* Potential projects to be packaged:
** Package khronos icd - probably not
** Package radeontop - To monitor a Radeon GPU (which supports OpenCL)
** Package piglit - This will be a testuite for the OpenCL implementations, 
has some non-fedora deps

* Other stuff:
** Add a new group to comps or a opencl-dev package?
** Add virtual provides to the opencl implementations - So a app requiring 
opencl just needs to require the virtual package (so any provider)
** Version opencl-headers

== Scope ==
Proposal owners: Mainly packaging 
Other developers: N/A (not a System Wide Change) 
Release engineering: N/A (not a System Wide Change) 
Policies and guidelines: N/A (not a System Wide Change) 
___
devel-announce mailing list
devel-annou...@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel-announce
-- 
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: Draft Product Description for Fedora Workstation

[Daniel J Walsh]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 11/06/2013 10:12 PM, Kevin Kofler wrote:
> Simo Sorce wrote:
> 
>> On Wed, 2013-11-06 at 01:13 +0100, Kevin Kofler wrote:
>>> Simo Sorce wrote:
 * and *ideally* I mean SELinux sanbdboxed with specific APIs that
 must be used to interact with the rest of the system, so that the 
 application doesn't have free reign over users files.
>>> 
>>> So you want to remove my freedom to disable SELinux? Way to
>>> go… 
>> 
>> If this is all you have to say about what I wrote (strawman on a note and
>> ignore completely the rest) you have nothing valid to say in this 
>> discussion.
> 
> If the system relies on SELinux to sandbox apps, it means that SELinux 
> becomes mandatory to use it, which definitely does remove my freedom to 
> disable it. So where's the strawman?
> 
> Kevin Kofler
> 
There will not be a requirement to run with SELinux.  We can also mitigate
some of the risks with using the namespacing, mounting over ~ and /tmp.  As
well as user_namespace if it is working well.  Of course DAC permissions and
capabilities will still be in place.

Security is about layers.  Removing SELiux will make it less secure but not
totally insecure.
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.15 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iEYEARECAAYFAlJ7lZIACgkQrlYvE4MpobOyJwCg5lrmiMx7Os8wGWN9PoreJPjE
5cYAnROJXHeqnFYhVL0st2W58I3NLpzi
=+5uZ
-END PGP SIGNATURE-
-- 
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: Draft Product Description for Fedora Workstation

[Nicolas Mailhot]

Le Jeu 7 novembre 2013 11:17, Olav Vitters a écrit :
> On Thu, Nov 07, 2013 at 03:53:48AM +0100, Kevin Kofler wrote:
>> Olav Vitters wrote:
>> > AFAIK (not sure), it should come somewhat easy once you the
>> distribution
>> > is based upon systemd.
>>
>> That means it will exclude the most popular distribution out there.
>
> I fail to see the point of discussing non-Fedora distributions on Fedora
> devel mailing list. If you want to discuss GNOME, we also have a
> development list, see
> https://mail.gnome.org/mailman/listinfo/desktop-devel-list. A bit more
> logical to include people who actually work on this and less annoying to
> people who don't want to discuss other distributions on the Fedora
> mailing list.

I fail to see the point of discussing non-GNOME-specific problems on a
GNOME development list. A bit more logical to include people who actually
work on non-GNOME software and don't want to discuss non-GNOME app
distribution on a GNOME list.

Really, why do I have to write this at all? Fedora Workstation is not
GNOME, that has already bee written in this thread.

-- 
Nicolas Mailhot

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

[389-devel] Please review lib389 ticket 47584 (take #3): CI tests: add backup/restore of an instance

[thierry bordaz]

This review differs from previous with:

 * skip verbose option (use of log.level).
 * use glob.glob to retrieve files matching rather that os.walk
 * fix a bug in instanceBackupFS that did not return an already
   existing backup
 * add two functions to handle instance backup: clearInstanceBackupFS
   (to remove one or all backups of an instance), _infoInstanceBackupFS
   (just to keep path/pattern info of backup into a single routine)

https://fedorahosted.org/389/attachment/ticket/47584/0003-Ticket-47584-CI-tests-add-backup-restore-of-an-insta.patch

--
389-devel mailing list
389-de...@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/389-devel

Re: Draft Product Description for Fedora Workstation

[Nicolas Mailhot]

Le Mer 6 novembre 2013 19:24, Josh Boyer a écrit :

> I'm just having trouble wrapping my head around the intense focus on a
> new app packaging technology when the entire distro is making massive
> changes to how it's produced.

Because all distributions can and do ship the same software and the main
thing that differences distributions is attention to packaging. What build
the Fedora brand is in huge part the hard work of packagers over the years
and careful definition of packaging guidelines.

There have been many people that claimed this process was awful in the
past and their alternatives all sank. Mainly because they were addressing
developer problems (freedom to take all the shortcuts that make
integration hard and users miserable) and thought they would win
marketshare this way (hint: you do not win marketshare by solving
developer problems you win marketshare by solving user problems. Users
always voted with their feet and rejected the developer-friendly solutions
that made their own life harder).

So what makes this initiative different? I guess that's because it
promotes itself as making it possible to get software in Fedora, competing
with and disparaging the work of packagers while hijacking the brand they
helped building.

Get this thing its own name. Let it win or lose user confidence on its own
merit, and don't confuse users with "in Fedora" claims when you're
absolutely *not* offering the same thing "in Fedora" means now.

Right now this proposal has the potential to ruin user trust and become
the same thorn nvidia drivers are for xorg and kernel people now. Of
course people who build this trust do not like it.

Is that clearer?

Regards,

-- 
Nicolas Mailhot

-- 
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: rpm macro magic help

[Sandro Mani]

On 07.11.2013 12:38, Michael Schwendt wrote:

On Sat, 02 Nov 2013 18:40:46 +0100, Sandro Mani wrote:


On 02.11.2013 18:18, Kevin Kofler wrote:

Hi,

Sandro Mani wrote:

%define do_build() \
mkdir build_win%{1}_%{2}; \
(cd build_win%{1}_%{2}; \
%{mingw%{1}_qmake_%{2}} 'PREFIX=%{mingw%{1}_prefix}'
'TARGET=quazip-%{2}' ../libquazip; \
%{mingw%{1}_make} %{?_smp_mflags}; \
)\
%{nil}

Ewww!

Sorry to rain on your parade, but are you sure this (and with the fix for
the nested expansion, it becomes even more ugly) is compatible with the
"spec files must be legible" packaging guideline?


That is a valid point. I don't know what is better,

Well, a Shell Function would be more readable, for example. It would
accept normal arguments to fill in variables -- instead of global RPM
macros, which are substituted in the entire spec file.
Uhm, how can one this be done? Shell variables are substituted after 
macro expansion, so i.e.


function do_build {
arch=$1
qt_version=$2
%{mingw${arch}_qmake_${qt_version}}
}

would hardly work? Or are you suggesting passing the entire macros as 
arguments? I.e.


function do_build {
qmake=$1
make=$2
${qmake} 
${make} %{?_smp_mflags}}
[...]
do_build "%{mingw32_qmake_qt4}" "%{mingw32_make}"


Sandro



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