Re: F19 DVD over size - what to drop?

[Luya Tshimbalanga]

On 02/05/13 05:46 AM, Bruno Wolff III wrote:

On Wed, May 01, 2013 at 20:26:13 -0400,
  Sam Varshavchik  wrote:

Bill Nottingham writes:

Anyway, here are my suggestions:

valgrind
eclipse
gimp
kdegames


I don't think gimp is that great of a choice to drop. That's a tool 
that I think some of the less technical of our users might want to use 
and making it easy for them to install it is a good thing.


+1.  As Design Suite maintainer I failed to see why Gimp is listed for 
removal,  its size is not that big.


Luya

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

Adding new group to comps-f19.xml.in

[Ravindra Kumar]

Hi Bill and others, 

Based on the earlier discussions in the emails, I have following diff for 
comps-f19.xml.in: 

--- comps-f19.xml.in 2013-04-29 17:41:10.003026000 -0700 
+++ comps-f19.xml.in.new 2013-05-08 20:35:57.000112000 -0700 
@@ -7,6 +7,9 @@ 
<_description>Local X.org display server 
false 
false 
+  
+ virt-agents-x 
+  
 
xorg-x11-drv-ati 
xorg-x11-drv-evdev 
@@ -1150,6 +1153,9 @@ 
<_description>Common set of utilities that extend the minimal 
installation. 
false 
false 
+  
+ virt-agents 
+  
 
acl 
at 
@@ -5633,6 +5639,26 @@ 
 
 
 
+ virt-agents 
+ <_name>Virtualization Agents 
+ <_description>These packages enable better management of virtual 
machine. 
+ true 
+ true 
+  
+ open-vm-tools 
+  
+  
+  
+ virt-agents-x 
+ <_name>Virtualization Agents 
+ <_description>These packages enable better user experience for virtual 
machine. 
+ true 
+ true 
+  
+ open-vm-tools-desktop 
+  
+  
+  
virtualization 
<_name>Virtualization 
<_description>These packages provide a virtualization 
environment. 

Could you please confirm if this is what you are expecting and how to test it? 
Wiki page 
http://fedoraproject.org/wiki/How_to_use_and_edit_comps.xml_for_package_groups 
says nothing about testing apart from running 'xsltproc'. I ran 'xsltproc' and 
it does not 
say anything about a 'group' containing a 'grouplist', so I'm not sure if this 
will work 
or not. 

Thanks, 
Ravindra 
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Packaging directory in /mnt - how to do so?

[Tomasz Torcz]

On Wed, May 08, 2013 at 12:24:43PM +0200, Lennart Poettering wrote:
> > > >   owfs is suite of program for accessing 1-wire network, which is
> > > >simple hardware protocol.  One of the program is FUSE module,
> > > >giving the access to network and devices on it through filesystem.
> > > >The "/mnt/1wire" directory is widely used default - it's in the
> > > >default config files and many scripts over the net uses it. I'd really
> > > >like to retain this similarity eith other distributions in Fedora.
> > > >
> >   What would be proper path for such kind of filesystem?
> 
> /run/owfs/1wire or so sounds like a good idea.

  Why not jus /run/owfs or /run/1wire?  Is there a reason for longer path?

-- 
Tomasz TorczThere exists no separation between gods and men:
xmpp: zdzich...@chrome.pl   one blends softly casual into the other.

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

Re: Do you think this is a security risk and if not is it a bad UI decision?

[Adam Williamson]

On Thu, 2013-05-09 at 00:44 -0400, Felix Miata wrote:
> On 2013-05-09 00:02 (GMT-0400) Adam Williamson composed:
> 
> > On Wed, 2013-05-08 at 22:36 -0400, Felix Miata wrote:
> 
> >> On 2013-05-08 10:09 (GMT+0200) Pierre-Yves Chibon composed:
> 
> >> > you are replying to a 4 days old email on a thread that is no
> >> > longer active?
> 
> >> A: The thread was started on a Friday night.
> 
> >> B: Some people don't get to read mail every day, or more than a few or less
> >> times a week.
> 
> >> A + B = perfectly justified timing of reply.
> 
> > C: the debate was taken to every place it could possibly go, and the
> > commit was reverted.
> 
> > So what's the point of reviving it? Sometimes, if you don't get your
> > $0.02 posted in time, it's best to just sit on it.
> 
> So everyone who cannot maintain currency has to catch up 100% prior to 
> writing a response coming to mind while reading, lest he be publicly 
> chastised by temporal relevance police? Likely "revival" was not the primary 
> objective of the late writer. The late arrival would much better have been 
> left ignored than have the already too long thread be further extended by OT 
> police commentary.

If I get behind on reading devel@, what I do is read through the
backlog, writing replies as I read, but *don't send any of them*. I just
leave them open. If it turns out someone else already said what I wanted
to say already, or the thread diverged into something else, or it became
toxic and then died, or whatever, I just trash the message.
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora
http://www.happyassassin.net

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

Re: Do you think this is a security risk and if not is it a bad UI decision?

[Felix Miata]

On 2013-05-09 00:02 (GMT-0400) Adam Williamson composed:


On Wed, 2013-05-08 at 22:36 -0400, Felix Miata wrote:



On 2013-05-08 10:09 (GMT+0200) Pierre-Yves Chibon composed:



> you are replying to a 4 days old email on a thread that is no
> longer active?



A: The thread was started on a Friday night.



B: Some people don't get to read mail every day, or more than a few or less
times a week.



A + B = perfectly justified timing of reply.



C: the debate was taken to every place it could possibly go, and the
commit was reverted.



So what's the point of reviving it? Sometimes, if you don't get your
$0.02 posted in time, it's best to just sit on it.


So everyone who cannot maintain currency has to catch up 100% prior to 
writing a response coming to mind while reading, lest he be publicly 
chastised by temporal relevance police? Likely "revival" was not the primary 
objective of the late writer. The late arrival would much better have been 
left ignored than have the already too long thread be further extended by OT 
police commentary.

--
"The wise are known for their understanding, and pleasant
words are persuasive." Proverbs 16:21 (New Living Translation)

 Team OS/2 ** Reg. Linux User #211409 ** a11y rocks!

Felix Miata  ***  http://fm.no-ip.com/
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Build control-center in mock fail

[Igor Gnatenko]

Huh! Today this problem not present..
--
Best Regards,
Igor Gnatenko
09.05.2013 8:12 пользователь "Rahul Sundaram"  написал:

> Hi
>
>
> On Thu, May 9, 2013 at 12:04 AM, Adam Williamson wrote:
>
>>
>>
>> Yes, I know that, thanks. I didn't ask for a lecture, but whether this
>> was actually written down in the guidelines somewhere.
>>
>
> It is not written down as policy and since the tools themselves enforce
> this, I don't think it has been needed
>
> Rahul
>
> --
> devel mailing list
> devel@lists.fedoraproject.org
> https://admin.fedoraproject.org/mailman/listinfo/devel
>
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Build control-center in mock fail

[Rahul Sundaram]

Hi


On Thu, May 9, 2013 at 12:04 AM, Adam Williamson wrote:

>
>
> Yes, I know that, thanks. I didn't ask for a lecture, but whether this
> was actually written down in the guidelines somewhere.
>

It is not written down as policy and since the tools themselves enforce
this, I don't think it has been needed

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

Re: Build control-center in mock fail

[Adam Williamson]

On Wed, 2013-05-08 at 22:59 -0400, Nico Kadel-Garcia wrote:
> On Wed, May 8, 2013 at 1:02 PM, Adam Williamson  wrote:
> > On 08/05/13 08:13 AM, Igor Gnatenko wrote:
> >>
> >> Thx. But why in oficially packages doesn't  fixed?
> >
> >
> > Does anyone know if it's actually the case that the guidelines require
> > packages be buildable without internet access? I just had a quick search on
> > obvious terms through https://fedoraproject.org/wiki/Packaging:Guidelines ,
> > and couldn't find anything.
> 
> There are huge security issues with downloading source at build time:
> someone who can manipulate your DNS or your proxies can get you
> downloading, building, and installing some arbitrarily contaminated
> source code. Also, repositories tend to evaporate or fail to publish
> specific releases in specific locations. so the module you download
> today may have nothing to do with the module of the same name that I
> download tomorrow.

Yes, I know that, thanks. I didn't ask for a lecture, but whether this
was actually written down in the guidelines somewhere.
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora
http://www.happyassassin.net

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

Re: Do you think this is a security risk and if not is it a bad UI decision?

[Adam Williamson]

On Wed, 2013-05-08 at 22:36 -0400, Felix Miata wrote:
> On 2013-05-08 10:09 (GMT+0200) Pierre-Yves Chibon composed:
> 
> > you are replying to a 4 days old email on a thread that is no
> > longer active?
> 
> A: The thread was started on a Friday night.
> 
> B: Some people don't get to read mail every day, or more than a few or less 
> times a week.
> 
> A + B = perfectly justified timing of reply.

C: the debate was taken to every place it could possibly go, and the
commit was reverted.

So what's the point of reviving it? Sometimes, if you don't get your
$0.02 posted in time, it's best to just sit on it.
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora
http://www.happyassassin.net

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

Re: Build control-center in mock fail

[David]

On 5/8/2013 10:59 PM, Nico Kadel-Garcia wrote:
> On Wed, May 8, 2013 at 1:02 PM, Adam Williamson  wrote:
>> On 08/05/13 08:13 AM, Igor Gnatenko wrote:
>>>
>>> Thx. But why in oficially packages doesn't  fixed?
>>
>>
>> Does anyone know if it's actually the case that the guidelines require
>> packages be buildable without internet access? I just had a quick search on
>> obvious terms through https://fedoraproject.org/wiki/Packaging:Guidelines ,
>> and couldn't find anything.
> 
> There are huge security issues with downloading source at build time:
> someone who can manipulate your DNS or your proxies can get you
> downloading, building, and installing some arbitrarily contaminated
> source code. Also, repositories tend to evaporate or fail to publish
> specific releases in specific locations. so the module you download
> today may have nothing to do with the module of the same name that I
> download tomorrow.
> 
> This is one of the absolute banes of all the "grab and build it when
> you need it and only when you need it" approaches, such as CPAN,
> rubygems, and maven.
> 


You forgot to mention the evil monkey that lives in your closet or the
monster that lives under your bed or the things that go bump in the
night.   :-)

-- 

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

Re: Build control-center in mock fail

[Nico Kadel-Garcia]

On Wed, May 8, 2013 at 1:02 PM, Adam Williamson  wrote:
> On 08/05/13 08:13 AM, Igor Gnatenko wrote:
>>
>> Thx. But why in oficially packages doesn't  fixed?
>
>
> Does anyone know if it's actually the case that the guidelines require
> packages be buildable without internet access? I just had a quick search on
> obvious terms through https://fedoraproject.org/wiki/Packaging:Guidelines ,
> and couldn't find anything.

There are huge security issues with downloading source at build time:
someone who can manipulate your DNS or your proxies can get you
downloading, building, and installing some arbitrarily contaminated
source code. Also, repositories tend to evaporate or fail to publish
specific releases in specific locations. so the module you download
today may have nothing to do with the module of the same name that I
download tomorrow.

This is one of the absolute banes of all the "grab and build it when
you need it and only when you need it" approaches, such as CPAN,
rubygems, and maven.
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Build control-center in mock fail

[Mathieu Bridon]

On Wed, 2013-05-08 at 19:25 +0200, Michael Scherer wrote:
> Le mercredi 08 mai 2013 à 10:02 -0700, Adam Williamson a écrit :
> > On 08/05/13 08:13 AM, Igor Gnatenko wrote:
> > > Thx. But why in oficially packages doesn't  fixed?
> > 
> > Does anyone know if it's actually the case that the guidelines require 
> > packages be buildable without internet access? I just had a quick search 
> > on obvious terms through 
> > https://fedoraproject.org/wiki/Packaging:Guidelines , and couldn't find 
> > anything.
> 
> It may not be explicitly written, but we want to have reproductible
> builds, which also mean a build that do not depend on external entity
> such as a networked server.

And the Koji builders don't have access to the Internet, to catch this
kind of problems.


-- 
Mathieu

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

Re: Do you think this is a security risk and if not is it a bad UI decision?

[Ankur Sinha]

On Wed, 2013-05-08 at 19:59 -0600, Pete Zaitcev wrote:
> FOUR DAYS is "no longer active" for you? Seriously?
> You want to STFU those who disagree _this hard_?

Pete, 

There is no constructive discussion going on here any more. 4 days is
certainly enough time for a mailing list thread to go inactive. Please
mind your language. You are not being excellent towards the rest of the
community. Use of such language in the future will get you moderated.
We'd really like to avoid that scenario. It's easy enough: please
re-read your mail before you send it to ensure it's polite, irrespective
of the situation.

I insist that you please stop posting to this thread.
-- 
Thanks, 
Warm regards,
Ankur: "FranciscoD"

Please only print if necessary. 

Looking to contribute to Fedora? Look here: 
https://fedoraproject.org/wiki/Fedora_Join_SIG

http://fedoraproject.org/wiki/User:Ankursinha
http://ankursinha.in/blog



signature.asc
Description: This is a digitally signed message part
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Do you think this is a security risk and if not is it a bad UI decision?

[Felix Miata]

On 2013-05-08 10:09 (GMT+0200) Pierre-Yves Chibon composed:


you are replying to a 4 days old email on a thread that is no
longer active?


A: The thread was started on a Friday night.

B: Some people don't get to read mail every day, or more than a few or less 
times a week.


A + B = perfectly justified timing of reply.
--
"The wise are known for their understanding, and pleasant
words are persuasive." Proverbs 16:21 (New Living Translation)

 Team OS/2 ** Reg. Linux User #211409 ** a11y rocks!

Felix Miata  ***  http://fm.no-ip.com/
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Do you think this is a security risk and if not is it a bad UI decision?

[Pete Zaitcev]

On Wed, 08 May 2013 10:09:13 +0200
Pierre-Yves Chibon  wrote:

> On Wed, 2013-05-08 at 10:10 +0200, Olav Vitters wrote:
> > On Fri, May 03, 2013 at 09:03:02PM -0700, Dan Mashal wrote:

> > > Let's be realistic here. The precedence they have recently set is they
> > > make decisions and if you don't like it "too bad".
> > 
> > Even if that is true, what is your point?
> 
> That you are replying to a 4 days old email on a thread that is no
> longer active?

FOUR DAYS is "no longer active" for you? Seriously?
You want to STFU those who disagree _this hard_?

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

Re: F-19 Branched report: 20130508 changes

[Emmanuel Seyman]

* Dan Mashal [08/05/2013 11:47] :
>
> Who obsoleted gnome-panel? It is required by a ton of packages.

"gnome-panel and gnome-applets just got blocked [1] in koji. We still
 have a number of packages depending on gnome-panel, either through
 library deps or through Requires: gnome-panel, and all of these are
 going to show up as broken deps with the next rawhide and F19 composes."

http://lists.fedoraproject.org/pipermail/devel/2013-May/182015.html

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

Old review ticket triage

[Jason L Tibbitts III]

I spent a bit of time recently trying to clean up the oldest package
review tickets, making sure links are accessible and the submitted
packages actually build.  At this point I think all of the tickets in
http://fedoraproject.org/PackageReviewStatus/NEW.html older than May
2012 should actually be reviewable.  Of course, I make no determination
as to whether the submitted packages are in any state to actually make
it into the distribution.

So, please, if you can review, do have a look, and if you're a sponsor,
try and help out one of the poor people who have been waiting up to two
years to become a contributor.

Next steps for me are to work forward six months, so everything older
than October is cleaned up and reviewable.  And, of course, to actually
find the time to review some tickets.

 - J<
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: F-19 Branched report: 20130508 changes

[Rahul Sundaram]

Hi


On Wed, May 8, 2013 at 6:46 PM, Dan Mashal wrote:

>
>
> The new version of cinnamon does not depend on it. Fighting with it to
> get to compile. Thanks for your reply. There were some other packages
> though that seemed affected.. (i.e. openbox) and some gnome packages
> too.
>

Openbox has some optional support.  It can be disabled.  The only package
which has a hard dependency on the panel is a applet package and that has
been retired now.

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

Re: F-19 Branched report: 20130508 changes

[Dan Mashal]

On Wed, May 8, 2013 at 3:26 PM, Matthias Clasen  wrote:
> We did, because GNOME no longer uses gnome-panel. All those packages
> that require gnome-panel are applets, which are just as useless without
> gnome-panel. If you want to keep gnome-panel alive for some reason
> (although you already have a fork of it), feel free to pick it up.

The new version of cinnamon does not depend on it. Fighting with it to
get to compile. Thanks for your reply. There were some other packages
though that seemed affected.. (i.e. openbox) and some gnome packages
too.

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

Re: F-19 Branched report: 20130508 changes

[Matthias Clasen]

On Wed, 2013-05-08 at 11:47 -0700, Dan Mashal wrote:

> Umm hi,
> 
> Who obsoleted gnome-panel? It is required by a ton of packages.
> 

We did, because GNOME no longer uses gnome-panel. All those packages
that require gnome-panel are applets, which are just as useless without
gnome-panel. If you want to keep gnome-panel alive for some reason
(although you already have a fork of it), feel free to pick it up.

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

Re: F-19 Branched report: 20130508 changes

[Dan Mashal]

On Wed, May 8, 2013 at 1:22 PM, Tom Callaway  wrote:
> It appears to be needed by only:
> byzanz - optional panel applet, update building right now.
> cinnamon-menu-editor - Not sure why this depends on gnome-panel.
> gnome-applet-sensors - probably should be blocked.
> openbox - Should disable gdm-control and gnome-panel-control (I doubt
> they've worked in a long time)
> workrave - only for the panel applet, fixed update in testing -
> https://admin.fedoraproject.org/updates/FEDORA-2013-7447/workrave-1.10-3.fc19
>
> GNOME Classic mode doesn't use it (and GNOME Shell only ever used it for
> the fallback mode, which is no longer in 3.8)

Thanks. Working on cinnamon.

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

Re: F-19 Branched report: 20130508 changes

[Adam Williamson]

On Wed, 2013-05-08 at 16:22 -0400, Tom Callaway wrote:
> On 05/08/2013 02:47 PM, Dan Mashal wrote:
> > Who obsoleted gnome-panel? It is required by a ton of packages.
> 
> It appears to be needed by only:
> byzanz - optional panel applet, update building right now.
> cinnamon-menu-editor - Not sure why this depends on gnome-panel.

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

Dan just went ahead and ripped the dep out and rebuilt it, though. So, I
guess Cinnamon folks get to complain if that breaks again.

-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora
http://www.happyassassin.net

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

Fedora ARM Weekly Status Meeting Minutes 2013-05-08

[Paul Whalen]

Thanks to those that were able to join for the status meeting today, for those 
unable the minutes
are posted below:


Minutes: 
http://meetbot.fedoraproject.org/fedora-meeting-1/2013-05-08/fedora-meeting-1.2013-05-08-20.00.html
Minutes (text): 
http://meetbot.fedoraproject.org/fedora-meeting-1/2013-05-08/fedora-meeting-1.2013-05-08-20.00.txt
Log: 
http://meetbot.fedoraproject.org/fedora-meeting-1/2013-05-08/fedora-meeting-1.2013-05-08-20.00.log.html


===
#fedora-meeting-1: Fedora ARM weekly status meeting
===


Meeting started by pwhalen at 20:00:03 UTC. The full logs are available
at
http://meetbot.fedoraproject.org/fedora-meeting-1/2013-05-08/fedora-meeting-1.2013-05-08-20.00.log.html
.



Meeting summary
---
* 0) Status of ACTION items from our previous meeting  (pwhalen,
  20:02:12)
  * COMPLETE - bconoboy will be automating the generation of a
failed-build script (Where %build failed)  (pwhalen, 20:02:21)
  * INPROGRESS - pwhalen/dmarlin will curate the fedora wiki to reflect
new build failures  (pwhalen, 20:02:30)
  * INPROGRESS - dgilmore to create appliance-creator based image
(pwhalen, 20:02:43)
  * LINK:

http://meetbot.fedoraproject.org/fedora-meeting-1/2013-05-01/fedora-meeting-1.2013-05-01-20.00.html
(pwhalen, 20:03:05)

* 1) Problem packages  (pwhalen, 20:12:16)

* 2) Kernel Status update  (pwhalen, 20:14:11)
  * ACTION: jonmasters to probe highbank 3.9 instability issue and send
update  (bconoboy, 20:19:40)
  * ACTION: jonmasters to help review 3.10 test kernels, and assist
pwhalen with vexpress  (jonmasters, 20:20:33)

* 3) Flock (formerly FUDcon)  (pwhalen, 20:22:41)
  * LINK: http://fedoraproject.org/wiki/Flock   (pwhalen, 20:23:24)

* 4) Fedora 19 ARM Alpha - creating images  (pwhalen, 20:26:51)
  * ACTION: dgilmore to post TC Images to list later today/tomorrow
(pwhalen, 20:33:39)
  * ACTION: pwhalen to update wiki with pointers/instructions  (pwhalen,
20:33:53)

* 5) Open Floor  (pwhalen, 20:34:22)

Meeting ended at 20:43:08 UTC.




Action Items

* jonmasters to probe highbank 3.9 instability issue and send update
* jonmasters to help review 3.10 test kernels, and assist pwhalen with
  vexpress
* dgilmore to post TC Images to list later today/tomorrow
* pwhalen to update wiki with pointers/instructions




Action Items, by person
---
* dgilmore
  * dgilmore to post TC Images to list later today/tomorrow
* jonmasters
  * jonmasters to probe highbank 3.9 instability issue and send update
  * jonmasters to help review 3.10 test kernels, and assist pwhalen with
vexpress
* pwhalen
  * jonmasters to help review 3.10 test kernels, and assist pwhalen with
vexpress
  * pwhalen to update wiki with pointers/instructions
* **UNASSIGNED**
  * (none)




People Present (lines said)
---
* pbrobinson (77)
* dgilmore (48)
* pwhalen (37)
* bconoboy (26)
* jonmasters (18)
* j_dulaney (16)
* masta (11)
* zodbot (8)
* dmarlin (5)
* ahs3 (1)
* ctyler (0)
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Adding open-vm-tools to core group

[Ravindra Kumar]

> *but* please undersatdn with your argumentation a lot of maintainers
> could claim that their packages are in CORE for several reasons
> because they are expected to be used from most users

> please leave core be what core means

> and as i clearly statet that i have open-vm-tools on nearly any
> of my setups please respect that i try to speak for other users
> which are not using VMware

I got your point. I will follow the approach of creating a new
group as suggested by Bill.

Thanks,
Ravindra
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: F-19 Branched report: 20130508 changes

[Tom Callaway]

On 05/08/2013 02:47 PM, Dan Mashal wrote:
> Who obsoleted gnome-panel? It is required by a ton of packages.

It appears to be needed by only:
byzanz - optional panel applet, update building right now.
cinnamon-menu-editor - Not sure why this depends on gnome-panel.
gnome-applet-sensors - probably should be blocked.
openbox - Should disable gdm-control and gnome-panel-control (I doubt
they've worked in a long time)
workrave - only for the panel applet, fixed update in testing -
https://admin.fedoraproject.org/updates/FEDORA-2013-7447/workrave-1.10-3.fc19

GNOME Classic mode doesn't use it (and GNOME Shell only ever used it for
the fallback mode, which is no longer in 3.8)

~tom

==
Fedora Project
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: F-19 Branched report: 20130508 changes

[Peter Robinson]

> > Compose finished at Wed May  8 12:20:02 UTC 2013

First please trim unneeded stuff from a reply.

> Umm hi,
>
> Who obsoleted gnome-panel? It is required by a ton of packages.

It was announced to the list as to why, it's dead upstream and doesn't
build with the current gnome and is in fact broken and uninstallable.
People should either rebuild the dependent packages without the support or
they should be retired.

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

Self Introduction & review/sponsor request

[Björn Esser]

Dear Fedora Community,

since I want to contribute to Fedora to make better and to become a
member of the packager-group, I'm going to introduce myself here a bit.

I am Björn Esser and I live in Hildesheim, Germany. That's about 30 km
(20 mi) south of Hannover. I'm just an ordinary guy using Linux about
seven years. Since then I used Ubuntu, openSuse, Debian and now Fedora
(since F17). My FAS-name ist besser82.

When I was using openSuse, I found a nifty piece of software called
'libyui' which is a GUI-abstaction library. That opens the possibilty
to write applications using ncurses, gtk and qt without demanding to
use a specific one of them and just needing one piece of code. It also
feature bindings to perl, python and ruby. And so I want to bring it
into Fedora.

I am in very good, continuos contact to upstream and have membership in
openSuse's libyui [1] and YaST [2] organisations on github. Thanks to
this I'm able to deal with possible bugs in short-time.

I've prepared rpms forlibyui and it's UI-plugins for review. [3-7]
The rpms for the bindings are WIP.

I am quite new to writing rpm-specs and packaging for Fedora so the
packages might not be perfect. I did my best to obey the
packaging-guidelines from the wiki and I am willing to learn.

I hope to find someone here who'd like to sponsor me and my packages.

Best Regards,
  Björn Esser

[1] https://github.com/libyui?tab=members
[2] https://github.com/yast?tab=members
[3] https://bugzilla.redhat.com/show_bug.cgi?id=959926
[4] https://bugzilla.redhat.com/show_bug.cgi?id=960198
[5] https://bugzilla.redhat.com/show_bug.cgi?id=960199
[6] https://bugzilla.redhat.com/show_bug.cgi?id=960201
[7] https://bugzilla.redhat.com/show_bug.cgi?id=960201

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

Summary/Minutes from today's FESCo Meeting (YYYY-MM-DD)

[Josh Boyer]

===
#fedora-meeting: FESCO (2013-05-08)
===


Meeting started by jwb at 18:06:59 UTC. The full logs are available at
http://meetbot.fedoraproject.org/fedora-meeting/2013-05-08/fesco.2013-05-08-18.06.log.html
.



Meeting summary
---
* init process  (jwb, 18:07:13)

* #1110 systemd preset for ipmi  (jwb, 18:08:20)
  * AGREED: FESCo does not believe a package-private solution to this is
the correct method.  We suggest you file a bug against systemd to
get it added to the default preset file and rework the service to do
detection of hardware to do the addional module loading and watchdog
starting at boot time  (jwb, 18:14:44)

* # systemd preset for ipmievd  (jwb, 18:15:02)
  * AGREED: FESCo does not believe a package-private solution to this
is the correct method.  We suggest you file a bug against systemd
to get it added to the default preset file  (jwb, 18:16:17)

* #1109 change provenpackager join message?  (jwb, 18:18:32)
  * AGREED: New provenpackager join message will read: "Please use your
new privileges wisely."  (jwb, 18:20:31)

* Next week's chair  (jwb, 18:21:00)
  * notting will chair next week's meeting  (jwb, 18:22:22)

* Open Floor  (jwb, 18:22:28)
  * FESCo election nomination period is May 18 - May 25.  5 seats are up
for election.  The seats up for election are currently occupied by
nirik, notting, pjones, jwb, and t8m  (jwb, 18:25:21)
  * LINK: https://apps.fedoraproject.org/calendar/   (nirik, 18:28:14)
  * Fedora now has a calendar app, Fedocal.  Take a look and use it!
(jwb, 18:28:49)
  * LINK: https://apps.fedoraproject.org/calendar/   (jwb, 18:29:07)
  * Considering doing some Flock presentation/hackfest proposals  (jwb,
18:44:06)
  * ACTION: sgallagh to file two flock proposals: "Meet Your FESCo" and
"Change Process Tutorial"  (jwb, 18:48:56)

Meeting ended at 18:54:07 UTC.




Action Items

* sgallagh to file two flock proposals: "Meet Your FESCo" and "Change
  Process Tutorial"




Action Items, by person
---
* sgallagh
  * sgallagh to file two flock proposals: "Meet Your FESCo" and "Change
Process Tutorial"
* **UNASSIGNED**
  * (none)




People Present (lines said)
---
* jwb (70)
* sgallagh (25)
* nirik (24)
* pjones (22)
* notting (18)
* abadger1999 (15)
* t8m (14)
* zodbot (9)
* Viking-Ice (3)
* mmaslano (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

Re: F-19 Branched report: 20130508 changes

[Dan Mashal]

On Wed, May 8, 2013 at 5:25 AM, Fedora Branched Report
 wrote:
> Compose started at Wed May  8 09:15:02 UTC 2013
>
> Broken deps for x86_64
> --
> [byzanz]
> byzanz-0.3-0.5.fc17.x86_64 requires libpanel-applet-4.so.0()(64bit)
> [cinnamon]
> cinnamon-menu-editor-1.6.7-7.fc19.noarch requires gnome-panel
> [deltacloud-core]
> deltacloud-core-1.0.5-2.fc19.noarch requires ruby(abi) = 0:1.9.1
> [dragonegg]
> dragonegg-3.1-19.fc19.x86_64 requires gcc = 0:4.7.2-9.fc19
> [fcitx-libpinyin]
> fcitx-libpinyin-0.2.90-1.fc19.x86_64 requires 
> libpinyin.so.3(LIBPINYIN)(64bit)
> fcitx-libpinyin-0.2.90-1.fc19.x86_64 requires libpinyin.so.3()(64bit)
> [freeipa]
> freeipa-server-strict-3.2.0-0.3.beta1.fc19.x86_64 requires pki-ca = 
> 0:10.0.1
> freeipa-server-strict-3.2.0-0.3.beta1.fc19.x86_64 requires 
> krb5-server = 0:1.11.2-1
> [ghc-data-memocombinators]
> ghc-data-memocombinators-0.4.4-3.fc19.x86_64 requires 
> libHSdata-inttrie-0.0.8-ghc7.4.2.so()(64bit)
> ghc-data-memocombinators-0.4.4-3.fc19.x86_64 requires 
> ghc(data-inttrie-0.0.8-1cc0f43b566911f823287ed46100a81e)
> ghc-data-memocombinators-devel-0.4.4-3.fc19.x86_64 requires 
> ghc-devel(data-inttrie-0.0.8-1cc0f43b566911f823287ed46100a81e)
> [ghc-show]
> ghc-show-0.4.1.2-4.fc19.x86_64 requires 
> libHSsmallcheck-0.6.1-ghc7.4.2.so()(64bit)
> ghc-show-0.4.1.2-4.fc19.x86_64 requires 
> ghc(smallcheck-0.6.1-909159f2996454c279da80ced02cfe48)
> ghc-show-devel-0.4.1.2-4.fc19.x86_64 requires 
> ghc-devel(smallcheck-0.6.1-909159f2996454c279da80ced02cfe48)
> [gnome-applet-sensors]
> gnome-applet-sensors-3.0.0-4.fc18.i686 requires libpanel-applet-4.so.0
> gnome-applet-sensors-3.0.0-4.fc18.x86_64 requires 
> libpanel-applet-4.so.0()(64bit)
> [gooddata-cl]
> gooddata-cl-1.2.56-2.fc19.noarch requires gdata-java
> [kawa]
> 1:kawa-1.11-5.fc19.x86_64 requires servlet25
> [kdevelop-custom-buildsystem]
> kdevelop-custom-buildsystem-1.2.2-2.fc19.x86_64 requires 
> libkdevplatformutil.so.6()(64bit)
> kdevelop-custom-buildsystem-1.2.2-2.fc19.x86_64 requires 
> libkdevplatformproject.so.6()(64bit)
> kdevelop-custom-buildsystem-1.2.2-2.fc19.x86_64 requires 
> libkdevplatformoutputview.so.6()(64bit)
> kdevelop-custom-buildsystem-1.2.2-2.fc19.x86_64 requires 
> libkdevplatformlanguage.so.6()(64bit)
> kdevelop-custom-buildsystem-1.2.2-2.fc19.x86_64 requires 
> libkdevplatforminterfaces.so.6()(64bit)
> [libkolab]
> php-kolab-0.4.1-3.fc19.x86_64 requires php(zend-abi) = 
> 0:20100525-x86-64
> php-kolab-0.4.1-3.fc19.x86_64 requires php(api) = 0:20100412-x86-64
> [libvirt-qmf]
> libvirt-qmf-0.3.0-6.fc19.x86_64 requires 
> libmcommon_qmf.so.1.0.0()(64bit)
> libvirt-qmf-0.3.0-6.fc19.x86_64 requires libmcommon.so.1.0.0()(64bit)
> [matreshka]
> matreshka-0.3.0-3.fc19.i686 requires libgnat-4.7.so
> matreshka-0.3.0-3.fc19.x86_64 requires libgnat-4.7.so()(64bit)
> matreshka-amf-0.3.0-3.fc19.i686 requires libgnat-4.7.so
> matreshka-amf-0.3.0-3.fc19.x86_64 requires libgnat-4.7.so()(64bit)
> matreshka-amf-mofext-0.3.0-3.fc19.i686 requires libgnat-4.7.so
> matreshka-amf-mofext-0.3.0-3.fc19.x86_64 requires 
> libgnat-4.7.so()(64bit)
> matreshka-amf-ocl-0.3.0-3.fc19.i686 requires libgnat-4.7.so
> matreshka-amf-ocl-0.3.0-3.fc19.x86_64 requires libgnat-4.7.so()(64bit)
> matreshka-amf-uml-0.3.0-3.fc19.i686 requires libgnat-4.7.so
> matreshka-amf-uml-0.3.0-3.fc19.x86_64 requires libgnat-4.7.so()(64bit)
> matreshka-amf-utp-0.3.0-3.fc19.i686 requires libgnat-4.7.so
> matreshka-amf-utp-0.3.0-3.fc19.x86_64 requires libgnat-4.7.so()(64bit)
> matreshka-fastcgi-0.3.0-3.fc19.i686 requires libgnat-4.7.so
> matreshka-fastcgi-0.3.0-3.fc19.i686 requires libgnarl-4.7.so
> matreshka-fastcgi-0.3.0-3.fc19.x86_64 requires libgnat-4.7.so()(64bit)
> matreshka-fastcgi-0.3.0-3.fc19.x86_64 requires 
> libgnarl-4.7.so()(64bit)
> matreshka-sql-core-0.3.0-3.fc19.i686 requires libgnat-4.7.so
> matreshka-sql-core-0.3.0-3.fc19.x86_64 requires 
> libgnat-4.7.so()(64bit)
> matreshka-sql-postgresql-0.3.0-3.fc19.i686 requires libgnat-4.7.so
> matreshka-sql-postgresql-0.3.0-3.fc19.x86_64 requires 
> libgnat-4.7.so()(64bit)
> matreshka-sql-sqlite-0.3.0-3.fc19.i686 requires libgnat-4.7.so
> matreshka-sql-sqlite-0.3.0-3.fc19.x86_64 requires 
> libgnat-4.7.so()(64bit)
> matreshka-xml-0.3.0-3.fc19.i686 requires libgnat-4.7.so
> matreshka-xml-0.3.0-3.fc19.x86_64 requires libgnat-4.7.so()(64bit)
> [maven-dependency-plugin]
> maven-dependency-plugin-2.7-1.fc19.noarch requires 
> mvn(org.apache.commons:commons-io)
> [ooo2gd]
> ooo2gd-3.0.0-6.fc19.x86_64 requires gdata-java
> [openb

Re: Build control-center in mock fail

[Michael Scherer]

Le mercredi 08 mai 2013 à 10:02 -0700, Adam Williamson a écrit :
> On 08/05/13 08:13 AM, Igor Gnatenko wrote:
> > Thx. But why in oficially packages doesn't  fixed?
> 
> Does anyone know if it's actually the case that the guidelines require 
> packages be buildable without internet access? I just had a quick search 
> on obvious terms through 
> https://fedoraproject.org/wiki/Packaging:Guidelines , and couldn't find 
> anything.

It may not be explicitly written, but we want to have reproductible
builds, which also mean a build that do not depend on external entity
such as a networked server.

-- 
Michael Scherer

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

Fedora ARM Weekly Status Meeting 2013-05-08

[Paul Whalen]

Good day all,

Please join us today (Wednesday, May 8th) at 4PM EDT (8PM UTC)
for the Fedora ARM weekly status meeting in #fedora-meeting-1 on Freenode.

On the agenda so far..

0) Status of ACTION items from our previous meeting

1) Problem packages

2) Kernel Status update

3) Flock (formerly FUDcon)
  
4) Fedora 19 ARM Alpha - creating images

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

Re: Build control-center in mock fail

[Adam Williamson]

On 08/05/13 08:13 AM, Igor Gnatenko wrote:

Thx. But why in oficially packages doesn't  fixed?


Does anyone know if it's actually the case that the guidelines require 
packages be buildable without internet access? I just had a quick search 
on obvious terms through 
https://fedoraproject.org/wiki/Packaging:Guidelines , and couldn't find 
anything.

--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora
http://www.happyassassin.net
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Adding open-vm-tools to core group

[Reindl Harald]

Am 07.05.2013 19:48, schrieb Ravindra Kumar:
> If there are strong use cases that don't require that functionality
> then probably it makes sense to not be part of core, otherwise, I think
> it makes more sense to make open-vm-tools part of @core because sooner
> or later users will end up installing these due to one or the other
> use case.

yes the user ends up installing them

hence, *i am* a VMware user and thanl you for bring the package
in Fedora which takes a lot of headache from using Rawhide-guests

*but* please undersatdn with your argumentation a lot of maintainers
could claim that their packages are in CORE for several reasons
because they are expected to be used from most users

please leave core be what core means

and as i clearly statet that i have open-vm-tools on nearly any
of my setups please respect that i try to speak for other users
which are not using VMware




signature.asc
Description: OpenPGP digital signature
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Adding open-vm-tools to core group

[Reindl Harald]

Am 07.05.2013 19:39, schrieb Ravindra Kumar:
>> and why?
> 
> open-vm-tools are required for anything that requires
> co-ordination with the guest. Here are a few examples,
> clean shutdown of guest from VM management interface,
> guest consistent snapshots, collection/display of guest
> resource usage information in VM management interface,
> guest automation (running commands inside guest) and
> other features VDR/HA as you mentioned

that is all true and nice but no valid reson to include it in CORE

the only packages which should allowed to be in CORE are
commands and libraries which gives you network access
to use yum, nothing else, really *nothing else*

with your argumentation i would have drivers and helpers
for whatever virtualization technology on my VMware guests

NO - that should be up to the admin and nobody else
VMware is doing a damn good hob get the guest-drivers in
the kernel and i am very happy with this because i am a
*heavy* VMware user but as i do not like *any* package
on my setups which i do not *really* need i see no reason
why a KVM user should have any byte of my optional vmware
userspace tools on his setup



signature.asc
Description: OpenPGP digital signature
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Build control-center in mock fail

[Igor Gnatenko]

Thx. But why in oficially packages doesn't  fixed?

Best Regards,
Igor Gnatenko
08.05.2013 18:35 пользователь "Jerry James"  написал:

> On Tue, May 7, 2013 at 10:10 PM, Igor Gnatenko
>  wrote:
> > I use mock to local build packages.
> > I was build control-center in mock. But always error...
> > How I fix it ?
> >   GEN  gnome-control-center.1
> > I/O error : Attempt to load network entity
> > http://docbook.sourceforge.net/release/xsl/current/manpages/docbook.xsl
> > warning: failed to load external entity
> > "http://docbook.sourceforge.net/release/xsl/current/manpages/docbook.xsl
> "
> > cannot parse
> > http://docbook.sourceforge.net/release/xsl/current/manpages/docbook.xsl
> > make[2]: Leaving directory
> > `/builddir/build/BUILD/gnome-control-center-3.8.1/man'
> > make[2]: *** [gnome-control-center.1] Error 4
> > make[1]: *** [all-recursive] Error 1
> > make[1]: Leaving directory
> > `/builddir/build/BUILD/gnome-control-center-3.8.1'
> > make: *** [all] Error 2
>
> You will need to patch doc/Makefile.am and regenerate man/Makefile.in,
> or patch man/Makefile.in.  Change the URL of the docbook.xsl file to:
>
> file:///usr/share/sgml/docbook/xsl-stylesheets/manpages/docbook.xsl
>
> Regards,
> --
> Jerry James
> http://www.jamezone.org/
> --
> devel mailing list
> devel@lists.fedoraproject.org
> https://admin.fedoraproject.org/mailman/listinfo/devel
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: ext4 - scsi: storvsc: avoid usage of WRITE_SAME

[Mario Ceresa]

Confirmed: kernel-3.9.1-0.rc1.201.fc18.x86_64 from koji fix this issue :)

On 8 May 2013 16:40, Mario Ceresa  wrote:
> Cool! thanks a lot!
>
>
> On 8 May 2013 16:38, Eric Sandeen  wrote:
>> On 5/8/13 9:30 AM, Mario Ceresa wrote:
>>> Thanks Eric, I'll upgrade to 3.9 then.
>>>
>>> Do you know if there is an easy way to know when a kernel patch goes 
>>> upstream?
>>
>> You can search in the git tree:
>>
>> [root@host linux-2.6]# git log --pretty=oneline | grep "storvsc: avoid usage"
>> 3e8f4f4065901c8dfc51407e1984495e1748c090 [SCSI] storvsc: avoid usage of 
>> WRITE_SAME
>> [root@host linux-2.6]# git describe --contains 
>> 3e8f4f4065901c8dfc51407e1984495e1748c090
>> v3.9-rc1~21^2~7
>>
>> -Eric
>>
>>> Mario
>>>
>>> On 8 May 2013 16:28, Eric Sandeen  wrote:
 On 5/8/13 9:21 AM, Mario Ceresa wrote:
> Dear all,
> When accessing a VHDX disc with a f18 VM (hyperv) with kernel
> 3.8.8-202 x86_64 I have tons of errors like:
>
> Add. Sense: No additional sense information
> hv_storvsc vmbus_0_12: cmd 0x41 scsi status 0x2 srb status 0x6
>
> I believe it is related to WRITE_SAME don't implemented in win2012
> server. It seems that this patch could make the trick:
>
> https://patchwork.kernel.org/patch/2172871/
>
> But how could I check if I have it in my kernel or not?

 It went upstream in v3.9-rc1 so if you have that or later, you have it.

 -Eric

> Of course, I can be completely wrong. If you have any other ideas,
> please share :)
>
> Thanks for any help,
>
> Mario
>

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

Re: ext4 - scsi: storvsc: avoid usage of WRITE_SAME

[Mario Ceresa]

Cool! thanks a lot!


On 8 May 2013 16:38, Eric Sandeen  wrote:
> On 5/8/13 9:30 AM, Mario Ceresa wrote:
>> Thanks Eric, I'll upgrade to 3.9 then.
>>
>> Do you know if there is an easy way to know when a kernel patch goes 
>> upstream?
>
> You can search in the git tree:
>
> [root@host linux-2.6]# git log --pretty=oneline | grep "storvsc: avoid usage"
> 3e8f4f4065901c8dfc51407e1984495e1748c090 [SCSI] storvsc: avoid usage of 
> WRITE_SAME
> [root@host linux-2.6]# git describe --contains 
> 3e8f4f4065901c8dfc51407e1984495e1748c090
> v3.9-rc1~21^2~7
>
> -Eric
>
>> Mario
>>
>> On 8 May 2013 16:28, Eric Sandeen  wrote:
>>> On 5/8/13 9:21 AM, Mario Ceresa wrote:
 Dear all,
 When accessing a VHDX disc with a f18 VM (hyperv) with kernel
 3.8.8-202 x86_64 I have tons of errors like:

 Add. Sense: No additional sense information
 hv_storvsc vmbus_0_12: cmd 0x41 scsi status 0x2 srb status 0x6

 I believe it is related to WRITE_SAME don't implemented in win2012
 server. It seems that this patch could make the trick:

 https://patchwork.kernel.org/patch/2172871/

 But how could I check if I have it in my kernel or not?
>>>
>>> It went upstream in v3.9-rc1 so if you have that or later, you have it.
>>>
>>> -Eric
>>>
 Of course, I can be completely wrong. If you have any other ideas,
 please share :)

 Thanks for any help,

 Mario

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

Re: ext4 - scsi: storvsc: avoid usage of WRITE_SAME

[Eric Sandeen]

On 5/8/13 9:30 AM, Mario Ceresa wrote:
> Thanks Eric, I'll upgrade to 3.9 then.
> 
> Do you know if there is an easy way to know when a kernel patch goes upstream?

You can search in the git tree:

[root@host linux-2.6]# git log --pretty=oneline | grep "storvsc: avoid usage"
3e8f4f4065901c8dfc51407e1984495e1748c090 [SCSI] storvsc: avoid usage of 
WRITE_SAME
[root@host linux-2.6]# git describe --contains 
3e8f4f4065901c8dfc51407e1984495e1748c090
v3.9-rc1~21^2~7

-Eric

> Mario
> 
> On 8 May 2013 16:28, Eric Sandeen  wrote:
>> On 5/8/13 9:21 AM, Mario Ceresa wrote:
>>> Dear all,
>>> When accessing a VHDX disc with a f18 VM (hyperv) with kernel
>>> 3.8.8-202 x86_64 I have tons of errors like:
>>>
>>> Add. Sense: No additional sense information
>>> hv_storvsc vmbus_0_12: cmd 0x41 scsi status 0x2 srb status 0x6
>>>
>>> I believe it is related to WRITE_SAME don't implemented in win2012
>>> server. It seems that this patch could make the trick:
>>>
>>> https://patchwork.kernel.org/patch/2172871/
>>>
>>> But how could I check if I have it in my kernel or not?
>>
>> It went upstream in v3.9-rc1 so if you have that or later, you have it.
>>
>> -Eric
>>
>>> Of course, I can be completely wrong. If you have any other ideas,
>>> please share :)
>>>
>>> Thanks for any help,
>>>
>>> Mario
>>>
>>

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

Re: Build control-center in mock fail

[Jerry James]

On Tue, May 7, 2013 at 10:10 PM, Igor Gnatenko
 wrote:
> I use mock to local build packages.
> I was build control-center in mock. But always error...
> How I fix it ?
>   GEN  gnome-control-center.1
> I/O error : Attempt to load network entity
> http://docbook.sourceforge.net/release/xsl/current/manpages/docbook.xsl
> warning: failed to load external entity
> "http://docbook.sourceforge.net/release/xsl/current/manpages/docbook.xsl";
> cannot parse
> http://docbook.sourceforge.net/release/xsl/current/manpages/docbook.xsl
> make[2]: Leaving directory
> `/builddir/build/BUILD/gnome-control-center-3.8.1/man'
> make[2]: *** [gnome-control-center.1] Error 4
> make[1]: *** [all-recursive] Error 1
> make[1]: Leaving directory
> `/builddir/build/BUILD/gnome-control-center-3.8.1'
> make: *** [all] Error 2

You will need to patch doc/Makefile.am and regenerate man/Makefile.in,
or patch man/Makefile.in.  Change the URL of the docbook.xsl file to:

file:///usr/share/sgml/docbook/xsl-stylesheets/manpages/docbook.xsl

Regards,
--
Jerry James
http://www.jamezone.org/
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: ext4 - scsi: storvsc: avoid usage of WRITE_SAME

[Mario Ceresa]

Thanks Eric, I'll upgrade to 3.9 then.

Do you know if there is an easy way to know when a kernel patch goes upstream?

Mario

On 8 May 2013 16:28, Eric Sandeen  wrote:
> On 5/8/13 9:21 AM, Mario Ceresa wrote:
>> Dear all,
>> When accessing a VHDX disc with a f18 VM (hyperv) with kernel
>> 3.8.8-202 x86_64 I have tons of errors like:
>>
>> Add. Sense: No additional sense information
>> hv_storvsc vmbus_0_12: cmd 0x41 scsi status 0x2 srb status 0x6
>>
>> I believe it is related to WRITE_SAME don't implemented in win2012
>> server. It seems that this patch could make the trick:
>>
>> https://patchwork.kernel.org/patch/2172871/
>>
>> But how could I check if I have it in my kernel or not?
>
> It went upstream in v3.9-rc1 so if you have that or later, you have it.
>
> -Eric
>
>> Of course, I can be completely wrong. If you have any other ideas,
>> please share :)
>>
>> Thanks for any help,
>>
>> Mario
>>
>
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: ext4 - scsi: storvsc: avoid usage of WRITE_SAME

[Eric Sandeen]

On 5/8/13 9:21 AM, Mario Ceresa wrote:
> Dear all,
> When accessing a VHDX disc with a f18 VM (hyperv) with kernel
> 3.8.8-202 x86_64 I have tons of errors like:
> 
> Add. Sense: No additional sense information
> hv_storvsc vmbus_0_12: cmd 0x41 scsi status 0x2 srb status 0x6
> 
> I believe it is related to WRITE_SAME don't implemented in win2012
> server. It seems that this patch could make the trick:
> 
> https://patchwork.kernel.org/patch/2172871/
> 
> But how could I check if I have it in my kernel or not?

It went upstream in v3.9-rc1 so if you have that or later, you have it.

-Eric

> Of course, I can be completely wrong. If you have any other ideas,
> please share :)
> 
> Thanks for any help,
> 
> Mario
> 

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

ext4 - scsi: storvsc: avoid usage of WRITE_SAME

[Mario Ceresa]

Dear all,
When accessing a VHDX disc with a f18 VM (hyperv) with kernel
3.8.8-202 x86_64 I have tons of errors like:

Add. Sense: No additional sense information
hv_storvsc vmbus_0_12: cmd 0x41 scsi status 0x2 srb status 0x6

I believe it is related to WRITE_SAME don't implemented in win2012
server. It seems that this patch could make the trick:

https://patchwork.kernel.org/patch/2172871/

But how could I check if I have it in my kernel or not?

Of course, I can be completely wrong. If you have any other ideas,
please share :)

Thanks for any help,

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

Schedule for Thursday's FPC Meeting (2013-05-09 16:00 UTC)

[James Antill]

 Following is the list of topics that will be discussed in the FPC
meeting Thursday at 2013-05-09 16:00 UTC in #fedora-meeting-1 on
irc.freenode.net.

 Local time information (via. rktime):

2013-05-09 09:00 Thu US/Pacific
2013-05-09 12:00 Thu US/Eastern
2013-05-09 16:00 Thu UTC <-
2013-05-09 17:00 Thu Europe/London
2013-05-09 18:00 Thu Europe/Paris
2013-05-09 18:00 Thu Europe/Berlin
2013-05-09 21:30 Thu Asia/Calcutta
--new day--
2013-05-10 00:00 Fri Asia/Singapore
2013-05-10 00:00 Fri Asia/Hong_Kong
2013-05-10 01:00 Fri Asia/Tokyo
2013-05-10 02:00 Fri Australia/Brisbane

 Links to all tickets below can be found at: 

https://fedorahosted.org/fpc/report/12


= New business =

#topic #279 Bundling exception for agg in mapnik
.fpc 279
https://fedorahosted.org/fpc/ticket/279

#topic #281 New Python Macros for Easier Packaging
.fpc 281
https://fedorahosted.org/fpc/ticket/281

#topic #282 Bundling exception request for gpick, about lua
.fpc 282
https://fedorahosted.org/fpc/ticket/282

#topic #283 specify that systemd .service, .socket, .timer, … should not
be marked executable
.fpc 283
https://fedorahosted.org/fpc/ticket/283

#topic #284 github source URL: improved tarball names
.fpc 284
https://fedorahosted.org/fpc/ticket/284


= 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

Re: Do you think this is a security risk and if not is it a bad UI decision?

[Dan Mashal]

On Wednesday, May 8, 2013, Pierre-Yves Chibon wrote:

> On Wed, 2013-05-08 at 10:10 +0200, Olav Vitters wrote:
> > On Fri, May 03, 2013 at 09:03:02PM -0700, Dan Mashal wrote:
> > > Let's be realistic here. The precedence they have recently set is they
> > > make decisions and if you don't like it "too bad".
> >
> > Even if that is true, what is your point?
>
> That you are replying to a 4 days old email on a thread that is no longer
> active?
>

+1

Kevin,

Please close this thread. Mission accomplished as your great wisdom
predicted.

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

Re: Re: dietlibc

[Jon Ciesla]

On Wed, May 8, 2013 at 7:48 AM, Frank Bergmann wrote:

> On Wed, May 08, 2013 at 06:56:59AM -0500, Jon Ciesla wrote:
> >On Wed, May 8, 2013 at 6:02 AM, Frank Bergmann <[1]
> fedora-de...@tuxad.de>
> >wrote:
> >  Hello,
> >  I freshly subscribed this list after reading that dietlibc seems to
> be
> >  unmaintained.
> >  ([2]
> http://mm3test.fedoraproject.org/hyperkitty/list/devel@mm3test.fedorap
> >  roject.org/thread/BP7LYYNGQA2DDTNFNS3EJXX3AGNZRNAX/)
> >  What's the current status of dietlibc in Fedora and how can it be
> checked?
> >  Last built was done by Jon Ciesla on 2013-03-27.
> >
> >Unmaintained how?  Speaking as the current maintainer, my plans have
> been to
>
> See URL. Toshio Kuratomi wrote:
> "needing to have new maintainers and comaintainers for some packages
> ...
> Note to potential new maintainers: although not mandatory, you may want to
> open an optional re-review request as the spec files for some of these may
> be very out of sync with the current Fedora Packaging Guidelines.
> ...
> dietlibc (devel is still owned by ensc but maybe that was an oversight)
> "
> >migrate any packages using it to glibc, but the keep dietlibc in the
> distro
> >for developer use.  I believe I've got that largely finished.  Is
> there
> >something you'd like to see done?
>
> No, thanks. I just don't want to see it kicked out of Fedora. :-)
> I'm glad that it actually has a maintainer.
>
> Ah.  Ok. :)  If you ever need anything, file a BZ.

-J


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




-- 
http://cecinestpasunefromage.wordpress.com/

in your fear, seek only peace
in your fear, seek only love

-d. bowie
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Re: dietlibc

[Frank Bergmann]

On Wed, May 08, 2013 at 06:56:59AM -0500, Jon Ciesla wrote:
>On Wed, May 8, 2013 at 6:02 AM, Frank Bergmann <[1]fedora-de...@tuxad.de>
>wrote:
>  Hello,
>  I freshly subscribed this list after reading that dietlibc seems to be
>  unmaintained.
>  
> ([2]http://mm3test.fedoraproject.org/hyperkitty/list/devel@mm3test.fedorap
>  roject.org/thread/BP7LYYNGQA2DDTNFNS3EJXX3AGNZRNAX/)
>  What's the current status of dietlibc in Fedora and how can it be 
> checked?
>  Last built was done by Jon Ciesla on 2013-03-27.
> 
>Unmaintained how?  Speaking as the current maintainer, my plans have been 
> to

See URL. Toshio Kuratomi wrote:
"needing to have new maintainers and comaintainers for some packages
...
Note to potential new maintainers: although not mandatory, you may want to
open an optional re-review request as the spec files for some of these may
be very out of sync with the current Fedora Packaging Guidelines.
...
dietlibc (devel is still owned by ensc but maybe that was an oversight) 
"
>migrate any packages using it to glibc, but the keep dietlibc in the distro
>for developer use.  I believe I've got that largely finished.  Is there
>something you'd like to see done?

No, thanks. I just don't want to see it kicked out of Fedora. :-)
I'm glad that it actually has a maintainer.

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

F-19 Branched report: 20130508 changes

[Fedora Branched Report]

Compose started at Wed May  8 09:15:02 UTC 2013

Broken deps for x86_64
--
[byzanz]
byzanz-0.3-0.5.fc17.x86_64 requires libpanel-applet-4.so.0()(64bit)
[cinnamon]
cinnamon-menu-editor-1.6.7-7.fc19.noarch requires gnome-panel
[deltacloud-core]
deltacloud-core-1.0.5-2.fc19.noarch requires ruby(abi) = 0:1.9.1
[dragonegg]
dragonegg-3.1-19.fc19.x86_64 requires gcc = 0:4.7.2-9.fc19
[fcitx-libpinyin]
fcitx-libpinyin-0.2.90-1.fc19.x86_64 requires 
libpinyin.so.3(LIBPINYIN)(64bit)
fcitx-libpinyin-0.2.90-1.fc19.x86_64 requires libpinyin.so.3()(64bit)
[freeipa]
freeipa-server-strict-3.2.0-0.3.beta1.fc19.x86_64 requires pki-ca = 
0:10.0.1
freeipa-server-strict-3.2.0-0.3.beta1.fc19.x86_64 requires krb5-server 
= 0:1.11.2-1
[ghc-data-memocombinators]
ghc-data-memocombinators-0.4.4-3.fc19.x86_64 requires 
libHSdata-inttrie-0.0.8-ghc7.4.2.so()(64bit)
ghc-data-memocombinators-0.4.4-3.fc19.x86_64 requires 
ghc(data-inttrie-0.0.8-1cc0f43b566911f823287ed46100a81e)
ghc-data-memocombinators-devel-0.4.4-3.fc19.x86_64 requires 
ghc-devel(data-inttrie-0.0.8-1cc0f43b566911f823287ed46100a81e)
[ghc-show]
ghc-show-0.4.1.2-4.fc19.x86_64 requires 
libHSsmallcheck-0.6.1-ghc7.4.2.so()(64bit)
ghc-show-0.4.1.2-4.fc19.x86_64 requires 
ghc(smallcheck-0.6.1-909159f2996454c279da80ced02cfe48)
ghc-show-devel-0.4.1.2-4.fc19.x86_64 requires 
ghc-devel(smallcheck-0.6.1-909159f2996454c279da80ced02cfe48)
[gnome-applet-sensors]
gnome-applet-sensors-3.0.0-4.fc18.i686 requires libpanel-applet-4.so.0
gnome-applet-sensors-3.0.0-4.fc18.x86_64 requires 
libpanel-applet-4.so.0()(64bit)
[gooddata-cl]
gooddata-cl-1.2.56-2.fc19.noarch requires gdata-java
[kawa]
1:kawa-1.11-5.fc19.x86_64 requires servlet25
[kdevelop-custom-buildsystem]
kdevelop-custom-buildsystem-1.2.2-2.fc19.x86_64 requires 
libkdevplatformutil.so.6()(64bit)
kdevelop-custom-buildsystem-1.2.2-2.fc19.x86_64 requires 
libkdevplatformproject.so.6()(64bit)
kdevelop-custom-buildsystem-1.2.2-2.fc19.x86_64 requires 
libkdevplatformoutputview.so.6()(64bit)
kdevelop-custom-buildsystem-1.2.2-2.fc19.x86_64 requires 
libkdevplatformlanguage.so.6()(64bit)
kdevelop-custom-buildsystem-1.2.2-2.fc19.x86_64 requires 
libkdevplatforminterfaces.so.6()(64bit)
[libkolab]
php-kolab-0.4.1-3.fc19.x86_64 requires php(zend-abi) = 0:20100525-x86-64
php-kolab-0.4.1-3.fc19.x86_64 requires php(api) = 0:20100412-x86-64
[libvirt-qmf]
libvirt-qmf-0.3.0-6.fc19.x86_64 requires 
libmcommon_qmf.so.1.0.0()(64bit)
libvirt-qmf-0.3.0-6.fc19.x86_64 requires libmcommon.so.1.0.0()(64bit)
[matreshka]
matreshka-0.3.0-3.fc19.i686 requires libgnat-4.7.so
matreshka-0.3.0-3.fc19.x86_64 requires libgnat-4.7.so()(64bit)
matreshka-amf-0.3.0-3.fc19.i686 requires libgnat-4.7.so
matreshka-amf-0.3.0-3.fc19.x86_64 requires libgnat-4.7.so()(64bit)
matreshka-amf-mofext-0.3.0-3.fc19.i686 requires libgnat-4.7.so
matreshka-amf-mofext-0.3.0-3.fc19.x86_64 requires 
libgnat-4.7.so()(64bit)
matreshka-amf-ocl-0.3.0-3.fc19.i686 requires libgnat-4.7.so
matreshka-amf-ocl-0.3.0-3.fc19.x86_64 requires libgnat-4.7.so()(64bit)
matreshka-amf-uml-0.3.0-3.fc19.i686 requires libgnat-4.7.so
matreshka-amf-uml-0.3.0-3.fc19.x86_64 requires libgnat-4.7.so()(64bit)
matreshka-amf-utp-0.3.0-3.fc19.i686 requires libgnat-4.7.so
matreshka-amf-utp-0.3.0-3.fc19.x86_64 requires libgnat-4.7.so()(64bit)
matreshka-fastcgi-0.3.0-3.fc19.i686 requires libgnat-4.7.so
matreshka-fastcgi-0.3.0-3.fc19.i686 requires libgnarl-4.7.so
matreshka-fastcgi-0.3.0-3.fc19.x86_64 requires libgnat-4.7.so()(64bit)
matreshka-fastcgi-0.3.0-3.fc19.x86_64 requires libgnarl-4.7.so()(64bit)
matreshka-sql-core-0.3.0-3.fc19.i686 requires libgnat-4.7.so
matreshka-sql-core-0.3.0-3.fc19.x86_64 requires libgnat-4.7.so()(64bit)
matreshka-sql-postgresql-0.3.0-3.fc19.i686 requires libgnat-4.7.so
matreshka-sql-postgresql-0.3.0-3.fc19.x86_64 requires 
libgnat-4.7.so()(64bit)
matreshka-sql-sqlite-0.3.0-3.fc19.i686 requires libgnat-4.7.so
matreshka-sql-sqlite-0.3.0-3.fc19.x86_64 requires 
libgnat-4.7.so()(64bit)
matreshka-xml-0.3.0-3.fc19.i686 requires libgnat-4.7.so
matreshka-xml-0.3.0-3.fc19.x86_64 requires libgnat-4.7.so()(64bit)
[maven-dependency-plugin]
maven-dependency-plugin-2.7-1.fc19.noarch requires 
mvn(org.apache.commons:commons-io)
[ooo2gd]
ooo2gd-3.0.0-6.fc19.x86_64 requires gdata-java
[openbox]
gdm-control-3.5.0-11.20121001git782b28.fc19.x86_64 requires gnome-panel
gnome-panel-control-3.5.0-11.20121001git782b28.fc19.x86_64 requires 
gnome-panel
[ovirt-engine]
ovirt-engine-notification-service-3.1.0-1.fc19.noarch requires 
c

Re: Re: dietlibc

[Jon Ciesla]

On Wed, May 8, 2013 at 6:02 AM, Frank Bergmann wrote:

> Hello,
>
> I freshly subscribed this list after reading that dietlibc seems to be
> unmaintained.
> (
> http://mm3test.fedoraproject.org/hyperkitty/list/de...@mm3test.fedoraproject.org/thread/BP7LYYNGQA2DDTNFNS3EJXX3AGNZRNAX/
> )
>
> What's the current status of dietlibc in Fedora and how can it be checked?
> Last built was done by Jon Ciesla on 2013-03-27.
>
> Unmaintained how?  Speaking as the current maintainer, my plans have been
to migrate any packages using it to glibc, but the keep dietlibc in the
distro for developer use.  I believe I've got that largely finished.  Is
there something you'd like to see done?

-J


> On Sun Mar 3 03:21:06 UTC 2013, Kevin Kofler wrote:
>
> > We agree then. But if we want to keep dietlibc, it needs to be fixed to
> > comply with the packaging guidelines and best practices, i.e.:
> > * Shared library build needs to be enabled. I see no reason to build this
> > library as static only as Enrico is doing. We tolerate this where
> upstream
> > does not support shared builds at all, but this is not the case here.
> > * The main package should contain the shared library (and the
> documentation
> > that's relevant at runtime, in particular COPYING) only. Right now it
> > contains some stuff which probably belongs into -devel.
> > * The main package must not require -devel as it does now.
> > * The -devel package should not contain the static library, which should
> > instead be in a -static subpackage.
> > * The -lib package (which is currently not built by default, it contains
> the
> > shared library if you enable shared build) should simply be the main
> > package. It doesn't make sense to have a -lib subpackage of a library.
> > * The -header subpackage should really be called -headers (There's more
> than
> > one header! And it'd also be consistent with glibc.) or folded into
> -devel
> > (though then it can't be noarch anymore).
>
> If you are actually looking for a maintainer and the policies/rules are
> not too difficult then I would do this job (before you throw dietlibc out
> of Fedora). :-)
>
> best regards
> Frank
> --
> devel mailing list
> devel@lists.fedoraproject.org
> https://admin.fedoraproject.org/mailman/listinfo/devel




-- 
http://cecinestpasunefromage.wordpress.com/

in your fear, seek only peace
in your fear, seek only love

-d. bowie
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Re: dietlibc

[Frank Bergmann]

Hello,

I freshly subscribed this list after reading that dietlibc seems to be
unmaintained.
(http://mm3test.fedoraproject.org/hyperkitty/list/de...@mm3test.fedoraproject.org/thread/BP7LYYNGQA2DDTNFNS3EJXX3AGNZRNAX/)

What's the current status of dietlibc in Fedora and how can it be checked?
Last built was done by Jon Ciesla on 2013-03-27.

On Sun Mar 3 03:21:06 UTC 2013, Kevin Kofler wrote:

> We agree then. But if we want to keep dietlibc, it needs to be fixed to 
> comply with the packaging guidelines and best practices, i.e.:
> * Shared library build needs to be enabled. I see no reason to build this 
> library as static only as Enrico is doing. We tolerate this where upstream 
> does not support shared builds at all, but this is not the case here.
> * The main package should contain the shared library (and the documentation 
> that's relevant at runtime, in particular COPYING) only. Right now it 
> contains some stuff which probably belongs into -devel.
> * The main package must not require -devel as it does now.
> * The -devel package should not contain the static library, which should 
> instead be in a -static subpackage.
> * The -lib package (which is currently not built by default, it contains the 
> shared library if you enable shared build) should simply be the main 
> package. It doesn't make sense to have a -lib subpackage of a library.
> * The -header subpackage should really be called -headers (There's more than 
> one header! And it'd also be consistent with glibc.) or folded into -devel 
> (though then it can't be noarch anymore).

If you are actually looking for a maintainer and the policies/rules are
not too difficult then I would do this job (before you throw dietlibc out
of Fedora). :-)

best regards
Frank
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Packaging directory in /mnt - how to do so?

[Lennart Poettering]

On Wed, 08.05.13 09:32, Tomasz Torcz (to...@pipebreaker.pl) wrote:

> On Tue, May 07, 2013 at 09:34:15AM +, "Jóhann B. Guðmundsson" wrote:
> > On 05/07/2013 09:14 AM, Tomasz Torcz wrote:
> > >Hey list,
> > >
> > >   In the course of review of owfs (#927237) I was pointed that
> > >shipping directory in /mnt is prohibited. FHS seems to agree.
> > >
> > >   owfs is suite of program for accessing 1-wire network, which is
> > >simple hardware protocol.  One of the program is FUSE module,
> > >giving the access to network and devices on it through filesystem.
> > >The "/mnt/1wire" directory is widely used default - it's in the
> > >default config files and many scripts over the net uses it. I'd really
> > >like to retain this similarity eith other distributions in Fedora.
> > >
> > >   Is there any way out from this situation?
> > >
> > 
> > Yeah fix this and push it upstream so those doing it wrong start
> > doing it right and follow FHS :)
> 
>   What would be proper path for such kind of filesystem?

/run/owfs/1wire or so sounds like a good idea.

/mnt really is something the admin owns and not the vendor, so the
package should stay away from it.

-- 
Lennart Poettering - Red Hat, Inc.
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Packaging directory in /mnt - how to do so?

[Alec Leamas]

On 2013-05-08 09:32, Tomasz Torcz wrote:

On Tue, May 07, 2013 at 09:34:15AM +, "Jóhann B. Guðmundsson" wrote:

On 05/07/2013 09:14 AM, Tomasz Torcz wrote:

Hey list,

   In the course of review of owfs (#927237) I was pointed that
shipping directory in /mnt is prohibited. FHS seems to agree.

   owfs is suite of program for accessing 1-wire network, which is
simple hardware protocol.  One of the program is FUSE module,
giving the access to network and devices on it through filesystem.
The "/mnt/1wire" directory is widely used default - it's in the
default config files and many scripts over the net uses it. I'd really
like to retain this similarity eith other distributions in Fedora.

   Is there any way out from this situation?


Yeah fix this and push it upstream so those doing it wrong start
doing it right and follow FHS :)

   What would be proper path for such kind of filesystem?

Hm... looking at FHS it actually looks like /mnt is the point for 
temporary filesystem, nfs mountpoints is an example. One alternative 
would be to see the 1-wire filesystem as a removable device and thus use 
/run/media for it., I guess.


There is the tmpfiles.d mechanism to set up the directory without 
packaging it (which isn't possible for /run anyway, since /run is empty 
on boot). Actually, I think you could technically use tmpfiles.d to add 
a temporary mountpount also in /mnt; no idea if this complies with the GL.



Just my 5 öre...

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

Re: Provenpackager mistakes

[Michael Schwendt]

On Tue, 7 May 2013 09:12:33 -0600, Jerry James wrote:

> On Tue, May 7, 2013 at 5:44 AM, Fedora Koji Build System wrote:
> > Package: m4rie-20130416-1.fc19
> > Tag: f19-updates-candidate
> > Status: complete
> > Built by: pbrobinson
> > ID: 416696
> > Started: Tue, 07 May 2013 11:35:25 UTC
> > Finished: Tue, 07 May 2013 11:44:10 UTC
> > Changelog:
> > * Mon May 06 2013 Jerry James  - 20130416-1
> > - New upstream release
> > - Add -aarch64 and -doxygen patches
> > - Build PDF documentation instead of HTML, because of numerous TeX-only
> >   constructs in the documentation
> 
> Peter, this may seem like a personal attack on you.  That is not my
> intent.  You have been very helpful to me in the past, and I
> appreciate that help.  But this is yet another example of a
> provenpackager doing something wrong to one of the packages I
> maintain.  Each time this happens, I have to do more work to fix the
> mistake.  I've had this happen 5 times since August, 3 times in 2013.
> Each time I have sent a private email to the individual involved, but
> since the same mistakes keep being made by different people, I think
> it is time to draw some attention to them.
> 
> These are the mistakes I keep seeing:
> 1. Building a package in isolation, without considering necessary
> buildroot overrides.
> 2. Updating a package that is a dependency of other packages without
> testing the effects of the update on those other packages.
> 3. Updating a package that is a dependency of other packages without
> rebuilding those other packages.
> 4. Pushing a change to a git branch without also pushing it to master.
> 5. Creating a new update in Bodhi instead of editing an existing update.
> 6. Not making any attempt to communicate with a package maintainer.
> 
> In this case, Peter, you made mistakes 1, 2, 3, and 6.  I imagine you
> saw the work I did in Rawhide yesterday, knew that m4rie has been
> broken on ARM for some time, and decided to push the new m4rie version
> to F-19 so you can build it for ARM and mark that build failure as
> being "fixed".  But what you must have missed is the email that has
> been sent to -devel over the last several days, coordinating the
> update of m4rie with several other packages.  The plan was this:
> 
> 1. Update in Rawhide
>a. Update libfplll, m4ri, and ntl
>b. Once those builds are in the buildroot, update eclib, flint,
>   latte-integrale, m4rie, polybori, and Singular
>c. Once those builds are in the buildroot, update linbox and Macaulay2
>d. Once those builds are in the buildroot, update sagemath
> 2. Test in Rawhide, going back to step 1 as necessary to fix problems.
> 3. Once all packages seem stable, do the same builds for F-19
> 
> I was still on step 1d, and you leapt ahead to part of step 3, without
> talking to me to find out what the plan is, and without doing all of
> the other builds that are necessary.  The m4rie build you did is now
> linked with the wrong version of m4ri, which means that I will have to
> bump NEVR to do the build properly, which means that I'll have to do a
> useless build in Rawhide just to bump NEVR there.  Please cancel the
> F-19 update you submitted, as that build is bogus.  I will submit a
> new update once I get to step 3.
> 
> And a general plea to provenpackagers: don't make mistake #6, please.
> Every single time this has happened, I could have told the
> provenpackager involved what needed to be done if he had just asked.
> But none of them did.  They just acted, without having sufficient
> knowledge to act correctly, and without making any attempt at
> acquiring that knowledge.  Don't do that.
> 
> 

A summary of what exactly has been done would have been good here.
It seems a version upgrade has been copied from Rawhide to F-19.
Is that true?

https://fedoraproject.org/wiki/Who_is_allowed_to_modify_which_packages

Adding to your list of mistakes 1-6, this is also an example where copying
the %changelog is not enough. IMHO. The published package appears as if _you_
did the build for F-19, while you only had prepared the spec/package for
Rawhide. I wouldn't mind, if a real "official" co-maintainer copied from one
branch to another and did builds like that for a version upgrade, but a
provenpackager ought to add to the %changelog an explicit comment. The
release versioning scheme where a minor ".1" is appended to the Release tag
makes that easy (and is the standard way to apply minor fixes anyway). That
would create a merge conflict with the master tree, but one would need to
figure out why the maintainers did not apply those _version upgrades_
themselves.

About the special dependencies of your package, it would be an idea to add
more specific EVR details to the BuildRequires (and perhaps even the Requires).
That's one common way to request a specific target environment, and the package
won't even build without the needed buildroot overrides you refer to.

-- 
Fedora release 19 (Schrödinger’s Cat) - Linux 3.9.0-301.fc19.x86_64

Re: Do you think this is a security risk and if not is it a bad UI decision?

[Pierre-Yves Chibon]

On Wed, 2013-05-08 at 10:10 +0200, Olav Vitters wrote:
> On Fri, May 03, 2013 at 09:03:02PM -0700, Dan Mashal wrote:
> > Let's be realistic here. The precedence they have recently set is they
> > make decisions and if you don't like it "too bad".
> 
> Even if that is true, what is your point?

That you are replying to a 4 days old email on a thread that is no
longer active?

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

Re: Expanding the list of "Hardened Packages"

[Florian Weimer]

On 04/14/2013 03:34 AM, Steve Grubb wrote:

  -fstack-protector-all really is all. The default in Fedora is 4 bytes which
would cover cases where ints and char[] are interposed as in some networking
code. But more importantly, the defaul stack-protector only kicks in when the
object is a char array. If its an int array or something exotic like an array
within a struct, it does not kick in. That is what the -fstack-protector-
strong patch provides. Its been floating around the internet and is the default
for chrome OS. All the testing I've done shows it catches all stack overflows
of all kinds. We really need it integrated with Fedora's gcc.


The basic patch has been committed upstream:



It's still incomplete, though, particularly for C++.  Slots for structs 
returned from functions can be allocated in the caller and are 
addressable in the callee (as a consequence of the named return value 
optimization).  This means that the calling function should be 
instrumented with a canary.  Han Shen is going to work on a follow-up 
patch which addresses this gap.  Once that additional patch is in, we 
should consider backporting both patches.


--
Florian Weimer / Red Hat Product Security Team
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Do you think this is a security risk and if not is it a bad UI decision?

[Olav Vitters]

On Fri, May 03, 2013 at 09:03:02PM -0700, Dan Mashal wrote:
> Let's be realistic here. The precedence they have recently set is they
> make decisions and if you don't like it "too bad".

Even if that is true, what is your point?

-- 
Regards,
Olav
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Do you think this is a security risk and if not is it a bad UI decision?

[Olav Vitters]

On Sat, May 04, 2013 at 12:03:39AM -0500, Eric Sandeen wrote:
> Anaconda has a pretty special place in this project.  It is the
> uber-administrator of every new Fedora install.  We would do better
> as a community to hash out major changes before they're made, and
> try to reach some agreement before we implement them.

I've been reading loads and loads of blogs about the Anaconda redesign.
That was a pretty major change. Something like showing a password is
terribly minor change when developing.

There was a pretty huge outcry about the Anaconda redesign, despite all
the blogs. Now there is some small change, and there is a call that
"major changes need to be hashed out".

Seems like nothing they'd do would ever be good enough. Getting
consensus before most commits sounds like a good way to scare away
developers.
-- 
Regards,
Olav
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Do you think this is a security risk and if not is it a bad UI decision?

[Olav Vitters]

On Mon, May 06, 2013 at 09:51:22AM -0400, Przemek Klosowski wrote:
> On 05/04/2013 12:30 AM, Matthew Garrett wrote:
> >On Fri, May 03, 2013 at 11:24:01PM -0500, Eric Sandeen wrote:
> >>Matthew, with all due respect the tone of the bug doesn't make me think
> >>that there is a lot of interest in discussion from the developers.
> >
> >Reopening bugs is generally a good way of ensuring that there's even
> >less interest in discussion from the developers, and posting to mailing
> >lists that most of the developers concerned don't read has pretty
> >obvious problems in terms of changing their minds.
> 
> From the process point of view, it does look a little
> obstructionist: "No, we won't discuss it in Bugzilla"; "No we won't
> discuss it in fedora-devel either". Reminds me of the joke: "Lunch
> on Tuesday? Sorry, can't do it on Tuesday---how about Never? is
> Never good for you?". I understand your point that the concerned
> Anaconda developers may simply not see the traffic, but they do know
> about the Bugzilla entry and this discussion on the devel list, so I
> hope that they could find it in their heart to put out their
> argument in the forum with the largest possible audience which at
> the moment seems to be here.

The simple explanation is:
- Bugzilla is awful to have a discussion. It is to solve bugs and focus
  on how to solve a particular bug
- If you want a discussion, hold it with the developers
  Meaning anaconda-developers

> Big changes deserve more explanation and outreach from the
> developers, not just dropping them in everyone's lap.

Define "big". To any developer, this change is minor. Usually "big" or
"invasive" is explained as "I have an issue with it", no matter how
small.

-- 
Regards,
Olav
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Packaging directory in /mnt - how to do so?

[Tomasz Torcz]

On Tue, May 07, 2013 at 09:34:15AM +, "Jóhann B. Guðmundsson" wrote:
> On 05/07/2013 09:14 AM, Tomasz Torcz wrote:
> >Hey list,
> >
> >   In the course of review of owfs (#927237) I was pointed that
> >shipping directory in /mnt is prohibited. FHS seems to agree.
> >
> >   owfs is suite of program for accessing 1-wire network, which is
> >simple hardware protocol.  One of the program is FUSE module,
> >giving the access to network and devices on it through filesystem.
> >The "/mnt/1wire" directory is widely used default - it's in the
> >default config files and many scripts over the net uses it. I'd really
> >like to retain this similarity eith other distributions in Fedora.
> >
> >   Is there any way out from this situation?
> >
> 
> Yeah fix this and push it upstream so those doing it wrong start
> doing it right and follow FHS :)

  What would be proper path for such kind of filesystem?

-- 
Tomasz Torcz"Funeral in the morning, IDE hacking
xmpp: zdzich...@chrome.plin the afternoon and evening." - Alan Cox

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