Self introduction
Hello everybody, I'm new in Fedora Devel list, using fedora and centos for years, and I intend to become -official- packager for my own project, Pandora FMS, a server/network monitoring project. I'm looking for a sponsor who guide me in the wonders of the fedora packaging. I have being creating RPM packages for centos, so I have some experience in RPM packaging, but this is not a science, its an art, so I've a lot to learn. -- Un saludo Sancho Lerena http://pandorafms.com sler...@gmail.com -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Fedora.NEXT Products and the fate of Spins
On Fri, 2014-01-31 at 16:22 -0700, Kevin Fenzi wrote: > > The desktop spins are the ones that seem most important to keep. I > > think there's a reasonable argument for dropping most or all of the > > non-desktop spins, because they're essentially just vehicles for > > delivering package groups, when you look at them. Games provides a > > bunch of games. Electronics Lab provides a bunch of electronics > > tools. There's nothing particularly compelling about shipping these > > particular bundles of packages as live images, or as images at all; > > we can come up with any number of other mechanisms for letting people > > get at them, very trivially. Hell, it's not particularly difficult to > > do it right now. > > I went down this same path a few years ago, but there are actually use > cases for the non desktop spins that aren't served by just installing > and then installing the packages. For example: > > * Using the security spin booted live to examine a compromised install. > You don't want to attach it to a real install thats r/w. Booting off > a read only media means if something messes it up, you can just > reboot. > > * You have 30 machines in a lab you can use for your electronics lab or > design class or gamer gathering. You're allowed to reboot them, but > not install anything on them (they have windows on them or something). > You can just walk around before class and boot them all up on live > dvd/cd's. If someone messes up their setup in the class, they just > reboot and get back to the desktop. > > Now perhaps these are cases where we just say: hey, make your own for > this, but they are valid use cases not easily handled by dropping those > spins. Thanks for the examples - I think you've given them before, and I've forgotten them. Yup: they're valid use cases, and they strengthen the argument for those spins *as* spins. But indeed you can still make the case that there just isn't enough value in doing it as part of Fedora, and viewed in the context of these fairly 'niche' uses, the argument about making them into remixes or something seems less alarming. I'm not sure I'd be onboard with hiving off KDE, Xfce and Sugar as non-Fedora stuff (or requiring them to become fully-fledged Products), but I can certainly see saying 'look, if you want to take Fedora and build a security forensics live image on top of it, that's awesome, but call it something else and maintain it yourself' - I'm rather more on-board with that argument *as applied to these somewhat niche cases* than just applied to, you know, everything we currently cover with Spins. I'm not sure I have a definite opinion on whether we need to / should do that or not, but I know I wouldn't be incredibly sad/angry if it happened. I do think there's some mileage in the argument that, if you go all the back to the original Spins conception as this wide-open field to create ANY PRODUCT YOU LIKE from Fedora bits and it'd be part of the Fedora project in *some* form, that's probably biting off more than we can realistically chew, especially given what releng has said about resources. Right now we're kinda between two stools on that: Spins didn't take off like wildfire and produce hundreds of awesome things like maybe it was originally expected to, but it wasn't a complete and utter dead loss either - so now we're in, I guess, a slightly weird situation where we have this very heavyweight conception of Spins which is maybe not providing us enough value to justify its weight. If you want to take a "market" view of it, you can make the argument that SUSE Studio is rather eating our lunch on the original Spins concept: http://susestudio.com/browse zoiks. Kind of beats our 'well, first figure out the way livecd-creator is duct taped together, then submit a kickstart file to this SIG thing that barely exists any more, then...' process into a cocked hat. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net http://www.happyassassin.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Fedora.NEXT Products and the fate of Spins
On Fri, 31 Jan 2014 14:37:02 -0800 Adam Williamson wrote: > So in my new constructive spirit ;) let me take a crack at some > answers to this: > > I think the Spins process as it currently exists has a lot of > problems. We've been saying this for years, long before we even > thought about Fedora.next. You identify some of them above, and there > are others - we've never had coherent messaging about the spins, for > instance. This is especially silly with the desktop spins, where > there are all kinds of mixed messages. Yeah. I think things got somewhat better in f20 at least due to the requirement that someone/anyone actually booted the thing and it worked. ...snip... > The desktop spins are the ones that seem most important to keep. I > think there's a reasonable argument for dropping most or all of the > non-desktop spins, because they're essentially just vehicles for > delivering package groups, when you look at them. Games provides a > bunch of games. Electronics Lab provides a bunch of electronics > tools. There's nothing particularly compelling about shipping these > particular bundles of packages as live images, or as images at all; > we can come up with any number of other mechanisms for letting people > get at them, very trivially. Hell, it's not particularly difficult to > do it right now. I went down this same path a few years ago, but there are actually use cases for the non desktop spins that aren't served by just installing and then installing the packages. For example: * Using the security spin booted live to examine a compromised install. You don't want to attach it to a real install thats r/w. Booting off a read only media means if something messes it up, you can just reboot. * You have 30 machines in a lab you can use for your electronics lab or design class or gamer gathering. You're allowed to reboot them, but not install anything on them (they have windows on them or something). You can just walk around before class and boot them all up on live dvd/cd's. If someone messes up their setup in the class, they just reboot and get back to the desktop. Now perhaps these are cases where we just say: hey, make your own for this, but they are valid use cases not easily handled by dropping those spins. > The desktop spins, though, do have a reasonable amount of value to > users of those desktops. People do use live media *just as live > media*, and we know there are Fedora users who want to use desktops > other than our default desktop, and Fedora contributors willing to do > the work of maintaining and testing live image deliverables for those > desktops. The desktop spins we have have mostly managed to meet > reasonable quality expectations in recent releases without imposing a > burden on the QA team. I just don't see any major problems to solve > in the area of the existing desktop spins *as small-p products that > are a part of the Fedora project*, though I certainly respect the > releng team's statement that their work scales more or less linearly > with the number of deliverables we decide to make a part of the > Fedora space. I'm not going to speak for releng, but IMHO... the items that are somewhat a burden still with spins are: * Making sure someone tests and signs off at milestones. (Perhaps this could be somehow automated?) * The volume of things makes composes take longer. (perhaps we could stop doing them as part of tc/rc composes, and just do them after each of those so they don't gate those?) * websites folks have to look at what was signed off and adjust the websites for them. (Perhaps we could make some kind of more self service site for spins?) > Even if we want to keep the alternative desktop live images as a part > of the Fedora space, though, that affords us quite a bit of > flexibility to change other things about this process. Agreed. kevin signature.asc Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
[Bug 1060360] New: Request branch
https://bugzilla.redhat.com/show_bug.cgi?id=1060360 Bug ID: 1060360 Summary: Request branch Product: Fedora EPEL Version: epel7 Component: perl-Mail-MboxParser Assignee: mmasl...@redhat.com Reporter: nathan...@gnat.ca QA Contact: extras...@fedoraproject.org CC: mmasl...@redhat.com, perl-de...@lists.fedoraproject.org, ppi...@redhat.com, psab...@redhat.com Hello Some of my packages require this package as part of their dependency chains. Would you mind creating an epel7 build? Branch requests can be made here https://fedoraproject.org/wiki/EPEL/epel7/Requests -- You are receiving this mail because: You are on the CC list for the bug. Unsubscribe from this bug https://bugzilla.redhat.com/token.cgi?t=u7ctIQr6El&a=cc_unsubscribe -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-de...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
Re: Fedora.NEXT Products and the fate of Spins
On Wed, 2014-01-29 at 15:30 -0500, Stephen Gallagher wrote: > Apologies for the slightly alarmist $SUBJECT, but I want to make sure > that this gets read by the appropriate groups. > > During today's FESCo meeting, there was the start of a discussion on > how to approve new Products into the Fedora family. As part of this, > it naturally strayed into discussion of what we do about Spins as they > currently exist. > > Several ideas were raised (which I'll go through below), but we didn't > feel that this was something that FESCo should answer on its own. We'd > prefer community input on how to handle spins going forward. > > So, in no particular order (because it's difficult to say which > questions are the most important): > > 1) Are Spins useful as they currently exist? There are many problems > that have been noted in the Spins process, most notably that it is > very difficult to get a Spin approved and then has no ongoing > maintenance requiring it to remain functional. We've had Spins at > times go through entire Fedora release cycles without ever being > functional. > > 2) Should Spins be eliminated entirely in favor of Fedora Remixes[1]. > The effect here would be that Spins are no longer an official part of > The Fedora Project but are instead projects unto themselves which are > permitted to consume (possibly large) portions of our tools, packages > and ecosystem. Maintenance and upkeep of these spins then becomes > entirely the responsibility of the downstream community that > constructs them and has no mandatory draw on Fedora's marketing, > ambassadors or quality assurance resources. > > 3) Should Spins be considered Products-in-development? In other words, > should we only approve Spins that are targeted or destined for > "promotion" to a fully-supported Fedora Product? This is a nuanced > question, as it means different things for different Spins, for > example Spins focusing on a target-audience (Security Spin, Design > Suite Spin) vs. Spins focusing on a technology (LXDE Spin, MATE-Compiz > Spin). > > 3b) If we treat Spins as Products-in-development, what do we do with > those Spins that don't fit that criteria? So in my new constructive spirit ;) let me take a crack at some answers to this: I think the Spins process as it currently exists has a lot of problems. We've been saying this for years, long before we even thought about Fedora.next. You identify some of them above, and there are others - we've never had coherent messaging about the spins, for instance. This is especially silly with the desktop spins, where there are all kinds of mixed messages. * Desktop is a spin, but it's also our default deliverable. * KDE is a spin, and considered a release-blocking deliverable. * Xfce, LXDE, MATE and SoaS are spins, aren't considered release-blocking deliverables, but they *are* shipped in the same directory as the Desktop and KDE spins on the mirrors (since F20), and they're broken out and given special status on the download page as "Desktops" - https://fedoraproject.org/get-fedora#desktops . * Security Lab, Design Suite, Scientific-KDE and Electronics Lab aren't shipped in the same directory as Desktop, KDE, LXDE, MATE and SoaS (the directory they're in isn't carried by all mirrors, I don't think), and they're not "Desktops", but they're shown on a Spins tab on the download page. * All the other spins are spins, but they're not the default deliverable, they don't block the release, they're shipped in the same directory as Security Lab etc, but they're not shown directly on the download page at all. * https://spins.fedoraproject.org/ shows all the spins *except Desktop* in a co-equal way. There's an ad-hoc method to all this madness - there's a sort of ranking system going on there that is intentional - but it's all been rather thrown together as we've gone along and tweaked from release to release with no great overarching plan. So it's a good idea to look at the Spins space and see if there are opportunities for improvement, almost regardless of the Products plan, in fact (though obviously it is relevant to some questions here). Despite the problems with the process, though, I think some of our actual Spins manage to be excellent small-p products that provide good solid value to the Fedora project and we should find a way to keep them within the Fedora space even in a Product-ified world. The desktop spins are the ones that seem most important to keep. I think there's a reasonable argument for dropping most or all of the non-desktop spins, because they're essentially just vehicles for delivering package groups, when you look at them. Games provides a bunch of games. Electronics Lab provides a bunch of electronics tools. There's nothing particularly compelling about shipping these particular bundles of packages as live images, or as images at all; we can come up with any number of other mechanisms for letting people get at them, very trivially. Hell, it's not particularly diffi
Re: Fedora.NEXT Products and the fate of Spins
On Fri, 31 Jan 2014 22:50:59 +0100 Emmanuel Seyman wrote: > * Frank Murphy [31/01/2014 11:22] : > > > > Personally, I know currently, most DEs' can be installed with yum > > groupinstall. But, that may not always be the case. > > I'm going to go in the opposite direction. The old anaconda installer > made it hard to see what groups you were installing and how you could > install others. The point is will there be choice, and only time will tell. Anaconda won't be used to select groups during Desktop.product install, if I've been following correctly. It will install what's considered "product" that the WG decides upon. Fully understand and accept that. There may not be a DVD available beyond .next for multiple choice. ___ Regards, Frank www.frankly3d.com -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Fedora.NEXT Products and the fate of Spins
* Frank Murphy [31/01/2014 11:22] : > > Personally, I know currently, most DEs' can be installed with yum > groupinstall. But, that may not always be the case. I'm going to go in the opposite direction. The old anaconda installer made it hard to see what groups you were installing and how you could install others. The new anaconda is much better in this regard and the need for spins is lessened, imho. Emmanuel -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Packages installing files to /etc/rpm
On 31.01.2014 21:23, Ville Skyttä wrote: smani keyrings-filesystem (none) Fixed. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Packages installing files to /etc/rpm
A number of packages install files to /etc/rpm in Rawhide; the proper
place for macros.* is /usr/lib/rpm/macros.d for rpm >= 4.11. And no
matter what the location, these files should not be marked as %config.
Specfiles not targeting EL < 7 can simply replace %{_sysconfdir}/rpm
with %{_rpmconfigdir}/macros.d and ones that wish to stay compatible
with EL5 and 6 can do something like this to find the proper dir:
%global macrosdir %(d=%{_rpmconfigdir}/macros.d; [ -d $d ] ||
d=%{_sysconfdir}/rpm; echo $d)
List of affected packages follows (maintainer package comaintainers):
bkabrda python3 amcnabb,bkabrda,mstuchli,tomspur
bkabrda python bkabrda,dmalcolm,ivazquez,jsteffan,mstuchli,tomspur,tradej
cicku ldc bioinfornatics
deji mpich (none)
dledford openmpi dajt,deji,orion
epienbro mingw-filesystem ivanromanov,kalev,rjones
erikos sugar-toolkit erikos,pbrobinson,sdz,tomeu
erikos sugar-toolkit-gtk3 dsd,pbrobinson
jakub prelink mjw
jcapik octave alexlan,fkluknav,jussilehtola,mmahut,orion,rakesh
jjames ffcall salimma
jjames gap (none)
jjames xemacs stevetraylen
jnovy texlive pertusus,than
jorton httpd hubbitus,jkaluza
jorton php-pear remi,timj
jorton php remi
jplesnik perl corsepiu,cweyl,iarnell,jplesnik,kasal,perl-sig,ppisar,psabata,spot
jussilehtola libint (none)
jzeleny scl-utils bkabrda,jzeleny
kanarip ruby bkabrda,jstribny,kanarip,mmorsi,mtasaka,skottler,tagoh,vondruch
kanarip rubygems kanarip,mtasaka,skottler,stahnma,vondruch
kwizart color-filesystem rhughes
limb drupal7 asrob,pfrields,siwinski
mmorsi jruby bkabrda,goldmann,vondruch
mstuchli pypy tomspur
msuchy rhn-client-tools mzazrive
nim fontpackages fonts-sig,frixxon,tagoh
orion hdf5 davidcl,pertusus
patches nodejs-packaging humaton,jamielinux,mrunge,sgallagh
patches nodejs-tap jamielinux
peter erlang-rpm-macros erlang-sig
petersen ghc-rpm-macros haskell-sig,petersen
phracek emacs jgu,phracek
pjones pesign (none)
pmatilai redhat-rpm-config jcm,pmatilai
ppisar perl-srpm-macros mmaslano,perl-sig
rdieter ggz-base-libs (none)
rdieter polkit-qt mbriza,rnovacek,than
remi php-horde-Horde-Role nb
rmattes ros-release (none)
rombobeorn fedora-gnat-project-common (none)
rstrode GConf2 walters
s4504kr blender fcami,hobbes1069,kwizart,roma
s4504kr gnustep-make s4504kr,salimma
smani keyrings-filesystem (none)
sochotni javapackages-tools java-sig,mizdebsk,msimacek,msrb
spot generic-release bruno
spot R salimma
than sip kkofler,ltinkl,rdieter
twaugh cups jpopelka
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
[perl-IPC-System-Simple/epel7] (5 commits) ...Update to 1.25
Summary of changes: 6d58c92... Perl 5.18 rebuild (*) b935bce... - Rebuilt for https://fedoraproject.org/wiki/Fedora_20_Mass (*) f62ffa1... Update to 1.23 (*) 17bad99... Update to 1.24 (*) 40163f7... Update to 1.25 (*) (*) This commit already existed in another branch; no separate mail sent -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-de...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[perl-autobox] Created tag perl-autobox-2.77-2.el7
The lightweight tag 'perl-autobox-2.77-2.el7' was created pointing to: bcfce90... - Rebuilt for https://fedoraproject.org/wiki/Fedora_19_Mass -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-de...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
Re: Fedora.NEXT Products and the fate of Spins
On Fri, 31 Jan 2014 10:53:17 -0800 Adam Williamson wrote: > > Personally, I know currently, most DEs' can be installed with yum > > groupinstall. But, that may not always be the case. > > I haven't seen any indication that anyone wants that to change as part > of .next. I do sincerely hope you are correct. ___ Regards, Frank www.frankly3d.com -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Fedora.NEXT Products and the fate of Spins
On Fri, 2014-01-31 at 11:22 +, Frank Murphy wrote: > On Fri, 31 Jan 2014 06:03:48 -0500 (EST) > Stephen Gallagher wrote: > > > What this does reveal is a bigger problem: that the audiences of at > > least some of the spins are not aware of this relationship to the > > larger Fedora ecosystem. This would indicate that the "dropping" or > > de-promoting the spins might lead the users of them to believe that > > the functionality they provided was removed from Fedora. While it is > > not a correct perception, it is nonetheless one that will occur (to > > some degree no matter how we advertise things) if some or all spins > > go away. It's a point that clearly merits consideration. > > As long as "audience" is kept informed I think most thing will be fine, > But, I'm am a bit worried by "some" who are of the opinion if not Gnome, > then dump it. Without the option to install any pkg that may not have > the G word in it's name or origin. > > Personally, I know currently, most DEs' can be installed with yum > groupinstall. But, that may not always be the case. I haven't seen any indication that anyone wants that to change as part of .next. What we're currently discussing is basically a deliverables question: what collections-of-packages-in-some-sort-of-lump do we want to release, under what names and branding, with what level of support, etc etc etc. But I haven't seen anything in even the most radical proposals which involves dumping non-Product bits from the repos. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net http://www.happyassassin.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
[Base] Meeting canceled for today
Apologies for the late notice everyone, but as i've been head of heels in tons of other work the past week and quite a few folks are either traveling or attending FOSDEM this weekend we're canceling the meeting today. Next week we'll have to see with a lot of people being at DevConf in Brno/CZ whether we can do a meeting or not, but i'll send out an notice on Thursday at the latest. Sorry again for the late note today. Thanks & regards, Phil -- Philipp Knirsch | Tel.: +49-711-96437-470 Manager Core Services| Fax.: +49-711-96437-111 Red Hat GmbH | Email: Phil Knirsch Wankelstrasse 5 | Web: http://www.redhat.com/ D-70563 Stuttgart, Germany -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Fedora.NEXT Products and the fate of Spins
On Fri, Jan 31, 2014 at 9:02 AM, Matthias Clasen wrote: I would be happy if Fedora moves towards being an OS, Red Hat Enterprise Linux comes in both Server and Workstation variants, among others. To continue to serve a useful role as upstream, I believe Fedora should be able to do *both* of these (and more). It hurts our downstream if we completely lose the server or client polish, and one has to be retrofitted after the fact. I think we *can* do both at the same time, while also not being a collection of packages. We can walk and chew bubble gum at the same time. To learn more about some technology I'm working on in that area, come to my devconf.cz talk =) -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Fedora.NEXT Products and the fate of Spins
On Fri, 2014-01-31 at 14:34 +0100, Lukáš Tinkl wrote: > Fedora isn't a Gnome OS, perhaps that's what they're trying to convey; > making it one will most probably create less confusion but I'm sure it > will also make us less relevant (my personal opinion). Not sure why that was necessary, but I'll answer anyway: I would be happy if Fedora moves towards being an OS, with a clear separation between system and applications, and a clear definition of what is part of the core system and what isn't. I don't think it makes sense to discuss products if we don't agree on that as a necessity. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Fedora.NEXT Products and the fate of Spins
On Fri, 31 Jan 2014 14:34:17 +0100 Lukáš Tinkl wrote: > Fedora isn't a Gnome OS, perhaps that's what they're trying to > convey; making it one will most probably create less confusion but > I'm sure it will also make us less relevant (my personal opinion). Currently it's not, it is a default DE, no problem there. ___ Frank www.frankly3d.com -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: rawhide builder issues?
On 01/31/2014 03:23 PM, Josh Boyer wrote: On Fri, Jan 31, 2014 at 8:16 AM, Dan Horák wrote: On Fri, 31 Jan 2014 08:10:49 -0500 Josh Boyer wrote: Hi, I've sent two builds of linux-firmware to koji this morning and both fail with a strange error in root.log/mock_output.log: ERROR: Command failed. See logs for output. # ['fedpkg', 'sources'] Downloading linux-firmware-20140131.tar.gz error: line 41: Double separator '-' in: iwl100-firmware-39.31.5.1-4: Obsoletes: iwl100-firmware < iwl100-firmware-39.31.5.1-4 must be Obsoletes: iwl100-firmware < 39.31.5.1-4 it's a new sanity check present in rpm in rawhide for eg. a week OK, thanks! Would have been nice if there was a heads up from the RPM people about that one. The error message is rather unhelpful considering it works fine in previous versions. The error message is bad indeed, will change it to something more easily comprehendable for 4.11.2 final. As for lack of a heads up for this, frankly I didn't expect to see it trip up anything in Fedora land as such dependencies are plain broken: In ranged dependencies the last part is always just an EVR version string, name does not belong there. While rpm version comparison will decide *something* on such a string, its almost certainly not what the packager intended. So apparently this is a highly useful and important sanity check, much more so than I expected :) - Panu - -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Fedora.NEXT Products and the fate of Spins
On Fri, 31 Jan 2014 08:20:18 -0500 Matthias Clasen wrote: > I've seen mails on this list recently where people proudly stated that > they would continue to advertise one particular spin at conferences > etc The current product is not Gnome, it is Fedora. And if asked about Xfce, which I solely use with Fedora. I will answer. ___ Regards, Frank www.frankly3d.com -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
gpodder update for f21
>From the release note request: gpodder is being upgraded from 2.20.3 to 3.5.2. There is a configuration and date storage change between these versions. After upgrading the RPM, any user on the system who uses gpodder, prior to opening it, should run /usr/bin/gpodder-migrate2tres, which will migrate the user's data and configuration to the new format, including all subscribed feeds and downloaded podcasts. 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 Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Fedora.NEXT Products and the fate of Spins
Dne 31.1.2014 14:20, Matthias Clasen napsal(a): On Fri, 2014-01-31 at 06:03 -0500, Stephen Gallagher wrote: What this does reveal is a bigger problem: that the audiences of at least some of the spins are not aware of this relationship to the larger Fedora ecosystem. This would indicate that the "dropping" or de-promoting the spins might lead the users of them to believe that the functionality they provided was removed from Fedora. While it is not a correct perception, it is nonetheless one that will occur (to some degree no matter how we advertise things) if some or all spins go away. It's a point that clearly merits consideration. The spins concept splits the community into small fiefdoms and creates unnecessary divisions. I've seen mails on this list recently where people proudly stated that they would continue to advertise one particular spin at conferences etc, regardless what the official Fedora products are. If that is how we advertise 'Fedora', it is not really a surprise that our users are unclear about what it really is... Fedora isn't a Gnome OS, perhaps that's what they're trying to convey; making it one will most probably create less confusion but I'm sure it will also make us less relevant (my personal opinion). -- Lukáš Tinkl Software Engineer - KDE desktop team, Brno KDE developer Red Hat Inc. http://cz.redhat.com -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: rawhide builder issues?
On Fri, Jan 31, 2014 at 8:16 AM, Dan Horák wrote: > On Fri, 31 Jan 2014 08:10:49 -0500 > Josh Boyer wrote: > >> Hi, >> >> I've sent two builds of linux-firmware to koji this morning and both >> fail with a strange error in root.log/mock_output.log: >> >> ERROR: Command failed. See logs for output. >> # ['fedpkg', 'sources'] >> Downloading linux-firmware-20140131.tar.gz >> error: line 41: Double separator '-' in: iwl100-firmware-39.31.5.1-4: >> Obsoletes: iwl100-firmware < iwl100-firmware-39.31.5.1-4 > > must be > Obsoletes: iwl100-firmware < 39.31.5.1-4 > > it's a new sanity check present in rpm in rawhide for eg. a week OK, thanks! Would have been nice if there was a heads up from the RPM people about that one. The error message is rather unhelpful considering it works fine in previous versions. josh -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Fedora.NEXT Products and the fate of Spins
On Fri, 2014-01-31 at 06:03 -0500, Stephen Gallagher wrote: > > What this does reveal is a bigger problem: that the audiences of at least > some of the spins are not aware of this relationship to the larger Fedora > ecosystem. This would indicate that the "dropping" or de-promoting the spins > might lead the users of them to believe that the functionality they provided > was removed from Fedora. While it is not a correct perception, it is > nonetheless one that will occur (to some degree no matter how we advertise > things) if some or all spins go away. It's a point that clearly merits > consideration. The spins concept splits the community into small fiefdoms and creates unnecessary divisions. I've seen mails on this list recently where people proudly stated that they would continue to advertise one particular spin at conferences etc, regardless what the official Fedora products are. If that is how we advertise 'Fedora', it is not really a surprise that our users are unclear about what it really is... -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
[perl-JavaScript-Minifier] 1.11 bump
commit bf573f4561ebee24c507160f5b28b6084d179a68
Author: Jitka Plesnikova
Date: Fri Jan 31 14:17:07 2014 +0100
1.11 bump
.gitignore|1 +
perl-JavaScript-Minifier.spec |8 +++-
sources |2 +-
3 files changed, 9 insertions(+), 2 deletions(-)
---
diff --git a/.gitignore b/.gitignore
index d515bac..e4ae037 100644
--- a/.gitignore
+++ b/.gitignore
@@ -2,3 +2,4 @@ JavaScript-Minifier-1.05.tar.gz
/JavaScript-Minifier-1.06.tar.gz
/JavaScript-Minifier-1.08.tar.gz
/JavaScript-Minifier-1.09.tar.gz
+/JavaScript-Minifier-1.11.tar.gz
diff --git a/perl-JavaScript-Minifier.spec b/perl-JavaScript-Minifier.spec
index 7b63e35..d81a9b1 100644
--- a/perl-JavaScript-Minifier.spec
+++ b/perl-JavaScript-Minifier.spec
@@ -1,5 +1,5 @@
Name: perl-JavaScript-Minifier
-Version:1.09
+Version:1.11
Release:1%{?dist}
Summary:Perl extension for minifying JavaScript code
License:GPL+ or Artistic
@@ -14,6 +14,9 @@ BuildRequires: perl(Exporter)
BuildRequires: perl(strict)
BuildRequires: perl(warnings)
# Tests
+BuildRequires: perl(File::Spec)
+BuildRequires: perl(IO::Handle)
+BuildRequires: perl(IPC::Open3)
BuildRequires: perl(Test::More)
Requires: perl(:MODULE_COMPAT_%(eval "`perl -V:version`"; echo $version))
@@ -47,6 +50,9 @@ make test
%{_mandir}/man3/*
%changelog
+* Fri Jan 31 2014 Jitka Plesnikova - 1.11-1
+- 1.11 bump
+
* Fri Jan 24 2014 Jitka Plesnikova - 1.09-1
- 1.09 bump
diff --git a/sources b/sources
index 4a9bd26..5c13647 100644
--- a/sources
+++ b/sources
@@ -1 +1 @@
-63f58ce5929780e3bd5273eeadd56b25 JavaScript-Minifier-1.09.tar.gz
+faada998749562628bc938a143014a34 JavaScript-Minifier-1.11.tar.gz
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-de...@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel
Re: rawhide builder issues?
On Fri, 31 Jan 2014 08:10:49 -0500 Josh Boyer wrote: > Hi, > > I've sent two builds of linux-firmware to koji this morning and both > fail with a strange error in root.log/mock_output.log: > > ERROR: Command failed. See logs for output. > # ['fedpkg', 'sources'] > Downloading linux-firmware-20140131.tar.gz > error: line 41: Double separator '-' in: iwl100-firmware-39.31.5.1-4: > Obsoletes: iwl100-firmware < iwl100-firmware-39.31.5.1-4 must be Obsoletes: iwl100-firmware < 39.31.5.1-4 it's a new sanity check present in rpm in rawhide for eg. a week Dan > error: query of specfile > /tmp/scmroot/linux-firmware/linux-firmware.spec failed, can't parse > > The line in question hasn't changed since June of 2012 and it builds > fine on F20 locally. > > To make things even more strange, I didn't get a build failure email > for either build. > > http://koji.fedoraproject.org/koji/taskinfo?taskID=6475080 > http://koji.fedoraproject.org/koji/taskinfo?taskID=6475160 > > An F20 build of literally the same Fedora git commit (F20/master > branches are in sync) builds fine: > > http://koji.fedoraproject.org/koji/taskinfo?taskID=6475213 > > Help? Confused... > > josh > -- > devel mailing list > devel@lists.fedoraproject.org > https://admin.fedoraproject.org/mailman/listinfo/devel > Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
rawhide builder issues?
Hi, I've sent two builds of linux-firmware to koji this morning and both fail with a strange error in root.log/mock_output.log: ERROR: Command failed. See logs for output. # ['fedpkg', 'sources'] Downloading linux-firmware-20140131.tar.gz error: line 41: Double separator '-' in: iwl100-firmware-39.31.5.1-4: Obsoletes: iwl100-firmware < iwl100-firmware-39.31.5.1-4 error: query of specfile /tmp/scmroot/linux-firmware/linux-firmware.spec failed, can't parse The line in question hasn't changed since June of 2012 and it builds fine on F20 locally. To make things even more strange, I didn't get a build failure email for either build. http://koji.fedoraproject.org/koji/taskinfo?taskID=6475080 http://koji.fedoraproject.org/koji/taskinfo?taskID=6475160 An F20 build of literally the same Fedora git commit (F20/master branches are in sync) builds fine: http://koji.fedoraproject.org/koji/taskinfo?taskID=6475213 Help? Confused... josh -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Fedora.NEXT Products and the fate of Spins
On 30 January 2014 23:07, Josh Boyer wrote: > On Thu, Jan 30, 2014 at 5:47 PM, Przemek Klosowski > wrote: >> On 01/29/2014 07:10 PM, Ian Malone wrote: >> >> On 29 January 2014 23:58, Josh Boyer wrote: >> >> I consider myself squarely in the middle of those two camps. I think >> they have value to people. I think they fill a niche, however large >> or small it might be. I also think they can be done by the people >> wishing to provide them without relying on Fedora resources for >> hosting and creation (outside of leveraging existing packages and >> repositories). >> >> I don't consider that "getting rid of them" at all. On the contrary, >> I think it lets people have more control over their spins, allows them >> to refresh them as they see fit throughout the release, and allows >> them to market and promote them beyond a token mention on a Fedora >> website. >> >> Some care is needed, if there are things getting packaged to fill a >> role in a spin they may disappear from Fedora if the spin in question >> does. >> >> On one hand, I am impressed by many spins as an excellent technology >> demonstration. On the other hand, what should existing users of a base >> Fedora do if they find an useful spin with a superior functionality? If its >> function is not integrated and easily accessible from the base system, they >> must either dual-boot or re-install from the spin. >> >> Therefore I prefer that the spins ultimate goal is to include the >> functionality into generic Fedora. The same goes for other bundling schemes >> discussed here. It's not that I object to them per se, but I do think that >> there's an opportunity cost involved: the person caring about the spin has >> to chose between working on integrating the spin functionality in generic >> Fedora, and developing the spin separately. I do recognize that the former >> is harder, but the opposite tack has a potential to fragment Fedora. Spins >> should be like branches in a VCS: let's not turn them into forks. >> >> I think the strength of Fedora comes from it being an excellent platform for >> all kinds of FOSS software, and the associated network effect---the better >> the platform is, the faster it gets better. > > "Spins" is a loaded term in Fedora that means exactly what you > suggest. An approved Spin, by definition, must only include packages > (and functionality) that is contained in the generic Fedora > repositories. So the project seems to very much agree with you. > > Remixes can contain external packages and have the pluses and minuses > that you highlight. Some of the discussion to date has been > suggesting or implying that "Spins" become "Remixes", but I think that > things that are already Spins would likely retain the qualities you > desire. The discussion has a lot of tribal knowledge behind it, so if > you aren't overly familiar with the history behind these concepts I > can see how it would be confusing. Indeed what Przemek Klosowski described (forking fedora) is what making all spins remixes might do. Concrete example: real-time audio. If left to its own devices a music production spin would probably do a realtime kernel and set priorites for jack on its own. However since whatever change was made had to apply to all fedora the result was that the default RT priority for jack was changed in the package (a realtime kernel not being necessarily required http://jackaudio.org/realtime_vs_realtime_kernel), so all Fedora JACK users get a better chosen default (though they still need to make manual changes to groups to benefit from it). -- imalone http://ibmalone.blogspot.co.uk -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Fedora.NEXT Products and the fate of Spins
On Fri, 31 Jan 2014 06:03:48 -0500 (EST) Stephen Gallagher wrote: > What this does reveal is a bigger problem: that the audiences of at > least some of the spins are not aware of this relationship to the > larger Fedora ecosystem. This would indicate that the "dropping" or > de-promoting the spins might lead the users of them to believe that > the functionality they provided was removed from Fedora. While it is > not a correct perception, it is nonetheless one that will occur (to > some degree no matter how we advertise things) if some or all spins > go away. It's a point that clearly merits consideration. As long as "audience" is kept informed I think most thing will be fine, But, I'm am a bit worried by "some" who are of the opinion if not Gnome, then dump it. Without the option to install any pkg that may not have the G word in it's name or origin. Personally, I know currently, most DEs' can be installed with yum groupinstall. But, that may not always be the case. If it ends up as not being the case, users may just want to code or whatever, without having to fight current distro to do so. It may be easier to boot: non-Fedora-livemedia/DE-of-choice. Carry on with your workflow. I hope the future proves me wrong, but I fear a too restrictive product, may increase the (user-base) emigration, not halt it. ___ Regards, Frank www.frankly3d.com -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: guided/interactive/scripted tutorials
On 30 January 2014 23:02, Richard Fearn wrote: >> You may have used this kind >> of thing - it tells you 'click this next' and waits until you do. >> As you might expect, googling for anything along these lines without >> having a very precise set of keywords only returns pages of tutorials. >> Any suggestions what to look for or, even better, tools in Fedora that >> can already do this appreciated. > > Eclipse calls these "cheat sheets": > > http://help.eclipse.org/kepler/index.jsp?topic=%2Forg.eclipse.platform.doc.user%2Freference%2Fref-cheatsheets.htm&cp=0_4_4_3_1 Thanks, that's the kind of thing. -- imalone http://ibmalone.blogspot.co.uk -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Fedora.NEXT Products and the fate of Spins
> On Jan 31, 2014, at 3:30 AM, Les Howell wrote: > >> On Thu, 2014-01-30 at 07:47 -0500, Christian Schaller wrote: >> >> >> >> - Original Message - >>> From: "Jaroslav Reznik" >>> To: "Development discussions related to Fedora" >>> >>> Sent: Thursday, January 30, 2014 1:25:10 PM >>> Subject: Re: Fedora.NEXT Products and the fate of Spins >>> >>> - Original Message - -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Apologies for the slightly alarmist $SUBJECT, but I want to make sure that this gets read by the appropriate groups. During today's FESCo meeting, there was the start of a discussion on how to approve new Products into the Fedora family. As part of this, it naturally strayed into discussion of what we do about Spins as they currently exist. Several ideas were raised (which I'll go through below), but we didn't feel that this was something that FESCo should answer on its own. We'd prefer community input on how to handle spins going forward. So, in no particular order (because it's difficult to say which questions are the most important): 1) Are Spins useful as they currently exist? There are many problems that have been noted in the Spins process, most notably that it is very difficult to get a Spin approved and then has no ongoing maintenance requiring it to remain functional. We've had Spins at times go through entire Fedora release cycles without ever being functional. >>> >>> Spins are useful especially as they makes our community inclusive, >>> one thing we should be proud about (and sometimes it was harder, could >>> cause issues but everything is solvable). >>> >>> For spins quality - it differs, it will differ but recent changes to >>> process were for good, more updates are still needed. Long time ago >>> we released what was build, I like how big step we did last few years. >>> It's not reason it wasn't functional before to ban spins. >>> >>> If there's interest in spins like product, someone is willing to lead >>> this effort, I think in some way, it can stay. >>> 2) Should Spins be eliminated entirely in favor of Fedora Remixes[1]. The effect here would be that Spins are no longer an official part of The Fedora Project but are instead projects unto themselves which are permitted to consume (possibly large) portions of our tools, packages and ecosystem. Maintenance and upkeep of these spins then becomes entirely the responsibility of the downstream community that constructs them and has no mandatory draw on Fedora's marketing, ambassadors or quality assurance resources. >>> >>> It's possible but much more resource hungry. The way how spins are set >>> helps these sub-projects deliver interesting piece of software. >>> >>> But there are two questions: >>> - does every single spin makes sense as standalone spin? I really liked >>> the idea of Fedora Formulas, it's exactly the way we should go. If for >>> some reason formulas would not be enough for desired use case -> remix. >>> >>> aka products + add-ons as formulas = spin >>> >>> For people who missed it https://fedoraproject.org/wiki/Fedora_formulas >> >> Well I think this idea is interesting and we have discussed something along >> these >> lines in the Workstation working group. I mean at the end of the day we all >> want as much >> software as possible packaged for Fedora/Product. The question to me lies in >> the details >> of how this is done. For instance the idea we hope to explore are we develop >> the technical >> specification for the workstation is what kind of rules should apply to >> these potential >> 'formulas'. There are some obvious ones like, you can't for instance in a >> 'formula' to replace a package >> that would break the core product for instance due to replacing a version of >> a package with one that >> got a different ABI. (This specific idea is quite well covered in existing >> Fedora guidelines, but I wanted to >> avoid derailing this discussion by choosing an example that I hope would >> generate discussion in itself :) >> >> >>> - or we could go even further and ask ourselves, do we want to call >>> products Fedora? Or do we want products as remixes too? Based on >>> underlying Fedora infrastructure? This could for example solve issues >>> with our values - 3rd party repos etc. >> >> Using the Fedora brand to only define a set of 'white box' packagesets is an >> option, >> but in some sense it means the end of 'Fedora' as a user facing brand. >> 3) Should Spins be considered Products-in-development? In other words, should we only approve Spins that are targeted or destined for "promotion" to a fully-supported Fedora Product? This is a nuanced question, as it means different things for different Spins, for example Spins focusing on a target-audience (Security Spin, Des
Critical Path: New Python version (2.7.6) in Rawhide
Hi, I have updated Python in Rawhide to version 2.7.6. The build is already tagged as f21. As far as I checked, the API/ABI should remain the same. Most patches applied neatly, only a few needed a rebase, and two were 1:1 incorporated upstream. If something Python-related starts acting up, try looking at this first, and if this version is indeed the cause, don't hesitate to untag the build and/or let me know, I will fix it. Cheers, -- Tomas Radej -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
