Re: Migrating sub-package to a different package: How to resolve file conflicts

[Florian Weimer]

On 06/13/2017 12:49 AM, Tom Stellard wrote:
> No plans to do this for gcc, because gcc is only compiler not a library,
> like LLVM, though I would like to do this for the clang libraries as well.

GCC potentially has similar issues.  However, libstdc++ aims at
backwards compatibility, and the other ABIs (the plug-in host, the other
language run-time library) only have few users, and ABI transitions are
traditionally handled as part of distribution rebuilds.

Thanks,
Florian
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: btw and Monitoring functionality ? Re: PkgDB search / info functionality

[Vít Ondruch]

Dne 12.6.2017 v 21:01 Ralph Bean napsal(a):
> On Mon, Jun 12, 2017 at 01:09:28PM +0100, Sérgio Basto wrote:
>> Hello , pkgdb also have Monitoring settings, Koschei integration,
>> timeline and Anitya , where do we have this on  Pagure over Dist-Git ? 
> The Koschei integration is going to move into Koschei's web UI.
> (Koschei actually already has this functionality, it is just turned
> off in Fedora's instance so that it only integrates with pkgdb
> instead.  The Koschei team will just enable that config switch).

On top of that, I requested "Koschei badge" [1] which could be displayed
somewhere in Pagure.

Also, I am playing with the idea of something like "fedpkg readme"
command, which would generated some default readme file containing links
to all the fedora badges and contain possibly similar information as the
PkgDB package page now. This file could already be included in freshly
prepared repository for new package.


Vít


[1] https://github.com/msimacek/koschei/issues/162

>
> For upstream release monitoring, we're going to move the values into
> the dist-git repo in the master branch, in a yaml file.
> the-new-hotness (which is the only tool which references those values)
> will have to be re-tooled to look for the values in the new location.
>
>
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org



signature.asc
Description: OpenPGP digital signature
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Retiring Packages with Broken Dependencies in branched (2017-06-12)

[Guido Aulisi]

Il giorno lun, 12/06/2017 alle 22.38 +, t...@fedoraproject.org ha
scritto:
> In preparation for the Final Freeze on 2017-06-27 Release
> Engineering will retire all packages in Branched with broken
> dependencies and
> all packages depending on these. If you get this e-mail directly this
> affects
> at least one of your packages. Please fix the broken dependency as
> soon as
> possible.  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
> 
This is going to break all audio applications in Fedora, because jack-
audio-connection-kit is affected, but I cannot see a dependency on efl,
I've got jack installed with no efl and only libffado, if I try to
install ffado I get no efl, so I cannot understand where the dependency
on efl is.

signature.asc
Description: This is a digitally signed message part
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Retiring Packages with Broken Dependencies in branched (2017-06-12)

[Christian Dersch]

On 06/13/2017 12:38 AM, t...@fedoraproject.org wrote:
> thunderbird-enigmail   lupinix75 weeks ago  
>

Should be fixed now, new build submitted for updates-testing.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Retiring Packages with Broken Dependencies in branched (2017-06-12)

[Haïkel]

2017-06-13 0:38 GMT+02:00  :
> In preparation for the Final Freeze on 2017-06-27 Release
> Engineering will retire all packages in Branched with broken dependencies and
> all packages depending on these. If you get this e-mail directly this affects
> at least one of your packages. Please fix the broken dependency as soon as
> possible.  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
>
>   Package(co)maintainers  Status Change
> ===
> AcetoneISO spot   160 weeks ago
> OmegaT olea, mtasaka  160 weeks ago
> RackTables coec   160 weeks ago
> Raysebhtml, jussilehtola  160 weeks ago
> YafaRayluya, slaanesh 15 weeks ago
> asterisk   jsmith, gtjoseph, itamarjp,83 weeks ago
>lbazan, russellb
> atomicapp  vpavlin, golang-sig,   103 weeks ago
>jchaloup, lalatendu
> ayttm  mintojoseph160 weeks ago
> banshee-community-extensions   chkr, elsupergomez 160 weeks ago
> beacon satyak 160 weeks ago
> compat-gcc-34  jakub  160 weeks ago
> consul fpokorny, golang-sig,  74 weeks ago
>jchaloup, sspreitz
> eclipse-avrvladimirk, akurtakov   160 weeks ago
> eflspot, dchen, sereinit  114 weeks ago
> elemental  rhl27 weeks ago
> erlang-riak_pipe   peter, erlang-sig  160 weeks ago
> etcd   jchaloup, avesh, cypret,   110 weeks ago
>eparis, golang-sig,
>gscrivano, jcajka, lsm5,
>peter, walters
> fedora-dockerfiles adimania, lsm5, scollier   130 weeks ago
> floppy-support bruno  160 weeks ago
> fusionforgebeuc, nerville 136 weeks ago
> gcc-python-plugin  dmalcolm, jakub160 weeks ago
> gearmand   ktdreyer, blakegardner 160 weeks ago
> getdp  ignatenkobrain, group  80 weeks ago
>::neuro-sig, smani
> gif2pngsundaram   160 weeks ago
> git-annex  mathstuf, haskell-sig  160 weeks ago
> gofed  jchaloup, fale, golang-sig 115 weeks ago
> golang-github-docker-go-   jchaloup   65 weeks ago
> connections
> golang-github-docker-  fpokorny, eparis, jchaloup,95 weeks ago
> libcontainer   lsm5, vbatts
> golang-github-fsouza-go-   fpokorny, eparis, golang-  95 weeks ago
> dockerclient   sig, jchaloup, lsm5,
>maxamillion
> golang-github-gonum-matrix fpokorny, jchaloup 86 weeks ago
> golang-github-kubernetes-  fpokorny, jchaloup 86 weeks ago
> heapster
> golang-github-mistifyio-go-jchaloup   57 weeks ago
> zfs
> golang-github-samalba- fpokorny, golang-sig,  97 weeks ago
> dockerclient   jchaloup
> golang-googlecode-go-exp   fpokorny, golang-sig,  97 weeks ago
>jchaloup, lsm5, vbatts
> grass  devrim, neteler, oliver,   160 weeks ago
>pertusus, rezso, volter
> gyachi sundaram, ghosler  160 weeks ago
> homerunjmarrero   160 weeks ago
> iwhd   meyering, clalance, zaitcev160 weeks ago
> java-gnome abo160 weeks ago
> kf5-libkface   rdieter70 weeks ago
> ledger radford, jamielinux160 weeks ago
> libsmbios  mebrown, gunnersrini,  33 weeks ago
>praveenp
> lldb   airlied, daveisfera,   71 weeks ago
>jankratochvil, jvcelak,
>siddharths, tstellar
> meshlabbrouhaha   160 weeks ago
> mesos  slaanesh, lloesche 5 

Re: Retiring Packages with Broken Dependencies in branched (2017-06-12)

[Peter Robinson]

I'm not sure how all those people can be co-maintainers of efl. I'm
not sure how that's meant to be interpreted but given some of the
other responses I think this script as bit rotted some what.

Peter

> Affected (co)maintainers

> alexl: efl
> ankursinha: lldb, efl
> atkac: efl
> bpepple: efl
> bsjones: efl
> caillon: efl
> caolanm: efl
> chkr: efl, banshee-community-extensions
> cicku: efl
> company: lldb, efl
> cwickert: efl
> danfruehauf: efl
> dchen: efl
> design-sw: efl
> drago01: efl
> dtimms: efl
> dwrobel: efl
> filiperosset: efl
> greghellings: efl
> group::gnome-sig: libsmbios, efl
> hobbes1069: efl
> ignatenkobrain: lldb, efl, getdp
> imntreal: efl
> jankratochvil: lldb, efl
> jjames: efl
> jkraehemann: efl
> jnovy: efl
> john2583: efl
> johnp: efl
> jvlomax: efl
> jwrdegoede: efl
> kkofler: efl
> konradm: lldb, efl
> kvolny: efl
> kwizart: efl
> lennart: efl
> limb: lldb, efl
> lkundrak: efl
> lorenzosu: efl
> luya: YafaRay, efl
> mbarnes: python-etcd, efl, etcd
> mbooth: efl
> mcrha: efl
> moezroy: efl
> mschwendt: efl
> mtasaka: OmegaT, efl, sslogger
> muep: efl
> nando: efl
> nobrakal: efl
> nonamedotc: efl
> nphilipp: efl
> nucleo: efl
> oget: efl
> pbrobinson: efl
> perex: efl
> pfj: efl
> pwalter: lldb, efl
> rakesh: efl
> rdieter: efl, kf5-libkface
> rhughes: libsmbios, efl
> roma: efl
> rrankin: efl
> rstrode: efl
> s4504kr: efl
> salimma: efl
> sereinit: efl
> sergiomb: efl
> slaanesh: YafaRay, efl, mesos
> smani: efl, getdp
> spot: python-repoze-who-plugins-sa, AcetoneISO, efl
> ssp: efl
> tartina: efl
> thm: efl
> thomasj: efl
> tikro: efl
> uraeus: efl
> verdurin: efl
> vicodan: libsmbios, efl, python-repoze-who-plugins-sa
> wtaymans: lldb, efl
> xiphmont: efl
> zbyszek: efl
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Retiring Packages with Broken Dependencies in branched (2017-06-12)

[Guido Aulisi]

Il giorno mar, 13/06/2017 alle 11.11 +0100, Peter Robinson ha scritto:
> I'm not sure how all those people can be co-maintainers of efl. I'm
> not sure how that's meant to be interpreted but given some of the
> other responses I think this script as bit rotted some what.
> 
> Peter

I think these are (co)maintainers of other packages affected by efl
problems, I am one of these, but IMHO dependencies are not well
computed here.

> > Affected (co)maintainers
> > alexl: efl
> > ankursinha: lldb, efl
> > atkac: efl
> > bpepple: efl
> > bsjones: efl
> > caillon: efl
> > caolanm: efl
> > chkr: efl, banshee-community-extensions
> > cicku: efl
> > company: lldb, efl
> > cwickert: efl
> > danfruehauf: efl
> > dchen: efl
> > design-sw: efl
> > drago01: efl
> > dtimms: efl
> > dwrobel: efl
> > filiperosset: efl
> > greghellings: efl
> > group::gnome-sig: libsmbios, efl
> > hobbes1069: efl
> > ignatenkobrain: lldb, efl, getdp
> > imntreal: efl
> > jankratochvil: lldb, efl
> > jjames: efl
> > jkraehemann: efl
> > jnovy: efl
> > john2583: efl
> > johnp: efl
> > jvlomax: efl
> > jwrdegoede: efl
> > kkofler: efl
> > konradm: lldb, efl
> > kvolny: efl
> > kwizart: efl
> > lennart: efl
> > limb: lldb, efl
> > lkundrak: efl
> > lorenzosu: efl
> > luya: YafaRay, efl
> > mbarnes: python-etcd, efl, etcd
> > mbooth: efl
> > mcrha: efl
> > moezroy: efl
> > mschwendt: efl
> > mtasaka: OmegaT, efl, sslogger
> > muep: efl
> > nando: efl
> > nobrakal: efl
> > nonamedotc: efl
> > nphilipp: efl
> > nucleo: efl
> > oget: efl
> > pbrobinson: efl
> > perex: efl
> > pfj: efl
> > pwalter: lldb, efl
> > rakesh: efl
> > rdieter: efl, kf5-libkface
> > rhughes: libsmbios, efl
> > roma: efl
> > rrankin: efl
> > rstrode: efl
> > s4504kr: efl
> > salimma: efl
> > sereinit: efl
> > sergiomb: efl
> > slaanesh: YafaRay, efl, mesos
> > smani: efl, getdp
> > spot: python-repoze-who-plugins-sa, AcetoneISO, efl
> > ssp: efl
> > tartina: efl
> > thm: efl
> > thomasj: efl
> > tikro: efl
> > uraeus: efl
> > verdurin: efl
> > vicodan: libsmbios, efl, python-repoze-who-plugins-sa
> > wtaymans: lldb, efl
> > xiphmont: efl
> > zbyszek: efl


signature.asc
Description: This is a digitally signed message part
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

REMINDER: Submission deadline for Changes of Fedora 27 requiring mass rebuild takes effect in one week

[Jan Kurik]

Hi everyone!

The submission deadline for Changes of Fedora 27 [1], requiring mass
rebuild, takes effect in one week on June 20th. All the Changes
requiring mass rebuild sent for review after this deadline are going
to be moved to Fedora 28 release.
The mass rebuild it self is planned on July 12th.

The deadline for System Wide Changes which do not need the mass
rebuild is planned on July 4th.

If your Change proposal needs mass rebuild, please submit it by the
deadline, earlier better. In case you'll need any help with your
Change proposals, feel free to contact me.

[1] https://fedoraproject.org/wiki/Releases/27/Schedule

Best Regards,
Jan
-- 
Jan Kuřík
Platform & Fedora Program Manager
Red Hat Czech s.r.o., Purkynova 99/71, 612 45 Brno, Czech Republic
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: F27 System Wide Change: Rsyslog log format change proposal

[Roman Pavelka]

IMHO it is exactly as Björn replied to you. Between 2010 and 2014 I was working 
in aerospace where the exact time of an event is of the highest importance. In 
this field there is deep understanding (based on several 
hundreds-millions-dollars screwups) how much compliance to standards is 
important, especially when working with/in the team scattered around the globe. 
In fact, anything different than ISO 8601 looks just wrong for me.

The current "traditional" format is even more "wrong" than just not being 
compliant to standards: It miss year and timezone. In my experience, people are 
*often* able to set some system scattered around the globe, use different 
timezones on different machines and even not provide the timezone used in 
logged timestamps. Then something breaks, call you and you have additional 
problem when the failure is not limited to single machine or single timezone. 
The reason why I decided to formulate this change was that people use default 
rsyslog format in their projects (real quote): "We've double-checked on the 
timestamps, and it's consistent with other syslogs."
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: F27 System Wide Change: Rsyslog log format change proposal

[Roman Pavelka]

Thanks, Stephen, I will update the "Benefit to Fedora" section.

>  It does not inspire confidence that the person(s) proposing this Change 
> understand the potential fallout. 
...
> what packages in Fedora parse the rsyslog output and make sure that they are 
> capable of handling the change.

Everyone is free to change his log's format, our proposed new default is even 
between templates packaged together with rsyslog under the name 
"RSYSLOG_FileFormat" (What we currently have default is 
"RSYSLOG_TraditionalFileFormat").

When some package will break because someone adjusted format of timestamps, the 
bug is in that package and not in the rsyslog's format.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Retiring Packages with Broken Dependencies in branched (2017-06-12)

[Kalev Lember]

On 06/13/2017 12:47 AM, Josh Stone wrote:
> On 06/12/2017 03:38 PM, t...@fedoraproject.org wrote:
>> lldb   airlied, daveisfera,   71 weeks ago  
>>jankratochvil, jvcelak,  
>>siddharths, tstellar 
> 
> Where does that 71 weeks come from?  The lldb-3.9.1-4.fc26 reported
> below was just in March, not to mention lldb-4.0.0-1.fc26 on May 12.
> 
>> Depending on: lldb (21), status change: 2016-01-27 (71 weeks ago)
>>  rust (maintained by: group::rust-sig, ignatenkobrain, jistone, ttorling)
>>  rust-lldb-1.17.0-1.fc26.i686 requires lldb = 3.9.1-4.fc26, 
>> python-lldb = 3.9.1-4.fc26
>>
>>  cargo (maintained by: group::rust-sig, ignatenkobrain, jistone, 
>> ttorling)
>>  cargo-0.18.0-1.fc26.i686 requires rust = 1.17.0-1.fc26
>>  cargo-0.18.0-1.fc26.src requires rust = 1.17.0-1.fc26
> 
> If it comes down to it, I'll just remove the rust-lldb subpackage, but I
> don't see what the actual problem is...

I think the llvm dep should already be fixed and nothing needs to be
done here. Looks like the report was generated using the latest
available F26 compose at that time; the next compose should pick up the
new lldb-4.0.0-1.fc26 build.

-- 
Kalev
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Retiring Packages with Broken Dependencies in branched (2017-06-12)

[Petr Pisar]

On 2017-06-13, Pavel Raiskup  wrote:
>> vim-syntastic  praiskup   38
>> weeks ago  
>
> Please don't remove this set of vim-syntastic* packages, there's
> nothing to do about this.  Once we have fixed release engineering
> processes [1] that allow me to ExcludeArch/ExclusiveArch particular
> **sub**packages, I'll do so.  Thanks!
>
> [1] https://pagure.io/pungi-fedora/issue/87
>
perl-Alien-ROOT is the same case .
The package is fine, but releng scripts cannot deal with it.

-- Petr
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: F27 System Wide Change: Rsyslog log format change proposal

[Roman Pavelka]

On Tue, Jun 13, 2017 at 2:18 PM, Reindl Harald  wrote:
>> When some package will break because someone adjusted format of
>> timestamps, the bug is in that package and not in the rsyslog's format
>
> there is a world outside packages called user scripts

That is true. But here there is simple way to revert back to original
format if wished
or change that regexp or strptime/strftime format used in the user script.

I am aware that any change is likely to broke someone's workflow:
https://xkcd.com/1172/

However there is real possibility of loss of data in current situation
(due to missing TZ and year)
and I experience more difficult operations due to this in my job
(testing of infrastructure scattered
around the globe).

R.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Retiring Packages with Broken Dependencies in branched (2017-06-12)

[Zbigniew Jędrzejewski-Szmek]

On Mon, Jun 12, 2017 at 09:22:57PM -0600, Jerry James wrote:
> On Mon, Jun 12, 2017 at 7:58 PM, Zbigniew Jędrzejewski-Szmek
>  wrote:
> > Till, it'd be great if this kind of scary e-mail, affecting quite a
> > lot of packagers, would contain more details, hints, etc. It seems
> > people are confused ;)
> 
> Yes, I'm confused, too.  This report lists jacknativeclient.  I've
> just done a search on my email: I've received exactly zero emails
> about problems with this package.  (I counted twice.)  There are no
> bugs filed on this package.  It was built successfully just back in
> February.  Koji shows zero failed builds.  What exactly is the problem
> with it?

It probably depends on jack, and jack depends on efl, and efl depends
on tslib, and tslib had a botched so-name in the i686 build. This will
be fixed when tslib which is in updated will go stable. So probably
the best option would be to provide positive karma on
https://bodhi.fedoraproject.org/updates/FEDORA-2017-240bb678f2 if
you are a user of those packages.

Zbyszek
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Retiring Packages with Broken Dependencies in branched (2017-06-12)

[Jan Chaloupka]

On 06/13/2017 12:38 AM, t...@fedoraproject.org wrote:

In preparation for the Final Freeze on 2017-06-27 Release
Engineering will retire all packages in Branched with broken dependencies and
all packages depending on these. If you get this e-mail directly this affects
at least one of your packages. Please fix the broken dependency as soon as
possible.  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

   Package(co)maintainers  Status Change
===
AcetoneISO spot   160 weeks ago
OmegaT olea, mtasaka  160 weeks ago
RackTables coec   160 weeks ago
Raysebhtml, jussilehtola  160 weeks ago
YafaRayluya, slaanesh 15 weeks ago
asterisk   jsmith, gtjoseph, itamarjp,83 weeks ago
lbazan, russellb
atomicapp  vpavlin, golang-sig,   103 weeks ago
jchaloup, lalatendu
ayttm  mintojoseph160 weeks ago
banshee-community-extensions   chkr, elsupergomez 160 weeks ago
beacon satyak 160 weeks ago
compat-gcc-34  jakub  160 weeks ago
consul fpokorny, golang-sig,  74 weeks ago
jchaloup, sspreitz
eclipse-avrvladimirk, akurtakov   160 weeks ago
eflspot, dchen, sereinit  114 weeks ago
elemental  rhl27 weeks ago
erlang-riak_pipe   peter, erlang-sig  160 weeks ago
etcd   jchaloup, avesh, cypret,   110 weeks ago
eparis, golang-sig,
gscrivano, jcajka, lsm5,
peter, walters


I don't see anything broken here. From Koji:

etcd-3.1.9-1.fc26 
 	jchaloup 
 	2017-06-12 
16:15:16 	complete
etcd-3.1.9-1.fc27 
 	jchaloup 
 	2017-06-11 
09:41:08 	complete



Any way to figure out what dependencies are exactly broken?


fedora-dockerfiles adimania, lsm5, scollier   130 weeks ago
floppy-support bruno  160 weeks ago
fusionforgebeuc, nerville 136 weeks ago
gcc-python-plugin  dmalcolm, jakub160 weeks ago
gearmand   ktdreyer, blakegardner 160 weeks ago
getdp  ignatenkobrain, group  80 weeks ago
::neuro-sig, smani
gif2pngsundaram   160 weeks ago
git-annex  mathstuf, haskell-sig  160 weeks ago
gofed  jchaloup, fale, golang-sig 115 weeks ago
golang-github-docker-go-   jchaloup   65 weeks ago
connections
golang-github-docker-  fpokorny, eparis, jchaloup,95 weeks ago
libcontainer   lsm5, vbatts
golang-github-fsouza-go-   fpokorny, eparis, golang-  95 weeks ago
dockerclient   sig, jchaloup, lsm5,
maxamillion
golang-github-gonum-matrix fpokorny, jchaloup 86 weeks ago
golang-github-kubernetes-  fpokorny, jchaloup 86 weeks ago
heapster
golang-github-mistifyio-go-jchaloup   57 weeks ago
zfs
golang-github-samalba- fpokorny, golang-sig,  97 weeks ago
dockerclient   jchaloup
golang-googlecode-go-exp   fpokorny, golang-sig,  97 weeks ago
jchaloup, lsm5, vbatts
grass  devrim, neteler, oliver,   160 weeks ago
pertusus, rezso, volter
gyachi sundaram, ghosler  160 weeks ago
homerunjmarrero   160 weeks ago
iwhd   meyering, clalance, zaitcev160 weeks ago
java-gnome abo160 weeks ago
kf5-libkface   rdieter70 weeks ago
ledger radford, jamielinux160 weeks ago
libsmbios  mebrown, gunnersrini,  3

Re: F27 System Wide Change: Rsyslog log format change proposal

[Roman Pavelka]

On Tue, Jun 13, 2017 at 2:33 PM, Reindl Harald  wrote:
> i call your infrastructure scattered around the globe the minority of setups

This can be the case for Fedora but it would be not for CentOS and RHEL,
where this change should head in too.

> "there is a simple way to change the format if you wish"

Sadly not, I am usually called to systems already deployed, used and broken.
My advice to maintainers of such troubling deployments then usually is to use
only ISO 8601 and UTC in timestamps, properly set ntp, backup, track
configuration changes etc... But, well, not every time are these recommendations
actually implemented.

Cause of these timestamps where you need somehow deduce TZ used is not
that their maintainers prefers traditional rsyslog format, but because
it is there
by default.

Regards

Roman
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Rawhide: where for art thou? (why no rawhide composes recently)

[Kevin Fenzi]

Greetings.

Some folks may have noticed that there have been no completed rawhide
composes in a while (13 days as of today).

This has been due to a variety of bugs and issues, along with pungi now
failing composes that don't have all required release blocking items.

Here's a partial list:

2017-06-01 - lorax traceback, bug 1457055
2017-06-02 - another lorax issue, bug 1457906
2017-06-03 - cloud base failed in anaconda, bug 1458509
2017-06-04 - ditto
2017-06-05 - ditto
2017-06-06 - pungi bug - https://pagure.io/pungi/issue/641
2017-06-07 - ditto
2017-06-08 - ditto
2017-06-09 - ditto
2017-06-10 - ditto
2017-06-11 - ditto
2017-06-12 - ditto
2017-06-12.1 - pungi bug fixed, but hit libgtop2 broken deps in metacity
that failed the comppose. I fixed those (and control-center) last night.
2017-06-13 - still running, cross your fingers.

All of this has been made a bit worse by us having some storage slowness
which means you can really only do about 2 rawhide compose attempts a
day. Thats being worked on and hopefully we will get it fixed soon.

You can also see here there were some gaps where we didn't yet have the
bug tracked down or didn't yet have a fix in place. We need to try and
do better there. (I was out on vacation last week, so it can't always be
me).

Anyhow, hopefully we will have a rawhide compose today, and if not I
will keep poking it to get it going...

kevin



signature.asc
Description: OpenPGP digital signature
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Announcing the release of Fedora 26 Beta

[Mohan Boddu]

The Fedora Project is pleased to announce the immediate availability
of Fedora 26 Beta, the next big step on our journey to the exciting
Fedora 26 release in July.

Download the prerelease from our Get Fedora site:

* Get Fedora 26 Beta Workstation
  https://getfedora.org/workstation/prerelease/

* Get Fedora 26 Beta Server
  https://getfedora.org/server/prerelease/

* Get Fedora 26 Pre-Release Atomic
  https://getfedora.org/atomic/prerelease/

Looking for Fedora Cloud Base? This is replaced by Atomic as a Fedora
Edition for the container use case, but we still produce it for those
of you who want to build up your own cloud-computing environment in a
more traditional way from https://cloud.fedoraproject.org/.

Or, check out one of our popular variants, including KDE Plasma, Xfce,
and other desktop environments, as well as images for ARM devices
like the Raspberry Pi 2 and 3:

* Get Fedora 26 Beta Spins
  https://spins.fedoraproject.org/prerelease

* Get Fedora 26 Beta Labs
  https://labs.fedoraproject.org/prerelease

* Get Fedora 26 Beta ARM
  https://arm.fedoraproject.org/prerelease


Fedora’s journey is not simply about updating one operating system
with the latest and greatest packages. It’s also about innovation for
the many different platforms represented in the Fedora Project:
Workstation, Server, Atomic, and the various Spins. Coordinating the
efforts across the many working groups is no small task, and serves
as a testament to the talent and professionalism found within the
Fedora community.

As we move into this Beta phase of the Fedora 26 release cycle, what
can users expect?


Fedora-Wide Changes
===

Fedora, always in the path of innovation, will ship with the latest
version of the GNU Compiler Collection, also known as GCC, bringing
the latest language features and optimizations to users and to the
software we build. Also the Go Language is updated to the latest
version, 1.8, which includes 32-bits MIPS support and speed
improvements.

One of the most important changes is the addition of "blivet-gui" to
the installer. This provides a "building-blocks" style partitioning
GUI for sysadmins and enthusiast users who are familiar with the
details of storage systems.

Also, we've made and included many improvements in security, improving
user experience and reducing the risks of the digital life.


Fedora Editions
===

The Workstation edition of Fedora 26 Beta features GNOME 3.24, which
includes important changes like Night Light, which changes the color
temperature of the display based on time of day. It will also
include the latest update of LibreOffice.

Our Atomic Host Edition also has a lot of improvements, including
more options to run containers, the latest version of the docker
container platform, the cockpit manager and the atomic CLI, improving
the way containers are managed, making being a sysadmin easier.


Spins and Labs
==

The Fedora Project is proud to announce two new versions: The LXQt
Spin, a lightweight desktop supporting the latest version of the Qt
libraries; and the Python Classroom Lab, a new version focused in the
teaching and learning of the Python programming language. And, in the
Cinnamon Spin, the desktop is updated to the latest version.


Alternative Architectures
=

We are also simultaneously releasing 64-bit F26 Beta for ARM
(AArch64), Power (both little and big endian) and s390x
architectures. You'll also find minimal network installers and the
Fedora 26 Beta Cloud Base image here:

* Get Beta Alternative Architectures and Other Downloads.
  https://alt.fedoraproject.org/prerelease/

What is the Beta Release?
=

A Beta release is code-complete and bears a very strong resemblance
to the third and final release. The final release of Fedora 26 is
expected in July. If you take the time to download and try out the
Beta, you can check and make sure the things that are important to
you are working. Every bug you find and report doesn’t just help you,
it improves the experience of millions of Fedora users worldwide!
Together, we can make Fedora rock-solid. We have a culture of
coordinating new features and pushing fixes upstream as much as we
can, and your feedback improves not only Fedora, but Linux and Free
software as a whole.


Issues and Details
==

Since this is a Beta release, we expect that you may encounter bugs
or missing features. To report issues encountered during testing,
contact the Fedora QA team via the mailing list or in #fedora-qa on
Freenode. As testing progresses, common issues are tracked on the
Common F26 Bugs page. https://fedoraproject.org/wiki/Common_F26_bugs

For tips on reporting a bug effectively, read how to file a bug
report: https://fedoraproject.org/wiki/How_to_file_a_bug_report


More information


For more detailed information about what's new on Fedora 26 Beta
Release, you can consult our Talking Points and the F26 Chang

Re: Rawhide: where for art thou? (why no rawhide composes recently)

[Peter Robinson]

On Tue, Jun 13, 2017 at 2:11 PM, Kevin Fenzi  wrote:
> Greetings.
>
> Some folks may have noticed that there have been no completed rawhide
> composes in a while (13 days as of today).
>
> This has been due to a variety of bugs and issues, along with pungi now
> failing composes that don't have all required release blocking items.

Is there a way we can loosen that up for rawhide and have it tightened
down for branched. I think it's worth while to have at least a flow of
the everything repository out on a regular basis like the old pre
pungi-4 use to do.

> Here's a partial list:
>
> 2017-06-01 - lorax traceback, bug 1457055
> 2017-06-02 - another lorax issue, bug 1457906
> 2017-06-03 - cloud base failed in anaconda, bug 1458509
> 2017-06-04 - ditto
> 2017-06-05 - ditto
> 2017-06-06 - pungi bug - https://pagure.io/pungi/issue/641
> 2017-06-07 - ditto
> 2017-06-08 - ditto
> 2017-06-09 - ditto
> 2017-06-10 - ditto
> 2017-06-11 - ditto
> 2017-06-12 - ditto
> 2017-06-12.1 - pungi bug fixed, but hit libgtop2 broken deps in metacity
> that failed the comppose. I fixed those (and control-center) last night.
> 2017-06-13 - still running, cross your fingers.
>
> All of this has been made a bit worse by us having some storage slowness
> which means you can really only do about 2 rawhide compose attempts a
> day. Thats being worked on and hopefully we will get it fixed soon.
>
> You can also see here there were some gaps where we didn't yet have the
> bug tracked down or didn't yet have a fix in place. We need to try and
> do better there. (I was out on vacation last week, so it can't always be
> me).
>
> Anyhow, hopefully we will have a rawhide compose today, and if not I
> will keep poking it to get it going...
>
> kevin
>
>
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
>
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Migrating sub-package to a different package: How to resolve file conflicts

[Rex Dieter]

Tom Stellard wrote:

> I'm working on moving the llvm-devel sub-package from the llvm package to
> a new llvm4.0 package, however, when I upgrade from the llvm sub-package
> to the llvm4.0 sub-package, I am getting file conflicts.
...
> Error: Transaction check error:
>   file /usr/include/llvm from install of llvm-devel-4.0.0-13.fc27.x86_64
>   conflicts with file from package llvm-devel-4.0.0-4.fc27.x86_64 file
>   /usr/include/llvm-c from install of llvm-devel-4.0.0-13.fc27.x86_64
>   conflicts with file from package llvm-devel-4.0.0-4.fc27.x86_64

> Is this a bug in dnf/rpm or am I doing something wrong with the spec
> files?

IMO, you're doing nothing wrong, it's a dnf/rpm bug.  dnf is supposed to 
implicitly Obsoletes/replace older packages of the same name (in general, 
though there are exceptions like "kernel")

-- Rex

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Migrating sub-package to a different package: How to resolve file conflicts

[Rex Dieter]

Rex Dieter wrote:

> Tom Stellard wrote:
> 
>> I'm working on moving the llvm-devel sub-package from the llvm package to
>> a new llvm4.0 package, however, when I upgrade from the llvm sub-package
>> to the llvm4.0 sub-package, I am getting file conflicts.
> ...
>> Error: Transaction check error:
>>   file /usr/include/llvm from install of llvm-devel-4.0.0-13.fc27.x86_64
>>   conflicts with file from package llvm-devel-4.0.0-4.fc27.x86_64 file
>>   /usr/include/llvm-c from install of llvm-devel-4.0.0-13.fc27.x86_64
>>   conflicts with file from package llvm-devel-4.0.0-4.fc27.x86_64
> 
>> Is this a bug in dnf/rpm or am I doing something wrong with the spec
>> files?
> 
> IMO, you're doing nothing wrong, it's a dnf/rpm bug.  dnf is supposed to
> implicitly Obsoletes/replace older packages of the same name (in general,
> though there are exceptions like "kernel")

Occurs to me you could avoid/skip relying on the implicit replacement, and 
make it *explicit*, but adding
Obsoletes: llvm-devel < 4.0.0-13
to the new llvm-devel subpkg

-- Rex
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Rawhide: where for art thou? (why no rawhide composes recently)

[Matthew Miller]

On Tue, Jun 13, 2017 at 03:10:58PM +0100, Peter Robinson wrote:
> > This has been due to a variety of bugs and issues, along with pungi now
> > failing composes that don't have all required release blocking items.
> 
> Is there a way we can loosen that up for rawhide and have it tightened
> down for branched. I think it's worth while to have at least a flow of
> the everything repository out on a regular basis like the old pre
> pungi-4 use to do.

I know we're already at new-deliverable explosion, but this seems like
a place where it'd be nice to have Rawhide and Bikeshed (or whatever we
want to call "tested and believed-to-be basically functional Rawhide").
That doesn't seem imminent, though, so Peter's suggestion seems
reasonable. Then maybe we could ask Jan as FPgM to keep track of what's
working and what's broken and help make sure the right people are on
it.


-- 
Matthew Miller

Fedora Project Leader
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Rawhide: where for art thou? (why no rawhide composes recently)

[Colin Walters]

On Tue, Jun 13, 2017, at 10:43 AM, Matthew Miller wrote:

> I know we're already at new-deliverable explosion, but this seems like
> a place where it'd be nice to have Rawhide and Bikeshed (or whatever we
> want to call "tested and believed-to-be basically functional Rawhide").
> That doesn't seem imminent, though, so Peter's suggestion seems
> reasonable. Then maybe we could ask Jan as FPgM to keep track of what's
> working and what's broken and help make sure the right people are on
> it.

An alternative to creating *even more* streams is to *revert* broken
things in existing streams.  lorax didn't work on arm?   Revert, don't
just file a bugzilla and have everyone sitting around wait for a patch.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Rawhide: where for art thou? (why no rawhide composes recently)

[Kaleb S. KEITHLEY]

You keep using that word — where for [sic] — I do not think it means 
what you think it means. (As inconceivable as it may seem.)


--

Kaleb
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Migrating sub-package to a different package: How to resolve file conflicts

[Neal Gompa]

On Tue, Jun 13, 2017 at 10:25 AM, Rex Dieter  wrote:
> Rex Dieter wrote:
>
>> Tom Stellard wrote:
>>
>>> I'm working on moving the llvm-devel sub-package from the llvm package to
>>> a new llvm4.0 package, however, when I upgrade from the llvm sub-package
>>> to the llvm4.0 sub-package, I am getting file conflicts.
>> ...
>>> Error: Transaction check error:
>>>   file /usr/include/llvm from install of llvm-devel-4.0.0-13.fc27.x86_64
>>>   conflicts with file from package llvm-devel-4.0.0-4.fc27.x86_64 file
>>>   /usr/include/llvm-c from install of llvm-devel-4.0.0-13.fc27.x86_64
>>>   conflicts with file from package llvm-devel-4.0.0-4.fc27.x86_64
>>
>>> Is this a bug in dnf/rpm or am I doing something wrong with the spec
>>> files?
>>
>> IMO, you're doing nothing wrong, it's a dnf/rpm bug.  dnf is supposed to
>> implicitly Obsoletes/replace older packages of the same name (in general,
>> though there are exceptions like "kernel")
>
> Occurs to me you could avoid/skip relying on the implicit replacement, and
> make it *explicit*, but adding
> Obsoletes: llvm-devel < 4.0.0-13
> to the new llvm-devel subpkg
>

Implicit replacements are dangerous, and lead to weird special cases.
It's far better to be explicit. I woudl argue that this was actually a
Yum bug that people turned into a misfeature, and we should adjust and
actually be explicit about when content changes so Obsoletes need to
be in place. DNF already handles most of the YumObsoletes behavior,
but implicit replacements are tricky.



-- 
真実はいつも一つ！/ Always, there's only one truth!
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Retiring Packages with Broken Dependencies in branched (2017-06-12)

[Tom Callaway]

On 06/12/2017 06:38 PM, t...@fedoraproject.org wrote:
> In preparation for the Final Freeze on 2017-06-27 Release
> Engineering will retire all packages in Branched with broken dependencies and
> all packages depending on these. If you get this e-mail directly this affects
> at least one of your packages. Please fix the broken dependency as soon as
> possible.  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

> spot: python-repoze-who-plugins-sa, AcetoneISO, efl

AcetoneISO and efl are not currently broken, as far as I can see:

https://bodhi.fedoraproject.org/updates/FEDORA-2017-2c6432f719
https://bodhi.fedoraproject.org/updates/FEDORA-2017-9dcc8be30a

I just fixed the build for python-repoze-who-plugins-sa:

https://bodhi.fedoraproject.org/updates/python-repoze-who-plugins-sa-1.0.1-14.20160106gite1a36c5.fc26

~tom
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Migrating sub-package to a different package: How to resolve file conflicts

[Rex Dieter]

Neal Gompa wrote:

> Implicit replacements are dangerous, and lead to weird special cases.

rpm handles it (rpm --upgrade ...), dnf should do the same.  This is not 
just a special case, but a very simple one that's always worked.   IMHO

-- Rex
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Retiring Packages with Broken Dependencies in branched (2017-06-12)

[Till Maas]

On Tue, Jun 13, 2017 at 11:14:37AM +0200, Guido Aulisi wrote:

> This is going to break all audio applications in Fedora, because jack-
> audio-connection-kit is affected, but I cannot see a dependency on efl,
> I've got jack installed with no efl and only libffado, if I try to
> install ffado I get no efl, so I cannot understand where the dependency
> on efl is.

The subpackage dbus-c++-ecore of dbus-c++ depends on libefl.so.1 and
libffado depends on dbus-c++. However, I understood that efl is being
fixed with the next stable push so you probably do not have to worry
about this one.

Kind regards
Till


signature.asc
Description: PGP signature
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: dnf bodhi plugin

[Zbigniew Jędrzejewski-Szmek]

On Sat, May 20, 2017 at 11:11:38AM -0400, Randy Barlow wrote:
> On Fri, 2017-05-19 at 11:48 -0400, Matthew Miller wrote:
> > Yeah, I just tested and this works:
> > 
> > $ sudo dnf upgrade --advisory FEDORA-2017-f590422f5b
> 
> Fantastic! I'm bummed that I now need a new idea, but I'm glad this
> exists because I will use it ☺

I just discovered that 'dnf install --advisory ...' does *not* work, --advisory
is only for upgrade. That's a bummer ;)
I filed https://bugzilla.redhat.com/show_bug.cgi?id=1461171 as an RFE…

Zbyszek
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Retiring Packages with Broken Dependencies in branched (2017-06-12)

[Adam Williamson]

On Tue, 2017-06-13 at 01:50 +, Zbigniew Jędrzejewski-Szmek wrote:
> On Tue, Jun 13, 2017 at 12:20:36AM +, Zbigniew Jędrzejewski-Szmek wrote:
> > On Mon, Jun 12, 2017 at 04:12:04PM -0700, Adam Williamson wrote:
> > > On Mon, 2017-06-12 at 16:06 -0700, Adam Williamson wrote:
> > > > On Mon, 2017-06-12 at 22:38 +, t...@fedoraproject.org wrote:
> > > > > os-autoinstadamwill   73 
> > > > > weeks ago  
> > > > 
> > > > Uh. What? I built this for fc26 in April. That's not 73 weeks ago. And
> > > > 'dnf install os-autoinst' does not report any broken dependencies.
> > > > 
> > > > https://koji.fedoraproject.org/koji/buildinfo?buildID=878719
> > > > https://bodhi.fedoraproject.org/updates/FEDORA-2017-2a2d78207d
> > > 
> > > Oh, I see the problem now, though it doesn't explain the '73 weeks
> > > ago':
> > > 
> > > [os-autoinst]
> > > os-autoinst-openvswitch-4.4-18.20170410git97928a2.fc26.armv7hl 
> > > requires openvswitch
> > > [os-autoinst]
> > > os-autoinst-openvswitch-4.4-18.20170410git97928a2.fc26.ppc64 
> > > requires openvswitch
> > 
> > Where did you find this information? I tried to find out what is
> > wrong with efl, and it install just fine on F26 here, and it was part
> > of an update that went to stable 3 days ago.
> 
> Found it:
> https://taskotron.fedoraproject.org/artifacts/all/382ff930-4d3d-11e7-a421-5254008e42f6/task_output/efl-1.19.0-4.fc26.x86_64.log

Actually, I got it from the report emails that are sent to test@ and
devel@ with every compose: "Fedora 26 compose report" and "Fedora
rawhide compose report". Each one includes a full repoclosure check for
each arch.
-- 
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
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Migrating sub-package to a different package: How to resolve file conflicts

[Tom Stellard]

On 06/13/2017 10:25 AM, Rex Dieter wrote:
> Rex Dieter wrote:
> 
>> Tom Stellard wrote:
>>
>>> I'm working on moving the llvm-devel sub-package from the llvm package to
>>> a new llvm4.0 package, however, when I upgrade from the llvm sub-package
>>> to the llvm4.0 sub-package, I am getting file conflicts.
>> ...
>>> Error: Transaction check error:
>>>   file /usr/include/llvm from install of llvm-devel-4.0.0-13.fc27.x86_64
>>>   conflicts with file from package llvm-devel-4.0.0-4.fc27.x86_64 file
>>>   /usr/include/llvm-c from install of llvm-devel-4.0.0-13.fc27.x86_64
>>>   conflicts with file from package llvm-devel-4.0.0-4.fc27.x86_64
>>
>>> Is this a bug in dnf/rpm or am I doing something wrong with the spec
>>> files?
>>
>> IMO, you're doing nothing wrong, it's a dnf/rpm bug.  dnf is supposed to
>> implicitly Obsoletes/replace older packages of the same name (in general,
>> though there are exceptions like "kernel")
> 
> Occurs to me you could avoid/skip relying on the implicit replacement, and 
> make it *explicit*, but adding
> Obsoletes: llvm-devel < 4.0.0-13
> to the new llvm-devel subpkg
> 

I just tried this, but I still get the same error as before.  Could there
be some other issue?

Here is the updated spec file:
http://copr-dist-git.fedorainfracloud.org/cgit/tstellar/llvm-versioned/llvm4.0.git/tree/llvm4.0.spec

-Tom
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Migrating sub-package to a different package: How to resolve file conflicts

[Matthew Miller]

On Tue, Jun 13, 2017 at 02:40:27PM -0400, Tom Stellard wrote:
> >>> Error: Transaction check error:
> >>>   file /usr/include/llvm from install of llvm-devel-4.0.0-13.fc27.x86_64
> >>>   conflicts with file from package llvm-devel-4.0.0-4.fc27.x86_64 file
> >>>   /usr/include/llvm-c from install of llvm-devel-4.0.0-13.fc27.x86_64
> >>>   conflicts with file from package llvm-devel-4.0.0-4.fc27.x86_64
[...]
> I just tried this, but I still get the same error as before.  Could there
> be some other issue?

Are all of the dependencies of the old llvm-devel package filled if you have
the new llvm-devel installed? My assumption is that this is happening
not because of any problem with obsoleting, but that DNF needs the old
package to stay to keep some dependency filled.

-- 
Matthew Miller

Fedora Project Leader
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Retiring Packages with Broken Dependencies in branched (2017-06-12)

[Guido Aulisi]

Il giorno mar, 13/06/2017 alle 19.12 +0200, Till Maas ha scritto:
> On Tue, Jun 13, 2017 at 11:14:37AM +0200, Guido Aulisi wrote:
> 
> > This is going to break all audio applications in Fedora, because
> > jack-
> > audio-connection-kit is affected, but I cannot see a dependency on
> > efl,
> > I've got jack installed with no efl and only libffado, if I try to
> > install ffado I get no efl, so I cannot understand where the
> > dependency
> > on efl is.
> 
> The subpackage dbus-c++-ecore of dbus-c++ depends on libefl.so.1 and
> libffado depends on dbus-c++. However, I understood that efl is being
> fixed with the next stable push so you probably do not have to worry
> about this one.

This I can't understand, libffado depends on dbus-c++, but dbus-c++
itself does not depend on libefl.so.1, only its subpackage dbus-c++-
ecore. So a dependency on a subpackage is affecting the entire package,
is this true? It looks strange to me, but maybe I'm wrong.
I know efl is being fixed, so I'm really not worried about this issue,
only a little bit curious about dependencies.

signature.asc
Description: This is a digitally signed message part
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Migrating sub-package to a different package: How to resolve file conflicts

[Tom Stellard]

On 06/13/2017 02:51 PM, Matthew Miller wrote:
> On Tue, Jun 13, 2017 at 02:40:27PM -0400, Tom Stellard wrote:
> Error: Transaction check error:
>   file /usr/include/llvm from install of llvm-devel-4.0.0-13.fc27.x86_64
>   conflicts with file from package llvm-devel-4.0.0-4.fc27.x86_64 file
>   /usr/include/llvm-c from install of llvm-devel-4.0.0-13.fc27.x86_64
>   conflicts with file from package llvm-devel-4.0.0-4.fc27.x86_64
> [...]
>> I just tried this, but I still get the same error as before.  Could there
>> be some other issue?
> 
> Are all of the dependencies of the old llvm-devel package filled if you have
> the new llvm-devel installed? My assumption is that this is happening
> not because of any problem with obsoleting, but that DNF needs the old
> package to stay to keep some dependency filled.
> 

It's possible, is there a good way to debug this?

-Tom
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Retiring Packages with Broken Dependencies in branched (2017-06-12)

[Rex Dieter]

Guido Aulisi wrote:

>  So a dependency on a subpackage is affecting the entire package,
> is this true?

Yes

-- Rex
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Migrating sub-package to a different package: How to resolve file conflicts

[Tom Stellard]

On 06/13/2017 02:51 PM, Matthew Miller wrote:
> On Tue, Jun 13, 2017 at 02:40:27PM -0400, Tom Stellard wrote:
> Error: Transaction check error:
>   file /usr/include/llvm from install of llvm-devel-4.0.0-13.fc27.x86_64
>   conflicts with file from package llvm-devel-4.0.0-4.fc27.x86_64 file
>   /usr/include/llvm-c from install of llvm-devel-4.0.0-13.fc27.x86_64
>   conflicts with file from package llvm-devel-4.0.0-4.fc27.x86_64
> [...]
>> I just tried this, but I still get the same error as before.  Could there
>> be some other issue?
> 
> Are all of the dependencies of the old llvm-devel package filled if you have
> the new llvm-devel installed? My assumption is that this is happening
> not because of any problem with obsoleting, but that DNF needs the old
> package to stay to keep some dependency filled.
> 

Here is the output I get with --debuglevel=1

--> Starting dependency resolution
---> Package llvm4.0-devel.x86_64 4.0.0-14.fc27 will be installed
---> Package llvm-devel.x86_64 4.0.0-4.fc27 will be obsoleted
---> Package llvm4.0.x86_64 4.0.0-14.fc27 will be installed
---> Package llvm4.0-libs.x86_64 4.0.0-14.fc27 will be installed
---> Package llvm-libs.x86_64 4.0.0-4.fc27 will be obsoleted
---> Package llvm-devel.x86_64 4.0.0-4.fc27 will be upgraded
---> Package llvm-devel.x86_64 4.0.0-14.fc27 will be an upgrade
---> Package llvm.x86_64 4.0.0-4.fc27 will be upgraded
---> Package llvm.x86_64 4.0.0-14.fc27 will be an upgrade
--> Finished dependency resolution


It looks like llvm-devel.x86_64 4.0.0-4.fc27 is being both
obsoleted and upgraded, could that be the problem?

-Tom
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Rawhide: where for art thou? (why no rawhide composes recently)

[Kevin Fenzi]

On 06/13/2017 08:10 AM, Peter Robinson wrote:
> On Tue, Jun 13, 2017 at 2:11 PM, Kevin Fenzi  wrote:
>> Greetings.
>>
>> Some folks may have noticed that there have been no completed rawhide
>> composes in a while (13 days as of today).
>>
>> This has been due to a variety of bugs and issues, along with pungi now
>> failing composes that don't have all required release blocking items.
> 
> Is there a way we can loosen that up for rawhide and have it tightened
> down for branched. I think it's worth while to have at least a flow of
> the everything repository out on a regular basis like the old pre
> pungi-4 use to do.

Possibly yes. But I think the idea was to do it for rawhide as well and
thus always be at least "Alpha" quality so we could not do alpha anymore.

kevin





signature.asc
Description: OpenPGP digital signature
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Rawhide: where for art thou? (why no rawhide composes recently)

[Kevin Fenzi]

On 06/13/2017 08:43 AM, Matthew Miller wrote:
> On Tue, Jun 13, 2017 at 03:10:58PM +0100, Peter Robinson wrote:
>>> This has been due to a variety of bugs and issues, along with pungi now
>>> failing composes that don't have all required release blocking items.
>>
>> Is there a way we can loosen that up for rawhide and have it tightened
>> down for branched. I think it's worth while to have at least a flow of
>> the everything repository out on a regular basis like the old pre
>> pungi-4 use to do.
> 
> I know we're already at new-deliverable explosion, but this seems like
> a place where it'd be nice to have Rawhide and Bikeshed (or whatever we
> want to call "tested and believed-to-be basically functional Rawhide").

(Side note: I am not sure why we can't just make these the same thing...
ie, always have rawhide basically functional).

> That doesn't seem imminent, though, so Peter's suggestion seems
> reasonable. Then maybe we could ask Jan as FPgM to keep track of what's
> working and what's broken and help make sure the right people are on
> it.

Well, it's sometimes not easy to tell where something is broken, it
takes a human to look and dig around and see where the failure is.

Example: Today's rawhide compose I had hopes for failed.

Turns out it was a koji bug we already fixed and we didn't hit it
yesterday because we didn't have the same fixed koji version on all the
builders. It took me and Patrick a while to track down what was
happening there. There's also another compose running now. Fingers
crossed. :)

kevin






signature.asc
Description: OpenPGP digital signature
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Rawhide: where for art thou? (why no rawhide composes recently)

[Stephen John Smoogen]

On 13 June 2017 at 17:28, Kevin Fenzi  wrote:
> On 06/13/2017 08:10 AM, Peter Robinson wrote:
>> On Tue, Jun 13, 2017 at 2:11 PM, Kevin Fenzi  wrote:
>>> Greetings.
>>>
>>> Some folks may have noticed that there have been no completed rawhide
>>> composes in a while (13 days as of today).
>>>
>>> This has been due to a variety of bugs and issues, along with pungi now
>>> failing composes that don't have all required release blocking items.
>>
>> Is there a way we can loosen that up for rawhide and have it tightened
>> down for branched. I think it's worth while to have at least a flow of
>> the everything repository out on a regular basis like the old pre
>> pungi-4 use to do.
>
> Possibly yes. But I think the idea was to do it for rawhide as well and
> thus always be at least "Alpha" quality so we could not do alpha anymore.

That was my take on the "no more alphas". If we can't do this then we
are going to have to look at doing an alpha in the schedule because it
is clear we aren't able to stabilize enough for that promise to exist.

> kevin
>
>
>
>
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
>



-- 
Stephen J Smoogen.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Retiring Packages with Broken Dependencies in branched (2017-06-12)

[Till Maas]

On Mon, Jun 12, 2017 at 03:47:48PM -0700, Josh Stone wrote:
> On 06/12/2017 03:38 PM, t...@fedoraproject.org wrote:
> > lldb   airlied, daveisfera,   71 weeks ago  
> >jankratochvil, jvcelak,  
> >siddharths, tstellar 
> 
> Where does that 71 weeks come from?  The lldb-3.9.1-4.fc26 reported
> below was just in March, not to mention lldb-4.0.0-1.fc26 on May 12.

Sorry for the confusion. The status change is an artifact from using the
script for finding long-time orphaned packages and states the time for
the last owner change in pkgdb. For this report it would be better if I
removed it.

Kind regards
Till
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Retiring Packages with Broken Dependencies in branched (2017-06-12)

[Till Maas]

On Tue, Jun 13, 2017 at 11:52:05AM +1000, Peter Hutterer wrote:
> On Mon, Jun 12, 2017 at 03:47:48PM -0700, Josh Stone wrote:
> > On 06/12/2017 03:38 PM, t...@fedoraproject.org wrote:
> > > lldb   airlied, daveisfera,   71 weeks 
> > > ago  
> > >jankratochvil, jvcelak,
> > >   
> > >siddharths, tstellar   
> > >   
> > 
> > Where does that 71 weeks come from?  The lldb-3.9.1-4.fc26 reported
> > below was just in March, not to mention lldb-4.0.0-1.fc26 on May 12.
> 
> not to mention that this lldb issue breaks rust which in turn breaks meson
> which in turn breaks anything using meson. I'm going out on a limb here and
> assume that packages using rust and meson are not necessarily EOL'd :)

lldb seems to be broken on aarch64, i686, x86_64 and armv7hl because of
unsatisfied dependencies for clang and llvm-libs. But I guess it will be
fixed once
https://bodhi.fedoraproject.org/updates/FEDORA-2017-10971fa7a7
will be properly in F26 stable.

Kind regards
Till
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Rawhide: where for art thou? (why no rawhide composes recently)

[Peter Robinson]

 Greetings.

 Some folks may have noticed that there have been no completed rawhide
 composes in a while (13 days as of today).

 This has been due to a variety of bugs and issues, along with pungi now
 failing composes that don't have all required release blocking items.
>>>
>>> Is there a way we can loosen that up for rawhide and have it tightened
>>> down for branched. I think it's worth while to have at least a flow of
>>> the everything repository out on a regular basis like the old pre
>>> pungi-4 use to do.
>>
>> Possibly yes. But I think the idea was to do it for rawhide as well and
>> thus always be at least "Alpha" quality so we could not do alpha anymore.
>
> That was my take on the "no more alphas". If we can't do this then we
> are going to have to look at doing an alpha in the schedule because it
> is clear we aren't able to stabilize enough for that promise to exist.

For actual artifacts such as cloud/disk/installer images I agree but
at least pushing out individual packages so people can do "dnf
upgrade" picks up issues such as dependency issues that also kill the
compose and allows people to still test explicit parts and have the
composite parts of a "rolling release" and get things fixed I feel
that's better than dragging everything to a blinding halt like we have
for the last 13... or is it 14 days?

I can't help but feel this is like British politics is ATM where
people are claiming everything is "strong and stable" while the wheels
have fallen off and are rolling down the road. I don't think pushing
out the Everything repo stops the "kill off Alpha" process from
happening, in fact I believe it means it's more likely to happen
because if the last two weeks shows anything all that happens is that
if we wait for a "everything is perfect ship it" we never will and
because nothing is shipped nothing is tested so once we get to the
"computer thinks it's good" we can get to the actual testing and then
we get to "what the hell changed in the last two weeks broke X, Y and
Z, are they related or completely independent?" process.

I think the all or nothing actually makes it less likely for us to
ever ship anything! I don't think shipping the traditional
"Everything" repo breaks the "kill Alpha" proposal, I think we need to
be pragmatic and realise that people actually consuming content helps
that.

Peter "yes I live in the as strong and stable as a house of cards
country so I can joke/comment on it" R
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Retiring Packages with Broken Dependencies in branched (2017-06-12)

[Till Maas]

On Mon, Jun 12, 2017 at 04:12:04PM -0700, Adam Williamson wrote:

> Oh, I see the problem now, though it doesn't explain the '73 weeks
> ago':

The 73 weeks relates to the state in pkgdb and I should have removed it
from the report. It is not useful here. :-/

> 
> [os-autoinst]
> os-autoinst-openvswitch-4.4-18.20170410git97928a2.fc26.armv7hl 
> requires openvswitch
> [os-autoinst]
> os-autoinst-openvswitch-4.4-18.20170410git97928a2.fc26.ppc64 requires 
> openvswitch
> 
> so the problem is that the current stable openvswitch was not built for
> two arches; the openvswitch package currently in updates-testing *is*
> built for those arches, however. It seems pointless to send out an
> update that disables the subpackage for two arches for a few days until
> openvswitch is pushed stable.

As long as all updates are stable for the Final Freeze to fix the broken
deps there should be no problem.

> Perhaps the proliferation of arches in primary Koji might cause a
> rethink of how this automatic retirement works? It wouldn't seem to be
> a good idea to automatically retire this package (which is in fact
> quite important, and under active maintenance) on this basis.

It sounds like several broken deps will be resolved, soon, so there will
be a different picture. Since we only do up to two cleanups a year for
broken deps, it would a good chance to at least add proper
ExcludeArch/ExclusiveArch tags to packages that we cannot fix for the
Final Freeze. If this is not possible I am sure we will find a solution
that does not require to retire well-maintained packages.

Kind regards
Till
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Rawhide: where for art thou? (why no rawhide composes recently)

[Matthew Miller]

On Tue, Jun 13, 2017 at 03:31:37PM -0600, Kevin Fenzi wrote:
> > I know we're already at new-deliverable explosion, but this seems like
> > a place where it'd be nice to have Rawhide and Bikeshed (or whatever we
> > want to call "tested and believed-to-be basically functional Rawhide").
> (Side note: I am not sure why we can't just make these the same thing...
> ie, always have rawhide basically functional).

Well... I guess because the reason it isn't functional right now is
non-trivial?

-- 
Matthew Miller

Fedora Project Leader
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

F26 Mesa update

[Michael Cronenworth]

Hello,

Is there a reason for delaying the update for mesa-17.1.2 to F26?

We're getting buildroot failures for some F26 packages that depend on mesa (llvm was 
updated).


Thanks,
Michael
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: F26 Mesa update

[Orion Poplawski]

On 06/13/2017 06:32 PM, Michael Cronenworth wrote:

Hello,

Is there a reason for delaying the update for mesa-17.1.2 to F26?

We're getting buildroot failures for some F26 packages that depend on 
mesa (llvm was updated).


Thanks,
Michael


something seems to be messed up.  llvm 4.0 should be in f26:

https://koji.fedoraproject.org/koji/buildinfo?buildID=889106

but:

DEBUG util.py:439:  Error: nothing provides libLLVM-4.0.so()(64bit) 
needed by mesa-dri-drivers-17.1.1-2.fc26.x86_64.
DEBUG util.py:439:  nothing provides libLLVM-4.0.so()(64bit) needed by 
mesa-libOSMesa-17.1.1-2.fc26.x86_64




--
Orion Poplawski
Technical Manager 303-415-9701 x222
NWRA/CoRA DivisionFAX: 303-415-9702
3380 Mitchell Lane  or...@cora.nwra.com
Boulder, CO 80301  http://www.cora.nwra.com
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: dnf bodhi plugin

[Sérgio Basto]

On Fri, 2017-05-19 at 16:04 +, Zbigniew Jędrzejewski-Szmek wrote:
> On Fri, May 19, 2017 at 11:48:37AM -0400, Matthew Miller wrote:
> > On Fri, May 19, 2017 at 11:44:57AM -0400, Matthew Miller wrote:
> > > See https://bugzilla.redhat.com/show_bug.cgi?id=1234930
> > > 
> > > It's my understanding this functioanlity is already being worked
> > > on in
> > > DNF 2.0, to match the yum functionality of "sudo yum upgrade
> > > --advisory FEDORA-2017-30604deb62"
> > 
> > Yeah, I just tested and this works:
> > 
> > $ sudo dnf upgrade --advisory FEDORA-2017-f590422f5b
> 
> Oh, that's super nice.
> 
> Randy, what about redirecting the effort to support the same for koji
> builds? I think that functionality is missing and it'd be quite
> useful
> for packagers (e.g. to test that an update will be OK before actually
> creating
> the update):
>   dnf install-koji 886677,886693
> or even
>   dnf install-koji package-version,package-version
> ?

you have `koji download-build package-evr` that may help you 

for example: 

koji download-build -a x86_64 po-debconf-1.0.16-8.nmu3.fc24 


> Zbyszek
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
-- 
Sérgio M. B.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org