Retiring gnome-media

[Dan Mashal]

Hi all,

I'm retiring gnome-media as it's no longer used by anything.

Thanks,
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: Branched iso

[Dan Mashal]

On Wed, Feb 12, 2014 at 7:48 PM, Carlos Morel-Riquelme
 wrote:
> Hi guys , i have a question , i use fedora 20 branched and work fine , also
> i can contribute to the comunity send bugs error and testing new packages :)
> , now i don't now if i can update to fedora 21 branched when this is out.
>
> its possible ?

Not sure if I understand your question correctly but..

https://fedoraproject.org/wiki/FedUp

If you're running Rawhide all you need to do is run yum update.
-- 
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: Why libicu soname bump required harfbuzz package to be built twice?

[Dan Mashal]

On Wed, Feb 12, 2014 at 7:56 PM, Parag N(पराग़)  wrote:
> Hi,
>From the yesterday's pkgs git commit logs I see 3-4 people built few
> packages for libicu soname bump. I am not sure why a single person can't
> carry such a few package rebuilds for libicu soname bump.
>Whoever (people names) want to rebuild packages should announce on devel
> list first. Looks like harfbuzz package is picked twice for these rebuilds.
> Both rebuilds happened in within 30 minutes time period.

Your guess is as good as mine. I asked on IRC in #fedora-devel after
my package failed to build on Rawhide and was told that there was a
soname bump for icu and was given an all clear to rebuild it. I then
nphilipp rebuild it after me for whatever reason. I have no idea why
they rebuilt again (maybe they had a reason).

Ideally the person who did the soname bump for icu would have rebuilt
harfbuzz with it (er...@redhat.com). This happens quite often and it's
quite annoying.

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: Why libicu soname bump required harfbuzz package to be built twice?

[Dan Mashal]

On Thu, Feb 13, 2014 at 4:49 AM, Nils Philippsen  wrote:
> sorry for stepping on your toes -- it was late in the evening and there
> were three packages blocking my build, I simply overlooked that harfbuzz
> was rebuilt already (I checked the others in koji and no builds were
> underway).

No problem.
-- 
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: mate-desktop 1.8

[Dan Mashal]

On Mar 14, 2014 7:52 AM, "Brian Millett"  wrote:
>
> What is the prospect of getting mate 1.8 for fedora 20?

Prospect is good.

We're QAing on Rawhide at the moment.

Dan

Sent from my Google Nexus 5
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Packaging changes on NetworkManager? Whither NetworkManager-glib...

[Dan Mashal]

On Fri, Mar 21, 2014 at 9:04 AM, Philip Prindeville
 wrote:
> Did something recently change with the packaging of NetworkManager?
>
> I'm not finding NetworkManager-glib, just NetworkManager-glib-devel:
>
> [root@builder philipp]# yum update
> Loaded plugins: langpacks, refresh-packagekit
> adobe-linux-x86_64   |  951 B 00:00
> rpmfusion-free-updates   | 3.3 kB 00:00
> updates/20/x86_64/metalink   | 9.7 kB 00:00
> updates  | 4.6 kB 00:00
> Resolving Dependencies
> --> Running transaction check
> ---> Package libnm-gtk.x86_64 0:0.9.9.0-7.git20131028.fc20 will be updated
> ---> Package libnm-gtk.x86_64 0:0.9.9.0-8.git20140123.fc20 will be an update
> ---> Package nm-connection-editor.x86_64 0:0.9.9.0-7.git20131028.fc20 will be 
> updated
> ---> Package nm-connection-editor.x86_64 0:0.9.9.0-8.git20140123.fc20 will be 
> an update
> --> Processing Dependency: NetworkManager-glib >= 1:0.9.9.0-26 for package: 
> nm-connection-editor-0.9.9.0-8.git20140123.fc20.x86_64
> --> Finished Dependency Resolution
> Error: Package: nm-connection-editor-0.9.9.0-8.git20140123.fc20.x86_64 
> (updates)
>Requires: NetworkManager-glib >= 1:0.9.9.0-26
>Installed: 
> 1:NetworkManager-glib-0.9.9.0-20.git20131003.fc20.x86_64 (@fedora)
>NetworkManager-glib = 1:0.9.9.0-20.git20131003.fc20
>  You could try using --skip-broken to work around the problem
>  You could try running: rpm -Va --nofiles --nodigest
> [root@builder philipp]# repoquery NetworkManager\*
> NetworkManager-config-server-1:0.9.9.0-31.git20131003.fc20.x86_64
> NetworkManager-devel-1:0.9.9.0-31.git20131003.fc20.i686
> NetworkManager-devel-1:0.9.9.0-31.git20131003.fc20.x86_64
> NetworkManager-glib-devel-1:0.9.9.0-31.git20131003.fc20.i686
> NetworkManager-glib-devel-1:0.9.9.0-31.git20131003.fc20.x86_64
> NetworkManager-iodine-0:0.0.4-2.fc20.x86_64
> NetworkManager-iodine-gnome-0:0.0.4-2.fc20.x86_64
> NetworkManager-l2tp-0:0.9.8.6-1.fc20.x86_64
> NetworkManager-openconnect-0:0.9.8.0-2.fc20.x86_64
> NetworkManager-openswan-0:0.9.8.0-1.fc20.x86_64
> NetworkManager-openvpn-1:0.9.9.0-0.1.git20140128.fc20.x86_64
> NetworkManager-openvpn-gnome-1:0.9.9.0-0.1.git20140128.fc20.x86_64
> NetworkManager-pptp-1:0.9.8.2-3.fc20.x86_64
> NetworkManager-pptp-gnome-1:0.9.8.2-3.fc20.x86_64
> NetworkManager-ssh-0:0.9.2-0.2.20140209git46247c2.fc20.x86_64
> NetworkManager-ssh-gnome-0:0.9.2-0.2.20140209git46247c2.fc20.x86_64
> NetworkManager-vpnc-1:0.9.8.2-2.fc20.x86_64
> NetworkManager-vpnc-gnome-1:0.9.8.2-2.fc20.x86_64
> [root@builder philipp]#

Don't see anything changed.

It's in the repos...

$ yum search NetworkManager-glib
Loaded plugins: fastestmirror, langpacks, refresh-packagekit
Loading mirror speeds from cached hostfile
 * fedora: mirrors.kernel.org
 * rpmfusion-free: mirror.web-ster.com
 * rpmfusion-free-updates: mirror.web-ster.com
 * rpmfusion-free-updates-testing: mirror.web-ster.com
 * rpmfusion-nonfree: mirror.web-ster.com
 * rpmfusion-nonfree-updates: mirror.web-ster.com
 * rpmfusion-nonfree-updates-testing: mirror.web-ster.com
 * updates: mirrors.kernel.org
updates/20/x86_64/pkgtags| 1.0 MB 00:00
=== N/S matched: NetworkManager-glib ===
NetworkManager-glib.i686 : Libraries for adding NetworkManager support to
 : applications that use glib.
NetworkManager-glib.x86_64 : Libraries for adding NetworkManager support to
   : applications that use glib.
NetworkManager-glib-devel.i686 : Header files for adding NetworkManager support
   : to applications that use glib.
NetworkManager-glib-devel.x86_64 : Header files for adding NetworkManager
 : support to applications that use glib.

  Name and summary matches only, use "search all" for everything.

You could always download the rpm from koji.


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: What will happen to XFCE, LXDE, Mate, Cinnemon in Fedora.Next

[Dan Mashal]

On Wed, Mar 19, 2014 at 4:55 AM, Josh Boyer  wrote:
> Any other DE that wants to meet the requirements for Workstation is similarly
> welcome.

So if we meet the "requirements" exactly what happens?

As far as I understand, all MATE would have to do is use gdm as the
display manager. Is that correct?

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: What will happen to XFCE, LXDE, Mate, Cinnemon in Fedora.Next

[Dan Mashal]

On Sat, Mar 22, 2014 at 7:29 PM, Kevin Kofler  wrote:
> Yeah, this idea of having to install GNOME first to be able to install the
> desktop you actually want is totally wacky, and if that is really what we
> recommend to our users, they will run to other distributions (that actually
> support the desktop environment they care about with a dedicated installable
> live image) in droves. Really, almost all users are NOT going to put up with
> this. You need to be really determined to want to run Fedora to jump through
> such ridiculous hoops, most people will just look elsewhere.
>
> And this is really true independently of the desktop environment we are
> talking about (except maybe things such as WM-only setups whose users are
> used to tweaking things by hand anyway).


You always make sense. But nobody listens.

Who the hell wants to install Gnome to install MATE or KDE or XFCE?

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: What will happen to XFCE, LXDE, Mate, Cinnemon in Fedora.Next

[Dan Mashal]

On Tue, Mar 25, 2014 at 1:07 PM, Kevin Kofler  wrote:
> My point is that it must ALSO be possible to install the preferred desktop
> directly, without installing GNOME first.


Exactly this.

Installing MATE from the spin is not exactly the same thing as
installing it from the netinstall or the DVD.

The spin does not include the same packages as the DVD and the
netinstall due to size constraints.

If we can keep the netinstall, which allows people to do exactly this,
then I really could careless what happens with workstation (and I'm
also a happy camper, as I imagine you and many others would be too).

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: rssh (need a sponsor and package from database)

[Dan Mashal]

Hi Alex!

Do you have an srpm we can test with?

Dan

On Wed, Nov 28, 2012 at 4:18 PM, Alexander Aristotle Davis <
aadav...@learn.senecac.on.ca> wrote:

> On 28/11/2012 5:27 PM, Alexander Aristotle Davis wrote:
>
>> Hello
>>
>> I have currently learned that the package rssh has been orphaned and I
>> will like to keep this package alive.
>>
>> I will like to non-deprecated the fedora 17 rssh in the fedora packager
>> database.
>>
>> I would like to work on the security issues.
>>
>> thank you
>>
>> Alex
>>
> I would like to be the maintainer for the rssh for Fedora. I am sending
> this e-mail to seek guidance and also a sponsor. Getting rssh on Fedora i
> will need to fix the security.
>
>
> Alex
> --
> 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: [Help Wanted] Which package provide the System Module for rawhide

[Dan Mashal]

You can also try ' repoquery --whatprovides "pkgconfig(haskell98-2.0.0.1)" '


On Wed, Nov 28, 2012 at 7:13 PM, Ben Boeckel  wrote:

> On Wed, Nov 28, 2012 at 21:45:23 GMT, Jochen Schmitt wrote:
> > Halli,
> >
> > I'm trying to build the kaya package for the rawnide branch of Fedora.
> >
> > Unfortunately, I have got the following error messages during the build
> > process:
> >
> > make -C compiler
> > make[1]: Entering directory `/builddir/build/BUILD/kaya-0.5.2/compiler'
> > /usr/bin/happy -g -a -c ./Parser.y -iParser.out -oParser.hs
> > unused terminals: 2
> > g++ -fPIC -fno-rtti -Wall -O2 -DNDEBUG -Wno-deprecated -I.   -c -o
> repl_load.o repl_load.cc
> > /usr/bin/ghc --make -fglasgow-exts   ./Main.hs repl_load.o -pgml g++ -o
> kayac -i. -odir .
> > on the commandline:
> > Warning: -fglasgow-exts is deprecated: Use individual extensions
> instead
> > Main.hs:31:8:
> > Could not find module `System'
> > It is a member of the hidden package `haskell98-2.0.0.1'.
> > Use -v to see a list of the files searched for.
>
> The compiler found System, but is only using what it was told it was
> allowed to use. It appears as though kaya is using autotools instead of
> cabal. I don't know how to get it to accept haskell98 as a dependency.
>
> > It may be nice, if anyone can tell me in which package I could find
> > the missed System module.
>
> We use ghc-$cabal_name-devel in Fedora, so ghc-haskell98-devel is the
> BuildRequires (but given the error message it's installed).
>
> -- Ben
>
> --
> 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: F18 ARM Beta VFAD - 2012-12-03

[Dan Mashal]

+1

Did you guys do anything for rpi?

Dan

-Original Message-
From: devel-boun...@lists.fedoraproject.org 
[mailto:devel-boun...@lists.fedoraproject.org] On Behalf Of Paul Whalen
Sent: Sunday, December 02, 2012 4:32 PM
To: Fedora ARM
Cc: devel@lists.fedoraproject.org
Subject: F18 ARM Beta VFAD - 2012-12-03


Please join us tomorrow (December 3rd, 2012) at 11am EST in #fedora-arm on 
Freenode for another Fedora ARM VFAD.

There will be a number of pre-created F18 ARM Beta RC1 images available for 
testing, including: Pandaboard, Trimslice, vexpress (QEMU), Highbank and 
Kirkwood.

All help is appreciated and we look forward to your participation. If your 
device is not listed and you would like to offer your assistance, please let us 
know on the list or the IRC.

Thanks,
Paul
--
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: Solicitation: Review Swap

[Dan Mashal]

I'll do it.

Dan

-Original Message-
From: devel-boun...@lists.fedoraproject.org 
[mailto:devel-boun...@lists.fedoraproject.org] On Behalf Of Ralph Bean
Sent: Wednesday, December 05, 2012 11:56 AM
To: devel@lists.fedoraproject.org
Subject: Solicitation: Review Swap

Anyone interested in a package review swap?

python-logutils:
  https://bugzilla.redhat.com/show_bug.cgi?id=884041
-- 
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: Where are we going? (Not a rant)

[Dan Mashal]

This IS a rant. And this includes a few analogies. Some good, some bad.

This is one of the reasons why I chose to run for board.

Nobody really knows where Fedora is going. It's like a too many chefs problem. 

Sometimes Fedora just feels like a bunch of people/SIGs working independent of 
each other (Red Hat included) that eventually come together to make the entire 
distro. 

There needs to be a more concerted to have a direction. There needs to be more 
communication with end users and what they want from Fedora.

For example, the same thing happened with Gnome 3 upstream where a lot of 
developers left the project due to a lack of a real vision or direction.

"Let's just include the latest greatest things that are cool in the Linux 
world." (FIRST on FEATURES) is part of the problem.

"Let's make it look like Ubuntu because Ubuntu is popular" is another 
philosophy that I have seen and I have a problem with.

In addition, LTS won't solve this problem. It goes against everything Fedora 
stands for. A really bad analogy and half joking here: LTS should just be 
renamed "Slackware". If you get the analogy kudos to you.
  
In my opinion the vision needs to be changed. It feels like Fedora has turned 
into Rawhide more than Fedora with 17 and even more so with 18. 

If there was more testing done with Rawhide then I wouldn't feel like the 6 
month release cycle may be a bit too aggressive right now.

I mean the proof is in the pudding. Spherical Cow is almost 3 months late.

Going forward, I would like to look at what the real vision and direction of 
Fedora should be.

In my opinion it should be a distribution that offers the latest software, but 
at the same time keeping stability and compatibility a #1 priority. 

At the end of the day the people that make a distro popular are the users, 
developers and sysadmins.

Sysadmins want things to just work as they have been for the last 15-20 years 
with some minor improvements that don't require them to go back and relearn 
everything. They don't have time for it.

Just my 2 cents.

Dan

-Original Message-
From: devel-boun...@lists.fedoraproject.org 
[mailto:devel-boun...@lists.fedoraproject.org] On Behalf Of Ralf Corsepius
Sent: Friday, December 07, 2012 9:51 PM
To: devel@lists.fedoraproject.org
Subject: Re: Where are we going? (Not a rant)

On 12/08/2012 06:07 AM, M. Edward (Ed) Borasky wrote:
> On Fri, Dec 7, 2012 at 7:26 PM, Arun SAG  wrote:
>>
>>
>> On Fri, Dec 7, 2012 at 5:32 AM, "Jóhann B. Guðmundsson" 
>> 
>> wrote:
>>>
>>>
 If we want to solve this we need to release an Fedora LTS release 
 for our and the potential other user >base that don't have to/want 
 to update every 6 or 12 months.
>>
>>
>>
>> Completely agree on this one. In my day job we started using Fedora 
>> as one of our desktop os. Then support  issues and upgrade cycle 
>> started giving nightmares to corp IT. They are looking at other 
>> avenues now. I really wish there is a LTS release for this awesome distro -  
>> Fedora.
>
> Why does there need to be a long-term support for Fedora?

My primary problem with Fedora isn't "lack of stability", but lack of API/ABI 
and UI-stability/persistence/sustainability between upgrades.

In other words, I can cope with the number of crashes upgrades typically come 
along with, but the number "UI-changes" is what makes Fedora difficult to use 
for me.

> Why not just
> use Red Hat Enterprise Linux?

My view: RHEL is not an alternative to Fedora. CentOS would be a candidate 
alternative to Fedora, however due to the nature of its upstream and its 
upstream target audience (servers) it lacks a lot to be functionally "on par" 
with Fedora.

That said, if I was managing a larger network, I'd likely choose CentOS as base 
OS and harvest Fedora to setup a custom "add-on" repo.

Ralf

--
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: [rawhide] (was Re: Where are we going? (Not a rant))

[Dan Mashal]

Kevin,

This is great and is exactly what I was talking about.

Michael,

For the record, yes I run rawhide.

I have Fedora 14,16,17,18 and 19 running here.

Dan

-Original Message-
From: devel-boun...@lists.fedoraproject.org
[mailto:devel-boun...@lists.fedoraproject.org] On Behalf Of Kevin Fenzi
Sent: Saturday, December 08, 2012 10:18 AM
To: devel@lists.fedoraproject.org
Subject: [rawhide] (was Re: Where are we going? (Not a rant))

On Sat, 08 Dec 2012 17:31:54 +0100
Michael Scherer  wrote:

...snip...
 
> in fact speaking of more testing in rawhide, do you run rawhide ? 
> If not, maybe that's something that is part of the problem, and the 
> first step to a solution. IE, someone should volunteer, and get enough 
> feedback on why people in the fedora community do not run rawhide.
> Once the problems are identified ( even roughly ), then the next step 
> to correct them could be found.
> 
> If the issue "people tell me to not do it", then we should change the 
> message. If the issue is "I did it but this $class_of_bug made me lose 
> months of work", then we should find a way to prevent $class_of_bug, 
> and make it know. And so on.
> 
> But just saying "more tests should be done on rawhide" doesn't make 
> them happen. You cannot force people to run rawhide.

...snip...

Just to highlight this... I intend to switch my laptop to rawhide and run it
and try and gather a like minded group of people to fix things as they break
faster and work on making rawhide more day to day consumable. I'll likely do
this switch over the holidays. 

I'd like to continue to use this list for this effort (with the idea that
increasing signal here would be welcome). 

Some random ideas: 

Create a 'serious rawhide regression tracking bug'. Anyone can nominate bugs
to get added to that and we have a pool of people watching it who can fix or
nag maintainers to fix such issues as a higher priority. We would need to
come up with some critera for acceptance there. 

Help improve autoqa efforts around rawhide and see if we can prevent broken
packages from even promoting into the collection. 

Note directly rawhide related discussion on this list with a [rawhide] so
people can easily pick out workarounds and discussions on day to day rawhide
bugs. 

Try to give maintainers feedback when they push something to rawhide that
doesn't work at all, and help untag builds identified that do this before
they go out in the next compose. 

Other ideas welcome. 

kevin


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

RE: Where are we going? (Not a rant)

[Dan Mashal]

Please don't speak about things you don't understand.

MATE 1.5 is more stable than 1.4 and was pushed for a reason.

Dan

-Original Message-
From: devel-boun...@lists.fedoraproject.org 
[mailto:devel-boun...@lists.fedoraproject.org] On Behalf Of Michael Scherer
Sent: Saturday, December 08, 2012 10:42 AM
To: devel@lists.fedoraproject.org
Subject: Re: Where are we going? (Not a rant)

Le samedi 08 décembre 2012 à 09:32 -0800, Adam Williamson a écrit :
> On Sat, 2012-12-08 at 17:31 +0100, Michael Scherer wrote:
> 
> > > In my opinion the vision needs to be changed. It feels like Fedora 
> > > has turned into Rawhide more than Fedora with 17 and even more so with 18.
> > 
> > You mean like people who are pushing features 
> > (https://fedoraproject.org/wiki/Features/MATE-Desktop ) directly on 
> > all stable releases ( 
> > https://admin.fedoraproject.org/updates/mate-desktop
> > ), despites being frowned upon by the policy :
> > https://fedoraproject.org/wiki/Updates_Policy#All_other_updates , 
> > who was part of the vision that the board proposed :
> > http://fedoraproject.org/wiki/Stable_release_updates_vision ) ?
> 
> In general, adding packages in an update is actually a fairly safe 
> thing to do, as it's very unlikely to disturb any existing setups 
> unless some of those packages somehow provide stuff existing packages 
> might depend on. You have to explicitly install the new packages in 
> order to be in any way 'affected' by them. I thought the updates 
> policy mentioned this, but I can't find it any more.

While I have no problem with pushing new packages to stable release, in this 
case, my point is there is a version upgrade from 1.4 to 1.5 ( but yes, i 
didn't clearly epxressed myself on this part ). Just take for example 
mate-desktop :

https://admin.fedoraproject.org/updates/mate-desktop 

Mate 1.4 is the stable release, 1.5 is the development release, following the 
same version numbering as GNOME. Even if that's not explicitly said, there is 
no 1.5 on the roadmap ( http://wiki.mate-desktop.org/roadmap ), and people keep 
talking of the
1.6 as being the next stable.

For example, 1.5 have been converted from mate-conf to gsettings, from corba to 
dbus, etc. And there is a few deprecated stuff that should disappear sooner or 
later.

So yes, that's pushing a development version on stable release, ie, using 
stable release as rawhide.

Now, if that's good or not is not what I am discussing, it is the contradiction 
between saying "we should not do that", and doing it.

--
Michael Scherer

--
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: dracut hang in %posttrans of Rawhide kernel install?

[Dan Mashal]

On Sat, Jul 13, 2013 at 12:09 AM, Adam Williamson  wrote:
> Hey, folks - I have my desktop on Rawhide now, and on trying to install
> the latest kernel build from Koji today -
> http://koji.fedoraproject.org/koji/buildinfo?buildID=433327 - the yum
> process seemed to hang indefinitely at '  Cleanup:
> kernel-3.10.0-1.fc20.x86_64  3/3' . I
> saw several stuck dracut processes:
>
> root 22006  0.0  0.0 113752  2188 pts/0S+   Jul12
> 0:00 /bin/bash /sbin/dracut
> -f /boot/initramfs-3.11.0-0.rc0.git7.1.fc20.x86_64.img
> 3.11.0-0.rc0.git7.1.fc20.x86_64
>
> all that same command, apparently spawned by:
>
> root 21986  0.0  0.0 113316  1720 pts/0S+   Jul12
> 0:00 /bin/bash /sbin/new-kernel-pkg --package kernel --mkinitrd --dracut
> --depmod --update 3.11.0-0.rc0.git7.1.fc20.x86_64
>
> I left them for several hours, none ever finished. Then I kill'ed them
> all - kill -9 was not necessary - and the yum process completed,
> complaining of:
>
> /sbin/dracut: line 871: /etc/crypttab: No such file or directory
> /sbin/new-kernel-pkg: line 496: 22006 Terminated  $tool
> mkinitrd failed
> warning: %posttrans(kernel-3.11.0-0.rc0.git7.1.fc20.x86_64) scriptlet
> failed, exit status 1
> Non-fatal POSTTRANS scriptlet failure in rpm package
> kernel-3.11.0-0.rc0.git7.1.fc20.x86_64
>
> and indeed, no initramfs existed for the new kernel.
>
> Has anyone else seen this? Any ideas on the cause, for a bug report?

I just upgraded to rawhide with 3.11.0-0.rc0.git7.1.fc20. I didnt get
any issues with dracut but Fedora would not boot. I am currently on
3.10.0-0.rc7.git0.2.fc20:

No dracut or post trans errors when upgrading to this:

Dependencies Resolved


 Package  Arch   Version  Repository
   Size

Installing:
 kernel   x86_64 3.11.0-0.rc0.git7.1.fc20 rawhide  31 M
 kernel-devel x86_64 3.11.0-0.rc0.git7.1.fc20 rawhide 8.4 M

I'll try and build the kernel manually and report back.

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

Re: f18 koji all failed

[dan . mashal]

This is becoming a more regular and annyoing accorance. If you can't get the 
dependencies right please hand it over to a provenpackager.

Dan
Sent from my Verizon Wireless BlackBerry

-Original Message-
From: Christopher Meng 
Sender: devel-boun...@lists.fedoraproject.org
Date: Thu, 25 Jul 2013 10:06:38 
To: Development discussions related to Fedora
Reply-To: Development discussions related to Fedora

Subject: f18 koji all failed

Hi list especially nss guys,

Does anyone know how to fix that?

All builds for f18 are failed.

DEBUG util.py:264:  Error: Package: nss-softokn-3.15.1-1.fc18.x86_64 (build)
DEBUG util.py:264: Requires: libnssutil3.so(NSSUTIL_3.15)(64bit)
DEBUG util.py:264:  Error: Package: nss-softokn-3.15.1-1.fc18.x86_64 (build)
DEBUG util.py:264: Requires: nss-util >= 3.15.1
DEBUG util.py:264: Installing: nss-util-3.14.3-1.fc18.x86_64 (build)
DEBUG util.py:264: nss-util = 3.14.3-1.fc18
DEBUG util.py:264:   You could try using --skip-broken to work around
the problem
DEBUG util.py:264:   You could try running: rpm -Va --nofiles --nodigest
DEBUG util.py:354:  Child return code was: 1

Thanks.

Yours sincerely,
Christopher Meng

Always playing in Fedora Project

http://cicku.me
-- 
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: [Test-Announce] FreeIPA AD Trust improvement Test Day tomorrow, 2013-07-25

[dan . mashal]

Hi Adam,

I apologize if I missed this in your email but Is there a link for Windows 
Administrators as to what versions of AD (2000,2003,200877,2012)  are supported 
and their caveats?
Sent from my Verizon Wireless BlackBerry

-Original Message-
From: Adam Williamson 
Sender: devel-boun...@lists.fedoraproject.org
Date: Wed, 24 Jul 2013 15:59:47 
To: 
Reply-To: t...@lists.fedoraproject.org,
Development discussions related to Fedora

Subject: [Test-Announce] FreeIPA AD Trust improvement Test Day tomorrow,
2013-07-25

Hello,

The FreeIPA team is happy to welcome you to a Fedora Test Day that is
being held on Thursday, July 25th.

We would like to invite you to take part in testing of the upcoming FreeIPA 3.3
release containing 2 major improvements for easier deployment of FreeIPA Active
Directory Trust feature to existing environments:

1) Use POSIX attributes defined in Active Directory [1]

With previous FreeIPA releases, users coming from Active Directory to FreeIPA
managed machines were always assigned POSIX attributes (UID and GID) by
algorithmic mapping.

However, in some deployments, Active Directory users and groups already have
defined custom POSIX attribute values (UID and GID), which may then be
leveraged on Linux machines via other 3rd party Active Directory integration
solutions. Administrator may choose to keep the values to not disrupt file
ownerships.

With FreeIPA 3.3, FreeIPA Active Directory Trust may be configured to use these
attributes when Active Directory user authenticates to Linux machines.


2) Expose POSIX data on legacy systems without recent SSSD

Administrators may have a deployment of machines which cannot use the recent
SSSD with Active Directory Trust support but would still like to be able to
authenticate with Active Directory user to these machines. This may affect for
example older Linux machines, UNIX machines.

With FreeIPA 3.3, Administrator may configure a compatibility LDAP tree which
will contain identities of the Active Directory users to the legacy systems.
These systems may then leverage standard LDAP authentication in this tree
allowing selected Active Directory users to authenticate.


To read more about the Test Day and suggested tests, see the following link:

https://fedoraproject.org/wiki/Test_Day:2013-07-25_AD_trusts_with_POSIX_attributes_in_AD_and_support_for_old_clients

Thank you for your help and participation!

The FreeIPA team

[1] http://www.freeipa.org/page/V3/Use_posix_attributes_defined_in_AD
[2] http://www.freeipa.org/page/V3/Serving_legacy_clients_for_trusts
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora
http://www.happyassassin.net

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

Re: F20 System Wide Change: No Default Sendmail

[dan . mashal]

+1
Sent from my Verizon Wireless BlackBerry

-Original Message-
From: Kevin Fenzi 
Sender: devel-boun...@lists.fedoraproject.org
Date: Wed, 24 Jul 2013 16:12:03 
To: 
Reply-To: Development discussions related to Fedora

Subject: Re: F20 System Wide Change: No Default Sendmail

-- 
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: [Test-Announce] FreeIPA AD Trust improvement Test Day tomorrow, 2013-07-25

[Dan Mashal]

Hi Alex this the reply I was looking for. Anyone still running 2k3 I feel
sorry for. 2k8r2 and beyond is the way to go.

Mainly we would be looking at something simple like having your Ad creds
work on Fedora boxes.

Thanks,
Dan
On Jul 24, 2013 10:44 PM, "Alexander Bokovoy"  wrote:

> On Thu, 25 Jul 2013, dan.mas...@gmail.com wrote:
>
>> Hi Adam,
>>
>> I apologize if I missed this in your email but Is there a link for
>> Windows Administrators as to what versions of AD
>> (2000,2003,200877,2012)  are supported and their caveats?
>>
> http://www.freeipa.org/page/**Howto/IPAv3_AD_trust_setup#**Prerequisites
> covers basic requirements. FreeIPA 3.x supports Windows Server 2008 and
> above, we are testing regularly with 2008R2 and 2012.
>
> This is due to the fact that the requirement for cross-forest trusts is
> functional level 2008 or above. However, it is possible to establish a
> trust between a FreeIPA server and Windows Server 2003 R2, with limited
> functionality. However, this is unsupported, highly experimental and
> of very limited value. Specifically, in this setup AES encryption is not
> supported (only RC4 encryption is available).
>
> In order to establish a trust between a FreeIPA server and a Windows
> Server 2003 R2, you need to raise the forest functional level to Windows
> Server 2003. To do this, open 'Active Directory Domains and Trusts'
> snap-in and right-click on 'Active Directory Domains and Trusts' root in
> the left pane. Then select 'Raise forest functional level ...' and use
> 'Windows Server 2003' as the level to raise.
>
> This action needs to be done before establishing a trust with the
> 'ipa trust-add' command. The rest of the setup is identical to that of
> Windows Server 2008 R2.
>
>
>  Sent from my Verizon Wireless BlackBerry
>>
>> -Original Message-
>> From: Adam Williamson 
>> Sender: 
>> devel-bounces@lists.**fedoraproject.org
>> Date: Wed, 24 Jul 2013 15:59:47
>> To: 
>> 
>> >
>> Reply-To: t...@lists.fedoraproject.org,
>> Development discussions related to Fedora
>> 
>> Subject: [Test-Announce] FreeIPA AD Trust improvement Test Day tomorrow,
>> 2013-07-25
>>
>> Hello,
>>
>> The FreeIPA team is happy to welcome you to a Fedora Test Day that is
>> being held on Thursday, July 25th.
>>
>> We would like to invite you to take part in testing of the upcoming
>> FreeIPA 3.3
>> release containing 2 major improvements for easier deployment of FreeIPA
>> Active
>> Directory Trust feature to existing environments:
>>
>> 1) Use POSIX attributes defined in Active Directory [1]
>>
>> With previous FreeIPA releases, users coming from Active Directory to
>> FreeIPA
>> managed machines were always assigned POSIX attributes (UID and GID) by
>> algorithmic mapping.
>>
>> However, in some deployments, Active Directory users and groups already
>> have
>> defined custom POSIX attribute values (UID and GID), which may then be
>> leveraged on Linux machines via other 3rd party Active Directory
>> integration
>> solutions. Administrator may choose to keep the values to not disrupt file
>> ownerships.
>>
>> With FreeIPA 3.3, FreeIPA Active Directory Trust may be configured to use
>> these
>> attributes when Active Directory user authenticates to Linux machines.
>>
>>
>> 2) Expose POSIX data on legacy systems without recent SSSD
>>
>> Administrators may have a deployment of machines which cannot use the
>> recent
>> SSSD with Active Directory Trust support but would still like to be able
>> to
>> authenticate with Active Directory user to these machines. This may
>> affect for
>> example older Linux machines, UNIX machines.
>>
>> With FreeIPA 3.3, Administrator may configure a compatibility LDAP tree
>> which
>> will contain identities of the Active Directory users to the legacy
>> systems.
>> These systems may then leverage standard LDAP authentication in this tree
>> allowing selected Active Directory users to authenticate.
>>
>>
>> To read more about the Test Day and suggested tests, see the following
>> link:
>>
>> https://fedoraproject.org/**wiki/Test_Day:2013-07-25_AD_**
>> trusts_with_POSIX_attributes_**in_AD_and_support_for_old_**clients
>>
>> Thank you for your help and participation!
>>
>> The FreeIPA team
>>
>> [1] 
>> http://www.freeipa.org/page/**V3/Use_posix_attributes_**defined_in_AD
>> [2] 
>> http://www.freeipa.org/page/**V3/Serving_legacy_clients_for_**trusts
>> --
>> Adam Williamson
>> Fedora QA Community Monkey
>> IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora
>> http://www.happyassassin.net
>>
>> __**_
>> test-announce mailing list
>> test-announce@lists.**fedoraproject.or

Re: Summary of accepted Fedora 20 Changes - week 30

[Dan Mashal]

On Thu, Jul 25, 2013 at 4:20 PM, Toshio Kuratomi  wrote:
> On Thu, Jul 25, 2013 at 05:09:54PM -0600, Stephen John Smoogen wrote:
>> On 25 July 2013 16:59, Billy Crook  wrote:
>> > On Thu, Jul 25, 2013 at 3:36 PM, Bastien Nocera  wrote:
>> >> Given the amount of time that he spent on the mailing-list fighting for 
>> >> those features, then it looks like a waste of time, that work has been 
>> >> done.
>> >
>> > Unfeatures technically.  He wanted to remove features from the Default
>> > spin.   Subtracting functionality is not a feature.  He wanted an
>> > unfeature.
>> >
>>
>> No he wanted out of the default install. We have a badly defined
>> naming scheme which is causing confusion:
>>
>> default install -> what you get when you put the DVD in and do a click
>> through install.
>> default spin -> The GNOME desktop livecd.
>>
>> Spins are managed by their respective "teams":
>> default has been GNOME and managed by GNOME sig
>> kde is managed by KDE sig
>> xfce is managed by XFCE sig
>> etc etc
>>
>> So I would say that the GNOME team is within its rights in managing
>> its spin. Whether it is named default etc is someone else's problem.
>>
> This has come up before and I think it's just plain unclear :-(
>
> The problem is that the desktop spin and the default spin are kinda two
> different roles but they are occupied by the same Product.  In browsing old
> tickets, I see some times when fesco has decided the default spin didn't
> have to do what other other things did and sometimes when fesco said they
> did.  AFAICS, there's been no generalized policy put into place in regards
> to this.  So it's something that is decided on in every case where it comes
> up.
>
> I don't think anyone thought they were doing anything wrong by making the
> change in the desktop spin but because the desktop spin has more than one
> owner, I've sent it back to FESCo to vote on whether allowing this change
> there is something we intended or not.
>
> (/me notes that if mattdm's Ring 1 was defined, this might be somewhat
> easier to decide upon.  If sendmail was in Ring 1 it would be an expected
> part of the Fedora Platform.  Anything general purpose and carrying the name
> Fedora would probably have to carry it as well.  If sendmail was in Ring 2,
> it probably would be fine to choose whether to install it or not as it
> wasn't a guaranteed part of the BaseOS. [You could also
> s@sendmail@/usr/bin/sendmail@ in that analysis if you so chose])
>
> -Toshio
>
> --
> devel mailing list
> devel@lists.fedoraproject.org
> https://admin.fedoraproject.org/mailman/listinfo/devel

That was done here by Ray:

https://git.fedorahosted.org/cgit/spin-kickstarts.git/commit/?id=279c21441cdacb1d548dc1f1b39acc2882ef4024


And good for them.

As far as the MATE spin goes I have no plans to do this.



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

Re: Summary of accepted Fedora 20 Changes - week 30

[Dan Mashal]

On Thu, Jul 25, 2013 at 4:47 PM, Lennart Poettering
 wrote:
> On Thu, 25.07.13 17:59, Billy Crook (billycr...@gmail.com) wrote:
>
>> After some reasonable dialog on the issue FESCo meeting, it was clear
>> he wasn't going to immediately get exactly what he wanted without any
>> challenge.  So he departed the meeting. In his absence, FESCo decided
>> to compromise and remove from @core, but not @standard.
>
> "He" didn't depart from the meeting. He was at dinner with friends and
> only had a peek every now and then on his phone while having some
> delicious Japanese food [1] which turned out to be much more fun than
> that meeting.
>
> Lennart
>
> [1] "Onsen", in Berlin-Friedrichshain (recommended)
>
> --
> Lennart Poettering - Red Hat, Inc.



Your attitude is atrocious. Go start your own distro. You already
ruined ours with systemd and PulseAudio. Stop acting like you own
everything. We have boards, comittees, and plenty of intelligent
people to decide things.

Had you proposed to replace sendmail with postfix that might have been
an intelligent argument.

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

Re: Summary of accepted Fedora 20 Changes - week 30

[Dan Mashal]

On Thu, Jul 25, 2013 at 6:14 PM, Rahul Sundaram  wrote:
> Hi
>
>
> On Thu, Jul 25, 2013 at 8:42 PM, Dan Mashal
>>
>>
>> Your attitude is atrocious. Go start your own distro. You already
>> ruined ours with systemd and PulseAudio. Stop acting like you own
>> everything. We have boards, comittees, and plenty of intelligent
>> people to decide things.
>
>
> Please don't attack a fellow contributor because he has a different opinion
> from yours.   The same intelligent people have decided to approve PulseAudio
> and systemd as well.

I think you missed my point, but you got the gist. We have way more
important things to discuss than sendmail.

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

Re: Summary of accepted Fedora 20 Changes - week 30

[Dan Mashal]

On Thu, Jul 25, 2013 at 6:33 PM, Chris Murphy  wrote:
>
> On Jul 25, 2013, at 6:42 PM, Dan Mashal  wrote:
>
>> On Thu, Jul 25, 2013 at 4:47 PM, Lennart Poettering
>>  wrote:
>>>
>>> "He" didn't depart from the meeting. He was at dinner with friends and
>>> only had a peek every now and then on his phone while having some
>>> delicious Japanese food [1] which turned out to be much more fun than
>>> that meeting.
>>
>>
>> Your attitude is atrocious.
>
> Opinions are funny things. I think his attitude is amusing as well as 
> informative. If Onsen does some things other than sushi (i.e. food that uses 
> names of things that by most all DNA testing are actually differently named 
> things) I should like to try it next time I'm in Berlin. Oh who am I kidding, 
> I probably will eat wrong named things anyway.

I didn't find it funny. I found it arrogant.

> Right, because when a decaying concept from the pleistocene by default only 
> increases boot times and consumes limited resources (it certainly doesn't do 
> anything useful out of the box), the intelligent thing to do is rearrange the 
> deck chairs.
>
> Deprecation is to a distribution, as fire is to a forest. It keeps them 
> healthy instead of cinder boxes.
>
> Really so much whining over having to yum install something? I think this 
> thread is a sufficiently tenderized horse.

Why not build it into some other component then?

I already to yum install too many things to get a working system.

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

Obsoleting ConsoleKit once and for all

[Dan Mashal]

Hi,

After discussion on #fedora-devel, my MATE co-maintainer raveit65,
Kalev, Misc, and previous conversations with Rex, I am ready to retire
ConsoleKit.

LightDM seems to fully support systemd-logind.


However I have no rights to commit to systemd.

Lennart or any proven packager please add the following obsoletes tag
to systemd:

obsoletes: ConsoleKit
obsoletes: ConsoleKit-x11
obsoletes: ConsoleKit-libs

I will take care of testing, retiring and blocking the package.

Thanks,
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: Obsoleting ConsoleKit once and for all

[Dan Mashal]

On Sun, Jul 28, 2013 at 4:24 AM, Christoph Wickert
 wrote:
> Am Sonntag, den 28.07.2013, 04:03 -0700 schrieb Dan Mashal:
>> Hi,
>>
>> After discussion on #fedora-devel, my MATE co-maintainer raveit65,
>> Kalev, Misc, and previous conversations with Rex, I am ready to retire
>> ConsoleKit.
>
> Others are not. I am pretty sure ConsoleKit is still needed by LXDM and
> slim as they don't support systemd-logind and by pcmamfm and thunar for
> handling permissions of removable devices.
>
>> LightDM seems to fully support systemd-logind.
>>
>>
>> However I have no rights to commit to systemd.
>>
>> Lennart or any proven packager please add the following obsoletes tag
>> to systemd:
>>
>> obsoletes: ConsoleKit
>> obsoletes: ConsoleKit-x11
>> obsoletes: ConsoleKit-libs
>
> I don't see why we need to obsolete it at this point. Sure, at some
> point it needs to die, but your approach doesn't seem well thought
> through.
>
>> I will take care of testing, retiring and blocking the package.
>
> Are you planning other desktops, too? And what about window-managers?

Hi Chris,

I took ownership of ConsoleKit because I saw what a disaster it would
be to retire/block it when Lennart wanted to. I didnt realize so many
other things required. By all means add yourself as co maintainer and
lets work together to get this resolved.

For all I care the package can live until Fedora 30.

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: Obsoleting ConsoleKit once and for all

[Dan Mashal]

On Wed, Jul 31, 2013 at 3:02 AM, Johannes Lips  wrote:
> On Tue, Jul 30, 2013 at 11:59 PM, Lennart Poettering 
> wrote:
>>
>> BOn Tue, 30.07.13 16:14, Dan Williams (d...@redhat.com) wrote:
>>
>> > On Tue, 2013-07-30 at 23:03 +0200, Lars Seipel wrote:
>> > > On Tue, Jul 30, 2013 at 04:28:55PM +0200, Christoph Wickert wrote:
>> > > > thunar and pcmanfm are file managers and require ConsoleKit for
>> > > > handling
>> > > > removable storage.
>> > >
>> > > Are you sure you aren't confusing this with something? HAL maybe?
>> >
>> > There's some interaction with ConsoleKit to ensure that the removable
>> >1;3406;0c storage is tied to a specific session so that the logged-in
>> > user can
>> > actually modify their USB drive.  Otherwise it's only accessible to
>> > 'root'.
>> >
>> > So yes, something *else* (HAL, udisks, etc) actually handles the
>> > mounting, but there's some other components involved in permissions and
>> > mount location, and that's where ConsoleKit helps out.
>>
>> But that's stuff that is hidden beneath udev/udisks not sure why a file
>> manager needs to know that...
>
> There is some stuff regarding thunar on this blog post by one of the thunar
> developers:
> http://gezeiten.org/post/2011/01/Xfce-4.8-on-BSD-flavors
>

Chris,

Please file a bug with various upstreams (if you haven't already) to
switch to udisks so we can retire ConsoleKit.

MATE no longer has any use for it and neither should XFCE. I only
picked up as a knee jerk reaction.  It shouldn't be that hard for
upstreams to move away from it. It wasn't for us.

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: Orphaning Blueman

[Dan Mashal]

On Thu, Aug 1, 2013 at 10:52 AM, Juan Rodriguez
 wrote:
> Hi Devel!
>
> I've recently been approached about one of the packages I maintain, Blueman,
> an alternative Bluetooth Manager.
>
> At the time I packaged it, it was actively being developed, however
> development has stopped for over a year [1]. The project's domain expired
> too. [2]
>
> The package has been continuously piling up bugs. Some of which I can fix
> (Packaging) but most of which I can't (Actual crashes).
>
> Given that both the KDE Bluetooth Manager and the Gnome Bluetooth Manager
> both work wonderfully, I'm orphaning the package.
>
> [1] https://code.launchpad.net/~chihchun/blueman/blueman-lp1087890
> [2] http://blueman-project.org/
>

Have you tried to contact upstream?

Why not just retire and block it at the same time if it is dead

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: BlueZ Status in Fedora.

[Dan Mashal]

On Tue, Aug 13, 2013 at 6:44 AM, Kalev Lember  wrote:
> On 08/13/2013 02:28 PM, Rave it wrote:
>> Other probs are:
>> 1. gnome-bluetooth upstream has removed the fallback icon for autostart in 
>> session,...no systray icon in other DE than gnome itself.
>> 2. if gnome revert this change in upstream 'OnlyShowIn=MATE" needs to be 
>> added.
>> 3. Also runtime dependencies needs to be checked, we don't want to be 
>> install more gnome as necessary in mate.
>
> I discussed this with raveit65 on IRC and we found a way forward with this.
>
> The issue with MATE switching from mate-bluetooth to gnome-bluetooth is
> that gnome-bluetooth no longer ships the panel applet that MATE needs.
> This was removed from gnome-bluetooth in commit
> https://git.gnome.org/browse/gnome-bluetooth/commit/?id=c54e93e4310342ffce13e15b5a1b9a6ee9500a05
> when GNOME stopped shipping the fallback mode.
>
> However, the panel applet code is pretty self contained. The way to make
> it work would be to move the panel applet code to a separate package. It
> could be called mate-panel-bluetooth or gnome-panel-bluetooth or
> similar. The package would then include the panel applet files that are
> no longer part of gnome-bluetooth, and link with libgnome-bluetooth.
>
> Anyone interested in teaming up with raveit65 to create a separate
> package for this?
>
> This package might also be useful for XFCE/LXDE.
>
> In any case, the best way forward is probably to go on with importing
> BlueZ 5 into rawhide so that it can be used as a development platform.
> Otherwise it's pretty hard to test the new code.
>
> --
> Kalev
> --
> devel mailing list
> devel@lists.fedoraproject.org
> https://admin.fedoraproject.org/mailman/listinfo/devel
> Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct


Could we reverse this commit? Everyone wins.

Otherwise we are looking at possibly reforking gnome-bluetooth at this
point in time.

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

retiring gpointing-device-settings

[Dan Mashal]

The package currently fails to build and upstream appears to be dead.
Even the working package does not save settings.

https://wiki.gnome.org/GPointingDeviceSettings

https://git.gnome.org/browse/gpointing-device-settings/

Problem: This is a useful package that controls touchpad settings.

I have tried xfce4-mouse-settings from xfce4-settings but this
obviously doesn't work since XFCE uses xfconf.

Does anyone have any alternatives or suggestions?

Otherwise we are losing some important functionality for GTK based desktops.

One alternative is to fork xfce4-settings and migrate it to gsettings.

Any feedback welcome.

Thanks,
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: BlueZ Status in Fedora.

[Dan Mashal]

On Thu, Aug 15, 2013 at 10:55 AM, Lars Seipel  wrote:
> On Wed, Aug 14, 2013 at 08:37:19PM -0700, Dan Mashal wrote:
>> Otherwise we are looking at possibly reforking gnome-bluetooth at this
>> point in time.
>
> Reforking? And then wait until the bitrot sets in again? ;-)
>
> Can't you just use gnome-bluetooth proper and resurrect the panel icon
> stuff like Kalev proposed?

Not so simple as reverting a commit. Must discuss with upstream.

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: BlueZ Status in Fedora.

[Dan Mashal]

On Thu, Aug 15, 2013 at 3:04 PM, Dan Mashal  wrote:
> On Thu, Aug 15, 2013 at 10:55 AM, Lars Seipel  wrote:
>> On Wed, Aug 14, 2013 at 08:37:19PM -0700, Dan Mashal wrote:
>>> Otherwise we are looking at possibly reforking gnome-bluetooth at this
>>> point in time.
>>
>> Reforking? And then wait until the bitrot sets in again? ;-)
>>
>> Can't you just use gnome-bluetooth proper and resurrect the panel icon
>> stuff like Kalev proposed?
>
> Not so simple as reverting a commit. Must discuss with upstream.
>
> Dan


Also as Wolfgang (comaintainer for MATE) said and I personally would
like to reiterate:

"3. Also runtime dependencies needs to be checked, we don't want to be
install more gnome as necessary in mate."

The whole point of forking to be dependant on gnome upstream as little
as possible.

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

[Dan Mashal]

On Thu, Aug 15, 2013 at 3:38 PM, T.C. Hollingsworth
 wrote:
> On Thu, Aug 15, 2013 at 2:02 PM, Orion Poplawski  wrote:
>> Thanks.  Turns out ckeditor also had a raw .fla file.  I don't know if any
>> package would have a .fla without a .swf, but it might be worth checking
>> for.
>
> Thanks for pointing that out!
>
> .fla files are source files, so it's not strictly against the guidelines to
> include them.  But, they're pretty useless to end users. ;-)
>
> So, here's the list of packages that contain .fla files:
>
> brummbq owncloud
> echevemaster python-django-ckeditor
> ke4qqq php-simplepie
> limb gallery3
> orion ckeditor
> sundaram evas-generic-loaders
> topdog dojo
>
> -T.C.

Forgive me if I sound rude and correct me if I'm wrong, but arent the
free versions of Flash pretty useless as well?

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

[Dan Mashal]

On Thu, Aug 15, 2013 at 3:49 PM, Ananda Samaddar  wrote:
> On Thu, 15 Aug 2013 15:46:36 -0700
> Yes  they are.  Flash is slowly dying though, only to be replaced by DRM
> in html5.  Out of the frying pan...
>
> Ananda
> --
> devel mailing list
> devel@lists.fedoraproject.org
> https://admin.fedoraproject.org/mailman/listinfo/devel
> Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Adobe flash and Google Chrome flash still work, looking at your domain
name makes me wonder.. does Opera bundle flash a la Chrome on Linux?

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: retiring gpointing-device-settings

[Dan Mashal]

On Wed, Aug 14, 2013 at 8:54 PM, Dan Mashal  wrote:
> The package currently fails to build and upstream appears to be dead.
> Even the working package does not save settings.
>
> https://wiki.gnome.org/GPointingDeviceSettings
>
> https://git.gnome.org/browse/gpointing-device-settings/
>
> Problem: This is a useful package that controls touchpad settings.
>
> I have tried xfce4-mouse-settings from xfce4-settings but this
> obviously doesn't work since XFCE uses xfconf.
>
> Does anyone have any alternatives or suggestions?
>
> Otherwise we are losing some important functionality for GTK based desktops.
>
> One alternative is to fork xfce4-settings and migrate it to gsettings.
>
> Any feedback welcome.

Hi the package has been officially retired and will be blocked.

The fork of it known as "mate-mouse-properties" works wonderfully (and
should work on all GTK/gsettings compliant DEs) but is part of the
mate-control-center package.

We are working on splitting out the binary for those that want to use it.

Thanks,
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: Orphaned: libgnomecups

[Dan Mashal]

On Fri, Aug 16, 2013 at 1:35 AM, Jiri Popelka  wrote:
> On 08/16/2013 01:54 AM, Peter Robinson wrote:
>>
>> On Thu, Aug 15, 2013 at 6:39 PM, Bill Nottingham 
>> wrote:
>>>
>>> Underlying dep of libgnomeprint22/libgnomeprintui22, which is used by a
>>> few
>>> end-user things (gpp, conglomerate, gnome-genius), but nothing I need for
>>> now, so giving up ownership.
>>
>>
>> Isn't it just time we killed the old gnome printing infra once and for
>> all? It was marked EOL years ago that the packages if they're remotely
>> actively maintained should have migrated by now.
>
>
> +1,
> libgnomecups even doesn't build against cups-1.6 in F19/rawhide
> (https://bugzilla.redhat.com/show_bug.cgi?id=841841)
>
> --
> Jiri
>
> --
> devel mailing list
> devel@lists.fedoraproject.org
> https://admin.fedoraproject.org/mailman/listinfo/devel
> Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct


Taken.
-- 
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: doxygen directory reference files

[Dan Mashal]

On Fri, Aug 16, 2013 at 3:31 PM, Orion Poplawski  wrote:
> doxygen (at least for some packages) is creating files like:
>
> _builddir_build_BUILD_torque-3.0.4_src_drmaa_src_.3
>
> that have contents like:
>
> .TH "src Directory Reference" 3 "Fri Aug 16 2013" "Version 3.0.4" "torque"
> \" -*- nroff -*-
> .ad l
> .nh
> .SH NAME
> src Directory Reference \-
> .SH SYNOPSIS
> .br
> .PP
> .SS "Files"
> 
>
>
> A number of packages are shipping them (see below).  Is there some way to
> prevent them from being built?
>
> # repoquery --whatprovides /usr/share/man/man3/_builddir_build\* --source |
> sort -u
> LogService-2.8.0-4.fc20.src.rpm
> QuantLib-1.2.1-6.fc20.src.rpm
> SILLY-0.1.0-16.fc20.src.rpm
> dmlite-0.6.1-3.fc20.src.rpm
> ecore-1.7.7-2.fc20.src.rpm
> evas-1.7.7-2.fc20.src.rpm
> globus-callout-2.2-7.fc20.src.rpm
> globus-common-14.9-6.fc20.src.rpm
> globus-gass-transfer-7.2-7.fc20.src.rpm
> globus-gsi-callback-4.4-5.fc20.src.rpm
> globus-gsi-cert-utils-8.3-7.fc20.src.rpm
> globus-gsi-credential-5.3-7.fc20.src.rpm
> globus-gsi-openssl-error-2.1-8.fc20.src.rpm
> globus-gsi-proxy-core-6.2-7.fc20.src.rpm
> globus-gsi-proxy-ssl-4.1-8.fc20.src.rpm
> globus-gsi-sysconfig-5.3-6.fc20.src.rpm
> globus-gssapi-error-4.1-8.fc20.src.rpm
> globus-gssapi-gsi-10.7-6.fc20.src.rpm
> globus-openssl-module-3.2-8.fc20.src.rpm
> globus-rls-client-5.2-12.fc20.src.rpm
> globus-xio-3.3-7.fc20.src.rpm
> libcaca-0.99-0.18.beta17.fc20.src.rpm
> libeXosip2-3.6.0-7.fc20.src.rpm
> libeina-1.7.7-2.fc20.src.rpm
> libftdi-0.20-5.fc20.src.rpm
> liblo-0.27-2.fc20.src.rpm
> libpgf-6.12.24-5.fc20.src.rpm
>

For ecore and evas I can look at disabling docs or just removing the
file outright.

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: doxygen directory reference files

[Dan Mashal]

On Fri, Aug 16, 2013 at 4:16 PM, Dan Mashal  wrote:
> On Fri, Aug 16, 2013 at 3:31 PM, Orion Poplawski  wrote:
>> doxygen (at least for some packages) is creating files like:
>>
>> _builddir_build_BUILD_torque-3.0.4_src_drmaa_src_.3
>>
>> that have contents like:
>>
>> .TH "src Directory Reference" 3 "Fri Aug 16 2013" "Version 3.0.4" "torque"
>> \" -*- nroff -*-
>> .ad l
>> .nh
>> .SH NAME
>> src Directory Reference \-
>> .SH SYNOPSIS
>> .br
>> .PP
>> .SS "Files"
>> 
>>
>>
>> A number of packages are shipping them (see below).  Is there some way to
>> prevent them from being built?
>>
>> # repoquery --whatprovides /usr/share/man/man3/_builddir_build\* --source |
>> sort -u
>> LogService-2.8.0-4.fc20.src.rpm
>> QuantLib-1.2.1-6.fc20.src.rpm
>> SILLY-0.1.0-16.fc20.src.rpm
>> dmlite-0.6.1-3.fc20.src.rpm
>> ecore-1.7.7-2.fc20.src.rpm
>> evas-1.7.7-2.fc20.src.rpm
>> globus-callout-2.2-7.fc20.src.rpm
>> globus-common-14.9-6.fc20.src.rpm
>> globus-gass-transfer-7.2-7.fc20.src.rpm
>> globus-gsi-callback-4.4-5.fc20.src.rpm
>> globus-gsi-cert-utils-8.3-7.fc20.src.rpm
>> globus-gsi-credential-5.3-7.fc20.src.rpm
>> globus-gsi-openssl-error-2.1-8.fc20.src.rpm
>> globus-gsi-proxy-core-6.2-7.fc20.src.rpm
>> globus-gsi-proxy-ssl-4.1-8.fc20.src.rpm
>> globus-gsi-sysconfig-5.3-6.fc20.src.rpm
>> globus-gssapi-error-4.1-8.fc20.src.rpm
>> globus-gssapi-gsi-10.7-6.fc20.src.rpm
>> globus-openssl-module-3.2-8.fc20.src.rpm
>> globus-rls-client-5.2-12.fc20.src.rpm
>> globus-xio-3.3-7.fc20.src.rpm
>> libcaca-0.99-0.18.beta17.fc20.src.rpm
>> libeXosip2-3.6.0-7.fc20.src.rpm
>> libeina-1.7.7-2.fc20.src.rpm
>> libftdi-0.20-5.fc20.src.rpm
>> liblo-0.27-2.fc20.src.rpm
>> libpgf-6.12.24-5.fc20.src.rpm
>>
>
> For ecore and evas I can look at disabling docs or just removing the
> file outright.
>
> Dan

Same for libeina.
-- 
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: BlueZ Status in Fedora.

[dan . mashal]

We've go the resources.

An entire DE doesn't appear out of nowhere.

Just trying to determine how to proceed.

Dan
Sent from my Verizon Wireless BlackBerry

-Original Message-
From: Adam Williamson 
Sender: devel-boun...@lists.fedoraproject.org
Date: Fri, 16 Aug 2013 17:19:27 
To: Development discussions related to Fedora
Reply-To: Development discussions related to Fedora

Subject: Re: BlueZ Status in Fedora.

On Thu, 2013-08-15 at 15:10 -0700, Dan Mashal wrote:
> On Thu, Aug 15, 2013 at 3:04 PM, Dan Mashal  wrote:
> > On Thu, Aug 15, 2013 at 10:55 AM, Lars Seipel  wrote:
> >> On Wed, Aug 14, 2013 at 08:37:19PM -0700, Dan Mashal wrote:
> >>> Otherwise we are looking at possibly reforking gnome-bluetooth at this
> >>> point in time.
> >>
> >> Reforking? And then wait until the bitrot sets in again? ;-)
> >>
> >> Can't you just use gnome-bluetooth proper and resurrect the panel icon
> >> stuff like Kalev proposed?
> >
> > Not so simple as reverting a commit. Must discuss with upstream.
> >
> > Dan
> 
> 
> Also as Wolfgang (comaintainer for MATE) said and I personally would
> like to reiterate:
> 
> "3. Also runtime dependencies needs to be checked, we don't want to be
> install more gnome as necessary in mate."
> 
> The whole point of forking to be dependant on gnome upstream as little
> as possible.

If you want to be independent of GNOME upstream, you need the resources
to keep up to date with upstream changes in a timely fashion. It's not
going to work for Fedora to delay moving to new upstream releases of
major components for entire release cycles because MATE didn't have the
resources to be ready for the change.
-- 
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 Code of Conduct: http://fedoraproject.org/code-of-conduct
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Retiring and blocking the following mate packages

[Dan Mashal]

Hi. These packages were obsoleted in MATE 1.6 along with the migration
to gsettings.

libmate
libmateui
libmatecanvas
libmatecomponent
libatecomponentui
libmatenotify
mate-conf (compiz no longer relies on mate-conf)
mate-conf-editor
mate-doc-utils (to be retired in F21 with MATE 1.8)
mate-keyring (to be retired in F21 with MATE 1.8 and will use gnome-keyring)
mate-mime-data
mate-vfs

Regarding mate-bluetooth we may take Kalev's advice and just create an
applet or use the XFC E applet which is currently still premature.

I have my own opinions on what should be done besides what I've
already stated the main one.

Just FYI

Thanks,
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: F20 release name election?

[Dan Mashal]

On Thu, Aug 22, 2013 at 12:43 PM, Stephen John Smoogen  wrote:
>
>
>
> On 22 August 2013 13:31, Michael Schwendt  wrote:
>>
>> https://admin.fedoraproject.org/voting/about/relnamef20
>>
>> Is this thing for real?
>>
>> https://admin.fedoraproject.org/voting/
>> says the End Date is 2013-08-23 23:59:59.
>>
>> Where has it been announced this time?
>> There's nothing in the archives for announce and devel-announce list.
>
>
>
> It didn't get announced but is real. Due to the lack of announcement it is
> being extended a week til 2013-08-30 23:59:59 (the Board ok'd that in
> today's meeting.) and an announcement will go out. [I guess no one read my
> blog :)]
>
>
> --
> Stephen J Smoogen.
>
>
> --
> devel mailing list
> devel@lists.fedoraproject.org
> https://admin.fedoraproject.org/mailman/listinfo/devel
> Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

What happened to naming 20 in honor of Seth?

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: F20 release name election?

[Dan Mashal]

On Thu, Aug 22, 2013 at 1:50 PM, Stephen John Smoogen  wrote:
> I believe that it was decided that like had been done in the past, this
> release would be dedicated to Seth Vidal, but not named after him as Seth
> hated released names with a white hot passion of 10,000 supernovas. [Of
> course he would probably still laugh if the release was named Vidalia Onion]
>

Yes I remember his hatred of release names being thrown around, and it
was suggested that we just call it "20", and that might please the
gods.

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: F20 release name election?

[Dan Mashal]

On Thu, Aug 22, 2013 at 4:44 PM, Chris Murphy  wrote:
> *smack own forehead* I like that better than the other options also. For me, 
> one extra point for Vidalia onion over "20".
>
> Heck I like "Crazy Train" based on a recent Matthew Miller assertion.
>
> Assuming there can be no late add ins though, the overwhelmingly obvious 
> correct answer is Heisenbug. I attract more Heisenbugs than anyone I know. 
> It's funny. It's true, they totally exist. And (sorry!) all the other options 
> are snoozers. Now, had it been "Santa's reindeer" that might have made it a 
> *little* less obvious, what the correct answer is.


How about no release name, just this one time. In his honor? I love
release names, and while I didn't know Seth very well personally,
probably the main reason I use Fedora/RHEL/CentOS is because of yum.
He deserves the honor in my opinion. The choices up there are lame.

If i I had to choose I guess I'd vote for Santa Claus but this is ridiculous.

With all due respect can someone please explain to me how this release
is "dedicated" to Mr. Vidal?

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: F20 release name election?

[Dan Mashal]

On Thu, Aug 22, 2013 at 5:12 PM, Josh Boyer  wrote:
> On Thu, Aug 22, 2013 at 8:05 PM, Dan Mashal  wrote:
>
> The choices are what the community came up with.  At this point, that
> is what we have to chose from.
>
> I'm not necessarily disagreeing, but there are essentially two camps
> right now.  Those that don't care about release names one bit (like
> me), and those that do.  If those that do care want better names,
> they'll need to work harder at creating meaningful suggestions.
>
> The Board has an open ticket on the naming process.  We're working
> through it now, but "no release names" isn't an immediate option
> because the last time we proposed that the community vote showed names
> were still desired.  Hopefully we'll resolve the ticket shortly and
> explain how naming needs to work in the future.
>
>
> It will be dedicated in the release announcement.  Perhaps someone
> might add something to the download page on the website as well.
>

Hi Josh,

Thanks for replying.

I personally LOVE release names. However, I feel that we should forego
it this one release.

What is the point of the board of the community decides everything?

We all know that there needs to be a tough decision made by the board,
and it's not release names vs no release names. For me it's about
doing what Seth would have wanted, whether he was close to us or not,
whether he he touched us or knew us or cared about personally.

Please seriously consider the following and have a BOARD vote on it:

On Thu, Aug 22, 2013 at 5:23 PM, Chris Murphy  wrote:
>
> On Aug 22, 2013, at 6:05 PM, Dan Mashal  wrote:
>>
>> How about no release name, just this one time. In his honor?
>
> I'd back no release name for 20 with 8 points and 0 for everything else, if 
> it's an option, and in particular if the marketing includes to the effect of: 
> "Fedora 20 is nameless in honor of Seth Vidal who hated release names with 
> the white hot passion of 10,000 supernovas."
>
>
> Chris Murphy
> --
> devel mailing list
> devel@lists.fedoraproject.org
> https://admin.fedoraproject.org/mailman/listinfo/devel
> Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct


Thank you,
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: [Comps] Adding FreeIPA package group

[Dan Mashal]

On Fri, Aug 30, 2013 at 1:52 AM, Tomas Babej  wrote:
> Hi,
>
> attached is a patch for Fedora comps that adds FreeIPA package group.
>
> Please chime in with any feedback you might have!
>
> --

Comps commit done for f20 and f21.

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: Rawhide tree now includes install images

[Dan Mashal]

On Tue, Jul 16, 2013 at 9:41 AM, Kevin Fenzi  wrote:
> Greetings.
>
> After consulting with various teams, release engineering has re-enabled
> rawhide composes to create install images again. These images were
> dropped as part of the 'no frozen rawhide' proposal several years ago.
>
> This allows users to use the latest boot.iso or pxe images to install
> rawhide instances or point to rawhide as a install-able tree.

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

Re: GNOME 3.9.91 megaupdate

[Dan Mashal]

On Wed, Sep 4, 2013 at 10:04 AM, Kalev Lember  wrote:
> On 09/02/2013 05:44 PM, Kalev Lember wrote:
>> The GNOME 3.9.91 release is coming as well, with a bit unfortunate
>> timing wrt. Fedora freezes. In any case, we'll handle the GNOME 3.9.91
>> builds together and file them as a single megaupdate in Bodhi.
>
> GNOME 3.9.91 builds are now done and made it in right before the Alpha
> freeze last night. Bodhi wasn't enabled yet so they made it directly
> to the base F20 repo, and are available in today's F20 compose.
>
> CC-ing Tim Flink: unfortunately, latest TC3 images were spinned based on
> last night's compose and GNOME 3.9.91 is only in today's. Could you guys
> request a new TC please?

We're on TC4
-- 
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

[Dan Mashal]

On Tue, Sep 10, 2013 at 12:00 PM, Kevin Fenzi  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%2FSpins&diff=352468&oldid=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: thunderbird-24.0.2 reverted - why? (Use the commit log..., Luke)

[Dan Mashal]

On Tue, Sep 24, 2013 at 2:39 AM, drago01  wrote:
> On Tue, Sep 24, 2013 at 10:16 AM, Michael J Gruber
>  wrote:
>> Hi there,
>>
>> I can see that thunderbird 24 had been built successfully and then
>> reverted on the fc18 branch (and others). The git commit log and the
>> spec changelog say
>>
>> Revert to 17.0.8
>>
>> and nothing else.
>
> What happened here is that 24 caused broken deps so the maintainers
> probably reverted to get the security fixes out faster while stuff
> is being sorted out.
>
> And yes I agree that commit messages should be more verbose.

I almost opened a bug on the broken dep issue when I managed to solve
it locally. I was fighting with this last night but after I installed
the latest build of sqlite thunderbird 24 installed without any
issues.

It's really strange because the problem was with sqlite, not
thunderbird but sqlite was rebuilt by its maintainer to fix this
problem.

The real root cause of the broken deps is kind of bugging me:

From sqlite's spec file:

%define realver 3080002
# Provide full package version
Provides: sqlite = %{fullver}

From various parts of thunderbird's spec fie:

%if %{?system_sqlite}
%define sqlite_version 3.7.13
# The actual sqlite version (see #480989):
%global sqlite_build_version %(pkg-config --silence-errors
--modversion sqlite3 2>/dev/null || echo 65536)
%endif
---
%if %{?system_sqlite}
Requires:   sqlite >= %{sqlite_build_version}
%endif

So it's like something went wrong a long time ago and nobody took a
few minutes to sit down and fix it.. ?


Unrelated: I also had to manually install the latest builds of
libselinux and keyutils (also built yesterday) because I was getting
multiarch problems for other things as well.

Hope this helps.

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: Rawhide buildroot broken?

[Dan Mashal]

Seems to be working OK here.

Dan

On Fri, Oct 4, 2013 at 6:24 AM, Jon Ciesla  wrote:
> I'm seeing this too.
>
> http://koji.fedoraproject.org/koji/taskinfo?taskID=6024388
>
> -J
>
>
> On Fri, Oct 4, 2013 at 8:22 AM, Paul Howarth  wrote:
>>
>> I'm seeing this in root.log for all Rawhide builds:
>>
>> DEBUG util.py:316:  Executing command: ['fedpkg', 'sources'] with env
>> {'LANG': 'en_US.UTF-8', 'TERM': 'vt100', 'SHELL': '/bin/bash', 'HOSTNAME':
>> 'mock', 'PROMPT_COMMAND': 'echo -n ""', 'HOME': '/builddir',
>> 'PATH': '/usr/bin:/bin:/usr/sbin:/sbin'}
>> DEBUG util.py:266:  Traceback (most recent call last):
>> DEBUG util.py:266:File "/usr/bin/fedpkg", line 13, in 
>> DEBUG util.py:266:  from fedpkg.__main__ import main
>> DEBUG util.py:266:File
>> "/usr/lib/python2.7/site-packages/fedpkg/__init__.py", line 12, in 
>> DEBUG util.py:266:  import pyrpkg
>> DEBUG util.py:266:File
>> "/usr/lib/python2.7/site-packages/pyrpkg/__init__.py", line 17, in 
>> DEBUG util.py:266:  import pycurl
>> DEBUG util.py:266:  ImportError: /lib64/libkrb5.so.3: symbol
>> keyctl_get_persistent, version KEYUTILS_1.4 not defined in file
>> libkeyutils.so.1 with link time reference
>> DEBUG util.py:356:  Child return code was: 1
>>
>> f20 builds don't seem to be affected.
>>
>> 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
>
>
>
>
> --
> 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
> Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: AutoQA ??? (was: Re: Building and submitting updates for Fedora 20)

[Dan Mashal]

On Sun, Oct 6, 2013 at 1:51 PM, Michael Schwendt  wrote:
> On Sun, 06 Oct 2013 15:09:24 -0500, Rex Dieter wrote:
>
>> Michael Schwendt wrote:
>>
>> > On Sun, 06 Oct 2013 19:11:41 +0200, Ralf Corsepius wrote:
>> >
>> >> I now see ... the version in f19 was greater than that in f20+rawhide,
>> >> for whatever reasons.
>> >> Actually, I wonder why AutoQA did not complain.
>> >
>> > There are no AutoQA comments in that bodhi ticket at all. Almost as if
>> > AutoQA has not been run for that update. Normally it would add a comment
>> > also for PASSED tests.
>>
>> Is AutoQA enabled globally yet?
>
> It isn't anymore? It used to be.
>
>> Last I knew, it was an opt-in service.
>
> Where may I read about that? I've searched a bit, found some old blog posts,
> but couldn't locate the programs they referred to, such as autoqa-optin.
> "yum search autoqa" -> No matches found
>
> Search a bit more, found this
>   
> http://jlaska.wordpress.com/2010/06/01/fedora-package-maintainers-want-test-results/
>
> but following the instructions, they are out-of-date and don't report
> settings that match reality.  It lists "devel F-16 F-17" as available
> releases, but there have been AutoQA comments for a recent update of
> "audacious" for F-19. And the package is not listed as "opted in" for that
> release either.

There was an issue with AutoQA that Tim Flink supposedly fixed. It
*should* be enabled. I will ask him to look into it.

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: AutoQA ??? (was: Re: Building and submitting updates for Fedora 20)

[Dan Mashal]

On Sun, Oct 6, 2013 at 5:01 PM, Dan Mashal  wrote:
> On Sun, Oct 6, 2013 at 1:51 PM, Michael Schwendt  wrote:
>> On Sun, 06 Oct 2013 15:09:24 -0500, Rex Dieter wrote:
>>
>>> Michael Schwendt wrote:
>>>
>>> > On Sun, 06 Oct 2013 19:11:41 +0200, Ralf Corsepius wrote:
>>> >
>>> >> I now see ... the version in f19 was greater than that in f20+rawhide,
>>> >> for whatever reasons.
>>> >> Actually, I wonder why AutoQA did not complain.
>>> >
>>> > There are no AutoQA comments in that bodhi ticket at all. Almost as if
>>> > AutoQA has not been run for that update. Normally it would add a comment
>>> > also for PASSED tests.
>>>
>>> Is AutoQA enabled globally yet?
>>
>> It isn't anymore? It used to be.
>>
>>> Last I knew, it was an opt-in service.
>>
>> Where may I read about that? I've searched a bit, found some old blog posts,
>> but couldn't locate the programs they referred to, such as autoqa-optin.
>> "yum search autoqa" -> No matches found
>>
>> Search a bit more, found this
>>   
>> http://jlaska.wordpress.com/2010/06/01/fedora-package-maintainers-want-test-results/
>>
>> but following the instructions, they are out-of-date and don't report
>> settings that match reality.  It lists "devel F-16 F-17" as available
>> releases, but there have been AutoQA comments for a recent update of
>> "audacious" for F-19. And the package is not listed as "opted in" for that
>> release either.
>
> There was an issue with AutoQA that Tim Flink supposedly fixed. It
> *should* be enabled. I will ask him to look into it.


AutoQA was fixed Sep 30. Checking random updates including one I just
submitted, it is working fine.

Updates where AutoQA ran:

https://admin.fedoraproject.org/updates/systemd-204-16.fc19

https://admin.fedoraproject.org/updates/FEDORA-2013-18394/policycoreutils-2.1.14-46.6.fc19

https://admin.fedoraproject.org/updates/FEDORA-2013-18423/nemo-2.0.0-1.fc20,cinnamon-session-2.0.0-2.fc20,cinnamon-screensaver-2.0.0-1.fc20,cinnamon-settings-daemon-2.0.1-1.fc20,cinnamon-translations-2.0.0-1.fc20,cjs-2.0.0-1.fc20,cinnamon-desktop-2.0.0-1.fc20,cinnamon-control-center-2.0.1-2.fc20

https://admin.fedoraproject.org/updates/FEDORA-2013-18317/gstreamer1-plugins-bad-free-1.2.0-2.fc20


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: Orphaning Farstream

[Dan Mashal]

On Wed, Mar 27, 2013 at 8:19 AM, Brian Pepple  wrote:
> Hi all,
>
> I'm orphaning Farstream, since it's no longer used in Empathy. I believe
> the only packages that might still depend on it are Pidgin and
> ktp-call-ui.
>
> Thanks,
> /B
> --
> Brian Pepple 
>
> https://fedoraproject.org/wiki/User:Bpepple
> gpg --keyserver pgp.mit.edu --recv-keys 810CC15E
> BD5E 6F9E 8688 E668 8F5B  CBDE 326A E936 810C C15E
>
> --
> devel mailing list
> devel@lists.fedoraproject.org
> https://admin.fedoraproject.org/mailman/listinfo/devel

I have taken this.

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

Re: F19 xorg AMD HD7xxx GPU support need package review

[Dan Mashal]

On Thu, Mar 28, 2013 at 6:52 AM, Jerome Glisse  wrote:
> Looking for someone willing to review package needed for supporting
> HD7xxx GPU family in F19
>
> https://bugzilla.redhat.com/show_bug.cgi?id=927269
>
> Cheers,
> Jerome
> --
> devel mailing list
> devel@lists.fedoraproject.org
> https://admin.fedoraproject.org/mailman/listinfo/devel

I have taken this.

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

Re: How do *you* use Fedora?

[Dan Mashal]

On Tue, Apr 2, 2013 at 12:47 PM, Pete Travis  wrote:

> Hello,
>
> The docs team has begun assembling release notes for Fedora 19, and I've
> been thinking over hardware requirements.
>
> Historically, we have cited the CPU, storage, and especially memory
> requirements for the default installation - a basic GNOME desktop.  I'd
> like to reexamine that practice, with input from the development community.
> Fedora is too versatile a product to document so narrowly.
>
> A few considerations come immediately to mind, but please don't limit
> yourself to the examples:
> Modern composited desktops like GNOME and KDE need better graphics
> hardware than XFCE or MATE.  Headless servers would benefit from better
> NICs or storage controllers, but not require them. Purpose driven virtual
> machines clearly need fewer resources than the machine that hosts them.
>
> I'm considering system specs at this point, but establishing the roles
> deployed might aid in targeting more comprehensive documentation. Beyond a
> basic desktop, what use cases would you like to see us represent?
>
> -- Pete Travis
> - Fedora Docs Project Leader
> - 'randomuser' on freenode
> - immanetize at fedoraproject.org
>
> --
> devel mailing list
> devel@lists.fedoraproject.org
> https://admin.fedoraproject.org/mailman/listinfo/devel


Differently over the years.

I used to run Fedora on servers at one point.

I then started contributing.

I now use it to stay up to date with "Distro X" upstream, learn new things,
and help other people, and I have come in to contact with some amazing
people along the way.

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

Re: LightDM is absent?

[Dan Mashal]

On Sat, Apr 13, 2013 at 2:52 PM, Kevin Kofler  wrote:
> John5342 wrote:
>> I think searching applications by default is a stupid idea when that
>> web app is mostly used by packagers
>
> I think it's a stupid idea, period. The default should be to search all
> packages.
>
> Kevin Kofler
>
> --
> devel mailing list
> devel@lists.fedoraproject.org
> https://admin.fedoraproject.org/mailman/listinfo/devel

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

Re: LightDM is absent?

[Dan Mashal]

On Sun, Apr 14, 2013 at 2:57 AM, Pierre-Yves Chibon  wrote:
> On Sun, 2013-04-14 at 02:39 -0700, Dan Mashal wrote:
>> On Sat, Apr 13, 2013 at 2:52 PM, Kevin Kofler  wrote:
>> > John5342 wrote:
>> >> I think searching applications by default is a stupid idea when that
>> >> web app is mostly used by packagers
>> >
>> > I think it's a stupid idea, period. The default should be to search all
>> > packages.
>> >
>> > Kevin Kofler
>> >
>
>> +1 +1
>
> Blahblahblahb
> http://lists.fedoraproject.org/pipermail/devel-announce/2013-January/001036.html
>
> Pierre
> --
> devel mailing list
> devel@lists.fedoraproject.org
> https://admin.fedoraproject.org/mailman/listinfo/devel

Let me know when it's functional.
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Keeping old versions of packages

[Dan Mashal]

On Wed, Apr 10, 2013 at 5:24 PM, Reindl Harald  wrote:
> but Fedora IS NOT RHEL
> if you want the RHEL way use it
>

WHO ARE YOU KIDDING?
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: LightDM is absent?

[Dan Mashal]

On Sun, Apr 14, 2013 at 5:16 AM, Rex Dieter  wrote:
> Dan Mashal wrote:
>
>> On Sun, Apr 14, 2013 at 2:57 AM, Pierre-Yves Chibon 
>> wrote:
>
>>> Blahblahblahb
>>> http://lists.fedoraproject.org/pipermail/devel-announce/2013-January/001036.html
>
>> Let me know when it's functional.
>
> Like now.
>
> (at least https://apps.fedoraproject.org/packages/ was when I tried just
> now)
>
> -- rex
>
> --
> devel mailing list
> devel@lists.fedoraproject.org
> https://admin.fedoraproject.org/mailman/listinfo/devel

It returns you to pkgdb to set acls and the relationships tab gives an
error. I was mainly looking at it to manage permissions (right now).

And when I meant functional I meant FULLY functional, meaning I
wouldn't have to touch pkdgb ever again.

Other than that it IS beautiful and fast.

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

Re: LightDM is absent?

[Dan Mashal]

On Sun, Apr 14, 2013 at 3:53 PM, Rahul Sundaram  wrote:
> Hi
>
>
> On Sun, Apr 14, 2013 at 6:28 PM, Dan Mashal  wrote:
>>
>>
>> It returns you to pkgdb to set acls and the relationships tab gives an
>> error. I was mainly looking at it to manage permissions (right now).
>>
>> And when I meant functional I meant FULLY functional, meaning I
>> wouldn't have to touch pkdgb ever again.
>
>
> It is functional for the purpose of searching packages which was the
> original topic of the conversation.   I have replaced the pkgdb link with a
> reference to this new UI to avoid any confusion.
>
> Rahul
>
> --
> devel mailing list
> devel@lists.fedoraproject.org
> https://admin.fedoraproject.org/mailman/listinfo/devel

I think you misunderstand.

2 things:

1) I want to be able to login and click "My packages" and see all my packages.

2) I want to be able to change acls without having to go back to
pkgdb. In fact, this might take exporting the pkdgb database and
putting it in to the same or seperate database Moksha uses.

Don't get me wrong, I love this application but it needs work to fully
replace pkgdb.. unless that wasn't the intended purpose in the first
place.. in which case that would be unfortunate.

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

Re: next pkgdb?

[Dan Mashal]

On Mon, Apr 15, 2013 at 3:08 AM, Pierre-Yves Chibon  wrote:
> On Sun, 2013-04-14 at 15:28 -0700, Dan Mashal wrote:
>> It returns you to pkgdb to set acls and the relationships tab gives an
>> error. I was mainly looking at it to manage permissions (right now).
>
> Packages is not meant for this
>
>> And when I meant functional I meant FULLY functional, meaning I
>> wouldn't have to touch pkdgb ever again.
>
> May I ask what is wrong with pkgdb? I'm involved in writing the next
> generation of pkgdb, so inputs on what it should do/look like are very
> welcome.
> Please tell me, what's wrong with pkgdb and feel free to suggest how it
> could be fixed.
>
> Pierre
> --
> devel mailing list
> devel@lists.fedoraproject.org
> https://admin.fedoraproject.org/mailman/listinfo/devel

1) It's slow.
2) It's spammy.
3) Setting ACLs is cumbersome. (related to #2)


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

Re: looking for co-maintainer / new owner

[Dan Mashal]

On Fri, Apr 19, 2013 at 9:12 AM, Nathanael D. Noblet  wrote:
> Hello,
>
>   The package barry is used to sync a blackberry device with a desktop. I
> took it over awhile ago when I owned a blackberry. I've since moved on to
> own various other devices and don't see myself returning to a blackberry
> anytime soon. As such I'm wondering if anyone wants to take ownership.
>
>   There is a semi-active upstream. They have new releases and a few
> community members contributing. A very responsive main developer - any
> issues we've had he's helped resolve and accepts patches readily. Its a low
> maintenance package by most accounts. I'll continue to maintain it if no one
> steps up for a little. If no one takes it I'll likely drop it around F20 or
> so.
>
> --
> Nathanael d. Noblet
> t 403.875.4613
> --
> devel mailing list
> devel@lists.fedoraproject.org
> https://admin.fedoraproject.org/mailman/listinfo/devel


As a Blackberry owner of the 9930 and the Z10 I will be happy to help.
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: looking for co-maintainer / new owner

[Dan Mashal]

On Sat, Apr 20, 2013 at 7:25 AM, Nathanael Noblet  wrote:
>
> On Apr 20, 2013, at 12:32 AM, Dan Mashal wrote:
>> As a Blackberry owner of the 9930 and the Z10 I will be happy to help.
>
> Perfect, ACLs approved. I started to update to the 0.18.4 release from 0.18.3 
> However they changed some of the udev rules and I wanted to make sure I knew 
> why before I fixed the spec. Once that is done it should basically be 
> maintance free till 0.19 is released.
>
> thanks for signing up
>
> --
> devel mailing list
> devel@lists.fedoraproject.org
> https://admin.fedoraproject.org/mailman/listinfo/devel

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

Re: Embedded SIG

[Dan Mashal]

On Sun, Apr 21, 2013 at 5:01 AM, Markus Mayer  wrote:
> Hi,
>
> I have started developing for embedded devices (aka microcontrollers) lately
> (mainly ARM cortex-M3 devices). Although fedora provides some of the needed
> tools, there are still some bits missing to provide a good out-of-the-box
> experience.
>
> So I have decide to ask if there are others like me, and if there are
> willing to form a SIG (special interest group) to enhance embedded
> developing with fedora.
>
> I think the main things to discuss within the sig are:
> - Finding out what fedora is missing to provide a good develepmont
> experience
> - Packaging (Cross-compilers, cross-debugers, ...)
>
> So if you are interested in helping to move thinks further or if you have
> any interesting/help-full information, I would highly appreciate your help.
>
>
> regards
>
> Markus
> --
> devel mailing list
> devel@lists.fedoraproject.org
> https://admin.fedoraproject.org/mailman/listinfo/devel

How does this differ from the already existing ARM sig?

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

Receiving bugs from "Crash Catcher" with [faf] in the subject line

[Dan Mashal]

Seems like someone turned on a bot this morning. Just a heads up..
these have [faf] in the subject line and seem to be filing bugs on old
components (for me at least). Looks like it's just starting to make
the rounds. Who owns this?

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

Re: F19 DVD over size - what to drop?

[Dan Mashal]

On Wed, May 1, 2013 at 1:03 PM, Bill Nottingham  wrote:
> The F19 DVD is currently *way* over size. (i686: 417MB, x86_64: 311MB).
> That's almost certainly more than can be fixed by trimming around the
> edges; we need to remove actual functionality that's on the DVD.
>
> Options include:
>
> 1) One/some of the desktops
>
> F19 DVD currently includes
> - GNOME
> - KDE
> - XFCE
> - LXDE
> - Sugar
> - MATE (new in F19)
> - Cinnamon (new in F19)
>
> 2) The web server environment
>
> Contains web server and web server runtimes (PHP, JBoss, Mongo, perl,
> python, rails)
>
> 3) The developer & content creator workstation
>
> Contains the web server stuff above, Eclipse, developer tools, designer
> tools, Fedora packaging tools, and so on.
>
> Opinions?
>
> Bill
> --
> devel mailing list
> devel@lists.fedoraproject.org
> https://admin.fedoraproject.org/mailman/listinfo/devel

In regards to MATE + Cinnamon:

MATE + Cinnamon fit on F18 x86_64 DVD but not the i686 DVD. The i686
and x86_64 have different sizes (one reason was due to including the
PAE and non PAE kernels).

That being said Cinnamon IS broken in F19 but it is only 2 packages on
top of Gnome 3.. cinnamon and muffin. We expect to have it working by
release and upstream is working on a fix, in fact I made some progress
last night and have Cinnamon 2D mode working.

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

Lots of other distros are dropping Cinnamon because of this. Let's not
be THAT distro.

Also after spending a lot of time the last few days trying to compose
the MATE liveCD a lot of unneeded dependencies were being pulled.

I think we should look at package dependencies. It seems that lots of
unnecessary packages are being pulled when composing media.

Just my experience over the last few days.

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

Re: F19 DVD over size - what to drop?

[Dan Mashal]

On Wed, May 1, 2013 at 1:21 PM, Bill Nottingham  wrote:
> Dan Mashal (dan.mas...@gmail.com) said:
>> I think we should look at package dependencies. It seems that lots of
>> unnecessary packages are being pulled when composing media.
>
> Here's everything new in the F19 DVD, sorted by size. I've dropped
> java-1.8.0-openjdk in the kickstart already, but that won't be enough.
>
> http://paste.fedoraproject.org/9849/36743327/
>
> Bill
> --
> devel mailing list
> devel@lists.fedoraproject.org
> https://admin.fedoraproject.org/mailman/listinfo/devel

Why is wayland being included? Last I checked we are still using X11.

42596   wayland-devel.x86_64
21216   libwayland-client-devel.x86_64
14860   libwayland-cursor.x86_64
7204libwayland-cursor-devel.x86_64



Thunderbird is new? Drop it. Let's use evolution.

=

8847388 community-mysql-server.x86_64 <-- ??



gnome-getting-started-docs.noarch <-- is this really needed? Why
doesn't Gnome 3 get docs online or something?

=

Quite a few devel packages as well.

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

Re: F19 DVD over size - what to drop?

[Dan Mashal]

On Wed, May 1, 2013 at 1:55 PM, Robert Relyea  wrote:
>> Thunderbird is new? Drop it.
>
> Hardly new since I've been using it on Fedora for 8 years now.
>
> bob
>
>

New to the DVD.

On Wed, May 1, 2013 at 1:48 PM, Ben Cotton  wrote:
> It's entirely possible that someone who is downloading the DVD image
> intends to install on a machine that doesn't have a consistent network
> connection. In that case, offline documentation is very useful.
>
>
> --
> Ben Cotton
> --
> devel mailing list
> devel@lists.fedoraproject.org
> https://admin.fedoraproject.org/mailman/listinfo/devel

Not really. This is a straw man argument.



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

Re: [Fedora-spins] F19 DVD over size - what to drop?

[Dan Mashal]

On Wed, May 1, 2013 at 2:04 PM, Bill Nottingham  wrote:
> (batching a couple of replies)
>
> That would be up to the Cinnamon maintainer, who is the one that
> is including it.
>

As cinnamon comaintainer and MATE maintainer I'll switch them both to
evolution today.

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

Re: F19 DVD over size - what to drop?

[Dan Mashal]

On Fri, May 3, 2013 at 6:45 AM, "Jóhann B. Guðmundsson"
 wrote:
> On 05/03/2013 01:40 PM, Jaroslav Reznik wrote:
>>
> Why not just make the assumption that administrators will use the netinstall
> and or ks and desktop users will use live spins?
>
> JBG
>


I used to use the DVD at one point as a user.. before Fedora 18. *sheds tear*

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

Re: Review swap

[Dan Mashal]

On Fri, May 3, 2013 at 9:27 AM, Jon Ciesla  wrote:
> I'd like to get trac10 (trac 1.0.1) into EL-6 sooner rather than later, so
> I'll take one of yours in return.  Thanks!
>
> -J
>
> --
> 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

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

Re: Review swap

[Dan Mashal]

On Fri, May 3, 2013 at 11:11 AM, Jon Ciesla  wrote:
>
>
>
> On Fri, May 3, 2013 at 1:00 PM, Dan Mashal  wrote:
>>
>> On Fri, May 3, 2013 at 9:27 AM, Jon Ciesla  wrote:
>> > I'd like to get trac10 (trac 1.0.1) into EL-6 sooner rather than later,
>> > so
>> > I'll take one of yours in return.  Thanks!
>> >
>> > -J
>> >
>> > --
>> > 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
>>
>> RHBZ #?
>
>
> Oh, that.
>
> https://bugzilla.redhat.com/show_bug.cgi?id=959509
>
> -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

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

Re: F19 DVD over size - what to drop?

[Dan Mashal]

On Fri, May 3, 2013 at 11:16 AM, Bill Nottingham  wrote:
> Hm, I've always thought of it differently - if we're trying to provide good
> value in the DVD media as a demonstration of all the things you can do with
> Fedora

It did. Until I couldn't install multiple desktops anymore. (18)

>Isn't there more value in a development workstation

Of course there is. Yet, we remove things like GCC from the default
install. Why?

> or a design suite

I don't think this is needed on the DVD. This should be a separate
spin (I think it is already). One can always "yum install gimp" after
having a working desktop or "minimal" install.

>or a web application stach, or other dissimilar things rather than

Define "web application stack".

This definition changes daily.

> the marginal added value of a 4th (or 5th, or 6th, or 7th) desktop?

I disagree that these are "marginal" value adds considering they got
more press than any other feature in Fedora 18.


> This is also why I've always found the multi-desktop DVD to be a strange
> thing to hand out.

I agree. It's useless to an experienced user. I'd rather be handing
out netinstall CD's as an ambassador. Cheaper, leaner, more updated
packages get installed.

> unless we're trying to tell people that Fedora is best
> for picking between one of 7 desktops and not other things.

We're trying to be too many things at once. Let's get back to basics.
A nice stable linux distro that offers you the most choice with the
most updated packages that is stable.

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

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

[Dan Mashal]

Hi,

In the latest Fedora 19 Beta TC2 install after I got through the
initial steps of the install I started to setup my root password.

To my surprise my password was shown in plain text instead of bullets.

I believe that this is a major security risk and that this is a new UI
change going forward and this is not a bug.

Do you think this is a good idea?

What if you are installing and someone is looking over your shoulder
and you don't know about this new "UI improvement"?

Someone would see a password that you may or may not often use whether
it's secure or not.

Even if someone watched you type the password or recorded it with a
camera, that would be harder to decrypt than just showing it in plain
text while you type it in to anaconda.

In addition, it was stated that this is becoming a "popular" UI
enhancement but there was no documentation provided as to where this
is popular. In my experience you would click on an icon next to the
dialog box if you wanted to see the password. This is what is becoming
popular. Not showing it as plain text while you type.

Thoughts?

Dan
-- 
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 Fri, May 3, 2013 at 2:17 PM, Chris Murphy  wrote:
>
> On May 3, 2013, at 2:04 PM, Dan Mashal  wrote:
>>
>> I believe that this is a major security risk and that this is a new UI
>> change going forward and this is not a bug.
>>
>> Do you think this is a good idea?
>
> No. I think it's a bug, and a bug should be filed on it.
>
>
> Chris Murphy
> --
> devel mailing list
> devel@lists.fedoraproject.org
> https://admin.fedoraproject.org/mailman/listinfo/devel

It was.


And closed as NOTABUG.

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

So I just wanted to email other intelligent people and see if I was
crazy or stupid.

Dan
-- 
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 Fri, May 3, 2013 at 8:40 PM, M. Edward (Ed) Borasky  wrote:
> I didn't notice this the last time I did an install. But yes, it's a
> *problem* if it does that. I'll upvote or whatever if someone re-opens; I do
> so many installs in coffee shops that I would flat out not use a distro that
> did this!
>


I observed this while installing with BETA TC2

Link:

https://dl.fedoraproject.org/pub/alt/stage/19-Beta-TC2/Fedora/x86_64/iso/Fedora-19-Beta-TC2-x86_64-netinst.iso

I see a TC3 but no x86_64 ISO yet.

Dan
-- 
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 Fri, May 3, 2013 at 8:48 PM, Felix Miata  wrote:
> Yet another case of trying to "fix" what isn't broken.
>
> Are any of the several who closed the bug more than 20 years old?
>
> Crazy is the unexpected behavior of echoing back typed password characters.
> Where else, if anywhere, is this happening? Never in 40 computing years can
> I remember ever seeing password characters echoed for viewing.

I don't want to make personal attacks on someone's maturity as much as
I have been frustrated since the "new and improved anconda UI"
introduced in Fedora 18.

Please try not to turn this in to a personal flame war.

Dan
-- 
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 Fri, May 3, 2013 at 8:51 PM, Matthew Garrett  wrote:
> On Fri, May 03, 2013 at 11:11:56PM -0400, Rahul Sundaram wrote:
>> On 05/03/2013 10:59 PM, Matthew Garrett wrote:
>> >Many UI decisions are unprecedented. That doesn't justify
>> >reopening bugs that the maintainer has closed. If you want to have
>> >a discussion about whether or not this is a reasonable UI
>> >decision, do so somewhere other than Bugzilla
>> This isn't a minor UI change but that one that has fairly serious
>> security and privacy concerns.   I feel more than justified in
>> reopening the bug.
>
> And if the maintainers feel more than justified in closing it again?
> Bugzilla isn't a discussion forum. If disagree with a deliberate policy
> decision, discuss it on an appropriate mailing list.
>
> --
> Matthew Garrett | mj...@srcf.ucam.org
> --
> devel mailing list
> devel@lists.fedoraproject.org
> https://admin.fedoraproject.org/mailman/listinfo/devel

Isn't that what we're doing? That's exactly the point of this email thread.

Dan
-- 
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 Fri, May 3, 2013 at 8:58 PM, Matthew Garrett  wrote:
> On Fri, May 03, 2013 at 08:52:25PM -0700, Dan Mashal wrote:
>> On Fri, May 3, 2013 at 8:51 PM, Matthew Garrett  wrote:
>> > And if the maintainers feel more than justified in closing it again?
>> > Bugzilla isn't a discussion forum. If disagree with a deliberate policy
>> > decision, discuss it on an appropriate mailing list.
>>
>> Isn't that what we're doing? That's exactly the point of this email thread.
>
> No, this isn't the most appropriate mailing list for the discussion -
> anaconda-devel-list is a better choice if you want to interact with the
> people who actually work on that code. In any case, I was disagreeing
> with Rahul's assertion that he was justified in re-opening a bug merely
> because he disagreed with a design choice.
>
> (Please trim the emails you're replying to. It's a pain to have to
> cut out my own signature just to make the mail coherent in isolation)
> --
> Matthew Garrett | mj...@srcf.ucam.org
> --
> devel mailing list
> devel@lists.fedoraproject.org
> https://admin.fedoraproject.org/mailman/listinfo/devel

This is a wider audience. I believe this was a better group of people to ask.

Dan
-- 
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 Fri, May 3, 2013 at 9:01 PM, Matthew Garrett  wrote:
> On Fri, May 03, 2013 at 11:55:24PM -0400, Rahul Sundaram wrote:
>> On 05/03/2013 11:51 PM, Matthew Garrett wrote:
>> >And if the maintainers feel more than justified in closing it again?
>> Hopefully, they will reconsider their decision before doing that.
>> You seem to be claiming that once the maintainer has a bug report as
>> a deliberate UI change, it should never be reopened no matter what.
>> I don't agree with your opinion in that case.
>
> I'm saying that if a bug report has been closed due to the change being
> a deliberate design decision, reopening the bug isn't going to change
> the fact that it was a deliberate design decision. The appropriate place
> to discuss deliberate design decisions is a forum where said decisions
> are made, ie not Bugzilla.
>
> --
> Matthew Garrett | mj...@srcf.ucam.org
> --
> devel mailing list
> devel@lists.fedoraproject.org
> https://admin.fedoraproject.org/mailman/listinfo/devel

Let's be realistic here. The precedence they have recently set is they
make decisions and if you don't like it "too bad".

Dan
-- 
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 Fri, May 3, 2013 at 9:03 PM, Matthew Garrett  wrote:
> Seriously. Learn to trim or I'm never reading email from you again.

Is this better? Quite frankly I could care less whether you read my
email or not.

Dan
-- 
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 Fri, May 3, 2013 at 9:32 PM, Matthew Garrett  wrote:
> If you want to change a decision, it helps if you're discussing it in a
> forum that's read by the people who made that decision.

Anaconda developers don't read the developer list? That's terrible!



On Fri, May 3, 2013 at 9:35 PM, Matthew Garrett  wrote:
> Bugzilla's a dreadful place to have discussions. The lack of threading
> means unpopular decisions tend to just result in large numbers of
> contentless comments which make meaningful discussion impossible - it's
> a nightmare to find appropriate context. If a project doesn't have a
> mailing list then Bugzilla may be the least worst choice, but where it
> does then make use of it.

Thanks. Can you stop littering this thread now? We got your point.
-- 
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 Fri, May 3, 2013 at 9:53 PM, Pete Zaitcev  wrote:
> This is a perfectly appropriate forum where their authority for
> making this decision is to be discussed before it's revoked if
> necessary.

Hi Pete. Thanks for your very helpful reply. You mentioned something
VERY important, so now I have a very important question.

What would be the process for "revoking" the privilege of these crazy
decisions from the design / anaconda development team and giving them
back to the community where they belong? Making the process more open
so we can avoid these ridiculous discussions, flame wars, regressions,
security holes, and over all unhappiness for all parties involved?

I would like to stress that this is not the first, nor will it be the
last time since the complete redesign of the installer since Fedora 18
that flame wars and absolutely atrocious design decisions without
community approval have been made and this needs to stop.

Thanks,
Dan
-- 
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 Fri, May 3, 2013 at 10:45 PM, Chris Adams  wrote:
> Once upon a time, Bruno Wolff III  said:
>> It's not like the people entering the password don't know it is visible.
>
> Actually, yes it is.  The vast majority of other software that accepts
> passwords for any reason hides the passwords as they are typed, so the
> general expectation is that passwords are not displayed on the screen.
> Many people look down at the keyboard to type and would not necessarily
> look up as they are typing the password.  So, they probably won't know
> the password is displayed in the clear on their screen until they are
> done.

It gets worse. Say you dont use the mouse. Keyboard only. Type a weak
password, which is shown in plaintext, TWICE. Now you tab over to done
and your password is shown YET AGAIN for a THIRD time in plain text.
This occurs during root password and user/administrator password
creation.

Dan
-- 
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 Sat, May 4, 2013 at 2:37 AM, Michael Scherer  wrote:
> and I think that even Bruce Schneier have gave his opinion in favor of
> the proposal :
> http://www.schneier.com/blog/archives/2009/06/the_problem_wit_2.html
> http://www.schneier.com/blog/archives/2009/07/the_pros_and_co.html

Which he later took back.

> I can add to that that I have seen more than once people setting a
> password which was not the one they believed due to  :
> - keyboard layout ( ie, qwerty vs azerty in France )
> - small usage difference with Windows way, again on azerty keyboard
> ( people using capslock on french keyboard to type numbers while they
> should use shift, as capslock just type capital letter like À or É and
> not 0 or 2, and if you do not understand, just look on the web to
> compare how different it is from qwerty-based keyboard )

The installer should detect the keyboard automatically. In fact you
can even tell it what type of keyboard you have on the first screen.

> Or I could also speak of the small non standard keyboard such as macbook
> one where ~ or | are not printed and where using the wrong keyboard
> could result in wrong characters if you are unaware of the problem.

I think people that have Macs have learned how to use their slightly
different keybaords by now.

> But the discussion is not about that, even if I think the rational
> around the defaults.
> Showing by default will help people who are less familiar, hidden by
> default will satisfy people who think that's a security issue.

Showing by default helps no one.

> Hidden by default and showing it on demand is likely to still be a
> hindrance to people who may not know they type their password wrong
> ( because I think most assume that it will work fine, we are not to a
> point where people assume by default this will fail ).

Straw man argument.

> So what about hiding on demand, and having it visible by default ? This
> way, people who prefer to have it hidden will be happy, and we are still
> friendly to non technical users.

Absolutely wrong.

On Sat, May 4, 2013 at 11:10 AM, Michael Cronenworth  wrote:
> On 05/04/2013 02:29 AM, Stef Walter wrote:
>>
>> There's already this exact phoneish password hint capability in GTK+
>> with the 'gtk-entry-password-hint-timeout' setting. Turn it on in
>> $XDG_CONFIG_HOME/gtk-3.0/settings.ini, or use
>> gtk_settings_set_string_property()

I guess this is somewhat of a reasonable compromise.. if I was
installing Fedora on my phone/tablet.

On Sat, May 4, 2013 at 2:48 PM, David Woodhouse  wrote:
> Or a forum where said decisions can be overridden with a little more
> sanity, such as FESCo.

Has it come to that? Do we really need a committee to decide "sanity"
and how ridiculous this is?

On Sat, May 4, 2013 at 9:35 AM, Adam Williamson  wrote:
> http://it.slashdot.org/story/13/05/04/1248242/fedora-19-to-stop-masking-passwords
>
> Well, that escalated quickly.

As it should have.

So where do we go from here? I think the vast majority of people here
have agreed that this was wrong. I guess does this now go to FESCo and
let a few people vote on it?

Why can't there  be a wider community approval be able to vote on
things like this? As I stated earlier there are a list of things that
have changed without any real widespread community approval.

I kind of feel helpless, and powerless.

Great. I brought the attention to a wider audience and the general
public and something may or may not get done about it, but what about
the next UI change I think is ridiculous or the ones I think that
already are?

I don't feel like if I filed a bug anything would get done about it
besides a "too bad" response.

I'm really lost.

Dan
-- 
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 Sat, May 4, 2013 at 3:42 PM, Kevin Fenzi  wrote:
> You posted this on friday afternoon, Rauhl re-opened the bug
> friday night. I suspect many anaconda folks have not even seen this
> discussion or the bug reopening yet. Is there some massive hurry here?

No.

> Lets see what anaconda developers say based on the feedback
> and see if they would like to revisit the change or if they still wish
> to keep it. Or perhaps they wish more information or feedback.
> Or perhaps they will revisit it and solve it some other way. There's
> lots of options there.

As I stated before the feeling I got from their response was "this is
our decision based on this and that and too bad", and it's not the
first time.

> If they do decide to keep the change, you could escalate it to FESCo.
> However, (speaking only for myself here) I would be VERY reluctant to
> override maintainers on their packages on something that is a design
> decision/judgement call. Where would we draw the line?

I would rather have QA have move oversight on these things. As I only
discovered this while doing QA.

Excuse my cynicism here but this would also require some change to the
QA process itself and what are blockers and what are not and the "nice
to have" process which should be renamed "we won't hold our breath".

So say I did bring this up as a blocker under new criterion like "This
isn't broken but probably a bad idea criterion" that I think should be
defined (with a better name) and it was -1'd by the whoever was around
during the meeting because most of us have $dayjobs, only then would I
feel it appropriate to bring up to FESCo and then possibly the board.
Short of doing that, it's much easier to just bring it to the
attention of this list and see what other people have to say about it.
Again, still a bit lost.

> Fedora isn't a direct democracy, and I don't think such a model would
> work well at all. Especially when it comes to how maintainers or
> people doing the work spend their time. I think it's great to bring up
> things like this and ask they be reconsidered, but mob rule isn't a
> good model.

I'm not saying it should be on everything. But changes to I guess
"CRITPATH" packages (which anaconda is one of I think) should be
vetted in the community not on the anaconda maintainer list first.

> Perhaps engage with the folks making those changes and offer to help
> out or provide more direct feedback?

As stated earlier this is not the first time I have tried to do so.

> I'm sure it will work out in the end... :)

I think that bringing it up here made a bit of difference. Thanks.


Dan
-- 
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 Mon, May 6, 2013 at 2:42 PM, Adam Williamson  wrote:
> For the record:
>
> commit da565b769979a031f318dbc727b9888e4f1fb37c
> Author: Chris Lumens 
> Date:   Mon May 6 17:18:30 2013 -0400
>
> Revert "Add signal handlers for controlling password entry
> visibility." (#958608).
>
> This reverts commit 99464761dab4e43cfbf8caa059815c6ab67c6282.
>
> Internet, you may stand down.

Thank you.

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

Re: Build control-center in mock fail

[Dan Mashal]

On Tue, May 7, 2013 at 9: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
>
>
Post your spec file.

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

Re: Build control-center in mock fail

[Dan Mashal]

On Tue, May 7, 2013 at 9:36 PM, Igor Gnatenko
 wrote:
> I use original .spec file. It in attachment.

Why are you using an unreleased git source?

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

[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: F19 DVD over size - what to drop?

[Dan Mashal]

On Thu, May 9, 2013 at 12:07 AM, Luya Tshimbalanga
 wrote:
> -1. Design Suite package is for those lacking online access and wanting to
> use available applications.

I see a lot of stupid justifications for "lacking online access". AN
ENTIRE SPIN is not enough?

Would you like us to mail you the spin by over night mail pre
installed on a hard drive via overnight as well by snail mail?

C'mon.

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

Re: F19 DVD over size - what to drop?

[Dan Mashal]

On Thu, May 9, 2013 at 11:19 AM, Luya Tshimbalanga
 wrote:
> You can call "lacking online access" justification stupid if you want,
> you forgot there are users who still prefer DVD installation rather than
> spin.  You wanted to remove the entire Design suite package set
> (available since several release) from DVD without consulting the
> maintainer first so an arrangement to remove some individual software
> could be made. I could say the same thing about MATE package set you
> maintained because it duplicated other desktop environments unlike
> Design suite complementing either of them.
> Bruno posts summarized my view so I stop here.

True. I didn't mean to pick on the design suite itself but more making
a point that a lot of people are using that as a justification, my
apologies.

In addition, I used to prefer the DVD (with or without an online
connection) myself because I could just down 4.7GB of Fedora goodness
and install all of it at the same time at once. I made that point
earlier in this thread. I did not mean to single out the design suite
itself, even though my email seemed like it did. I no longer have any
desire to download the DVD installer anymore due to the reasons stated
in this email and my earlier emails in this thread.

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

Re: MTA virtual provides craziness

[Dan Mashal]

On Tue, May 14, 2013 at 6:10 PM, Adam Williamson  wrote:
> We now appear to have *four* virtual provides for mail servers:
>
> MTA
> smtpd
> smtpdaemon
> server(smtp)
>
> This seems a tad excessive. exim and postfix provide all four. sendmail
> provides MTA, smtpdaemon and server(smtp). Nothing else provides any of
> them (though if we could just agree on what any of them meant or what
> they were for, probably esmtp and ssmtp might want to).
>
> Nothing requires 'smtpd'. One thing each requires each of the others,
> just to make things nice and complicated:
>
> [root@adam blivet (master %)]# repoquery --whatrequires MTA
> ratbox-services-0:1.2.1-8.fc19.x86_64
> [root@adam blivet (master %)]# repoquery --whatrequires "server(smtp)"
> sagator-core-0:1.2.3-6.fc19.noarch
> [root@adam blivet (master %)]# repoquery --whatrequires smtpdaemon
> vacation-0:1.2.7.1-3.fc19.x86_64
>
> Good lord. Anyone feel like injecting any sanity? Anyone have a long
> enough memory to know what the hell each of the different provides is
> meant for? I seem to vaguely recall that 'MTA' and 'smtpdaemon' were
> meant to express subtly different things, but I can't remember any
> details.

Sanity: Switching to postfix?

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

Re: Maintainer input on release notes

[Dan Mashal]

On Mon, May 13, 2013 at 12:52 PM, John J. McDonough  wrote:
> We had a short discussion of this at this morning's meeting but felt a
> broader discussion here was warranted.
>
> When preparing the Release Notes, we often ask the developers for wiki
> input, and generally come up dry. More recently, we look though the
> repos for changes, but the upstream release notes are often very poor or
> nonexistent. Every release includes literally thousands of changed
> packages, and while we strive to document "significant" changes, these
> poor upstream release notes leave us little clue as to what constitutes
> "significant".  Certainly the feature pages get us started, but they
> only capture a tiny fraction of what changes in a release.
>
> But if we think about the maintainers, chances are they begin working on
> the next thing just as soon as the compose closes for the previous
> release, if not sooner.  Very likely they have an interest in the
> packages they are maintaining, and it would not be surprising if they
> viewed some features to be important.
>
> But by the time we ask for input, odds are they have moved on and most
> of the updated packages in the new release are ancient history.
>
> However, if we were to open the beats as soon as possible, certainly
> when the compose closes or even as soon as we have converted the beats
> to XML, then the developers could make a note in the wiki about what is
> significant, right at the time they are working on it and interested in
> it.
>
> Of course we would still need to remind the maintainers that we want
> their input, and especially that it doesn't need to be beautiful prose -
> all we really need is a clue as to what is important.  But I think if we
> can capture the input early, we have better odds of getting more
> complete release notes.
>
> Is this something we should do?  Is there something different we should
> be doing?
>
> --McD

I think you should focus on "Common Bugs" and work with the IRC support SIG.

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

Re: anaconda / initial-setup / gnome-initial-setup: can we do this better?

[Dan Mashal]

On May 21, 2013 11:50 AM, "Adam Williamson"  wrote:
>
> On Fri, 2013-05-17 at 14:25 -0700, Adam Williamson wrote:
> > So I'm writing a blog post on this topic ATM, and that really kinda
> > brought home how messy this design is at present.
>
> So! I've been poking through the logic of this for the last few days,
> still, and with some further testing of exactly what g-i-s and i-s
> actually do, and what anaconda and firstboot did in previous releases, I
> have an even simpler proposal:
>
> Make anaconda warn if you don't create a user, and nuke initial-setup
> for non-OEM installs.
>
> Here is how F18 behaved:
>
> * anaconda only let you create a root password, no user creation
> * firstboot ran on graphical installs, not text
> * firstboot would let you skip the user creation step, with a warning
>
> So here are all the things you could do with F18 and earlier:
>
> * Do a text install and create user account manually after initial login
> if you want one
> * Do a graphical install and create a user using firstboot
> * Do a graphical install, skip user creation in firstboot, and create
> user account manually if you want one
>
> Since F19 has user creation in anaconda, we can actually cover all those
> scenarios in anaconda quite easily. Literally all we have to do is make
> it pop up a warning if you try to quit the installer without creating a
> user account, but let you go ahead if you really want to.
>
> If we do that, then initial-setup is entirely superfluous to
> requirements. Anaconda would be able to do everything necessary, and
> would be encouraging people down the right path, but those who really
> want to do installs with no user account would still be able to.
>
> gnome-initial-setup would still be a different case, as GNOME apparently
> really wants to force the creation of a non-root account. So g-i-s will
> likely want to go on popping up if a user account was not created during
> installation. But that's entirely up to the desktop team what they want
> to do, and it's not at all incompatible with this proposal.
>
> So basically, I think we can just do a simple tweak to anaconda and not
> bother running initial-setup at all on a 'normal' install. We can of
> course keep it around for the OEM case, but that doesn't need to bother
> anyone else.

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

[faf] bug reports

[Dan Mashal]

What is the status of this?

Is this still filing bug reports?

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