Re: fedora-release-$PRODUCT, /etc/issue, /etc/os-release, Per-Product Configs and more!

[William]

On Wed, 2014-07-02 at 20:40 -0700, Samuel Sieb wrote:
> On 07/02/2014 06:55 PM, William wrote:
> >
> >> First of all, I'd like to formally propose that each of the products
> >> will have a fedora-release-$PRODUCT (and corresponding
> >> generic-release-$PRODUCT) package. This package will meet several
> >> needs (with magical hand-waving in this initial email).
> >
> > How will this work with fedup from 20 to 21? Will there be multiple
> > upgrade targets?
> >
> Why would that be necessary?  All packages are in one repository, so 
> fedora-release-$PRODUCT will be upgraded to the next version and 
> everything will be fine.

My machine doesn't currently have a fedora-release-$PRODUCT package
installed. So how will fedup work out what one to put on my system? Will
these packages be added to 20, and the user need to preinstall before
fedup? 
-- 
William 

-- 
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-release-$PRODUCT, /etc/issue, /etc/os-release, Per-Product Configs and more!

[Samuel Sieb]

On 07/02/2014 06:55 PM, William wrote:



First of all, I'd like to formally propose that each of the products
will have a fedora-release-$PRODUCT (and corresponding
generic-release-$PRODUCT) package. This package will meet several
needs (with magical hand-waving in this initial email).


How will this work with fedup from 20 to 21? Will there be multiple
upgrade targets?

Why would that be necessary?  All packages are in one repository, so 
fedora-release-$PRODUCT will be upgraded to the next version and 
everything will be fine.

--
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: [ACTION REQUIRED][FINAL NOTICE] Retiring packages for Fedora 21 v4

[Robin Lee]

I would like to take this one:
espresso-aborphan, chitlesh

FAS ID: cheeselee

-robin


On Thu, Jul 3, 2014 at 3:48 AM, Till Maas  wrote:

> On Wed, Jul 02, 2014 at 06:49:23PM +0800, Christopher Meng wrote:
> > I'd like to take these 3:
> >
> > bitbakeixs
> > guile-lib  laxathom
> > rats   smilner, rmonk
>
> changed.
>
> Regards
> Till
> --
> 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: fedora-release-$PRODUCT, /etc/issue, /etc/os-release, Per-Product Configs and more!

[William]

> First of all, I'd like to formally propose that each of the products
> will have a fedora-release-$PRODUCT (and corresponding
> generic-release-$PRODUCT) package. This package will meet several
> needs (with magical hand-waving in this initial email).

How will this work with fedup from 20 to 21? Will there be multiple
upgrade targets? 

-- 
William 


signature.asc
Description: This is a digitally signed message part
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: I'll take tinyca2

[Till Maas]

On Wed, Jul 02, 2014 at 10:18:52PM +0200, Peter Hanecak wrote:

> b) it was mentioned as "orphaned" also in
> https://admin.fedoraproject.org/pkgdb/package/tinyca2/ (but IIRC only
> for "devel" branch - maybe that's "the bug")

According to fedmsg, Paul never became owner of tinyca2 for the master
branch:
https://apps.fedoraproject.org/datagrepper/raw?package=tinyca2

I guess there was/is a bug in the script to unretire packages.

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

Fedora ARM Status Meeting - Moving to Biweekly!

[Paul Whalen]

As discussed in the status meeting today, we will be moving to a biweekly
meeting in preparation for F21 Alpha. 

Our next meeting will be held on July 16th, 2014 at 4PM EDT (8PM UTC).

Please send anything you would like discussed to the ARM mailing list.

Regards, 
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

Fedora ARM Status Meeting Minutes - 2014-07-02

[Paul Whalen]

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



#fedora-meeting-1: Fedora ARM status meeting


Meeting summary
---
* 1) Kernel Status Update  (pwhalen, 20:07:46)
  * Peter's '3.15 Fedora ARM kernel status'  (pwhalen, 20:08:13)
  * LINK: http://nullr0ute.com/2014/06/3-15-fedora-arm-kernel-status/
(pwhalen, 20:08:13)
  * kernel testing needed on Utilite  (pwhalen, 20:10:03)
  * ACTION: pwhalen to file BZ on highbank crash with latest 3.16
kernels  (pwhalen, 20:11:08)

* 2a) F21 Alpha Status - Deliverables (Installation methods)  (pwhalen,
  20:14:07)
  * ACTION: pwhalen, dgilmore to follow up with jdisnard re: lorax &
pungi  (pwhalen, 20:19:32)

* 2b) F21 Alpha Status - Open ARM bugs  (pwhalen, 20:20:43)
  * dracut unable to boot 3.16 most of the time  (pwhalen, 20:21:57)
  * LINK: https://bugzilla.redhat.com/show_bug.cgi?id=1109603
(pwhalen, 20:22:03)
  * LINK: https://bugzilla.redhat.com/show_bug.cgi?id=1088933
(dgilmore, 20:29:12)
  * Bug 1088933 - update grubby to support device tree options for arm
(pwhalen, 20:29:35)
  * LINK: https://bugzilla.redhat.com/show_bug.cgi?id=1088933
(pwhalen, 20:29:41)

* 2c) F21 Alpha Status - Other Planning ?  (pwhalen, 20:30:42)

* 3) Aarch64 Status update  (pwhalen, 20:34:43)
  * The v8 package isn't built, blocking some packages. A v8 port for
aarch64 is available however.  Investigation ongoing.  (bconoboy,
20:40:59)
  * kernel-3.16.0-0.rc3.git1.1.fc21 should have all patches needed to
boot on mustang board  (bconoboy, 20:41:29)

* 4) Open Floor  (pwhalen, 20:43:06)
  * LINK: http://koji.fedoraproject.org/koji/packageinfo?packageID=15301
(dgilmore, 20:46:42)
  * ACTION: pwhalen to take over ownership of fedora-arm-installer
(pwhalen, 20:51:18)
  * If you want to make changes in packages for arm related things,
that's awesome. but please coordinate with the arm team. Please do
so by cc'ing the arm list on discussions and patches amd block the
arm tracker for bugs.  (pwhalen, 20:52:02)
  * LINK: https://bugzilla.redhat.com/show_bug.cgi?id=245418   (pwhalen,
20:52:27)
  * aarch64 tracker  (pwhalen, 20:53:09)
  * LINK: https://bugzilla.redhat.com/show_bug.cgi?id=922257   (pwhalen,
20:53:17)
  * Next Fedora ARM status meeting - July 16th  (pwhalen, 20:54:31)

Meeting ended at 20:55:11 UTC.




Action Items

* pwhalen to file BZ on highbank crash with latest 3.16 kernels
* pwhalen, dgilmore to follow up with jdisnard re: lorax & pungi
* pwhalen to take over ownership of fedora-arm-installer




Action Items, by person
---
* dgilmore
  * pwhalen, dgilmore to follow up with jdisnard re: lorax & pungi
* jdisnard
  * pwhalen, dgilmore to follow up with jdisnard re: lorax & pungi
* pwhalen
  * pwhalen to file BZ on highbank crash with latest 3.16 kernels
  * pwhalen, dgilmore to follow up with jdisnard re: lorax & pungi
  * pwhalen to take over ownership of fedora-arm-installer
* **UNASSIGNED**
  * (none)




People Present (lines said)
---
* dgilmore (88)
* pwhalen (74)
* bconoboy (28)
* zodbot (13)
* nirik (7)
* dmarlin (1)
* jsmith (1)
* msalter (0)
* jdisnard (0)
* pbrobinson (0)
* ctyler (0)
* jonmasters (0)
-- 
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: I'll take tinyca2

[Peter Hanecak]

Hello,

OK, than we found a bug, because:

a) Till Maas proclaimed it as orphaned in mail "[ACTION REQUIRED]
Retiring packages for Fedora 21 v3"

b) it was mentioned as "orphaned" also in
https://admin.fedoraproject.org/pkgdb/package/tinyca2/ (but IIRC only
for "devel" branch - maybe that's "the bug")


I have no problem being co-maintainer if you do not object. :)

If so, problem solved.


Sincerely

Peter


On 07/02/2014 09:58 PM, Paul Wouters wrote:
> On Wed, 2 Jul 2014, Peter Hanecak wrote:
> 
>>
>> I would like to take over tinyca2.
>>
>> I do not see anywhere on the list why the maintainers left it. So I'll
>> check the procedures and also other sources and take it.
>>
>> According to Koji[1], some F21 build was successful last month so
>> hopefully there wont be many difficulties.
> 
> huh? I re-instated tinyca2 a few months ago and am the active
> maintainer? I see you grabbed ACLs, so now you are co-maintainer
> whether you like it or not :)
> 
> Paul
> 



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

Re: I'll take tinyca2 (was Re: [ACTION REQUIRED] Retiring packages for Fedora 21 v3)

[Paul Wouters]

On Wed, 2 Jul 2014, Peter Hanecak wrote:



I would like to take over tinyca2.

I do not see anywhere on the list why the maintainers left it. So I'll
check the procedures and also other sources and take it.

According to Koji[1], some F21 build was successful last month so
hopefully there wont be many difficulties.


huh? I re-instated tinyca2 a few months ago and am the active
maintainer? I see you grabbed ACLs, so now you are co-maintainer
whether you like it or not :)

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

Re: Realted to "Fedora Release Engineering" is this OK?!!

[Till Maas]

On Tue, Jul 01, 2014 at 11:02:11PM +0200, مصعب الزعبي wrote:

> This commit add number after %{?dist} .. is this OK !!
> 
> http://pkgs.fedoraproject.org/cgit/gnulib.git/commit/?id=c2f0d77aba7a2b745886654c42c943f6a9c1a4b7
> 
> See full package name 
> 
> http://fr2.rpmfind.net//linux/RPM/fedora/devel/rawhide/src/g/gnulib-0-8.20140504git.fc21.1.src.html

It is normally only used if a package is only updated in Fedora 20 but
not Fedora 21 and the version and release are the same otherwise. But it
is also used by the script to increase the release automatically if the
release is too complex to increase it correctly otherwise.

Regards
Till
-- 
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: [ACTION REQUIRED][FINAL NOTICE] Retiring packages for Fedora 21 v4

[Till Maas]

On Wed, Jul 02, 2014 at 06:49:23PM +0800, Christopher Meng wrote:
> I'd like to take these 3:
> 
> bitbakeixs
> guile-lib  laxathom
> rats   smilner, rmonk

changed.

Regards
Till
-- 
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: [ACTION REQUIRED] Retiring packages for Fedora 21 v3

[Till Maas]

On Wed, Jul 02, 2014 at 12:38:10AM +0200, Sergio Pascual wrote:
> I thought I had retired correctly pywcs, but is not in the list. Did I miss
> some step?

The list contains only packages I am going to retire unless they are
taken care of. So if you retired a package, it is expected that the
package is not on the list. If you have further questions, be welcome to
ask.

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

I'll take tinyca2 (was Re: [ACTION REQUIRED] Retiring packages for Fedora 21 v3)

[Peter Hanecak]

Hello,

I would like to take over tinyca2.

I do not see anywhere on the list why the maintainers left it. So I'll
check the procedures and also other sources and take it.

According to Koji[1], some F21 build was successful last month so
hopefully there wont be many difficulties.

Sincerely

Peter

[1] http://koji.fedoraproject.org/koji/buildinfo?buildID=536751


On 06/24/2014 10:12 PM, Till Maas wrote:
> The following packages are orphaned or did not build for two
> releases and will be retired when Fedora (F21) is branched, unless someone
> adopts them. If you know for sure that the package should be retired, please 
> do
> so now with a proper reason:
> https://fedoraproject.org/wiki/How_to_remove_a_package_at_end_of_life
> 
> According to https://fedoraproject.org/wiki/Schedule branching will
> occur not earlier than 2014-07-08 (this is in *two* weeks). The packages
> will be retired shortly before.
> 
> Note: If you received this mail directly you (co)maintain one of the affected
> packages or a package that depends on one.
> 
>   Package(co)maintainers
> ===
> NearTree   tmatsuu  
> SOAPpy orphan, pingou   
> SteGUI orphan, pingou   
> aeolus-configure   orphan, clalance, jeckersb, mmorsi,  
>slinabery
> aleorphan, silfreed 
> alliance   chitlesh, tnorth 
> barry  orphan, gnat, vicodan
> bitbakeixs  
> blktap ke4qqq   
> cbmc   orphan, shakthimaan  
> cgnsliborphan, chitlesh 
> clutter-gtkmm  orphan, rhl  
> cx18-firmware  orphan, athimm   
> dee-qt orphan, jreznik  
> drwright   caillon  
> eclipse-cmakeedorphan, swagiaal 
> emacs-common-muse  orphan   
> emacs-identica-modeorphan, shakthimaan  
> eqntottorphan, chitlesh 
> espresso-aborphan, chitlesh 
> fprint_demoorphan, pingou   
> freetalk   orphan, rishi
> fuse-smb   szpak
> g-wrap laxathom 
> gdome2 orphan, sundaram 
> ghc-chalmers-lava2000  orphan, chitlesh 
> ghemical   orphan, tolland  
> gnome-shell-theme-elementary   orphan, eldermarco   
> gnomeradio orphan, itamarjp, roma   
> guile-lib  laxathom 
> ha-jdbcorphan   
> hdrpreporphan, silfreed 
> jbosscache-support orphan, arg  
> jbrout orphan   
> jchartsorphan   
> jdbm   orphan   
> jgroups212 orphan, arg  
> kannel thias, cicku, linuxthomass   
> libghemicalorphan   
> liboglappthorphan   
> minbar izhar, hicham
> mopac7 orphan   
> mozilla-firetray   hicham   
> mpqc   orphan   
> mule   orphan   
> nagios-plugins-check_sip   orphan   
> nesc   orphan, chitlesh 
>

Re: libgcrypt soname bump in rawhide

[Tomasz Torcz]

On Wed, Jul 02, 2014 at 06:03:33PM +0200, Kalev Lember wrote:
> On 07/02/2014 05:24 PM, Stephen Gallagher wrote:
> > -BEGIN PGP SIGNED MESSAGE-
> > Hash: SHA1
> > 
> > On 07/02/2014 11:22 AM, Stephen Gallagher wrote:
> >> On 07/02/2014 11:19 AM, Kalev Lember wrote:
> >>> On 07/02/2014 05:13 PM, Stephen Gallagher wrote:
>  This is not an official solution, but I am now providing a
>  COPR for Rawhide installs that provides a compatibility library
>  for libgcrypt.
> >>
> >>> That's awesome, but can we get this in rawhide proper instead?
> >>> I'd be happy to help get this through the review process if you
> >>> need a reviewer.
> >>
> >>
> >> Short answer: no. I don't have the time or inclination to attempt
> >> to maintain a compat *crypto* library. There's far too much
> >> possibility for disaster there.
> 
> Fair enough, that's totally understandable if you don't want to maintain
> a crypto library. I just had to ask :)
> 
> However, we've got a F21 release looming closer and I'd like to make
> sure major 3rd party apps keep working out of the box. And yes, this
> includes Chrome.
> 
> This is especially important since we don't have Chromium in the Fedora
> repositories; otherwise we could tell users to use that instead.

  In this specific case, users have two options:
– use Chromium from Spot's repository
– use Chromium from Russian Fedora repository

  Third option is:
– use compat libgcrypt from Stephen's repository.

  Those are not really different, but I suppose maintaining multiple
version of crypto library is worse.  Either way, it is up to Google
to provide precompiled software with up-to-date environment.

-- 
Tomasz Torcz   ,,(...) today's high-end is tomorrow's embedded processor.''
xmpp: zdzich...@chrome.pl  -- Mitchell Blank on LKML

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

Summary/Minutes from today's FESCo Meeting (2014-07-02)

[Kevin Fenzi]

===
#fedora-meeting: FESCO (2014-07-02)
===


Meeting started by nirik at 17:00:27 UTC. The full logs are available at
http://meetbot.fedoraproject.org/fedora-meeting/2014-07-02/fesco.2014-07-02-17.00.log.html
.



Meeting summary
---
* init process  (nirik, 17:00:27)

* #1178 Fedora 21 scheduling strategy  (nirik, 17:03:39)
  * LINK: https://fedorahosted.org/fesco/ticket/1178   (nirik, 17:03:40)
  * AGREED: if f21 alpha slips, we will slip 2 weeks to not conflict
with flock. (+8,0,0)  (nirik, 17:15:02)
  * will keep to the schedule for now, please revisit with additional
concerns  (nirik, 17:16:21)

* #1314 FESCo should grant product WGs the right to decide default
  services  (nirik, 17:17:16)
  * LINK: https://fedorahosted.org/fesco/ticket/1314   (nirik, 17:17:16)
  * AGREED: FESCo would like the Base WG to be responsible for defining
a minimum set of publicly-accessible services that define Fedora.
(This can be zero services if that is the decision) (+9,0,0)
(sgallagh, 17:26:45)
  * AGREED: FESCo grants WG's the right to decide default services
(+6,0,0)  (nirik, 17:30:23)

* #1310 Reconsidering rpcbind's exception allowing it to start by
  default  (nirik, 17:32:15)
  * LINK: https://fedorahosted.org/fesco/ticket/1310   (nirik, 17:32:15)
  * AGREED: rpcbind should not start by default. (+7,0,0)  (nirik,
17:40:33)

* #1311 Disable syscall auditing by default  (nirik, 17:42:19)
  * LINK: https://fedorahosted.org/fesco/ticket/1311   (nirik, 17:42:20)
  * this was decided last week, will update ticket with info.  (nirik,
17:45:09)

* #1318 shared-mime-info arbitration  (nirik, 17:45:15)
  * LINK: https://fedorahosted.org/fesco/ticket/1318   (nirik, 17:45:16)
  * AGREED: FESCo doesn’t require the fdatasync() behavior in F20
shared-mimo info to be modified (+6,+2,0)  (nirik, 18:05:44)

* #1321 Can packages not approved for Fedora be placed in non-official
  branches of the Fedora pkgs repo?  (nirik, 18:06:47)
  * LINK: https://fedorahosted.org/fesco/ticket/1321   (nirik, 18:06:47)
  * HELP: we sure could use a lot of enhancements to our tools to
support these ues cases  (mattdm, 18:11:43)
  * AGREED: do not use pkgs dist-git for changes not directly going into
official packages for now. Work with infrastructure to plan a git
for these uses, use fedorapeople or external services for now.
(+6,0,-2)  (nirik, 18:39:23)

* 1320 Proposal: trivial patch policy  (nirik, 18:39:31)
  * LINK: https://fedorahosted.org/fesco/ticket/1320   (nirik, 18:39:31)
  * AGREED: policy is approved (+6,0,0)  (nirik, 18:49:07)

* Next week's chair  (nirik, 18:50:55)
  * mattdm to chair next week  (nirik, 18:51:50)

* Open Floor  (nirik, 18:51:53)

Meeting ended at 18:57:25 UTC.




Action Items






Action Items, by person
---
* **UNASSIGNED**
  * (none)




People Present (lines said)
---
* nirik (162)
* mitr (66)
* abadger1999 (63)
* dgilmore (50)
* sgallagh (44)
* t8m (38)
* rdieter (27)
* kylem (24)
* mattdm (23)
* zodbot (16)
* pjones (14)
* jwb (5)
* smani (4)
* pingou (2)
* jreznik (2)
* blackbird (1)
* mmaslano (0)
--
17:00:27  #startmeeting FESCO (2014-07-02)
17:00:27  Meeting started Wed Jul  2 17:00:27 2014 UTC.  The chair is 
nirik. Information about MeetBot at http://wiki.debian.org/MeetBot.
17:00:27  Useful Commands: #action #agreed #halp #info #idea #link 
#topic.
17:00:27  #meetingname fesco
17:00:27  #chair abadger1999 dgilmore jwb kylem mattdm mitr mmaslano 
nirik pjones  sgallagh t8m
17:00:27  #topic init process
17:00:27  The meeting name has been set to 'fesco'
17:00:27  Current chairs: abadger1999 dgilmore jwb kylem mattdm mitr 
mmaslano nirik pjones sgallagh t8m
17:00:32  hello.
17:00:41  .hellomynameis sgallagh
17:00:42  sgallagh: sgallagh 'Stephen Gallagher' 
17:01:08  hello
17:01:17  szia
17:01:21  .hellowmynameis mattdm
17:01:42  .hellowmynameis pjones
17:01:44  Hello
17:01:56  (no w in hello :)
17:02:03  .hellomynameis pjones
17:02:04  pjones: pjones 'Peter Jones' 
17:02:17  yeah, totally works better if we don't copy-pasta eachother's 
misspelled "hello".
17:02:29  morning.
17:02:53  yay!
17:02:54  dgilmore / abadger1999 ?
17:03:32  ok, we have quorum I guess so we can go ahead and get started.
17:03:39  #topic #1178 Fedora 21 scheduling strategy
17:03:40  .fesco 1178
17:03:40  https://fedorahosted.org/fesco/ticket/1178
17:03:42  nirik: #1178 (Fedora 21 scheduling strategy) – FESCo - 
https://fedorahosted.org/fesco/ticket/1178
17:03:50  hola
17:04:01  there was a question here brought up by tflink who noticed 
that we are planning to release f21alpha right before flock.
17:04:19 * mattdm notes that he took benadryl after being stung by a wasp last 
night, and the brain fog is _just_ starting to wear off
17:04:28  mattdm: ouch. ;(
17:04:46  mattdm: Here, just sign this. No you don't need to read 
it...
17:04:49  so, the ques

Schedule for Thursday's FPC Meeting (2014-07-03 16:00 UTC)

[James Antill]

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

 Local time information (via. rktime):

2014-07-03 09:00 Thu US/Pacific PDT
2014-07-03 12:00 Thu US/Eastern EDT
2014-07-03 16:00 Thu UTC <-
2014-07-03 17:00 Thu Europe/London  BST
2014-07-03 18:00 Thu Europe/Paris  CEST
2014-07-03 18:00 Thu Europe/Berlin CEST
2014-07-03 21:30 Thu Asia/Calcutta  IST
--new day--
2014-07-04 00:00 Fri Asia/Singapore SGT
2014-07-04 00:00 Fri Asia/Hong_Kong HKT
2014-07-04 01:00 Fri Asia/Tokyo JST
2014-07-04 02:00 Fri Australia/Brisbane EST

 Links to all tickets below can be found at: 

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

= Followups =

(approval and retirement sections already passed, /opt exception passed,
basename passed)
#topic #339 software collections in Fedora
.fpc 339
https://fedorahosted.org/fpc/ticket/339

#topic #382 Go Packaging Guidelines Draft
.fpc 382
https://fedorahosted.org/fpc/ticket/382

(needs to be reworded to match new .desktop wording, req. license for
metadata)
#topic #414 Please consider requiring AppData for all desktop
applications
.fpc 414
https://fedorahosted.org/fpc/ticket/414

(dots in name, utility of ruby without rails)
#topic #419 ruby193 in SCL
.fpc 419
https://fedorahosted.org/fpc/ticket/419

(Packaging guidlines mention it, isn't cleaned by default) 
#topic #435 %py3dir not removed by rpmbuild --clean
.fpc 435
https://fedorahosted.org/fpc/ticket/435

(discussion around %ghost and need for %post macro)
#topic #439 update for Packaging:Tmpfiles.d
.fpc 439
https://fedorahosted.org/fpc/ticket/439

= New business =

#topic #440 mimeinfo scriptlet update
.fpc 440
https://fedorahosted.org/fpc/ticket/440


= Open Floor = 

 For more complete details, please visit each individual ticket.  The
report of the agenda items can be found at:

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


 If you would like to add something to this agenda, you can reply to
this e-mail, file a new ticket at https://fedorahosted.org/fpc,
e-mail me directly, or bring it up at the end of the meeting, during
the open floor topic. Note that added topics may be deferred until
the following meeting.
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: libgcrypt soname bump in rawhide

[Matthew Garrett]

On Thu, Jul 03, 2014 at 01:20:26AM +0800, Christopher Meng wrote:
> On Thu, Jul 3, 2014 at 1:11 AM, Matthew Garrett  wrote:
> > Maintaining software in general is a burden, but we do it for the
> > benefit of our users anyway. The best case scenario would certainly be
> > for Google to update their packages, but if they don't then how does
> > rendering the package uninstallable benefit our users who want to
> > install it?
> 
> I don't think they "don't" if you could give google-chrome-unstable a try.

I don't follow. My understanding was that all the Chrome builds were 
generic RPMs rather than tracking a specific branch of Fedora, so how 
does the rate of development releases do anything to help us get them to 
update their packages to build against a more recent gcrypt?

-- 
Matthew Garrett | mj...@srcf.ucam.org
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: fedora-release-$PRODUCT, /etc/issue, /etc/os-release, Per-Product Configs and more!

[Zbigniew Jędrzejewski-Szmek]

On Wed, Jul 02, 2014 at 09:47:26AM -0400, Miloslav Trmač wrote:
> - Original Message -
> > On Wed, Jul 02, 2014 at 10:38:15AM +0200, Karel Zak wrote:
> > >  It would be really really nice have only *one* file (/etc/os-release)
> > >  that contains operating system identification data. The mess like
> > >  /etc/fedora-release and /etc/redhat-release should be deprecated.
> > 
> > Yeah. The tricky thing is providing "sub-release" information when there's
> > just one file. Maybe something like "/etc/os-release.d/" could solve the
> > problem
> 
> It really seems to me that it’s way too early to generalize this into a 
> general mechanism we don’t really need, but would have to keep supporting for 
> years.  AFAICT a (probably Fedora-specific) patch to login(1) that 
> specifically hard-coded detection of a Fedora product, and added an 
> appropriate message in to contents of /etc/issue, would be a smaller 
> maintenance burden than any of the generic proposals, would work just as 
> well, and would give us a full freedom to change our mind about the 
> implementation later.

That's an unnecessary overcomplication too. Just put:

- /etc/issue --
-- \S{PRETTY_NAME} --
Kernel \r on an \m (\l)

---

and 

- /etc/os-release -
...
PRETTY_NAME="Fedora 21 server (Rawhide)"
...
---

Works as expected.

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

Fedora ARM Status Meeting 2014-07-02

[Paul Whalen]

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

On the agenda so far..

1) Kernel Status Update

2) F21 Alpha Status a) Deliverables (Installation methods)
b) Open ARM bugs 
c) Other Planning 

3) Aarch64 Status update 

4) Open Floor

If there is something that you would like to discuss that isn't mentioned
please feel free to bring it up at the end of the meeting or send an email
to the list.

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

Re: libgcrypt soname bump in rawhide

[Christopher Meng]

On Thu, Jul 3, 2014 at 1:11 AM, Matthew Garrett  wrote:
> On Thu, Jul 03, 2014 at 12:35:26AM +0800, Christopher Meng wrote:
>
>> It's a burden for downstream to ship such a compat- package for chrome
>> only, and chrome is not a part of Fedora.
>
> Maintaining software in general is a burden, but we do it for the
> benefit of our users anyway. The best case scenario would certainly be
> for Google to update their packages, but if they don't then how does
> rendering the package uninstallable benefit our users who want to
> install it?

I don't think they "don't" if you could give google-chrome-unstable a try.
-- 
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: libgcrypt soname bump in rawhide

[Matthew Garrett]

On Thu, Jul 03, 2014 at 12:35:26AM +0800, Christopher Meng wrote:

> It's a burden for downstream to ship such a compat- package for chrome
> only, and chrome is not a part of Fedora.

Maintaining software in general is a burden, but we do it for the 
benefit of our users anyway. The best case scenario would certainly be 
for Google to update their packages, but if they don't then how does 
rendering the package uninstallable benefit our users who want to 
install it?

-- 
Matthew Garrett | mj...@srcf.ucam.org
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: libgcrypt soname bump in rawhide

[Christopher Meng]

On Thu, Jul 3, 2014 at 12:22 AM, Kalev Lember  wrote:
> You must be confusing me with someone else. I am not a libgcrypt
> maintainer and haven't talked to Google about this.

No.

It's a burden for downstream to ship such a compat- package for chrome
only, and chrome is not a part of Fedora.

https://code.google.com/p/chromium/issues/detail?id=369973
-- 
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: libgcrypt soname bump in rawhide

[Kalev Lember]

On 07/02/2014 06:11 PM, Christopher Meng wrote:
> On Thu, Jul 3, 2014 at 12:03 AM, Kalev Lember  wrote:
>> Anyone here interested in maintaining a libgcrypt compat package for F21
>> lifetime? I'd be happy to help sort out packaging and get this through
>> the review process.
> 
> Have you got any response from Google actually?

You must be confusing me with someone else. I am not a libgcrypt
maintainer and haven't talked to Google about this.

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

Re: libgcrypt soname bump in rawhide

[Christopher Meng]

On Thu, Jul 3, 2014 at 12:03 AM, Kalev Lember  wrote:
> Anyone here interested in maintaining a libgcrypt compat package for F21
> lifetime? I'd be happy to help sort out packaging and get this through
> the review process.

Have you got any response from Google actually?
-- 
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: libgcrypt soname bump in rawhide

[Kalev Lember]

On 07/02/2014 05:24 PM, Stephen Gallagher wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
> 
> On 07/02/2014 11:22 AM, Stephen Gallagher wrote:
>> On 07/02/2014 11:19 AM, Kalev Lember wrote:
>>> On 07/02/2014 05:13 PM, Stephen Gallagher wrote:
 This is not an official solution, but I am now providing a
 COPR for Rawhide installs that provides a compatibility library
 for libgcrypt.
>>
>>> That's awesome, but can we get this in rawhide proper instead?
>>> I'd be happy to help get this through the review process if you
>>> need a reviewer.
>>
>>
>> Short answer: no. I don't have the time or inclination to attempt
>> to maintain a compat *crypto* library. There's far too much
>> possibility for disaster there.

Fair enough, that's totally understandable if you don't want to maintain
a crypto library. I just had to ask :)

However, we've got a F21 release looming closer and I'd like to make
sure major 3rd party apps keep working out of the box. And yes, this
includes Chrome.

This is especially important since we don't have Chromium in the Fedora
repositories; otherwise we could tell users to use that instead.

I feel like this is our (Fedora's) responsibility to provide a libgcrypt
compat package, since it's been part of standard ABI for a while and 3rd
party packages are likely to rely on it. In my book, it's fine to phase
a widely used ABI out, but not pull the plug in a single release.

It's unreasonable to ask 3rd party developers to follow Rawhide closely
and port stuff while F21 is still under development. A much better 3rd
party developer story would be saying:

  "Hi Mr. 3rd Party Developer, we've released F21 today with a new
   libcrypt. We'll remove old libcrypt in F22 but we are providing ABI
   compatiblity for F21 lifetime; you have 6 months to port your stuff."

Anyone here interested in maintaining a libgcrypt compat package for F21
lifetime? I'd be happy to help sort out packaging and get this through
the review process.

> To clarify: in my COPR, it's use-at-your-own-risk. If we moved it to
> Rawhide, I'm on the hook to make sure it's constantly kept up-to-date
> and keep track of vulnerabilities. I'm not prepared to take that level
> of ownership on. I only built this COPR because I was updating to
> Rawhide today and this bit me. I'm being nice and sharing it, with the
> expectation that it's really only meant for this singular use-case,
> which should be obsoleted as soon as Google moves to the newer
> libgcrypt (or bundles their own, whatever).

I'm afraid that this could lead to technically capable people using your
copr because it provides an easy way out, and leaving others out in the
cold. People who'd be able to fix this in rawhide proper switch to using
your copr, and end users who expect point and click Chrome installation
to work are going to be disappointed and look for alternatives.

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

Re: [ACTION REQUIRED][FINAL NOTICE] Retiring packages for Fedora 21 v4

[Richard W.M. Jones]

On Tue, Jul 01, 2014 at 07:55:42PM +0200, Till Maas wrote:
> 
> The following packages are orphaned or did not build for two
> releases and will be retired when Fedora (F21) is branched, unless someone
> adopts them. If you know for sure that the package should be retired, please 
> do
> so now with a proper reason:
> https://fedoraproject.org/wiki/How_to_remove_a_package_at_end_of_life
> 
> According to https://fedoraproject.org/wiki/Schedule branching will
> occur on 2014-07-08. The packages will be retired starting 2014-07-04.
> If you intend to claim a package, please take it now.
> 
> Note: If you received this mail directly you (co)maintain one of the affected
> packages or a package that depends on one.
> 
>   Package(co)maintainers
> ===
[...]
> mule   orphan, tspauld98

The upstream developer turned up on devel last week wishing to
maintain this package.  He is not a packager yet.  Can it be saved?

(Alternatively, perhaps it could do with a re-review ...)

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
virt-builder quickly builds VMs from scratch
http://libguestfs.org/virt-builder.1.html
-- 
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: libgcrypt soname bump in rawhide

[Stephen Gallagher]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 07/02/2014 11:22 AM, Stephen Gallagher wrote:
> On 07/02/2014 11:19 AM, Kalev Lember wrote:
>> On 07/02/2014 05:13 PM, Stephen Gallagher wrote:
>>> This is not an official solution, but I am now providing a
>>> COPR for Rawhide installs that provides a compatibility library
>>> for libgcrypt.
> 
>> That's awesome, but can we get this in rawhide proper instead?
>> I'd be happy to help get this through the review process if you
>> need a reviewer.
> 
> 
> Short answer: no. I don't have the time or inclination to attempt
> to maintain a compat *crypto* library. There's far too much
> possibility for disaster there.
> 

To clarify: in my COPR, it's use-at-your-own-risk. If we moved it to
Rawhide, I'm on the hook to make sure it's constantly kept up-to-date
and keep track of vulnerabilities. I'm not prepared to take that level
of ownership on. I only built this COPR because I was updating to
Rawhide today and this bit me. I'm being nice and sharing it, with the
expectation that it's really only meant for this singular use-case,
which should be obsoleted as soon as Google moves to the newer
libgcrypt (or bundles their own, whatever).
-BEGIN PGP SIGNATURE-
Version: GnuPG v1
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iEYEARECAAYFAlO0JDcACgkQeiVVYja6o6NLSgCfQVvwmyK+szYOCSq8O35H/wtx
1J4An0VYxt3tSGteebrzwOWQMwy434GH
=jSLy
-END PGP SIGNATURE-
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: libgcrypt soname bump in rawhide

[Stephen Gallagher]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 07/02/2014 11:19 AM, Kalev Lember wrote:
> On 07/02/2014 05:13 PM, Stephen Gallagher wrote:
>> This is not an official solution, but I am now providing a COPR
>> for Rawhide installs that provides a compatibility library for
>> libgcrypt.
> 
> That's awesome, but can we get this in rawhide proper instead? I'd
> be happy to help get this through the review process if you need a
> reviewer.
> 

Short answer: no. I don't have the time or inclination to attempt to
maintain a compat *crypto* library. There's far too much possibility
for disaster there.
-BEGIN PGP SIGNATURE-
Version: GnuPG v1
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iEYEARECAAYFAlO0I7MACgkQeiVVYja6o6PIEQCgkV/CpCi43z25Nz/W1y+dpDsP
C2IAoICVySLOxqhJFSrxVxxv2CY08tdv
=TomH
-END PGP SIGNATURE-
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: libgcrypt soname bump in rawhide

[Christopher Meng]

On Wed, Jul 2, 2014 at 11:19 PM, Kalev Lember  wrote:
> On 07/02/2014 05:13 PM, Stephen Gallagher wrote:
>> This is not an official solution, but I am now providing a COPR for
>> Rawhide installs that provides a compatibility library for libgcrypt.
>
> That's awesome, but can we get this in rawhide proper instead? I'd be
> happy to help get this through the review process if you need a reviewer.

Why not blame Google to update their environments??
-- 
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: libgcrypt soname bump in rawhide

[Kalev Lember]

On 07/02/2014 05:13 PM, Stephen Gallagher wrote:
> This is not an official solution, but I am now providing a COPR for
> Rawhide installs that provides a compatibility library for libgcrypt.

That's awesome, but can we get this in rawhide proper instead? I'd be
happy to help get this through the review process if you need a reviewer.

-- 
Thanks,
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

Re: libgcrypt soname bump in rawhide

[Stephen Gallagher]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 02/28/2014 02:37 PM, Richard Hughes wrote:
> On 28 February 2014 15:38, Tomas Mraz  wrote:
>> This should not break builds of any reasonably current software.
> 
> libgcrypt.so.11()(64bit) is needed by (installed) 
> google-chrome-stable-33.0.1750.117-1.x86_64
> 
> I guess not much we can do there, other than maintain a compat
> package -- right? :(


This is not an official solution, but I am now providing a COPR for
Rawhide installs that provides a compatibility library for libgcrypt.
Note: I have not tested it for any use other than making sure that
Google Chrome runs with it. I will try to keep it updated with any
security updates that come out for F20, but I make no promises. Use at
your own risk.

For the record, I am currently running successfully on Rawhide with
Google Chrome.


(For the record, this does not replace the standard libgcrypt; it
supplements it. So anything built normally in Koji will be linked with
the updated .so.20 version).


> 
> Richard.
> 

-BEGIN PGP SIGNATURE-
Version: GnuPG v1
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iEYEARECAAYFAlO0IY4ACgkQeiVVYja6o6MCUACfbARjh/JlrX2Kd/40SzHYdJVm
nmgAn3wcxXSUa15VX2cAIT651ZQLi6D+
=XlIR
-END PGP SIGNATURE-
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: delta rpms - can we turn them off

[John Reiser]

> Doesn't the current process assume that xz always produces the same
> output?

Yes, the deltarpm process depends on xz giving the same output
when run by the consumer of the .drpm as when run by the producer.
If not, then deltarpm gives a warning and ignores the .drpm --
the entire new .rpm must be downloaded.

> 
> What would happen if a newer version of xz/lzma comes out which (for
> example) produces better compressed output while still remaining
> compatible with the file format and older decompression tools?

Then there would be a "one-time" event where none of the .drpm
could be used, until xz on the consumer machine matches (catches up to)
xz on the producer machine.
-- 
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: delta rpms - can we turn them off

[Reindl Harald]

Am 02.07.2014 16:46, schrieb Richard W.M. Jones:
> Doesn't the current process assume that xz always 
> produces the same output?

hopefully not

> What would happen if a newer version of xz/lzma comes out which (for
> example) produces better compressed output while still remaining
> compatible with the file format and older decompression tools?

XZ and BZ2 seems to have predictable results

but it's just dangerous to assume that will be forever true
and as you can see below with gzip you have *always*
different results for the same data

not sure about XZ, other compressors support different
levels and so if you change decisions in favour to
size/performance you are already lost if you can't
make sure that the rebuild process is using the same

[harry@srv-rhsoft:~/Desktop]$ tar -p -cJf 1.tar.xz test.bin
[harry@srv-rhsoft:~/Desktop]$ tar -p -cJf 2.tar.xz test.bin
[harry@srv-rhsoft:~/Desktop]$ tar -p -cJf 3.tar.xz test.bin
[harry@srv-rhsoft:~/Desktop]$ tar -p -cJf 4.tar.xz test.bin
[harry@srv-rhsoft:~/Desktop]$ tar -p -cJf 5.tar.xz test.bin
[harry@srv-rhsoft:~/Desktop]$ md5sum *.xz
244b1e8e64686007acec1cc17928223c  1.tar.xz
244b1e8e64686007acec1cc17928223c  2.tar.xz
244b1e8e64686007acec1cc17928223c  3.tar.xz
244b1e8e64686007acec1cc17928223c  4.tar.xz
244b1e8e64686007acec1cc17928223c  5.tar.xz

[harry@srv-rhsoft:~/Desktop]$ tar -p -cjf 1.tar.bz2 test.bin
[harry@srv-rhsoft:~/Desktop]$ tar -p -cjf 2.tar.bz2 test.bin
[harry@srv-rhsoft:~/Desktop]$ tar -p -cjf 3.tar.bz2 test.bin
[harry@srv-rhsoft:~/Desktop]$ tar -p -cjf 4.tar.bz2 test.bin
[harry@srv-rhsoft:~/Desktop]$ tar -p -cjf 5.tar.bz2 test.bin
[harry@srv-rhsoft:~/Desktop]$ md5sum *.bz2
10abef602d3eba260b97c339a40936e8  1.tar.bz2
10abef602d3eba260b97c339a40936e8  2.tar.bz2
10abef602d3eba260b97c339a40936e8  3.tar.bz2
10abef602d3eba260b97c339a40936e8  4.tar.bz2
10abef602d3eba260b97c339a40936e8  5.tar.bz2

[harry@srv-rhsoft:~/Desktop]$ tar -p -czf 1.tar.gz test.bin
[harry@srv-rhsoft:~/Desktop]$ tar -p -czf 2.tar.gz test.bin
[harry@srv-rhsoft:~/Desktop]$ tar -p -czf 3.tar.gz test.bin
[harry@srv-rhsoft:~/Desktop]$ tar -p -czf 4.tar.gz test.bin
[harry@srv-rhsoft:~/Desktop]$ tar -p -czf 5.tar.gz test.bin
[harry@srv-rhsoft:~/Desktop]$ md5sum *.gz
8f132cafffe6d7a613a480a5e593abc8  1.tar.gz
3cf402bbbde27db631a2896af9365275  2.tar.gz
5cb1fc9f6628a41d71572862ea4c19a1  3.tar.gz
bd51a4779ca4e2e9377488dc64ccaf1c  4.tar.gz
5506a0cfbf39cb28b05babba6755049a  5.tar.gz




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

Re: Handling package conflicts caused by arch specific doc files

[Kalev Lember]

On 07/02/2014 03:15 PM, Ankur Sinha wrote:
> I was wondering if there's a standard way of solving package conflicts
> that arise from arch specific doc files. An example is here:
> 
> https://bugzilla.redhat.com/show_bug.cgi?id=565676
> 
> The conflict is because the docs are generated during the build, and the
> files, even though they are installed in the same location, differ.

My personal take on this is that multilibbed -devel packages are rarely
tested and largely useless. Most people use mock (or some other chroot
mechanism or a VM) for building 32 bit packages on 64 bit hosts instead.

Multilibbing libs makes a lot of sense, but -devel packages, not so
much. I wonder how many users would miss this if we were to blacklist
all -devel packages in mash.

Anyway, having said that, I've hopefully now fixed it in
libchamplain-0.12.8-1.fc21 build.

-- 
Hope this helps,
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

Re: delta rpms - can we turn them off

[Jonathan Dieter]

This has already happened once before a few years back.  IIRC, we 
updated xz on the builder to match the one in Fedora, but our users had 
broken deltarpms until they got the updated xz.


Jonathan

On 07/02/2014 07:46 AM, Richard W.M. Jones wrote:

Doesn't the current process assume that xz always produces the same
output?

What would happen if a newer version of xz/lzma comes out which (for
example) produces better compressed output while still remaining
compatible with the file format and older decompression tools?

Rich.



--
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-release-$PRODUCT, /etc/issue, /etc/os-release, Per-Product Configs and more!

[Richard W.M. Jones]

On Mon, Jun 30, 2014 at 03:44:26PM -0400, Stephen Gallagher wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
> 
> On 06/30/2014 03:39 PM, Lennart Poettering wrote:
> > On Mon, 30.06.14 14:59, Stephen Gallagher (sgall...@redhat.com)
> > wrote:
> > 
> >> 2) The fedora-release-$PRODUCT package (and possibly %post or
> >> systemd snippets therein) will be responsible for the creation
> >> and maintenance of /etc/issue, /etc/os-release and
> >> /etc/fedora-release-product (note: there is no $ there. That's
> >> the literal name. This file will be equivalent to
> >> /etc/fedora-release except that it will include the Product
> >> name.
> > 
> > Probably quite unrelated to the actual topic of this thread, but I
> > just wanted to mention that we intend to move /etc/os-release to 
> > /usr/lib/os-release (and make /etc/os-release a symlink). We are
> > working on making factory reset/stateless stuff work on Fedora, and
> > this actually turned out to be one of the surprisingly few
> > incomptibilities (the two other being dbus and PAM) we ran into.
> > Placing this in /usr/lib is certainly the most appropriate place
> > for it, after all it describes what /usr actually contains, not
> > what /etc contains...
> > 
> > Anyway, just wanted to mention this. We will soon upload a new
> > systemd release to Rawhide, that prepares everything for moving the
> > file, will then file a bug against fedora-release asking for the
> > file to be moved.
> 
> 
> Sure, the real-world location of this file is pretty much immaterial,
> as long as we get it created properly.

Provided the symlink remains in place for a very long time ...

> Any chance that systemd wants to build a hostnamectl-like interface
> for setting the os-release values? That would make life a lot easier
> on us, as we could reconfigure that file if-and-when a
> fedora-release-$PRODUCT package was installed in a %post snippet.

As long as you don't require running special programs in order to make
changes to what are basically configuration files.

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
virt-builder quickly builds VMs from scratch
http://libguestfs.org/virt-builder.1.html
-- 
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: delta rpms - can we turn them off

[Richard W.M. Jones]

Doesn't the current process assume that xz always produces the same
output?

What would happen if a newer version of xz/lzma comes out which (for
example) produces better compressed output while still remaining
compatible with the file format and older decompression tools?

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
virt-top is 'top' for virtual machines.  Tiny program with many
powerful monitoring features, net stats, disk stats, logging, etc.
http://people.redhat.com/~rjones/virt-top
-- 
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: Koschei - continuous rebuilds for packages

[Petr Pisar]

On 2014-07-02, jpac...@redhat.com  wrote:
>> The rebuilds run in koji. You cannot get scratch build into koji build
>> root. You would need separate koji build target tag for that.
>
> I understood that Koschei does it anyway (to be able to rebuild the
> dependency subtree).

Speculation: Or it doesn't. Maybe it submits the rebuilds in dependency
order but it does the builds against vanilla koji repository. And that's
all only to prevent from continuing in rebuilding reverse dependecies if
a package has failed.

> Either way, it doesn't sound problematic to create
> temporary tags (although I'm not sure about performance penalty).
>
I worry the Koschei is just a packager-space tool without any
koji-releng-priviledges for creating tags. I heard using offical koji
instance is one of the design decisions.

Maybe perl-Fedora-Rebuild could satisfy your desire. It can do dependency
ordered bootstrap in mock or in koji. (Bootstrap means you define
a pattern for a dependency symbols of interest, e.g. /perl\([^)]*\)/,
and then the build order is computed on this constrained set of
dependecies starting from empty set---thus the bootstrap.)

-- Petr

-- 
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: Heads-up on rpm 4.12 coming to rawhide soon

[Florian Festi]

On 07/02/2014 03:05 PM, Igor Gnatenko wrote:
> Where I can read more about weak dependencies?

Have a look at my announcement I made in February:

https://lists.fedoraproject.org/pipermail/devel/2014-February/195743.html

Be aware that rpm-4.12 only implements the weak dependencies. Having
support in RPM is also only the first step for getting it into Fedora.
Support is needed throughout the packaging stack. As soon as all pieces
are in place and are well tested the FPC needs to come up with a policy
on how they should be used.

Florian


> --
> -Igor Gnatenko
> 
> On Jun 27, 2014 7:38 PM, "Panu Matilainen"  > wrote:
> 
> 
> Hi all,
> 
> Rpm 4.12 alpha just got released:
> http://lists.rpm.org/__pipermail/rpm-announce/2014-__June/45.html 
> 
> 
> The plan is to update rawhide to this shiny new version first thing
> on Monday morning and babysit as needed (ie the usual drill), but if
> you're feeling bored over the weekend or its as rainy wherever you
> live as it is in here now, and you're feeling a little bit brave,
> give it a spin in the meanwhile:
> 
> https://copr.fedoraproject.__org/coprs/pmatilai/rpm-__snapshot/
> 
> 
> The copr packages are for rawhide only and should be very close to
> what goes into rawhide on Monday. If you're dying to test but not
> willing to rawhide all the way, they can be used on F20 too if you
> 1) install perl-generators from rawhide
> 2) remove rpm-python3 package before updating
> 
> As the announcement says, there are some rough edges still (as in,
> there's a reason its alpha). I run it on my systems and it's not
> expected to eat anybody (or their systems) alive, but do pay
> attention...
> 
> Bug reports and other feedback welcome.
> 
> - 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
> 
> 
> 
> 


-- 

Red Hat GmbH, http://www.de.redhat.com/ Registered seat: Grasbrunn,
Commercial register: Amtsgericht Muenchen, HRB 153243,
Managing Directors: Charles Cachera, Michael Cunningham, Michael
O'Neill, Charles Peters
-- 
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: Koschei - continuous rebuilds for packages

[Michael Simacek]

- Original Message -
> From: jpac...@redhat.com
> To: devel@lists.fedoraproject.org
> Sent: Tuesday, July 1, 2014 5:41:45 PM
> Subject: Re: Koschei - continuous rebuilds for packages
> 
> Hi Michael,
> 
> it sounds like a way how one could automatically handle library so-bumps
> in rawhide. Idea discussed with hhorak, jzeleny, pingou and others was
> to bump the library package, rebuild the dependency tree depending on
> this library and if some of them fail, notify it's maintainer(s) and the
> bumped library owner as well (email CC should be sufficient). If it
> doesn't fail, we can automatically immediately rebuild it in non-scratch
> environment. This'll save so much time and effort and also suppress the
> need for finding maintainers of the library and notifying them about the
> so-bump.
> 
> So the question regarding Koschei is if one could schedule one-shot
> build of a library package (preferably from CLI) and if one could get
> the result of such run on CLI (allowing automation). The CLI tool would
> be just thin wrapper around remote interface (JSONRPC/XMLRPC/...). Do
> Koschei have such interface?

I can consider it a a future feature, but I'm not sure whether I completely
undestand the exact process. Detecting soname bumps and doing real rebuilds
instead of scratch build should be possible. Koschei could automatically start
rebuilding dependent packages AFTER you update the library in rawhide. But if
you want to know what will break before you do the update then it will be
more complicated, because Koschei will need to manage separate Koji tags and
obviously first get permission to do so and I'm not sure whether relengs would
be willing to make this happen. And for both solutions Koschei would need to get
provenpackager-like priviledges to be able to bump the release. Regarding remote
interface - there is none, but I can make it as soon as it's needed. I didn't
have use case for it yet.

> 
> Kind regards,
> 
> -- Jan Pacner
> --
> 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: fedora-release-$PRODUCT, /etc/issue, /etc/os-release, Per-Product Configs and more!

[Miloslav Trmač]

- Original Message -
> On Wed, Jul 02, 2014 at 10:38:15AM +0200, Karel Zak wrote:
> >  It would be really really nice have only *one* file (/etc/os-release)
> >  that contains operating system identification data. The mess like
> >  /etc/fedora-release and /etc/redhat-release should be deprecated.
> 
> Yeah. The tricky thing is providing "sub-release" information when there's
> just one file. Maybe something like "/etc/os-release.d/" could solve the
> problem

It really seems to me that it’s way too early to generalize this into a general 
mechanism we don’t really need, but would have to keep supporting for years.  
AFAICT a (probably Fedora-specific) patch to login(1) that specifically 
hard-coded detection of a Fedora product, and added an appropriate message in 
to contents of /etc/issue, would be a smaller maintenance burden than any of 
the generic proposals, would work just as well, and would give us a full 
freedom to change our mind about the implementation later.
Mirek
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: fedora-release-$PRODUCT, /etc/issue, /etc/os-release, Per-Product Configs and more!

[Matthew Miller]

On Wed, Jul 02, 2014 at 10:38:15AM +0200, Karel Zak wrote:
>  Note that agetty(8) allows to keep /etc/issue distribution
>  independent and it reads all necessary information from
>  /etc/os-release to generate the final pre-login message. All you need
>  is to create /etc/issue with \S sequences, for example:
>\S{PRETTY_NAME}
>\S{HOME_URL}
>Kernel \r on an \m (\l)
>  .. so /etc/issue does not have to be maintained within packages like
>  fedora-release-$PRODUCT or so.

Oh, that's nice. I just learned yesterday that it has all of those fancy new
escapes.

>  It would be really really nice have only *one* file (/etc/os-release)
>  that contains operating system identification data. The mess like
>  /etc/fedora-release and /etc/redhat-release should be deprecated.

Yeah. The tricky thing is providing "sub-release" information when there's
just one file. Maybe something like "/etc/os-release.d/" could solve the
problem

-- 
Matthew Miller

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

Handling package conflicts caused by arch specific doc files

[Ankur Sinha]

Hi,

I was wondering if there's a standard way of solving package conflicts
that arise from arch specific doc files. An example is here:

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

The conflict is because the docs are generated during the build, and the
files, even though they are installed in the same location, differ.
-- 
Thanks,
Warm regards,
Ankur (FranciscoD)

http://fedoraproject.org/wiki/User:Ankursinha

Join Fedora! Come talk to us!
http://fedoraproject.org/wiki/Fedora_Join_SIG



signature.asc
Description: This is a digitally signed message part
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Heads-up on rpm 4.12 coming to rawhide soon

[Igor Gnatenko]

Where I can read more about weak dependencies?
--
-Igor Gnatenko
On Jun 27, 2014 7:38 PM, "Panu Matilainen"  wrote:

>
> Hi all,
>
> Rpm 4.12 alpha just got released: http://lists.rpm.org/
> pipermail/rpm-announce/2014-June/45.html
>
> The plan is to update rawhide to this shiny new version first thing on
> Monday morning and babysit as needed (ie the usual drill), but if you're
> feeling bored over the weekend or its as rainy wherever you live as it is
> in here now, and you're feeling a little bit brave, give it a spin in the
> meanwhile:
>
> https://copr.fedoraproject.org/coprs/pmatilai/rpm-snapshot/
>
> The copr packages are for rawhide only and should be very close to what
> goes into rawhide on Monday. If you're dying to test but not willing to
> rawhide all the way, they can be used on F20 too if you
> 1) install perl-generators from rawhide
> 2) remove rpm-python3 package before updating
>
> As the announcement says, there are some rough edges still (as in, there's
> a reason its alpha). I run it on my systems and it's not expected to eat
> anybody (or their systems) alive, but do pay attention...
>
> Bug reports and other feedback welcome.
>
> - 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
-- 
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: Koschei - continuous rebuilds for packages

[jpac...@redhat.com]

Hi Petr,

> The rebuilds run in koji. You cannot get scratch build into koji build
> root. You would need separate koji build target tag for that.

I understood that Koschei does it anyway (to be able to rebuild the
dependency subtree). Either way, it doesn't sound problematic to create
temporary tags (although I'm not sure about performance penalty).

-- Jan Pacner
-- 
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: [ACTION REQUIRED][FINAL NOTICE] Retiring packages for Fedora 21 v4

[Christopher Meng]

I'd like to take these 3:

bitbakeixs
guile-lib  laxathom
rats   smilner, rmonk
-- 
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: Tasklist for the Fedora Workstation

[Marcela Mašláňová]

On 06/25/2014 06:55 PM, Christian Schaller wrote:

Hi everyone,
As we are ramping up the development effort around the workstation we wanted to 
help increase transparency and enable more community participation in the 
Fedora Workstation
effort by providing a more detailed view of the various tasks underway as 
derived from the more high level PRD and Technical Specification documents. You 
can find the current
version of the tasklist here - http://fedoraproject.org/wiki/Workstation - but 
we hope to expand on it in the coming days and weeks to be even more 
comprehensive and also include more explanations around the motivation for each 
task.

The list enumerates the various efforts that is being undertaken around the 
Fedora Workstation effort and also puts a name next to many of the items.
If you are interested in helping out with any of these efforts please get in 
touch by reaching out either to the Working group board members or to
the people listed next to the tasks in question. For those of you not familiar 
with the working group we have contact information and board membership 
information
available on this page:
http://fedoraproject.org/wiki/Workstation

If you are getting this email you probably already know about the mailing list, 
but the working group can also be reached on IRC on #fedora-workstation on 
freenode.
Looking forward to discussing our plans with both new and old contributors to 
the workstation product effort.

Feel free to ask questions about the various tasks as I realize that the list 
is quite low on detail atm., and not all items might be self explanatory and as 
mentioned we do hope to add more detailed information to each item in the next 
few days.

Sincerely,
Christian Schaller

Looks great. I'll prepare similar page for Env and Stack WG for easier 
tracking of progress.


Marcela
--
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: Agenda for Env-and-Stacks WG meeting (2014-07-01)

[Marcela Mašláňová]

On 06/30/2014 06:51 PM, Marcela Mašláňová wrote:

On odd weeks WG meeting will be at 15:00 UTC, 17:00 Central Europe,
11:00 (noon) Boston, 8:00 San Francisco, 0:00 Tokyo in #fedora-meeting
on Freenode.

= Topics =
* free seats in Env WG
* Taskotron and rpmgrill
* OpenFloor


Meeting cancelled for low attendance.
--
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: free seats in Env and Stacks WG - volunteers wanted

[Marcela Mašláňová]

On 07/01/2014 11:31 AM, Marcela Maslanova wrote:

Env and Stacks Working Group has noble plan to make development in
Fedora easier and also work with new technologies, which are not in
Fedora yet.

The whole statement can be found here:
https://fedoraproject.org/wiki/Env_and_Stacks/Product_Requirements_Document
There is missing Atomic and/or Docker, because all members were mostly
interested in things mentioned in the document than looking at
containers. I believe we need someone who can pick what will be in Fedora base
image. Details can be found in Matt statement:
https://lists.fedoraproject.org/pipermail/env-and-stacks/2014-June/000431.html

We don't have manpower to work on all projects, but we started to work
or co-operate on these:
1/ testing additional repositories – Playground repo
https://fedoraproject.org/wiki/Changes/Playground_repository
Playground plugin is similar to Copr plugin
http://dnf.baseurl.org/2014/03/19/copr-plugin/
2/ automation – Automated packages review tools
https://fedoraproject.org/wiki/Env_and_Stacks/Changes_Drafts/Automated_packages_review_tools
3/ automation – Taskotron
tool for Fedora tests
https://fedoraproject.org/wiki/User:Tflink/taskotron_development_plan
4/ Build Systems – Copr
http://copr.fedoraproject.org/
5/ Software Collections in Fedora
https://fedoraproject.org/wiki/Changes/SCL
6/ DevAssistant
http://devassistant.org/
7/ Continuous Integration - prototype of few projects

If you are interested in current topics or containers, then please let
us know on env-and-sta...@lists.fedoraproject.org what you want to do and what 
you did until now.
I received some private replies, but I'd like to give opportunity to wider 
audience.

Thanks,
Marcela


Deadline for submission is Sunday, 6th July.

Marcela
--
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-release-$PRODUCT, /etc/issue, /etc/os-release, Per-Product Configs and more!

[Karel Zak]

On Mon, Jun 30, 2014 at 02:59:20PM -0400, Stephen Gallagher wrote:
> 2) The fedora-release-$PRODUCT package (and possibly %post or systemd
> snippets therein) will be responsible for the creation and maintenance
> of /etc/issue, /etc/os-release and /etc/fedora-release-product (note:
> there is no $ there. That's the literal name. This file will be
> equivalent to /etc/fedora-release except that it will include the
> Product name.

 Note that agetty(8) allows to keep /etc/issue distribution
 independent and it reads all necessary information from
 /etc/os-release to generate the final pre-login message. All you need
 is to create /etc/issue with \S sequences, for example:

   \S{PRETTY_NAME}
   \S{HOME_URL}

   Kernel \r on an \m (\l)

 .. so /etc/issue does not have to be maintained within packages like
 fedora-release-$PRODUCT or so.


 It would be really really nice have only *one* file (/etc/os-release)
 that contains operating system identification data. The mess like
 /etc/fedora-release and /etc/redhat-release should be deprecated.

Karel

-- 
 Karel Zak  
 http://karelzak.blogspot.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: [ACTION REQUIRED][FINAL NOTICE] Retiring packages for Fedora 21 v4

[Christopher Meng]

kannel failed to BFS because texlive does have a bug (dependency) problem:

https://bugzilla.redhat.com/show_bug.cgi?id=995752
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct