Re: Fedora developer portal - proof of concept
On 23 Jul 2015 01:17, "Adam Samalik" wrote: > > Hi everyone, > > I updated the prototype and tried apply your feedback: https://developer-phracek.rhcloud.com/ Very nice! > What I would like to do next? Ideally, if you find some time, I would like to have a session with you, people interested in this project, to discuss the content, structure and basically everything related to this. For example, I really like how the Fedora Hubs project [2] is going. If we could do something similar, even when the Fedora Developer Portal is not that big, it would be really nice. I'd be interested in attending a session like that (but would also understand if having Australia in the time zone mix proved impractical from the point of view of scheduling a discussion). Regards, Nick. -- 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 developer portal - proof of concept
Hi Nick, thanks! What I'm still missing in the current prototype is the "problem to be solved" starting point - as you pointed out at the env-and-stacks meeting. For example: I want to develop a web application. The site would give me options like Django, Flask, Ruby on Rails, PHP, Jekyll,... Or even better, something more precise like deciding the type of the web app: an application with backend and database, a static site, blog or a wiki page? The tech-specific overview would show up afterwards. Suitable tools and deployment option would show up as well. What do you think? About the session vs time zones, I haven't realized that we are literally all around the world :-) Personally, I'm very flexible with timing and willing to do a session at (I know I will regret that at 3 AM) any time. It's very important for me to make it successful. Or we can do more than one. I will attend both/all of them. Adam - Original Message - From: "Nick Coghlan" To: "Development discussions related to Fedora" Cc: "Fedora Environment and Stacks Working Group mailing list" , ncogh...@redhat.com, du...@redhat.com Sent: Friday, 24 July, 2015 10:45:06 AM Subject: Re: Fedora developer portal - proof of concept On 23 Jul 2015 01:17, "Adam Samalik" < asama...@redhat.com > wrote: > > Hi everyone, > > I updated the prototype and tried apply your feedback: > https://developer-phracek.rhcloud.com/ Very nice! > What I would like to do next? Ideally, if you find some time, I would like to > have a session with you, people interested in this project, to discuss the > content, structure and basically everything related to this. For example, I > really like how the Fedora Hubs project [2] is going. If we could do > something similar, even when the Fedora Developer Portal is not that big, it > would be really nice. I'd be interested in attending a session like that (but would also understand if having Australia in the time zone mix proved impractical from the point of view of scheduling a discussion). Regards, Nick. -- 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: Boost updated to 1.58.0 in rawhide and f23
On 23/07/15 14:39 -0700, Josh Stone wrote: On 07/23/2015 02:33 PM, Josh Stone wrote: Is this a general failure in f23-boost, or just a few packages? The f23-boost target tag is using build tag f23-build! http://koji.fedoraproject.org/koji/buildtargetinfo?targetID=150 vs f24-boost has itself for both build and destination tag: http://koji.fedoraproject.org/koji/buildtargetinfo?targetID=154 Thanks for spotting that. I should read more koji docs so I actually understand these things and I might have noticed it myself. Am I right in thinking the build tag defines which other packages it uses to build against, and the destination tag defines where it goes after it's built? So everything that was rebuilt was going to the right tag, but nothing else looked at those rebuilt packages? -- 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: Boost updated to 1.58.0 in rawhide and f23
On 23/07/15 14:33 +0200, David Tardon wrote: Hi, On Thu, Jul 23, 2015 at 02:27:33PM +0200, David Tardon wrote: Hi, On Sat, Jul 18, 2015 at 12:46:51PM +0100, Jonathan Wakely wrote: > Any problems rebuilding either open a bug or feel free to email me or > ping me on IRC (my freenode nick is 'redi') and I'll be happy to help. This is a work-in-progress list of FTBFS packages: * Build failures: - F23 + Rawhide xs This fails with: /usr/bin/ld: xmlcopyeditor.o: relocation R_X86_64_32 against `_ZN7MyFrame13sm_eventTableE' can not be used when making a shared object; recompile with -fPIC xmlcopyeditor.o: error adding symbols: Bad value which doesn't seem related to Boost, and indeed I see the same failure on plain rawhide, without the f4-boost tag. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
PyX update for Fedora 23 and rawhide just supports python 3
I will update PyX, a Python graphics package, to version 0.14. Since version 0.13, released in December of 2013, that PyX transitioned from python 2 to 3. So the new version (and version 0.13 before) only supports python 3, while version 0.12 was a strict python 2 version. The update will be pushed to f23+. Regards, -- José Abílio -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
pkgdb_updater updated: summary, description of perl-MooX-ConfigFromFile
pkgdb_updater updated: summary, description of perl-MooX-ConfigFromFile https://admin.fedoraproject.org/pkgdb/package/perl-MooX-ConfigFromFile/ -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-de...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
Re: Boost updated to 1.58.0 in rawhide and f23
On 24/07/15 11:00 +0100, Jonathan Wakely wrote: On 23/07/15 14:33 +0200, David Tardon wrote: Hi, On Thu, Jul 23, 2015 at 02:27:33PM +0200, David Tardon wrote: Hi, On Sat, Jul 18, 2015 at 12:46:51PM +0100, Jonathan Wakely wrote: Any problems rebuilding either open a bug or feel free to email me or ping me on IRC (my freenode nick is 'redi') and I'll be happy to help. This is a work-in-progress list of FTBFS packages: * Build failures: - F23 + Rawhide xs Gah, sorry, this is for the xmlcopyeditor package, not xs (I'm in the process of reporting the xs bug upstream and got my packages beginning with 'x' mixed up :-) This fails with: /usr/bin/ld: xmlcopyeditor.o: relocation R_X86_64_32 against `_ZN7MyFrame13sm_eventTableE' can not be used when making a shared object; recompile with -fPIC xmlcopyeditor.o: error adding symbols: Bad value which doesn't seem related to Boost, and indeed I see the same failure on plain rawhide, without the f4-boost tag. -- 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: Boost updated to 1.58.0 in rawhide and f23
On 23/07/15 19:06 +0100, Jonathan Wakely wrote: The attached patch fixes the xs build for rawhide. Upstream fixed it differently: https://github.com/frytvm/XS/commit/034bab9965ab554c4e51053d65cf18a9f40192db I'll add that patch to the spec file instead. -- 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: Boost updated to 1.58.0 in rawhide and f23
On 23/07/15 22:33, Josh Stone wrote: On 07/22/2015 07:50 AM, Jonathan Wakely wrote: On 22/07/15 15:30 +0100, Tom Hughes wrote: On 22/07/15 14:54, Jonathan Wakely wrote: mapnik-0:2.2.1-0.4.20150127git0639d54.fc23.src nodejs-mapnik-vector-tile-0:0.6.2-6.fc23.src I did these for both branches when you announced it at the weekend. Great, thanks. nodejs-mapnik-0:1.4.17-7.fc23.src This one is proving more interesting... It builds fine for F23 but fails some tests on F24 although it still builds fine with the old boost. As best I can tell it's down to boost::spirit::karma but that hasn't actually changed in the new boost, and in any case the new boost works in F23. I'm kind of stumped at the moment. I'll look into it and see if I can figure it out. It's good that the F23 build is OK, as that's obviously the one with more time pressure. Beware! I was just looking into dyninst, which also succeeded on F23 but failed on F24. But looking at the root.log for F23 reveals it still had 1.57! f23-boost: http://koji.fedoraproject.org/koji/buildinfo?buildID=671537 f24-boost: http://koji.fedoraproject.org/koji/buildinfo?buildID=670925 nodejs-mapnik on f23-boost also had boost 1.57: http://koji.fedoraproject.org/koji/buildinfo?buildID=669822 Now that I have rebuilt everything again both builds of nodejs-mapnik are failing, so at least there is some consistency... Tom -- Tom Hughes (t...@compton.nu) http://compton.nu/ -- 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] FTBFS Packages in rawhide (2015-07-22)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Dne 23.7.2015 v 21:23 Dennis Gilmore napsal(a): > On Thursday, July 23, 2015 09:44:58 AM Vít Ondruch wrote: >> Dne 22.7.2015 v 21:43 opensou...@till.name napsal(a): >>> rubygem-git-up jvcelak 62 weeks ago >> >> This is actually interesting piece. This might or might not be FTBFS. >> This package was not touched by mass rebuild scripts, since it contains >> "noautobuild" file [1, 2], which (although not mentioned in F23 mass >> rebuild page [3]) is apparently honored. So this package should not be >> retired IMO and I am wondering how many other similar packages we have >> in Fedora. >> >> Till, would you mind to improve your script? >> >> Actually I am not sure what is the state of "noautobuild". It is not >> mentioned in F23 mass rebuild notes [3] at all, for F21 there is >> mentioned opt-out [4] but the actual section is missing. For F20 - F15 >> was opt-out probably disabled [5]. > > opt out was disabled in the f21 mass rebuild. but was not disabled in any > other rebuild. Well, the mass rebuild pages says otherwise, you can take F20 as an example: https://fedoraproject.org/wiki/Fedora_20_Mass_Rebuild#Opting_Out But this might be just Copy/Paste issue. > if you have the noautobuild file in place the onus is on you to > build the package yourself. Perhaps we should remove all ability to opt out. +1 for removing the opt-out. Or does anybody have any valid reason for not rebuilding his/her packages? I don't think "The rubygem-git-up package is noarch, rebuild is usualy not needed." is good justification. > > > in this case I think retiring the package is the right thing to do unless it > is rebuilt. Till removed the "noautobuild" and rebuilt the package, so problem solved for this instance. Vít -BEGIN PGP SIGNATURE- Version: GnuPG v2 iQIcBAEBCAAGBQJVshlyAAoJEAzgnueZF7h8TrsP/3fMAExlQMD+zVY88AtNoQr/ QwC7gZ2IOLNRmDZs4D88b3gCnZMmecZoSt8WsncN+98/Fzpot9hLTlT5wV0tGhMV xMFSkVKJ0ew20QXUgCBqjwq0kdYrlWS2BLexjtt5ZiGpr+WOrWIPZAYygXYtPkOK hdWUVMPYcAnxgPgyz91t3IkcZF+LcmSpmKCfhIg66uLZ5QOaUda1NYc6D+r0dFE7 nHYMVTSUqSbah+koWj1GFUIsnhIMhsWCEUZM2nMMSnYHVD7DL1+EOcc8udNHL7/h ZLRMm422eO5uFP89Mui2bfxKL7yWyceS6UHViaap3z91OhgyuPmcbIouW243h6Gu uCPgR4sazEZD4eza6P3LQvNeanOGfAy1CQGfKH5dxk6G31EEWkxehLlmg31McJRT CEOz32K8kjKUxg49EooBdbxMgbIopZm9BNfQGepNA0vg3WXBS0J/bKh0UZhiMNs6 x5kBPJiFHRGqUcY/CkG7u/kpknzeinBbabNTpv9eYMW3yTwlaGe1urbWfz4u/4O7 gyCaplnm34x6MtsqqhmVqG0vQXFZhYVVqlmafucAEgtiQ8IrANTa571andmdXnw3 jIxcCVOK0TShKtDP267eKE8rIZQ6zPqZxz4JKO7W9m0hCoi+LGbneyjPj6Fu8xjo L0DSo/e7mnRn2zgQvY6V =oM1K -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
Broken dependencies: perl-Test-Vars
perl-Test-Vars has broken dependencies in the F-23 tree: On x86_64: perl-Test-Vars-0.005-6.fc22.noarch requires perl(:MODULE_COMPAT_5.20.0) On i386: perl-Test-Vars-0.005-6.fc22.noarch requires perl(:MODULE_COMPAT_5.20.0) On armhfp: perl-Test-Vars-0.005-6.fc22.noarch requires perl(:MODULE_COMPAT_5.20.0) Please resolve this as soon as possible. -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-de...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
perl-File-Find-Object license change
perl-File-Find-Object-0.2.13-1.fc24 changes license from (GPLv2+ or Artistic) to (GPLv2+ or Artistic 2.0). -- 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: Boost updated to 1.58.0 in rawhide and f23
On Thursday, July 23, 2015 02:39:53 PM Josh Stone wrote: > On 07/23/2015 02:33 PM, Josh Stone wrote: > > Is this a general failure in f23-boost, or just a few packages? > > The f23-boost target tag is using build tag f23-build! > http://koji.fedoraproject.org/koji/buildtargetinfo?targetID=150 I have fixed this, everything built for f23-boost will need to be rebuilt Dennis > vs f24-boost has itself for both build and destination tag: > http://koji.fedoraproject.org/koji/buildtargetinfo?targetID=154 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
F-23 Branched report: 20150724 changes
Compose started at Fri Jul 24 07:15:03 UTC 2015 Broken deps for armhfp -- [apache-scout] apache-scout-1.2.6-11.fc21.noarch requires mvn(org.apache.juddi:uddi-ws) apache-scout-1.2.6-11.fc21.noarch requires mvn(org.apache.juddi:juddi-client) [aws] aws-tools-2015-2.fc23.armv7hl requires libaws_ssl.so [bluetile] bluetile-0.6-28.fc23.armv7hl requires libHSpango-0.13.0.5-ghc7.8.4.so bluetile-0.6-28.fc23.armv7hl requires libHSgtk-0.13.4-ghc7.8.4.so bluetile-0.6-28.fc23.armv7hl requires libHSglib-0.13.0.7-ghc7.8.4.so bluetile-0.6-28.fc23.armv7hl requires libHSgio-0.13.0.4-ghc7.8.4.so bluetile-0.6-28.fc23.armv7hl requires ghc(pango-0.13.0.5-0fe13302ab9696f4be39a474ef640c67) bluetile-0.6-28.fc23.armv7hl requires ghc(gtk-0.13.4-952587399cc6bbaffa0a5a0acbb89116) bluetile-0.6-28.fc23.armv7hl requires ghc(glib-0.13.0.7-da7af048681401db23082470f4a21a05) bluetile-0.6-28.fc23.armv7hl requires ghc(gio-0.13.0.4-6e8649bb2527e539c8a16a338226fe59) bluetile-core-0.6-28.fc23.armv7hl requires libHSxmonad-contrib-0.11.3-ghc7.8.4.so bluetile-core-0.6-28.fc23.armv7hl requires libHSxmonad-0.11-ghc7.8.4.so bluetile-core-0.6-28.fc23.armv7hl requires ghc(xmonad-contrib-0.11.3-478caab82eecee607d1e38de521b1d39) bluetile-core-0.6-28.fc23.armv7hl requires ghc(xmonad-0.11-57a5efb379c3c72328a03242ff2b217e) [bustle] bustle-0.4.8-3.fc23.armv7hl requires libHSsetlocale-1.0.0.1-ghc7.8.4.so bustle-0.4.8-3.fc23.armv7hl requires libHSpango-0.13.0.5-ghc7.8.4.so bustle-0.4.8-3.fc23.armv7hl requires libHSgtk-0.13.4-ghc7.8.4.so bustle-0.4.8-3.fc23.armv7hl requires libHSglib-0.13.0.7-ghc7.8.4.so bustle-0.4.8-3.fc23.armv7hl requires libHSgio-0.13.0.4-ghc7.8.4.so bustle-0.4.8-3.fc23.armv7hl requires ghc(setlocale-1.0.0.1-ac2c917693b349254e738a23a8498d85) bustle-0.4.8-3.fc23.armv7hl requires ghc(pango-0.13.0.5-0fe13302ab9696f4be39a474ef640c67) bustle-0.4.8-3.fc23.armv7hl requires ghc(hgettext-0.1.30-aaf24a59a6ce4284e068de299f4fa833) bustle-0.4.8-3.fc23.armv7hl requires ghc(gtk-0.13.4-952587399cc6bbaffa0a5a0acbb89116) bustle-0.4.8-3.fc23.armv7hl requires ghc(glib-0.13.0.7-da7af048681401db23082470f4a21a05) bustle-0.4.8-3.fc23.armv7hl requires ghc(gio-0.13.0.4-6e8649bb2527e539c8a16a338226fe59) [cockpit] cockpit-docker-0.66-1.fc23.armv7hl requires docker >= 0:1.3.0 [dislocker] dislocker-0.4.1-4.fc23.armv7hl requires libmbedtls.so.9 dislocker-libs-0.4.1-4.fc23.armv7hl requires libmbedtls.so.9 fuse-dislocker-0.4.1-4.fc23.armv7hl requires libmbedtls.so.9 [dpm-contrib-admintools] dpm-contrib-admintools-0.2.1-6.fc23.armv7hl requires MySQL-python(armv7hl-32) [ffgtk] ffgtk-plugin-evolution-0.8.6-14.fc23.armv7hl requires libebook-contacts-1.2.so.1 ffgtk-plugin-evolution-0.8.6-14.fc23.armv7hl requires libcamel-1.2.so.53 [gammaray] gammaray-qt5-2.2.1-10.fc23.armv7hl requires qt5-qtbase(armv7hl-32) = 0:5.4.2 [ghc-glade] ghc-glade-0.12.5.0-5.fc23.armv7hl requires libHSpango-0.13.0.5-ghc7.8.4.so ghc-glade-0.12.5.0-5.fc23.armv7hl requires libHSgtk-0.13.4-ghc7.8.4.so ghc-glade-0.12.5.0-5.fc23.armv7hl requires libHSglib-0.13.0.7-ghc7.8.4.so ghc-glade-0.12.5.0-5.fc23.armv7hl requires libHSgio-0.13.0.4-ghc7.8.4.so ghc-glade-0.12.5.0-5.fc23.armv7hl requires ghc(gtk-0.13.4-952587399cc6bbaffa0a5a0acbb89116) ghc-glade-0.12.5.0-5.fc23.armv7hl requires ghc(glib-0.13.0.7-da7af048681401db23082470f4a21a05) ghc-glade-devel-0.12.5.0-5.fc23.armv7hl requires ghc-devel(gtk-0.13.4-952587399cc6bbaffa0a5a0acbb89116) ghc-glade-devel-0.12.5.0-5.fc23.armv7hl requires ghc-devel(glib-0.13.0.7-da7af048681401db23082470f4a21a05) [ghc-gtksourceview2] ghc-gtksourceview2-0.13.1.2-2.fc23.armv7hl requires libHSpango-0.13.0.5-ghc7.8.4.so ghc-gtksourceview2-0.13.1.2-2.fc23.armv7hl requires libHSgtk-0.13.4-ghc7.8.4.so ghc-gtksourceview2-0.13.1.2-2.fc23.armv7hl requires libHSglib-0.13.0.7-ghc7.8.4.so ghc-gtksourceview2-0.13.1.2-2.fc23.armv7hl requires libHSgio-0.13.0.4-ghc7.8.4.so ghc-gtksourceview2-0.13.1.2-2.fc23.armv7hl requires ghc(gtk-0.13.4-952587399cc6bbaffa0a5a0acbb89116) ghc-gtksourceview2-0.13.1.2-2.fc23.armv7hl requires ghc(glib-0.13.0.7-da7af048681401db23082470f4a21a05) ghc-gtksourceview2-devel-0.13.1.2-2.fc23.armv7hl requires ghc-devel(gtk-0.13.4-952587399cc6bbaffa0a5a0acbb89116) ghc-gtksourceview2-devel-0.13.1.2-2.fc23.armv7hl requires ghc-devel(glib-0.13.0.7-da7af048681401db23082470f4a21a05) [ghc-hjsmin] ghc-hjsmin-0.1.4.7-7.fc23.armv7hl requires ghc(language-javascript-0.5.13-09e4f74578c09254f3515579177112ae) ghc-hjsmin-devel-0.1.4.7-7.fc23.armv7hl requires ghc-devel(language-javascript-0.5.13-09e4f745
Re: Packaging golang for secondary architectures, go-srpm-macros
Dne 9.7.2015 v 11:18 Jan Chaloupka napsal(a):
>
> Recommended use in spec file:
> 1) To choose the correct compiler:
> %ifarch %{golang_arches}
> BuildRequires: golang
> %else
> BuildRequires: gcc-go >= %{gccgo_min_vers}
> %endif
>
> 2) To choose the correct command for building and testing:
> %ifarch %{golang_arches}
> %{golang_build} -o bin/binary %{import_path}/binary
> %{golang_test} %{import_path}/binary
> %else
> %{gcc_go_build} -o bin/binary %{import_path}/binary
> %{gcc_go_test} %{import_path}/binary
> %endif
>
Why are you not using the %{?golang_arches} and similar (i.e. with the
"?" at the beginning). Why the GO compilers does not provide some
virtual provide, which ensures that the compiler is available, without
even checking for architecture? This would avoid the need of requiring
go-srpm-macros by redhat-rpm-config and it could be build require just
by Go packages.
This is definitely step backward.
Vít
--
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: F-23 Branched report: 20150724 changes
Dne 24.7.2015 v 14:01 Fedora Branched Report napsal(a): > Broken deps for armhfp > Broken deps for i386 > Broken deps for x86_64 > Welcome back ;) ... and thanks to all involved for fixing this. Vít -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
[HEADS UP] rpm-4.12.90 in rawhide
The freshly released rpm-4.12.90 aka rpm-4.13.0-alpha is going to hit rawhide soon. The two major new features are: * Boolean (aka rich) dependencies to support more complicated relation between packages * File Triggers - run scripts if files get installed in given paths - possibly to replace most of the regular - per package - scriptlets at some point in the future. But for now and for Fedora this update is more about testing and stabilizing the many smaller changes as far as they have not been ported back already. See the draft release notes for details: http://rpm.org/wiki/Releases/4.13.0 Florian -- 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
[HEADS UP] policycoreutils - python3 and utilities moved to policycoreutils-python-utils
Hi, I've just pushed an update of policycoreutils which defaults to python 3 and with python utilities moved from policycoreutils-python to policycoreutils-python-utils. Both changes were requested by Python team as part of their Fedora Change [1]. Since the conversion to python 3 is in its early phase and probably not complete yet, there might occur problems with update and with the implementation. Please test and file bugs which should be set to block the change tracker bug [2] so the python team can provide fixes and help. [1] https://fedoraproject.org/wiki/Changes/Python_3_as_Default [2] https://bugzilla.redhat.com/show_bug.cgi?id=1076441 Thanks, Petr -- Petr Lautrbach 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: Boost updated to 1.58.0 in rawhide and f23
On 07/24/2015 02:31 AM, Jonathan Wakely wrote: > On 23/07/15 14:39 -0700, Josh Stone wrote: >> On 07/23/2015 02:33 PM, Josh Stone wrote: >>> Is this a general failure in f23-boost, or just a few packages? >> >> The f23-boost target tag is using build tag f23-build! >> http://koji.fedoraproject.org/koji/buildtargetinfo?targetID=150 >> >> vs f24-boost has itself for both build and destination tag: >> http://koji.fedoraproject.org/koji/buildtargetinfo?targetID=154 > > Thanks for spotting that. I should read more koji docs so I actually > understand these things and I might have noticed it myself. > > Am I right in thinking the build tag defines which other packages it > uses to build against, and the destination tag defines where it goes > after it's built? So everything that was rebuilt was going to the > right tag, but nothing else looked at those rebuilt packages? That's the way I understand it, yes. -- 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] rpm-4.12.90 in rawhide
On Fri, Jul 24, 2015 at 4:49 PM, Florian Festi wrote: > See the draft release notes for details: http://rpm.org/wiki/Releases/4.13.0 > Terminate builds on empty files (?_empty_manifest_terminate_build) That should probably read "on empty manifest files". Anyway, one effect of this is that empty debuginfo packages will now cause builds to fail, yay! -- 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: Boost updated to 1.58.0 in rawhide and f23
On Thu, Jul 23, 2015 at 6:27 AM, David Tardon wrote: > This is a work-in-progress list of FTBFS packages: > > * Build failures: > > - F23 + Rawhide ... > polymake The polymake build was already broken for other reasons (namely, the latest perl update broke it, which happens with pretty much every perl update). I am working with polymake upstream to resolve the issue. -- Jerry James http://www.jamezone.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: Boost updated to 1.58.0 in rawhide and f23
On 23/07/15 14:33 +0200, David Tardon wrote:
Hi,
On Thu, Jul 23, 2015 at 02:27:33PM +0200, David Tardon wrote:
Hi,
On Sat, Jul 18, 2015 at 12:46:51PM +0100, Jonathan Wakely wrote:
> Any problems rebuilding either open a bug or feel free to email me or
> ping me on IRC (my freenode nick is 'redi') and I'll be happy to help.
This is a work-in-progress list of FTBFS packages:
* Build failures:
- F23 + Rawhide
adobe-source-libraries
This won't even install the BuildRequires, it fails with an error
about libpoppler.so
Error: Package:
4:texlive-pdftex-bin-svn30845.0-11.20140525_r34255.fc23.1.x86_64 (build)
Requires: libpoppler.so.52()(64bit)
Error: Package:
4:texlive-luatex-bin-svn31084.0-11.20140525_r34255.fc23.1.x86_64 (build)
Requires: libpoppler.so.52()(64bit)
Doesn't look related to Boost.
blobby
blobby needs this patch to build:
http://git.engineering.redhat.com/git/users/jwakely/fedora/blobby/commit/?h=ostream
(I've sent the patch to one of the upstream project maintainers).
But it still fails anyway with:
/usr/bin/ld: CMakeFiles/blobby.dir/BlobbyDebug.cpp.o: relocation R_X86_64_32
against `.bss' can not be used when making a shared object; recompile with -fPIC
CMakeFiles/blobby.dir/BlobbyDebug.cpp.o: error adding symbols: Bad value
which doesn't seem to be a Boost problem.
condor
Another BuildRequires failure with libpoppler.so
elektra
/builddir/build/BUILD/elektra-0.8.7/src/bindings/swig/python3/kdb.i:77: Error:
Unknown SWIG preprocessor directive: TODO (if this is a block of target
language code, delimit it with %{ and %})
src/bindings/swig/python3/CMakeFiles/_swig-python3.dir/build.make:64: recipe
for target 'src/bindings/swig/python3/kdbPYTHON_wrap.cxx' failed
Probably not Boost related.
fityk
Not Boost related:
app.cpp:12:2: error: #error "Not everything is working with wxGTK3. Use default wxGTK
instead, " "based on GTK+2. If you want to test it, just remove this #error."
flamerobin
This looks like a Boost problem:
configure: error: invalid value: boost_major_version=
But actually it's caused by a GCC change that puts a # preprocessor
marker before macro expansions:
boost-lib-version =
# 2 "/tmp/conftest.cpp" 3 4
"1_58"
The configure script needs to use -P as described at
https://gcc.gnu.org/gcc-5/porting_to.html
inkscape
Fails due to a glibmm problem, see adamw's email in this thread.
scantailor
This has some weird CMake error about being unable to figure out how
to use -pthread.
xmlcopyeditor
This fails with a "recompile with -fPIC" error that doesn't seem
related to Boost.
xs
This is fixed.
I'll keep checking the remaining failures, but maybe not until Monday.
--
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: building an embedded Linux distro into a RPM package
On Thu, 23 Jul 2015 10:19:26 -0400 Chuck Anderson wrote: ...snip... > I would like to submit a new package that provides a Pre-Boot > Authorization (PBA) image. The PBA is a "bootloader" of sorts that > prompts the user for the passphrase to unlock a Self-Encrypting Drive > (SED) using the TCG OPAL command set, and then either chainloads to > the real OS or reboots to allow the BIOS to boot the real OS. The > image gets installed to the OPAL SED as a sort of "shadow MBR/shadow > disk image" using a special command "msed" (Manage Self-Encrypting > Drive) that I also plan to submit a package for. So, the idea would be someone would 'dnf install' this package, run msed and then reboot to have it take effect? > In my case, I've developed a tiny embedded Linux-based PBA image [1] > using Buildroot [2] and the MSED software [3]. The final image is a > MBR-partitioned disk image with VFAT filesystem containing the > specially built Linux kernel (vmlinuz), initramfs (rootfs.gz), and the > installed syslinux bootloader. > > Before you ask, I can't use even a stripped-down Fedora image for this > purpose, because it must be TINY and it only exists to run a single > command (linuxpba), then reboot. My image is 4MB and could be made > even smaller. See the reasoning in [1] for why it must be so small. > > [1] https://github.com/cranderson/buildroot-linuxpba > [2] http://buildroot.uclibc.org/ > [3] http://www.r0m30.com/msed > > Now I know there are several challenges to using the Buildroot > approach to building software for Fedora. Buildroot downloads > software from the Internet, unpacks, patches, configures, and builds > it. The build environment is built first, so gcc, uClibc, busybox, > etc. and then the packages you want to include are built in that > environment. > > What is the best approach I should use that is acceptable to Fedora? I'm not sure. :) > Would it be acceptable to bundle source packages, Buildroot itself, > and my Buildroot configuration into one SRPM so everything is > self-contained and can be built without requiring network > connectivity? This means I would have to bundle the source code for > gcc, the linux kernel, uClibc, busybox, etc. > > Or is there some way to pull in SRPM packages that already exist in > Fedora, and use those as part of my build process so that I don't have > to bundle all the source code? Additionally, I could made separate > SRPM packages for Buildroot itself, any components needed (uClibc is > already in the distro), the Buildroot build scripts for > buildroot-linuxpba, and the actual package I need (msed). This sounds to me like something thats better suited to be composed and shipped as some kind of image instead of being a package. I can see the appeal of a package however since it's so small. The build system will not let you download stuff from the net. If we did builds would not be reproducable. You cannot use the existing gcc/busybox/etc to build the image? Alternately, how intensive is this image build? Perhaps you could package the tools (as you are) and the end user can create their own image? kevin pgpusaseAm6HO.pgp 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: Boost updated to 1.58.0 in rawhide and f23
On Fri, Jul 24, 2015 at 19:26:09 +0100, Jonathan Wakely wrote: blobby blobby needs this patch to build: http://git.engineering.redhat.com/git/users/jwakely/fedora/blobby/commit/?h=ostream (I've sent the patch to one of the upstream project maintainers). But it still fails anyway with: /usr/bin/ld: CMakeFiles/blobby.dir/BlobbyDebug.cpp.o: relocation R_X86_64_32 against `.bss' can not be used when making a shared object; recompile with -fPIC CMakeFiles/blobby.dir/BlobbyDebug.cpp.o: error adding symbols: Bad value which doesn't seem to be a Boost problem. I have taken a couple of looks at blobby and I'll take a look at your patch. Unfortunately the svn repo at sourceforge is broken right now, so I can't see if there is a later snapshot than we are using that might be better. It looks like the issue is something might be fixed in a few days or weeks. Blobby was FTBFS before the boost update, so likely there isn't a boost issue. -- 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: Boost updated to 1.58.0 in rawhide and f23
On Fri, Jul 24, 2015 at 19:26:09 +0100, Jonathan Wakely wrote: blobby needs this patch to build: http://git.engineering.redhat.com/git/users/jwakely/fedora/blobby/commit/?h=ostream Could you attach a copy of that patch to https://bugzilla.redhat.com/show_bug.cgi?id=1239387 (the blobby FTBFS f23 bug) as the patch doesn't appear to be on a public server. -- 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: Boost updated to 1.58.0 in rawhide and f23
On Fri, 2015-07-24 at 19:26 +0100, Jonathan Wakely wrote: > On 23/07/15 14:33 +0200, David Tardon wrote: > > Hi, > > > > On Thu, Jul 23, 2015 at 02:27:33PM +0200, David Tardon wrote: > > > Hi, > > > > > > On Sat, Jul 18, 2015 at 12:46:51PM +0100, Jonathan Wakely wrote: > > > > Any problems rebuilding either open a bug or feel free to email > > > > me or > > > > ping me on IRC (my freenode nick is 'redi') and I'll be happy > > > > to help. > > > > > > This is a work-in-progress list of FTBFS packages: > > > > > > * Build failures: > > > > > > - F23 + Rawhide > > > > > > adobe-source-libraries > > This won't even install the BuildRequires, it fails with an error > about libpoppler.so > > Error: Package: 4:texlive-pdftex-bin-svn30845.0 > -11.20140525_r34255.fc23.1.x86_64 (build) >Requires: libpoppler.so.52()(64bit) > Error: Package: 4:texlive-luatex-bin-svn31084.0 > -11.20140525_r34255.fc23.1.x86_64 (build) >Requires: libpoppler.so.52()(64bit) > > Doesn't look related to Boost. poppler got an soname bump at approximately the same time as boost, which is confusing things. Obviously texlive has not yet been rebuilt for the new poppler. For any poppler case, I'd say just go ahead and fire the rebuild. Well, possibly except for texlive, it's never wise to touch texlive until you've said the sacred incantations and sacrificed at least six chickens. > > > inkscape > > Fails due to a glibmm problem, see adamw's email in this thread. I've already worked around that and rebuilt it for main f23 and f24, you should be able to just bump again and build against f23-boost and f24-boost and it'll either succeed or fail for some more boost-y reason. :) > > > xmlcopyeditor > > This fails with a "recompile with -fPIC" error that doesn't seem > related to Boost. fPIC stuff is likely to be related to the newish hardening flags, see https://fedoraproject.org/wiki/Changes/Harden_All_Packages . -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net http://www.happyassassin.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: building an embedded Linux distro into a RPM package
On Fri, Jul 24, 2015 at 12:54:23PM -0600, Kevin Fenzi wrote: > On Thu, 23 Jul 2015 10:19:26 -0400 > Chuck Anderson wrote: > > ...snip... > > > I would like to submit a new package that provides a Pre-Boot > > Authorization (PBA) image. The PBA is a "bootloader" of sorts that > > prompts the user for the passphrase to unlock a Self-Encrypting Drive > > (SED) using the TCG OPAL command set, and then either chainloads to > > the real OS or reboots to allow the BIOS to boot the real OS. The > > image gets installed to the OPAL SED as a sort of "shadow MBR/shadow > > disk image" using a special command "msed" (Manage Self-Encrypting > > Drive) that I also plan to submit a package for. > > So, the idea would be someone would 'dnf install' this package, run > msed and then reboot to have it take effect? Basically, yes. There would be a few msed runs, once to set the passphrase, once to load the PBA image to the drive, and once to enable the shadow MBR. I envision making this easier eventually, perhaps with a GUI for presenting a list of drives that support OPAL and providing the ability to encrypt them and load a PBA image for unlocking at boot. The nice thing about SEDs is that you can "encrypt" them without reinstalling--you are basically just setting the passphrase for the master key that is always being used inside the drive for the always-on encryption. > > In my case, I've developed a tiny embedded Linux-based PBA image [1] > > using Buildroot [2] and the MSED software [3]. The final image is a > > MBR-partitioned disk image with VFAT filesystem containing the > > specially built Linux kernel (vmlinuz), initramfs (rootfs.gz), and the > > installed syslinux bootloader. > > > > Before you ask, I can't use even a stripped-down Fedora image for this > > purpose, because it must be TINY and it only exists to run a single > > command (linuxpba), then reboot. My image is 4MB and could be made > > even smaller. See the reasoning in [1] for why it must be so small. > > > > [1] https://github.com/cranderson/buildroot-linuxpba > > [2] http://buildroot.uclibc.org/ > > [3] http://www.r0m30.com/msed > > > > Now I know there are several challenges to using the Buildroot > > approach to building software for Fedora. Buildroot downloads > > software from the Internet, unpacks, patches, configures, and builds > > it. The build environment is built first, so gcc, uClibc, busybox, > > etc. and then the packages you want to include are built in that > > environment. > > > > What is the best approach I should use that is acceptable to Fedora? > > I'm not sure. :) > > > Would it be acceptable to bundle source packages, Buildroot itself, > > and my Buildroot configuration into one SRPM so everything is > > self-contained and can be built without requiring network > > connectivity? This means I would have to bundle the source code for > > gcc, the linux kernel, uClibc, busybox, etc. > > > > Or is there some way to pull in SRPM packages that already exist in > > Fedora, and use those as part of my build process so that I don't have > > to bundle all the source code? Additionally, I could made separate > > SRPM packages for Buildroot itself, any components needed (uClibc is > > already in the distro), the Buildroot build scripts for > > buildroot-linuxpba, and the actual package I need (msed). > > This sounds to me like something thats better suited to be composed and > shipped as some kind of image instead of being a package. Perhaps, but however it is delivered, it needs to be built somewhere by someone...and I don't think RelEng would be happy to have a build procedure that involved downloading sources from the Internet either... > I can see the appeal of a package however since it's so small. > > The build system will not let you download stuff from the net. > If we did builds would not be reproducable. Agreed. > You cannot use the existing gcc/busybox/etc to build the image? The msed "linuxpba" Linux userspace program is the one that prompts the user for the passphrase, does the unlocking, and reboots the system afterwards. It is written in C++ and links against ncurses. I haven't found a way to statically link the whole thing since it is written in C++, so it needs enough of a Linux userspace to be able to dynamically load libraries, access device nodes, etc. Everything else exists solely to boot up and run "linuxpba" in as tiny a way as possible. To keep things tiny, the kernel is built with most options turned off, and anything required is built-in (no modules)--including all SATA drivers. uClibc is used with a tweaked config file, again to keep things small. busybox is used as an "init" program and to launch "linuxpba"--most of the busybox options are turned off in the config. It might be possible to completely eliminate busybox as well, but I haven't figured that part out yet. The whole thing is built with a cross-compile toolchain. First the toolchain itself is built--the host g
Systemd Preset Policy
Hi, Let me see if I understand , on 2015-05-20 [1] FESCo has decided to merge some of the policy around service units, socket units and timer units into a single policy that treats all units that run as default the same way. Note: decision made 6 days before Fedora 22 Final Release. We got some new wiki pages [2] - How to enable a service by default ? Services are enabled or disabled by default through systemd preset files But before that I used a script to enable services like this: %post guest /bin/systemctl daemon-reload >/dev/null 2>&1 || : /bin/systemctl restart systemd-modules-load.service >/dev/null 2>&1 || : /bin/systemctl enable vboxservice.service >/dev/null 2>&1 || : /bin/systemctl restart vboxservice.service >/dev/null 2>&1 || : This kind of scriptlet still works on Fedora 22 (updated), on a new installation ? Other wiki page shows that PackagePresets are from Fedora 18 ! [3] And what is the best way to set a preset for a service ? that we want enable by default, when is installed . Note: I'm asking this because I don't saw any example on package guidelines. [1] https://fedorahosted.org/fpc/ticket/532 [2] https://fedoraproject.org/wiki/Packaging:DefaultServices#Locally_running_services [3] https://fedoraproject.org/wiki/Features/PackagePresets Thanks, -- Sérgio M. B. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Review swap
Hi, I need to push three node packages so I'm willing to swap reviews for these: nodejs-prismjs: https://bugzilla.redhat.com/show_bug.cgi?id=1246720 nodejs-flot: https://bugzilla.redhat.com/show_bug.cgi?id=1246721 nodejs-js-beautify: https://bugzilla.redhat.com/show_bug.cgi?id=1246724 Thanks, Eduardo -- http://about.me/mayorgatellez -- 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: Review swap
On Sat, Jul 25, 2015 at 11:46 AM, Eduardo Mayorga Téllez wrote: > Hi, > > I need to push three node packages so I'm willing to swap reviews for these: > > nodejs-prismjs: https://bugzilla.redhat.com/show_bug.cgi?id=1246720 Taken. Yours sincerely, Christopher Meng http://awk.io -- 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: Systemd Preset Policy
On Sat, Jul 25, 2015 at 04:10:28AM +0100, Sérgio Basto wrote: > Hi, > > Let me see if I understand , on 2015-05-20 [1] FESCo has decided to > merge some of the policy around service units, socket units and timer > units into a single policy that treats all units that run as default the > same way. > Note: decision made 6 days before Fedora 22 Final Release. That's not particularly relevant, becuase the old way of doing things still works, even though it is deprecated by the guidelines. > We got some new wiki pages [2] - How to enable a service by default ? > > Services are enabled or disabled by default through systemd preset files Yes. This centralizes the policy as to which services should be enabled by default. It also makes it very easy to create custom policy in a product / spin / local deployment / etc. > But before that I used a script to enable services like this: > > %post guest > /bin/systemctl daemon-reload >/dev/null 2>&1 || : > /bin/systemctl restart systemd-modules-load.service >/dev/null 2>&1 || : > /bin/systemctl enable vboxservice.service >/dev/null 2>&1 || : > /bin/systemctl restart vboxservice.service >/dev/null 2>&1 || : > > This kind of scriptlet still works on Fedora 22 (updated), on a new > installation ? Yes, that still works, but should be converted to the new way of doing things. So most likely you'd want to first file a bug against fedora-release (see below), and after it is resolved, modify your package to use %systemd_post. > Other wiki page shows that PackagePresets are from Fedora 18 ! [3] That is when this functionality was originally introduced. What changed now is that presets has become *the* official way to enable services by default. It is less convenient for packagers, but is more convenient for admins and products. > And what is the best way to set a preset for a service ? that we want > enable by default, when is installed . > Note: I'm asking this because I don't saw any example on package > guidelines. [2] shows the syntax in the spec file (common for all services), and [3] shows the additional steps which need to be taken for enabled-by-default services. [2] https://fedoraproject.org/wiki/Packaging:ScriptletSnippets#Systemd [3] https://fedoraproject.org/wiki/Packaging:DefaultServices#How_to_enable_a_service_by_default 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
