Re: numatop: %{optflags} fail the 32bit build
On Wed, 11 Sep 2013 00:31:12 +0200
Dridi Boukelmoune dridi.boukelmo...@gmail.com wrote:
Hi,
I have my first packaging issue on the numatop package[1].
During the review it appeared that I forgot the %{optflags}, and that
adding them breaks the i686 build. The upstream dev is very patient
and willing to help me, but I feel I have wasted enough of his time.
The guilty gcc flag seems to be:
-specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 [2]
I can (hopefully) easily reproduce the failure with just mock on my
machine, but right now I can't figure out how to solve this. And the
fact that I don't know/understand this flag at all doesn't help.
Does anyone know what could be the cause and how to solve this ?
the -spec option is used to set flags for gcc from a file, see
https://bugzilla.redhat.com/show_bug.cgi?id=991221#c15
Dan
--
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: numatop: %{optflags} fail the 32bit build
On 09/11/2013 12:31 AM, Dridi Boukelmoune wrote:
I have my first packaging issue on the numatop package[1].
During the review it appeared that I forgot the %{optflags}, and that
adding them breaks the i686 build. The upstream dev is very patient
and willing to help me, but I feel I have wasted enough of his time.
The guilty gcc flag seems to be:
-specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 [2]
It would be helpful to provide more context and pointers to the analysis
so far.
The failing build log is here:
http://kojipkgs.fedoraproject.org//work/tasks/1414/5911414/build.log
This is the offending function:
void
cpuid(unsigned int *eax, unsigned int *ebx, unsigned int *ecx,
unsigned int *edx)
{
__asm volatile
(cpuid\n\t
: =a (*eax),
=b (*ebx),
=c (*ecx),
=d (*edx)
: a (*eax));
}
The cryptic GCC error message (inconsistent operand constraints in an
‘asm’) refers to the fact that in PIC mode (which is activated by the
hardening flags), %ebx is a reserved register.
This version should work in 32 bit mode, and only in 32 bit mode:
void
cpuid(unsigned int *eax, unsigned int *ebx, unsigned int *ecx,
unsigned int *edx)
{
__asm volatile
(push %%ebx\n\t
cpuid\n\t
mov %%ebx, (%1)\n\t
pop %%ebx
: =a (*eax),
=S (ebx),
=c (*ecx),
=d (*edx)
: 0 (*eax));
}
I have not actually tested this. There are other solutions floating
around, but they are clearly incorrect and produce wrong code.
In 64 bit mode, you should use the original version.
--
Florian Weimer / Red Hat Product Security Team
--
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: does mc really require perl*?
On 09/10/2013 08:25 AM, Dan Horák wrote: I did a TC5 minimal install last night, which omitted mc, my most used cmdline tool. So: # yum install mc ... installing for dependencies: gpm-libs (which I never ever use) perl* (29 packages)... Seriously? What does mc need perl for? see /usr/libexec/mc/extfs.d So unless you try to open deb, rpm package and few other format you do not need perl. So it is merely nice-to-have. Usually called soft-dependency, which unfortunately our tools still does not know. Does somebody knows when we can expect soft dependencies in rpm? -- 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
are you annoyed by frequent password prompts?
Hi, In FESCo ticket #1115, it was decided to modify the privilege escalation policy in order to allow local, active, admin user to update/remove/etc signed software without requiring a password. At this point, such an user can do pkcon install package to install packages without being prompted for the password. In FESCo ticket #1117, it was decided to extend this policy to potentially cover other privileged operations. At this point, we are looking for more use cases. Lot of such use cases are already listed on the following page, https://fedoraproject.org/wiki/Privilege_escalation_policy Here is a sample use case; ability to launch my own VMs using virt-manager without authenticating every time. Do *you* have a use case of your own? Here is your chance to get rid of those password prompts for your own use case! Please *note* that these policies can be modified locally (or disabled altogether) to fit different situations. An option to *specifically* enable or disable such privilege escalation policy can be given at the install time or / and run-time. Thoughts? Also *note* that the goal of this email (and the ticket in general) is to promote brainstorming at this point. I'm not saying or promising that we are going to do everything you guys demand. Some of you may find http://tinyurl.com/linus-printer to be relevant here. FESCo Tickets == https://fedorahosted.org/fesco/ticket/1115 https://fedorahosted.org/fesco/ticket/1117 Bugzilla Links == https://bugzilla.redhat.com/show_bug.cgi?id=975214 -- Dhiru -- 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: IMPORTANT, please read: Spins QA signoff for milestones
On Tue, Sep 10, 2013 at 12:00 PM, Kevin Fenzi ke...@scrye.com wrote: Per: https://fedorahosted.org/fesco/ticket/1171 I have added a set of cols to the spins page for f20: https://fedoraproject.org/w/index.php?title=Releases%2F20%2FSpinsdiff=352468oldid=340210 One each for Alpha Beta and Final kde and desktop are release blocking so they will always be shipped, so I put 'yes' for them for all milestones. Please update this table when/if you test a TC/RC version of a spin for a milestone. I'll also try and go update it based on other tests in the wiki as we go on. I updated Xfce Alpha as I tested TC4 with it (and intend to test rc's as well). It's important to keep this up to date so we know what spins to ship for a milestone. If you are a spin owner and don't have time to test, please try and line up some folks to test for you. You will need at least one person to test or your spin will not be shipped for that milestone. Just an FYI for everyone... target size for MATE spin will probably change (to =1000MB). While I haven't had a chance to test I will get someone (besides myself) to test. In regards to the size, I have not changed a thing so I'll try to look deeper into it later (currently not really able to work on it )... it's not a deal breaker for the spin just a NTH and again this is just an FYI so everyone knows. Dan -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Proposal: AppData files in all application packages?
On 10 September 2013 17:58, Remi Collet fed...@famillecollet.com wrote: Just to confirm: this new file is only useful on fedora = 20 ? Yup. (so we need to not ship it in fedora 20, perhaps some Guildelines about this could be useful) Like Elad said, I think shipping it before that is fine. Which package own /usr/share/appdata ? At the moment it's gnome-software, which isn't exactly ideal. I'm erring towards adding it to filesystem, but other ideas welcome. P.S. new version 0.3RC of qelectrotech in rawhide have this file, added by upstream on my proposal. That's great, thanks. 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: Proposal: AppData files in all application packages?
Which package own /usr/share/appdata ? At the moment it's gnome-software, which isn't exactly ideal. I'm erring towards adding it to filesystem, but other ideas welcome. Yes filesystem seems definively the good choice (as other dir as /usr/share/applications, icons, ...). 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: Proposal: AppData files in all application packages?
On 11 September 2013 08:38, Remi Collet fed...@famillecollet.com wrote: Yes filesystem seems definively the good choice (as other dir as /usr/share/applications, icons, ...). Okay, I've added this to filesystem-3.2-20 this morning. Thanks for the reminder! :) 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: Schedule for Wednesday's FESCo Meeting (2013-09-11)
On 09/10/2013 06:59 PM, Marcela Mašláňová wrote: Following is the list of topics that will be discussed in the FESCo meeting Wednesday at 18:00UTC in #fedora-meeting on irc.freenode.net. To convert UTC to your local time, take a look at http://fedoraproject.org/wiki/UTCHowto or run: date -d '-MM-DD HH:MM UTC' Links to all tickets below can be found at: https://fedorahosted.org/fesco/report/9 = Followups = #topic #1117 Generalize policy about privilege escalation and Administrator user accounts .fesco 1177 https://fedorahosted.org/fesco/ticket/1177 #topic #1161 fqdn should be clearly display at login and command prompt .fesco 1161 https://fedorahosted.org/fesco/ticket/1161 #topic #1148 F20 System Wide Change: Application Installer - https://fedoraproject.org/wiki/Changes/AppInstaller .fesco 1148 https://fedorahosted.org/fesco/ticket/1148 #topic #1164 F20 Changes - Progress on Changes Freeze .fesco 1164 https://fedorahosted.org/fesco/ticket/1164 = New business = #topic #1173 provenpackager request .fesco 1173 https://fedorahosted.org/fesco/ticket/1173 #topic #1174 Exception - F20 Self Contained Change: WildFly 8 - https://fedoraproject.org/wiki/Changes/WildFly8 .fesco 1174 https://fedorahosted.org/fesco/ticket/1174 = Open Floor = For more complete details, please visit each individual ticket. The report of the agenda items can be found at https://fedorahosted.org/fesco/report/9 If you would like to add something to this agenda, you can reply to this e-mail, file a new ticket at https://fedorahosted.org/fesco, e-mail me directly, or bring it up at the end of the meeting, during the open floor topic. Note that added topics may be deferred until the following meeting. Adding to new business: #topic #1170 Working Group call for Volunteers .fesco 1170 https://fedorahosted.org/fesco/ticket/1170 -- 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: Firewall blocking desktop features
On Wed, 2013-09-11 at 10:04 +0200, Reindl Harald wrote: and who controls for sure that bad software does not the same? snip The source of all this software is available to be looked at. So really, you can verify that only the required ports are opened up. *nobody* and *nothing* has to punch holes im my firewalls - period No one is doing it behind your back here either. Reiterating the points from my last mail: - These software inform and take permission from the user before opening ports in the firewall. - An alternative solution is where the software would just pop a message telling you that you need to open so and so ports in the firewall. -- Thanks, Warm regards, Ankur (FranciscoD) http://fedoraproject.org/wiki/User:Ankursinha Join Fedora! Come talk to us! http://fedoraproject.org/wiki/Fedora_Join_SIG 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: Firewall blocking desktop features
On Wed, 2013-09-11 at 18:41 +1000, Ankur Sinha wrote: - These software inform and take permission from the user before opening ports in the firewall. In light of the parallel discussion on too many password prompts, as pointed out by Bochecha, I'd like to clarify: - The software *must* inform the user and take permission before opening ports. (Getting rid of the permission requests altogether will enable proprietary software to open ports too) -- Thanks, Warm regards, Ankur (FranciscoD) http://fedoraproject.org/wiki/User:Ankursinha Join Fedora! Come talk to us! http://fedoraproject.org/wiki/Fedora_Join_SIG 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: Firewall blocking desktop features
Am 11.09.2013 10:41, schrieb Ankur Sinha: - These software inform and take permission from the user before opening ports in the firewall. IMHO it should be the job of the firewall to inform the user about an application that want's to open one or more ports and ask for permission to open that ports either temporary for the current session or permanent. -- Regards, Heiko Adams signature.asc Description: OpenPGP digital 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: Firewall blocking desktop features
On 2013-09-11 11:11, Heiko Adams wrote: Am 11.09.2013 10:41, schrieb Ankur Sinha: - These software inform and take permission from the user before opening ports in the firewall. IMHO it should be the job of the firewall to inform the user about an application that want's to open one or more ports and ask for permission to open that ports either temporary for the current session or permanent. Is this a good idea? The firewall just knows aboyt an attempt to use a specific port. It does not know which application which *really* is trying to use that port. It could certainly make an educated guess, but that's just not good enough in this context IMHO. OTOH, the application knows what ports it needs (even some which just might be used later) and can also identify itself to the user. Seems more reasonable to me. --alec -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: does mc really require perl*?
On 11 September 2013 08:05, Miroslav Suchý msu...@redhat.com wrote: On 09/10/2013 08:25 AM, Dan Horák wrote: I did a TC5 minimal install last night, which omitted mc, my most used cmdline tool. So: # yum install mc ... installing for dependencies: gpm-libs (which I never ever use) perl* (29 packages)... Seriously? What does mc need perl for? see /usr/libexec/mc/extfs.d So unless you try to open deb, rpm package and few other format you do not need perl. So it is merely nice-to-have. Usually called soft-dependency, which unfortunately our tools still does not know. Does somebody knows when we can expect soft dependencies in rpm? Can someone explain what the consequences of a 'soft dependency' would actually be and how it would be different from putting those files into a sub-package? (Which may or may not work depending on whether mc is able to cope dynamically with that.) Because when we saw a similar discussion on the user list a while ago it seemed that people expected it to simply know that they wouldn't need feature X of package Y and therefore magically leave it out but still have the application run successfully. -- imalone http://ibmalone.blogspot.co.uk -- 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: Firewall blocking desktop features
Le Mer 11 septembre 2013 11:23, Alec Leamas a écrit : On 2013-09-11 11:11, Heiko Adams wrote: Am 11.09.2013 10:41, schrieb Ankur Sinha: - These software inform and take permission from the user before opening ports in the firewall. IMHO it should be the job of the firewall to inform the user about an application that want's to open one or more ports and ask for permission to open that ports either temporary for the current session or permanent. Is this a good idea? The firewall just knows aboyt an attempt to use a specific port. It does not know which application which *really* is trying to use that port. It could certainly make an educated guess, but that's just not good enough in this context IMHO. OTOH, the application knows what ports it needs (even some which just might be used later) and can also identify itself to the user. Seems more reasonable to me. The application can lie and propose to open X and then when user says ok open Y. The prompt really needs to be initiated firewall-side -- 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
Packages requiring Xorg BackingStore true
Hello, Some time ago I've packaged Xfoil, Avl and Xrotor (which are popular codes for foil/fluid-dynamics related computations), but I never ended up posting a package review for one reason: the plot window of those programs needs BackingStore true set in xorg.conf, or otherwise the contents of the plot windows will disappear as soon as something else covers the window. Now, this is not a terribly huge blocker, in the sense that the package basically also works without the setting, but still, it is not pretty. Hence I wonder on possible approaches to pursue: - There are reports of BackingStore causing instabilities with certain configurations, so I guess shipping a file in xorg.conf.d is not really the way to go. - A README file telling the user that sHe should enable the setting for the optimal experience but warning of potential instability is probably the best way to proceed, though the user needs to think of looking in /usr/share/doc/Xfoil or in the read the package description to gather this information. - Question for anyone with Xorg knowledge: how feasible is it to patch out of the plot window code the need for BackingStore? I.e. does it only require some minor changes to the Xlib calls? For reference, the code is here: [1] Thanks! Sandro [1] http://smani.fedorapeople.org/Xwin.c -- 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: Packages requiring Xorg BackingStore true
On 09/11/2013 12:16 PM, Sandro Mani wrote:
- Question for anyone with Xorg knowledge: how feasible is it to patch
out of the plot window code the need for BackingStore? I.e. does it only
require some minor changes to the Xlib calls? For reference, the code is
here: [1]
[1] http://smani.fedorapeople.org/Xwin.c
case Expose:
if(last_event != Expose)
{ /* replot_(idev); */
XSetInputFocus(display,window,RevertToNone,CurrentTime); }
break;
As a first step, I would comment-in that replot_ call and see what happens.
--
Florian Weimer / Red Hat Product Security Team
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Heads up - updating openobex in rawhide to 1.7.1 - API change
Hi. I'm going to update the openobex package in rawhide to the latest version (1.7.1) in about two weeks. Unfortunately this version breaks the API, so dependent packages need to be patched in order to be build. Needed changes should be small. Since the rebase is from version 1.5 - 1.7.1 following changes are relevant: Upgrade guide from previous version of openobex === Upgrading to version 1.7 When using an event loop that triggers on incoming data, you must call OBEX_HandleInput() after each call to OBEX_Request() to actually send the request. Upgrading to version 1.6 The function OBEX_UnicodeToAscii() and its counterpart OBEX_AsciiToUnicode() are gone. Please use the more complete functionality from your toolkit. (For example libunistring - http://www.gnu.org/software/libunistring/manual/libunistring.html#uniconv_002eh) If you use one of the functions InOBEX_ServerRegister() and InOBEX_TransportConnect(), please change to TcpOBEX_ServerRegister() and TcpOBEX_TransportConnect(). The functions OBEX_GetCustomData() and OBEX_SetCustomData() will really only work with OBEX_TRANS_CUSTOM. Also, obex_t and obex_object_t changed the declared type. If you pass it around, make sure to use them as pointer. To use the bluetooth function, include the bluetooth headers of your system before including openobex/obex.h or define bt_addr_t to the proper type. The function OBEX_FindInterfaces is replaced by the functions OBEX_EnumerateInterfaces() and OBEX_GetInterfaceByIndex(). The new version of openobex package can be found here: http://koji.fedoraproject.org/koji/taskinfo?taskID=5918748 or http://thozza.fedorapeople.org/openobex-1.7.1-repo/ Dependent packages are: ircp-tray-0:0.7.6-3.fc20 - http://thozza.fedorapeople.org/openobex-1.7.1-rebuilds_results/results_ircp-tray/ libbtctl-0:0.11.1-14.fc20 - http://thozza.fedorapeople.org/openobex-1.7.1-rebuilds_results/results_libbtctl/ libopensync-plugin-irmc-1:0.22-7.fc20 - http://thozza.fedorapeople.org/openobex-1.7.1-rebuilds_results/results_libopensync-plugin-irmc/ obex-data-server-1:0.4.6-6.fc20 - http://thozza.fedorapeople.org/openobex-1.7.1-rebuilds_results/results_obex-data-server/ obexfs-0:0.12-7.fc20 - http://thozza.fedorapeople.org/openobex-1.7.1-rebuilds_results/results_obexfs/ obexftp-0:0.23-15.fc20.x86_64 - http://thozza.fedorapeople.org/openobex-1.7.1-rebuilds_results/results_obexftp/ syncevolution-1:1.3.99.3-6.fc20.x86_64 - http://thozza.fedorapeople.org/openobex-1.7.1-rebuilds_results/results_syncevolution/ If someone thinks we should not rebase openobex to the latest version and has a good reason for it, feel free to replay to this email. Thanks! Regards, Tomas Hozza -- 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: Firewall blocking desktop features
On 2013-09-11 12:02, Nicolas Mailhot wrote: Le Mer 11 septembre 2013 11:23, Alec Leamas a écrit : On 2013-09-11 11:11, Heiko Adams wrote: Am 11.09.2013 10:41, schrieb Ankur Sinha: - These software inform and take permission from the user before opening ports in the firewall. IMHO it should be the job of the firewall to inform the user about an application that want's to open one or more ports and ask for permission to open that ports either temporary for the current session or permanent. Is this a good idea? The firewall just knows aboyt an attempt to use a specific port. It does not know which application which *really* is trying to use that port. It could certainly make an educated guess, but that's just not good enough in this context IMHO. OTOH, the application knows what ports it needs (even some which just might be used later) and can also identify itself to the user. Seems more reasonable to me. The application can lie and propose to open X and then when user says ok open Y. The prompt really needs to be initiated firewall-side True. But isn't there a lot to do if we should safefuard against local, lying applications? Well, we have the precompiled, proprietary ones... Even if an app isn't malware, most applications are just not designed for a scenario where the user is prompted to punch o hole in the firewall as soon as an attempt is done. There might be surprises down this road. That said, I see your point. Seems to boil down to that only the application knows which port(s) to open and why, whereas only the firewall can guarantee that it actually opens the ports requested by user instead of something else. --alec -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Packages requiring Xorg BackingStore true
On ons, 2013-09-11 at 12:16 +0200, Sandro Mani wrote: Hello, Some time ago I've packaged Xfoil, Avl and Xrotor (which are popular codes for foil/fluid-dynamics related computations), but I never ended up posting a package review for one reason: the plot window of those programs needs BackingStore true set in xorg.conf, or otherwise the contents of the plot windows will disappear as soon as something else covers the window. Now, this is not a terribly huge blocker, in the sense that the package basically also works without the setting, but still, it is not pretty. Hence I wonder on possible approaches to pursue: It probably works without backingstore on most modern desktops anyway since they use compositing managers which doesn't throw away non-visible window content. -- 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: Firewall blocking desktop features
Am 11.09.2013 12:30, schrieb Alec Leamas: That said, I see your point. Seems to boil down to that only the application knows which port(s) to open and why, whereas only the firewall can guarantee that it actually opens the ports requested by user instead of something else. So the application needs to ask the firewall to open one or more ports and the firewall has to ask the user for permission to do so. In this szenario the firewall knows what application wants which port(s) to be open. Letting the application directly ask for permission to punch holes in the firewall is IMHO the worst case of all and a securiry nightmare. -- Regards, Heiko Adams signature.asc Description: OpenPGP digital 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: Packages requiring Xorg BackingStore true
On 11.09.2013 12:21, Florian Weimer wrote:
On 09/11/2013 12:16 PM, Sandro Mani wrote:
- Question for anyone with Xorg knowledge: how feasible is it to patch
out of the plot window code the need for BackingStore? I.e. does it only
require some minor changes to the Xlib calls? For reference, the code is
here: [1]
[1] http://smani.fedorapeople.org/Xwin.c
case Expose:
if(last_event != Expose)
{ /* replot_(idev); */
XSetInputFocus(display,window,RevertToNone,CurrentTime); }
break;
As a first step, I would comment-in that replot_ call and see what
happens.
Thanks for you quick reply, unfortunately the replot function is defined
nowhere. Possibly the author had started to look at the issue but never
finished, since I guess that the comment if Expose events are to regen
the display, comment out these references to backing store above assume
the replot function is used. (My blind attempt at commenting the
references to backing store as hinted did not magically fix the problem,
as probably was to be expected).
Adding here to what Alexander answered: this is a good point, I hadn't
thought of that since I was running the program on an Xfce desktop
without compositing...
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
Re: Packages requiring Xorg BackingStore true
On 09/11/2013 01:07 PM, Sandro Mani wrote: Thanks for you quick reply, unfortunately the replot function is defined nowhere. Oooh. Perhaps try calling GWXFLUSH(), then? That should restore the window contents from the stored pixmap. It won't work if client code ever calls GWXDRAWTOWINDOW(), though. Can you provide more context? -- Florian Weimer / Red Hat Product Security Team -- 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: Blocking unblocked retired packages
hi, requested review for libgssglue unretirement: https://bugzilla.redhat.com/show_bug.cgi?id=1006837 can you, please, comment/review? thanks best regards jiri kastner -- 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: does mc really require perl*?
On 2013-09-11, 09:36 GMT, Ian Malone wrote: Can someone explain what the consequences of a 'soft dependency' would actually be and how it would be different from putting those files into a sub-package? (Which may or may not work depending on whether mc is able to cope dynamically with that.) See http://www.debian.org/doc/debian-policy/ch-relationships.html (section 7.2 for definition of Suggests and Recommends). And of course, all this matter only if yum, PackageKit, etc. know about these suggested/recommended packages and have some way how to deal with them. Debian apt* programs have either option to always follow/not-follow these soft-dependencies, or they will just select for installation all packages on which the selected package(s) Depends and then nicely ask user whether she wants to install also suggested/recommended packages. Matěj -- 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] 2013-09-11 @ 16:00 UTC - F20 Alpha Blocker Bug Review #5
# F20 Alpha Blocker Review meeting #5 # Date: 2013-09-11 # Time: 16:00 UTC (12:00 EDT, 09:00 PDT) # Location: #fedora-blocker-review on irc.freenode.net Go/No-Go will be on this Thursday, so it's time for what will hopefully be the last blocker review meeting for F20 alpha. We'll be running through the final blockers and freeze exception bugs. The current list is available at: http://qa.fedoraproject.org/blockerbugs/current We'll be reviewing the bugs to determine ... 1. Whether they meet the alpha release criteria [1] and should stay on the list 2. Whether they are getting the attention they need [1] http://fedoraproject.org/wiki/Fedora_20_Alpha_Release_Criteria For guidance on Blocker and FreezeException bugs, please refer to - https://fedoraproject.org/wiki/QA:SOP_blocker_bug_process - https://fedoraproject.org/wiki/QA:SOP_freeze_exception_bug_process For the blocker review meeting protocol, see -https://fedoraproject.org/wiki/QA:SOP_Blocker_Bug_Meeting signature.asc Description: PGP signature ___ 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: Packages requiring Xorg BackingStore true
On 11.09.2013 13:22, Florian Weimer wrote: On 09/11/2013 01:07 PM, Sandro Mani wrote: Thanks for you quick reply, unfortunately the replot function is defined nowhere. Oooh. Perhaps try calling GWXFLUSH(), then? That should restore the window contents from the stored pixmap. It won't work if client code ever calls GWXDRAWTOWINDOW(), though. Can you provide more context? The xfoil code is here [1]. The relevant code for the plot window is what is in the plotlib subfolder. I've just checked whether that Expose case is ever reached, and it does not seem the case, since GWXCURS is apparently only called occasionally based on user input on the xfoil command line. I guess there would need to be a permanently active while loop which looks at X events, the question is how to do it without blocking the rest of the program - I fear that it is not so easy to do without major changes at the program logic. But thanks for your suggestions, now I have a good idea of where to fiddle around;) Sandro [1] http://smani.fedorapeople.org/xfoil6.97.tar.gz -- 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: does mc really require perl*?
W dniu 11.09.2013 09:05, Miroslav Suchý pisze: So it is merely nice-to-have. Usually called soft-dependency, which unfortunately our tools still does not know. Does somebody knows when we can expect soft dependencies in rpm? IIRC Mandriva had patches which added Suggests/Recommends to RPM over 5 years ago. We used such ones in OpenEmbedded to get rpm packages more in par with ipk/deb ones. -- 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: Firewall blocking desktop features
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 09/11/2013 06:35 AM, Heiko Adams wrote: Am 11.09.2013 12:30, schrieb Alec Leamas: That said, I see your point. Seems to boil down to that only the application knows which port(s) to open and why, whereas only the firewall can guarantee that it actually opens the ports requested by user instead of something else. So the application needs to ask the firewall to open one or more ports and the firewall has to ask the user for permission to do so. In this szenario the firewall knows what application wants which port(s) to be open. Letting the application directly ask for permission to punch holes in the firewall is IMHO the worst case of all and a securiry nightmare. Asking my wife if she intends to open port 2345 is a waste of time. She has no idea whether or not this is required. And will quickly learn to answer ok. Asking her Do you want to make security changes to share directory /home/phyllis/Share? Or Do you want to make security changes to share Printer XYZ? Would make sense. If we had applications register prompts/ports in the installed package that firewalld could look up and send the prompt to the user would be the best solution to this problem. This of course does not stop firefox plugin from attempting to share a directory, but my wife would have more of a chance to say no. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.14 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlIwZhYACgkQrlYvE4MpobO2awCfU+l1bnGFR7nymjUO16PyfB+v 7YkAn0Yegzql2b0SfMq04s0ic+hJfvsJ =6ZgX -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: are you annoyed by frequent password prompts?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 09/11/2013 03:10 AM, Dhiru Kholia wrote: Hi, In FESCo ticket #1115, it was decided to modify the privilege escalation policy in order to allow local, active, admin user to update/remove/etc signed software without requiring a password. At this point, such an user can do pkcon install package to install packages without being prompted for the password. In FESCo ticket #1117, it was decided to extend this policy to potentially cover other privileged operations. At this point, we are looking for more use cases. Lot of such use cases are already listed on the following page, https://fedoraproject.org/wiki/Privilege_escalation_policy Here is a sample use case; ability to launch my own VMs using virt-manager without authenticating every time. Do *you* have a use case of your own? Here is your chance to get rid of those password prompts for your own use case! Please *note* that these policies can be modified locally (or disabled altogether) to fit different situations. An option to *specifically* enable or disable such privilege escalation policy can be given at the install time or / and run-time. Thoughts? Also *note* that the goal of this email (and the ticket in general) is to promote brainstorming at this point. I'm not saying or promising that we are going to do everything you guys demand. Some of you may find http://tinyurl.com/linus-printer to be relevant here. FESCo Tickets == https://fedorahosted.org/fesco/ticket/1115 https://fedorahosted.org/fesco/ticket/1117 Bugzilla Links == https://bugzilla.redhat.com/show_bug.cgi?id=975214 Is the policy as far as installing packages on getting them from a signed repo or does it allow me to install a random package I download from the internet. Signed Repo not a bad idea. Random crap from the internet not a good idea. Since firefox can out and crab stuff to install, and I would never no. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.14 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlIwZ8QACgkQrlYvE4MpobM2NgCgw82uvwwcy7MpVJpJ7wfTKRSA sMkAoMnj54B14HcCnJXwrpjhAPp44CYq =ohvd -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: Firewall blocking desktop features
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 09/11/2013 08:56 AM, Alec Leamas wrote: On 2013-09-11 14:46, Daniel J Walsh wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 09/11/2013 06:35 AM, Heiko Adams wrote: Am 11.09.2013 12:30, schrieb Alec Leamas: That said, I see your point. Seems to boil down to that only the application knows which port(s) to open and why, whereas only the firewall can guarantee that it actually opens the ports requested by user instead of something else. So the application needs to ask the firewall to open one or more ports and the firewall has to ask the user for permission to do so. In this szenario the firewall knows what application wants which port(s) to be open. Letting the application directly ask for permission to punch holes in the firewall is IMHO the worst case of all and a securiry nightmare. Asking my wife if she intends to open port 2345 is a waste of time. She has no idea whether or not this is required. And will quickly learn to answer ok. Asking her Do you want to make security changes to share directory /home/phyllis/Share? Or Do you want to make security changes to share Printer XYZ? Would make sense. If we had applications register prompts/ports in the installed package that firewalld could look up and send the prompt to the user would be the best solution to this problem. This of course does not stop firefox plugin from attempting to share a directory, but my wife would have more of a chance to say no. Although this would work for both our wifes I'd hate it myself. There need to be some way in the interface to understand what's *really* going on here, the ports opened, triggers etc. But not unless requested, agreed. My idea is that Samba registers something with firewalld that says here is the prompt to show if a process in user space says to open port 2345. Or cups registers the ports that would be required to share a printer. And the prompt. The apps on the desktop would have limited control over these prompts other them maybe a couple of args the could pass in. The problem with this solution is potential conflicts in port numbers and pps that just use random ports (Which I think should just not be allowed to use the service and would require to disable the firewall.) Bottom line we need to give feed back to the user about the action being requested that makes sense. I might understand I am sharing a printer or a directory containing music, what network ports these apps require, I would have no clue. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.14 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlIwaqgACgkQrlYvE4MpobPuFgCZAUzmcjZ/FzQ57o1x5NOwjqxu y10AoM2ESDn5xo9ct8r2NTzUerWW2YEI =Z+VQ -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
[perl-App-cpanminus] 1.7001 bump
commit d2a2c75da6740174f8819a0cf1bea2be9e5115f2
Author: Petr Písař ppi...@redhat.com
Date: Wed Sep 11 14:58:54 2013 +0200
1.7001 bump
.gitignore |1 +
perl-App-cpanminus.spec | 45 ++---
sources |2 +-
3 files changed, 20 insertions(+), 28 deletions(-)
---
diff --git a/.gitignore b/.gitignore
index 8aeb964..7c18f09 100644
--- a/.gitignore
+++ b/.gitignore
@@ -57,3 +57,4 @@ App-cpanminus-0.9935.tar.gz
/App-cpanminus-1.6921.tar.gz
/App-cpanminus-1.6922.tar.gz
/App-cpanminus-1.6927.tar.gz
+/App-cpanminus-1.7001.tar.gz
diff --git a/perl-App-cpanminus.spec b/perl-App-cpanminus.spec
index af4181a..20f3e9e 100644
--- a/perl-App-cpanminus.spec
+++ b/perl-App-cpanminus.spec
@@ -1,6 +1,6 @@
Name: perl-App-cpanminus
-Version:1.6927
-Release:3%{?dist}
+Version:1.7001
+Release:1%{?dist}
Summary:Get, unpack, build and install CPAN modules
License:GPL+ or Artistic
Group: Development/Libraries
@@ -31,18 +31,21 @@ BuildRequires: perl(CPAN::Meta::Requirements)
# CPAN::Meta::YAML not needed for compilation
BuildRequires: perl(Cwd)
# Digest::SHA not needed for compilation
+# Dumpvalue not needed for compilation
+# ExtUtils::Manifest not needed for compilation
BuildRequires: perl(File::Basename)
BuildRequires: perl(File::Copy)
BuildRequires: perl(File::Find)
# File::pushd not needed for compilation
BuildRequires: perl(File::Temp)
# HTTP::Tiny not needed for compilation
-# local::lib not needed for compilation
# JSON::PP not needed for compilation
-# Module::CPANfile not needed for compilation
+# local::lib not needed for compilation
# Module::CoreList not needed for compilation
+# Module::CPANfile not needed for compilation
# Module::Metadata not needed for compilation
BuildRequires: perl(Parse::CPAN::Meta)
+# POSIX not needed for compilation
# Safe not needed for compilation
BuildRequires: perl(String::ShellQuote)
BuildRequires: perl(Symbol)
@@ -55,51 +58,33 @@ BuildRequires: perl(Test::More)
Requires: perl(:MODULE_COMPAT_%(eval `perl -V:version`; echo $version))
# Current dependency generator cannot parse compressed code. Use PPI to find
# them, and list them manually:
-Requires: perl(aliased)
# Archive::Tar is optional
# Archive::Zip is optional
# Compress::Zlib is optional
-Requires: perl(Config)
-Requires: perl(constant)
Requires: perl(CPAN::DistnameInfo)
Requires: perl(CPAN::Meta)
Requires: perl(CPAN::Meta::Check)
Requires: perl(CPAN::Meta::Prereqs)
-Requires: perl(CPAN::Meta::Requirements)
Requires: perl(CPAN::Meta::YAML)
-Requires: perl(Cwd)
Requires: perl(Digest::SHA)
Requires: perl(ExtUtils::Install) = 1.46
Requires: perl(ExtUtils::MakeMaker) = 6.31
-Requires: perl(File::Basename)
-Requires: perl(File::Copy)
-Requires: perl(File::Find)
+Requires: perl(ExtUtils::Manifest)
# File::HomeDir is optional
-Requires: perl(File::Path)
Requires: perl(File::pushd)
-Requires: perl(File::Spec)
-Requires: perl(File::Temp)
-Requires: perl(Getopt::Long)
# HTTP getter by LWP::UserAgent or wget or curl or HTTP::Tiny
Requires: perl(HTTP::Tiny)
-Requires: perl(JSON::PP)
Requires: perl(local::lib)
-# LWP::UserAgent is optional
# LWP::Protocol::https is optional
+# LWP::UserAgent is optional
Requires: perl(Module::Build)
Requires: perl(Module::CPANfile)
Requires: perl(Module::CoreList)
Requires: perl(Module::Metadata)
# Module::Signature is optional
-Requires: perl(Parse::CPAN::Meta)
-Requires: perl(Safe)
-Requires: perl(String::ShellQuote)
-Requires: perl(Symbol)
-Requires: perl(version)
Requires: perl(version::vpp)
# Win32 not used
Requires: perl(YAML)
-Provides: perl(App::cpanminus) = %{version}
# XXX: Keep Provides: cpanminus to allow `yum install cpanminus' instead of
# longer `yum install perl-App-cpanminus'.
Provides: cpanminus = %{version}-%{release}
@@ -119,9 +104,12 @@ scripting. When running, it requires only 10 MB of RAM.
%setup -q -n App-cpanminus-%{version}
# Unbundle fat-packed modules
podselect lib/App/cpanminus.pm lib/App/cpanminus.pod
-%{SOURCE1} --libdir lib --filter '^App/cpanminus' bin/cpanm bin/cpanm.stripped
-perl -c -Ilib bin/cpanm.stripped
-mv bin/cpanm{.stripped,}
+
+for F in bin/cpanm lib/App/cpanminus/fatscript.pm; do
+%{SOURCE1} --libdir lib --filter '^App/cpanminus' $F ${F}.stripped
+perl -c -Ilib ${F}.stripped
+mv ${F}.stripped $F
+done
%build
perl Makefile.PL INSTALLDIRS=vendor
@@ -143,6 +131,9 @@ make test
%{_bindir}/cpanm
%changelog
+* Wed Sep 11 2013 Petr Pisar ppi...@redhat.com - 1.7001-1
+- 1.7001 bump
+
* Wed Sep 11 2013 Petr Pisar ppi...@redhat.com - 1.6927-3
- Unbundle all modules (bug #907464)
diff --git a/sources b/sources
Re: Schedule for Wednesday's FESCo Meeting (2013-09-11)
On 09/11/2013 08:23 AM, Marcela Mašláňová wrote: #topic #1170 Working Group call for Volunteers .fesco 1170 https://fedorahosted.org/fesco/ticket/1170 Given that Matthew wanted me to come up with a concrete, positive proposals [¹] surrounding Fedora as a platform, as essentially an tool for sub communities to build upon the core/baseOS and deliver their product as opposed to us having now three categorized defaults as he proposes instead of one. I would like to ask FESCO and other to hold of any work on the ring proposal so I can build and present to the community and we can have the community vote on both those proposal as an way forward for the project for the next 5 - 10 years. Thanks JBG -- 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: Firewall blocking desktop features
On 09/11/2013 02:46 PM, Daniel J Walsh wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 09/11/2013 06:35 AM, Heiko Adams wrote: Am 11.09.2013 12:30, schrieb Alec Leamas: That said, I see your point. Seems to boil down to that only the application knows which port(s) to open and why, whereas only the firewall can guarantee that it actually opens the ports requested by user instead of something else. So the application needs to ask the firewall to open one or more ports and the firewall has to ask the user for permission to do so. In this szenario the firewall knows what application wants which port(s) to be open. Letting the application directly ask for permission to punch holes in the firewall is IMHO the worst case of all and a securiry nightmare. Asking my wife if she intends to open port 2345 is a waste of time. She has no idea whether or not this is required. And will quickly learn to answer ok. Asking her Do you want to make security changes to share directory /home/phyllis/Share? Or Do you want to make security changes to share Printer XYZ? Would make sense. My marriage would be facing serious troubles, if my wife opens any port on our shared machines ;) Seriously, I think you guys are forgetting Linux isn't a Single-User-Single-Seat OSes. 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: Firewall blocking desktop features
On 2013-09-11 15:20, Ralf Corsepius wrote: On 09/11/2013 02:46 PM, Daniel J Walsh wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 09/11/2013 06:35 AM, Heiko Adams wrote: Am 11.09.2013 12:30, schrieb Alec Leamas: That said, I see your point. Seems to boil down to that only the application knows which port(s) to open and why, whereas only the firewall can guarantee that it actually opens the ports requested by user instead of something else. So the application needs to ask the firewall to open one or more ports and the firewall has to ask the user for permission to do so. In this szenario the firewall knows what application wants which port(s) to be open. Letting the application directly ask for permission to punch holes in the firewall is IMHO the worst case of all and a securiry nightmare. Asking my wife if she intends to open port 2345 is a waste of time. She has no idea whether or not this is required. And will quickly learn to answer ok. Asking her Do you want to make security changes to share directory /home/phyllis/Share? Or Do you want to make security changes to share Printer XYZ? Would make sense. My marriage would be facing serious troubles, if my wife opens any port on our shared machines ;) Seriously, I think you guys are forgetting Linux isn't a Single-User-Single-Seat OSes. Ralf Well, it is. Also. And hat's really the core here. It's so damned different in these two cases. --alec -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Firewall blocking desktop features
On 09/11/2013 03:32 PM, Alec Leamas wrote: On 2013-09-11 15:20, Ralf Corsepius wrote: On 09/11/2013 02:46 PM, Daniel J Walsh wrote: -BEGIN PGP SIGNED MESSAGE- Asking her Do you want to make security changes to share directory /home/phyllis/Share? Or Do you want to make security changes to share Printer XYZ? Would make sense. My marriage would be facing serious troubles, if my wife opens any port on our shared machines ;) Seriously, I think you guys are forgetting Linux isn't a Single-User-Single-Seat OSes. Ralf Well, it is. Also. Sure, Single-User-Single-Seat systems are a singular, degenerated case of Multi-User-Multi-Seat systems. And hat's really the core here. It's so damned different in these two cases. Correct, it means that Single-Seat-Single-User focused approaches often lack the generality required on Multi-User-Multi-Seat systems. It often means approaches, which are easily applicable on other OSes, will never fly on Linux. 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: are you annoyed by frequent password prompts?
On Wed, Sep 11, 2013 at 2:53 PM, Daniel J Walsh dwa...@redhat.com wrote: Random crap from the internet not a good idea. Since firefox can out and crab stuff to install, and I would never no. No one is that insane ;) This is all about signed packages. -- 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: Firewall blocking desktop features
On 2013-09-11 15:41, Ralf Corsepius wrote: On 09/11/2013 03:32 PM, Alec Leamas wrote: On 2013-09-11 15:20, Ralf Corsepius wrote: On 09/11/2013 02:46 PM, Daniel J Walsh wrote: -BEGIN PGP SIGNED MESSAGE- Asking her Do you want to make security changes to share directory /home/phyllis/Share? Or Do you want to make security changes to share Printer XYZ? Would make sense. My marriage would be facing serious troubles, if my wife opens any port on our shared machines ;) Seriously, I think you guys are forgetting Linux isn't a Single-User-Single-Seat OSes. Ralf Well, it is. Also. Sure, Single-User-Single-Seat systems are a singular, degenerated case of Multi-User-Multi-Seat systems. And hat's really the core here. It's so damned different in these two cases. Correct, it means that Single-Seat-Single-User focused approaches often lack the generality required on Multi-User-Multi-Seat systems. It often means approaches, which are easily applicable on other OSes, will never fly on Linux. Ralf This discussion could easily fly away. Trying to stay on topic: what we are discussing so far is hints for firewall configuration for each application. I don't think anyone should be upset by that. The key issue is just *who* is punching the hole. But isn't this as simple as having administrative rights for this, which some wifes have and some don't? --alec -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Firewall blocking desktop features
On 09/11/2013 06:30 AM, Alec Leamas wrote: On 2013-09-11 12:02, Nicolas Mailhot wrote: Le Mer 11 septembre 2013 11:23, Alec Leamas a écrit : On 2013-09-11 11:11, Heiko Adams wrote: Am 11.09.2013 10:41, schrieb Ankur Sinha: - These software inform and take permission from the user before opening ports in the firewall. IMHO it should be the job of the firewall to inform the user about an application that want's to open one or more ports and ask for permission to open that ports either temporary for the current session or permanent. Is this a good idea? The firewall just knows aboyt an attempt to use a specific port. It does not know which application which *really* is trying to use that port. It could certainly make an educated guess, but that's just not good enough in this context IMHO. OTOH, the application knows what ports it needs (even some which just might be used later) and can also identify itself to the user. Seems more reasonable to me. The application can lie and propose to open X and then when user says ok open Y. The prompt really needs to be initiated firewall-side True. But isn't there a lot to do if we should safefuard against local, lying applications? Well, we have the precompiled, proprietary ones... Even if an app isn't malware, most applications are just not designed for a scenario where the user is prompted to punch o hole in the firewall as soon as an attempt is done. There might be surprises down this road. That said, I see your point. Seems to boil down to that only the application knows which port(s) to open and why, whereas only the firewall can guarantee that it actually opens the ports requested by user instead of something else. --alec Application should request the ports to be opened and the firewalld layer should then confirm with the user stating which ports and which app requested said ports. The app can't lie if the firewall layer is the one asking for confirmation. -- 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: Firewall blocking desktop features
On 09/11/2013 10:59 AM, Ankur Sinha wrote: - The software*must* inform the user and take permission before opening ports. Hmm, can you use this feature?: https://lists.fedoraproject.org/pipermail/devel/2013-July/186797.html I.e. you will write script, which will ask admin and open the port. And once rpmconf is run, it will execute it. Of course this is just for command line users using rpmconf and lack integration into GUI tools. :( -- 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
Re: does mc really require perl*?
On 09/11/2013 02:18 PM, Marcin Juszkiewicz wrote: IIRC Mandriva had patches which added Suggests/Recommends to RPM over 5 years ago. Suse as well. -- 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
Re: does mc really require perl*?
Miroslav Suchý wrote: On 09/11/2013 02:18 PM, Marcin Juszkiewicz wrote: IIRC Mandriva had patches which added Suggests/Recommends to RPM over 5 years ago. Suse as well. Is there a bug opened for this enhancement? I know it has been talked about for years, but nothing has come out of mailing list discussions. A quick BZ search turned up nothing. -- 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: Schedule for Wednesday's FESCo Meeting (2013-09-11)
On Wed, Sep 11, 2013 at 3:13 PM, Jóhann B. Guðmundsson johan...@gmail.com wrote: On 09/11/2013 08:23 AM, Marcela Mašláňová wrote: #topic #1170 Working Group call for Volunteers .fesco 1170 https://fedorahosted.org/fesco/ticket/1170 Given that Matthew wanted me to come up with a concrete, positive proposals [¹] surrounding Fedora as a platform, as essentially an tool for sub communities to build upon the core/baseOS and deliver their product as opposed to us having now three categorized defaults as he proposes instead of one. This would be a complete chaos from a users POV. We cannot equally support 10 different workstation or server products. Claiming otherwise is dishonest against our users. -- 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: does mc really require perl*?
On 09/11/2013 01:24 PM, Matěj Cepl wrote: Debian apt* programs have either option to always follow/not-follow these soft-dependencies, or they will just select for installation all packages on which the selected package(s) Depends and then nicely ask user whether she wants to install also suggested/recommended packages. To be precise IIRC: * Depends are always installed * Recommends are selected but you can remove from list before installation * Suggests and Enhances are offered for selections, but not selected by default and user must select it manually -- 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
Re: does mc really require perl*?
Once upon a time, Miroslav Suchý msu...@redhat.com said: On 09/11/2013 04:39 PM, Michael Cronenworth wrote: Is there a bug opened for this enhancement? I know it has been talked about for years, but nothing has come out of mailing list discussions. A quick BZ search turned up nothing. You are correct! To my surprise. But this can be easily fixed: https://bugzilla.redhat.com/show_bug.cgi?id=1006954 Lets watch this :) The problem is that many (most?) programs won't handle this well. For example, how does mc handle having its perl scripts installed but non-functional? If it is a graceful failure (an error message that tells you what to do), then maybe a soft dependency would be okay. If you just get a meaningless it failed message (or worse, mc breaks, crashes, etc.), then a soft dependency would not be a good thing. In addition, the package managers need some way later to easily install uninstalled soft dependencies, so when mc doesn't work, someone can just say add what's needed, rather than end-users having to hunt down what is really required to make the external scripts work. Anything that results in more bugs being reported in Bugzilla will not be used by packagers. If soft dependencies existed, and mc used them, the mc packager would most likely stop using them if there were a bunch of I get perl error bug reports. There's a lot of work needed to make soft dependencies work right, and it isn't all that clear that they'd really be useful in a wide variety of cases. -- Chris Adams li...@cmadams.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: fedmsg for voting?
On Sep 10, 2013 8:20 PM, Ralf Corsepius rc040...@freenet.de wrote: On 09/11/2013 12:00 AM, Matthew Miller wrote: I think the benefit of encouraging more participation through voting is a reasonable tradeoff for this particular bit of information (voted in a particular election, possibly chosing no candidates). I do think we need to disclose it. Do you feel strongly enough about this that you would refrain from voting in Fedora elections? (Serious question.) Yes. Votes must be entirely anonymous, as well as their must be no records nor metadata records allowing conclusions about whether an individual has participated in an election. Just for comparison purposes: - a record of whether an individual voted must be kept to prevent an individual voting multiple times. All current and past fedora election software has had this information and kept it private. - a record of who voted for what has been kept since this feature was implemented: fedorahosted.org/elections/ticket/30 in 2009. All election software that recorded this information has kept the information private. -Toshio -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
File Module-Metadata-1.000017.tar.gz uploaded to lookaside cache by pghmcfc
A file has been added to the lookaside cache for perl-Module-Metadata: 191b97e1640f8de856fc4e88efb4ea2e Module-Metadata-1.17.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: does mc really require perl*?
On 09/11/2013 04:39 PM, Michael Cronenworth wrote: Is there a bug opened for this enhancement? I know it has been talked about for years, but nothing has come out of mailing list discussions. A quick BZ search turned up nothing. You are correct! To my surprise. But this can be easily fixed: https://bugzilla.redhat.com/show_bug.cgi?id=1006954 Lets watch this :) -- 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
Re: fedmsg for voting?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On Tue, Sep 10, 2013 at 03:50:58PM -0500, inode0 wrote: On Tue, Sep 10, 2013 at 3:38 PM, Matthew Miller mat...@fedoraproject.org wrote: On Tue, Sep 10, 2013 at 03:24:28PM -0500, inode0 wrote: What is under question is that it publishes a message for each set of votes cast by users[3]. It includes the number of votes cast, the fas username of the person who did the voting, and in what election they voted. It does *not* include what the person voted for or against. That can often be easily obtained from the other information. Assuming the number of votes cast is removed, the two bits of new information here are 1) person voted in a certain election and 2) when they voted. Would it help if we removed #2, by storing the messages and releasing them in random order when the election completes? No. In what election where the votes cast are secret is the fact of voting public? I can't recall ever participating in such an election but maybe my head is full of mud today. I have an expectation that my voting behavior is private. If you vote in the United States the fact that you did, in fact, vote is public record. *How* you voted is not, however. - -- Eric - -- Eric Sparks Christensen Fedora Project spa...@fedoraproject.org - spa...@redhat.com 097C 82C3 52DF C64A 50C2 E3A3 8076 ABDE 024B B3D1 - -- -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.14 (GNU/Linux) iQGcBAEBCgAGBQJSMIbZAAoJEB/kgVGp2CYv/U4L/0e9dH3+sfgWaawtY6ZFMICt vtHEMLY3LFgkKfDUvTsMRiuNrU7ixTyDVltDXHcMFmquOEXhdBMMaMcfNylX6On+ u8mzb1NqsLvsknhxCLBq+3DJrYG/sryWMs3PKb5ws12siHEW+DMlfMMAYbccIUNa 1FAnDGlc9NClPiwXQpNEfRJ/s1Gm1AfXsEuCyuoSJMbP9GYO4/vQouYgf8tl9mEa 8OUTAv3fTdrCrAjbAUDP6TYAyNQ/2MV7+o7g28tvU42fIHxnK3qdiFbLpwKgOghk WEeB3M8NERCha48NAIQQ87cQlLIKLKxeTqYCzAVhJnUw1x5IMDUfI0wSreTuO2qk qWbjd2791PvN31IGd4I7Mf7tOZgQbEMwhv1gzEwNPohUq21oHBcwQXSjGfvHHERx UbcfyV/PcVMihopXrT4vsDW7LZdhtmRWILmYa+M7+IqGsFoJ7RlvNKS9I+zeAKE7 qVB5TlEc/xB2JHUozBP5eOXTsh0SpEEdxRFP2RddSA== =HAWd -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
[perl-Test-Warnings/f20] Update to 0.009
Summary of changes: 49cd1ff... Update to 0.009 (*) (*) 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
Re: fedmsg for voting?
On 09/11/2013 05:00 PM, Toshio Kuratomi wrote: On Sep 10, 2013 8:20 PM, Ralf Corsepius rc040...@freenet.de mailto:rc040...@freenet.de wrote: On 09/11/2013 12:00 AM, Matthew Miller wrote: I think the benefit of encouraging more participation through voting is a reasonable tradeoff for this particular bit of information (voted in a particular election, possibly chosing no candidates). I do think we need to disclose it. Do you feel strongly enough about this that you would refrain from voting in Fedora elections? (Serious question.) Yes. Votes must be entirely anonymous, as well as their must be no records nor metadata records allowing conclusions about whether an individual has participated in an election. Just for comparison purposes: - a record of whether an individual voted must be kept to prevent an individual voting multiple times. Sure. German data privacy laws demand such records be destroyed immediately after the elections. All current and past fedora election software has had this information and kept it private. Have these been deleted/permanently destroyed? If no, in the ages of the NSA scandal, keeping such records is hardly acceptable to anybody (outside of the US). - a record of who voted for what has been kept since this feature was implemented: fedorahosted.org/elections/ticket/30 http://fedorahosted.org/elections/ticket/30 in 2009. All election software that recorded this information has kept the information private. You'd go to jail in Germany, if this SW was used for official elections. Again, I have to emphasize it: The NSA scandal has fundamentally changed the situation. What was tolerable in the past, isn't anymore. Ralf -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: are you annoyed by frequent password prompts?
On Sep 11, 2013 7:10 AM, drago01 drag...@gmail.com wrote: On Wed, Sep 11, 2013 at 2:53 PM, Daniel J Walsh dwa...@redhat.com wrote: Random crap from the internet not a good idea. Since firefox can out and crab stuff to install, and I would never no. No one is that insane ;) This is all about signed packages. Note: Ticket 1115 was about signed packages. Dhiru is currently asking what else should we apply this to? In order to answer 1117. -Toshio -- 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: Firewall blocking desktop features
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 09/11/2013 09:18 AM, Reindl Harald wrote: Am 11.09.2013 15:05, schrieb Daniel J Walsh: On 09/11/2013 08:56 AM, Alec Leamas wrote: Although this would work for both our wifes I'd hate it myself. There need to be some way in the interface to understand what's *really* going on here, the ports opened, triggers etc. But not unless requested, agreed. My idea is that Samba registers something with firewalld that says here is the prompt to show if a process in user space says to open port 2345. very very bad idea! In a perfect world I agree. Sadly we need something better then we currently have. Microsoft tried the tell the user about every port connection and this does not work, because users have no idea. I am trying to find some happy ground between, telling everyone you have to disable firewall to do cool stuff on the desktop. If a random prompt came up that says Do you want to share FOOBAR on the internet? A non educated user could have a chance of saying No? If it kept on happening, he might even ask someone why his machine is acting weird. But if he just said setup sharing of FOOBAR he would understand this and make the correct decision. We have a tool that could be used for labeling the processes that are asking, SELinux, but we would have to eliminate the unconfined_t domain :^(. that means if the is no samba running and whatever harmful process needs to open incoming connections it would trigger the promt for samba these is the way to go only if you want to design a security nightmare The problem with this solution is potential conflicts in port numbers and pps that just use random ports (Which I think should just not be allowed to use the service and would require to disable the firewall.) the real problem i described above as long the is no way to get *predictable* which service/process is aksing for open a specific port and verify this on the system level this all is completly pointless -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.14 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlIwi0QACgkQrlYvE4MpobOOsgCeNKvHYntJyqHecZ3w8SUdk37n +koAn3/y/dI73xIT428bj/23Ryzl/CSK =h307 -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: Schedule for Wednesday's FESCo Meeting (2013-09-11)
On Wed, Sep 11, 2013 at 01:13:04PM +, Jóhann B. Guðmundsson wrote: I would like to ask FESCO and other to hold of any work on the ring proposal so I can build and present to the community and we can have the community vote on both those proposal as an way forward for the project for the next 5 - 10 years. I *do* continue to welcome alternate proposals, but asking everything to stop seems... unhelpful. It's not like this proposal is either sudden or secret. And, it was discussed at several (public, as always) FESCo meetings and discussed and approved by the Fedora Board last week. At this point, what I'd _really_ like is your help in making this work going forward. From what you've said, I don't think we're really all that far out of alignment, and maybe we can bring that together. -- Matthew Miller ☁☁☁ Fedora Cloud Architect ☁☁☁ mat...@fedoraproject.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Schedule for Thursday's FPC Meeting (2013-09-12 16:00 UTC)
Following is the list of topics that will be discussed in the FPC meeting Thursday at 2013-09-12 16:00 UTC in #fedora-meeting-1 on irc.freenode.net. Local time information (via. rktime): 2013-09-12 09:00 Thu US/Pacific PDT 2013-09-12 12:00 Thu US/Eastern EDT 2013-09-12 16:00 Thu UTC - 2013-09-12 17:00 Thu Europe/London BST 2013-09-12 18:00 Thu Europe/Paris CEST 2013-09-12 18:00 Thu Europe/Berlin CEST 2013-09-12 21:30 Thu Asia/Calcutta IST --new day-- 2013-09-13 00:00 Fri Asia/Singapore SGT 2013-09-13 00:00 Fri Asia/Hong_Kong HKT 2013-09-13 01:00 Fri Asia/Tokyo JST 2013-09-13 02:00 Fri Australia/Brisbane EST Links to all tickets below can be found at: https://fedorahosted.org/fpc/report/12 = New business = #topic #339 software collections in Fedora .fpc 339 https://fedorahosted.org/fpc/ticket/339 #topic #344 Wrong library name conflicts solution .fpc 344 https://fedorahosted.org/fpc/ticket/344 = Open Floor = For more complete details, please visit each individual ticket. The report of the agenda items can be found at: https://fedorahosted.org/fpc/report/12 If you would like to add something to this agenda, you can reply to this e-mail, file a new ticket at https://fedorahosted.org/fpc, e-mail me directly, or bring it up at the end of the meeting, during the open floor topic. Note that added topics may be deferred until the following meeting. -- 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: fedmsg for voting?
On Wed, Sep 11, 2013 at 10:06 AM, Eric H. Christensen spa...@fedoraproject.org wrote: On Tue, Sep 10, 2013 at 03:50:58PM -0500, inode0 wrote: No. In what election where the votes cast are secret is the fact of voting public? I can't recall ever participating in such an election but maybe my head is full of mud today. I have an expectation that my voting behavior is private. If you vote in the United States the fact that you did, in fact, vote is public record. *How* you voted is not, however. Ok, now we are getting into a semantic argument for sure. Where I have voted for decades they simply do not have any way to know if I did, in fact, vote. All they know is I showed up to vote. Was the first thing I did in the voting booth click the I'm Done. button? Did I drop an empty ballot into the box on my way out the door? Only I know. You can conclude from registration records most places that someone did not vote for some period of time but I don't see how one can really conclude that anyone in particular did vote if the votes are cast in secret. Of course, if choosing to not vote at the polling station is considered voting then, yeah, you know I voted. Fedora has treated my voting behavior as private so far. If Fedora has respected my privacy to a greater degree than the various governments running other elections I have been involved in then I say good for Fedora. Now I am going to click the I'm Done. button on this. John -- 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-Module-Metadata] Created tag perl-Module-Metadata-1.000017-1.fc21
The lightweight tag 'perl-Module-Metadata-1.17-1.fc21' was created pointing to: c12d050... Update to 1.17 -- 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: Schedule for Wednesday's FESCo Meeting (2013-09-11)
On 09/11/2013 02:41 PM, drago01 wrote: This would be a complete chaos from a users POV. We cannot equally support 10 different workstation or server products. Claiming otherwise is dishonest against our users. ? For the first we dont support anything we only provide best effort secondly we already have extensive server and desktop environment application ( each in a sense an product ) portfolio existing in the project. The only product that we as an larger community would be delivering is the core/baseOS something that might be called FedoraOS The only thing the services sub community would have main focus on supporting is the FedoraOS as well as the installer since it's the product that the sub community would building their product upon and delivering to the world. But hey please give me the time and allow me to provide the community the concrete proposal as an alternative to what Matthew suggested before you shoot it down.. JBG -- 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-Perl-OSType] Update to 1.005
commit 48e91b9c20012474f17f227be17c08042499e682
Author: Paul Howarth p...@city-fan.org
Date: Wed Sep 11 16:54:20 2013 +0100
Update to 1.005
- New upstream release 1.005
- Ensured no non-core test dependencies
- Various non-functional changes to files and metadata included with
the distribution
- Add patch with additional stopwords for the spell checker
- Reinstate EPEL support as we no longer require Capture::Tiny
Perl-OSType-1.005-old-Test::More.patch | 34
Perl-OSType-1.005-stopwords.patch | 11 ++
perl-Perl-OSType.spec | 33 --
sources|2 +-
4 files changed, 76 insertions(+), 4 deletions(-)
---
diff --git a/Perl-OSType-1.005-old-Test::More.patch
b/Perl-OSType-1.005-old-Test::More.patch
new file mode 100644
index 000..11f447a
--- /dev/null
+++ b/Perl-OSType-1.005-old-Test::More.patch
@@ -0,0 +1,34 @@
+--- t/OSType.t
t/OSType.t
+@@ -1,7 +1,7 @@
+ use strict;
+ use warnings;
+
+-use Test::More 0.88;
++use Test::More tests = 19;
+
+ use constant NON_EXISTENT_OS = 'titanix'; #the system they said could not go
down...
+
+@@ -65,5 +65,3 @@ can_ok( $test_pkg, @functions );
+ ok( !is_os_type(), $fcn: false if no type provided );
+ }
+
+-done_testing;
+-
+--- xt/release/test-version.t
xt/release/test-version.t
+@@ -1,6 +1,6 @@
+ use strict;
+ use warnings;
+-use Test::More;
++use Test::More tests = 2;
+
+ # generated by Dist::Zilla::Plugin::Test::Version 0.002004
+ BEGIN { eval use Test::Version; 1; or die $@; }
+@@ -18,5 +18,4 @@ push @imports, $params
+
+ Test::Version-import(@imports);
+
+-version_all_ok;
+-done_testing;
++version_all_ok();
diff --git a/Perl-OSType-1.005-stopwords.patch
b/Perl-OSType-1.005-stopwords.patch
new file mode 100644
index 000..407898e
--- /dev/null
+++ b/Perl-OSType-1.005-stopwords.patch
@@ -0,0 +1,11 @@
+--- lib/Perl/OSType.pm
lib/Perl/OSType.pm
+@@ -103,6 +103,8 @@
+
+ =head1 DESCRIPTION
+
++=for :stopwords Unix Win32 Windows
++
+ Modules that provide OS-specific behaviors often need to know if
+ the current operating system matches a more generic type of
+ operating systems. For example, 'linux' is a type of 'Unix' operating system
diff --git a/perl-Perl-OSType.spec b/perl-Perl-OSType.spec
index e37ba7c..c241e00 100644
--- a/perl-Perl-OSType.spec
+++ b/perl-Perl-OSType.spec
@@ -1,11 +1,17 @@
+# Test suite needs patching if we have Test::More 0.88
+%global old_test_more %(perl -MTest::More -e 'print (($Test::More::VERSION
0.88) ? 1 : 0);' 2/dev/null || echo 0)
+
Name: perl-Perl-OSType
-Version: 1.004
+Version: 1.005
Release: 1%{?dist}
Summary: Map Perl operating system names to generic types
License: GPL+ or Artistic
Group: Development/Libraries
URL: http://search.cpan.org/dist/Perl-OSType/
Source0:
http://search.cpan.org/CPAN/authors/id/D/DA/DAGOLDEN/Perl-OSType-%{version}.tar.gz
+Patch1:Perl-OSType-1.005-old-Test::More.patch
+Patch2:Perl-OSType-1.005-stopwords.patch
+BuildRoot: %{_tmppath}/%{name}-%{version}-%{release}-root-%(id -nu)
BuildArch: noarch
# Build
BuildRequires: perl(ExtUtils::MakeMaker)
@@ -15,10 +21,11 @@ BuildRequires: perl(strict)
BuildRequires: perl(warnings)
# Test Suite
BuildRequires: perl(blib)
-BuildRequires: perl(Capture::Tiny)
BuildRequires: perl(constant)
BuildRequires: perl(File::Spec::Functions)
BuildRequires: perl(File::Temp)
+BuildRequires: perl(IO::Handle)
+BuildRequires: perl(IPC::Open3)
BuildRequires: perl(List::Util)
BuildRequires: perl(Test::More)
# Optional tests, not run for this dual-lived module when bootstrapping
@@ -52,11 +59,20 @@ systems are given the type 'Windows' rather than 'Win32').
%prep
%setup -q -n Perl-OSType-%{version}
+# Fix test suite for Test::More 0.88
+%if %{old_test_more}
+%patch1
+%endif
+
+# More stopwords for the spell checker
+%patch2
+
%build
perl Makefile.PL INSTALLDIRS=vendor
make %{?_smp_mflags}
%install
+rm -rf %{buildroot}
make pure_install DESTDIR=%{buildroot}
find %{buildroot} -type f -name .packlist -exec rm -f {} \;
%{_fixperms} %{buildroot}
@@ -64,15 +80,26 @@ find %{buildroot} -type f -name .packlist -exec rm -f {} \;
%check
make test
%if !%{defined perl_bootstrap} 0%{?fedora}
-make test TEST_FILES=$(echo $(find xt/ -name '*.t'))
+LANG=en_US make test TEST_FILES=$(echo $(find xt/ -name '*.t'))
%endif
+%clean
+rm -rf %{buildroot}
+
%files
%doc Changes CONTRIBUTING LICENSE README
%{perl_vendorlib}/Perl/
%{_mandir}/man3/Perl::OSType.3pm*
%changelog
+* Wed Sep 11 2013 Paul Howarth p...@city-fan.org - 1.005-1
+- Update to 1.005
+ - Ensured no non-core test dependencies
+ - Various non-functional changes to files and metadata included with
+the distribution
+- Add patch with additional stopwords for the spell checker
+- Reinstate
Re: Firewall blocking desktop features
On 09/10/2013 10:07 PM, Peter Oliver wrote: Empathy's People Nearby feature doesn't work out of the box because the required ports are blocked by default by the firewall (https://bugzilla.redhat.com/show_bug.cgi?id=844308). It's a similar story with Gnome's Media Sharing feature, and I'm sure there are lots of other examples. With NM connection editor you can bind zones to the connections. For wireless connections you have a connection per ssid. This makes it possible to bind a zone (for example 'home') to your home connection. If you are trusting your home environment completely, you can also use 'trusted'. Then your home network will have full access to your machine. If you are using your machine in an other environment, then it will use another connection and therefore will be bound to another zone. The initial default zone is 'public'. If you are not in a semi or full trusted environment, then there is no simple solution. See further down... Now, if you're running a server and you install, say, Apache, I think you expect to have to go and poke at the firewall config, but these seem to be very desktop-focused features, and the UI provides no clue about the extra steps required. I am not sure if I am getting this right. What is 'these'? Are you are talking about the desktop UI or firewall-config UI here? The FirewallD wiki page talks about a proposed user interaction mode (https://fedoraproject.org/wiki/FirewallD#User_interaction_mode), which sounds like it's intended to address these kinds of issues. I guess that's not going to be with us soon? The user interaction mode is not planned for the short term anymore and it needs to be verified if it could be used with these desktop features at all. The time to ask the user and to get an ok/deny might be too long to establish a connection with the already received packets. A reconnect might be essential to make it work. Meanwhile, are there any quick ways we could simply this for users? It's not much, but should application packages ship /usr/lib/firewalld/services/service.xml files so that users can open the correct ports by ticking a box in firewall-config rather than having to go hunting around to find the ranges? We already have a long list of service configuration files provided by firewalld, most of them are service related. But there is sure room for improvement. To be able to add a service configuration file, the information about ports etc. is needed. Dynamic ports are not good for this. Lots of these desktop features are using some dynamic port(s), which makes the creation of service configuration files hard or impossible. Therefore there are (mostly) no service configuration files for these desktop features. At first there is no documentation about the used ports, addresses and so on and further more there seems to be no interest in firewalls at all. -- 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 ARM Weekly Status Meeting 2013-09-11
Good day all, Please join us today (Wednesday, September 11th) at 4PM EDT (8PM UTC) for the Fedora ARM weekly status meeting in #fedora-meeting-1 on Freenode. On the agenda so far.. 1) Kernel Status Update 2) Aarch64 - Status Update - Koji 3) Fedora 20 Alpha RC1 4) Weekly Status Meeting 5) Open Floor If there is something that you would like to discuss that isn't mentioned please feel free to bring it up at the end of the meeting or send an email to the list. Paul -- 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 Alpha Release Candidate 1 (RC1) Available Now!
NOTE: The 32- and 64-bit DVDs, the 64-bit Desktop Live, the 32-bit MATE and Security Spins, and the 64-bit LXDE and MATE Spins are over their respective size targets. As per the Fedora 20 schedule [1], Fedora 20 Alpha Release Candidate 1 (RC1) is now available for testing. Content information, including changes, can be found at https://fedorahosted.org/rel-eng/ticket/5745#comment:23 . Please see the following pages for download links (including delta ISOs) and testing instructions. Normally dl.fedoraproject.org should provide the fastest download, but download-ib01.fedoraproject.org is available as a mirror (with an approximately 1 hour lag) in case of trouble. To use it, just replace dl with download-ib01 in the download URL. Installation: https://fedoraproject.org/wiki/Test_Results:Current_Installation_Test Base: https://fedoraproject.org/wiki/Test_Results:Current_Base_Test Desktop: https://fedoraproject.org/wiki/Test_Results:Current_Desktop_Test Ideally, all Alpha priority test cases for Installation [2], Base [3], and Desktop [4] should pass in order to meet the Alpha Release Criteria [5]. Help is available on #fedora-qa on irc.freenode.net [6], or on the test list [7]. Create Fedora 20 Alpha test compose (TC) and release candidate (RC) https://fedorahosted.org/rel-eng/ticket/5745 Current Blocker and Freeze Exception bugs: http://qa.fedoraproject.org/blockerbugs/current [1] http://fedorapeople.org/groups/schedule/f-20/f-20-quality-tasks.html [2] https://fedoraproject.org/wiki/QA:Installation_validation_testing [3] https://fedoraproject.org/wiki/QA:Base_validation_testing [4] https://fedoraproject.org/wiki/QA:Desktop_validation_testing [5] https://fedoraproject.org/wiki/Fedora_20_Alpha_Release_Criteria [6] irc://irc.freenode.net/fedora-qa [7] https://admin.fedoraproject.org/mailman/listinfo/test signature.asc Description: OpenPGP digital signature ___ 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: Schedule for Wednesday's FESCo Meeting (2013-09-11)
On 09/11/2013 04:18 PM, Matthew Miller wrote: At this point, what I'd_really_ like is your help in making this work going forward. From what you've said, I don't think we're really all that far out of alignment, and maybe we can bring that together. There is alot of alignment in how I see us going forward as are in your proposal however there is a fundamental difference in what you are proposing and what I'm proposing we should do. What I see us going forward with is the core/baseOS FedoraOS that the community delivers at large while the sub community they themselves set the direction, their target audience and deliver their product on top of the stable foundation we provide them with, the FedoraOS. You want to limit the project to three official default products that the community delivers at large, which to me, does not solve existing problem in our community, narrows down the scope of the project as well as hinders innovation and participation while I want to liberate the community from the shackles of the default thus finally put the default skeletons to their grave, reduce the bureaucracy and allow for more innovation. more products, and faster adoption for us as an community in whole to the constantly changing open source environment and have us contribute shaping that landscape. Due to the fundamental difference in our proposal I'm not seeing where we could meet half way through, on a common grounds in them ( i'm all ears if you have a starting point ). And since we are setting the direction for the project for the next 5 - 10 years we as a community need to give this some serious thought if something like what you proposed is the way forward ( tying us down to 3 products ) or if we should move into the direction of what I propose in that time. JBG -- 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 978233] perl-5.18: Regex \8 and \9 after literals no longer work
https://bugzilla.redhat.com/show_bug.cgi?id=978233 Fedora Update System upda...@fedoraproject.org changed: What|Removed |Added Status|MODIFIED|ON_QA --- Comment #5 from Fedora Update System upda...@fedoraproject.org --- Package perl-5.18.1-288.fc20: * should fix your issue, * was pushed to the Fedora 20 testing repository, * should be available at your local mirror within two days. Update it with: # su -c 'yum update --enablerepo=updates-testing perl-5.18.1-288.fc20' as soon as you are able to. Please go to the following url: https://admin.fedoraproject.org/updates/FEDORA-2013-16400/perl-5.18.1-288.fc20 then log in and leave karma (feedback). -- 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=EskaeUJP0xa=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
[Bug 989486] perl-5.18: Dereferencing undefined glob value as a code reference causes segfault
https://bugzilla.redhat.com/show_bug.cgi?id=989486 Fedora Update System upda...@fedoraproject.org changed: What|Removed |Added Status|MODIFIED|ON_QA --- Comment #3 from Fedora Update System upda...@fedoraproject.org --- Package perl-5.18.1-288.fc20: * should fix your issue, * was pushed to the Fedora 20 testing repository, * should be available at your local mirror within two days. Update it with: # su -c 'yum update --enablerepo=updates-testing perl-5.18.1-288.fc20' as soon as you are able to. Please go to the following url: https://admin.fedoraproject.org/updates/FEDORA-2013-16400/perl-5.18.1-288.fc20 then log in and leave karma (feedback). -- 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=9D7PEbLIBua=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
[Bug 988805] IPC::Open3 keeps zombies after failed execve()
https://bugzilla.redhat.com/show_bug.cgi?id=988805 Fedora Update System upda...@fedoraproject.org changed: What|Removed |Added Status|MODIFIED|ON_QA --- Comment #3 from Fedora Update System upda...@fedoraproject.org --- Package perl-5.18.1-288.fc20: * should fix your issue, * was pushed to the Fedora 20 testing repository, * should be available at your local mirror within two days. Update it with: # su -c 'yum update --enablerepo=updates-testing perl-5.18.1-288.fc20' as soon as you are able to. Please go to the following url: https://admin.fedoraproject.org/updates/FEDORA-2013-16400/perl-5.18.1-288.fc20 then log in and leave karma (feedback). -- 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=NlRlORss7ra=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
[Bug 970567] perl-5.18: t/op/coreamp.t sometimes fails
https://bugzilla.redhat.com/show_bug.cgi?id=970567 Fedora Update System upda...@fedoraproject.org changed: What|Removed |Added Status|MODIFIED|ON_QA --- Comment #3 from Fedora Update System upda...@fedoraproject.org --- Package perl-5.18.1-288.fc20: * should fix your issue, * was pushed to the Fedora 20 testing repository, * should be available at your local mirror within two days. Update it with: # su -c 'yum update --enablerepo=updates-testing perl-5.18.1-288.fc20' as soon as you are able to. Please go to the following url: https://admin.fedoraproject.org/updates/FEDORA-2013-16400/perl-5.18.1-288.fc20 then log in and leave karma (feedback). -- 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=daUOHjoU3Pa=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: Firewall blocking desktop features
Am 11.09.2013 15:05, schrieb Daniel J Walsh: On 09/11/2013 08:56 AM, Alec Leamas wrote: Although this would work for both our wifes I'd hate it myself. There need to be some way in the interface to understand what's *really* going on here, the ports opened, triggers etc. But not unless requested, agreed. My idea is that Samba registers something with firewalld that says here is the prompt to show if a process in user space says to open port 2345. very very bad idea! that means if the is no samba running and whatever harmful process needs to open incoming connections it would trigger the promt for samba these is the way to go only if you want to design a security nightmare The problem with this solution is potential conflicts in port numbers and pps that just use random ports (Which I think should just not be allowed to use the service and would require to disable the firewall.) the real problem i described above as long the is no way to get *predictable* which service/process is aksing for open a specific port and verify this on the system level this all is completly pointless signature.asc Description: OpenPGP digital 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
[perl-Perl-OSType/f20] Update to 1.005
Summary of changes: 48e91b9... Update to 1.005 (*) (*) 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
Re: Schedule for Wednesday's FESCo Meeting (2013-09-11)
On Wed, Sep 11, 2013 at 6:27 PM, Jóhann B. Guðmundsson johan...@gmail.com wrote: On 09/11/2013 02:41 PM, drago01 wrote: This would be a complete chaos from a users POV. We cannot equally support 10 different workstation or server products. Claiming otherwise is dishonest against our users. ? For the first we dont support anything we only provide best effort secondly we already have extensive server and desktop environment application ( each in a sense an product ) portfolio existing in the project. Lets not discuss the word support again we have had enough threads of that. And yes we have other desktop environments in the project but we do not promote them equally because we don't have the resources to support them on equal terms. The only product that we as an larger community would be delivering is the core/baseOS something that might be called FedoraOS And I disagree with that. I thing we should produce something that we can give to our users. The only thing the services sub community would have main focus on supporting is the FedoraOS as well as the installer since it's the product that the sub community would building their product upon and delivering to the world. See above. But hey please give me the time and allow me to provide the community the concrete proposal as an alternative to what Matthew suggested before you shoot it down.. You are of course free to come up with a concrete proposal but it is not like I cannot kind of predict what kind of direction you want to move in (based on your past emails not just in this thread) ... I am not convinced that this one is feasible as way forward. -- 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 982131] Regular expression in regular expression code block corrupts back-reference
https://bugzilla.redhat.com/show_bug.cgi?id=982131 Fedora Update System upda...@fedoraproject.org changed: What|Removed |Added Status|MODIFIED|ON_QA --- Comment #3 from Fedora Update System upda...@fedoraproject.org --- Package perl-5.18.1-288.fc20: * should fix your issue, * was pushed to the Fedora 20 testing repository, * should be available at your local mirror within two days. Update it with: # su -c 'yum update --enablerepo=updates-testing perl-5.18.1-288.fc20' as soon as you are able to. Please go to the following url: https://admin.fedoraproject.org/updates/FEDORA-2013-16400/perl-5.18.1-288.fc20 then log in and leave karma (feedback). -- 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=ddwHj6p595a=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: Packages requiring Xorg BackingStore true
On Wed, 2013-09-11 at 12:32 +0200, Alexander Larsson wrote: On ons, 2013-09-11 at 12:16 +0200, Sandro Mani wrote: Hello, Some time ago I've packaged Xfoil, Avl and Xrotor (which are popular codes for foil/fluid-dynamics related computations), but I never ended up posting a package review for one reason: the plot window of those programs needs BackingStore true set in xorg.conf, or otherwise the contents of the plot windows will disappear as soon as something else covers the window. Now, this is not a terribly huge blocker, in the sense that the package basically also works without the setting, but still, it is not pretty. Hence I wonder on possible approaches to pursue: It probably works without backingstore on most modern desktops anyway since they use compositing managers which doesn't throw away non-visible window content. Well, yes, but it ought to work regardless of the xorg.conf setting, because that setting has been effectively hardwired to true for about six years now. I rewrote the backing store implementation to use Composite internally, which is always available, so we just blindly ignore the config setting and give you backing store if you ask for it. There may be bugs, I freely admit, but it's definitely meant to work. If it doesn't it's probably a bug in X and I'll fix it, so hook me up with test packages and I'll take a look. - ajax -- 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: [389-devel] 389-devel Digest, Vol 99, Issue 6
389-devel-requ...@lists.fedoraproject.org wrote: Send 389-devel mailing list submissions to 389-de...@lists.fedoraproject.org To subscribe or unsubscribe via the World Wide Web, visit https://admin.fedoraproject.org/mailman/listinfo/389-devel or, via email, send a message with subject or body 'help' to 389-devel-requ...@lists.fedoraproject.org You can reach the person managing the list at 389-devel-ow...@lists.fedoraproject.org When replying, please edit your Subject line so it is more specific than Re: Contents of 389-devel digest... Today's Topics: 1. Re: RFC: New Design: Fine Grained ID List Size (Rich Megginson) 2. Re: RFC: New Design: Fine Grained ID List Size (Ludwig Krispenz) -- Message: 1 Date: Tue, 10 Sep 2013 08:29:14 -0600 From: Rich Megginson rmegg...@redhat.com To: Ludwig Krispenz lkris...@redhat.com Cc: 389 Directory server developer discussion. 389-de...@lists.fedoraproject.org Subject: Re: [389-devel] RFC: New Design: Fine Grained ID List Size Message-ID: 522f2cba.1040...@redhat.com Content-Type: text/plain; charset=UTF-8; format=flowed On 09/10/2013 01:47 AM, Ludwig Krispenz wrote: On 09/09/2013 07:19 PM, Rich Megginson wrote: On 09/09/2013 02:27 AM, Ludwig Krispenz wrote: On 09/07/2013 05:02 AM, David Boreham wrote: On 9/6/2013 8:49 PM, Nathan Kinder wrote: This is a good idea, and it is something that we discussed briefly off-list. The only downside is that we need to change the index format to keep a count of ids for each key. Implementing this isn't a big problem, but it does mean that the existing indexes need to be updated to populate the count based off of the contents (as you mention above). I don't think you need to do this (I certainly wasn't advocating doing so). The statistics state is much the same as that proposed in Rich's design. In fact you could probably just use that same information. My idea is more about where and how you use the information. All you need is something associated with each index that says not much point looking here if you're after something specific, move along, look somewhere else instead. This is much the same information as don't use a high scan limit here. In the short term, we are looking for a way to be able to improve performance for specific search filters that are not possible to modify on the client side (for whatever reason) while leaving the index file format exactly as it is. I still feel that there is potentially great value in keeping a count of ids per key so we can optimize things on the server side automatically without the need for complex index configuration on the administrator's part. I think we should consider this for an additional future enhancement. I'm saying the same thing. Keeping a cardinality count per key is way more than I'm proposing, and I'm not sure how useful that would be anyway, unless you want to do OLAP in the DS ;) we have the cardinality of the key in old-idl and this makes some searches where parts of the filter are allids fast. I'm late in the discussion, but I think Rich's proposal is very promising to address all the problems related to allids in new-idl. We could then eventually rework filter ordering based on these configurations. Right now we only have a filter ordering based on index type and try to postpone = or similar filter as they are known to be costly, but this could be more elaborate. An alternative would be to have some kind of index lookup caching. In the example in ticket 47474 the filter is ((|(objectClass=organizationalPerson)(objectClass=inetOrgPerson)(objectClass=organization)(objectClass=organizationalUnit)(objectClass=groupOf Names)(objectClass=groupOfUniqueNames)(objectClass=group))(c3sUserID=EndUser078458)) and probably only the c3sUserID=x part will change, if we cache the result for the ((|(objectClass=... part, even if it is expensive, it would be done only once. Thanks everyone for the comments. I have added Noriko's suggestion: http://port389.org/wiki/Design/Fine_Grained_ID_List_Size David, Ludwig: Does the current design address your concerns, and/or provide the necessary first step for further refinements? yes, the topic of filter reordering or caching could be looked at independently. Just one concern abou the syntax: nsIndexIDListScanLimit: maxsize[:indextype][:flag[,flag...]][:value[,value...]] since everything is optional, how do you decide if in nsIndexIDListScanLimit: 6:eq:AND AND is a value or a flag ? and as it defines limits for specific keys, could the attributname reflect this, eg nsIndexKeyIDListScanLimit or nsIndexKeyScanLimit or ... ? Thanks, yes, it is ambiguous. I think it may have to use keyword=value, so something like this: nsIndexIDListScanLimit: limit=NNN [type=eq[,sub]] [flags=ADD[,OR]] [values=val[,val...]] That should be easy to parse for both humans and machines. For values, will have
Re: Proposal: AppData files in all application packages?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Fri, 6 Sep 2013 10:33:42 +0100 Richard Hughes hughsi...@gmail.com wrote: Hi all. I'm the developer for PackageKit and gnome-software, the latter being the new software center we're hopefully including as a technical preview in Fedora 20. snip Any questions, either grab me on irc 'hughsie' or reply to this email. Be sure to read [1] as a lot of common questions are answered there. I have one question, if the data is shipped in the packages how is it supposed to get to the end user so that they can know about it and choose to install the application? Dennis -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.21 (GNU/Linux) iEYEARECAAYFAlIwrHMACgkQkSxm47BaWfeUVQCgqL4XJrR5z3694HQjvSaXOM0P 228An112DvsSejBOJVwOjedMlbaet0DK =FIpA -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: Problem getting package to compile on EL6
On Tue, 10 Sep 2013 16:48:37 -0600 Orion Poplawski or...@cora.nwra.com wrote: That's interesting - I don't see a segfault. It would seem that the first find error comes from the strip phase (line 196 of find-debuginfo.sh), and the second from the symlink phase (line 262). You need to set RPM_BUILD_DIR and RPM_BUILD_ROOT to run find-debuginfo.sh by hand. That gets rid of the find error. Thanks. I've now confirmed that this is indeed https://bugzilla.redhat.com/show_bug.cgi?id=903009 as you suspected. -- Susi Lehtola Fedora Project Contributor jussileht...@fedoraproject.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Fedora 20-Alpha RC1 AMIS
On Wed, Sep 11, 2013 at 01:00:10PM -0500, Dennis Gilmore wrote: RC1 images have been uploaded to EC2 and are available at ami-136a237a : us-east-1 image for i386 ami-116b2278 : us-east-1 image for x86_64 Awesome. Thanks again. additionally if your looking to the AMI's they have been added to files in the release tree http://dl.fedoraproject.org/pub/alt/stage/20-Alpha-RC1/Images/i386/Fedora-Images-i386-20-Alpha-AMI http://dl.fedoraproject.org/pub/alt/stage/20-Alpha-RC1/Images/x86_64/Fedora-Images-x86_64-20-Alpha-AMI To be clear, those are files containing the AMI id, not the actual AMI bits. This is bikeshedding to some degree, but maybe they should be named to reflect that? #nobigdeal -- Matthew Miller ☁☁☁ Fedora Cloud Architect ☁☁☁ mat...@fedoraproject.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Schedule for Wednesday's FESCo Meeting (2013-09-11)
On 09/11/2013 05:37 PM, drago01 wrote: Lets not discuss the word support again we have had enough threads of that. And yes we have other desktop environments in the project but we do not promote them equally because we don't have the resources to support them on equal terms. You mean Red Hat is not backing up their development through manpower equally and not doing so makes them lesser of products then Gnome and hence we should not give them equal place and footing within our project and our community. In other words we should only proudly display and stand behind applications and application stacks that are backed up by Red Hat from our community. Yep that's pretty much how that 3 product default sounds to me, I however do not discriminate between application in our community nor between the people that are maintaining them. And encase you have missed the 21 centry... The fact is even after all those years of people crying This year will be the year of the Linux desktop!, we still cant do as basic function as to update the firmware on our computers, we still cant update the firmware of all the peripheral devices like camera, mobile phone,tablets, gps etc. The manufacturers of those devices still dont provide application for their devices that run on top of general linux distrubtion and they never will since they are making the application available for Android and IOS and are providing tables in schools ( as opposed to pc's ) so I'm not sure if you have realized it yet but the era of the consumer desktop environment as we have known it, on any OS is coming to end. And proposing that we somehow continue to tie ourselves and our processes to *any* of the desktop environments in the GNU/Linux ecosystem while they try to redefine themselves and struggle with their own existence is not doing us as a community any favours nor our users base. What I argue with my proposal is that we prepare ourself and our workflow for that inevitable evolution that will take place in 5 - 10 years and continue to keep ourselves relevant and help shaping the IT industry in the 21 century. JBG -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
[OffTopic] Backup of messages from Google Groups group?
Hi, I know that I am off topic here, but I guess somebody here may tried to deal with this issue. I would like to create a group on gmane.org for jbr...@googlegroups.com list and if possible import all its messages there (because, among reasons, it is obvious that gmane.org is much more user friendly than googlegroups). Now, I know there is no official support for export of messages from Google Groups (entry for it on the Data Liberation Front website is conspicuous by its absence), but I trust esteemed group of hackers here that they created some better solution. Did you? Best, Matěj -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
File Module-Metadata-1.000018.tar.gz uploaded to lookaside cache by pghmcfc
A file has been added to the lookaside cache for perl-Module-Metadata: 36174dd21bf9168e513c7351ef2b9f2b Module-Metadata-1.18.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: does mc really require perl*?
On 2013-09-11, 15:56 GMT, Richard W.M. Jones wrote: mc is also missing a dependency on dpkg! Not really. If some esteemed Perl hacker here would be willing to spent some time on /usr/libexec/mc/extfs.d/dpkg+ I think it could be possible to get it into shape. Deb archives are nothing than else than ar(1) archives in disguise (i.e., it is possible to do ar x file.deb to get to it). Best, Matěj -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Proposal: AppData files in all application packages?
On Wed, 2013-09-11 at 12:46 -0500, Dennis Gilmore wrote: Any questions, either grab me on irc 'hughsie' or reply to this email. Be sure to read [1] as a lot of common questions are answered there. I have one question, if the data is shipped in the packages how is it supposed to get to the end user so that they can know about it and choose to install the application? We plan to extract it in the build system and provide it separate from the applications in the repository. -- 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: Schedule for Wednesday's FESCo Meeting (2013-09-11)
On Wed, Sep 11, 2013 at 05:22:54PM +, Jóhann B. Guðmundsson wrote: What I see us going forward with is the core/baseOS FedoraOS that the community delivers at large while the sub community they themselves set the direction, their target audience and deliver their product on top of the stable foundation we provide them with, the FedoraOS. Yes, this is basically the proposal in its current form. You want to limit the project to three official default products I don't want to limit the project in that way. I think these three products are reasonable starting points. I think _one_ doesn't work because it's impossible to be all things to all people and we also can't (and shouldn't) simply choose one narrow case. I also think chosing _none_ doesn't work, because there are concrete benefits to having a clear direction. So, when the idea of three products (Stephen Gallagher's proposal) came up at Flock, that seemed like a reasonable place to start. The respective subgroups will need to define exactly what those products look like -- after establishing governing and communication strategies, this is their first deliverable. And if working groups other than these three want to form and start delivering the same, the board can choose to make those primary as well, just as they've approved these three initially. that the community delivers at large, which to me, does not solve So, this depends a lot on what you mean by community at large here. I want Fedora to be inclusive, and the work of all of the subgroups to be considered part of the community. existing problem in our community, narrows down the scope of the project as well as hinders innovation and participation while I want to liberate the community from the shackles of the default thus finally put the default skeletons to their grave, reduce the bureaucracy and allow for more innovation. more products, and faster adoption for us as an community in whole to the constantly changing open source environment and have us contribute shaping that landscape. I'm not finding much to disagree with in the specifics here, but I don't think I understand some of the more vague parts. What existing problem in our community in particular do you want to address? What do you mean by narrows down the scope, when we are going from that single default you clearly dislike into a broader world? Sure, each of the different products will no longer be expected to be all things to all people, but it's about _focus_, not excusion. Now, about bureaucracy -- I don't think it's overly heavy-handed to require clear membership, governence model, and so on. Yes, that's more formal than a SIG, but the working groups don't *need* to have a heavyweight process if they don't want -- they just need a clear, documented one. And while this does call for the formation of more committees, each will have more autonomy than a SIG or spin, and each will have that focus I just mentioned as an organizing principle, along with clear deliverables. -- Matthew Miller ☁☁☁ Fedora Cloud Architect ☁☁☁ mat...@fedoraproject.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Fedora 20-Alpha RC1 AMIS
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 hi all, RC1 images have been uploaded to EC2 and are available at ami-136a237a : us-east-1 image for i386 ami-116b2278 : us-east-1 image for x86_64 additionally if your looking to the AMI's they have been added to files in the release tree http://dl.fedoraproject.org/pub/alt/stage/20-Alpha-RC1/Images/i386/Fedora-Images-i386-20-Alpha-AMI http://dl.fedoraproject.org/pub/alt/stage/20-Alpha-RC1/Images/x86_64/Fedora-Images-x86_64-20-Alpha-AMI when we get to final alpha and the images are uploaded to all regions they will all be listed and the file will be signed in the final tree Dennis -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.21 (GNU/Linux) iEYEARECAAYFAlIwr6oACgkQkSxm47BaWfezGwCfZ6dkyF5fsb+MPUQg2IXFpDdV DhAAoJBo2LBkGTQ+Drkt0HLrTz1PfpY3 =dFPM -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
SSSD 1.11 and AD homeDirectory
I'm messing around a bit with the new AD support in SSSD 1.11. I've gotten authentication working against our AD at work, but I'd like to be able to mount the user's home folder (in our environment, it gets mapped to the P: drive if you're logging into a Windows system that is part of the domain) as their Linux home directory. The user's home folder can be on one of a dozen or more file servers, so I need to use the AD homeDirectory attribute and dynamically mount the CIFS filesystem. Numerous Google searches and man page readings haven't turned up the magic incantation that I need to turn this on. Is what I want to do possible with SSSD 1.11? If so, is it documented anywhere than the source? -- Jeff Ollie -- 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: Schedule for Wednesday's FESCo Meeting (2013-09-11)
On 09/11/2013 05:57 PM, Matthew Miller wrote: You want to limit the project to three official default products I don't want to limit the project in that way. I think these three products are reasonable starting points. I do not and from my perspective we should only be focusing on what I call FedoraOS ( core/baseOS ) I think _one_ doesn't work because it's impossible to be all things to all people and we also can't (and shouldn't) simply choose one narrow case. That's the fundamental disagreement I was talking about unlike you I think the sub communities that produce their product are the ones that should be focusing on this. I also think chosing _none_ doesn't work, because there are concrete benefits to having a clear direction. So, when the idea of three products (Stephen Gallagher's proposal) came up at Flock, that seemed like a reasonable place to start. The sub communities they themselves will set their own direction, their own target audience and their own goals as well be in full control how they will try to meet those goal after all they are the ones doing all the work necessary to achieve that goal in ( mostly in their spare time I might add ). The respective subgroups will need to define exactly what those products look like -- after establishing governing and communication strategies, this is their first deliverable. And if working groups other than these three want to form and start delivering the same, the board can choose to make those primary as well, just as they've approved these three initially. that the community delivers at large, which to me, does not solve So, this depends a lot on what you mean by community at large here. I want Fedora to be inclusive, and the work of all of the subgroups to be considered part of the community. By community at large I mean the entire project made up of ever community member sub-community or otherwise. I did not call this subgroups but sub communities which I though clearly indicated they were part of the community at large. existing problem in our community, narrows down the scope of the project as well as hinders innovation and participation while I want to liberate the community from the shackles of the default thus finally put the default skeletons to their grave, reduce the bureaucracy and allow for more innovation. more products, and faster adoption for us as an community in whole to the constantly changing open source environment and have us contribute shaping that landscape. I'm not finding much to disagree with in the specifics here, but I don't think I understand some of the more vague parts. What existing problem in our community in particular do you want to address? The discrimination problem that has existed this whole time between contributors as in not all contributors are treated equal nor their work is getting equal presentation from the project. What do you mean by narrows down the scope, when we are going from that single default you clearly dislike into a broader world? Sure, each of the different products will no longer be expected to be all things to all people, but it's about _focus_, not excusion. As see it it is indeed about exclusion since you will be excluding everyone that are not part of those three defaults as we are doing now with a single default. Now, about bureaucracy -- I don't think it's overly heavy-handed to require clear membership, governence model, and so on. Yes, that's more formal than a SIG, but the working groups don't *need* to have a heavyweight process if they don't want The sub communities themselves already have existing governing structure. The cloud community has theirs, the server community has theirs etc. We dont need an additional layer on top of that other than arguably what Josh recently proposed on the advisory list. JBG -- 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-Module-Metadata] Created tag perl-Module-Metadata-1.000018-1.fc20
The lightweight tag 'perl-Module-Metadata-1.18-1.fc20' was created pointing to: 7e4bd58... Update to 1.18 -- 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-Module-Metadata] Update to 1.000018
commit 7e4bd583256d802641bad5e1481c478a0eaf31e6
Author: Paul Howarth p...@city-fan.org
Date: Wed Sep 11 19:41:13 2013 +0100
Update to 1.18
- New upstream release 1.18
- Re-release of de-tainting fix without unstated non-core test
dependencies
- Drop BR: perl(Test::Fatal)
perl-Module-Metadata.spec |8 ++--
sources |2 +-
2 files changed, 7 insertions(+), 3 deletions(-)
---
diff --git a/perl-Module-Metadata.spec b/perl-Module-Metadata.spec
index d69072d..19f6970 100644
--- a/perl-Module-Metadata.spec
+++ b/perl-Module-Metadata.spec
@@ -1,5 +1,5 @@
Name: perl-Module-Metadata
-Version: 1.17
+Version: 1.18
Release: 1%{?dist}
Summary: Gather package and POD information from perl module files
License: GPL+ or Artistic
@@ -25,7 +25,6 @@ BuildRequires:perl(Exporter)
BuildRequires: perl(File::Temp)
BuildRequires: perl(File::Path)
BuildRequires: perl(lib)
-BuildRequires: perl(Test::Fatal)
BuildRequires: perl(Test::More)
# Release tests
%if !%{defined perl_bootstrap}
@@ -63,6 +62,11 @@ make test TEST_FILES=xt/*.t
%{_mandir}/man3/Module::Metadata.3pm*
%changelog
+* Wed Sep 11 2013 Paul Howarth p...@city-fan.org - 1.18-1
+- Update to 1.18
+ - Re-release of de-tainting fix without unstated non-core test dependencies
+- Drop BR: perl(Test::Fatal)
+
* Wed Sep 11 2013 Paul Howarth p...@city-fan.org - 1.17-1
- Update to 1.17
- De-taint version, if needed (CPAN RT#88576)
diff --git a/sources b/sources
index 3f61582..00a0258 100644
--- a/sources
+++ b/sources
@@ -1 +1 @@
-191b97e1640f8de856fc4e88efb4ea2e Module-Metadata-1.17.tar.gz
+36174dd21bf9168e513c7351ef2b9f2b Module-Metadata-1.18.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-Module-Metadata] Created tag perl-Module-Metadata-1.000018-1.fc21
The lightweight tag 'perl-Module-Metadata-1.18-1.fc21' was created pointing to: 7e4bd58... Update to 1.18 -- 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
Summary/Minutes from today's FESCo Meeting (2013-09-11)
=== #fedora-meeting: FESCO (2013-09-11) === Meeting started by mmaslano at 18:00:15 UTC. The full logs are available at http://meetbot.fedoraproject.org/fedora-meeting/2013-09-11/fesco.2013-09-11-18.00.log.html . Meeting summary --- * init process (mmaslano, 18:04:51) * #1117 Generalize policy about privilege escalation and Administrator user accounts (mmaslano, 18:05:05) * AGREED: remove this ticket from meetings, because someone is currently working on it. Now FESCo action at the moment. (+5,-0,0) (mmaslano, 18:10:53) * #1161 fqdn should be clearly display at login and command prompt (mmaslano, 18:11:07) * AGREED: fqdn should be clearly display on login prompt, but not on commandline prompt (+7,-0,0) (mmaslano, 18:17:19) * #1148 F20 System Wide Change: Application Installer - https://fedoraproject.org/wiki/Changes/AppInstaller (mmaslano, 18:17:27) * AGREED: Packaging team would be happy with properly publicized test day. No other action needed here (+7,-0,0) (mmaslano, 18:23:17) * #1164 F20 Changes - Progress on Changes Freeze (mmaslano, 18:23:27) * #1173 provenpackager request (mmaslano, 18:26:32) * AGREED: vicodan's request for provenpackager was approved (+6,-0,0) (mmaslano, 18:31:26) * #1174 Exception - F20 Self Contained Change: WildFly 8 - https://fedoraproject.org/wiki/Changes/WildFly8 (mmaslano, 18:31:34) * ACTION: mattdm will ping Wildfly people about release notes (mmaslano, 18:33:59) * AGREED: WildFly 8 feature is approved (+6,-0,0) (mmaslano, 18:34:19) * #1170 Working Group call for Volunteers (mmaslano, 18:34:50) * AGREED: let's move on with proposal of Working Groups (+6,-0,0) (mmaslano, 18:41:22) * ACTION: mattdm to send out message as drafted (mattdm, 18:41:49) * AGREED: Once more agreed Working Group proposal should be sent as draft and members have month for joining those groups (+5,-0,0) (mmaslano, 18:58:01) * #1142 F20 System Wide Change: Change Packaging Guidelines to discourage requires into /bin and /sbin - https://fedoraproject.org/wiki/Changes/NoBinDeps (mmaslano, 18:59:49) * AGREED: Packaging Guidelines were already approved by FPC. No FESCo action needed now. (+7,-0,0) (mmaslano, 19:04:19) * Next week's chair (mmaslano, 19:04:38) * ACTION: mmaslano will chair also next meeting (mmaslano, 19:08:55) * Open Floor (mmaslano, 19:09:05) Meeting ended at 19:15:04 UTC. Action Items * mattdm will ping Wildfly people about release notes * mattdm to send out message as drafted * mmaslano will chair also next meeting Action Items, by person --- * mattdm * mattdm will ping Wildfly people about release notes * mattdm to send out message as drafted * mmaslano * mmaslano will chair also next meeting * **UNASSIGNED** * (none) People Present (lines said) --- * mmaslano (90) * mattdm (50) * nirik (28) * abadger1999 (21) * t8m (21) * frankieonuonga (19) * zodbot (16) * pjones (13) * notting (13) * Viking-Ice (11) * sgallagh (0) * mitr (0) 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
[perl-Module-Metadata/f20] (2 commits) ...Update to 1.000018
Summary of changes: c12d050... Update to 1.17 (*) 7e4bd58... Update to 1.18 (*) (*) 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
Re: Proposal: AppData files in all application packages?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 El Wed, 11 Sep 2013 14:35:34 -0400 Matthias Clasen mcla...@redhat.com escribió: On Wed, 2013-09-11 at 12:46 -0500, Dennis Gilmore wrote: Any questions, either grab me on irc 'hughsie' or reply to this email. Be sure to read [1] as a lot of common questions are answered there. I have one question, if the data is shipped in the packages how is it supposed to get to the end user so that they can know about it and choose to install the application? We plan to extract it in the build system and provide it separate from the applications in the repository. that is very vague and handwavy, who is we? how exactly would it be provided to the user? Dennis -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.21 (GNU/Linux) iEYEARECAAYFAlIwxHgACgkQkSxm47BaWfcXewCfYUXfH+XRdR1DibAW2v+SJNot ISoAnA8gXhbv7GAZbvHvQpzF9omPrfLN =x9NK -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: Schedule for Wednesday's FESCo Meeting (2013-09-11)
On Wed, Sep 11, 2013 at 8:07 PM, Jóhann B. Guðmundsson johan...@gmail.com wrote: On 09/11/2013 05:37 PM, drago01 wrote: Lets not discuss the word support again we have had enough threads of that. And yes we have other desktop environments in the project but we do not promote them equally because we don't have the resources to support them on equal terms. You mean Red Hat is not backing up their development through manpower equally and not doing so makes them lesser of products then Gnome and hence we should not give them equal place and footing within our project and our community. No. This has nothing to do with Red Hat but yes manpower (which is not limited to maintainers but also *developers*). And whether are employed by Red Hat (note: I am not) or come from another planet does not matter. In other words we should only proudly display and stand behind applications and application stacks that are backed up by Red Hat from our community. No, see above. Yep that's pretty much how that 3 product default sounds to me, I however do not discriminate between application in our community nor between the people that are maintaining them. And encase you have missed the 21 centry... No I did not. The fact is even after all those years of people crying This year will be the year of the Linux desktop!, we still cant do as basic function as to update the firmware on our computers, we still cant update the firmware of all the peripheral devices like camera, mobile phone,tablets, gps etc. What does firmware update has to do with anything here? The manufacturers of those devices still dont provide application for their devices that run on top of general linux distrubtion and they never will since they are making the application available for Android and IOS What?!. None of those manufactures provide software to update firmware with for iOS nor Android And proposing that we somehow continue to tie ourselves and our processes to *any* of the desktop environments in the GNU/Linux ecosystem while they try to redefine themselves and struggle with their own existence is not doing us as a community any favours nor our users base. Sorry but just because tablets and smart phones outsell PCs does not mean that we should start doing everything on tablets. And no we are not tying our processes to a desktop environment ... that would only apply to the workstation product. We have a server and a could product as well in Matthew's proposal. If anything all your mobile talk suggest that we should have a mobile product as well. And I wouldn't be really against that it fits into the picture. But having 1000 workstations, 1000 servers and 1000 different cloud products makes no sense. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: fedmsg for voting?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 El Tue, 10 Sep 2013 18:32:00 -0400 Matthew Miller mat...@fedoraproject.org escribió: On Tue, Sep 10, 2013 at 05:13:03PM -0500, inode0 wrote: How shallow are Fedora contributors if a badge is what it takes to tip them over from being non-voters to being voters? If doing this increases our turnout from 300 voters to 900 voters the only thing I'll conclude is that we have 600 chuckleheads who voted to get a badge. Well, I might also conclude that the thoughtful voters were outnumbered 2 to 1 by the chuckleheads. It's not the voting-to-get-a-badge that I'm interested in. It's raising the visibility of voting as an important part of Fedora participation. I am actually more likely to not vote because of badges being associated with them. I will admit that over the last few years for various reasons I tended to not vote in elections. especially the release name election because all of the options to me have been silly. I really want us to drop release names. Dennis -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.21 (GNU/Linux) iEYEARECAAYFAlIwyGgACgkQkSxm47BaWfcPcACeMMbqCXngAJl07sGyILB+o5Ip Lu8An2Xb31sgcKCLzHIfDGQ0NCrLOqXB =nMLH -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: Summary/Minutes from today's FESCo Meeting (2013-09-11)
HI On Wed, Sep 11, 2013 at 3:17 PM, Marcela Mašláňová wrote: Can you just paste the content as the body instead of attachments in the future? Attachments are harder to deal with for mobile devices. 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: SSSD 1.11 and AD homeDirectory
On Wed, 2013-09-11 at 14:19 -0500, Jeffrey Ollie wrote: I'm messing around a bit with the new AD support in SSSD 1.11. I've gotten authentication working against our AD at work, but I'd like to be able to mount the user's home folder (in our environment, it gets mapped to the P: drive if you're logging into a Windows system that is part of the domain) as their Linux home directory. The user's home folder can be on one of a dozen or more file servers, so I need to use the AD homeDirectory attribute and dynamically mount the CIFS filesystem. Numerous Google searches and man page readings haven't turned up the magic incantation that I need to turn this on. Is what I want to do possible with SSSD 1.11? If so, is it documented anywhere than the source? Almost certainly you do not want a home directory backed by a cifs filesystem, however if you really do I suggest you configure autofs and cifs with multi-user mounts on your machine. You will not be able to have the home directory be specified by the AD server though unless you want to cleverly use the unixHomeDirectory attribute (and your windows admin properly populates it for each user). 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: SSSD 1.11 and AD homeDirectory
On Wed, Sep 11, 2013 at 3:07 PM, Simo Sorce s...@redhat.com wrote: Almost certainly you do not want a home directory backed by a cifs filesystem, however if you really do I suggest you configure autofs and cifs with multi-user mounts on your machine. It's not a question of want, I'm trying to integrate a Fedora desktop(s) as seamlessly as possible into an existing Active Directory environment, and that means having a user's personal files accessible as seamlessly as possible. The new AD support in SSSD 1.11 means that the AD admins don't need to extend the AD schema and maintain the new attributes. You will not be able to have the home directory be specified by the AD server though unless you want to cleverly use the unixHomeDirectory attribute (and your windows admin properly populates it for each user). The actual attribute in AD is homeDirectory and is populated with UNC paths to the user's home directory. I'll have to dig into autofs to see if it can do what I want. -- Jeff Ollie -- 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: fedmsg for voting?
Ralf Corsepius (rc040...@freenet.de) said: - a record of who voted for what has been kept since this feature was implemented: fedorahosted.org/elections/ticket/30 http://fedorahosted.org/elections/ticket/30 in 2009. All election software that recorded this information has kept the information private. You'd go to jail in Germany, if this SW was used for official elections. The laws prevent a voter-verifiable trail that their vote was recorded and cast for who they intended to cast it for, in case of recounts or similar occurences? I can see requiring it be purged after results are certified, but there are systems that have required this level of verification be available to voters. What certainly might be required is a mechanism to decouple the vote itself from the account, so only the voter knows which record id is theirs, etc. 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: does mc really require perl*?
Miroslav Suchý (msu...@redhat.com) said: On 09/11/2013 01:24 PM, Matěj Cepl wrote: Debian apt* programs have either option to always follow/not-follow these soft-dependencies, or they will just select for installation all packages on which the selected package(s) Depends and then nicely ask user whether she wants to install also suggested/recommended packages. To be precise IIRC: * Depends are always installed * Recommends are selected but you can remove from list before installation * Suggests and Enhances are offered for selections, but not selected by default and user must select it manually The problem with soft dependencies has always been the semantics and the workflow, not the implementation. Even as you describe here with defined semantics, that makes assumptions about the workflow, namely that to make use of them: - the installers are interactive in ways that most of our frontends aren't - that we're designing for the case where the person handling software installation is interested in this level of platform micromanagement (Admittedly, our focus on exposing individual RPMs to the user drives this issue in spades, and in fact drives how our entire ecosystem works, or, in many cases, doesn't work.) 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
Fedora Working Groups: Call for Self-Nominations
Introduction Based on discussions at and around Flock, the Fedora Project Board has approved a proposal for a big change in the way we put Fedora together. Rather than presenting one Fedora with multiple slightly-different install options, future Fedora will be designed, developed, and promoted as three separate products built around a common core. To take that idea from talk to reality, we're making a corresponding change to Fedora leadership. Each product will be guided by a Working Group, which will function as an independent subcommittee of FESCo, (the Fedora Engineering Steering Committee). FESCo will resolve issues which impact multiple working groups, and the Fedora Board will continue to set overall strategic direction, but the working groups will be largely autonomous within their own areas. The Groups -- We are creating a group for each of the three initial products the Board has approved: * Fedora Workstation * Fedora Server * Fedora Cloud The Board asks that the Working Groups determine their own target audience definition and product description as a first task; the names aren't set in stone. We're also creating groups to focus on the common core, and to work on policies and practices for software operating outside of Fedora's traditional packaging model, alongside the existing (and continuing) Fedora Packaging Committee. * Base Design Working Group * Environments Software Stacks Working Group Composition --- The working groups' initial membership will be chosen by FESCo from volunteers. This message is the request for those volunteers to self-nominate. Each group will have at least one FESCo member, who will act as a liaison to FESCo and as a representative of the group at FESCo meetings. We would like each group to also have representation from other major areas of Fedora - Quality Assurance, Infrastructure, Release Engineering, Documentation, Design, Websites, Ambassadors, Feature Wrangler, Marketing. We don't intend for this to be additional work to current members of those teams; working group members should interact with and augment the existing subprojects. What's Expected --- These working groups will be more formal than the existing SIGs, with a documented governing structure and process of operation, voting members, up-to-date and maintained project materials, and regular open communication. All working group members will need to actively participate. The first responsibility will be to establish a governance charter, followed by a product requirements document. We're obviously in the middle of Fedora 20 development, and that's the priority for many of us right now. For that reason, these deliverables won't be required until after the F20 release, but we do want to start organizing as soon as possible. Interlude: Interested in Something Else? Are the projects listed above not your interest? That's fine; you can keep on working the way you are now. Or, perhaps you're interested in a target product, but something different from the ones described above. In that case, you may start a secondary product working group following the same model; if that is successful the Fedora Board may elect to promote that product to a primary target. How to Self-Nominate To volunteer to serve on one of the new Fedora working groups, simply add yourself to the appropriate section in the wiki page below, along with a brief description of your current involvement with Fedora and plans for participation in this group. https://fedoraproject.org/wiki/Fedora.next/WG_Nominations Next Steps -- The nomination period will be at least one month from this announcement. FESCo will review the applications, appoint the initial members, and assist with the development of each group's independent governance. -- Matthew Miller ☁☁☁ Fedora Cloud Architect ☁☁☁ mat...@fedoraproject.org ___ 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
Fedora ARM weekly Status Meeting Minutes 2013-09-11
Thanks to those that were able to join us for the status meeting today, for those unable the minutes are posted below: Minutes: http://meetbot.fedoraproject.org/fedora-meeting-1/2013-09-11/fedora-meeting-1.2013-09-11-20.00.html Minutes (text): http://meetbot.fedoraproject.org/fedora-meeting-1/2013-09-11/fedora-meeting-1.2013-09-11-20.00.txt Log: http://meetbot.fedoraproject.org/fedora-meeting-1/2013-09-11/fedora-meeting-1.2013-09-11-20.00.log.html === #fedora-meeting-1: Fedora ARM weekly status meeting === Meeting summary --- * 1) Kernel Status Update (pwhalen, 20:02:49) * kernel-3.11.0-300.fc20 - trimslice PCIe fixed, regression on vexpress (pwhalen, 20:06:39) * 2a) Aarch64 - Status Update (pwhalen, 20:13:02) * 2b) Aarch64 - Koji (pwhalen, 20:16:49) * Nirik making progress on aarch64 koji server setup. May be ready for testing this week, barring distractions (bconoboy, 21:04:33) * 3) Fedora 20 Alpha RC1 (pwhalen, 20:22:50) * LINK: https://dl.fedoraproject.org/pub/alt/stage/20-Alpha-RC1/Images/armhfp/ (pwhalen, 20:22:50) * RC1 images have been posted, please help test, add findings to the wiki, file bugs (pwhalen, 20:23:37) * Please test RC1 if you have a supported device (bconoboy, 20:24:45) * 4) Weekly Status Meeting (pwhalen, 20:27:38) * AGREED: Fedora ARM Weekly status meeting moving to a biweekly schedule, to be re-evaluated as needed. (pwhalen, 20:39:32) * next Fedora ARM meeting - 2013-09-25 (pwhalen, 20:40:16) * 5) Open Floor (pwhalen, 20:40:46) * ldconfig will be showing warnings in f20 due to binutils bug, bz to be filed and glibc dev consulted (bconoboy, 20:49:29) * AGREED: ARM Kernel patch submitters are asked to send the patches they apply to the mailing list prior to checkin, including their tested status. (bconoboy, 21:02:48) Meeting ended at 21:07:16 UTC. Action Items, by person --- * **UNASSIGNED** * (none) People Present (lines said) --- * bconoboy (55) * jwb (54) * pwhalen (49) * kylem (48) * dgilmore (29) * hrw (20) * masta (12) * nirik (9) * jcapik (8) * zodbot (8) * dmarlin (7) * ahs3 (3) * dmarlin_away (1) * msalter (0) * pbrobinson (0) * ctyler (0) * agreene (0) * handsome_pirate (0) * jonmasters (0) * ddd (0) 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
