Re: vte in F20 stable is downgraded by yum distro-sync
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Tue, 2 Sep 2014 11:35:59 + (UTC) Andre Robatino robat...@fedoraproject.org wrote: I previously had vte-0.34.9-3.fc20 installed in F20 stable (installed on July 3, which is probably the push date) but a yum distro-sync downgraded it to vte-0.34.9-2.fc20, and the -3 version does not appear in Bodhi. What happened to it? you never got it from stable, I have the last almost 41,000 emails from bodhi actions, I get email whenever people add updates, sthey get pushed to stable etc there is zero emails for vte-0.34.9-3.fc20 it wasnt pushed out as an update. Dennis -BEGIN PGP SIGNATURE- Version: GnuPG v2 iQIcBAEBAgAGBQJUBa6NAAoJEH7ltONmPFDRRs0P/03zbQhxa2O29gSzFnG3RMe9 veY9WlvjIIApYFyvWTKdod9QRK6zR01dujacdbMRa3S6eeKFRUEudft6pCLzXMhP 8JfuURf4e1E0uiyeNVIUz2QJlngrZyFZIxm5OnSzXvo766nm05frXPKwWR+pbj9T UsEppDeqkREaCn9RNsYWc1jj3lftKstuW8FZeEhnEK8LJ3ra0ldB/Q5OVdrE5WE5 RVakzKPL1W2Rlq8T+JFA/1o0guHN/Z6P6vd86YldkTBgw6G4jn2I5hj8pTZoFrcG uDVLuqOiKf8HVNT9Sdb/EqtK7mxgV9Z0dFHnNx8k6ei8hHDV0JpEQxg2FRP8ypP4 5vXc+bI3otcaogd4lWwOmNp6hlnYnSZKhW2Dj/4OTeRdEmqI+M6OYGwXJzzPDStx YxIvPYPzXhLAyeDxIZXqtopwr68jSteSggwnlaKXpJ/9kdmAatqKNXPY8yAqgFyQ r8gWuCV7/3BsQwq51IX9pdJTWpjnzp3PtYHK/cE3+nT3KwtfHCIEx2fut/4Dvq1Z 5VzWRVvFL0E0jPLDiLHOY4kKhb6Y/5yWFuvS5hn/qpx563uZ9c3CASQUhTyv8R32 jQpOwhnj5qm6EeHHILwK4e726Ing5q0Nn+LeP6LI8JLeGRYH27tigHrKVijGmX3R 0APGjSvpLG1UFRJpuIP6 =ifjF -END PGP SIGNATURE- -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: Freeze Break request: ppcle dhcp/tftp handling
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Tue, 2 Sep 2014 10:40:20 -0600
Stephen John Smoogen smo...@gmail.com wrote:
The X needs a real ip address but otherwise the patch should work.
ack with what Smooge said
On 2 September 2014 10:30, Kevin Fenzi ke...@scrye.com wrote:
Greetings.
The ppc secondary arch folks would like to try and automate things a
bit more than they have now, so would like to try and get their kvm
guests pulling an ip from dhcp and then using tftp/grub2 to boot and
install.
This patch adds a test host to dhcp.conf on noc01.
Additionally, we will need to add boot/grub2/ contents...
I don't think there will be any disruption from this to anything
else.
+1s?
kevin
--
diff --git a/roles/dhcp_server/files/
dhcpd.conf.noc01.phx2.fedoraproject.org b/roles/dhcp_server/files/
dhcpd.conf.noc01.phx2.fedoraproject.org
index ad39fcd..dbf92f4 100644
---
a/roles/dhcp_server/files/dhcpd.conf.noc01.phx2.fedoraproject.org
+++
b/roles/dhcp_server/files/dhcpd.conf.noc01.phx2.fedoraproject.org
@@ -1766,6 +1766,13 @@ shared-network qa { next-server 10.5.126.41;
filename pxelinux.0; }
+
+ host ppc-le-builder7 {
+hardware ethernet 52:54:00:4e:c0:de;
+fixed-address 10.5.131.X;
+option host-name
ppc-le-builder7.qa.fedoraproject.org;
+filename boot/grub2/powerpc-ieee1275/core.elf;
+}
}
}
___
infrastructure mailing list
infrastructure@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/infrastructure
-BEGIN PGP SIGNATURE-
Version: GnuPG v2
iQIcBAEBAgAGBQJUBfTSAAoJEH7ltONmPFDRCwgP/iwe/0xNeskDpUy3kiV8saL3
OBeNd6+bsLOdaJeu5Urg05F6lV/9RywuNfGNXQOZioXK4luHPgchkbRxLepF6zFv
oY71gg1P/Eg2ASHWsJtFmCFq8/8yA1WT+O/S0Gu2ctipOJhkEXbEfB3AWIabbzti
wzzQY0aWRd0Qz5D88IqCRb96keC6TXtpvzSIgPHa/CsKyAdgKbSf7/L1saIqsDRK
bWBxXzybX4vQWqUF7u8WEHj1Erd/7uGgPOo9yrE3xoG1A5F7am1ftNsa/pKbOvbH
5iyngZ1GoUY4Xl0Lm9N6ago7tQOURS/aCrGFr5NF34vQIkBBDiiNtocLGSZLuzKj
6oqF2rUtmNMFVcW20ih7ElfBq+2CbpATA+ad9Zbkcjw/m/+3xFdYHVJlwuS5n6XV
zB79mD+W5ovndED1EbTqaRDKNwWqODYS0X3LSss5ODMcxWulpg4XHCWNEnKygl2U
/xv1GNcDIUCXt//RAXt3ccLpC6xQEUHq6XrYtWjV0YbThwk/gc6/bjNX8I6sQE58
N8nEs3GfGaKvrpZCc+HLrKzmQm1kxVMDHKWFoiCjAfl4axXpwqLlVn9te2fIRlYz
2GMhvAKWJpjD/d7TioLzP1qmZDoW0T+CQwm6bBYUF2B0yM4BkWVRH5LoIMREYT2g
DLek9FyDFzy2keqhMmcF
=++D/
-END PGP SIGNATURE-
___
infrastructure mailing list
infrastructure@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/infrastructure
Re: Freeze exception for adjusting fedorapeople.org and copr URLs to HTTPS
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Tue, 2 Sep 2014 10:26:56 -0600 Kevin Fenzi ke...@scrye.com wrote: +1 from me. I'd really like us to apply this when lots of folks are around so we can make sure and test everything it touches to make sure nothing was broken. kevin +1 from me also Dennis -BEGIN PGP SIGNATURE- Version: GnuPG v2 iQIcBAEBAgAGBQJUBfUYAAoJEH7ltONmPFDRWOAP/jwdLHQR/L9b+tvVNnrfC1H9 Sr+qLAIA6iOAvv2Qk5IxaD/NJAUaZ1J0Ttwtagtok9rpcme5h/7r1zX01WMQHjqy RwzYKdclHPLhPpJ04EF+NCoS7FyvQoC8COtgStpivkR5V0BZc8TDBVCn8GHKMNU7 Jyy3SzpCIqEECllkqlakAY3Sw5LfmBnmAh7aVGixzJzO248QybZ6Tl62ezUmLDpT z6w1Qu8X59Eq1pYUYBzAVTyfTqkJxRyVTRwHVjjsimLpVgtkWkzmBNCXEbnr3mdU k9z+JdR2wsdd3vrFVxlJF2DwyMg5cxU3nidgPSyf/0dMoOtRacdsREY8LQhEIvNI Hh4HizI6SKCDhLSoIRF/4a8Nly2h+VyBTdyQJSqlcLDT0KWmVfd2KyzVgSD5se+a 2CPDIxHS5PLUpINW26cU7YjhA92L2RXSf11l3ZXB6Oav/II0t+3ynmGLz7YYPtV9 Pw9I4hQUkQdrxbgH1P6+tFsLhq46vHr1LntWRLKg7VQ8s2KUBR8cpmXnvlgDMXWc tjg8/jfjoAxtrehI2YOwj+0fAyzfQX9OMG2WRFYIrwQv0b0vvMC4g60pckkn91mZ jLsznUwDmp+t88HHgwYWoHy2kehsEg/BmzHoiVGVZxVg8rr7F1XbbOhvs6jZZKa3 v2bd8+ZOs7OD0vXXQLGd =dn8J -END PGP SIGNATURE- ___ infrastructure mailing list infrastructure@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/infrastructure
Re: Freeze Break Request: Remove Old directories from lockbox01
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Tue, 2 Sep 2014 14:03:41 -0600 Stephen John Smoogen smo...@gmail.com wrote: We have a lot of old apprentice accounts with old data in it. Cleaning out these accounts would lower our disk usage and hopefully drop the number of 'we ran out of disk space' nagios alerts. Special break.. clean out a directory from skvidals account: ./skvidal/dns Accounts to be cleaned up 4140148 total 275348 blob 251532 anshprat 180872 arielb 179840 daredel 172580 nigelj 123184 spack 119688 gagomes 93248 jkeating 79556 glezos 74344 duffy 67748 nj0y 66304 jokajak 64996 wsterling 64512 fcami 64484 lfacchinelli 59968 janfrode 59372 poelstra 56404 codemaniac 55676 sts 55560 mosburn 55336 klainn 55152 rigeld2 54992 rdeys 49564 crothers 49276 jacibato 47972 kanarip 46928 jorn 43668 smillie 42008 charul 40096 boodle 38620 sheid 38364 jclark48 37668 oddshocks 37132 ctria 36412 katzj 34356 phuzion 32776 walt 32396 rhaen 32092 yingbull 31188 mahrud 30848 tgalyean 29188 akistler 29116 xeladem 28964 hiemanshu 28960 asuthar 28400 mangas 28320 wakko666 27192 kubo 26708 ingmar 26620 thesharp 26272 ggruener 25168 wtogami 23548 jmosco 23384 jchen 23144 zemmiph0bia 22612 johnstanton 22468 jsh 21916 ttech 21804 corgi 21560 swa 21488 frankly3d 20832 marcdeop 20828 miguelcnf 20552 asrob 20024 whiterhino 20008 informatux 19848 davidvz 17884 vglafirov 17648 kaos01 1840 sheap 1772 iambryan 1624 sumitrai 496 gmarchant 100 jcollie 84 axilleas 48 kushal124 48 joshkayse 44 zqw86713 44 danrimal 40 akshayb 36 wileywarren 36 mrwizer 36 flare183 32 wraeth 32 vrutkovs 32 vhumpa 32 tideline 32 tensov 32 tdk2fe 32 shubhmoy 32 rossdylan 32 rameshraithatha 32 rabisg 32 phobot 32 onuonga 32 nerdsville 32 mhaynes 32 mariocav 32 loic 32 kjs 32 kilted1 32 kc4zvw 32 jlaska 32 jam3s 32 housewifehacker 32 ghostalker 32 frankieonuonga 32 echevemaster 32 docent 32 dbhole 32 danstar 32 codegerbil 32 cmullead 32 bradbailey 32 bitlord 32 besser82 32 ayrx 32 ausmarton 32 amitksaha 28 vincentvdk 28 tchung 28 sudhirmenon 28 suchakra 28 sseago 28 slinabery 28 sgrubb 28 securegates 28 santosp 28 rfelsburg 28 red 28 pvangundy 28 pranithk 28 pmyers 28 pjp 28 p3ll0n 28 nokia 28 mspevack 28 mfurman 28 mchua 28 lutter 28 kklic 28 johe 28 jmoskovc 28 jdieter 28 jdarcy 28 jcwillia 28 jbass29503 28 jaysonr 28 jaxjax 28 imain 28 icole 28 hbrock 28 goozbach 28 efadeev 28 dunnderr 28 dcr226 28 cyberworm54 28 billchen 28 asgeirf 28 arjunroy 28 akishore 28 aeperezt 28 adrianhannah 24 vbenes 24 packday 24 methanigai 24 mattjones 24 lrsz 24 jlar 24 farara 24 brundlfly 24 bhumish 24 aharms 20 rkersten 20 nryoung 20 mmello 20 marcelk 20 func2nagios 20 freemanpd36 20 fortu 8 dsk4.out +1 -BEGIN PGP SIGNATURE- Version: GnuPG v2 iQIcBAEBAgAGBQJUBipyAAoJEH7ltONmPFDRsuoP/iQssKtHDHyFsYBF/cZ/2iyW lLt6l4wx3r7t2QYj9Ua/arWPZroUTNAYqn3LocHmvy3imJFSx7+O32W4xVI1/XW+ sg2tkyg4VEwCwgXA9ec6yKZI2XauFkGYzbxoPb1SSGW6Yvdgl5MgGa15iFhO/+DY +vXL/2YM6KjflLc8woeIPLvJZ6H5q3eqdkLLDJ+x1WXZKmrE17m7jzu2UheyF9P1 vN7V5H19vs3fS61d5rMhNavbUFCEZtAG1/SdowforIQwtj61QbeJlnWpDf0RE95M eskmyeb6h8bUa6aeoF0roQ17PlYnzWEywl1yNtGrZiKVQkHICarDbUEtKm2GYUOL /omO8x+Qou5g33r+D3b9rcFN5QKngJJTs4Mc6NtofHnxZQL0hVOgtrf3I9SIodZ1 J1rNPc9xY8bzVoObM7P2ehPBmtU1/SG2K1WU4dyHjc61bUsRimpIwHJeIlik1bAD 3RehRND5EbnY6GD3Wm3gE06ZB5melBYHbPSRgsV3J6BozRSAAFvvhvpRnWYrOdkX 27KPj4nsNpb6IXmt2XLZ7ldtEbHrIfFAewAVBLr7vP1Q8DrkhT5pFj22KUNYjkC8 hMR8y9CtqbFPEc3NRc59IVd0zZyITvfrQdq/VmjHAqVlah1ypVSJjG/2kJelY2Qt 4k/ey13eNk8KoUckq1IZ =p1W8 -END PGP SIGNATURE- ___ infrastructure mailing list infrastructure@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/infrastructure
Re: EPEL moving epel 7 out of beta
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Fri, 29 Aug 2014 07:53:06 +0200 Remi Collet fed...@famillecollet.com wrote: Le 28/08/2014 23:26, Dennis Gilmore a écrit : Hi All, Kevin and I working to move epel 7 out of beta, as of a few hours ago builds require bodhi updates to get pushed out. EPEL-7 is now on Bodhi. But trying to push an update for a freshly buld package: No package found on these branches: el7 Any idea ? Bodi has hard coded assumptions about epel and wasn't updated to deal with the changes we made for epel7 it will be fixed today. Dennis Remi. P.S.: Package: php-horde-Horde-Mime-2.4.5-1.el7 Tag: epel7-testing-candidate Status: complete ___ epel-devel mailing list epel-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/epel-devel -BEGIN PGP SIGNATURE- Version: GnuPG v2 iQIcBAEBAgAGBQJUAHCAAAoJEH7ltONmPFDRAJ0QANMyzMXn4ASbBw7gyGQevZam tZpBUc6Nb+3tIj32cBWaC5GOOuVMeheLMWcnukCYBa63a38Z0uBk58lYfzEWh8s0 GHiKpjjp5uQSB6k8ksVQ7SFdPkAP4m9Iqg/5/CEFoj+eVFpD0EmFIVH646Zf4CmJ u61eY1YnCKqNkaCalQro+sNTnzxli0hwfKruTIEssOqqkLHAbH+puYWB2MPXQmUw IHh9qESQnzcB+KgOHnjy6J6LeXu1Jv3uDmwZ+no7tkA3n43ECIAFlgH8OMmdH3Id +WV/JQWk/LfIV7YuC5RcevYwZSbL8YKhT8Oy8DMaD81LbrLbgvnigVHlhzRq/Lk+ xZYheoz5tn5m5U0BosvoNY26HJ/KV0hBdYyk8SrISr/D9JnyX+dC6keQ23Mh/ecP ZQejcaQZH6jnmMWeTwAOcVCWFqcX9BRLYL8dhApg8icAc8arGHQYtGoUipVytDIi am7u+M4VfQBAAtsmpe+bbGaCPih5B9gjY6RK11ClIIObMjKn41gropmKbdNWPv+O sGjBXw9TpBzvnx2rkRLMzFUOKVrE3y4L0UHhk5scIEAYfpkZNUD0/KI9MpmLGqGS yzNpjLd3BGYD/pV54ewQj/NCvv+kVZ6iAzhYjqTXtEY8QJTVeVb/HcFLvsSI6GQE uG0AbZ5TPuDR1gRGBeu+ =ju0W -END PGP SIGNATURE- ___ epel-devel mailing list epel-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/epel-devel
Re: Bodhi freeze break
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Fri, 29 Aug 2014 11:15:08 -0600
Kevin Fenzi ke...@scrye.com wrote:
On Fri, 29 Aug 2014 11:09:43 -0600
Luke Macken lmac...@redhat.com wrote:
I submitted a pull request to bodhi to get things working with the
new EPEL7 tagging schema. I'd like to spin up a new release and get
it deployed today to enable EPEL7 updates.
https://github.com/fedora-infra/bodhi/pull/87
There are plenty of places in the code that bodhi has to see if it's
dealing with EPEL, and handle things a little differently.
Previously, it would only look to see if the
Release.name.startswith('EL'), and this patch changes it to look
for just 'E'. This is an ugly hack to an existing ugly hack, but it
is already resolved in the current bodhi2 codebase, so I'm cool
with it.
+1
This would go on bodhi01/02 and releng04/relepel01?
kevin
+1 from me also
Dennis
-BEGIN PGP SIGNATURE-
Version: GnuPG v2
iQIcBAEBAgAGBQJUALehAAoJEH7ltONmPFDRZZ4P/RFyWDj5jPSunST+v9TJh4GC
rLptbmlL89FdQGB8Z7jJo+mtDbAuf7ph/OTV80MYhOyVBSDM7Cs/wI8p4SDmRmyB
QzJDpc5053lsTwDqs4ixKpkcusGrqHNsQq8rVnplvThSl8yGfLJ/QXjidOjlSM1s
oLEihnFeEbG6iqNHVeAi9tVUtTFs2rP8HkXqdhgG4jQqOV8/B9DqumUJylQ29wC8
AVKB3UBfsCA2Ze2cDM+dv0UdM+TnDoDs/tWtPhCTc5IS6x/Y3HPE18RRjEp4taBh
/JBpCwYwh3G2sTvHfv0Bm+iqus0JfIcHtSpbGUjALfoPoJOibWcWnKyTajRRlknd
Ij4aqaZUK9+taaviq17P5I3UrOQ33Cpk8V/uu9h2mMqp9hHR+S56XOr/yasj836r
9ANu6CvSCKclsHv2mH6hKIMSKi2CWnrbonDIAKxsR3qposNP6/Bn+arIeBnX8uPP
8HYVw+2NnKL+IFalfINoszkHcUXzRHEdeUUYHsYxQac/KwuQ3FXy2lbX067feupW
9lAOq4GSl62jBwU12ZkTHMzrgiJ4mdcwQrtnFXLDt+cj/dAlAlZNftyRCILOQQh8
zV9eohguCnqbFnMpUDGqmvtdp+tW3Kp1XnUNqKF6gz3ga680O4uMeor9YRjk7PIB
QL993WhXxTCBoH7eUWSx
=9j/2
-END PGP SIGNATURE-
___
infrastructure mailing list
infrastructure@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/infrastructure
EPEL moving epel 7 out of beta
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi All, Kevin and I working to move epel 7 out of beta, as of a few hours ago builds require bodhi updates to get pushed out. you can now me sure that all packages are signed. we are cleaning up the broken deps in the repo and moving everything that has broken deps to epel7-testing-candidate and they will need to have updates created, making sure to deal with the broken deps. Additionaly this means that the wiki can no longer be used for branch requests. that all needs to be done via bugzilla now. Thanks Dennis -BEGIN PGP SIGNATURE- Version: GnuPG v2 iQIcBAEBAgAGBQJT/56XAAoJEH7ltONmPFDR+V0P/17ta0bHqchHR6rtr50t1/9z ZMBSO94HmjhHRdcS9jn1KvCXvct9T3sXFGHG5M18BT1ZF3qIB/edroEK3nfV9PEZ vghEZZXOW1GO5w1cvaV2Y8h9l1vb3NdLHx73luzhnxol1AeTngh+1a4F6ZbDaEWx 1VcXEbLsa6l8N640ugvGJQIhP7kmXRD1Z+lyXcE1PL7GWHti2Fb8fDtnbpEzEEIv pcbv7R667g27qpmnpZ9EGjNRgwFpaWKMnjITdr6HtwwnsG1AdKifP2TfpDyRTznn Z9IMJNCd9e91Ost5TgsuklFrvuIc+Ye3m+BqQYMpkH2LmRCALQNvw8Ck3eq3zeIE aOn0Q6iC1FraIHq0nON4gWomUG8d+K9eD+pU7BXTR+BkyWZns1b1YNGsGseTdR6x NcqCargDqul/D4NY7GuAX/9SJGMHKc+f42XlzwtcTZXs3ZAclv78DsnS8EKAomWD 4wJ8j6BkUXUZcIgSmA4nUCvoOmrJbz1K5k4AET9rJndVxoP1ZFhbIt2O6HlHHQuZ WC5eNXJxEWLx6JdZ9SBBd3czNRpo7B6lRJ+2qXgOV0SUqptKyLKbdKEzlQkGJGkF 83VFyyCzeQJG0O/FD+DKWDiLs+lyEoiPpiJgHfBjwx+AEoduzYUCWP7/K0Sf3HYz 4FqlVxE1cxt4NMjPxUxA =I5Dp -END PGP SIGNATURE- ___ epel-devel mailing list epel-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/epel-devel
Re: Pkgdb2 hotfix freeze break
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Thu, 28 Aug 2014 15:42:36 +0200 Pierre-Yves Chibon pin...@pingoured.fr wrote: Good morning everyone, I just manually hotfix pkgdb2 for this fix: https://github.com/fedora-infra/pkgdb2/commit/e5ca8bcb2a1b8fed2a68c50ed959f3ed0a654dd1 The idea is to keep allowing people who have the proper ACLs to commit on Orphaned packages (so that they can fix things). The bug was introduced in pkgdb (manually as well) by me yesterday morning before we went into freeze. Could I please have two +1 in retro? +1 it is causing issues Dennis -BEGIN PGP SIGNATURE- Version: GnuPG v2 iQIcBAEBAgAGBQJT/zKfAAoJEH7ltONmPFDRRCIP/2LXcK786DSuMvgYQGnnLiAn l67i9NIjAD3bv2JAT03853KJZPiTz395aoUYXeYHTgec1tfeooTUl7riyCfiQqK+ y3xj/Iw0MCxGVtx23b2e8yRXYcIYSnTRLo8a0pWaQn1bOr9d4lh3NvuTSQP6NWOB JnKjJdufm7ebbkchhdsZ0GRPzEDnef+WVT4UNc8yIQRGFBnSwa34qBNFRuL0yecE tA0DmZhhlS7IPpoH8m/MSrJu7gYwDG3mBvAsUwwNEQuf5TRIpcg34IsuzFJdOh3y CGa03H4VrTiNkfHyIKa7FLyuMRMWCO+LOUt470lVYld9vcAIRLY6LJPZ4CIQLv9o t3C60CP9tbjrwk8w5FIzYA6R2i06Rzp9mGY1lBlXrzK0MWCPajrkF3Ai2eksqxEv 65G49g5gerBRe9VYjw7B11FWI1E5/BHg+FxaDE1szZT26POg4bXWDCp1n4rmL0zT IMIcvMnVPiYzTHcrdEjmjPtOCY589opOnUgfDZ/0pxRe3NDIpBXcdBrySGht+Xm2 8N0XCTqDc48sltPLSubYyu4IMPtmFV3pd+K1F0xV1Mz9WAxACLCLGOTYyAjCcdEJ A0Mg8hog7oGWVrdJO5Qe80yRq7ztZ0rmaLJJbHlYwQKlhVJpiL38EXvId+C8glgj DmxFpwnpTmylLDs6HNLh =vmnd -END PGP SIGNATURE- ___ infrastructure mailing list infrastructure@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/infrastructure
Re: F21 Alpha Change Freeze
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Tue, 26 Aug 2014 10:47:02 -0500 Dennis Gilmore den...@ausil.us wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi all, As the Fedora 21 schedule[1] states the Alpha change freeze is upon us and we have a confidence in delivering RC composes. As we are now at the change freeze bodhi will be enabled for f21 tomorrow morning US Time. It means all builds will now need an update created and as we are at Alpha freeze only accepted exceptions[2] will be allowed in. we are at the pre beta stage of release, so the Pre-beta[3] stage of the updates policy applies Bodhi has now been enabled, you need to create updates for f21 builds and only FreezeException and blocker bugs fixes will be allowed into stable until Alpha is ready. additionally you now need to create buildroot overrides if you need to build against something new. Dennis -BEGIN PGP SIGNATURE- Version: GnuPG v2 iQIcBAEBAgAGBQJT/jhfAAoJEH7ltONmPFDRXfkQAIzWjMqnQLpTBhSC7kiXK36T Nf3pfF28Gfz0Ov6kGqIDcAurkoytXOMbFSRSNw6BayzsZrtlfF2ayYXpsKykhZ3E RPEjSFR2n+hH0NXR09X5ya40k1XTUKeLh+wo2W1WDKVGUIEFo8EsYBmAEQNGULCL SgivI9GpRlyFcQpKm90fiIlJhBNFTwuLj41fu15oaDa9NOxZ9o5jv8cXqURCb84n h2nV1O29CzTzcA4dNFXCAzaJZFgHWnFlx3J6v0oIeb8UZ+5xrV6Kc3cnx/a85Tzm fEk+nvvNaOgS0PwC0nSzkGDd92uEjRlrqWxQptBD+zCul+PJHm1sZ2WHuiCAeyAR MAhbGngoGlMc96gx4T1+ixu/3ws6yiOWABsPPElPuxdue7JYTd32IyQXkJl0gYRU 8+iUy3Sc9coYtqP1rR26WJFx2JEYkfbKk6lOTYa3NoU0KAnjE38IWhlfc6RQmp+k oAPutTyUUQ5VatfglSkFpGt8qy+xUSPsNMCfsKSQBHTKNQOmQAeBSulaWtj7aSkL f2ldSyVCGpyYrLi42uH2NJ4vtkIYQYdozWj/NTXjw6UoggvPlvz1QCJ4rjt37J1V 5U/w50AwKm3xBBvRazfugDPXLlZtVdWfRkffV1Gmiu81Z3U1ImIHlweYiqZ5/rkq UJSfJ9crJhsSk5auvz09 =1Ajy -END PGP SIGNATURE- ___ devel-announce mailing list devel-annou...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel-announce -- 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: F21 Alpha Change Freeze
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Tue, 26 Aug 2014 10:47:02 -0500 Dennis Gilmore den...@ausil.us wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi all, As the Fedora 21 schedule[1] states the Alpha change freeze is upon us and we have a confidence in delivering RC composes. As we are now at the change freeze bodhi will be enabled for f21 tomorrow morning US Time. It means all builds will now need an update created and as we are at Alpha freeze only accepted exceptions[2] will be allowed in. we are at the pre beta stage of release, so the Pre-beta[3] stage of the updates policy applies Bodhi has now been enabled, you need to create updates for f21 builds and only FreezeException and blocker bugs fixes will be allowed into stable until Alpha is ready. additionally you now need to create buildroot overrides if you need to build against something new. Dennis -BEGIN PGP SIGNATURE- Version: GnuPG v2 iQIcBAEBAgAGBQJT/jhfAAoJEH7ltONmPFDRXfkQAIzWjMqnQLpTBhSC7kiXK36T Nf3pfF28Gfz0Ov6kGqIDcAurkoytXOMbFSRSNw6BayzsZrtlfF2ayYXpsKykhZ3E RPEjSFR2n+hH0NXR09X5ya40k1XTUKeLh+wo2W1WDKVGUIEFo8EsYBmAEQNGULCL SgivI9GpRlyFcQpKm90fiIlJhBNFTwuLj41fu15oaDa9NOxZ9o5jv8cXqURCb84n h2nV1O29CzTzcA4dNFXCAzaJZFgHWnFlx3J6v0oIeb8UZ+5xrV6Kc3cnx/a85Tzm fEk+nvvNaOgS0PwC0nSzkGDd92uEjRlrqWxQptBD+zCul+PJHm1sZ2WHuiCAeyAR MAhbGngoGlMc96gx4T1+ixu/3ws6yiOWABsPPElPuxdue7JYTd32IyQXkJl0gYRU 8+iUy3Sc9coYtqP1rR26WJFx2JEYkfbKk6lOTYa3NoU0KAnjE38IWhlfc6RQmp+k oAPutTyUUQ5VatfglSkFpGt8qy+xUSPsNMCfsKSQBHTKNQOmQAeBSulaWtj7aSkL f2ldSyVCGpyYrLi42uH2NJ4vtkIYQYdozWj/NTXjw6UoggvPlvz1QCJ4rjt37J1V 5U/w50AwKm3xBBvRazfugDPXLlZtVdWfRkffV1Gmiu81Z3U1ImIHlweYiqZ5/rkq UJSfJ9crJhsSk5auvz09 =1Ajy -END PGP SIGNATURE- ___ devel-announce mailing list devel-announce@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel-announce
F21 Alpha Change Freeze
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi all, As the Fedora 21 schedule[1] states the Alpha change freeze is upon us and we have a confidence in delivering RC composes. As we are now at the change freeze bodhi will be enabled for f21 tomorrow morning US Time. It means all builds will now need an update created and as we are at Alpha freeze only accepted exceptions[2] will be allowed in. we are at the pre beta stage of release, so the Pre-beta[3] stage of the updates policy applies Regards Dennis [1] http://fedorapeople.org/groups/schedule/f-21/f-21-devel-tasks.html [2] http://fedoraproject.org/wiki/QA:SOP_freeze_exception_bug_process [3] http://fedoraproject.org/wiki/Updates_Policy#Pre_Beta -BEGIN PGP SIGNATURE- Version: GnuPG v2 iQIcBAEBAgAGBQJT/Kv6AAoJEH7ltONmPFDRV+YP/1qqQPUqqiC1S5q6Qrj+Uh/E WZuj1wdEpttYi5tQ0oWn9mcjUL9ZZrb8oqeIxunDM175TRYLKKJ4+wL65gOCH7l/ t4zJjmfCyogWxMLRghw5XK+udgUum7fcs78Cuc/8kG1SYwDLFHwprCIUED7eo9eB oIT9m/hqrp1ZgGfVcDGARIcN9k8yzQUYucvgSrPCyZGEdaXmnGLP/JOz21pInbKO jCX+Fy9eveIv/DidxTXRUtIQLt/zH1AKUZ/c81TSm0tp6YoEYfOXfs4IMDm7TYL0 lObHJyaYDpFuEzWcyTvCs5AYjLfLYzwwFZ8GS6iRXdBwfaAPTBduTOIId2zZq4Zd vVYXfiACTEa0GrElT5CJ6ip3wz1h3rwaL4lbvpkYOmOO4FDGIX9K1nMOqYBfqffD O/n3EiAoZNJDICgdnJ655LM9ZdVdFnn1tmPbO8wB8ldcmrW4ANK0yWEQz/7EYqn5 PD4NXLdez5CJEH4klkPwGOwVl6JuvgiSqHcnLx/r+CdzOEUjx1usgWPIpf65ZJ18 +KnQHbJgQ27t3IDCQzCNWlq2d2xAy0l4QbYOGnAHSlUvfPW+DfBsxITTiwBvc54L WoLpg+slhe9nvOhlsMEJ13LC9ooREytevUjXcoQCB9kXFcgdP03rlEpWe+2wBPx7 L7yebc6vHouKWxQrs/n5 =XD30 -END PGP SIGNATURE- ___ devel-announce mailing list devel-annou...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel-announce -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
F21 Alpha Change Freeze
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi all, As the Fedora 21 schedule[1] states the Alpha change freeze is upon us and we have a confidence in delivering RC composes. As we are now at the change freeze bodhi will be enabled for f21 tomorrow morning US Time. It means all builds will now need an update created and as we are at Alpha freeze only accepted exceptions[2] will be allowed in. we are at the pre beta stage of release, so the Pre-beta[3] stage of the updates policy applies Regards Dennis [1] http://fedorapeople.org/groups/schedule/f-21/f-21-devel-tasks.html [2] http://fedoraproject.org/wiki/QA:SOP_freeze_exception_bug_process [3] http://fedoraproject.org/wiki/Updates_Policy#Pre_Beta -BEGIN PGP SIGNATURE- Version: GnuPG v2 iQIcBAEBAgAGBQJT/Kv6AAoJEH7ltONmPFDRV+YP/1qqQPUqqiC1S5q6Qrj+Uh/E WZuj1wdEpttYi5tQ0oWn9mcjUL9ZZrb8oqeIxunDM175TRYLKKJ4+wL65gOCH7l/ t4zJjmfCyogWxMLRghw5XK+udgUum7fcs78Cuc/8kG1SYwDLFHwprCIUED7eo9eB oIT9m/hqrp1ZgGfVcDGARIcN9k8yzQUYucvgSrPCyZGEdaXmnGLP/JOz21pInbKO jCX+Fy9eveIv/DidxTXRUtIQLt/zH1AKUZ/c81TSm0tp6YoEYfOXfs4IMDm7TYL0 lObHJyaYDpFuEzWcyTvCs5AYjLfLYzwwFZ8GS6iRXdBwfaAPTBduTOIId2zZq4Zd vVYXfiACTEa0GrElT5CJ6ip3wz1h3rwaL4lbvpkYOmOO4FDGIX9K1nMOqYBfqffD O/n3EiAoZNJDICgdnJ655LM9ZdVdFnn1tmPbO8wB8ldcmrW4ANK0yWEQz/7EYqn5 PD4NXLdez5CJEH4klkPwGOwVl6JuvgiSqHcnLx/r+CdzOEUjx1usgWPIpf65ZJ18 +KnQHbJgQ27t3IDCQzCNWlq2d2xAy0l4QbYOGnAHSlUvfPW+DfBsxITTiwBvc54L WoLpg+slhe9nvOhlsMEJ13LC9ooREytevUjXcoQCB9kXFcgdP03rlEpWe+2wBPx7 L7yebc6vHouKWxQrs/n5 =XD30 -END PGP SIGNATURE- ___ devel-announce mailing list devel-announce@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel-announce
Re: How quickly should we retire orphaned packages?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Thu, 21 Aug 2014 11:02:23 -0400 (EDT) Miloslav Trmač m...@redhat.com wrote: Hello, - Original Message - As requested on this ticket, I'm opening this up for discussion. https://fedorahosted.org/fesco/ticket/1332 snip (a) The reason for wanting packages to be retired so quickly has not been made clear by rel-eng. My reading of the ticket gives two reasons: * Make the act of orphaning and the impact of removing a package more connected to each other, allowing the reasons for orphaning the package to be considered in the decision to retire or revive it. (Retiring in smaller batches would help this as well.) * Make broken dependencies caused by retiring a package more immediately visible after the orphaning, to avoid once-per-release “time bombs” and the scramble to suddenly find maintainers. That our processes allows for such “time bombs” seems, to me, an inherently bad thing that we should be fixing. Note that we can not remove anything the shipped in the GA tree of a release. that content is static forever. so while we can remove updates we can not remove a package completely, but removing from rawhide is very doable (b) The biggest reason for people to use one distro over another is based on number of packages available to be installed. By retiring packages more quickly we inevitably reduce this number thereby making Fedora less popular. We wouldn’t remove packages from released branches, and the cumulative impact of the regular retirement cycles on rawhide would AFAICT be exactly the same as the current one big retirement cycle. (c) An orphaned package is not necessarily a risk (security has been mentioned here ...). We don’t want to gain a reputation of shipping packages that “are not necessarily a risk but each user is required to verify this for themselves”. Also, risk or not, an orphaned package is frequently a _burden_ on whoever has to fix it up after failed rebuilds of the package, or API breakage by its dependencies. (d) 4 weeks is too short. Some people go on holiday for this long. That can obviously be tweaked. Mirek -BEGIN PGP SIGNATURE- Version: GnuPG v2 iQIcBAEBAgAGBQJT90pmAAoJEH7ltONmPFDR3dUP/RReCsssCzLrQ0faS6H0Z25G 9vpZ+AuRbxu9r3v2rIUbqPG7SqD/iuaxrUnCj0M4GLlu4YODR4hBfFqjoZbRohFu lMzC4jMDWhUMtrs2rvkKWJ+prUl4Nfqah/E4cZd0EslwubTvCsBt4vkY7nGvBJVI bd9m6kjH7LTfTtothF9jbLWKGXkfWWYJAgmHHi6jqcT8L1AxfT9e7TMhG7CNtBvN Ro4PT8SsYCqkC5ZanS0G6IYj21ZCJrndnzsH/+Kqjm46VV/2uIOqfQSsqKsDRJ/d iM1Ecn4MbsAovmsV4ljdoYYWlHUHqqlau2UQfFYB188lfLqRY8VjDpEdYYJ1XLhS 9RkG+1+MbQ/MRJRBa3XZRZsFmlHi4VohiktrWJSxrwgi/ZI/Pi6TMEYdUeP7hdEn bTA6iraF6YyMP7tcrYo0rvIKL6zZ28fTYMCtvt76u77crNC0TVKD9Z2OBrcK2Z14 5YLr6LGhrNpzJNPeRgqpon8a7EztvCFd3A6F/9g+SP0nIVLD9AvansWq+np6QKbS QLN7MrB143m07FdHwS/n8r/4pfh2Mm6slR/7cBBfF79eekaXOsvQB0HGevHGeXUu RWAuJKJHD52LaSUFAIPzI4ArDBHhoTFbBpwzyz2v3cg6RCzkaWyKkC1LSJjrOCLo 8gt8P6xOxiJH2SgPKJ0S =k5Fh -END PGP SIGNATURE- -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: [PATCH] Added option for setting release note files
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Thu, 31 Jul 2014 08:44:01 -0500 Pat Riehecky riehe...@fnal.gov wrote: The attached patch has been working well in the development of Scientific Linux 7. Since the attached patch allows for overriding a hard coded value, I'm hopeful that it will be considered for upstream inclusion. Pat Sorry for the delay, I have pushed the patch upstream. Thanks Dennis -BEGIN PGP SIGNATURE- Version: GnuPG v2 iQIcBAEBAgAGBQJT950WAAoJEH7ltONmPFDR3v8P/0z1xB4OBqmjR0RNM+exzE/P 9VDGTLQ6YYImiGphK8aBFRJWa1C3M5uC7MOUaN6/YWBu5JEX+mG+QcyNbCzeYqce ucHqi3MdYFMAzP+f/gZ8z67gL1aqFgofK2sIQZjq797uo4MG5stjYFT/uHpXHuWn GklNRD3oR6dcXJaZExUO57rIpf0AvyoJsSjdiw1RjQdzuBcj0jjAo6Z3H3OC+c1T PIGbLeA4NDksHP7gBZR5JU486qoWkm1Nou1wtSGJi2N6HED3VVveFfTCMSIuMI/w YIZuyGyRp7GlyeLG6foaXJGe/l0g54uIcewFN2QGPK9ANnDSR1ONn8Gp7LHukUaV 3GxKmq0d7UlDBq9te6FOqKZzO+bEr4CyHXotuy01ew3p2K5a6Cl/YFoNi4ZADU3D QdaVWJX9XjIKbfkOnGEiD6WO4H0LKJHgMgUSS1tzLA1YS4///hVzhGx8HehsLdw7 MFI7M5hJHtXYNw+l0DtFkd7mj4viMWs8VqJx251kFwoc8WiOxitWw84j/7gAiu9h 8P2W1ZXKGRi+d3s77KXyQtROqU33AmZ0fJeTP+xZ0K0Y2dyzO9StNd/8UCfNftX2 Y0Tov7uStc0SRQtpuK/PpRlaVv7YbNOkB5s8FUOBfWxWRRI+czDA5AW+3y/OYe6g /+0K6r8dbQH9acnZZZYV =pJzo -END PGP SIGNATURE- -- buildsys mailing list buildsys@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/buildsys
Re: [mock PATCH 1/5] configs: s390x is legal host arch for s390
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Fri, 22 Aug 2014 14:37:58 -0500 Dennis Gilmore den...@ausil.us wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Wed, 30 Jul 2014 14:30:01 +0200 Dan Horák d...@danny.cz wrote: I have applied patches 1-4 there is alread a ppc64le config file in the repo Patch 5 didn't apply as I had started to make a config, i cleaned it up and have applied patch 5 also. Dennis -BEGIN PGP SIGNATURE- Version: GnuPG v2 iQIcBAEBAgAGBQJT957/AAoJEH7ltONmPFDROp0P/1K59ADpJ1ar+tH1X1YFjuoV /kSQWT73VTwqTiR6nEHjJBuJTBCCGGZifQsJl2u2g30DojMD1tZI1YI2E3KpM5R7 FWptmDkPhiiTHmDScOetKodmYq4UKOnC73OZdm6X/4sy8s7ccOiFpSimfi7YnvTe D8VyEZ/xSWfVQhp217gOLH2jZJ5eBUz2z+ZGg9sIwQGle+4p/ZbHA1Tjk5wc8eDT 87EcPKGH5INBrhmdFIkdqdP3lGk17KxWRZfuOOLSHS5pwludj0Xmwjwy8T1Nf8ua ygrcMKJ1k/J0B9GzrZX2VFKPYIPpKKBq5g9MeaP+g09VAcOMrOpv/Nh7kMLUfxgp JgSAuXslZ9xKzgoINS73ivPkvrLXfuEgp9xC1qCzCA9uZxLCzOfHvFA/YTRsyN75 vG6mr4mMqTGMAsQap3SB+Oeg4nUvVYy9QP6qrPz6Lw796BO+/30KjlqPqFj80WvK jr7ZwxZKcvFxtGUFrlANKstHYn0gq6ypWLR/z8g+0ccoHtz8XICrQVvdaLD/CJ4Y V9fcE/QoFI2jfNOU6bjjdnLCBrwBeZiKDBF00/OCr/oYIBhsVGJO1x/RFp/u/JTy a97Jw3ckz9D5t/XN8DtHYos2nZPcgvNuyXuHiB5fT6v3+nPrXahR4UHySUJgqcKX d0i74+H26iCvytF1J4q3 =9+wZ -END PGP SIGNATURE- -- buildsys mailing list buildsys@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/buildsys
Re: Special mass rebuild
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Thu, 21 Aug 2014 20:46:05 -0700 Dave Johansen davejohan...@gmail.com wrote: http://koji.fedoraproject.org/koji/taskinfo?taskID=7370474 There was a failure building odb during the rebuild. A later rebuild worked, but is this something I should worry about or file a report against? Thanks, Dave If you have fixed it then it should be fine. if its repeatable then you should look into whats broken and file bugs as appropriate Dennis On Thu, Aug 14, 2014 at 9:47 AM, Dennis Gilmore den...@ausil.us wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi All, It was requested in https://fedorahosted.org/rel-eng/ticket/5962 that we do a mass rebuild for Fedora 21 and 22 of all archful packages This is due to an ABI issue on s390/x and some gcc issues. we will start the mass rebuild on 2014-08-14. This is a heads up that it will be done in side tags and moved over when completed. We will be running scripts to output failure stats. please be sure to let releng know if you see any bugs in the reporting. Dennis -BEGIN PGP SIGNATURE- Version: GnuPG v2 iQIcBAEBAgAGBQJT7OhEAAoJEH7ltONmPFDRFoIP/3FU2oUlk1wKedi3cXoFPV1k bVbFqaeGLrCFoBXZpaag+Zm8gVrojAWNyXgVzzoLlsLhO+m25lkLsvEVnnCPojxG Ze/D0Lx4hZ1mMQ+PExSXDv9IDrYyjerCcdEaRNxvhOJ3TMw9JyH5MbSlZ5Rm1qPp EwBNKq/phT9POWrHCLI8efTerKJHYhIyAzxwJzektA3OMKLal90GBojWpy3lA5wF XP0Y2DGUDSoIqZcwKtzs1LNQazCy0JINGKm8jjtLG1FgLk0nqvNnC8uTr9nFFhkI J32C2PVq69gPaun1mnq8LNjVCqBwtR7jgqLcvhZzvb5do/i0EVDS0F+176e4eRQC iJJKoGa6sri14VENUQVOfBWqQgj+qKdBGH/NhE3qS6KR4UvpZNNIykVEONfiPCwT lBMtyVYgqnj/7E+MJD0Behe6BSxHPJNTWDi+zHOQBaMAugaXCQaQLizVydZ76hjK 5TJYLInJJ4fl8J5hvVpJTDNOisvTFFHZUtLZUQT79L2xjhc8+oaX0zYQ3cViaYsB wJmz73BdMsdEwKmhBVpTpXeZL4do6XxyACw/uabU3nZ74J58Lj/PFcW26ulTm7m2 Tk3z7zFjR0M0PZIFzzEiDJlaVHFvyxwabjMveRk5v5mgx3Jq6huJhERnZRhpDv5F bWwZzUlfNCYRNL6ZPn3P =tfVC -END PGP SIGNATURE- ___ devel-announce mailing list devel-annou...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel-announce -BEGIN PGP SIGNATURE- Version: GnuPG v2 iQIcBAEBAgAGBQJT9s2tAAoJEH7ltONmPFDR4mQQALcwDhlyY/u7oQSyUlk/Fzbl 3Xmj2mjPFcWplnyWW6pQGGuY7paOo9F+VqEz6hLHi5xF6Pvq5jJyvR1kNYqiDBT6 7j8VVfcyIzRthJ+rGLQ7iAT38vzmOjpSxWP+yvYKNyAJFSOKnsZVWBp3+bZ7V9t/ a7eLaXeWpErmip6vTfnHJ8qtEFQt+QABcSKuwGzHHc/QEuCXVNyK0jsQgVVDVyNV FjvsslrrRheVd3nhgo3aiEVvL+LJTnI6Czku+8QfU2ebEFyavGmjaAezoqrmXCo+ jMzyBsZ/Y6CrjzCC/w5hab9PBOpAwADoCtx7+M5GcpiTAgl1FKEDB3YKxvtQOx0e zbOtlglndvFOA9cg3ADO60Qhya2QHsNOhaSJBdiZojnfyeeMBVqqQCpFgg8FGbVY h82waVTz6iQ2HXVeg20KLXEvP7STq6omhMGVUp1KAbh4iqgQ0LusO4pMtmkAWYL1 /in4W4lZ5I86cH3dk4Dp/ru3AY+Gls6K7c1+Jao9lkITyOsWEIn9MMZMT4R7PkmI BvD0t0BmsCJrVvWLl7AqvMz3dyGwb1Pk3Z3V6L4W2I7zY1Cqihzlt9gHuSwolYG2 pRF9lvj2JWFbMRPPfy+GTncOhviMmJ6qBx2kPrHtc6UbgRQXBThucDMWuw8kOj46 hN9vlKMWdu3vfmB49kkF =drqF -END PGP SIGNATURE- -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Creds needed for Rackspace, GCE, and HP cloud image uploading, etc.
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Mon, 18 Aug 2014 19:35:47 -0400 (EDT) Joe Brockmeier j...@redhat.com wrote: - Original Message - From: Dennis Gilmore den...@ausil.us To: David Gay d...@redhat.com Cc: Fedora Infrastructure infrastructure@lists.fedoraproject.org, Joe Brockmeier j...@redhat.com, Ian McLeod imcl...@redhat.com, Paul Frields pfrie...@redhat.com Sent: Friday, August 15, 2014 8:39:45 PM Subject: Re: Creds needed for Rackspace, GCE, and HP cloud image uploading, etc. -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Fri, 15 Aug 2014 17:12:23 -0400 (EDT) David Gay d...@redhat.com wrote: Hi, As per our cloud meeting today, here are the credentials I need in order to work with Rackspace, GCE, and HP, as far as I know: Rackspace: user, API key GCE: email, key, and project ID HP: user, password, tenant name The above accounts do not exist and will not until we have agreements in place with the providers. What type of agreement do we need, and is one in the works currently for GCE? We need Red Hat legal to be okay with the legal agreements, afaik only HP is underway If we just need hosting/etc. that's easy. What, specifically, are we looking for? I also need credentials for our internal Openstack, which is my first priority. Kevin should be able to set you up here If anyone knows of other services that we use along with these (excepting EC2, which is already done), please let me know. as i understand it thats what we have for now. In the case that a service does not provide a good way to programmatically register images so that they are available to others, we'll have to work that out, as well. -BEGIN PGP SIGNATURE- Version: GnuPG v2 iQIcBAEBAgAGBQJT7rZmAAoJEH7ltONmPFDR/XMQALNmHLaOzzpqsN27b1/dQlwl pArKas5BYUL2Sff3Jd0Iq2RlzAiVGC2gauxq6ygZsQWJNMQDqU40of9cx0vIwhvu BTCg5eueeZgr5QK7XJ0Kr1Q5QJp/zwU/MsJ8sk+MMojPEH3RvfUICTkrl6BPjE1N s1ixFFJnE399niAJrVqc+rt3vh1HpEAj36Qhi65sNxfO4hM844EaACkPVPzeM/Tp hWoznci2xhQORsfNdRKwLpKrBPCTuxNcRxaQjqc0JuCMpbKeMskgxPY9FzpKyZdQ RsLN2EOsTtzXtqSVbj/q5Nqikb0pEVu/lbXD8SdBN8xHK12WY4tgDASy9ZttR0wj iaAHOf7zIxeOexIISPoFI9egMPFTWeJattNP/JgvkkIonUqUOMe26X38b0DXfsVe qGPmAULlo7ipCwEF1cm2f4Q4YO86zpsONnO6ocBMlrVx/+iwpmhSlbWKHEcfZxx9 UaxtGizrObenAjlM9zsT6oE5wI18O2j2bFw6c1kfwf3yFhJQb/YqI8h7H2JHHceV MIOBJHa0aIjWNHQHV5P82iHdc8tYHAq5yqBJWajF7Z+jV6waSOMbIUQhutqKhH1l 8+d6BcwSYuuQro2Av9PRkFJQ/jEDeiWimnz9d2LKp0AXVGVZu4PlXRca5hIjtyeg BW5wgb+rwzg5e6mVHqjK =tNo4 -END PGP SIGNATURE- -BEGIN PGP SIGNATURE- Version: GnuPG v2 iQIcBAEBAgAGBQJT80r6AAoJEH7ltONmPFDR28MP/R9kL+/Vo8INQXMjpNuD37Hy gwJXvf+CsfJjPPSgm89HRLX7swAHiwdmDXiN/Y4zzaYUryaHB3RAAouH/GV53U2Z tcIAX9KEaKKy4cLji01K+XJlvmck/TdlXJZnMuyM8Ps1v0vauudtUBqQ/sipnl5u ulIPxmTzVr7qKeF8T2PYr0eB738dSsLpnNyajPViNRsOcGWB7S6NdQEGpxulAdFH ZbXJmQKIpQs6zuBFPhjUZk1GYW3PvAaj/bfW5i2qdknOVo2rMBMixd0QxDaeIQKb jlOXHfY761etykCZqM3L6y0LW56EGdr1yry2gED3s/sPbzNzeytpORkb69bjOa21 UJRLF8piy4L5DIvJmDSHObBsWrtkvIqCh1Rmw9eCNn5/7PltUt9D3ESomEZG7R4r AMrahb4v1aWyI4T7Pimjf0taeL7mP45Om5AqOI+Hrdspw8xY9yAumUSvNRQiew6a oVwOcc1rOKSeflvpds0pAG0Po+JDNY5fFcm3MecXd2z/Sj4a/9ptLHObBQ9GWsW8 Za6IOIpHhDmBOADwPXk3jPMprXMsrfMmPDbPW1lAWND1flBaW1dx0x38D6e2DGko QXPOFSRBEp10TqYCbeem6/9vPmq/aRl6jjFPnFJAgjop0NDD+ISHNQ2wvlqwzzhP iJoSxWq++xTEP8YrtKgj =0/V/ -END PGP SIGNATURE- ___ infrastructure mailing list infrastructure@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/infrastructure
Re: [fedora-arm] Problems with tigervnc-server
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Tue, 19 Aug 2014 09:20:31 -0400 Robert Moskowitz r...@htt-consult.com wrote: On 08/19/2014 08:43 AM, Robert Moskowitz wrote: First, I have gotten tigervnc-server working on the Fedora20 remix for my cubieboard2, so I have the steps down. At least for F20. I am running Fedora-Minimal-armhfp-21-20140815-sda.raw.xz on my cubieboard2. I have done basic setup and have only moved ssh to a non-standard port (see my posts on selinux issues, but not germaine here). I installed Xfce: yum groupinstall Xfce Desktop --nogpgcheck This took 640 rpms?! And installed tigervnc-server. I logged in as me an created my .vnc/passwd file with vncpasswd. I then configured the start script with: cp /lib/systemd/system/vncserver@.service /etc/systemd/system/vncserver@:3.service vi /etc/systemd/system/vncserver@:3.service where I replaced user with my userid. I also opened tcp port 5903 with: firewall-cmd --permanent --add-port=5903/tcp Now wanting to be 'clean', I rebooted then: # systemctl enable vncserver@:3.service Created symlink from /etc/systemd/system/multi-user.target.wants/vncserver@:3.service to /etc/systemd/system/vncserver@:3.service. # systemctl start vncserver@:3.service Job for vncserver@:3.service failed. See 'systemctl status vncserver@:3.service' and 'journalctl -xn' for details. # systemctl -l status vncserver@:3.service ● vncserver@:3.service - Remote desktop service (VNC) Loaded: loaded (/etc/systemd/system/vncserver@:3.service; enabled) Active: failed (Result: exit-code) since Tue 2014-08-19 08:06:13 EDT; 1min 4s ago Process: 980 ExecStart=/sbin/runuser -l rgm -c /usr/bin/vncserver %i (code=exited, status=126) Process: 976 ExecStartPre=/bin/sh -c /usr/bin/vncserver -kill %i /dev/null 21 || : (code=exited, status=0/SUCCESS) Aug 19 08:05:47 cb2.htt-consult.com systemd[1]: Starting Remote desktop service (VNC)... Aug 19 08:06:13 cb2.htt-consult.com systemd[1]: vncserver@:3.service: control process exited, code=exited status=126 Aug 19 08:06:13 cb2.htt-consult.com systemd[1]: Failed to start Remote desktop service (VNC). Aug 19 08:06:13 cb2.htt-consult.com systemd[1]: Unit vncserver@:3.service entered failed state. I rebooted and checked again: # systemctl -l status vncserver@:3.service ● vncserver@:3.service - Remote desktop service (VNC) Loaded: loaded (/etc/systemd/system/vncserver@:3.service; enabled) Active: activating (start) since Thu 1970-01-01 00:00:22 EST; 44 years 7 months ago Process: 608 ExecStartPre=/bin/sh -c /usr/bin/vncserver -kill %i /dev/null 21 || : (code=exited, status=0/SUCCESS) Control: 615 (runuser) CGroup: /system.slice/system-vncserver.slice/vncserver@:3.service ‣ 615 /sbin/runuser -l rgm -c /usr/bin/vncserver :3 Looks like it is running! Great, so I check for the pid under my userid: # ls /home/rgm/.vnc/ passwd What? Only passwd that I had earlier created? Where is the pid, log, and the xstartup files? So I restarted vncserver: # systemctl restart vncserver@:3.service Job for vncserver@:3.service failed. See 'systemctl status vncserver@:3.service' and 'journalctl -xn' for details. # systemctl -l status vncserver@:3.service ● vncserver@:3.service - Remote desktop service (VNC) Loaded: loaded (/etc/systemd/system/vncserver@:3.service; enabled) Active: failed (Result: exit-code) since Tue 2014-08-19 08:26:17 EDT; 25s ago Process: 999 ExecStart=/sbin/runuser -l rgm -c /usr/bin/vncserver %i (code=exited, status=126) Process: 995 ExecStartPre=/bin/sh -c /usr/bin/vncserver -kill %i /dev/null 21 || : (code=exited, status=0/SUCCESS) Aug 19 08:26:17 cb2.htt-consult.com systemd[1]: vncserver@:3.service: control process exited, code=exited status=126 Aug 19 08:26:17 cb2.htt-consult.com systemd[1]: Failed to start Remote desktop service (VNC). Aug 19 08:26:17 cb2.htt-consult.com systemd[1]: Unit vncserver@:3.service entered failed state. So one of the following (or something I have not guessed): I missed installing something else needed like tigervnc client? Something broken for using vncserver in F21. Because no video for Allwinner, this is somehow impacting vncserver startup. And thus no remote graphical access at all (that is a scary thought, why would it matter anyway?). So any assistance on trouble shooting this? I am going to install all of tigervnc stuff now to see if it makes a difference, but I don't see why it would. Anyone with working video, if they could see if vncserver works for them? Installing the tigervnc client did not make a difference. Still failing to start. you might be best off asking on the users list, most of your questions are not at all arm specific but just general running things on fedora, and the wider audience of the users list would likely be better suited to help you.
Re: [fedora-arm] Installing on a Hard Drive
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Tue, 19 Aug 2014 14:18:29 -0400 Robert Moskowitz r...@htt-consult.com wrote: I have a couple SATA drives I would like to test booting from. Is there anything special I need to do, or can I 'just' attach with a USB/SATA adapter, run the install script (and the Cubieboard2 uboot dd command), and boot? Once I figure out the right power connector, I will be using some IDE drives on an IDE/SATA adapter as well. really the best way to install to sata is to put u-boot on a sdcard and boot the machine. you should have dhcp setup and configure pxe booting. then just do an install using anaconda. Dennis -BEGIN PGP SIGNATURE- Version: GnuPG v2 iQIcBAEBAgAGBQJT86CXAAoJEH7ltONmPFDRXsAQAKH4w7+W3/e1UPS3QTPygCXJ R0Ga2CBzOM4RNhWg0BumEU8KdweXff4Mybbk9RXtx9d1IN34PaSg2XWp+uCUoroI NZrNxvgJi2tqicvvGf7xXWbHB0+Bc3sGLc9CIOVhwA3pnNoAe1scQM0Rqr3X2Fr1 +TVCgWLDXkbmhbafhfZVy32ESSYDUcynRdzyGPN62X3PSKTe+G0T0Bfns/j1gAgv Je+0lB/YWgpypAH/3r0LRcW6jmTosSB41ErbNxgw2QsXtzjClmTtEB96GqFRZpLo vEAZjvHdBtkvE1xWqc01Im41HDAZVQDbTV0wsAQWwbor9NC8vt+0rUYfrIQCWeyf XsNJ/UOLj/PvwXHSGtZxU0yjNSUvn6P3WAgJZEhvw0h3xGp7qrEGUhSNOSPziL/d 4ISwB7W166q7mccutPPOHSnF60yKcDhcKENQGdLuWCnMaddSz6AbprTnvSS6iNSA bg/Lvztlsi/gSRNG15VkehwZI1wJe6QGVAdvv7TkGGWXKfmX4uNDsxMSq5dD17T2 2B8DtGYZt/dLW3cBayTLUwP4bm6UUnNDEaLjjqUgXyJNIriZdmg82QqF9OpnmM41 IJ/2gyfgIGwxx/AxepFovGzCntjSiqIyxhFffhwFXH6j0CvQ2eksHSURq1e24qpk 2seMC2TIN+5pEmrsmqXP =QIsh -END PGP SIGNATURE- ___ arm mailing list arm@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/arm
Re: Creds needed for Rackspace, GCE, and HP cloud image uploading, etc.
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Fri, 15 Aug 2014 17:12:23 -0400 (EDT) David Gay d...@redhat.com wrote: Hi, As per our cloud meeting today, here are the credentials I need in order to work with Rackspace, GCE, and HP, as far as I know: Rackspace: user, API key GCE: email, key, and project ID HP: user, password, tenant name The above accounts do not exist and will not until we have agreements in place with the providers. I also need credentials for our internal Openstack, which is my first priority. Kevin should be able to set you up here If anyone knows of other services that we use along with these (excepting EC2, which is already done), please let me know. as i understand it thats what we have for now. In the case that a service does not provide a good way to programmatically register images so that they are available to others, we'll have to work that out, as well. -BEGIN PGP SIGNATURE- Version: GnuPG v2 iQIcBAEBAgAGBQJT7rZmAAoJEH7ltONmPFDR/XMQALNmHLaOzzpqsN27b1/dQlwl pArKas5BYUL2Sff3Jd0Iq2RlzAiVGC2gauxq6ygZsQWJNMQDqU40of9cx0vIwhvu BTCg5eueeZgr5QK7XJ0Kr1Q5QJp/zwU/MsJ8sk+MMojPEH3RvfUICTkrl6BPjE1N s1ixFFJnE399niAJrVqc+rt3vh1HpEAj36Qhi65sNxfO4hM844EaACkPVPzeM/Tp hWoznci2xhQORsfNdRKwLpKrBPCTuxNcRxaQjqc0JuCMpbKeMskgxPY9FzpKyZdQ RsLN2EOsTtzXtqSVbj/q5Nqikb0pEVu/lbXD8SdBN8xHK12WY4tgDASy9ZttR0wj iaAHOf7zIxeOexIISPoFI9egMPFTWeJattNP/JgvkkIonUqUOMe26X38b0DXfsVe qGPmAULlo7ipCwEF1cm2f4Q4YO86zpsONnO6ocBMlrVx/+iwpmhSlbWKHEcfZxx9 UaxtGizrObenAjlM9zsT6oE5wI18O2j2bFw6c1kfwf3yFhJQb/YqI8h7H2JHHceV MIOBJHa0aIjWNHQHV5P82iHdc8tYHAq5yqBJWajF7Z+jV6waSOMbIUQhutqKhH1l 8+d6BcwSYuuQro2Av9PRkFJQ/jEDeiWimnz9d2LKp0AXVGVZu4PlXRca5hIjtyeg BW5wgb+rwzg5e6mVHqjK =tNo4 -END PGP SIGNATURE- ___ infrastructure mailing list infrastructure@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/infrastructure
Special mass rebuild
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi All, It was requested in https://fedorahosted.org/rel-eng/ticket/5962 that we do a mass rebuild for Fedora 21 and 22 of all archful packages This is due to an ABI issue on s390/x and some gcc issues. we will start the mass rebuild on 2014-08-14. This is a heads up that it will be done in side tags and moved over when completed. We will be running scripts to output failure stats. please be sure to let releng know if you see any bugs in the reporting. Dennis -BEGIN PGP SIGNATURE- Version: GnuPG v2 iQIcBAEBAgAGBQJT7OhEAAoJEH7ltONmPFDRFoIP/3FU2oUlk1wKedi3cXoFPV1k bVbFqaeGLrCFoBXZpaag+Zm8gVrojAWNyXgVzzoLlsLhO+m25lkLsvEVnnCPojxG Ze/D0Lx4hZ1mMQ+PExSXDv9IDrYyjerCcdEaRNxvhOJ3TMw9JyH5MbSlZ5Rm1qPp EwBNKq/phT9POWrHCLI8efTerKJHYhIyAzxwJzektA3OMKLal90GBojWpy3lA5wF XP0Y2DGUDSoIqZcwKtzs1LNQazCy0JINGKm8jjtLG1FgLk0nqvNnC8uTr9nFFhkI J32C2PVq69gPaun1mnq8LNjVCqBwtR7jgqLcvhZzvb5do/i0EVDS0F+176e4eRQC iJJKoGa6sri14VENUQVOfBWqQgj+qKdBGH/NhE3qS6KR4UvpZNNIykVEONfiPCwT lBMtyVYgqnj/7E+MJD0Behe6BSxHPJNTWDi+zHOQBaMAugaXCQaQLizVydZ76hjK 5TJYLInJJ4fl8J5hvVpJTDNOisvTFFHZUtLZUQT79L2xjhc8+oaX0zYQ3cViaYsB wJmz73BdMsdEwKmhBVpTpXeZL4do6XxyACw/uabU3nZ74J58Lj/PFcW26ulTm7m2 Tk3z7zFjR0M0PZIFzzEiDJlaVHFvyxwabjMveRk5v5mgx3Jq6huJhERnZRhpDv5F bWwZzUlfNCYRNL6ZPn3P =tfVC -END PGP SIGNATURE- ___ devel-announce mailing list devel-annou...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel-announce -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Special mass rebuild
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi All, It was requested in https://fedorahosted.org/rel-eng/ticket/5962 that we do a mass rebuild for Fedora 21 and 22 of all archful packages This is due to an ABI issue on s390/x and some gcc issues. we will start the mass rebuild on 2014-08-14. This is a heads up that it will be done in side tags and moved over when completed. We will be running scripts to output failure stats. please be sure to let releng know if you see any bugs in the reporting. Dennis -BEGIN PGP SIGNATURE- Version: GnuPG v2 iQIcBAEBAgAGBQJT7OhEAAoJEH7ltONmPFDRFoIP/3FU2oUlk1wKedi3cXoFPV1k bVbFqaeGLrCFoBXZpaag+Zm8gVrojAWNyXgVzzoLlsLhO+m25lkLsvEVnnCPojxG Ze/D0Lx4hZ1mMQ+PExSXDv9IDrYyjerCcdEaRNxvhOJ3TMw9JyH5MbSlZ5Rm1qPp EwBNKq/phT9POWrHCLI8efTerKJHYhIyAzxwJzektA3OMKLal90GBojWpy3lA5wF XP0Y2DGUDSoIqZcwKtzs1LNQazCy0JINGKm8jjtLG1FgLk0nqvNnC8uTr9nFFhkI J32C2PVq69gPaun1mnq8LNjVCqBwtR7jgqLcvhZzvb5do/i0EVDS0F+176e4eRQC iJJKoGa6sri14VENUQVOfBWqQgj+qKdBGH/NhE3qS6KR4UvpZNNIykVEONfiPCwT lBMtyVYgqnj/7E+MJD0Behe6BSxHPJNTWDi+zHOQBaMAugaXCQaQLizVydZ76hjK 5TJYLInJJ4fl8J5hvVpJTDNOisvTFFHZUtLZUQT79L2xjhc8+oaX0zYQ3cViaYsB wJmz73BdMsdEwKmhBVpTpXeZL4do6XxyACw/uabU3nZ74J58Lj/PFcW26ulTm7m2 Tk3z7zFjR0M0PZIFzzEiDJlaVHFvyxwabjMveRk5v5mgx3Jq6huJhERnZRhpDv5F bWwZzUlfNCYRNL6ZPn3P =tfVC -END PGP SIGNATURE- ___ devel-announce mailing list devel-announce@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel-announce
Re: [fedora-arm] vncserver on F20 working sometimes
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Thu, 14 Aug 2014 09:43:07 -0400 Robert Moskowitz r...@htt-consult.com wrote: On 08/14/2014 09:22 AM, R P Herrold wrote: On Thu, 14 Aug 2014, Gordan Bobic wrote: You could just mount tmpfs on /tmp. Then you can be sure it gets cleared by a reboot. or, more targeted, a: /tmp/.X11-unix/ as tmpfs So please help me a bit here with fstab, as I have hosed them a time or two tmpfs /tmp/.X11-unixtmpfs defaults0 0 And how to I switch over? Boot will take care of it? we switch off /tmp on tmpfs when making the images echo Disabling tmpfs for /tmp. systemctl mask tmp.mount im assuming if you just ran systemctl unmask tmp.mount that /tmp on tmpfs will be reenabled Dennis -BEGIN PGP SIGNATURE- Version: GnuPG v2 iQIcBAEBAgAGBQJT7L74AAoJEH7ltONmPFDRfTMQAMoW0ImHC33uIhCvbPEXnElF Da2/SLrP9RNTU+Sd2UOvcbeU99FShEhCWNF+Ps81fsj4FtuJomn+AKKuukSPx+Hp 79Prlc8rAScqTVp9klJ6IgJ/QYDb/CVtDsD0WsQmXLG1YTcWAoPPm3sRC+RD4w42 CDYmYl58/5qy0RQs85uchF53GF+0GZG60K7h9GnuGsdjZGtgmtEB1mFoXxVvz/QX FGlbWe1MEliFnnYUEfUxn5B5WddCigp18RjlRq6vHVFcBJ/9bomLSn+Su6hYmxuf Fq6bAbPxT47zwoBNsOjO8CMkUClrAI8oCrtku6PAYFXAb/5NCKS09XPEB9RwlshV diRbCFuwj60Jw11ptTYITX7EoSKI3z+pdyXAurJy4BWxfTwST0qpncmR9MojbdAh hn+YN94Jb2lIvgPIe2ekhhwFKiq5YsFG/ND3roKAc1AIu2GPNMcxe8tX+86YRDCi 2zuYGCN7blRGI0WTx+CjGhtTzHPV9kpiiMHJLXMbzjp4yAiccc6hq6V+0p7ecO7E Wu/vlBrqjG1XyMWaUbyg+fSQ+3cbAGIxE56DA/iazPhbzVuwxBeW5bG4I9YAvDb+ dTwlc3yKkSSXd9+uDDlpktdoMSCVpv79EESP8TtawMgVAOlqi5t+Ry19eWe/8T7A 08oTuJ8hYKPXn8H/YLWb =5UWJ -END PGP SIGNATURE- ___ arm mailing list arm@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/arm
Re: EPEL zabbix for EL7
On Wed, 13 Aug 2014 09:49:14 +0200 Patrick Hurrelmann patrick.hurrelm...@lobster.de wrote: Orion built zabbix22 (2.2.5) in EPEL 7 yesterday. Volker Hi Volker, I just wanted to test the packages, but the zabbix22 rpms are not signed. Could you please push signed rpms? Thx a lot for your and other's hard work on zabbix rpms. Regards Patrick epel rpms are not guaranteed to be signed until we go out of beta. releng signs them, packagers have no ability to do so. Dennis ___ epel-devel mailing list epel-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/epel-devel
[U-Boot] Wandboard console speed
Hi all, The default environment for the wandboard does not specify the speed for the console. I have an open bug in Fedora[1] I am curious if there was a particular reason why the speed is not set, or if i should just send in a patch to change it? I really do not want to carry a patch around forever. Dennis [1] https://bugzilla.redhat.com/show_bug.cgi?id=1044778 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Wandboard console speed
On Wed, 13 Aug 2014 15:00:43 -0300
Fabio Estevam feste...@gmail.com wrote:
On Wed, Aug 13, 2014 at 2:55 PM, Dennis Gilmore den...@ausil.us
wrote:
Hi all,
The default environment for the wandboard does not specify the speed
for the console. I have an open bug in Fedora[1] I am curious if
there was a particular reason why the speed is not set, or if i
should just send in a patch to change it? I really do not want to
carry a patch around forever.
Actually we do specify the baudrate in wandboard.h:
console=${console},${baudrate}
must have changed recentlyish we are using 2014.04 and it's
console=ttymxc0 im in the process of updating to 2014.10 so i guess
its a non issue anymore
Dennis
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Wandboard console speed
On Wed, 13 Aug 2014 15:33:43 -0300 Fabio Estevam feste...@gmail.com wrote: On Wed, Aug 13, 2014 at 3:30 PM, Dennis Gilmore den...@ausil.us wrote: must have changed recentlyish we are using 2014.04 and it's console=ttymxc0 im in the process of updating to 2014.10 so i guess its a non issue anymore It is the same in 2014.04: http://git.denx.de/?p=u-boot.git;a=blob;f=include/configs/wandboard.h;h=6c74c72952586f3e9264591c41af34d4bfa8e1e1;hb=dda0dbfc69f3d560c87f5be85f127ed862ea6721 Please check lines 137 and 160. check line 112, most boards just use the console variable and not the way you have it set. in my porting to generic distro configs it seems that we dropped off the re-configuring of the variable. Ill send in a patch to clean things up soon. along with porting to the distro generic configs Dennis ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: EPEL Notes from .next discussion.
On Tue, 12 Aug 2014 21:05:07 +0200 Stephen John Smoogen smo...@gmail.com wrote: At FLOCK this year, I did a short workshop on what was labeled EPEL.Next. At that we went over a bit of what EPEL has done in the past, what its current challenges are, and what could be its future. Toshio Kuratomi was great in capturing what was said at the meeting and EPEL * Extra packages for enterprise linux * Lots of name recognition now * Formed as rhel5 was being released people needed more packages. at the time there were a ton of addon repos. None of the m were compatible with each other necessarily. All the other repos, dag, freshrpms, etc overrode the base os in some places. Decided for EPEL, overriding RHEL was something we wouldn't do. Started with RHEL3,4 and soon after release we had 5. RHEL was supported 5-7years and we figured we could support EPEL packages for the same length of time. Early controversy - repotags (shortened name that can be in the packages. [graph of Fedora machines measured by unique ips that hit mirrormanager vs EPEL machines] [graph shows steady growth in EPEL. Larger initial Fedora machines that rose and then plateaued] [graph shows a noticable dip every weekend. Can also see the dip in Fedora numbers for the Incident.] [graph is probably conservative in numbers as many enterprises Second graph: [Graph shows combined growth same as last graph.] [Graph shows EPEL5 that has risen but plateaued about the time EPEL6 came out.] [graph shows that EPEL6 has been growing and has surpassed the EPEL5 plateau.] Where are we now: We support 3 arches. I think you mean 3 releases. we have 3 arches for epel5 and epel6 and 2 for epel7 RHEL4: 1258 srpms. EOL RHEL5: 3651 srpms RHEL6: 5449 srpms RHEL7: 3100 srpms and growing fastest For CENTOS7: the epel repofile will be shipped directly with centos for the first time. Current Problems: * 10+ year support for RHEL now. Hard for EPEL packagers to commit to doing the same. * We have requests for both newer and older conflicting packages. - Currently policy is not to have unpleasant surprises regarding compatibility. - puppet2.x vs puppet3.x * Some people need major changes to build new software * Some people need no changes in order to keep existing software running * Developer burnout: People come in and after a few years, they are burnt out because they can't upgrade the things that they want due to the compatibility policies. I think i would like to see us add an epel-extras repo where things can change faster. Things like mediawiki, puppet, etc could go in extras. Where are we going? Pain Points: * Inability to yum downgrade because only include one old package in the updates tree * Harder for EPEL than Fedora because EPEL users have more need to rollback if an incompatibility creeps in and because EPEL users may schedule their releases * Not every part of package repo is suitable for inclusion in anaconda because we may not have dep closure in the subset of the repo. * Which RHEL point release can also make a difference because the base RHEL sometimes upgrades incompatibly and we don't keep a separate build for both point releases. * Can take a long time to push packages through bodhi. Can take 7 days to push a CVE through bodhi. (global EPEL and Fedora problem) * Not all maintainers interpret Don't break compatibility in the same way. * Many guidelines are verbal, not formal. * Some maintainers are mainly Fedora maintainers and don't know what people are using it for in EPEL. They respond to requests to install or update a package out of a willingness to help but don't know what users need. * No guideline enforcement. * Takes a while for new EPEL releases to be brought out once a new RHEL release is made (because CentOS hasn't released yet). * Traditionally, we wait because contributors may not have RHEL entitilements so they need to have CentOS to test. * Need entitlements for contributors to run RHEL (Easiest: Use RHEL, SciLinux, Fermi Linux). * Packages get added to one of the RH base repositories and then we have to pull them from the EPEL repositories. * Some people have extra layered products from RH and do not want us to conflict with those. Other people do not have the layered products and therefore want to be able to get those packages from EPEL. * Overlap between EPEL and CentOS Extras. Ideas to deal with Pain * Get RHEL licenses for contributors. There is a process but it takes a long while because of the tax problems for giving it to people. Current procedure is that we get requests, we give the names to a person inside of RH and then they eventually get back to us with licenses. * Let's create EPIC: separate repo. 3 year lifespan instead of 10 year, rhel life cycle. * Debian Volatile repository and also Debian Backports. These repos contain newer versions of packages, even for Debian
Re: [U-Boot] [PATCH 1/3] config: introduce a generic $bootcmd
On Tue, 12 Aug 2014 19:29:02 +0200 Jeroen Hofstee jer...@myspectrum.nl wrote: Hello Stephan, On 11-08-14 20:55, Stephen Warren wrote: snip No, Linux distros need to be able to install a single bootloader configuration file to tell the bootloader how to boot. Don't understand this, I though extlinux is yet another chainloaded bootloader? I doubt there is the bootloader. I don't understand why it needs a single bootloader. It gets in handy if the last bootloader is known, but I don't even see why that is required. This is obviously where the disconnect is... extlinux is (IIRC) a bootloader yes. However, this patch isn't about extlinux, but extlinux.conf. haha, right that is a funny misunderstanding. Yes, extlinux is indeed a bootloader and I was in the impression you actively searched for it to chainload it. And to make extlinux a requirement for distro support... And as I tried to explain I am not that fond of such an approach in general, and that had nothing to do, as Tom suggested, with booting FreeBSD, it is just the image I encountered searching for it in various places. It remains a badly named file though (for U-boot), but well so be it, I guess. u-boot in the pxe code has an implementation that parses the syslinux config file. though there really is nothing that says its a linux only thing, admittedly I'm a bit naive as to how things like freebsd boot but i assume you can load a kernel and pass some boot arguments just the same. We are looking for a extlinux.conf file as that's what extlinux looks for and we are mimicking the functionality. extlinux.conf is a text file format the defines a menu of bootable OSs. It's a (de-facto I suppose) standard that's implemented by extlinux (if indeed that is a piece of SW:-) and also U-Boot and barebox and likely other bootloaders too. So, when U-Boot locates extlinux.conf on disk and processes it, it's parsing a configuration file/menu, not chain-loading/executing another bootloader. I see, so shouldn't we document then who is in charge of its format at least, before we start making a U-boot/distro specific version of it? We are using the same format as is used by the syslinux project. we support a couple of optional items to specify the dtb, fdt and fdtdir, fdt is a location to a devicetree blob and fdtdir is a directory where you can find devicetree blobs. snip example file That would require all Linux distros to have specific support to install boot.scr, which is a bootloader-specific format script file. Systems that boot using e.g. Barebox or other bootloaders presumably can't process boot.scr. However, if all bootloaders end up supporting extlinux.conf, the distro won't care what bootloader is on the HW. We will see if this works, I am bit skeptical, but it is at least a whole lot better then polling all possible options, where I took the patch for. (Well not all yet, but the start to do so). Even with checking the different places that we can find the config file. There is no noise, u-boot doesn't print out when there is no files found only when it find them. The time to check for the existence of the file is very quick. Dennis ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: Consistent names changed yet again?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Wed, 6 Aug 2014 07:41:07 -0400 Tom Horsley horsley1...@gmail.com wrote: I've got F21 branched installed on an alternate partition on my system, and I noticed this nonsense. On F21 I get this: enp5s0: flags=4163UP,BROADCAST,RUNNING,MULTICAST mtu 1500 inet 10.134.30.143 netmask 255.255.255.0 broadcast 10.134.30.255 inet6 fe80::20b:eff:fe0f:ed prefixlen 64 scopeid 0x20link ether 00:0b:0e:0f:00:ed txqueuelen 1000 (Ethernet) RX packets 112 bytes 13242 (12.9 KiB) RX errors 0 dropped 0 overruns 0 frame 0 TX packets 84 bytes 10207 (9.9 KiB) TX errors 0 dropped 0 overruns 0 carrier 1 collisions 0 this comes systemd's naming structure. On F20 the same hardware (note the MAC address) gives this: p6p1: flags=4163UP,BROADCAST,RUNNING,MULTICAST mtu 1500 inet 10.134.30.143 netmask 255.255.255.0 broadcast 10.134.30.255 inet6 fe80::20b:eff:fe0f:ed prefixlen 64 scopeid 0x20link ether 00:0b:0e:0f:00:ed txqueuelen 1000 (Ethernet) RX packets 1233320 bytes 144491797 (137.7 MiB) RX errors 0 dropped 0 overruns 0 frame 0 TX packets 2058583 bytes 2951769070 (2.7 GiB) TX errors 0 dropped 0 overruns 0 carrier 1 collisions 0 this comes from biosdevname's naming structure. Dennis -BEGIN PGP SIGNATURE- Version: GnuPG v2 iQIcBAEBAgAGBQJT54GYAAoJEH7ltONmPFDRE4AQALDcOWuQyBurqmOd55OMXJuW kWNAf9jn4Jz4WJOBnAFD64BNq1SHJ/ToxhbT3Ip7mr/ljRGs5Ctq52BX8nnxZ799 /JT3INAydphquIm5yLLTswyklsGfHhOnQnLyZRTmDLgXnxl1bMlKWhWLnXNKIPol rXGRH2MqCO9eQQ9wC3C0HypwefcKa7e3Cmw3uioZ4sCni4GnhF3YrQ/wW26x6tGb k/D6gHvYNp/76PrN+IOeTF2GYqN3UqVasMIthsdbpAFfwWJE7xPb6SecWLBNXXYj /4O7UzvgxygMSLgQvjyit4g/7hIuPC0QAYwXi5EnQxn1EIqnhWPTkjRb8yxjk5HV x78dVQFTNLuBklCDx/hA++rRdcxNrLfeLghOQxLJgoD7r4VgS/6TQ2IHkgBIYIlY kPzDeaLkblkwMfpPZ6azrqMVD0TBqiGacH/penjuW0pFxDR/36X33CMP6lDliQMh Nkm7C0WzDv0c0H++rWEmosbjTmi/1t7YXI5E7fyf9zLwyEM2u/b1uSxfuiY4IU11 x+KDm9PTOcqnhKdUGgF6b5TQ4mLpwMCexdTEJgsB7W6hngEgMqcTaukCZE4b8h22 8B6XW/aXOog9k0iSJvIKaVinAmK7Ase6WEZKozxmYVTpfPu/GtvMuDMuUVdYt18m acynVG+xp4ha/35snBL1 =PQQ0 -END PGP SIGNATURE- -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: [U-Boot] [PATCH 1/3] config: introduce a generic $bootcmd
On Wed, 06 Aug 2014 10:01:09 -0600 Stephen Warren swar...@wwwdotorg.org wrote: On 07/30/2014 04:37 PM, Stephen Warren wrote: From: Dennis Gilmore den...@ausil.us This generic $bootcmd, and associated support macros, automatically searches a defined set of storage devices (or network protocols) for an extlinux configuration file or U-Boot boot script in various standardized locations. Distros that install such a boot config file/script in those standard locations will get easy-to-set-up booting on HW that enables this generic $bootcmd. Simon, are you OK with these patches following the discussion? Dennis, I assume you're OK with the new version of this patch? I am okay with this version. Dennis I assume that your acks would go a long way towards Tom applying this series. Thanks. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [fedpkg PATCH 2/2] add new s390 only packages
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Fri, 1 Aug 2014 22:33:07 +0200 Dan Horák d...@danny.cz wrote: --- src/fedpkg/__init__.py | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/fedpkg/__init__.py b/src/fedpkg/__init__.py index 0837120..9f2ce49 100644 --- a/src/fedpkg/__init__.py +++ b/src/fedpkg/__init__.py @@ -89,7 +89,7 @@ class Commands(pyrpkg.Commands): 'servicelog', 'yaboot', ], 'arm': ['xorg-x11-drv-omapfb'], - 's390': ['s390utils', 'openssl-ibmca', 'libica'] + 's390': ['s390utils', 'openssl-ibmca', 'libica', 'libzfcphbaapi'] } # New properties applied both thanks Dennis -BEGIN PGP SIGNATURE- Version: GnuPG v2 iQIcBAEBAgAGBQJT3zc9AAoJEH7ltONmPFDRHiQP/RKn7Shg/eXA+10Grxkl3Oel sEPapT5PfGBu2bJI6+BkQb2xBuKZGHxDfPHDYxgdUJHXjFHhS7W7sa2gBxMO3QAe WCiCFLCsnxZXrlcMGYtwtM6kdX8LVtZITnjMEt/2WXg7k6pdgFjWwwTLYzJsLxYt d4YnD3Aj55GBp7X8TBTG+1+EfRgOi3/AQUDkX9MZj9UW5gdUEhjnhtruU8euMqT9 E8AC/tB8Azz5PqlGyLIe/UULQ3v1FRgduvwWp68ZV7cYVSgmXufIm0s8t7gNBRU4 7RuvytrMYprDIbTm1/AZdqA+4bM/+ZayiJkOIuTdd+RV4CpHKKAl0mN2mBhrvVw2 pZ7tvFhV3aK+AXtBrQ+tPLV1GmoQ7lDJv9VIg6LAUVjStESvzXINB1s5GlVG3Igr wlF/+kK1GWsrmKiU1uOC/zX8RjEh8jyi6WMjEx3nro9ic5SYTwkZHRSkfMFpAcYw w5x6JbrZ8QJ5avvWJhpnzSV3QS5VJSzMRyUFLLoK03Ag1Wsqegt+/QIwY3883RaB FNlKAcdB2toewANPZOsO5Q5Z/zeQlvfJJppdjCUJQRdWPYEmFOV2jAMjMM8c7rRU ta65nq60b17bHo44iDdqljQZcMyyleuHplpBm8tamrAhRy02Lf/c4mFabK7kssOR 4eULqtgzA5oDhPcTBFrM =r1Cg -END PGP SIGNATURE- -- buildsys mailing list buildsys@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/buildsys
Re: [U-Boot] [PATCH 1/3] config: introduce a generic $bootcmd
On Mon, 4 Aug 2014 04:13:41 -0600 Simon Glass s...@chromium.org wrote: Hi Stephen, On 31 July 2014 17:00, Stephen Warren swar...@wwwdotorg.org wrote: On 07/31/2014 04:03 PM, Simon Glass wrote: Hi Stephen, On 30 July 2014 23:37, Stephen Warren swar...@wwwdotorg.org wrote: From: Dennis Gilmore den...@ausil.us This generic $bootcmd, and associated support macros, automatically searches a defined set of storage devices (or network protocols) for an extlinux configuration file or U-Boot boot script in various standardized locations. Distros that install such a boot config file/script in those standard locations will get easy-to-set-up booting on HW that enables this generic $bootcmd. Boards can define the set of devices from which boot is attempted, and the order in which they are attempted. Users may later customize this set/order by edting $boot_targets. Users may interrupt the boot process and boot from a specific device simply by executing e.g.: $ run bootcmd_mmc1 or: $ run bootcmd_pxe This patch was originally written by Dennis Gilmore based on Tegra and rpi_b boot scripts. I have made the following modifications since then: * Boards must define the BOOT_TARGET_DEVICES macro in order to specify the set of devices (and order) from which to attempt boot. If needed, we can define a default directly in config_distro_bootcmd.h. * Removed $env_import and related variables; nothing used them, and I think it's better for boards to pre-load an environment customization file using CONFIG_PREBOOT if they need. * Renamed a bunch of variables to suit my whims:-) Signed-off-by: Dennis Gilmore den...@ausil.us Signed-off-by: Stephen Warren swar...@nvidia.com I do understand the desirability of getting something sorted in this area. But I am not thrilled with all the macro magic. How does this fit with the new Kconfig setup? It encourages a single setting for each variable, and I feel that the #ifdefs are not compatible with that. I think Kconfig would be completely unsuitable for this kind of detailed configuration. Kconfig is great for enabling/disabling features, but applying it here feels too much to me. Equally, Kconfig is rather new in U-Boot. It'd be better to enable the feature so that distros can rely on it, and then refactor it later if required. Are you saying that we can reimplement this in a nicer way and distros will still see the same behaviour? As long as the implementation loads a extlinux.conf file yes. how things are implemented in u-boot really does not matter at all. the API between os and u-boot is the config file. I do feel that actually implementing the boot script as U-Boot environment variables is much preferred over hard-coding any algorithm into U-Boot. That way, the user can easily modify the scripts as they desire. If we just put e.g. $boot_targets into the environment or DT, but none of the other scripts in this patch, the user would be much more severely restricted in how they could reconfigure the system to act how they want. But that worries me. It means that it is easy for one board to deviate from what is essentially an undocumented boot standard, and then we will end up having to support that use case in the future. Or if it is documented, where is that? http://www.syslinux.org/wiki/index.php/Doc/syslinux we have added fdt and fdtdir options for dealing with dtb. we probably should have our own documentation. We have adopted a standard. Would it be possible to put the settings in the device tree somehow instead of CONFIGs? At least part of the information isn't a HW description, but rather user-/vendor configuration. So, I don't think it's appropriate to put this into DT. Equally, very few U-Boot platforms currently use DT, and I certainly hope it doesn't become mandatory in any way. So, using DT for this purpose would severely limit the platforms where this feature was available. The only platforms I see support for in your series are Tegra (which has DT) and Raspberry PI. Adding basic DT support is not really onerous so doesn't impose any real limits on adoption. In any case I'm mostly just responding to what I see might become a large and mandatory script setup in U-Boot. Would it not be better now to document this clearly and specify that changes are not supported? Then we might be able to refactor it later and still retain compatibility. If we have a clear API separate from the implementation then it is easier to live with the scripts knowing we can do things a different way later. Looking at this from a driver model perspective we would probably want to have a list of devices to try, in a certain order. Certainly driver model would support the approach in this series, but it would be a very ugly way of achieving the goal IMO. BTW in your series bootpart is always 1
Re: [fedora-arm] Update on Allwinner / sunxi u-boot support
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Fri, 01 Aug 2014 00:20:19 +0200 Hans de Goede hdego...@redhat.com wrote: Hi, On 07/31/2014 02:58 PM, Dennis Gilmore wrote: On Thu, 31 Jul 2014 10:16:00 +0200 Hans de Goede hdego...@redhat.com wrote: Hi, On 07/30/2014 10:48 AM, Hans de Goede wrote: Hi Dennis et al, As you may have heard Ian Campbell and I have become u-boot custodians for sunxi boards. As such we've been working hard to get sunxi support into shape for the upcoming v2014.10 release. Yesterday sun4i (the original A10) and sun5i (A13 / A10s) support got merged to complete the existing sun7i (A20) support, as well as most of the PSCI code needed to do smp + hyp mode on the A20. I've just send a pull-request adding AHCI, EHCI and PSCI support + support for 14 new boards. You can find the branch for this here: http://git.denx.de/?p=u-boot/u-boot-sunxi.git;a=shortlog So assuming that F-21 will use v2014.10 that should put us in pretty good shape wrt sunxi support. I would like to make sure that Fedora can use upstream u-boot as-is. AFAIK we still need to do some work wrt unified distro support / config_distro_defaults.h e.g. I think we need to specify the dts file name for each board config somewhere for thinks to work ootb, correct ? Dennis, can you provide a minimal patch on top of the above branch needed to get things to work ootb on one board, e.g. the cubietruck ? A quick update on this, Stephen Warren (nvidia) has posted an updated version of your config: introduce a generic $bootcmd, and that just got Acked, so hopefully that will make it into v2014.10: http://patchwork.ozlabs.org/patch/375060/ It would be nice to also sunxi converted to this upstream. This means that you need to post a conversion patch this weekend the latest, otherwise it will be too late for the freeze (freezes in u-boot are based on the posting of v1 of a patch). I can try to do this myself this weekend, but chances are that I won't have time for this. I can try and get something together for you. I was not planning on using 2014.10 at all. But I think that given whats going in, we should move to it. I do need to get a Fedora 21 Test Compose out this week. sorry for the slow response, because i was directly copied on the email it went though an unusual path of my procmail recipes and ended up in a folder I do not often check. as it gets mostly spam. Ok, so I've managed to get write a patch for this myself, currently it only sets the dtb filename for the bananapi, I will add to all the other boards tomorrow and then submit it upstream, in the mean time you can find it here: https://github.com/jwrdegoede/u-boot-sunxi/commits/next The last commit there is a slightly cleaned-up version of your: automatically add console= to bootline when not existing patch, I would also like to submit that one upstream, may I add your (Dennis)' Signed-off-by to it ? NAK, I was planning to drop the patch entirely, while its useful in some cases, it breaks things like plymouth working, as well it will force anaconda installs to always be text over the serial port. wandboard and cubox-i for instance boot happily without a console= line and you get plymouth on the screen when video is initialised. having it add the console line if u-boot has the console set to serial would be okay. I think it needs some more thought and careful planning. Dennis -BEGIN PGP SIGNATURE- Version: GnuPG v2 iQIcBAEBAgAGBQJT20hmAAoJEH7ltONmPFDRepEP/3aErbWDUmhe14B0SrXNJok8 tjJdOQ4tF7kQTtGM+PZlhzCDJPoa7D6Wl8bCMs8I5jgkoOnvLFty0Qdzo3GZiKnE f4n5XQeX9kzhqAXz/mO5Xt6j2nkYdJOkePUxZJC+gP0o/9EwVTWS65qU+dDPoiXN QVOtQXw0CgVo53brf/XZqlof29S4tmmPqYN2lik+2IrOC2aS1H8DfICZxCQ8/9vj xJFTPVEqa+c8CP3QY7p9B5VILXtNgUZHvcrndXugMdeVgmp05lJRD4J9oWnuHd8P A8A+O9+r0elsZYdVMk+FF8h0JHjGeBQc3+X/uXRp6Ju7DAl5jnySeVPzf+VlXgrC h9I7Z2gBv6YnM8qT8ffFmTEjAqemLDlTL3cwVKI8e5BzGzGnS23gQyq3r30/6n// Y7s0JUvbIs0Ro4ML7BeAN+UV54iE1KMPp/bwHB7zqVy9OF09q26kpJVKjcO3B6g8 udvMfXnk0MaFTF6bls/FJxPYFGkqyHXNhsckcdOGZlu3cFfe54QMTbmdAX4ACfND raFtSThvS8PQPlVwqxFxUVX7J6VHtweE4e6pVPWlgUStvsSvfRRQvL7O+tzIN8MW aHlFSrI86f9aUO5pKR9dBm2ivU+NQxunXu2IId7gdYrH8B6dFVOwavA7VqNwCL5a iJ5BsT2Ofav7oyGVPIQb =rvTu -END PGP SIGNATURE- ___ arm mailing list arm@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/arm
Re: [U-Boot] [PATCH 7/7] sunxi: Add environment settings to make extlinux.conf booting work
On Fri, 01 Aug 2014 12:57:31 -0600 Stephen Warren swar...@wwwdotorg.org wrote: On 08/01/2014 01:46 AM, Hans de Goede wrote: Automatic booting using an extlinux.conf file requires various environment variables to be set. Acked-by: Stephen Warren swar...@nvidia.com I'd personally be tempted to set fdt_high=0x, initrd_high=0x to stop U-Boot copying the DT/initrd from the load location to some other location under 256M, but that's just an optimization and entirely optional. There has been quite a few times where using 0xff has caused issues. I really think you should set bootm_size to something reasonable. beaglebones for instance has to be 0x1000 as the beaglebone white only has 256M of ram. and let u-boot move things around, ensuring we do not get into a place where the decompressed kernel overwrites memory. This behaviour is what I had in the docs I had written earlier in the year. Dennis ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 7/7] sunxi: Add environment settings to make extlinux.conf booting work
On Fri, 01 Aug 2014 14:22:40 -0600 Stephen Warren swar...@wwwdotorg.org wrote: On 08/01/2014 02:05 PM, Dennis Gilmore wrote: On Fri, 01 Aug 2014 12:57:31 -0600 Stephen Warren swar...@wwwdotorg.org wrote: On 08/01/2014 01:46 AM, Hans de Goede wrote: Automatic booting using an extlinux.conf file requires various environment variables to be set. Acked-by: Stephen Warren swar...@nvidia.com I'd personally be tempted to set fdt_high=0x, initrd_high=0x to stop U-Boot copying the DT/initrd from the load location to some other location under 256M, but that's just an optimization and entirely optional. There has been quite a few times where using 0xff has caused issues. What kind of issues? At least for Tegra, I've carefully chosen the values for the various load addresses so that there won't be issues. (Without that I can easily see the potential for issues.) I've seen far more repeated problems when U-Boot moves the DT/initrd around than than when it didn't (none in that case). Besides, it's completely redundant and unnecessary work if the blobs are already loaded at sane addresses, which they are on Tegra at least. Mostly to do with the decompressed kernel overwriting the initrd or dtb resulting in machines that would hang on boot. it came up quite a few times earlier this year on both imx and omap. Dennis ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [fedora-arm] Update on Allwinner / sunxi u-boot support
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Thu, 31 Jul 2014 10:16:00 +0200 Hans de Goede hdego...@redhat.com wrote: Hi, On 07/30/2014 10:48 AM, Hans de Goede wrote: Hi Dennis et al, As you may have heard Ian Campbell and I have become u-boot custodians for sunxi boards. As such we've been working hard to get sunxi support into shape for the upcoming v2014.10 release. Yesterday sun4i (the original A10) and sun5i (A13 / A10s) support got merged to complete the existing sun7i (A20) support, as well as most of the PSCI code needed to do smp + hyp mode on the A20. I've just send a pull-request adding AHCI, EHCI and PSCI support + support for 14 new boards. You can find the branch for this here: http://git.denx.de/?p=u-boot/u-boot-sunxi.git;a=shortlog So assuming that F-21 will use v2014.10 that should put us in pretty good shape wrt sunxi support. I would like to make sure that Fedora can use upstream u-boot as-is. AFAIK we still need to do some work wrt unified distro support / config_distro_defaults.h e.g. I think we need to specify the dts file name for each board config somewhere for thinks to work ootb, correct ? Dennis, can you provide a minimal patch on top of the above branch needed to get things to work ootb on one board, e.g. the cubietruck ? A quick update on this, Stephen Warren (nvidia) has posted an updated version of your config: introduce a generic $bootcmd, and that just got Acked, so hopefully that will make it into v2014.10: http://patchwork.ozlabs.org/patch/375060/ It would be nice to also sunxi converted to this upstream. This means that you need to post a conversion patch this weekend the latest, otherwise it will be too late for the freeze (freezes in u-boot are based on the posting of v1 of a patch). I can try to do this myself this weekend, but chances are that I won't have time for this. I can try and get something together for you. I was not planning on using 2014.10 at all. But I think that given whats going in, we should move to it. I do need to get a Fedora 21 Test Compose out this week. sorry for the slow response, because i was directly copied on the email it went though an unusual path of my procmail recipes and ended up in a folder I do not often check. as it gets mostly spam. Dennis -BEGIN PGP SIGNATURE- Version: GnuPG v2 iQIcBAEBAgAGBQJT2j14AAoJEH7ltONmPFDRt3kQANG6jrMEFRMYzb2Ftr/qAU9R Mkh3vn5etU/mQ0wANYHI+atJOhZ4kP7lP6MyRrj9VJZEXLQI5hAGncZCwa2PDZsq U/toTq0pVYWx6zsZyZzPhVhIkseeHSnqSsWscSEEZ50CVK9uPvuu0qWngKeK7a+W vYIKeDjx8QbGo32yOeN0wdlkZg5w+TppZSei5q019vlbONP3n59lLEpQEEHYEebw dcd70/zRzUQffWM805FsYYetWugWW07Zwcm8kwnWfuDoMpoV+z+DVLLCgeKvXPEH 0w0c8qA2nfvaA5OoRDctEXcPktI46F5iwkHfsZRnfrSkD7At4L7vm/xiC1MK+3+t H+aZWJG/TGELEqDEBcGsbV4LqRZlcFg5v9vNUV+x84L8rIw/ism8bSVcXNbEXBp4 9grkLHw4lrrGnNF3qbc8z/nd8qN8oZWcfL8dmm6HO7m6xTbncLXMbEvo2PYcVe3W SzRAaWsCAxs4gr3C9BjBXZNlLGr61B1b6cJlSQy7XE7dJNoSwOE68AHbOoSnizlP zw/MG4u4Dbv++ZJjLFCruQcQbImiBLBKdNrmGBYf/4NGsCQB5VcB73t2Tmi/IDVI yQRF++7qK7U7Vp7MCKjTCmW4wb1piya8JAd6SFEf0D01X64AYJx9cb7tqVmRAinX 5p32gHno6ewAeKHUEXJA =LHe/ -END PGP SIGNATURE- ___ arm mailing list arm@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/arm
Re: Good time to sync Thursday or Friday morning?
I'm in Brno all week. Early morning us would work best On Jul 29, 2014 10:36 PM, Joe Brockmeier j...@redhat.com wrote: Hi Dennis, Is there a good time for us to sync on infrHi Dennis, Is there a good time for us to sync on infra issues for Atomic this Thursday or Friday? Most important folks to be there are you and Colin, I think. Best, jzb -- Joe Brockmeier | Principal Cloud Storage Analyst j...@redhat.com | http://community.redhat.com/ Twitter: @jzb | http://dissociatedpress.net/ ___ infrastructure mailing list infrastructure@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/infrastructure
Re: Good time to sync Thursday or Friday morning?
Should be good for me. On Jul 29, 2014 10:51 PM, Joe Brockmeier j...@redhat.com wrote: Colin, Dennis - can you do Friday 9 a.m. Eastern? BestColin, Dennis - can you do Friday 9 a.m. Eastern? Best, jzb - Original Message - From: Dennis Gilmore dgilm...@redhat.com To: Joe Brockmeier j...@redhat.com Cc: Colin Walters walt...@redhat.com, infrastructure@lists.fedoraproject.org Sent: Tuesday, July 29, 2014 4:40:35 PM Subject: Re: Good time to sync Thursday or Friday morning? I'm in Brno all week. Early morning us would work best On Jul 29, 2014 10:36 PM, Joe Brockmeier j...@redhat.com wrote: Hi Dennis, Is there a good time for us to sync on infrHi Dennis, Is there a good time for us to sync on infra issues for Atomic this Thursday or Friday? Most important folks to be there are you and Colin, I think. Best, jzb -- Joe Brockmeier | Principal Cloud Storage Analyst j...@redhat.com | http://community.redhat.com/ Twitter: @jzb | http://dissociatedpress.net/ -- Joe Brockmeier | Principal Cloud Storage Analyst j...@redhat.com | http://community.redhat.com/ Twitter: @jzb | http://dissociatedpress.net/ ___ infrastructure mailing list infrastructure@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/infrastructure
Re: Fedora-Xfce-armhfp-21-20140725-sda.raw.xz - Cubieboard 2
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Fri, 25 Jul 2014 14:23:46 -0400 Robert Moskowitz r...@htt-consult.com wrote: OK. Some more information. I should have read the known issues that video was not supported yet and not waste time when I forgot my console serial usb adapter. So I just built of 0725 and did a firstboot. It hung at: Fedora release 21 (Twenty One) Kernel 3.16.0-0.rc6.git1.1.fc21.armv7hl on an armv7l (ttyS0) [ 90.945170] Ebtables v2.0 registered [ 103.427868] cfg80211: Calling CRDA to update world regulatory domain [ 104.033676] cfg80211: World regulatory domain updated: [ 104.053602] cfg80211: (2402000 KHz - 2472000 KHz @ 4 KHz), (N/A, 2000 mBm), (N/A) [ 104.078213] cfg80211: (517 KHz - 525 KHz @ 16 KHz), (N/A, 2000 mBm), (N/A) [ 104.094960] cfg80211: (549 KHz - 573 KHz @ 16 KHz), (N/A, 2000 mBm), (0 s) [ 104.103304] cfg80211: (5735000 KHz - 5835000 KHz @ 8 KHz), (N/A, 2000 mBm), (N/A) [ 106.258769] eth0: device MAC address 6a:69:4a:ec:9a:81 [ 107.145200] IPv6: ADDRCONF(NETDEV_UP): eth0: link is not ready there was no prompting for root password, time zone or login user. So I built another Sd card with --norootpass you need to use the minimal image to get initial-setup running on the serial console. all the Graphical images run it in X Dennis -BEGIN PGP SIGNATURE- Version: GnuPG v2 iQIcBAEBAgAGBQJT0qlLAAoJEH7ltONmPFDRwNgP/3tcv3G08hIkDcMTQF1Wqaeg ZU1Hl5DdMAduOPpxuQvOm26V/3lFydiKWXVoz63iG4ib3Tb2fTlwflBvOoprXMwA ilO56NiQn4fft/eBJ5gLX9HOcNY3Zi9gWFZUtOL8A5op++7owC8VKXpjEypxVMJs Bkmabiy19ZU5BTX/WX3UwWmwzNM53mq+6xIdFbI3mxmLyZacYBDLEkVWzKKPB6fy 6YyP+dXaTFbJRIgnMgAq8iU+P9lLjuapbjNjaJDs7Kf+WgxegMZBIKATFA9nfdmP 5MsyjVL0mQEl/GIRuN7DuIUuSw1hv1LVBvp/KSs4f/b19gV2zl1OMxCmBdX7gGiN lv3Dov4pb0Gay4Hbi8mMNAtQd094cA9CARKdP6pu58tArBGe9v7aQeBM0PYteteW vVPuUklOh25vPsklAtwimvg07L6zWmugAC/CNUCQyju8FZAU5UWbIWtnaukKGP0N CcEyrp7zyQAbHS20Jb7ZnOJ5YXN/4aTUibVyuz7GL7Gm5h2tV/bE+vmq2VlUJNgt ppXr0QJ5sGai6lQA/CTETCazVyNZXTjLxc5HmJPh9OKesqR8HL/nt1rRj3JRLJhU HhbL7R64MTtEezKCzcKrhlzFr9jqkB6dGLbd914w5DffZ3s1Ir8bB71uv49irXq8 gPn1CPK88f2BlSToTrjK =ZPJG -END PGP SIGNATURE- -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: Schedule of package signing for F21?
On Wed, 23 Jul 2014 08:48:20 +0200 Miroslav Suchý msu...@redhat.com wrote: Looking at http://fedorapeople.org/groups/schedule/f-21/f-21-releng-tasks.html I could not guess from this document when packages for F21 will be signed. When it will happen? I'm asking because of https://bugzilla.redhat.com/show_bug.cgi?id=1119275#c3 We sign the packages every day, but until bodhi is enabled we can not guarantee that all packages will get signed. Dennis -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
update keys on fedoraproject.org
Hi all, per http://fedoraproject.org/wiki/Create_release_signing_key#Web_team_SOP I am sending this email to get the f21 and f22 gpg keys added to https://fedoraproject.org/keys the keys can be found at https://git.fedorahosted.org/cgit/fedora-repos.git/tree/?h=f21 Thanks Dennis -- websites mailing list websites@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/websites
Re: Make buildSRPMFromSCM faster?
On Sat, 19 Jul 2014 12:30:38 +0100 Richard W.M. Jones rjo...@redhat.com wrote: The first step of most Koji builds is buildSRPMFromSCM, where a .src.rpm file is built from the git repo. Currently this involves completely building a mock buildroot containing all the BuildRequires, and running `rpmbuild -bs'. This takes many minutes (especially when arm is chosen as a builder). It seems the reason for this is because the spec file has to be fully parsed in order to work out the Source lines. Since Source lines might depend on RPM macros which might depend on any BuildRequire'd package, every BR package must be installed in the mock root. `rpmbuild -bs' takes seconds because it just bundles all the Source files with the spec file into an SRPM. Is this really necessary? This is not at all true. we have a minimal buildroot that is installed for every single build, the buildroot packages are the same across all builds. there is no BuildRequires pulled in until the buildArch task Two shortcuts seem possible: (1) Limit the use of macros in Source lines, so that only a simple, standard, perhaps pre-cached buildroot can be used. (2) Perhaps uglier: Just build an SRPM that contains everything in dist-git + everything in the lookaside cache, and hope for the best ... This is what we do now. Dennis -- 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: Make buildSRPMFromSCM faster?
On Mon, 21 Jul 2014 13:58:49 -0500 Dennis Gilmore den...@ausil.us wrote: On Sat, 19 Jul 2014 12:30:38 +0100 Richard W.M. Jones rjo...@redhat.com wrote: The first step of most Koji builds is buildSRPMFromSCM, where a .src.rpm file is built from the git repo. Currently this involves completely building a mock buildroot containing all the BuildRequires, and running `rpmbuild -bs'. This takes many minutes (especially when arm is chosen as a builder). It seems the reason for this is because the spec file has to be fully parsed in order to work out the Source lines. Since Source lines might depend on RPM macros which might depend on any BuildRequire'd package, every BR package must be installed in the mock root. `rpmbuild -bs' takes seconds because it just bundles all the Source files with the spec file into an SRPM. Is this really necessary? This is not at all true. we have a minimal buildroot that is installed for every single build, the buildroot packages are the same across all builds. there is no BuildRequires pulled in until the buildArch task Two shortcuts seem possible: (1) Limit the use of macros in Source lines, so that only a simple, standard, perhaps pre-cached buildroot can be used. (2) Perhaps uglier: Just build an SRPM that contains everything in dist-git + everything in the lookaside cache, and hope for the best ... This is what we do now. Dennis we could make it faster by switching to a fedpkg wrapper that was just a shell script to get the sources. fedpkg has a lot of deps, we would make what needs installed smaller. Dennis -- 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: rpm is not signed
On Tue, 15 Jul 2014 11:42:00 +0200 poma pomidorabelis...@gmail.com wrote: yum update ... Package fedora-kickstarts-0.21.7-1.fc21.noarch.rpm is not signed I guess, it doesn't need bzz? Its known and expected, we can not guarantee that everything is signed until we enable bodhi for updates. Dennis -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: Wither Fedora 21 boot.iso?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Tue, 15 Jul 2014 12:58:54 -0500 Bruno Wolff III br...@wolff.to wrote: On Tue, Jul 15, 2014 at 19:50:59 +0200, poma pomidorabelis...@gmail.com wrote: After 21 gets released, due to the use of 'updates-testing', do we need to yum --releasever=21 distro-sync after yum-config-manager --disable updates-testing yum-config-manager --enable updates You can enable updates now if you want. There is an empty repo there so things will work, but slightly slower. You don't have to disable updates-testing after the release. If you are running with it enabled now, it's reasonable to keep it enabled after the release. updates and updates-testing are both enabled currently. we will disable updates-testing before making the final release. you should do a distro-sync once we push the zero day updates Dennis -BEGIN PGP SIGNATURE- Version: GnuPG v2 iQIcBAEBAgAGBQJTxZX2AAoJEH7ltONmPFDRPD4P+wZE18mmiFZlVeWRWGx9toJb zcyXWwMDnIm4NCVnRoKP9A4ly2Id7hMcCc1oXLTH4Tjd0AgSl5P4VqLL/ffH69tN ukSy9okfLLrG9+AkGQ6mCO9YHAyJKUfZlPi/gPWkwEPL5kbQ1FbUshA+2flrJFfq VMB9HVrU5/NHIeqpYT0kbZMGsK/dE4ytfzN7OgSBR/6I7thPcV4RIn8S7R3VkZeu Y67vUstieQ8La7i80v5oItwuZGxt0nA7gnLQ6bxtmtIZJR3a9q0dv4uPyVqwYLNU hSTHggXlmVtx040iDZp7KWTlwySb4dqABm8aC0FMpGVGdE3ZHOLrB5b35lyeE6aC iWTj1DSEsAQdUlecVbgGvWWfBwvIFxeyiJIPLm28LIkOVFX6J9JfYJmmbBHe0NcQ a88RILjTeL5EGavmXHI0iySJrHoiz+XMFZ2Bfdq3UcUhbTO9v2MW7vwDuHKTtg7P Mh3M4UhpG/cYkge6ObnLV76Iib3lEoh00LBVWoJfs20x9xyOOkUUnQ2VY6ESMotH Fo7o18wc+6I4LX+2Wfkfp1Loxvj3rZJFjfCYnrDwPO3hwFmnHj7S1RIliAlPtQFu yVwS1Xj/FJ8j0vYBT4dre3MXwV7BNutdigoJUQ/svrPDUYzwbR8DwhKq4BvORd0j tNDCZFcFqGYhywzg7+nl =0N6T -END PGP SIGNATURE- -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: [fedora-arm] Fedora Rawhide and Allwinner A10S
On Sun, 13 Jul 2014 10:12:45 +0100 Peter Robinson pbrobin...@gmail.com wrote: When it finished, I popped it out and re-inserted it so that it would mount the partitions. I read the instructions for the CubieTruck on the ARM Rawhide Installation page (https://fedoraproject.org/wiki/Architectures/ARM/Rawhide/Installation ). I looked around in the /usr/share/uboot directory, but didn't find a directory I thought was more appropriate. We currently only build a uboot for the CubieTruck as the AllWinner support isn't yet completely upstream. That will change in time and we should be rebasing to 2014.07 shortly but I'm not sure what the support is like in that release. last I looked it was the only device that had support land upstream. Dennis ___ arm mailing list arm@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/arm
Fedora 21 Mass Branching
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi All, Fedora 21 has been branched, please be sure to do a git pull --rebase to pick up the new branch, as an additional reminder rawhide/f22 has had inheritance cut off from previous releases, so this means that anything you do for f21 you also have to do in the master branch and do a build there. This is the same as we did for fedora 19 and 20. Dennis -BEGIN PGP SIGNATURE- Version: GnuPG v2 iQIcBAEBAgAGBQJTvN+zAAoJEH7ltONmPFDRBOAP/31mp+fzedIM0KMOuDvkgRRm /5NYjkWwwoR8ocFdGfSDsYPy/YPo5hJNnA41vtNTf6Sl2nZVRfniCiE15OXnwpfH FBV/fSqBODMnEi43q9hojVNE1abS3i9QLO966GaS5YexEcvRsd9PdVTtb20oU3qK dEFGChyXzD7H9HgaMN3cUBKBQisErwt7ZznNrPzxdGPJskXEf4R0Jcb3M7n9lJl3 GOH2mS93KTfty67/Kxqdq5WGJ0UeJL8lQJzfs61vgP8vnfFkI0Lojhr6uCuPIwoa vaLbE+7Z2Ky0J2/fNsMkmQzEnbTcUTEi0jTzEejrPcQSF2pKuQfWD5eBxai65V95 44eetg20Mir7s1NrJ3lkNgxwfeneNauRnTJpk8G24rr7f6fqA12TdvFvIqZLhB/o 0DFfHjme93kVtxndXy+Z9cqx2JViF83xc0l/4mcDed/T47hbDc0/gpfnyJdayi9X mwrWWLWqDo+uvwlMbJOPvIbfejDLZQ7PsBNFvZr/j2uiP0sqR33/ajJmEPyTB0/G Im0IJ2PQa1Em7Or7sCsJwF7gThXPfOvExEZ9gkG8cfDXdxQIcAo7CTmXz0J3fdY5 FFUenCy0BX0QrKWdQIQHhFiT2siKn5x/pG8k4C+vM/6iGlRoInAE4qrRojkOh4rH xIfMAdvlJkfp00FJwiob =MUNE -END PGP SIGNATURE- ___ devel-announce mailing list devel-annou...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel-announce -- 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: [PATCH 0/2] Allow rpkg to use custom source metadata file and format
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Wed, 2 Jul 2014 15:45:50 -0500 Pat Riehecky riehe...@fnal.gov wrote: On 07/02/2014 02:40 PM, Dennis Gilmore wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Wed, 2 Jul 2014 11:21:13 -0500 Pat Riehecky riehe...@fnal.gov wrote: On 07/02/2014 11:11 AM, Pat Riehecky wrote: From: Pat Riehecky riehe...@fnal.gov Over at the CentOS project they are looking into an rpkg based tool, but due to the hard coded filename for external sourecs, a lot of code is duplicated. The attached patch preserves the existing behavior, but allows a hook into the 'sources' function so that other metadata files can be consulted. The format of the url in the CentOS structure is also different. However, I've not (yet?) taken a stab at making that customizable. Pat Riehecky (2): Allow custom 'sources' metadata file Added optional 'valsep' for metadata files not seperated by ' ' src/pyrpkg/__init__.py |6 +++--- 1 files changed, 3 insertions(+), 3 deletions(-) For the custom url format, would a config entry or optional arg to Commands.sources be preferred? Pat what kind of custom url format are you looking at? the url format today is what koji needs. Dennis The 'sha summed source file(s)' for git.centos.org is hosted under the following pattern: https://git.centos.org/sources/packagename/branch/shasum Whereas rpkg's expects (from line 1489 of __init__.py): https://git.centos.org/sources/packagename/filename/shasum/filename For example, when using the default URL path rpkg attempts to download the following file: https://git.centos.org/sources/a2ps/SOURCES/a2ps-4.14.tar.gz/365abbbe4b7128bf70dad16d06e23c5701874852/SOURCES/a2ps-4.14.tar.gz The path I wish to set for rpkg to use is: https://git.centos.org/sources/a2ps/c7/365abbbe4b7128bf70dad16d06e23c5701874852 ewww, seriously eww. the tooling would need to rename the file it gets to the name in the spec file. this I think doesn't belong in rpkg, whatever tooling centos people come up with will have to replace rpkgs function with its own version. I would strongly advocate for centos to rethink how they are doing it and follow the standard convention. Sorry for not being clear earlier, No Problem Dennis -BEGIN PGP SIGNATURE- Version: GnuPG v2 iQIcBAEBAgAGBQJTtWWTAAoJEH7ltONmPFDRNFYQAIQwTDBnOyuYEzryzrP0sG4E ZJbYhQXoQmnSK3ImhdEGgj203HnSnyLLYFgGT+qFBqOBCV5zNA0bkMJK55JTjWw4 IDoV/x4JrYATnyxagVJdgtIEgQq5r05TSnK8sAemGcPTE4USs8aoMGwEz5HveRSW 9jYwhozlvl6KFd6thxVQZRWd0hN6bVnNguDtq4RKgsZeulhQrLqcIHkK1/jZNO3A Dn1wzZL1LSeeg6uJb0zMNPPCvVomh9nLFJW7yQXc6i+na+9AK718j/ssAYW3BwUG S8Cq5j3ZO1sG8+pZ6Kh/BI+di2qbEjnMFLD6g1k9N2pvkBxEv/nKp0SMLMIY3PhS UrewFQ+Hdc7yn/JDIeI4qLQ0s5pFqxvvL6ccLnMQyTLJlgDSjcbu4U5B7P5M6zSO 2RhlOJzgDzg7B4LQko9vyYT6IUOPVMC6duJkaESorEHB88W998o+YS7HpoegUrUO 02JpMwRVuNMjgZw4v3an5X7VPKSaJaQsagIJXhcZYUa+vUkMr4xHoUS4LbOyl1r8 KX1zipRFKTk0XinYm87IuS9qXq4dcNE/zhvq8/JMQYVLkuwv4Noofww4cWobcL6V 5wJKLprRrLTsWWGAQNyr+incpE4il11W/tZfHYkiS7kE+4sLkL9987e2nLnXtlHU sZEhjBaIAAndnYJBUv6M =ZAdf -END PGP SIGNATURE- -- buildsys mailing list buildsys@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/buildsys
Re: [fedora-arm] RPM Bug in Rawhide - Resolved with 'rpm-4.11.90-0.git12844.4.fc21'
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Wed, 2 Jul 2014 14:00:48 -0400 (EDT) Paul Whalen pwha...@redhat.com wrote: Good afternoon, For those using rawhide there is a bug in rpm which will prevent further updates (arch detection will be 'arm' vs 'armhfp'). This can be resolved by installing the latest 'rpm-4.11.90-0.git12844.4.fc21'[1]. Download the needed rpm's and force the installation: rpm -Uvh --force --ignorearch rpm*.rpm you should not need to force it but you will need to tell rpm to ignore the arch Dennis Paul [1] - http://koji.fedoraproject.org/koji/buildinfo?buildID=541544 ___ arm mailing list arm@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/arm -BEGIN PGP SIGNATURE- Version: GnuPG v2 iQIcBAEBAgAGBQJTtGJ6AAoJEH7ltONmPFDRvLoQANHKQR3ZCPcU0/U9q82P+pwH q846b/N4oWrOrNh07dUzCXvCW+kTGMI7meve63Ip7Yd1UhEZkV0QnoD8Ksz1q0Jv EyQux6Qk+X0WUThspGk7Fj6DuMg0iFncAEJTG17zT5Dpgy9Uph5ad22LOdIMqgaD SnzFS8BDmHzvam2xbLEmAkmCcwRn7HvSzAe5zrP8U+Q5ncrpbkPrmy8odAH/D/oh V6t+b59h3bsJWkjgrVe06q4rRQRt5JgmxI+iP5tDQgq/F6UUVDHhIIMPzitjxmR7 AgMCgiC0tExDU/N6vRbncWn5twuY4fKUdqjOOjrj0ESC2piJ2CB85FOm4jIArZ8Q 8+YdCkE0ADh67qsoHWLSmZK+6j1OJxYXYXs4xOujFE12XUOu4EZU1qD5AnL89Spm IEMWAsUYIRmxjww6R31ZUQVGG6/pF9I35OZJkNc50DhrmukZUz/Sn+8t4aQfn3Jp AeGWQIMwEQHMHZicB4dt+kz3tQE2A6sf2AghLfDuubJr5zYVv9Nckx0SZYhdEpyw felMz4s+YnIsZHM2vgVwgN+SkYdrmQb3YVlhHZ8YtrjnM+ejG4XSi7HgYPnGPcET 67KAgsdS4qjzvNlkVNZ3QdQ6kOIN8Ys/Ai5g/pfHIYQMZxX+wpKmFZdUPCP3U4vU s50zbO1Y+HGKRfXrVcxK =vR+E -END PGP SIGNATURE- ___ arm mailing list arm@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/arm
Re: delta rpms - can we turn them off
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Fri, 27 Jun 2014 11:35:20 -0600 Kevin Fenzi ke...@scrye.com wrote: On Fri, 27 Jun 2014 19:23:04 +0200 drago01 drag...@gmail.com wrote: Why? My understanding of the process as it exists: Download drpm. Take drpm contents + old package files installed locally that were not changed and create updated rpm. yum/dnf hands off this updated new version to rpm as normal. If they didn't create the orig rpm, it would require rpm to handle drpms differently and apply them somehow on existing files and update rpmdb. If the drpms were signed, only those parts of the package that changed in that drpm could be verified, the rest of the ones from the filesystem would just be whatever was on the filesystem. additionally the drpms are created at repo creation time and are never available to the signing process. we would have to redo and rethink how we make deltarpms. which would open up a massive can of worms that would likely result in much wasted effort. Dennis -BEGIN PGP SIGNATURE- Version: GnuPG v2 iQIcBAEBAgAGBQJTss+aAAoJEH7ltONmPFDRW4wP/RmPoKSW46VImnYuDdI+KPaO PQp/Mg9InbsuRr6Re+o2pk+fOlxZoDY0P8G9xuzuoi9j8CMh+nIENx7/GEQa3wh/ D8YpQRLZtNFnNRFB6aJm9hgWrjTtBG5YB+xc+ROXo65s/vqhYKbjCoxgl+u4ZL/l jwW7Z0pgtoAzxPrceLIjn5MrwTGin7oVcsHMnghP8+/svM2al9x1M6Jx1kzO0NGy h3L1ClkUXCM2lVsuib79fETMAICF40EGZQPZ5/RErJ5FYmu3ldif7crt/qydtA9u 8XaN6xIdc2EW7L2aqy2MYuKzxwwfpHcXg/W6WCjS2/Zd+UJMVpg8ZHIv4wOR+Eww LXfz2RHThn0siLti2WenH6pm+UagipvSGJesoVu/igdgoa9UCOtH/w+MePO1OoIv QcvtCzQ9zmDdzJoA/bsbwo9QIThtlCXCU7AT6JAbOVwZlkXvatjpUCjjmo5gWyuD XNMEIvvEkna975+TU8Y4atkkSRxIt3tOFdkzbV4nrS0OPclP9TSpsUt4zsJecosl +mT2ca2JihJfJkJXe0e1k+QZPaAon+VYHMGq6n/+T8zwjH2277ct3pn9jE2iUT62 WvubEOw6Q8jrEiBBEgfgG6uyucW49Q0jqSnyrOosikrfvwH4Inp3viO0zj7bB+yA bpktGNj51E6Qk8HkWzkX =QpUV -END PGP SIGNATURE- -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: delta rpms - can we turn them off
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Sun, 29 Jun 2014 20:01:04 -0500 Jon jdisn...@gmail.com wrote: On Sun, Jun 29, 2014 at 7:42 PM, Stephen John Smoogen smo...@gmail.com wrote: [snip] Personally I would just say don't make delta-rpms for i386 and arm or just have deltarpm=1 on those architectures by default. Or all architectures even. This should, in my opinion, be disabled by default. The default-off setting should be self-documented in the config, so that it could be easily found and toggled on/off. While I generally disable deltarpm locally, you need to look at teh whole picture. There are many parts of the world that generally have caps on downloads. Australia is an example of such a country, using deltarpms there can save you a ton of bandwidth that goes against your download cap. now some ISP's run mirrors and if you hit their mirror it doesnt count against your cap. but thats not always a given. The sane default is what we have today. This should please the masochists, or people with very slow internet. Meanwhile, we can bikeshed on how to optimise the feature. Eventually somebody will make the changes that cause DRPMs to suck slightly less. At that future time we can reevaluate if we rewards are worth the aggravations. in the initial use case laid out that started this thread the user should be using ansible or puppet or something for config management. and then it is a trivial thing to disable deltarpm. Dennis -BEGIN PGP SIGNATURE- Version: GnuPG v2 iQIcBAEBAgAGBQJTstElAAoJEH7ltONmPFDRWlAP/1fzM9cjzrQqS7Bazpe5LWD3 hy+LNbLEjACuUHVtAvxfCqHE14FzuSG9Th7KVsRfQeCIQpztOkLN4pHoWytTPv3V aj8pjnaRK719kV89g2CYQtP9ZIRmHEVJqrw+DOXgyu17H1D9+7RZdw6qULwQheT9 +uWy72qLGGZw7+l2IzPKFGoGyoPQkw1esPC9IDoZyhm1LckBwBYTs+9NMHpmiwl9 iVf/pRENOXG7uLaiGZI7B/Vll3FVbLBAcjLze1tPjyZSvRsdJq8shQXBIgeitlEm dKsfNg+9iOANRBIQJaM/dCODFRJPr0uMZlB8SoxJy+LOtQYyOrVCEKt0u2LEpAwF XPDMt8wOQTiUIyWXteGDbPbsFqpc44cvrhgko4mVVfZDjFzadr+WS3ZWasNlqSZW 9vuvNaqMGZTRitoFXZGSV4tvPrK2FZ/uEgEW8PbwEBACJk5fkBnJW4dAxei7AsvC YSRkiJztz3zzcGeXRQtq1GHQPaWAEEkPeGerjnJEFyXq3ZQaRV+L6ej0CS0wPnJh Ni1d2zL0iXdiAlN0BrIEttoKsECc9FEShHWsYkeKdmHjCMGom1E0gqFjVR2wqQkX WLH7dPcBT95/OOZnmMg2Ii9PrBwp7YXxtNM1wYB59QVSZLnfYO0cMwfmj7cSmT3G ky69yJoWC5CbZGpEf+qi =ZH83 -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
Schedule for Wednesday's FESCo Meeting (2014-06-25)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Following is the list of topics that will be discussed in the FESCo meeting Wednesday at 17:00UTC in #fedora-meeting on irc.freenode.net. To convert UTC to your local time, take a look at http://fedoraproject.org/wiki/UTCHowto or run: date -d '2014-06-25 17:00 UTC' Links to all tickets below can be found at: https://fedorahosted.org/fesco/report/9 = Followups = #topic #1310 Reconsidering rpcbind's exception allowing it to start by default .fesco 1310 https://fedorahosted.org/fesco/ticket/1310 #topic #1311 Disable syscall auditing by default .fesco 1311 https://fedorahosted.org/fesco/ticket/1311 #topic #1312 F22 System Wide Change: Replace Yum With DNF - http://fedoraproject.org/wiki/Changes/ReplaceYumWithDNF .fesco 1312 https://fedorahosted.org/fesco/ticket/1312 = Open Floor = For more complete details, please visit each individual ticket. The report of the agenda items can be found at https://fedorahosted.org/fesco/report/9 If you would like to add something to this agenda, you can reply to this e-mail, file a new ticket at https://fedorahosted.org/fesco, e-mail me directly, or bring it up at the end of the meeting, during the open floor topic. Note that added topics may be deferred until the following meeting. -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.22 (GNU/Linux) iQIcBAEBAgAGBQJTqujXAAoJEH7ltONmPFDRbLYP/iNvEnSq4NFT8Xb1rfTpF5lY ZlmzGZOt89d893Ukog98QlZScKWcvRyFOoK6973ZPeiw7uITic6lJsW/gbAaI+I9 M91oTkyKuxG2BgG7QJTYE7+mxFhMalqsGQl7iR04K8dcheLLAlPln1p06ZhVaNtf A9GeEUCVR2KgMxvfTI8bIif/hf+lFIlK8T9vZ6LOh3eGTmMnc5mSl8ep8d/s0R+A hbjWXejNQtio+gy8UlizY3v1GSQj4nkQbtr+a5FGQwSLBxVoQu0mar/FUBL6HDiU WwtHAUb7CMxmn4qrkXHGQNv7OSwOKw9Tka1R3A/V1MMNMDskqga8vXUxFF7zOYoC O+KNMj3AHj/pSt5sID8e6NezfZcIQXKdVhck+dr6VkMs2BV+FaLl8N/qtKY+iWDJ 1j2FicbwQCmPLR3Hg/+24v+i9DF5FbbkHSqLH9c8gb0OJ+Gw07zgUe7P0vfXFrX+ d01eJFyC1txv/XPHZkA77uWqp3A8pnbYnweLR1LFksiD7PphRja3pX4UXG6M2jbs reSylrQDh9iK+hBucCjYcikysYAnDFNTSpnheN9LHJiEEv4llLZe4tVjdrmRbNpi GigD9dHYtiEVGoyminSDkJyu3fO05abLrAMbSsXE1vHlfoGyUH3eW8/r5DrWxZCx UyNDxAOpDr+b5G47pYWv =qCfV -END PGP SIGNATURE- -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Fedora @ Google Cloud
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Sun, 22 Jun 2014 05:05:36 -0700 Colin Walters walt...@verbum.org wrote: On Wed, Jun 18, 2014, at 01:49 PM, Dennis Gilmore wrote: The issue is we are trying to build one image to run in all clouds, so cloud provider specific tools are out. I faced a similar problem with the images I am generating with ostree, and what I ended up doing was producing a base image, and then postprocessing it via libguestfs to enable/disable services. So if we did decide to ship the GCE agent software, it would be possible to produce one cloud image with both cloud-init and GCE agent, with *both disabled by default* (note requires changing cloud-init package to stop auto-enabling itself) Then the script boils down to: $ cp fedora-cloud.qcow2 fedora-cloud-standard.qcow2 $ guestmount /path/to/fedora-cloud-standard.qcow2 /mnt $ systemctl --root=/mnt/ enable cloud-init.service $ fusermount -u /mnt $ cp fedora-cloud.qcow2 fedora-cloud-google.qcow2 $ guestmount /path/to/fedora-cloud-google.qcow2 /mnt $ systemctl --root=/mnt/ enable google-daemon.service $ fusermount -u /mnt Each takes literally just a second or two to execute and can be easily scripted on a rel-eng server (though I guess you'd want to wrap mock around it). It may not take long but its not an option. for a few reasons. 1) the image is intended to be just ran without tweaks 2) we publish the image on the mirrors and anyone using them will have to tweak it before using. which breaks at least openstack. you can point it at a mirror and it will pull in the cloud image and it just works. 3) it means having two systems installed in the image along with any unique deps. We are trying to make the base as small and unbloated as possible. extend the functionality of cloud-init if you feel its useful. Ideally its something that can work in all providers. All of the above said, I agree and would prefer investing in cloud-init, even at the cost of the image deviating a bit from the GCE standard. Any other opinions? I strongly believe we need one way to do it. now having a hook to say start an extra service when it detects its being run in GCE i wouldn't object to. assuming that service is not huge. Dennis -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.22 (GNU/Linux) iQIcBAEBAgAGBQJTpyAOAAoJEH7ltONmPFDRyWAP/joh7p3T+NZJqVqCnoVFx3M4 4FTplMOMGveNgv8xmkuUKm0gbyUQoPm059ExBowKAgE/68oa/ynZURL4cvB7Dc45 NAUwWGivdKZzWpJ9d5JS4KGy4RcrK0rBJwY09OxEmmFtLJ2IbiJA74NVZy9vs0aM RZYkZJ/8QCeLSU9nLYSv4Hls/JhuyLbj2qeIrsjSiwknCzXEmeaRGXRYONp1Kuk4 3XlJifbgeRawymdq/ZxqXgWHVlANfAgmPtFQys9yIy/X3tZClI55jUFBZLLQ8wbX zcp8tnqfjm2h1mkDS+aXRccrr0RKdYVzt7X9O95FLHteYFtNK4LZ3sqA41UY8XRu zO+XAJprOEEqof/ubsbpqjoDEIzPgFBdA+2u+/UoLQ+i/18xDTgP92COD+PnNftF WMasDPc7NaFh1ZLLMlv8ffeQ5uAkd7kilz4tmSkseEle4VfwCJfNC3fQ4LhlKfOV pm9fhVl157qFYbz92l2d/pAopam37T+A8dBSqDgqMoWGXI5287Jt3Bm3HyDuTCqp Zh7AfpBkxXK54p7aysoR+bHjXkAbuZ0KmtgqtxLzLyqQErEskziQeb5OluBK/Psz xQdwtPcvjtpl6Eejj5QIMx/XSNJOFbGimad2x4FJXp0x1kHQ/QfGXb+qEzM0pbtj Jm7y30MWVr0q5YJ6B/37 =Usht -END PGP SIGNATURE- ___ cloud mailing list cloud@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/cloud Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: repodata - xz
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Fri, 20 Jun 2014 03:19:55 +0200 poma pomidorabelis...@gmail.com wrote: f20: *filelists.sqlite.bz2 3.5 M *filelists.xml.gz 3.3 M *primary.sqlite.bz22.7 M *primary.xml.gz1.3 M *other.sqlite.bz2 1.3 M *other.xml.gz964 K *Fedora-20-comps.xml 906 K *Fedora-20-comps.xml.gz 210 K repomd.xml 3.6 K rawhide: *filelists.xml.gz 28 M - xz? *filelists.sqlite.xz 25 M *primary.sqlite.xz17 M *primary.xml.gz 10 M - xz? *other.sqlite.xz 7.5 M *other.xml.gz 5.8 M - xz? *prestodelta.xml.xz2.9 M *comps-rawhide.xml 1.6 M - ? *comps-rawhide.xml.xz230 K repomd.xml 4.2 K - xz? Why aren't all compressed with the xz, in rawhide? Why two *comps* with the same original checksums? because thats how createrepo works. the gzipped files are not ones you download. yum and dnf use the sqlite files. Dennis -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.22 (GNU/Linux) iQIcBAEBAgAGBQJTpDrMAAoJEH7ltONmPFDRtsEP/3aRbAhcYMLhHemlAIE/7nRT 1kp6PH4TfWdZxsBBCEK1Ko9lFC254oDr+hpFm7/dFXAXrXPbMHMOTunfI9iO52G2 he2wrJxg8ho6SOpudnI0D7LewGgIQYHV6lGkop+hExRQoaBCGSw7pOIE9b87t4iI dD4peB7VBUAA7BY/vyz87fLjxgWFM91DTnL8UTnIPoCcbr+BPlE/BQDUtGeRGyLH hKJTnrbQg8XpDN11xGYAm9tRAtLpAQhY0tm7jgjgRJ+s/3Io4KN2Xz4HCTyTFtSw rFvOx0T5+ryl7dJ/x737OaPC2aqcQQ0pr7bTwQSvhV2b4cvaT+00sKjJUMgZR/WM /jrRju2882tR9YeBFql1E7oMHbOV+Yudt5XL72mwc/6GCLHSa5ZgkILdgiN5K36s 3jfkB4P8tRtUkZIxhE+6owNuWwE30eAhEY/EKWo+zK7FhrbOqxZTW/1OXhgHHs8k q545kyX5sU4oC1o1SAyxkO9ZHPdEa9qlAl62vrkO5MKurzqbYtFuDCy9RhqX2Toh rSOfbliN27HVd2b8w5/khAu7n071x2F5qzh8B09+WrJqwObO5lV9crKxDmkaaxg7 iA/1pM3sEWbnyPPbggDCkjhBYk1Zvq1zD2bXK5yWf96mQ0+1Xj7YE4JrVf5TpmpR TW2Gug5u1yY9qNgtw3zs =cXTi -END PGP SIGNATURE- -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: DNF: why does it refresh metadata all the time
In testing dnf on rawhide I nearly always do dnf clean metadata dnf update purely because I found most of the time dnfs metadata was out of date. To me dnf fetching the metadata behind the scenes just doesn't work right. But I'm not sure that me or rawhide fits into the experience dnf is trying to give. Dennis On June 19, 2014 1:01:03 PM CDT, Reindl Harald h.rei...@thelounge.net wrote: Am 19.06.2014 19:57, schrieb Jon: On Thu, Jun 19, 2014 at 12:46 PM, Reindl Harald h.rei...@thelounge.net wrote: that's not the question the question is why such traffic wasting *defaults* I might be way off base here, but in an effort to make DNF go faster compared to YUM, the idea was made to have it pre-fetch metadata ahead of time, so when DNF command is finally run by the user, it skips a costly step... and *seems* faster. Although I believe YUM could do that also with a simple crontab. It is actually a nice feature of DNF or YUM, and I would suggest you embrace. Also, I'm skeptical there is very much network traffic, unless it downloads file lists by default? It's arguable if file lists should be pre-fetched, to do things like determine what package provides something... I would say no, but bandwidth is cheap. So there really is a benefit, and it mostly leads to continuously update metadata if *that* is what is supposed to make DNF faster it's just a lie if i am really interested in updates now i do yum clean metadata yum upgrade for many years simply because you don't know how accurat you metadata are and *no* traffic is not cheap everywhere, by far not -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct -- Sent from my Android device with K-9 Mail. Please excuse my brevity.-- 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: [PATCH 0/2] Fixes for non-pci platform devices
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Mon, 16 Jun 2014 14:13:15 -0400 Rob Clark robdcl...@gmail.com wrote: This makes it possible for a DDX to implement platformProbe() for non- pci devices. The second patch implements a way that the DDX can detect whether or not it is safe to claim a device in platformProbe(), so as to work-around the issue with an unpatched xserver. The patches in the patchset are against master. I also have branches for 1.15 and 1.14: git://github.com/robclark/xserver.git platform-dev-fixes git://github.com/robclark/xserver.git platform-dev-fixes-1.15 git://github.com/robclark/xserver.git platform-dev-fixes-1.14 Rob Clark (2): platform: support non-pci platform devices add SERVER_SUPPORTS_NON_PCI_PLATFORM_DEVS hw/xfree86/common/xf86Init.c| 10 +- hw/xfree86/common/xf86platformBus.c | 65 ++--- hw/xfree86/common/xf86str.h | 1 + 3 files changed, 71 insertions(+), 5 deletions(-) Series: Tested-by Dennis Gilmore den...@ausil.us These are needed to allow X to just work on arm platforms for Fedora. Other distros will have the same issue with X not starting without a config snippet forcing fbdev or another driver. Dennis -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.22 (GNU/Linux) iQIcBAEBAgAGBQJTo2XhAAoJEH7ltONmPFDRrKkP/15QQ1qHPm14DU1dQbHIZjQT IM040CDZ51obvQt98BIiwpw7MJGMb+FqwSB6z3pk31lEPapSbHbM0VT9basRpsb9 sMSfcYjMJovDhJ4vwIx7dQK8ztEcNtx4VVR0QPtW0bmy0+VBnq4xWZqMmHU/AAMS w/cJHAO+1bIaPa+Abe/uKSQwgK/OmjQa5FHAudrWZWe+5qe+KlWlQA+eK6GxUfrm FLNoFrIZQjRFNdbRUlp83l2TAod0nDfuKAPTxLIq9VQ4h8aVZFp2oyRtqD4YwpC8 ja8NSxuQy0GZNHaXaZ++Z4OsSIzxx1u8wGKuXGjFoaTNF/YkUuReROD70Hyisrzv BpM7yZjYMLqokFah2a0YvSc7IafEwBggqUuF7M/zbyumMlZ4RNxuOj0n3g7YBDLm szUao0FD++NNEnNSVkwlXIKUwgBdscDaOXLcar6/R6gOqEy+TvpLcMcOi/7Sdcxw l65zwfgr0XiufMotAMVTb0ir28DRekpUmhpN/aHKD0RxfX+itxLioH6Qou/h/Dq4 U89fZjZ6PcqJKHHwDExMVBfneIQ9SmVHMbGOL7v6+ESnt4Ea2CibDAI/VneFrZjT 20vKNkET+fvkQQbofnyKzpXDJMDJTXqXX1qWPYUiv376ZnNUlvNLcRQ201gKis5M At6KE+IBtGLDAb3z27w1 =8c5e -END PGP SIGNATURE- ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
Re: Fedora @ Google Cloud
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Wed, 18 Jun 2014 13:20:05 -0700 Filipe Brandenburger filbran...@google.com wrote: Hi Renich, I'd like to volunteer with this project of building an official Fedora image for GCE. Right now I have an image that I use for myself, I built it using appliance-creator and started with Vaidas' kickstarts, but I replaced cloud-init with the Google packages you mention below. The issue is we are trying to build one image to run in all clouds, so cloud provider specific tools are out. extend the functionality of cloud-init if you feel its useful. Ideally its something that can work in all providers. Dennis On Tue, Jun 17, 2014 at 5:09 PM, Renich Bon Ciric ren...@woralelandia.com wrote: I wonder about the services: https://github.com/GoogleCloudPlatform/compute-image-packages These are used for different purposes: - Google API connection - User creation/deletion - HHD live mounting/unmounting - SSH Key CRUD - etc. So I like the idea of using cloud-init but the problem is that it doesn't give us the same integrations with tools like gcutil (e.g. gcutil ssh cloud-host does not work since it expects an user account with your name instead of fedora, the Google packages will also manage user accounts and SSH keys after the VM is up.) I built the packages from the GitHub sources (I wrote a small specfile for them), the 1.1.3 release is not enough for Fedora 20 since it doesn't have systemd support, but trunk head does have support, so 1.1.4 should be enough when it gets released. I'd be willing to become a package maintainer for Fedora packages for these GCE tools. Should I submit builds for these packages (more specifically, google-compute-daemon, google-startup-scripts and gcimagebundle)? Or is someone else already planning to do that? There was also the DHCP issue mentioned earlier. I contributed a patch for that bug that was already released in Fedora 20. My last test image build didn't have to include a custom dhclient anymore, so that's good news! https://admin.fedoraproject.org/updates/FEDORA-2014-7468/dhcp-4.2.6-5.fc20 Let me know how I could help, I'd really like to get involved and help to get an official Fedora image in GCE. Cheers! Filipe DISCLAIMER: Google is my employer, though I'm not directly involved in GCE. My contributions here are mainly as a Fedora enthusiast and volunteer. My involvement does not imply official support by Google. ___ cloud mailing list cloud@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/cloud Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.22 (GNU/Linux) iQIcBAEBAgAGBQJToftSAAoJEH7ltONmPFDRhWkP/1U1dSh1Bg8nb/ElPMG0hK8D vwy5rzgQupgowQjseMMCtc05carfkkJn4BuacI5EnVaWEVCr9f3dV+tqXBK86pGD awrfhF2dDgp4slL99wAtrR/1neDge6UjU/pxJlmk/xzba4AYiy8eQCQjkUiZB3oU ZC7BbCmSfvkXAT74vJoYLOhAmkfHB7l2ntnzmYZN2Q8ylxobpFugKq49Lf6UZ9+1 xkOqFEybanZapwL7J6P3MWaNnKyxTEt6m4kvMCjqTaYwLzXFNRt27fQp711LwU9p IaIdVOGibAixUz6WM/BbJyTkR+k2jEGB88Z9zmghYapjiuc1unswJtGOPYFdBrDN 7St8+oScVDGDTIn9L74BNKCLerVv4K/QjjOFJY5SXMPtddAlHQh4jdsS8jUUT7DB 2rVBwc3du1585E2ICKr6DkvtFcGT3HCywanNwwVULAnHlSttaUiFTgL1mvaHsO82 ZdahXBRZM7LSh3UjlvWBDB4C0aLVdN9zE4NjUfBX8kCFoii1bGvfIFUXj6RQ9V+e V2jdvKLJQWm+1NlETvFlDwrjMTRPejKKeVoDJFElmX6Hcw1TMqoYE3END6aNRbUl 7nZHJq/W7eN16Zo8Bq5dqLjCVvXJD7jJrwAFGbgqJM504Vr9Rx4FujluBDClhE5Z NXlQReRcgm2O/uiTlvsJ =5i0b -END PGP SIGNATURE- ___ cloud mailing list cloud@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/cloud Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Proposal: time to set up the fedora-release-{cloud,workstation,server} subpackages
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Wed, 18 Jun 2014 16:15:03 -0400
Matthew Miller mat...@fedoraproject.org wrote:
We talked about this before, but I think now it's getting really
close to the time when we _need_ it. See
https://bugzilla.redhat.com/show_bug.cgi?id=1110764... as Dennis
says, we have not yet decided how to differentiate the different
Fedora products.
I suggest that we have fedora-release-{workstation,server,cloud}
packages. I had originally suggested these as subpackages of
fedora-release, but I think that it might actually be better to have
them be separate packages, so they can be maintained and released
individually.
These packages could have dependencies on other packages which are
essential to that product's identity (like ye olde dreaded
redhat-lsb, I suppose), and could either contain systemd presets
appropriate for that product -- or perhaps better, could depend on
another (for example) fedora-presets-server package.
Aslo, each workgroup should be able to set what services are started
in those presets rather than needing a FESCo exception (because
that's part of the point of the different WGs, after all).
Right now, all of the packages are drawing from the same repos, but
this would also provide an avenue for doing that differently in the
future if we so choose.
I also suggest that /etc/os-release be switched using the alternatives
system (http://fedoraproject.org/wiki/Packaging:Alternatives), with
the variant in either the VERSION field (VERSION=21 (Cloud)) or a
new os-release field which we would propose -- probably VARIANT.
I suppose /etc/issue and /etc/issue.net would also be candidates for
alternatives.
Comments? Missing pieces? Better ways to do it? Volunteers to
implement?
I will handle it, geenric-release is already a mess from things being
done differently to fedora-release. we need things to be done
consistently so they should all be done in one place.
Dennis
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.22 (GNU/Linux)
iQIcBAEBAgAGBQJToie+AAoJEH7ltONmPFDRRrIQAKzCKm9CUNJdlTfANvq8nAJB
iEGkt06M29Gd9Z7F7k8TfFOImTc9Nl4cFvaMEdp/buUDHqWNniD7MMUbtMs2O/UT
8KZgDOgrHL336luY0A5NkiL4VFiN07SzYqj2XO5g2Q+ADwYfljNVqAiLOEbI7C3w
84umwJMhH6fq6LoQ8A78knZlx+UxGCSS5IEOpoYuMtHDBHCz/rPepwLCQh+w6LyP
76T4LXTgUX3XiHWpA31hXkKnfGVYPy6r2etLUflmk4r2mN5tlAyOYWI0ChxbYRKR
Milu2pKhT/LAEqROySK/pIqEkj19YzK8IEQLLXf07lPGFKAx2OTK4MpYBulJ4Gxn
SJ/J3ND9oQTcCnqOLqlS26x+Z5vOkmAgXHV3tzKs44HN+SfyMS2DHfAJfx7z1HKz
HWEIPXT3VwszGMv/ifzSJIScVyRwwGII16ZpKw9F50CzmiwJpFGtNR6wjicUjsuP
Fgkf5RMhfEbl5/3IJ9TOWH4aJ8o6aPLfZYBwN+xWyQcnnCiKfJQfwB10o60sCk9T
q62zMyrMGANebb7gaFoT16U0GAkq1gMd0JECR95Sbk4DKw2+8+FvqDw9E1RJq72/
vpbCknqYTdoBmWTvv00XOHJV1ixhrig03o5dwMlPC2EU+J8YHXVW43DUiFfpd/9p
+6DMLcrhBTkOUVcOdw2y
=CC8X
-END PGP SIGNATURE-
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Proposal: time to set up the fedora-release-{cloud, workstation, server} subpackages
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Wed, 18 Jun 2014 16:55:02 -0500
Jon jdisn...@gmail.com wrote:
On Wed, Jun 18, 2014 at 3:15 PM, Matthew Miller
mat...@fedoraproject.org wrote:
We talked about this before, but I think now it's getting really
close to the time when we _need_ it. See
https://bugzilla.redhat.com/show_bug.cgi?id=1110764... as Dennis
says, we have not yet decided how to differentiate the different
Fedora products.
I suggest that we have fedora-release-{workstation,server,cloud}
packages. I had originally suggested these as subpackages of
fedora-release, but I think that it might actually be better to
have them be separate packages, so they can be maintained and
released individually.
Separate packages please, we want to keep the thrash/churn on a
release packages low.
I actually prefer a single package. if its not we will at the least
need to look at making a separate repos packages. as thats something we
do not want to risk copy paste errors etc.
These packages could have dependencies on other packages which are
essential to that product's identity (like ye olde dreaded
redhat-lsb, I suppose), and could either contain systemd presets
appropriate for that product -- or perhaps better, could depend on
another (for example) fedora-presets-server package.
Same as above, keep the systemd preset files out of the release
package, but feel free to add whatever requirements make sense.
Aslo, each workgroup should be able to set what services are
started in those presets rather than needing a FESCo exception
(because that's part of the point of the different WGs, after all).
Right now, all of the packages are drawing from the same repos, but
this would also provide an avenue for doing that differently in the
future if we so choose.
I also suggest that /etc/os-release be switched using the
alternatives system
(http://fedoraproject.org/wiki/Packaging:Alternatives), with the
variant in either the VERSION field (VERSION=21 (Cloud)) or a new
os-release field which we would propose -- probably VARIANT.
I suppose it's better than making server, workstation or whatever
mutually exclusive.
Would /etc/os-release -- /etc/os-release-{workstation,server,cloud}
eww, I honestly don't think alternatives is appropriate here.
I suppose /etc/issue and /etc/issue.net would also be candidates for
alternatives.
Perhaps, but /etc/issue.* files are things the sysadmin should be
managing, so IMHO be left alone.
(Perhaps I'm not fully appreciating the implications)
Dennis
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.22 (GNU/Linux)
iQIcBAEBAgAGBQJToirMAAoJEH7ltONmPFDR7dUQAM5x42QxpYamwGXAkYsKiEPv
uyBOazYzm9ZtbMiAdJjxfwj8iQdSnOPJr9+EoNSG8IFpwqrlcVP7m7raHq8a6Puz
n0R4nXfeiaeGuGAVX2I33drws1DFViGPyXViSZynugKJHQsoMw4qzi9hqxwT1Dcd
0l2gyZP6vphBP/PBTjBjCOX1Pz1Q+ys6wETUZL3Z/0ooCqQuOH8WyLvVF1C5O0EZ
lyhF+JzJJux1l1k73GSl52eO0wKal29e8tTGj1qrY8GVg8G+BBlE2OVTedTBrnrt
k+imU993e03r5RBXR5jwYuxUFCl7+yM93nMBY03kw2DzgRUtzJRpNf+7MLyxrDr/
c0tU6VMj8wuElXbl3j90aVisG6KzmJSgjqaiotxsNokTTNT1c7OIFu/yhZj5Ol0A
RCScJkpwJR7Bpq7nM44rc2426eUXEgK2jCSbTFBGNHA4z+FZE1nxixeNp4na0WRV
/M5c6bfjN2nBraGgkDY1sgOVXHJzSqYqx5skQRLtmXkuMz5k6Ix5zI0UZl9QwSzX
hCVNliRCvi+1a/qlrx40ohVgfhsWkNNXlMl1FG+uy1gLLYZCkEHhegVB/n84H01N
P6OArFmyvuGxwty6psPZ+4dQhkWOpBOydGCTyaCm2ZqUOfEhyv+I3Cgy8UwJgM/f
ulmpH62YYcfMuO0kJe8z
=QQUV
-END PGP SIGNATURE-
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Fedora @ Google Cloud
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Mon, 16 Jun 2014 23:26:19 -0500 Renich Bon Ciric ren...@woralelandia.com wrote: On Mon, Jun 16, 2014 at 10:05 AM, Dennis Gilmore den...@ausil.us wrote: we build all images for Fedora in koji using imagefactory/oz, your best bet is to take one of the nightly images and upload and see what's broken. note, there is a itern working on an uploading service to upload to the different providers. we also have a ticket open to gather all the accounts we need to create for providing images to all the different providers, this is so we can get a definite sign off from Legal on the agreements on uploading. In the end if we do not get legals okay for the accounts we can not make the accounts and provide images. Well, as far as it's working goes, my image works fine. The thing is to adhere to their recommendations and stuff. some are kind of questionable. For example, they suggest automatic updates. Another thing is get your firewall down; since they provide their own implementation. Then, there's the daemon and init scripts they provide, which are not packaged (as RPM) and should be, IMHO. # recommendations https://developers.google.com/compute/docs/images#buildingimage Another thing is that they forbid root login and ask it to be locked. But they like passwordless sudo; which brings no alternate benefit other than easier audit as they said; which is irrelevant if you get hacked. I'd like to know if we're on to discuss this or just adhere to their recommendations. they bring some benefits... most of them. we ship our images with root locked. cloud-init sets up a fedora user with sudo perms. to my displeasure we did disable the firewall in f20. cloud-init is fedora's tool for configuringa ccess to cloud guests and is a drop in replacement for googles versions. I think our existing images should be in compliance and should work, you could try uploading one and seeing what happens Dennis -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.22 (GNU/Linux) iQIcBAEBAgAGBQJToJZwAAoJEH7ltONmPFDRxQ0P/1INY/xhZ20+ft0ea2JeevTr oe4rwGwnW2MHUPVuOUS7z+ZnXFJEhGD+/BhZ+EtGx6EbcZpZBwB6xwYW6KJ2Gsp0 bMfWzOU40uw8X0hYhqHXVbrGgNaljBgTsVNd75Q/eyZ9bXVuQ1O19N7hmDFPRbza k89uK4MOM44KWDIRE5GorNrSotrMVRuAbzSVcdsXztspTPfKQX8u6fedbF8zpK3c KTZrwiSQ+LOT17UTHoPFhyQ8FdCw+IQxwvRL6/bHToRy2YmggVCJ56Nl0QxBni7o A39fGbKTwRgdEqJoEg1hcT3+DJSZ8I7Ht8Pw2Bpb3klkxCfhP9LMn6GZvjIDxRYJ Fb9y+4i70BbxBiTt3YgaGVvK9w0dvb+/tVc8Ht+FZAKpeK9dz1zkvqLcOO5JHUbc C4EEOGoNvCmlcyiBAbEVhLUcL4AjwX4EruNIF+lZ6RPGgicAx9dHplAmkLwCpxje uAye8u+CQJyGrSK9Zm3eEAPgC16a4i3KtBHx+DZL7uQ0urUwlAQWG3OP9UWb85Mw vjiA0jHoH1thDpqoc9fA4rYzXeZBKEhhG9lJE43n9KaSXiTYowKy79Ls4zkaO0wi 8I/8Z9zPACdRhV+zNDjSolSGfpeP2Jc2bjWFF9HAcezPdjaVdlihJQhy/8HZFDBX mYOJd+SfPC8r9y5GRpWt =nXND -END PGP SIGNATURE- ___ cloud mailing list cloud@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/cloud Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Question on documentation location for upgrading the kernel on a Fedora AWS cloud server
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Tue, 17 Jun 2014 12:54:09 -0400 Mark C. Allman mcall...@allmanpc.com wrote: Where is the documentation for upgrading to a newer kernel once you have a server set up and running? You can't just run yum upgrade or dnf upgrade. I've googled around and there are all kinds of docs, blogs, etc., on setting up a new server but I can't find anything documenting how to update. Just point me to the docs. I can RTFM. ;-] Thanks, yum update or dnf update should both just work Dennis -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.22 (GNU/Linux) iQIcBAEBAgAGBQJToJbKAAoJEH7ltONmPFDRstEQAMD23CL6si06Seud6ohOuXUL Pqn5iP90UtrgI7MSekzid1Gnz3ZzOXqeb7m/WPb+kK73/s1DEMkR+hpoGSOKVgu3 +DtcpFpmE0F++i18ERqkg+wH4uIGj+sSlEQpIr6/SSIkWbeGXkMvYwvTBPwFnor+ FiIukZfx8GWSTMoQxd0i8DON5uJAv61mPXf3i1MjqMOHWQro2HOoCOsP3NIqOb7P wN6U90uH5kLvIG0VtbInB23yibgDdBXb0dDiT3RB4oe7nX1enLODIw7zSOufU+m5 PzHRPzqGshq9hjXHv2sS7iquqSmfp7k3p+R45gDLd6+1Wt15B+6P/cCqxoV9kVRc q44IVD19odcEOsiqGtPCzGagWg4Dji3JGGUnqmbxNyMNdDtPec1Grj/w7fLz4iiN /c3y4h+YOwY5n6lYDuaS7W5oh7af5l4nlPknIG4jT4093oNtlpLYDnjiygkTtBlL lrU5eawsmZPMrwzXcwjOamgSTAQuhiAQWby/jy0zRNQ6UBhZjW3Ypwqa9DQkUvtZ M3uVPhUj0aPkCuzQFT+IgjlTRGDpy2MYjb0c88uNVlSGnuS9OMz7pKTnxBgJQwhV tPP/vGnpZxLI59zUgtG6OSQpOE0Q4OzQ6pkLXfWhn/7DSiuvt4OlaOOB4n2/feMa XCXJL1/8HYko+JpaniYH =hd3f -END PGP SIGNATURE- ___ cloud mailing list cloud@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/cloud Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: F22 System Wide Change: Replace Yum With DNF
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Wed, 11 Jun 2014 08:52:34 -0400 Matthew Miller mat...@fedoraproject.org wrote: On Wed, Jun 11, 2014 at 02:44:10PM +0200, Jaroslav Reznik wrote: * package 'dnf-yum-compat-command' is installed by default. It obsoletes Yum and provides its own code/usr/bin/yum/code, a short script that redirects to code/usr/bin/dnf/code with an appropriate warning message that DNF is the preferred package manager now. Notice that upgrading F21 to F22 will not cause the compat package to be installed so will not disturb any upgrading users. This is kind of sentimental, and I think possibly Seth would not have liked to have a big deal made of it, but... I guess I'm going to anyway. I would like to keep the yum name in remembrance of his contributions. This also seems like the easiest path for all of the documentation, scripts, and user habits out there. I don't mind if the backend package is called dnf, but why not keep /usr/bin/yum as the primary command and just do the right thing, only warning on incompatible usage rather than nagging every time it is used? I have personally always been under the impression that when dnf was ready to be a yum replacement it would all be renamed to yum. though there is still a lof of areas we will have to work on before dnf can be a replacement. I am not away of any work to make mock use dnf. dnf will need to be able to make mock chroots going all the way back to rhel5 since we use mock in the buildsystem and we build epel5 there. I really think forcing users to use dnf as the command is going to be a lot of needless retraining and redoing of work. Dennis -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.22 (GNU/Linux) iQIcBAEBAgAGBQJToJm9AAoJEH7ltONmPFDRVhoP/3hCvYuNjU6smvu/yqoCO9nb GaSYANDRQ0hCiGcirXC54w1XLH9MbrfWIOcL98SQMyvTuNwziD6rvAnxAxWBBRAi BdxTaHBi7DlZudHKpsmsER4ACLN0kLMpTaPG80+j5Q8CtG80w1eY/BWnDi2nwHHx 1u4NIzYtn70Hk9r836PHTyH9ojZc1FkYUjsNTVFdwxYgeRLj9IsVY0GoEl6t9ZfE DR4JMO3YrmsmsvL8ghOUmnbhNOvZJAd6D4x/Qyt2EIkfkmwD/RdeHzOwJjtiCQI0 AiLNU4JdcvW/cYFPKA5uLaYM7CDLS6vPT+mUZPEUAQMGKPGG4GhC791+J1w8TraK GoF3oI4u/VaKc8DHzQLsfcF2lLI2zHi3EH++Lku+9iKeoYBQvaegRGAwN/fTf8qz Tn5lexogfW/BuHgcjF8fm4H/YkX7uCZOgno8j5qeSY8fKAcWu6wz3wwBC/wwmTFT Qu85xFmz5wkXKtdxfwvOZOyW3DwjLgjW9U8xj+VvKO/cUQAmEF/sdPwHifXCDvNa sj++6XHVqkjnVLfrf8P031XbroSl5CnIaYS7TOw+IAnoyG+jQIhirAgQHNtsSZjM WyTKbyz49xGSdeGiUG9K+5aelwSY8pbUeIGJMGYEuU4pI+JUQW8ATDNIylrESeJ+ a9SXfRN6bmETT5CmyR4o =2EKB -END PGP SIGNATURE- -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: F22 System Wide Change: Replace Yum With DNF
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Tue, 17 Jun 2014 16:37:32 -0400 Peter Jones pjo...@redhat.com wrote: On Tue, Jun 17, 2014 at 02:40:45PM -0500, Dennis Gilmore wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Wed, 11 Jun 2014 08:52:34 -0400 Matthew Miller mat...@fedoraproject.org wrote: On Wed, Jun 11, 2014 at 02:44:10PM +0200, Jaroslav Reznik wrote: * package 'dnf-yum-compat-command' is installed by default. It obsoletes Yum and provides its own code/usr/bin/yum/code, a short script that redirects to code/usr/bin/dnf/code with an appropriate warning message that DNF is the preferred package manager now. Notice that upgrading F21 to F22 will not cause the compat package to be installed so will not disturb any upgrading users. This is kind of sentimental, and I think possibly Seth would not have liked to have a big deal made of it, but... I guess I'm going to anyway. I would like to keep the yum name in remembrance of his contributions. This also seems like the easiest path for all of the documentation, scripts, and user habits out there. I don't mind if the backend package is called dnf, but why not keep /usr/bin/yum as the primary command and just do the right thing, only warning on incompatible usage rather than nagging every time it is used? I have personally always been under the impression that when dnf was ready to be a yum replacement it would all be renamed to yum. though there is still a lof of areas we will have to work on before dnf can be a replacement. I am not away of any work to make mock use dnf. dnf will need to be able to make mock chroots going all the way back to rhel5 since we use mock in the buildsystem and we build epel5 there. Wait, why will it need to do that? The chroots appear to be compatible, unless I've missed something major. So creating them with the RHEL 5 host's yum should work, I hope. Is there a something I've missed? i am talking about creating a rhel5 chroot on Fedora 21. not saying it wont work. but we need to ensure that it givces us the same results, same for el6, el7 should just be fine. it may just work, but it needs explicit testing. Dennis -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.22 (GNU/Linux) iQIcBAEBAgAGBQJToMmDAAoJEH7ltONmPFDRt04QAIzpWgfG+6a6Ml2ivw7zINMi bJxPPO23bS8GIU5qt6WcQKWo3zLdxBXNulUy53N7G1gb600KZ8nIJGjMR8y4nBT6 b+lpf0zQi/vSD7vlROCdGiW0LqDTxNADc+6PVl/bkG49wvFTrUqc0Kex2YXada/N arx124nEVXLDjWeYLi/vCqQ+VGRWuzZoGaxauZ3EBonZc9XAN8dJnS30gh9TiijK YrDwDR3/2quYet87Z7CzJEf6P4Wjh11H8raQRy+hcSf7eFEvc/UjNQQQimw80lYW ZRIaJkwEmMTD+wuXxmoOHvqbigb3qek73hmSKohUatU6w9m9GtLTqR8Xj6MRrCEq ZFVvWjRt3EGQbxYHWtgApbIJd7jVE9x7fSU3LDFrEsVpd4UPmnmfSqacc8tWAq8i RyuR/airlO9EeNNUPPxSu9vvQd1ZF9+2Txmf+Xx68QixDxNR2v6Kp91dnideHbw4 ZKRXdK383HvrkIlQeh5r7qjTyqLaKiSeQhjIOWHsUkgNlqTAbP3cJCa1ZLlYGhgz P+wHoZDjJzDEu81Det0lpzgAtQqlU/vZV24TRgr/cSbT8nr2aNrwDHX4jmG0OCgR sFJeKQokCP+b/0ELNz5kjJzoEeC/tf+pBCDnb8wJd1oK1bcXsLMI72IBalJB1YK/ yBomIvdBIvkJ2vuk0LzE =T7/r -END PGP SIGNATURE- -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: ARM armv7hl-redhat-linux-gnu
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Sun, 15 Jun 2014 15:35:24 +0200 Pavel Zhukov pavel.y.zhu...@gmail.com wrote: Hi all, Ada support has been added to Fedora's GCC. This is good news. For some reasons koji passes armv7hl-redhat-linux-gnu as target in configure option and all packages built with gprbuild are FTBFS as the result [1]. I'm not able to debug it using qemu because both rpmbuild and mock use right target *-linux-gnueabi and gprbuild can handle it without any problems. So Why does koji replace the target and is it expected to have different targets on build and target systems? Google said me at least Asterisk developers were complained about that. mock is actually doing the wrong thing locally it seems the triplet we have always used is armv7hl-redhat-linux-gnu gcc does some special things to append gnueabi we use arch-redhat-linux-gnu everywhere, and do so on arm for consistency. Dennis -- Pavel [1] https://bugzilla.redhat.com/showdependencytree.cgi?id=1109392 -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.22 (GNU/Linux) iQIcBAEBAgAGBQJTneGAAAoJEH7ltONmPFDRWj8QAMcTqBwBcZATUFBV8gOonLta t0fvzv2LBxddEOuHPhMRHJ2bE6rGn113E+kGlhrqqRMZUE4sDSQzCC3LAD5k7FMG VtSwqRmQmnY+v7CwmDVmTdxwAl7RnbqsfQrHieRfWn3qvqd7vO/nsxFNUV4HKuVk /N9OLEGesRlGa2X6DzAWCSsp8spfUWngNCsSsElusnJ/l+NmfxDaqCt0NesyBVNM 0bdkL6+ChSxAyQrzZWm6q2ObUMbvsbnYIxyWxG+SW6VR1kQOyIoBD+hYFawRobYB i+mSJBoAwzP4EW3mcIUzBKQ4ojILs99rYjh2KSXXtFe6bxzb+70VljR4xG5mISmi tPjNYx8FiCg4RKV+8tVtB/7Z7ZBZE8zKpwlNSovQ2cvAOAChIO8w/gEUb8px9v7L IO9qDyeNwIXg4Z/fDTef7Uf9tuK416HZspN4+b4rhQ5i7qF8BuUPSEvvBVftLdDJ bJeCxO5mCMnjt3aNPAnJkP0QZK73Fu5sJsi3NAKj5CTMzzDTowPyGdIWADpRHW34 O3zomViik5TuAs3uIYPkOax6LS2NJW/0CLDDL+ToH9O8M4z5c3fsRd3YQ2eNXX9v t3/5d+xzG9ktf28ur12qZmhHMxuB23Qjro1hhcFmpM+8SShJpoDFKkq9ecfgU4z9 t6bTIpzlNsyob7MFLtW/ =k95f -END PGP SIGNATURE- -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: [Bug 1106637] New: odb: FTBFS in rawhide
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Wed, 11 Jun 2014 23:48:10 -0500 Dennis Gilmore den...@ausil.us wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Wed, 11 Jun 2014 20:01:19 -0700 Dave Johansen davejohan...@gmail.com wrote: On Wed, Jun 11, 2014 at 7:49 PM, Dave Johansen davejohan...@gmail.com wrote: I resolved the issue with ODB not building with gcc 4.9, but it appears that there's something going wrong with the ARM build. I don't have access to a Fedora 21 machine or ARM hardware to debug this issue, so does anyone have any ideas on what I can do to get the ARM build working on Fedora 21? Thanks, Dave Sorry for the multiple emails but I forgot to include the link to the failed build: Task: http://koji.fedoraproject.org/koji/taskinfo?taskID=7038059 Failed ARM Build: https://kojipkgs.fedoraproject.org//work/tasks/8064/7038064/build.log Thanks, Dave /usr/lib/gcc/armv7hl-redhat-linux-gnueabi/4.9.0/plugin/include/config/arm/arm.h has in it #include config/vxworks-dummy.h which i think either needs to be wrapped in an ifdef or the file needs to be provided. either way it is a gcc bug. gcc has been fixed, and i resubmitted your build, odb is now built Dennis -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.22 (GNU/Linux) iQIcBAEBAgAGBQJTmzIeAAoJEH7ltONmPFDR2h0P/1gWebpz7z/qSGqilDiDK4TT kBZIddnOg9I1eTRuBUQcn9M/4WDd2PJq3MRjzoncUcbtWMc4eiRKbBjUmmRfHMXP xkmsi3Lo5fvZ6xAYf6QHi/AJvh/jlP1URpEFZ3X4n5P16FUYm14gHLBkjrxO0Uek yZcnMCijuAees8s9RAJpbgD/PsomEdQU3Y/uJUDGX+t+tntRmkA4icqX0qkChbjm EttULlp50ta7D/eTrw648lMpzGS7T7bfX1shXHu9kmCSeJ8Qpa1kv7N5jUaHub4I KPPq56GjwCzbuxJMzfcZTYkGMKxq1f411PjjUp6dOiRnO++9X1B72PjpG+XB5iEX myNtd+rzZklRn15Ji5Kj2EA6ORnL5Bq/vM8aHL8+b7tot/khLHwpyAb5Mfh6VLMi JjUgzAx4NTFh9E+OkWgiPe0E6MHj/qLqaQpxiUCS//1GCTslXRlK6dqgUyVS/kEt MRO7GF0IZ4jRzEeef578qE0VF5ia+Ku0bIrXuiiMota9YY8Wj2hZACrF1MFiwYLb DqVjEA5qmb6FwuxP4P07dIGajtIzKhJ65iKDSO2NgTCSPgYUZeBaAowv9z3d3m35 YHoTE2wgdSVmo0QRdZxnKKlhOYHjlEXrXmSfSksTCaJrh7Eku0J0vwOaivIwMq19 j9SJRDi75atlf+iF4WdS =mOvz -END PGP SIGNATURE- -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: [fedora-arm] ExcludeArch tracker doesn't appear to be effective
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Thu, 12 Jun 2014 11:39:00 +0100 Richard W.M. Jones rjo...@redhat.com wrote: Of the ones I know about ... avgtime Written in the 'D' language which doesn't have support for ARM upstream. grub2 ARM (32 bit) boots using u-boot. Aarch64 machines will boot using grub2 (or is that grub2-efi? - you know better than I do :-) its using grub2-efi the grub2 binary is grubaa64.efi -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.22 (GNU/Linux) iQIcBAEBAgAGBQJTmbW5AAoJEH7ltONmPFDRv7cP/R9/+ch7QZsmO78q+V995dlI Ftjduje5c3ZC3QYstMIns18wkvkrNmI5pSuQHMVVpajC2aRFAxuoXYXP8WLnjC2S fU++TrFz+n3j81Hed0dZ5w1KOjHHqaR8fpPOuo1zX8JVBLTF9JQkP8Oe54SCSIZz 1la/eF4TepQ+7QzYBjTqEsUySKL8UoNMcb3m4ZMSYq+s3Wi+MksVy30TDh+Dd+hK limHase5HTgjSA0pma8WjcS6NKYOrP9fmH45e5xl2wcTJodwxrop3IESW7QMdDZN ZqSOl0V3zRGDWGoVZt4CdhOB7RNK0jdpIL0SbNVHlr6k7m9+zmSNScwvEbv1oZ8N 41ZPtC4C2bjZwWJL3fgPLCWKZN2UqaFZZyDtWNt5b5UOM9K6FMlqMRTC4IIFDAV0 plO8TnnTcUmHhCHz8EXjG5EpSrjXLL0o0rSrxIRx2k3a1LS01Tq/IDWkbdivzpWK aR/MgjEjMXEzj1w1AnYekM+9lLWUKtKSrzrjlREvQTJObc8xcp7vKpX0oPT+MMu1 hjK03AVw+cp+NDzrCcRYbd75YPqqDOUa333XMC6oyw15rzqv4SCa5kGXVM0wkjAP 4aWSqYgm4IB2NM1jCjY90qs2N7SktaenDD/EMhbgRkKQ9903wXYOa2yqijWdaEK5 Y/eH465VG+fsCwoSuXVN =Sleu -END PGP SIGNATURE- -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: [fedora-arm] ExcludeArch tracker doesn't appear to be effective
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Thu, 12 Jun 2014 11:39:00 +0100 Richard W.M. Jones rjo...@redhat.com wrote: Of the ones I know about ... avgtime Written in the 'D' language which doesn't have support for ARM upstream. grub2 ARM (32 bit) boots using u-boot. Aarch64 machines will boot using grub2 (or is that grub2-efi? - you know better than I do :-) its using grub2-efi the grub2 binary is grubaa64.efi -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.22 (GNU/Linux) iQIcBAEBAgAGBQJTmbW5AAoJEH7ltONmPFDRv7cP/R9/+ch7QZsmO78q+V995dlI Ftjduje5c3ZC3QYstMIns18wkvkrNmI5pSuQHMVVpajC2aRFAxuoXYXP8WLnjC2S fU++TrFz+n3j81Hed0dZ5w1KOjHHqaR8fpPOuo1zX8JVBLTF9JQkP8Oe54SCSIZz 1la/eF4TepQ+7QzYBjTqEsUySKL8UoNMcb3m4ZMSYq+s3Wi+MksVy30TDh+Dd+hK limHase5HTgjSA0pma8WjcS6NKYOrP9fmH45e5xl2wcTJodwxrop3IESW7QMdDZN ZqSOl0V3zRGDWGoVZt4CdhOB7RNK0jdpIL0SbNVHlr6k7m9+zmSNScwvEbv1oZ8N 41ZPtC4C2bjZwWJL3fgPLCWKZN2UqaFZZyDtWNt5b5UOM9K6FMlqMRTC4IIFDAV0 plO8TnnTcUmHhCHz8EXjG5EpSrjXLL0o0rSrxIRx2k3a1LS01Tq/IDWkbdivzpWK aR/MgjEjMXEzj1w1AnYekM+9lLWUKtKSrzrjlREvQTJObc8xcp7vKpX0oPT+MMu1 hjK03AVw+cp+NDzrCcRYbd75YPqqDOUa333XMC6oyw15rzqv4SCa5kGXVM0wkjAP 4aWSqYgm4IB2NM1jCjY90qs2N7SktaenDD/EMhbgRkKQ9903wXYOa2yqijWdaEK5 Y/eH465VG+fsCwoSuXVN =Sleu -END PGP SIGNATURE- ___ arm mailing list arm@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/arm
Re: Fedora 21 Mass rebuild update
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Tue, 10 Jun 2014 23:49:05 +0100 Sérgio Basto ser...@serjux.com wrote: On Ter, 2014-06-10 at 17:40 -0500, Dennis Gilmore wrote: On Tue, 10 Jun 2014 23:24:41 +0100 Sérgio Basto ser...@serjux.com wrote: Hi, On Sáb, 2014-06-07 at 08:51 -0500, Dennis Gilmore wrote: [2] http://ausil.fedorapeople.org/f21-need-rebuild.html Mass rebuild stopped ? or script stopped ? Not sure what exactly you are trying to ask, Since yesterday need rebuild script says that have 1052 packages that need rebuilding, now says 1050 other script says 907 failed builds. the automatic mass rebuild has finished or not ? Yes it is finished, it was finished when i sent the email saying it was finished and merged back into rawhide. the difference in numbers will be due to packages that fail to create a srpm. they do not get as far as actually making a srpm to create a build in koji, they do not show up as failures because they failed too early. Dennis -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.22 (GNU/Linux) iQIcBAEBAgAGBQJTmJfdAAoJEH7ltONmPFDRIQ0P/1DBch1YrT6+F3kcLrbuA+Mz d3SxR81s2w8NH+kSW0Gckh3EPbNG/EqFl/PjR/KdGvz1PUluWy0avamkzEXCIKyl F2IRJTNTy7O7a/rMpizu32T6TUq2txtf4J07fQdP5nLtZhr0BjMSkXJzc7LlTI4p XfDo43c0VO70oDAys/o1GkHcIOfdDfL4p+MSPR3HTUrkY/RzH30Aame3bqgS2iy0 F9WRO/jy6o6Q9pRNj91Ja9v6i5qKL9N0R1mBZwNCY1c26haCHnbdF/ZCpFEap6qw tPO6SNZtMK90oa1b6mvX1jneNLPSOA08U3RJNjIJQgShHrTXdI30oLa+w0CddjYP zgnFfk6pcfccYqVewojCl/7VQ8aI6WKdKOoh5W1jJpotN5O2LT8qsda3C1k5m2U3 ROXAa+4QGqmlzGPu/9ftb85aratLPeWhDYP9tIRxnWagPnC49fkz8pdYaMYHbCD8 5zqqN8Umq8GfiBn5qJ5bkOuWSRSdI3nQ5lvbO96kmyWOhk+PlyPp6IVH0er2SzR5 Zrsc1M2tCmdhhYT9MOOrVfNGFjE/7xf7GxczzcHelemEV5kUbkXX3v9mC1DtimFM /h5SMJTgZ4WT/ysyKiQv2Lan1tkYv3j14jtYJw6wNsuSN4QxwkipfyY26q2j+MXv lPkChvqWIIS0T8UIoFv4 =XBcP -END PGP SIGNATURE- -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: [fedora-arm] ExcludeArch tracker doesn't appear to be effective
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Wed, 11 Jun 2014 18:03:35 +0200 drago01 drag...@gmail.com wrote: On Wed, Jun 11, 2014 at 10:14 AM, Richard W.M. Jones rjo...@redhat.com wrote: On Wed, Jun 11, 2014 at 12:07:23AM +0200, drago01 wrote: On Tue, Jun 10, 2014 at 11:52 PM, Peter Robinson pbrobin...@gmail.com wrote: [...] So moving on from that why don't you feel comfortable pointing to the ARM port? The question wasn't really directed at me but adding my 2 cents ... basically on x86(_64) hardware I can point people at fedora and most of the time it will work. As for ARM if you get a random arm hardware chances are that it is simply not supported or needs some manual hacks to get used. That's not really a fedora specific problem but it makes ARM more of a gimmick to me ... until hardware vendors catch up. As you say, mostly this is the nature of the platform. 32 bit ARM hardware is not self-describing, and not at all uniform (unlike PCs). There is no BIOS. There's no standard text display or serial port. Yeah I know but it still makes it inferior to x86_64 ... debian seems to be in a better shape simply because it supported ARM for a long time (i.e there builds for a larger set of boards). Debian is in the state its in because they build a bunch of different kernels from different sources, we have chosen not to do that but take the longer better road to use a unified kernel and support systems in a unified manner. We have been working upstream in u-boot to make things more standardised and make supporting new arm systems much much simpler. its starting to pay off with much more supportable hardware and systems that will just work in a standard fashion. debian chose to hack in support for each different system in their installer and setup/management tools. which is something we chose not to do as its really not a supportable path. Dennis -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.22 (GNU/Linux) iQIcBAEBAgAGBQJTmJoXAAoJEH7ltONmPFDRrBsQAKPZWL/5BoQLHe3jigTZtwml N/sM0n6OgSKb28pA8d1nV1hHrKYKfTL/wFW29OL10MQAAZaTyOuQxznWzOh7yxKc NJUpbF3MVnNkX6DvJ4/HSzzF0Tb1C7BGX2vccM1+0ZFZtdTb2s6+GZ0tOKNVFD20 jT67t/DATnY8WtwL5HvuStgO5f6G0cpQerpDyCgbfBWKDQT270VxzFL/AIGHYhPx byvuOiROPqJAoHuJ9csPSKF+l5/b5S38bCYi6a2BTS06kfHmof0ct+NfIqrk11+3 ACTolPnN0Hcy2BRXglD+v4XC/KB1fCFfpb99muup7OE2fSqG0/u6yYwVEDdxWw1a j7c7YeNFSnJ1UGt+v5iUpGp97gdThuc727qb15YNhLd4nniBdShn63NxOuEk68yA wgfSd0x+dvj1aZRnYo4SMhXQOErUjNtFQYTASrkp/Qs2R6Zsza0+wYwqhFG2FZDQ ybLcwVAJthDkhAcz0Bu0xak9BQmb8z7hgggsbZWwxP04qmnG3msoTw7icVLni6UI yeaJOiKBS/7t1F9JmKdBE5susryFMYm0ESVSrOAVbKVS190IzcCxfOKGHRsPM3b/ xE8FG0wZAWgwFSgU7EZPGWQnQH1ABNlBkuTcO7Gt6+BHYo0+X+gI/LuQwAikon4g dN3tQNAohUs9kHhYheOE =33Vh -END PGP SIGNATURE- -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: [Bug 1106637] New: odb: FTBFS in rawhide
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Wed, 11 Jun 2014 20:01:19 -0700 Dave Johansen davejohan...@gmail.com wrote: On Wed, Jun 11, 2014 at 7:49 PM, Dave Johansen davejohan...@gmail.com wrote: I resolved the issue with ODB not building with gcc 4.9, but it appears that there's something going wrong with the ARM build. I don't have access to a Fedora 21 machine or ARM hardware to debug this issue, so does anyone have any ideas on what I can do to get the ARM build working on Fedora 21? Thanks, Dave Sorry for the multiple emails but I forgot to include the link to the failed build: Task: http://koji.fedoraproject.org/koji/taskinfo?taskID=7038059 Failed ARM Build: https://kojipkgs.fedoraproject.org//work/tasks/8064/7038064/build.log Thanks, Dave /usr/lib/gcc/armv7hl-redhat-linux-gnueabi/4.9.0/plugin/include/config/arm/arm.h has in it #include config/vxworks-dummy.h which i think either needs to be wrapped in an ifdef or the file needs to be provided. either way it is a gcc bug. Dennis -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.22 (GNU/Linux) iQIcBAEBAgAGBQJTmTEQAAoJEH7ltONmPFDRzxcP/irhXy7f2A+7w22Wip6g1oHL XFTp5fJydxMvfGXttxeTvRmGGtCrEMIWQvwqKUvUuHt2n8K6kL6Ye/3Ewmr8mVRH EURdfiqUxBQp3tBkrf0d5Cy9qLA0CHf1PZc8jNdyBFwFVk9sZ+paUVVeO/OPYthQ RDfwRclpxGiwaeeCYTTd00H3qIWnLxRspGgTe91Euhr8Ansa72aTP5ZA73SFZc9Q vVaUf8lakbfjBt9yvxoci1auGB+Mjfq6rN1e/DS+2ykRkD+rnkpCraQ/6I33gRfJ 5st+DP6h9iqiWKs9xqnUmf/roI/3eowqnNnbSJDtnVBO407c7ypbIpnwSzUjqGRw rzzkmXoFmmoB+oc3se68hvlKhHzCdrs4gx6q/5Ys3NKhX1xgSIp6MqKOyQn4Mccf m5xpHsB7PevfmI/JRgo3xmV9Qb616AR7jAjorjWJ+ExUeUfK8rPKuheOH+kmxUJf u5ZMi9fecSTC3CgHSfd3l+BGkU4byGhu80RGAVfRo1uCmvoW82DV8gNNtmebnlhV 8gOEcDVv2pnriw7z08NsNAbPNvbn8M0ArtK1TVUBHPod9GTg8IIOY8+M1PH5O35o /tWvw8Bm6O69wE8xh/dr84Hn5A3mBx6JCi05i8RBw5boC6oJfdPv320YWZivwq25 UC/oYa6/y73lp2l54NSH =1zt1 -END PGP SIGNATURE- -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Current FTBFS packages (was Re: [ACTION REQUIRED] Retiring packages for Fedora 21)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Tue, 10 Jun 2014 07:48:36 +0100 Richard W.M. Jones rjo...@redhat.com wrote: On Mon, Jun 09, 2014 at 02:22:57PM -0500, Dennis Gilmore wrote: On Mon, 9 Jun 2014 17:08:13 +0100 Richard W.M. Jones rjo...@redhat.com wrote: I have a Fedora 20 ppc64 Mac right next to my feet here that is definitely booting using yaboot. Then you did not install using Fedora 20. F20/Rawhide from DVD is uninstallable on these Macs. I wish that were not so, but it is. You have to go via the upgrade route from F19 or earlier. I'm just saying it's a fact that I have a ppc64 machine that uses yaboot to boot into Fedora 20. Rich. its a fact that there is no way to build a yaboot update period because 32 bit ppc has been dropped. I believe that apple and yellowdog ppc hardware is not tested or supported by the ppc team. so you are very much on your own there. just because you have an old build of a package installed is not a valid reason to keep it active when it can not be built or supported. any upgraded system will not automatically be migrated over. Dennis -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.22 (GNU/Linux) iQIcBAEBAgAGBQJTlw+XAAoJEH7ltONmPFDRCQIP/jDwC7IGHj0V02ynnooJD08K PmLJaox8ApAz53rs3JSC27z5SozbJrBrS+EJMAfdwWp8ub/VYn8ag7tLlR489GJ0 0oR+EicjQ1HrlHGFxYgO8C/NAgWtCMgpLIhmnqLzUcjpAz6lz8iDGnwUoxeIYdew pzc54OpAqxDSXU8OXnb1DblxEa+WYn8RxYXlnyFTz/7gPELd6btjznYIRQC/tfgE C8iXAnQOfU80rJT5l5FcSb1CRd6iGqgn1ZAh7PDH7W+cinSZn2d/+K1qChqwpPb6 nYZJw8sPojObv+RDQZKzqYdXR9+wR0NHe9wSFqIxbazf9Ybv+fn2Efk8oQwuhfSh Ywb4srXRZBXJ43aSAhCJeMveNOQp+Ey6lYryEr/dwDi1lzp0XBk6hfTwi0gZqkJC GtHQjMIA58u1OSlEWAktZAzc4sLEkHvHIbppzysmYEML6IYCJPt3JinUoJvmu9l0 tLxMHeFeGGquFBQlQpN1afVIXoWJ+X36IK+u4xTrJFOfwe/upf22mBi7ko01HOAm VokF1Q9PntXSa6r2btfpnAEq3ix145ci9JqqZRMzpA+eovxI+CddY0YdcNiYr38+ 7BApct1/KL/CcMofO4MUUB2GEXgUaI8bY2M7XbjT8z3KU0cS3dSbDEL+Jv8b4n3S GeOLgIUdJyBvV4ExLrYu =p2eF -END PGP SIGNATURE- -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: koji uploads (for scratch builds) broken?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Tue, 10 Jun 2014 17:43:37 +0100 Richard W.M. Jones rjo...@redhat.com wrote: I'm not sure if this is a local problem, but currently I'm unable to upload the SRPM to do a scratch build: $ fedpkg srpm Wrote: /home/rjones/d/fedora/libguestfs/master/libguestfs-1.27.14-3.fc21.src.rpm $ koji build --scratch rawhide /home/rjones/d/fedora/libguestfs/master/libguestfs-1.27.14-3.fc21.src.rpm Uploading srpm: /home/rjones/d/fedora/libguestfs/master/libguestfs-1.27.14-3.fc21.src.rpm [] 00% 00:00:00 0.00 B- B/sec At this point it hangs for a very long time, before eventually printing: GenericError: upload path exists: /mnt/koji/work/cli-build/1402417278.641677.KCBIWmof/libguestfs-1.27.14-3.fc21.src.rpm I've tried this a few times, including bumping the release, but it fails in the same way each time. Rich. What version of koji do you have installed? Dennis -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.22 (GNU/Linux) iQIcBAEBAgAGBQJTl0A8AAoJEH7ltONmPFDREtYQAINhVGlyam0Hm4rinHxKmO2+ 8NQ2ebHLzm1xWcZ24UIzQOvYbRqAqXx0hAaz/1uaAUOnVpp8Jcl0DlfPJstR7HIp MMPUmK8QwVNeXfz6LCsbrAXyJbVAiQWkGLdx18DToCbddO+cP3C2CS8+Xq4+jKDx /plRQDhn8iO03B1dbJwS1Xmz3OPtKus6joU8Pqyd5jl0rGNmuJkfVysQVrg+zYa+ ZaSnWcyTRPJrFbbnGU+MMhsQrB0pqStHhSoF8fP6LCwlY49SEoCQGzQ/ZbFGxvyx /G/iejilVBET+s6cxeJybUspstm6ovymh7IHmFKfDxZ2RWNWdAhGyAMdTHaA7Rjr ITl37PAwRWf+KN4JX1vHA5ngegXJ3v7b4gh9zKIkK/9pgulGG7a2hmsmkYVUrZWc wmkF0kaBmC8nWpmnzny3y1UBLmRgCmA25yCa88Ej/ZQVOWJOdZjOhUfcKmGTeJq5 2Rcy1iK03OR8qZ0j+lMApEQr8tIsZZi/2ZmGEXNTDbEiROItTu2y9KGiHZ9suJq7 Xw34L1Nu2sfB8/xyrbjrHNmODXmFk6+sG5GZ8LYkSgDNh6zRQZhRFX6Mo6zu4MR8 c1pCLj/hAygzQmYj42uuFAoEFSIjHG85N2shLzpTX6VFBahWaUXuKuEgOxpwAF4C E2HjISAt+UYZCv7JSr2k =F0bO -END PGP SIGNATURE- -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Fedora 21 Mass rebuild update
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Tue, 10 Jun 2014 23:24:41 +0100 Sérgio Basto ser...@serjux.com wrote: Hi, On Sáb, 2014-06-07 at 08:51 -0500, Dennis Gilmore wrote: [2] http://ausil.fedorapeople.org/f21-need-rebuild.html Mass rebuild stopped ? or script stopped ? Not sure what exactly you are trying to ask, but that is the list of packages that needs to be built. it includes packages that have been submitted but failed to build. Dennis -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.22 (GNU/Linux) iQIcBAEBAgAGBQJTl4leAAoJEH7ltONmPFDRGG4QAJS/mQjwnqWRcaWQ1AVyV8v+ wuLbxbpRpPwBBJ6CNoKvrTFr+/UBEaq5JqfU6XEya2L7JCJnx4/Tnbvhw9+U5C+n 1ZKe8fcf9uOwCqgZPxRlAamAen0utNM6tYbRPKosjsfrPQshQPcAtLLP6z1bzOM1 6moc1wcB0LhTk5c08HZ/4qKkTlAPK7HprAWECNYRAaNOnZ5k/WkZcZ9g4qlGv1jH PqQM0RW07lgCKM0nvokR+FZfxReLXP9xCeUxfuDJntrFlwty2+myMA3OE7nPpGbr A/ioc3cxLJTJhzZkVyWRbHhC16dJRDLAepzARVTYxtha4AQ+4bndLGdgqxCUnG9y IaLEP5EUlJCt6PZXp1xJEa4+pbPYyuUimRM2zJhWqxRP9FQpS1htc/kjYhf2sL/4 eagoDRDJJa4R0q9sqT7CZZy7PdCzEtx271zS3KHMKJLeIMfpgmK6Ob5qsXBAH8Sp gMHthkT6l8cEb+RNHLtVxYqxSWDAVrbjNUN+QLWF8clho8msR9btQOcQkC8+/Vgb 58QXC2IzTh52uu+alwIKK6pvi0+TsuXfti9gEm3/h91ZZwZ8C6kluX+lhEN2cYMm wfY1ti2aZi4HjyYjfi8Qct0g460bEpMh/J4mPWCRDhLI8lTmRiodHYyhwPGPXcJq qub4bHphKmbZ+HZVPU2A =hwqJ -END PGP SIGNATURE- -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Fedora 21 Mass rebuild update
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Mon, 9 Jun 2014 07:13:27 -0400 Neil Horman nhor...@redhat.com wrote: Dennis, I've been considering retiring the coda package here soon. If I do so sooner rather than later, would that clear the coda FTBFS, or is it too late to remove the package from F21? Neil It is not too late to remove from F21, and if you retire it it will clear it. Dennis -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.22 (GNU/Linux) iQIcBAEBAgAGBQJTlanwAAoJEH7ltONmPFDRtEYQAM1jWHOxBZd1XzhZtVzuJWd+ YAEw1UUmtZo0Wr+eX3jaebcmcFjP6W86X/0sOhuAPVY5khoUZZjYtrjyBuFTEc/f JLtilaMqMbEIfgT/plv+L/J88qOz98PgvamYWhYtcbr+cIRmColJC7uSP62FxBdx /ZU93llFqA7rQKwaRWDaW61MrMFPGnGw7CJ4n/fRpiImC4YSTXkJFr9rDLmrKxdX S7ZHG3KeGLDZliuVksexVOLM+VyVV/uOlKZjbTPZ0QFyDjTv7aq2bDpMAd0ofODa qg1BA/1H52DRy1jJ7Uer/F+wVcwl/sqvIWNvUHh6o8JqKEtf+CLI3X+0Haphj5o7 6OWDgGBCx/CDAFoVQs9w7yLfkVXxzob6NcT+ns8ggb6xop5btQlbZHOlweIhtY2B hOqf/vE1e/DX0fS71YKn8Afw/S3Y6kYq/QxBpC2IeW4yseExs8jhAVkegeIV3h8n /swbxfPsET6+CF8YrcN2G20hMRzpTqA0x1RUzBptOM+yxf4jLf605YFtFV+i9NE1 U54wTAZFILHgPudM9Ph5aroBQke4PIcrGcoqsLlnaVPsZ/7F2Ao99h0GdazN+/4A qLA0VM/0ntqWi2mJeAKoTyJ9vw9k37HJRp4+XhTvpBzBozOfxeekvum7WMm5iIGB yLMIsbRKgArBSPnYkAM9 =cU5k -END PGP SIGNATURE- -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Current FTBFS packages (was Re: [ACTION REQUIRED] Retiring packages for Fedora 21)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Mon, 9 Jun 2014 00:01:34 +0100 Richard W.M. Jones rjo...@redhat.com wrote: On Mon, Jun 02, 2014 at 04:36:28PM -0400, Al Dunsmuir wrote: On Monday, June 2, 2014, 2:53:33 PM, Till Mass wrote: On Mon, Jun 02, 2014 at 11:01:53AM +0200, Dan Horák wrote: On Sun, 1 Jun 2014 11:24:09 +0200 Till Maas opensou...@till.name wrote: yaboot dwmw2, dwmw2, fkocina, this is a secondary arch only package since F-12, so it should be excluded from the FTBFS list in primary koji Actually according to Dennis this is a ppc32 package that can be retired, because ppc32 support is being dropped. Till, Please do not start deleting ppc32-only packages. A few of us would like to resurrect ppc32, likely initially as a Fedora Remix. Deleting ppc32-only packages just adds more work to that effort. Plus yaboot is still needed to boot ppc64 Macs, even on F20/F21. no it doesn't that part of why ppc is no longer built at all. f20 uses yaboot for dvd and grub2 for the installed system, f21 is using grub2 everywhere. Dennis -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.22 (GNU/Linux) iQIcBAEBAgAGBQJTlRkhAAoJEH7ltONmPFDRj0sQAJx47oFGw8WFmddl55Q8u/sm EhD9xtZlKLorIhH81iYWO9gWgDUVwiZjfTKuo5QUcFNoNKtoslJlhIaZFIFStBAl phbkd0tJagUC9/QVHeMYnTvi3AjSHtom+jVK2e4KnsA4wrnHWbPlI3TiRY4lQ7Jx cKENNX35x8fhh9nu6o+8P4WafySz6ZRtGe+u2QbnZ5qc0zDrB8EFmiQiggkIs55t s/i1VEvhGC+PNQxf86xpPMBfCUVeGZ+ww5XRe/3ypnijTH/OPYDjiKGJnk8zSNYF Bgd12W4mR1AjPyiBVjL4Wg0r8N9u/Cl+sf99L2S4Hg8uqBXlQHAXWTMOCxCV78pl FuJdjDSyU42G/RCvQETV6cb2maVY8HiR1xCJOaHD7Md1ggqSdi2/G+mktnXBueWc MBSD2Ix/uVBsEaghd+ag8zohGY/imXNkSg1vjPeZVZuC2eb1oSQbYk2mqOhQ5Z4B /yHjZ3Bzkhvx0yxcCfyYbtfm4o/K6nsLTgKj+u6LGhM0Kng4UxWtLYuNO/TTBDjs Gt4QBrK3nGcKQ2Upl19N/dOUOOpy93DsYj/wUR7EbAj1+EVUhZ+MwFK2b+zWKDGW t5OvzOYWMA4GRwdyPx4ugadC5xUUZb0Pamqc3jNvNUJdtlQkrHhAb1lsO+BNtQP+ e7+qJRgeXnBW+zqFvGx2 =1LGo -END PGP SIGNATURE- -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Current FTBFS packages (was Re: [ACTION REQUIRED] Retiring packages for Fedora 21)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Mon, 9 Jun 2014 17:08:13 +0100 Richard W.M. Jones rjo...@redhat.com wrote: On Sun, Jun 08, 2014 at 09:18:12PM -0500, Dennis Gilmore wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Mon, 9 Jun 2014 00:01:34 +0100 Richard W.M. Jones rjo...@redhat.com wrote: On Mon, Jun 02, 2014 at 04:36:28PM -0400, Al Dunsmuir wrote: On Monday, June 2, 2014, 2:53:33 PM, Till Mass wrote: On Mon, Jun 02, 2014 at 11:01:53AM +0200, Dan Horák wrote: On Sun, 1 Jun 2014 11:24:09 +0200 Till Maas opensou...@till.name wrote: yaboot dwmw2, dwmw2, fkocina, this is a secondary arch only package since F-12, so it should be excluded from the FTBFS list in primary koji Actually according to Dennis this is a ppc32 package that can be retired, because ppc32 support is being dropped. Till, Please do not start deleting ppc32-only packages. A few of us would like to resurrect ppc32, likely initially as a Fedora Remix. Deleting ppc32-only packages just adds more work to that effort. Plus yaboot is still needed to boot ppc64 Macs, even on F20/F21. no it doesn't that part of why ppc is no longer built at all. f20 uses yaboot for dvd and grub2 for the installed system, f21 is using grub2 everywhere. I have a Fedora 20 ppc64 Mac right next to my feet here that is definitely booting using yaboot. Then you did not install using Fedora 20. the ppc team has dropped all 32 bit support. yaboot has only ever been built as a 32 bit app. they are the ones that chose to have it go away. They are the ones that made the decision to no longer support yaboot and worked to make grub2 its replacement. likely to move to grub2 you will need to manually set it up. but it really is not a viable bootloader for ppc64 anymore. no amount of disagreement will change that fact. Dennis -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.22 (GNU/Linux) iQIcBAEBAgAGBQJTlgmRAAoJEH7ltONmPFDRovoP/1q7Fq3v7V2jRULaD1jYDP4w ObmCx05Mht7kA+d8oDMUuMJW53JxSpSzY0CT79t9GWZqys8dNmeH9vE5Af7DGuUG pRIjj5ohR/R86EVP7qQYvpJCDUZ/iKVepssJLWuEJJCTBo7c0X/T+kknKiq6Vm56 pu7HeITtsv58309qV8vbNaa7n4UAtbojBMK06yxnk2wBtHAuTNBOBKyx8TohOWr2 Gh0kb8TRdW5g01ARfI1YrFVpFJRhbAwBN70GwHPFdfHIbynGfK4nnMr7/nLm4Zg7 4kXvKfwMGkHmA1BN9+q3kWqS038XmViWfTc0Ui1f9aCC5NRdPj1lJpl0ks8d9TE7 hL4sfYp4UA5YhoK/68Q4NUdqZXhj+j1cR6OZ7pmcTIsKthc6RMlWa+Li9QbXhwY0 nn9ar7DfOOaeHwbMmWxRyO5ySNneaSxvkMyJo6WcKhO5+IXRIOjTziEOmWtw2L2M tMwQ3FKBlkhCWYSI42niaXfSH2RNFQzWQNL1xEoCvypPOWiC+pFPa/b23wLv/Kte G/7kGgyyeoTolwT3KpudqFJa42JIOdaZQU8uSOxbO2jTVwfvCo5HKtu10RgeizqB 8j/UbBk81E885bCmAUhC27lxpBxRvX1f49dBtBE2/lJx5hENtr9NyEVsqSpHXdVY UY1xz10TlE6IqXyKDL3G =xHnz -END PGP SIGNATURE- -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Today's Rawhide mail missing due to mass rebuild
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Mon, 09 Jun 2014 12:00:49 -0700 Adam Williamson awill...@redhat.com wrote: Just in case anyone was wondering - I've rejected today's Rawhide report mail because it's 3MB(!) in size, which is a bit crazy. I believe it's due to fallout from the mass rebuild currently in progress, so it should work itself down to a more reasonable size in the next couple of days. it should be much smaller tomorrow there was over 13,000 changed packages in todays rawhide. if you really want to see what changed http://kojipkgs.fedoraproject.org/mash/rawhide-20140609/logs/repodiff has the diff and http://kojipkgs.fedoraproject.org/mash/rawhide-20140609/logs/depcheck has the broken deps. Dennis -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.22 (GNU/Linux) iQIcBAEBAgAGBQJTljLtAAoJEH7ltONmPFDRV+IP/2sUE67PgTNFIDTYGiy6Lu/P k3NfDrlwZ29UfLTgGAyGf2fewjtKnIEaQHOKoN8Yhz4ERsJUX2NFwaTE3/CkaIYI y75xKPQiUqT+PExcympDbatrRnVn24ccTUDfQQuoq+ee+AnQaGRomBPfYM7bEudl hJDIvJDgMsG9d0upTljoJrtXJ8Y4JelmwaQ6nk3zVdJVpEVQXy3hPp9Rw5iGFuJW OoJaX2GoDeC845vRdDiLBLci2f123hfoSsdIsSv78uAaufFbVhuWupDeGJDNdOJb FDj0zIuAVhApA0nxVA8Q88QL+cO802B4IQ/sp5KIs3sAfqqheFncWvi/xcb+d/PL KjHEy1W0d9q/GGb28wbz8oB1P7baifhduMM8QA1Tzjl7n2JzNX0LGkKjzCwGgHim 2wp12pW0j5Fs3/JjVHyaE2lFJuzjQnWMHPiZRlMp0K0p4aMrTEW6CtPWcGnCIXIu mlMs2gnOx5eLSM5IsUYPi0QUyVpo3FO5rmonT3kgrGdlJ2CZqgu31JdCsK6WTYoI /aSaozKvbzL3pZQZYWQKLjnAVKeJaZ1ZWkqJZQYtZPwZ8HYjKa4Y2/eFm3DRGcVG zpIghFz94tm76XviiUY8I+/7YjOaKpMBuCBKmeHCcNVhfPm9QEObNt0y2TF8IxIg 06SgzEJWv9yVjHGLhyCd =RJwk -END PGP SIGNATURE- -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: Fedora 21 Mass rebuild update
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi All, I am in the process of tagging the mass rebuild into f21 it will land in the next rawhide which due to the size will take some time to compose, and sync out to the mirrors The tagging script tells me it is Checking 13923 builds... there is a very large number of failures[1]. There seems to be a very large number of java and ruby failures. so people interested in those stacks please get onto them and fix them quickly Regards, Dennis [1] http://ausil.fedorapeople.org/f21-failures.html On Sat, 7 Jun 2014 08:51:06 -0500 Dennis Gilmore den...@ausil.us wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi all, We merged in the side tags on May 27, and on June 6 kicked off the mass rebuild. we are currently about 1/3rd of the way through. You can see the current list of failures[1] and list to be built[2]. Both lists are updated every 5 minutes. at the end of the initial run though we will file bugs for all FTBFS. Please be sure to get on top of FTBFS quickly as they need to be done before the Alpha Change deadline of 2014-07-22. Dennis [1] http://ausil.fedorapeople.org/f21-failures.html [2] http://ausil.fedorapeople.org/f21-need-rebuild.html -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.22 (GNU/Linux) iQIcBAEBAgAGBQJTlKKCAAoJEH7ltONmPFDRTTQP/i4LYQRFeidi0Rr4zsU5Dy9A s7AOJIFlrSFjbVvl7XzQX4yi8LsztsYohiz4sGKw29SeGwymEdPQYZ9n0Rsjfg+F OmyZ98CKf1FPsfDLD0tojfLO59qmeGqUNWred4Ov8dcJqUb0il1A4gEQeivrVNIO 6wHmVxsEYACpEs2nrNqLZcRv22j6LNBa2kBRqrF1tYPpAnszmUiSuJJTe91yy/a1 nLONrLCp5ZG8Xw/o+kHvtXMWNTnofbHYZTebxx2kLSfu4ZcxypfJdbJXrZGK0vKV J1Wv3l56S+janjtTCqOXiijWAiSFOj5kLnQ6pmVhLym4KNMSoy5uaVuwXJ3wkwwP kc2PTNqr8XUJlpZCyYzUuuiWv5wgZTxmAmc1UR3tKxbYSrkv/bsR1BmwNwcgM6N9 Efj6n4Lk+FJ9F5zRcKXpxyJamKyeaApr1t1u3JunbKGpo7iwgCT4J+RwUif0XFdc Oeh93heGsSQfcbko3gVVd2e9rsr6nhiRKc1C1sMWJvZnD+a6TZeaoyQW+RxPUX0L VbppEZHkWLMCzZ+5ADUXsF17PFnhLfZBpECK0aHpvYHhoiRjFLTwxSaK7xksU1wR ENQioVUzfW8UCYd1VuquPOQfTVz9AwbAPGbclqzc139aU4B4TVYlo2xS+FUHWIrE vxZ+w8ao4UapyOz626QT =bMTV -END PGP SIGNATURE- ___ devel-announce mailing list devel-annou...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel-announce -- 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: Current FTBFS packages (was Re: [ACTION REQUIRED] Retiring packages for Fedora 21)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Mon, 9 Jun 2014 00:01:34 +0100 Richard W.M. Jones rjo...@redhat.com wrote: On Mon, Jun 02, 2014 at 04:36:28PM -0400, Al Dunsmuir wrote: On Monday, June 2, 2014, 2:53:33 PM, Till Mass wrote: On Mon, Jun 02, 2014 at 11:01:53AM +0200, Dan Horák wrote: On Sun, 1 Jun 2014 11:24:09 +0200 Till Maas opensou...@till.name wrote: yaboot dwmw2, dwmw2, fkocina, this is a secondary arch only package since F-12, so it should be excluded from the FTBFS list in primary koji Actually according to Dennis this is a ppc32 package that can be retired, because ppc32 support is being dropped. Till, Please do not start deleting ppc32-only packages. A few of us would like to resurrect ppc32, likely initially as a Fedora Remix. Deleting ppc32-only packages just adds more work to that effort. Plus yaboot is still needed to boot ppc64 Macs, even on F20/F21. no it doesn't that part of why ppc is no longer built at all. f20 uses yaboot for dvd and grub2 for the installed system, f21 is using grub2 everywhere. Dennis -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.22 (GNU/Linux) iQIcBAEBAgAGBQJTlRlkAAoJEH7ltONmPFDRkXAQAI3WLyXqOvIEbQycCmPJI4BS kil882vSjlqcQN4QGGLvqBwjI2LB/hiD0r3svzWWdCoQDj5EQgzA2rMfh+QWiKxD 9H+puoycDiNBmUK9pFvXrSnv1/Q5bs+NuXcp64DLPZXHSeVpDhNeTTU7unN5kgwU hWblqZ8/pLxLLSz1CPgzSttEcGtMYvasGVTvkhoZPkECp7kZt3ojXV3sChl8AA9U /ZS94/IHnkcFt1CsbtAZ5MlO14T03xXA8hVvUaPKHN9IE9/N71Od9o7mv8eLsK70 z5HvAYNUg94epo1+WXDESsYZ8kJZhaV6ykys2n0hlm3OGSjGvbyYHZ5DJX9u9yGw vrXZYAy6PCs88kq3eI29i+xQxMXbaN+XaMiIbshTTpWj++hVN9F6sVSlVPhV/acy FmBHcEAjJGi3cTBcDJ+l4wki6OIULcmTtQXg7cO+r6pyVPEwU9CAFE9EJKZURChj H+K3Fw/KiVSUlKWThNw8oXaeq0W0El7af13+NiM2KJbkd5fgReWKtYY2kuq3VJ/9 i8rcTSL2d4alZYbcnBXmOaDja5qSsU6R2yF4l88pPwPN17/6XtlWafvvzgVwWZDW ilCrNWxOM1bpPWkdLPvSuAF0hnyyQGIa9Bip6wlXSL7TPKeplsWKgScxHSOU3zrH uLH58ShkSrByIt+XkF+f =nDww -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
Fedora 21 Mass rebuild update
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi all, We merged in the side tags on May 27, and on June 6 kicked off the mass rebuild. we are currently about 1/3rd of the way through. You can see the current list of failures[1] and list to be built[2]. Both lists are updated every 5 minutes. at the end of the initial run though we will file bugs for all FTBFS. Please be sure to get on top of FTBFS quickly as they need to be done before the Alpha Change deadline of 2014-07-22. Dennis [1] http://ausil.fedorapeople.org/f21-failures.html [2] http://ausil.fedorapeople.org/f21-need-rebuild.html -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.22 (GNU/Linux) iQIcBAEBAgAGBQJTkxjPAAoJEH7ltONmPFDRUbcQANL/twn90/M69kMVCI+ZUcj/ MRh9aamT8Dsv0vliP6fikmvNEstWV0x+sKUMNK2DRcmobQAiM6hNtgQEc1uPXdGj z+AszNLjJVeV1ZeQ7yORFjU9rmGPYCyxEC8BqLJy8BnUXZOcWbryEb06/8mYJaz3 QMpE2s1A6H4gbZlkL0VaIadfH0QQH6cjENyIofMOEvaDe0MAkUiC2dobubgkf7Zq yYcl0k391BKoEdZ4HZoqxAspVz0FTdIsX1E9EnuiVr1TxiWxKZOT1S7uz1lyjali gOLndnBhYvPSZU1IdrIjEbJczfRnjmnpX3Mda9UqQoBqajlsTjWwZgt2sIq5KQoO lyDwDjufz2KZ6JlDucgV/GrVh1C/LCPpFOyVJ3ZoDfSVAnAK1ZermxX/oTe4Emwz 6+bBvWplDR+nyGty7pmtgeENXJigm6RrxPIeXclFAYV98bQxdA3efTALW/1iwaBx 6WORl7cjmQipGtQLh2ixY5R+ELYG2eRIK7sqU4eswLqOEl0Ws0ASW7JPtHyCEd2u 3QFC3hw+pgpemvFEXLM/cfRMpY8hv52X7teerISKhu6QUcKX2CZbf+7QKOH8OpXH qFGiw5LqJBHN4BfbjFR3VOjD5Vxuc4T1MP1jXyOM0zUEWoHPjxaRZL7O7t7Ivjiq zielPS7idFpdNuoK0UPV =MtQO -END PGP SIGNATURE- ___ devel-announce mailing list devel-annou...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel-announce -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
[perl-Lingua-Preferred] - Rebuilt for https://fedoraproject.org/wiki/Fedora_21_Mass_Rebuild
commit 179a6239a08721c7591dbfe1d7120fa0038ea8cf
Author: Dennis Gilmore den...@ausil.us
Date: Sat Jun 7 01:15:54 2014 -0500
- Rebuilt for https://fedoraproject.org/wiki/Fedora_21_Mass_Rebuild
perl-Lingua-Preferred.spec |5 -
1 files changed, 4 insertions(+), 1 deletions(-)
---
diff --git a/perl-Lingua-Preferred.spec b/perl-Lingua-Preferred.spec
index 6af14e3..5e9eebd 100644
--- a/perl-Lingua-Preferred.spec
+++ b/perl-Lingua-Preferred.spec
@@ -1,6 +1,6 @@
Name: perl-Lingua-Preferred
Version:0.2.4
-Release:17%{?dist}
+Release:18%{?dist}
Summary:Perl extension to choose a language
License:GPLv2+ or Artistic
@@ -50,6 +50,9 @@ make test
%changelog
+* Sat Jun 07 2014 Fedora Release Engineering rel-...@lists.fedoraproject.org
- 0.2.4-18
+- Rebuilt for https://fedoraproject.org/wiki/Fedora_21_Mass_Rebuild
+
* Sun Sep 08 2013 Emmanuel Seyman emman...@seyman.fr - 0.2.4-17
- Remove no-longer-needed macros
- Add perl default filter
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[perl-Log-TraceMessages] - Rebuilt for https://fedoraproject.org/wiki/Fedora_21_Mass_Rebuild
commit 4254f00080bcdae9661d254c5164a471ee5465cf
Author: Dennis Gilmore den...@ausil.us
Date: Sat Jun 7 01:32:09 2014 -0500
- Rebuilt for https://fedoraproject.org/wiki/Fedora_21_Mass_Rebuild
perl-Log-TraceMessages.spec |5 -
1 files changed, 4 insertions(+), 1 deletions(-)
---
diff --git a/perl-Log-TraceMessages.spec b/perl-Log-TraceMessages.spec
index eea09dd..fc35fa9 100644
--- a/perl-Log-TraceMessages.spec
+++ b/perl-Log-TraceMessages.spec
@@ -1,6 +1,6 @@
Name: perl-Log-TraceMessages
Version:1.4
-Release:16%{?dist}
+Release:17%{?dist}
Summary:Perl extension for trace messages used in debugging
License:GPL+ or Artistic
@@ -51,6 +51,9 @@ make test
%changelog
+* Sat Jun 07 2014 Fedora Release Engineering rel-...@lists.fedoraproject.org
- 1.4-17
+- Rebuilt for https://fedoraproject.org/wiki/Fedora_21_Mass_Rebuild
+
* Sun Sep 08 2013 Emmanuel Seyman emman...@seyman.fr - 1.4-16
- Remove no-longer-needed macros
- Add perl default filter
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[perl-Net-CIDR] - Rebuilt for https://fedoraproject.org/wiki/Fedora_21_Mass_Rebuild
commit 29dfcdf6504e82789ec65fdc1b7a2be2cf059ebc
Author: Dennis Gilmore den...@ausil.us
Date: Sat Jun 7 02:50:53 2014 -0500
- Rebuilt for https://fedoraproject.org/wiki/Fedora_21_Mass_Rebuild
perl-Net-CIDR.spec |5 -
1 files changed, 4 insertions(+), 1 deletions(-)
---
diff --git a/perl-Net-CIDR.spec b/perl-Net-CIDR.spec
index c5fd5cd..65a23cd 100644
--- a/perl-Net-CIDR.spec
+++ b/perl-Net-CIDR.spec
@@ -1,6 +1,6 @@
Name: perl-Net-CIDR
Version:0.17
-Release:3%{?dist}
+Release:4%{?dist}
Summary:Manipulate IPv4/IPv6 netblocks in CIDR notation
License:GPL+ or Artistic
@@ -42,6 +42,9 @@ make test
%{_mandir}/man3/*.3pm*
%changelog
+* Sat Jun 07 2014 Fedora Release Engineering rel-...@lists.fedoraproject.org
- 0.17-4
+- Rebuilt for https://fedoraproject.org/wiki/Fedora_21_Mass_Rebuild
+
* Sat Aug 03 2013 Fedora Release Engineering rel-...@lists.fedoraproject.org
- 0.17-3
- Rebuilt for https://fedoraproject.org/wiki/Fedora_20_Mass_Rebuild
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[perl-PatchReader] - Rebuilt for https://fedoraproject.org/wiki/Fedora_21_Mass_Rebuild
commit 5481b18e4bb8f90ffea5561869a272ce26ddda50
Author: Dennis Gilmore den...@ausil.us
Date: Sat Jun 7 03:53:38 2014 -0500
- Rebuilt for https://fedoraproject.org/wiki/Fedora_21_Mass_Rebuild
perl-PatchReader.spec |5 -
1 files changed, 4 insertions(+), 1 deletions(-)
---
diff --git a/perl-PatchReader.spec b/perl-PatchReader.spec
index 94f9eb3..fab6fe4 100644
--- a/perl-PatchReader.spec
+++ b/perl-PatchReader.spec
@@ -1,6 +1,6 @@
Name: perl-PatchReader
Version: 0.9.6
-Release: 6%{?dist}
+Release: 7%{?dist}
Summary: Utilities to read and manipulate patches and CVS
Group: Development/Libraries
@@ -67,6 +67,9 @@ make test
%changelog
+* Sat Jun 07 2014 Fedora Release Engineering rel-...@lists.fedoraproject.org
- 0.9.6-7
+- Rebuilt for https://fedoraproject.org/wiki/Fedora_21_Mass_Rebuild
+
* Sun Aug 04 2013 Fedora Release Engineering rel-...@lists.fedoraproject.org
- 0.9.6-6
- Rebuilt for https://fedoraproject.org/wiki/Fedora_20_Mass_Rebuild
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[perl-Socket-GetAddrInfo] - Rebuilt for https://fedoraproject.org/wiki/Fedora_21_Mass_Rebuild
commit 6e3f923a095475d3ace725512c3d05b96a8a15c4
Author: Dennis Gilmore den...@ausil.us
Date: Sat Jun 7 04:52:32 2014 -0500
- Rebuilt for https://fedoraproject.org/wiki/Fedora_21_Mass_Rebuild
perl-Socket-GetAddrInfo.spec |5 -
1 files changed, 4 insertions(+), 1 deletions(-)
---
diff --git a/perl-Socket-GetAddrInfo.spec b/perl-Socket-GetAddrInfo.spec
index bbbadf1..5ef9976 100644
--- a/perl-Socket-GetAddrInfo.spec
+++ b/perl-Socket-GetAddrInfo.spec
@@ -1,6 +1,6 @@
Name: perl-Socket-GetAddrInfo
Version:0.22
-Release:3%{?dist}
+Release:4%{?dist}
Summary:RFC 2553's getaddrinfo and getnameinfo functions
License:GPL+ or Artistic
@@ -62,6 +62,9 @@ find $RPM_BUILD_ROOT -depth -type d -exec rmdir {}
2/dev/null ';'
%changelog
+* Sat Jun 07 2014 Fedora Release Engineering rel-...@lists.fedoraproject.org
- 0.22-4
+- Rebuilt for https://fedoraproject.org/wiki/Fedora_21_Mass_Rebuild
+
* Sun Aug 04 2013 Fedora Release Engineering rel-...@lists.fedoraproject.org
- 0.22-3
- Rebuilt for https://fedoraproject.org/wiki/Fedora_20_Mass_Rebuild
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[perl-Test-Refcount] - Rebuilt for https://fedoraproject.org/wiki/Fedora_21_Mass_Rebuild
commit 6a264f9620c59a69287adc4e1aa02ec13c9ce176
Author: Dennis Gilmore den...@ausil.us
Date: Sat Jun 7 06:07:26 2014 -0500
- Rebuilt for https://fedoraproject.org/wiki/Fedora_21_Mass_Rebuild
perl-Test-Refcount.spec |5 -
1 files changed, 4 insertions(+), 1 deletions(-)
---
diff --git a/perl-Test-Refcount.spec b/perl-Test-Refcount.spec
index 12d4a11..6f762d6 100644
--- a/perl-Test-Refcount.spec
+++ b/perl-Test-Refcount.spec
@@ -1,6 +1,6 @@
Name: perl-Test-Refcount
Version:0.08
-Release:1%{?dist}
+Release:2%{?dist}
Summary:Assert reference counts on objects
Group: Development/Libraries
@@ -54,6 +54,9 @@ make test
%changelog
+* Sat Jun 07 2014 Fedora Release Engineering rel-...@lists.fedoraproject.org
- 0.08-2
+- Rebuilt for https://fedoraproject.org/wiki/Fedora_21_Mass_Rebuild
+
* Sun Mar 30 2014 Emmanuel Seyman emman...@seyman.fr - 0.08-1
- Update to 0.08
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[perl-Tk-TableMatrix] - Rebuilt for https://fedoraproject.org/wiki/Fedora_21_Mass_Rebuild
commit c8e6c4804830a31d245a365da6a91e0d09658639
Author: Dennis Gilmore den...@ausil.us
Date: Sat Jun 7 06:54:09 2014 -0500
- Rebuilt for https://fedoraproject.org/wiki/Fedora_21_Mass_Rebuild
perl-Tk-TableMatrix.spec |5 -
1 files changed, 4 insertions(+), 1 deletions(-)
---
diff --git a/perl-Tk-TableMatrix.spec b/perl-Tk-TableMatrix.spec
index a12245d..e68db28 100644
--- a/perl-Tk-TableMatrix.spec
+++ b/perl-Tk-TableMatrix.spec
@@ -1,6 +1,6 @@
Name: perl-Tk-TableMatrix
Version:1.23
-Release:19%{?dist}
+Release:20%{?dist}
Summary:Perl module for creating and manipulating tables
License:(GPL+ or Artistic) and BSD
@@ -69,6 +69,9 @@ chmod -x demos/*
%changelog
+* Sat Jun 07 2014 Fedora Release Engineering rel-...@lists.fedoraproject.org
- 1.23-20
+- Rebuilt for https://fedoraproject.org/wiki/Fedora_21_Mass_Rebuild
+
* Sun Sep 08 2013 Emmanuel Seyman emman...@seyman.fr - 1.23-19
- Remove no-longer-needed macros
- Add perl default filter
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[perl-XML-Writer] - Rebuilt for https://fedoraproject.org/wiki/Fedora_21_Mass_Rebuild
commit f60336a0bfee71253653efd267f4df7f51cfb6ef
Author: Dennis Gilmore den...@ausil.us
Date: Sat Jun 7 07:36:38 2014 -0500
- Rebuilt for https://fedoraproject.org/wiki/Fedora_21_Mass_Rebuild
perl-XML-Writer.spec |5 -
1 files changed, 4 insertions(+), 1 deletions(-)
---
diff --git a/perl-XML-Writer.spec b/perl-XML-Writer.spec
index a361d4f..52e219e 100644
--- a/perl-XML-Writer.spec
+++ b/perl-XML-Writer.spec
@@ -1,6 +1,6 @@
Name: perl-XML-Writer
Version:0.624
-Release:1%{?dist}
+Release:2%{?dist}
Summary:A simple Perl module for writing XML documents
Group: Development/Libraries
@@ -66,6 +66,9 @@ make test
%changelog
+* Sat Jun 07 2014 Fedora Release Engineering rel-...@lists.fedoraproject.org
- 0.624-2
+- Rebuilt for https://fedoraproject.org/wiki/Fedora_21_Mass_Rebuild
+
* Thu Feb 13 2014 Petr Pisar ppi...@redhat.com - 0.624-1
- 0.624 bump
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel
Fedora 21 Mass rebuild update
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi all, We merged in the side tags on May 27, and on June 6 kicked off the mass rebuild. we are currently about 1/3rd of the way through. You can see the current list of failures[1] and list to be built[2]. Both lists are updated every 5 minutes. at the end of the initial run though we will file bugs for all FTBFS. Please be sure to get on top of FTBFS quickly as they need to be done before the Alpha Change deadline of 2014-07-22. Dennis [1] http://ausil.fedorapeople.org/f21-failures.html [2] http://ausil.fedorapeople.org/f21-need-rebuild.html -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.22 (GNU/Linux) iQIcBAEBAgAGBQJTkxjPAAoJEH7ltONmPFDRUbcQANL/twn90/M69kMVCI+ZUcj/ MRh9aamT8Dsv0vliP6fikmvNEstWV0x+sKUMNK2DRcmobQAiM6hNtgQEc1uPXdGj z+AszNLjJVeV1ZeQ7yORFjU9rmGPYCyxEC8BqLJy8BnUXZOcWbryEb06/8mYJaz3 QMpE2s1A6H4gbZlkL0VaIadfH0QQH6cjENyIofMOEvaDe0MAkUiC2dobubgkf7Zq yYcl0k391BKoEdZ4HZoqxAspVz0FTdIsX1E9EnuiVr1TxiWxKZOT1S7uz1lyjali gOLndnBhYvPSZU1IdrIjEbJczfRnjmnpX3Mda9UqQoBqajlsTjWwZgt2sIq5KQoO lyDwDjufz2KZ6JlDucgV/GrVh1C/LCPpFOyVJ3ZoDfSVAnAK1ZermxX/oTe4Emwz 6+bBvWplDR+nyGty7pmtgeENXJigm6RrxPIeXclFAYV98bQxdA3efTALW/1iwaBx 6WORl7cjmQipGtQLh2ixY5R+ELYG2eRIK7sqU4eswLqOEl0Ws0ASW7JPtHyCEd2u 3QFC3hw+pgpemvFEXLM/cfRMpY8hv52X7teerISKhu6QUcKX2CZbf+7QKOH8OpXH qFGiw5LqJBHN4BfbjFR3VOjD5Vxuc4T1MP1jXyOM0zUEWoHPjxaRZL7O7t7Ivjiq zielPS7idFpdNuoK0UPV =MtQO -END PGP SIGNATURE- ___ devel-announce mailing list devel-announce@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel-announce
[perl-AnyEvent] - Rebuilt for https://fedoraproject.org/wiki/Fedora_21_Mass_Rebuild
commit d973bad3d7b74b651f7e819bf3898900d94755c5
Author: Dennis Gilmore den...@ausil.us
Date: Fri Jun 6 19:17:10 2014 -0500
- Rebuilt for https://fedoraproject.org/wiki/Fedora_21_Mass_Rebuild
perl-AnyEvent.spec |5 -
1 files changed, 4 insertions(+), 1 deletions(-)
---
diff --git a/perl-AnyEvent.spec b/perl-AnyEvent.spec
index 7cd2afc..6d1d2b8 100644
--- a/perl-AnyEvent.spec
+++ b/perl-AnyEvent.spec
@@ -5,7 +5,7 @@
Name: perl-AnyEvent
Version:7.07
-Release:1%{?dist}
+Release:2%{?dist}
Summary:Framework for multiple event loops
Group: Development/Libraries
License:GPL+ or Artistic
@@ -146,6 +146,9 @@ make test
%changelog
+* Sat Jun 07 2014 Fedora Release Engineering rel-...@lists.fedoraproject.org
- 7.07-2
+- Rebuilt for https://fedoraproject.org/wiki/Fedora_21_Mass_Rebuild
+
* Tue Dec 17 2013 Paul Howarth p...@city-fan.org - 7.07-1
- Update to 7.07:
- The documentation for custom tls verify schemes was wrong; make it agree
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[perl-Guard] - Rebuilt for https://fedoraproject.org/wiki/Fedora_21_Mass_Rebuild
commit 6d909a1802df621a9aa4c9dada9da13177603264
Author: Dennis Gilmore den...@ausil.us
Date: Fri Jun 6 23:58:36 2014 -0500
- Rebuilt for https://fedoraproject.org/wiki/Fedora_21_Mass_Rebuild
perl-Guard.spec |5 -
1 files changed, 4 insertions(+), 1 deletions(-)
---
diff --git a/perl-Guard.spec b/perl-Guard.spec
index 2b5985b..16ed520 100644
--- a/perl-Guard.spec
+++ b/perl-Guard.spec
@@ -1,6 +1,6 @@
Name: perl-Guard
Version:1.022
-Release:6%{?dist}
+Release:7%{?dist}
Summary:Safe cleanup blocks
License:GPL+ or Artistic
Group: Development/Libraries
@@ -47,6 +47,9 @@ rm -rf $RPM_BUILD_ROOT
%{_mandir}/man3/*
%changelog
+* Sat Jun 07 2014 Fedora Release Engineering rel-...@lists.fedoraproject.org
- 1.022-7
+- Rebuilt for https://fedoraproject.org/wiki/Fedora_21_Mass_Rebuild
+
* Sat Aug 03 2013 Fedora Release Engineering rel-...@lists.fedoraproject.org
- 1.022-6
- Rebuilt for https://fedoraproject.org/wiki/Fedora_20_Mass_Rebuild
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[paktype-naskh-basic-fonts] - Rebuilt for https://fedoraproject.org/wiki/Fedora_21_Mass_Rebuild
commit 6e3bba25ff83079117dc24723f7323257f871336
Author: Dennis Gilmore den...@ausil.us
Date: Fri Jun 6 18:28:23 2014 -0500
- Rebuilt for https://fedoraproject.org/wiki/Fedora_21_Mass_Rebuild
paktype-naskh-basic-fonts.spec |5 -
1 files changed, 4 insertions(+), 1 deletions(-)
---
diff --git a/paktype-naskh-basic-fonts.spec b/paktype-naskh-basic-fonts.spec
index 9aef4c8..ca79fa3 100644
--- a/paktype-naskh-basic-fonts.spec
+++ b/paktype-naskh-basic-fonts.spec
@@ -4,7 +4,7 @@
Name: %{fontname}-fonts
Version: 4.1
-Release: 3%{?dist}
+Release: 4%{?dist}
Summary: Fonts for Arabic, Farsi, Urdu and Sindhi from PakType
Group: User Interface/X
License: GPLv2 with exceptions
@@ -53,6 +53,9 @@ ln -s %{_fontconfig_templatedir}/%{fontconf}.conf \
%doc PakType_Naskh_Basic_License.txt PakTypeNaskhBasicFeatures.pdf
%changelog
+* Fri Jun 06 2014 Fedora Release Engineering rel-...@lists.fedoraproject.org
- 4.1-4
+- Rebuilt for https://fedoraproject.org/wiki/Fedora_21_Mass_Rebuild
+
* Thu Feb 06 2014 Pravin Satpute psatp...@redhat.com - 4.1-3
- Resolves bz:1062128 : Making default font for Urdu language
___
fonts-bugs mailing list
fonts-bugs@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/fonts-bugs
http://fonts.fedoraproject.org/
[PATCH] image: support xz compressed raw files
as we publish the raw files on the mirrors we want to be able to request
xz compressed versions of theraw image.
Signed-off-by: Dennis Gilmore den...@ausil.us
---
builder/kojid| 25 -
cli/koji | 4 ++--
docs/schema-upgrade-1.9-next.sql | 9 +
docs/schema.sql | 1 +
4 files changed, 36 insertions(+), 3 deletions(-)
create mode 100644 docs/schema-upgrade-1.9-next.sql
diff --git a/builder/kojid b/builder/kojid
index 14309bb..34c62d8 100755
--- a/builder/kojid
+++ b/builder/kojid
@@ -2737,7 +2737,7 @@ class BaseImageTask(OzImageTask):
we have to do this. rhevm-ova requires rhevm, but if the user did not
request it, we should not pass it back up.
-supported = ('raw', 'vmdk', 'qcow', 'qcow2', 'vdi', 'rhevm-ova',
'vsphere-ova', 'docker')
+supported = ('raw', 'raw-xz', 'vmdk', 'qcow', 'qcow2', 'vdi',
'rhevm-ova', 'vsphere-ova', 'docker')
for f in formats:
if f not in supported:
raise koji.ApplianceError('Invalid format: %s' % f)
@@ -2863,6 +2863,27 @@ class BaseImageTask(OzImageTask):
base.base_image.parameters['libvirt_xml'])
images[format] = {'image': newimg, 'libvirt': lxml}
+# xz compress the raw disk image if asked for
+for format in ('raw-xz',):
+if format not in self.formats:
+continue
+newimg = os.path.join(self.workdir, imgname + 'raw.xz')
+rawimg = os.path.join(self.workdir, imgname + 'raw')
+cmd = ['/bin/cp', base.base_image.data, rawimg]
+conlog = os.path.join(self.workdir,
+'xz-cp-%s-%s.log' % (format, arch))
+log_output(self.session, cmd[0], cmd, conlog,
+self.getUploadDir(), logerror=1)
+cmd = ['/usr/bin/xz', '-z', rawimg]
+conlog = os.path.join(self.workdir,
+'xz-%s-%s.log' % (format, arch))
+log_output(self.session, cmd[0], cmd, conlog,
+self.getUploadDir(), logerror=1)
+lxml = self.fixImageXML(format, imgname,
+'libvirt-%s-%s.xml' % (format, arch),
+base.base_image.parameters['libvirt_xml'])
+images[format] = {'image': newimg, 'libvirt': lxml}
+
return images
def handler(self, name, version, release, arch, target_info, build_tag,
repo_info, inst_tree, opts=None):
@@ -2954,6 +2975,8 @@ class BaseImageTask(OzImageTask):
newname = imgname + '.' + format.replace('-', '.')
elif format == 'docker':
newname = imgname + '.' + 'tar.gz'
+elif format == 'raw-xz':
+newname = imgname + '.' + 'raw.xz'
else:
newname = imgname + '.' + format
if format != 'docker':
diff --git a/cli/koji b/cli/koji
index 504b4ba..1ba273f 100755
--- a/cli/koji
+++ b/cli/koji
@@ -4981,7 +4981,7 @@ def handle_spin_appliance(options, session, args):
help=_(Set the number of virtual cpus in the appliance, +
default is 1))
parser.add_option(--format, metavar=DISK_FORMAT, default='raw',
-help=_(Disk format, default is raw. Other options are qcow, +
+help=_(Disk format, default is raw. Other options are raw-xz, qcow,
+
qcow2, and vmx.))
(task_options, args) = parser.parse_args(args)
@@ -4998,7 +4998,7 @@ def handle_spin_appliance(options, session, args):
def handle_image_build(options, session, args):
Create a disk image given an install tree
formats = ('vmdk', 'qcow', 'qcow2', 'vdi', 'rhevm-ova', 'vsphere-ova',
- 'docker')
+ 'docker', 'raw-xz')
usage = _(usage: %prog image-build [options] name version +
target install-tree-url arch [arch...])
usage += _(\n %prog image-build --config FILE)
diff --git a/docs/schema-upgrade-1.9-next.sql b/docs/schema-upgrade-1.9-next.sql
new file mode 100644
index 000..7d45e91
--- /dev/null
+++ b/docs/schema-upgrade-1.9-next.sql
@@ -0,0 +1,9 @@
+-- schema migration from version 1.9 to next
+-- note: this update will require additional steps, please see the migration
doc
+
+BEGIN;
+
+-- new archive types
+insert into archivetypes (name, description, extensions) values ('raw-xz', 'xz
compressed raw disk image', 'raw.xz');
+
+COMMIT;
diff --git a/docs/schema.sql b/docs/schema.sql
index 56418c9..91bcfd2 100644
--- a/docs/schema.sql
+++ b/docs/schema.sql
@@ -713,6 +713,7 @@ insert into archivetypes (name, description, extensions)
values ('pdb', 'Windows
insert into archivetypes (name, description, extensions) values ('oem',
'Windows driver oem file', 'oem');
insert into archivetypes (name, description, extensions) values ('iso',
'CD/DVD Image', 'iso');
insert into archivetypes (name, description, extensions) values ('raw', 'Raw
disk image', 'raw');
+insert
Re: [PATCH] parallel-drpm enable in mash
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Wed, 4 Jun 2014 18:27:58 -0600 Kevin Fenzi ke...@scrye.com wrote: Createrepo in rawhide now has parallel drpm creation, this patch should hopefully enable it in mash (with 8 workers). Note that it's missing a createrepo version check right now since there's not yet been a released createrepo with the support. kevin Applied thanks Dennis -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.22 (GNU/Linux) iQIcBAEBAgAGBQJTj+aFAAoJEH7ltONmPFDRmWgP/3M/5RXM3g/I1WUyBIV3NqEs 4QuVeuDm9Q1TDpABTsn27RPM58S0+83sWF43dPIeGvRcJ8t2EWedQ5Z0bJF7hekN I7NZrwtd6AGoNp+zxGPzp/uzp1BfeZQUxMWy35vbGc4HQkOBb7v4Jz+0XTka8RwY c2z29wEKqSJKZ7qosOPKe63rd4B+4LeWsg5KzZLwVMdUkTM8qQt94q2ZPAW7Lsmk YbTsdOcz0KTaR3GnALKaYRQ18XYBWNR73xHYLtpJKFz33mvdQVGz2u/FhG8XTCKQ y9+pEIX07WhtfbpgU3Wqbv2kyLKRte5Gp1KW1XWJ0vs4gmkqDM7zCgZ7bpwlAhUr lfYuDwzboZgRio6ibGBrmxretpkkU8avxx1k7taRoC39vijRc0BpHg/RCLyFhfxn 4bFmRU/HUw6TlmNeN1Pclwo2viLWX3UlEeDRM744k4P8KeHDbJbZma3NFXlQ8+9c OCm8IE6jmeiQzaMNyl+k1Yjb+Xki7gQva25fMVoheMV07dbJo9BrJiAyLl1OTpBB wJYsx/b6D/xebtc6toSlyaXljdJWWR1eBesZHNDg31O/BoJNJl9R+skFBYEghy3F otfecsEV/iAUbcY5JVC4c18ljtgam8Y4RSgjHa37OWEJpVTXV+qboBVaJ9Z0+UgK Mqk/MzGaQr2n9dp2Ibct =mgJj -END PGP SIGNATURE- -- buildsys mailing list buildsys@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/buildsys
Re: pkgdb2 post-mortem and strategy for future deployments
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Wed, 4 Jun 2014 11:44:54 -0700 Toshio Kuratomi a.bad...@gmail.com wrote: This came up in a different venue and pingou and I have continued to talk about it. Seemed that this was the right place to bring the discussion though. Some observations: * Pkgdb2 and a call for testing in staging was announced well in advance of the deployment to production (good) but not everyone understood that we were going to be breaking API (bad). * There were people inside of fedora infrastructure and outside of infrastructure who were surprised by the API break. There were also some community members and infrastructure members who heeded the call for testing and both gave feedback and ported before the deployment. * There was a FAS2 update that pkgdb2 depended upon. That was also pending in stg for a long time and also had some minor API changes (IIRC, all unintentional. I hotfixed one of them that was simply a bug last week). These also caused issues for some scripts. * Unexpected problems: we had things that we didn't know used the pkgdb API, things that weren't tested in stg because stg couldn't replicate that part of production, and things that were ported but mistakes caused the ported scripts to not be deployed or to point at stg instead of production. I saw that we had the right people on IRC throughout the day working on analyzing and patching all of the broken things so. However, this was somewhat by accident and some of those people were surprised that they spent their day doing this. Some ideas for doing major deployments in the future: 1: We have to make people aware when a new deployment means API breaks. * Be clear that the new deployment means API breaks in every call for testing. Send announcements to infrastructure list and depending on the service to devel list. * Have a separate announcement besides the standard outage notification that says that an API breaking update is planned for $date * When we set a date for the new deployment, discuss it at least once in a weekly infrastructure meeting. * See also the solution in #3 below I have a suggestion make everything provide and validate api info. this is something koji does, though we to date have not broken api, we expect we will do when we start on koji-2.0 so each app would provide a getAPIVersion() function, then the consumers validate that they know how to talk to that API version. for bodhi for instance apps could check for api version if it fails assume version 1 and then be able to support both version 1 and 2, when we deploy live bodhi2 the clients like fedpkg update will transparently switch over. Dennis -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.22 (GNU/Linux) iQIcBAEBAgAGBQJTj51hAAoJEH7ltONmPFDRZB4P/1R3cdAlSMPatOVoGw8QYgzq khMZKCaNjQT0V3KI5b4yl0MA6VqUXjlhT9SuscWMuQD8eADkizXbVzyHUQxMAz/F rlAeezgHss/LRt51TmrHhpBupuzDQKHtzh1wrlz1b6KQgnR7ZuyLF0pgdgN4EaiY Ydtpj0pg7Bm+4x98TgmfoCcugiLuKNSFVyxYCc4Erkr4YB1BEF6VhGZJ1yvlkq23 hugsNbLx6/oGKg18U5QDKPmwl/AuOSOK7hVz+nHDQmjn9x24l2x/yq9KAN8++RMN 2kfqwM3QEJ+qqMoauZc8JiLxJYCATLk3xmrfUKlKF29D1Wy13riburt+VXmmCxyt PP8QSRWgTesJzecN7YS58Q8HG8Fu209K9mpVLGExg9KEseAAU+Ccm+B2er02gDTw VJKI/fP341IerEVtF2BFKd6FHhe3yPpzKpAe7pbOcTOi1rDmZSEI9Z7kuLucK/EE tQSm5ZyXqgOdAvC3nhvTwm1OSRvjDb4zcg+p+Uwgxw/vs6V9c8cxcmQlGQGv6HDd 0VBKsyzhu1cVWJy0pCJHUa4qeztxTkBN167lISxtivTIGhdaIl/HrnEJjBDmXWCO FMaM/sWVKxMPTetkFFJ96AoxV1E8qzSAXdq2+CqfVQpgPETMMnUsUO7sfTHXGX2i UAVScMl0M1PBZos1upa6 =0xdj -END PGP SIGNATURE- ___ infrastructure mailing list infrastructure@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/infrastructure
Re: rawhide installation problems
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Sat, 31 May 2014 12:53:21 -0400 Gene Czarcinski gczarcin...@gmail.com wrote: Currently, it is a bit difficult to do any testing which involves doing an install. First, the gui is broken because of a gtk3 problem so you cannot do a gui install: https://bugzilla.redhat.com/show_bug.cgi?id=1102793 [Is it really going to take 2-3 weeks to get this fixed??] So, lets try a kickstart TUI install: https://bugzilla.redhat.com/show_bug.cgi?id=1103441 There is a message about not having a network BUT /run/install/ks.cfg has the kickstart file I specified with http:// Fortunately, not all is lost because Live Install is currently working. [rsync update in the 20140531 rawhide]. Comments? Any circumvention available? The last good DVD iso I have was created based on the 20140528 rawhide and, I believe, requires at least two CPUs (virtual or real). Gene after some debugging of a bunch of issues this week we finally got the nightly automated cloud images building using oz in koji http://koji.fedoraproject.org/koji/tasks?state=allview=treemethod=imageorder=-id is all the tasks. http://koji.fedoraproject.org/koji/taskinfo?taskID=6914183 is last nights task. it installed just fine doing a kickstart install. you do have to specify the device in your network line. you can always do a text mode interactive install also. Dennis -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.22 (GNU/Linux) iQIcBAEBAgAGBQJTihGzAAoJEH7ltONmPFDRxvAP+QHTcezGLDU0/TuseBjvcRb9 zCarCJa4qKR90ial5hnxiBOVcfpyNIqGuCR1qTssGB8iss8CyKa4WkBzMUJoO/pn IN9pjDqRykUN2mbT6+KtJtwg5nS3r/w7aUAJzLPI2C9A1TPywkjNh7e9n7bKaKG7 W08EDdV/JKNiZt+Uqu5sfVxu5q9LbIeR9tJFYq2lUY91KCrMWxiywU7GtXVBcssd MfJuvQmkJM6qtNMAZ7gcEefpW4hNPv1Sx2ddn+P00+tLNEjieUQaHUGoagPwGSnP +ZbumTnWWtP3z8AlbcreOyHDYwB+gnxZp+YUVBtqmhG2CaaVvtpOIGBoEkDY410E 5rhO2vmapkkMb463tuOjQK3AIyL/q9G+KQ3JOfrKDtOVXFIOsD0MIFyDqvBmbkWX ra97ur/pNhKZCjWGDLy/4DlzyyPobG5Ks28iXvRbK1AzQA3EXyj/chYO3d+lOmRO /G1+Q1MLN6OzmdUMkvXyere5HlwDpNa4PQ8EoL9EEsGu/Vn8ctiSnKs3NYeqa8zA LFFo/q5KCbmk70xW6Bg5hOzZgPUtFWKJe+Z2HdHFGjxPRP0Orzf5cNYjfpovOzPY W2vptiglZFL+RhaVBjpbzvkopGXb2//MsFIxqT5dr9I+6lG51D28Bx6B/UaithxP yRIREOJL+znX3+1R2uL0 =gyQE -END PGP SIGNATURE- -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: [fedora-arm] U-boot plan for F-21
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Fri, 30 May 2014 15:41:55 +0200 Hans de Goede hdego...@redhat.com wrote: Hi All, Are we going to stay with 2014.04, or are we going to move to 2014.07 ? The main reason I'm asking is because of Allwinner support. Currently we (the linux sunxi community) are making good progress on getting sunxi support into 2014.07, so if we're going to go with that then I'm going to focus on that. But if we're going to stick with 2014.04 then I'll try to prep a patchset on top of what we already have to add support for more boards. We will move to 2014.07 quite possibly also 2014.10 I am just way behind on u-boot work right now. Dennis -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.22 (GNU/Linux) iQIcBAEBAgAGBQJTiJBlAAoJEH7ltONmPFDRVfkP/2Ru3IeUXIk20tfy1CeW9mN1 KhrkUCsz22iEIh5x9lLtKL9Y82he/K3VmtegADdmlZjC/MzS6tlg30Vdlf9Pqnbw zQP4XwuAqfwJh5R+BBU0d26Ov9AFNlpndOn/7sJOOf9GjKrwwRrlfahSwhrlbba3 O5UcH3uOQccukUW4OwbUx1UwkE/QdS/HN31KhB9H0lEvtpbbNIgolPk9uAO/RKUt vORM99+ivX5xogQ7aN/Be0t6p5EkrvtxsLDR3iU3wh/+bHUnLmMoXKm+3ceA8kjT 0buk7ESo4gHQRgURw1tV/Kb2RQrqVHd2QFl8wce/5O674Cio8IWuljQz0hsI7AGr /uIP0oOtG63dlcw1QewR4+8szK2z6Enje/ehsSv//k9K9aqmsifWebotjqvuH5h8 62xuH957TXlWW83BM3Tkiv3ToilFj085eMZqZSIsm24Clo2a3qqb5kaPum/JSOuO OzOt2jTAFtFNXuqhb+Iz0V+0klomJr5d99Wi9Q3EdweTs6A41L/VVt/1jCYdeRA3 JhRZTEwnnb1O17BUPXNdteNRu/+O9AtSfCNl0TdXITIJKuDbAneV5xucz1izJpY/ gx3n8cXOwPRkSFjrODcNifkVbZtaOEVL5K1wJZIc3BayzmJoB4OMVBdmPlvfJhup fkTKIrNY40L4l/iyMe20 =rlDU -END PGP SIGNATURE- ___ arm mailing list arm@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/arm
Re: [fedora-arm] Fedora Server product delivery
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Thu, 29 May 2014 13:13:19 -0700 Adam Williamson awill...@redhat.com wrote: So, I wish we'd noticed this sooner, but hacking at the release criteria today I happened to notice a bit of a problem in the Fedora Server product planning. The Server PRD states (https://fedoraproject.org/wiki/Server/Product_Requirements_Document#Delivery_Mechanisms ): Fedora Server will produce two main installation resources, a netinstall image and an offline install iso image that allows one to install and configure featured roles offline. the Server tech spec states (https://fedoraproject.org/wiki/Server/Technical_Specification#Supported_Architectures_and_Install_Media ): Fedora Server will run on and provide install media for i686, x86_64, and armv7hl servers. There will be two official install media for the Fedora Server A network installation media (either a traditional netinst.iso or a boot.fedoraproject.org style) A local installation media providing the default package set as well as any featured roles that are meaningfully installed without a network connection. The local installation media will be allowed a maximum size to fit on a 4.0GB USB device. The local installation media can be pointed at network resources to make available a larger package set. So...we're planning to release Server with ARM as a primary supported arch, but so far we'd only planned to do two traditional install media (a netinst image and a DVD-type 'trad installer plus packages' image). Fedora ARM releases so far have emphasized disk image-type release media much more strongly than installer release media, and I believe the ARM installer media only work at all on one particular ARM platform. I need to work on some patches for anaconda, but the plan is that with the changes I've been working on for u-boot that anaconda will be able to just work on most arm systems. simply that is only a pxe tree install. It shouldnt take too much work to be able to make a install image as well as a boot image to be able to launch the installer. it would require some work on tooling to setup the image to boot on systems that do not ship with an onboard u-boot. but we really need that work done for the existing installed system images. So, the reward for work being more work ;), I've been nominated by Server WG to liaise with ARM team on this one. What should we do here? Is Server going to have to grow a set of ARM disk image media, or is there any possibility of it being plausible to release Fedora 21 with just installer-type images for ARM? It shoudl be possible to have only installer images for arm for the Server product Looking at it in a bit wider scope, what kind of media has the ARM team been expecting would be part of the Fedora 21 release? If, say, we did make a set of images just like images done for Fedora releases so far - the appropriate set of disk images plus installer media for whatever ARM platforms are 'supported' - only had those be 'Fedora Server' media, would it be OK to release those as the only Fedora 21 ARM images, or at least the only official / promoted / supported / whatever set of images? Or would ARM team also be expecting to have a 'generic' set of ARM images produced? I realize that's a lot of questions, sorry! Any thoughts would be appreciated. Thanks! We have dropped the vfat images so we only have one type of preinstalled images now. I am honestly pretty sure we have not thought greatly about what the actual deliverables for f21 will be and we need to. Dennis -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.22 (GNU/Linux) iQIcBAEBAgAGBQJTiMJaAAoJEH7ltONmPFDRmrsQAJ4MK7fQXq9fTIwokB7pgX4D FdyAnXFF9Tf8EruSrCJGeh3k+O+HpZnoomiM/TP4r2gk5i3WXD6CYt9e7nwoGXmv EdW+uI04OsOzggJJ0UB6UlomaZ6wqp7JBItdG+42HKAuoqavD9H+WB5G3SHwv/wv 0SCGr8devXicLBQQpK4Sa+7032NE5XFsVmm8stKMi7u82ADE0ptU9lATJHUjSqVs etD6zSl5LKor7MjjaV+DMVvpMMsyyiMB6+CCIS29hDD7azpx2fe4XtTwyUDw07x5 MGepuGIyZL0Ipjk+86O+1B1MDiytMH2w1FrYYfTAgmVReoXR21aDaEL9vV+a9z5y 3PWL33CQrFmv4fm1hhNMDyj8rCHrtNQFODDKERzBukWngoT+B5BqlFr3xMaX4a26 szpRD7T/aknVd+I902CfSHMEqlvFa2CbVs1wH8hSOuA0se8ZLJ2B+36NSITKNPGb 9CdXaLgi5IWgCo52FAIlRTNDNrCFvlJGeAYRkNkObD66yvr33gVcLf1/4BNakSsz lgg6ZnplUfv+8B67MvNAWKdr2lNtW2B4dq2cSpuRl+PA4QqPBZnsxmeS9fRGcQ45 0mQFJHidAL+ff/i6Q4xvt2avSu4AMRW0yPrkWkI8PDHNcJlrMLHfvV+oSJnQIBGg TLSKGd0Bn5wp7B8sPY7r =+bom -END PGP SIGNATURE- ___ arm mailing list arm@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/arm
Re: [PATCH] support ppc64le in mash
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Tue, 25 Mar 2014 15:35:20 -0500
Mark Hamzy ha...@us.ibm.com wrote:
Add support for the ppc64le architecture in mash.
---
mash/arch.py | 1 +
1 file changed, 1 insertion(+)
diff --git a/mash/arch.py b/mash/arch.py
index a2b0f79..cbeb24b 100644
--- a/mash/arch.py
+++ b/mash/arch.py
@@ -19,6 +19,7 @@ compat = { i386 : (athlon, i686, i586,
i486, i386, noarch), ia64 : (ia64, noarch),
ppc : (ppc, noarch),
ppc64 : (ppc64p7, ppc64pseries, ppc64iseries,
ppc64, noarch),
+ ppc64le : (ppc64le, noarch),
s390 : (s390, noarch),
s390x : (s390x, noarch),
sparc : (sparcv9v, sparcv9, sparcv8, sparc,
noarch),
applied thanks
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.22 (GNU/Linux)
iQIcBAEBAgAGBQJTh8MaAAoJEH7ltONmPFDR41QP/1wK79CD22WEJbWuna/MSRML
aRqv/+UomQqx2Ar1qQXvZ6EGDLtFVRcDjjeRCdgGzzFGTQEGfSu9Pa84iuiCybeV
suCkS9B91FjB10sL5+zE36QNMcO5Ntxsv9XxZ3jtLxPb6s3DgCN0iaOa24vB8En0
TCgXz9R+idhGQSNMhgFniR+d8YGhS2wzKbL7H62zzvbkbNlaGV3/J4whDDffo5hq
UCmhjVHExABikWntRfrhEYCe596odPO+F/q8RDDg3QYHPpAm8mYFKJNhpW2V9grA
UQYRaaKKH7ueAToCTX0xvHQvRDdgnIAfg9KeIG08w6xyu5Nyo3grRzu1/d7NaKEv
/foIh0+TF62JBWRfIqef1+yWdZV1x5jFDlXS9iJO3sk4w5zaMsawD+ltC+WTziib
00HqRoKJHY+UKWSXnkWd+H0hRy/wNili/+1ubf5H3Qc3NXuR4fUPXMdqckH9ZKww
Xnss+d/dx0KMHZXHMapXCVtV2jPPXXrzwCP8w4pSVGV9QLtu8kfRORrkLSrNWp0A
9nUawyw+NocCRxmGNetmVFgoLP6xDKvV80dsHx1aKj+muCkYtxjLgsKbVHb4Vi44
BSLU0RM6NJHgudIJ8S13vYOM8wbrYkjghi4pR8UJPdN2MQP+j+UPU/L5ph9NpiXu
MdU8o7DsUP53px2+uQUV
=HR9N
-END PGP SIGNATURE-
--
buildsys mailing list
buildsys@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/buildsys
