Re: "Workstation" Product defaults to wide-open firewall
Kevin Kofler chello.at> writes: > I just happened to look at the firewalld default settings, and I was not > amused when I noticed this: > http://pkgs.fedoraproject.org/cgit/firewalld.git/tree/FedoraWorkstation.xml > > > > > This "firewall" is a joke! ALL higher ports are wide open! I just did a check of all the service ports and various higher port ranges using ShieldsUP! ( https://www.grc.com/x/ne.dll?bh0bkyd2 ) and AFAICT, the only open higher port is the one random port that Transmission is currently using. (BTW, Transmission now seems to automatically open an incoming port - in F20 and below I had to tell Transmission to use a fixed port instead of a random one, and manually open that port in the firewall.) This is on a system clean installed from Fedora-Live-Workstation-x86_64-21-5.iso. -- 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: "Workstation" Product defaults to wide-open firewall
I just verified that I have the same default configuration from a clean install. Not good at all. I expected more. -- Christopher L Tubbs II http://gravatar.com/ctubbsii On Mon, Dec 8, 2014 at 1:41 AM, Kevin Kofler wrote: > Hi, > > I just happened to look at the firewalld default settings, and I was not > amused when I noticed this: > http://pkgs.fedoraproject.org/cgit/firewalld.git/tree/FedoraWorkstation.xml > > > > > This "firewall" is a joke! ALL higher ports are wide open! > > There had been a prior discussion on this list where they wanted to disable > the firewall entirely. We told them that that's a horrible idea (which it > is, of course!). But the result is that they implemented this "solution" > which is almost entirely as bad, and which additionally gives users a false > sense of security, because a "firewall" is "enabled" (for a very twisted > definition of "enabled"). > > IMHO, this is a major security issue that MUST be fixed. It also shows what > horribly bad an idea per-Product configuration is. > > Yet another reason why you should NOT use "--product=workstation" to > upgrade > your F20 to F21 (ALWAYS use "--product=nonproduct"). Installing the > "Workstation Product", or upgrading to it, will leave you with a totally > insecure system. > > Kevin Kofler > > -- > devel mailing list > devel@lists.fedoraproject.org > https://admin.fedoraproject.org/mailman/listinfo/devel > Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
"Workstation" Product defaults to wide-open firewall
Hi, I just happened to look at the firewalld default settings, and I was not amused when I noticed this: http://pkgs.fedoraproject.org/cgit/firewalld.git/tree/FedoraWorkstation.xml > > This "firewall" is a joke! ALL higher ports are wide open! There had been a prior discussion on this list where they wanted to disable the firewall entirely. We told them that that's a horrible idea (which it is, of course!). But the result is that they implemented this "solution" which is almost entirely as bad, and which additionally gives users a false sense of security, because a "firewall" is "enabled" (for a very twisted definition of "enabled"). IMHO, this is a major security issue that MUST be fixed. It also shows what horribly bad an idea per-Product configuration is. Yet another reason why you should NOT use "--product=workstation" to upgrade your F20 to F21 (ALWAYS use "--product=nonproduct"). Installing the "Workstation Product", or upgrading to it, will leave you with a totally insecure system. Kevin Kofler -- 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: "Tick-tock" release cadence?
On Thu, Dec 4, 2014 at 6:42 PM, Matthew Miller wrote: > On Thu, Dec 04, 2014 at 11:02:28AM -0600, Bruno Wolff III wrote: >> >For us, that would mean alternating between concentrating on release >> >features and on release engineering and QA process and tooling. During >> >the "tick", we'd focus on new features and minimize unrelated rel-eng >> >change. During the "tock", we'd focus on the tools, and minimize change >> >that might affect that. >> Presumably we wouldn't need to do this even up. We want say 2 to 1 >> or 3 to 1. > > A waltz beat, say. :) > > > >> >* prevent compounded delays caused by intersection of feature needs >> > and releng changes >> There was a bit of that this time. But this was a really big change. >> Are you thinking we will have this scale of change for releng on a >> regular basis? > > > So, frankly — and I think the rel eng team won't be offended here, > because they know it more than anyone! — we're beyond what the current > releng overall design can really scale to, and it needs an order of > magnitude _more_ work in order to allow us to keep growing. (And that's > not just with the Fedora.next stuff or new things like Atomic — the > sheer _size_ means composes are going to take more than 24 hours in the > forseeable future.) No offence taken but it does depend on a number of things, some out of our control. We're working to be able to parallelise a bunch of the process but part of that isn't fixable with code alone. Parts are being improved with more human resources for time (like me) and some is due to things like IO on infrastructure. Peter -- 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: "Tick-tock" release cadence?
>> What do you think? Would this help towards the goals listed above? >> Would it help _other_ things? What downsides would it bring? > > I think it is not useful to set up a general mechanism of alternating > releases and borrow a name for it before you've discussed what concrete > tasks in release engineering and qa there are that we just cannot get > done. You're essentially asking ask to buy the cat in the bag... > > If we agree to this, will we get > > https://fedorahosted.org/rel-eng/ticket/5721 This was discussed again at Flock and is currently awaiting two things from Richard/Kalev and not rel-eng at all. It would have been delivered in F-21 time frame if those things were delivered in a timely manner for beta. Peter -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Review swap -- Budgie Desktop
I can help as several months ago the budgie music player was packaged by myself. At that time the desktop was however unstable. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
python-dateutil update
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi all, python-dateutil is old[0]. Fedora is carrying version 1.5, and upstream is up to 2.3 . If you're receiving this mail directly, you are a maintainer of a package that depends on python-dateutil, and we need your help. There are some changes that might cause breakage for you if the package was updated. Luckily, there is a python-dateutil15 package that could continue to provide the same code. The maintainer of python-dateutil15 has agreed to carry the one patch that makes it different from python-dateutil. After this update to python-dateutil15, maintainers of dependent packages[1] can simply submit an update with the new requires for business as usual. python-dateutil can then be updated to the current version, and packages needing *that* can move forward. I intend to file a bug against python-dateutil15 for the patch, a tracking bug that's blocked by tickets filed against individual affected packages and dependent on the python-dateutil15 change, and the tracking bug will block the cited python-dateutil ticket. It should be relatively easy to see when each step is complete, and a relatively painless change for the maintainers involved. Please reply here with any concerns about this process that might not have occurred to me. [0] https://bugzilla.redhat.com/show_bug.cgi?id=1126521 [1] https://immanetize.fedorapeople.org/python-dateutil.requires - -- - -- Pete Travis - Fedora Docs Project Leader - 'randomuser' on freenode - immanet...@fedoraproject.org -BEGIN PGP SIGNATURE- Version: GnuPG v1 iQEcBAEBAgAGBQJUhOZ4AAoJEL1wZM0+jj2Z4jUH/A7d3onPkvwUNKUo5uCDXBJb WIXOKtCZbK3LrBK7VSUk7px4cfOjcFumRCs+ZSXSq4URIRd8pxCFbcXWTpfk1fq3 uoxeZDXiK9Ab9P+2ksPDlPODuDxjoj77Pa79YNnoxUTL2tvdz2YcrlIqOrgJa2+h uopMO8BF9qE6t8KXfhiGkP2w/EF6rfqrUaL0F7xvVzyDfkA/akS0LPcRyfQ0fOi6 Tbfr9Qoj54dpJWLjlBXky0RLodMXl2oFOnotdhmqAF9RRIbotYG03NXH9CeQn3SU wdQm/RdXgQQyoTbghwq8k0yGWsPrhm4AyeC++XTKUtBFZwEEGxVj+2kAnpvJ24Q= =7BTl -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: Not-very-reassuring info on FedUp wiki page for F21
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 07/12/14 22:00, Matthew Miller wrote: > On Sun, Dec 07, 2014 at 01:49:47PM -0800, Samuel Sieb wrote: >>> [1] https://fedoraproject.org/wiki/FedUp >> I was about to go edit it, but I see that mattdm has already >> fixed it. :-) > > Very quickly. If you have further refinements, go for it! > Very quickly indeed! Thanks a lot! :) Gerard. -BEGIN PGP SIGNATURE- Version: GnuPG v1 iQIcBAEBCAAGBQJUhNe+AAoJEG7cfkpivEoVdesQAJgC0yMkqnU9nedn5AgelqdP jkrxmAGJyu4awaaO/YLfa/1Rky+6H3QnNeXuM5y26TwxugDqV5XlbN+kwfOo4dfK +ntt/QaOSphqYR4TJcGaK0ETSMvyKsnZ+VkvE84vILZ3M9Fpf9vZxY1QgBNigqNA pWvAoJRBL7rl9TZeyFBcxjQGRVD5iJCgs2AjI1xQsesN3fpdV8W5ZlJGJQDDe/tY zAZsuTI751NgMEmw63OBFtkzKb0wCtSxLpCQ+cX3+VVaLI9bigj4qs22OHohggvA vKPMopEynvuvYdFkgICvF/DjlEPhQqhMd2G5/iAPSGqHcBx0AgI4R4Pmbe1jNdr7 j3F5mpHKpFSHnKbQkn6tJW9EyzG5Ae69/+ba4hptTkB+KFMFE1hYO0XJ5JGGZubV ED+BdLmgg7FI3d79g6jq5dLo27GgE3do5qmrWoPZBZQUi9O9vr5U5khP4w6ieDo4 BFHb+ku5GGvSSBvXPj4enfhvSmarRDy1ZYH0eGdJtLNhW9TEv7EINs4ff233lmBs dVclj/O9nr/EFI/3dr0QnW3q6WzFO3MuVVKyNzau67HeQb7NXFcUpXpSHKFEU3xV WqE/mw1FW3OTs4TQ1LDeR9otugU5+bsXnqbv28iwWiIw5KFWXzu9ecNUkJYwx9ox /bn9Ay8eu85KP5pkxa0E =qbpA -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: F21 LIve USB failing on Chromebook
On Sun, Dec 7, 2014 at 11:53 AM, john.tiger wrote: > usb boots fine on macbook air (WITH holding option key) > > on Acer 720 Chromebook the install screen shows - then fails There should be logs in /tmp that would be helpful in determining what the problem is. Most valuable is any file starting with tb- since that's a crash traceback, then program.log, and storage.log. It may also be helpful to have output from dmesg. It's easier to attach these things to a bug report, and then reference the bug URL here. > Since the whole point of Live CD is for non-Fedora savvy people to try > Fedora (and Linux): > a) Install either needs to get fixed - or right memory setting needs to be > figured out > b) instructions / FAQ need to be more clear, easier to understand - they are > not - a better FAQ is needed (we're happy to help here if we know where to > submit a new draft It's probably a question for docs team if it's desirable and feasible to have model specific install instructions, single page wiki style perhaps, for cases where the standard installation guide instructions need supplementing. > > btw since most new people using newer laptops will have to create an install > usb - we have found the dd methods do not seem to create bootable drives and > the instructions to make it bootable are obtuse at best (is it toggle N or > toggle X - too confusing) - we did find gnome-disk-util works very good > both with Nautilus and xfce Thunar - no idea how it works from Windows which > many new users might be coming from. Can you be more specific? Do you have any bug reports for this? The description above makes it sound like this is a blanket "does not work" problem. There is fairly extensive testing of the dd method of creating USB media. Pretty much every smoke build, and all TC and RC candidates get written to USB media using dd. There's always the possibility of hardware edge cases so the more people testing with a wide variety of hardware the better chance of catching them in advance of release. https://fedoraproject.org/wiki/Test_Results:Fedora_21_Final_RC5_Installation?rd=Test_Results:Current_Installation_Test#USB_media -- Chris Murphy -- 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: Not-very-reassuring info on FedUp wiki page for F21
On Sun, Dec 07, 2014 at 01:49:47PM -0800, Samuel Sieb wrote: > >[1] https://fedoraproject.org/wiki/FedUp > I was about to go edit it, but I see that mattdm has already fixed it. :-) Very quickly. If you have further refinements, go for it! -- Matthew Miller Fedora Project Leader -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Not-very-reassuring info on FedUp wiki page for F21
On 12/07/2014 11:46 AM, Gerard Ryan wrote: I think this could be improved to give more "sure" directions. I know it's a wiki, and "just edit/fix it", but I don't know enough about what it should be to confidently change it. Could someone who is more sure than I (and the original author, apparently) of what it should be weigh in? Is it just a case of removing the "apparently"(s)? [1] https://fedoraproject.org/wiki/FedUp I was about to go edit it, but I see that mattdm has already fixed it. :-) -- 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: Not-very-reassuring info on FedUp wiki page for F21
On 12/07/2014 11:46 AM, Gerard Ryan wrote: I think this could be improved to give more "sure" directions. I know it's a wiki, and "just edit/fix it", but I don't know enough about what it should be to confidently change it. Could someone who is more sure than I (and the original author, apparently) of what it should be weigh in? Is it just a case of removing the "apparently"(s)? Yes. I've used that option several times. -- 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: Self Introduction: Michael Spahn
On Sun, Dec 7, 2014 at 11:22 PM, Michael Spahn wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > Hello, Hi, > > my name is Michael Spahn, I'm 24 years old and living in Hamburg, Germany. > > I'm using and loving Fedora for several years. Starting with Fedora 8 > and supporting Fedora since 2009 as an ambassador I decided to start > maintaining packages. Cool. > > I'm working as a software engineer for a small company. Great! > > When I tried to start as a packager for 2 years I could not find any > software I would like to maintain which is not already well maintained. This is Fedora! > > I still don't get why some guys are complaining about missing software > in Fedora; in my opinion we have some of the best software repositories. > > But finally I friend of mine created a useful peace of software I'd > like to bring to Fedora and packaged it. I have a pending review > request and already asked Christoph Wickert about a mentorship. Not sure can Christoph be mentor for packagers.. > > I hope a fulfilled every step according to our wiki to join this group > of Fedora packagers :-). > > See you guys. You're welcome! > > Regards, > Michael > > -BEGIN PGP SIGNATURE- > Version: GnuPG v2 > > iQIcBAEBAgAGBQJUhLcDAAoJEGtRNj3Wo+zB+N0P/A9hxjMSJRO5FwD/qocdi+kq > /LDxbZP30Vv5KTSdv/9juA7VQ8VN4mu+nfS6iyt1x74j+Ly5ZT29qaFDI7T7IyHo > rE5IM80Wcd8TOFicfFgtVKzJolaNeSzP868N7mAoUDAqw0Im7PZscewjMYKkB9zR > VTSD3+A0RwQDWmDZFtkfnHy+l2XJrR+YWpk/enz5v8+GbM/xTTGo7cpy4MDKwbrF > +P2leaaLro1afEbtCZ7KE3PMsign+GnihxLoM6PsxXzQXOh2IDRWGlJdbjoAa869 > 4271fE+/erfjXIyV81dcnOYYcymUG5mdkUtk54YlosVRWrFfwhRv8pQUZ/Pbmjn+ > 98i+7SJISTEERhkvK7Xg9lRIYcqO3FJb/I7aXbbmuhtrKgovqUmfr87qC14Uuuwt > rOMtLDBGI4si8p2gBK4yE0vSAETMUXj2Kl8AIaQTSpsG+tn0CRpRc4LJkb0GNlh6 > cBraZpK2CbPAMxxaq62kKgKWWC0CUDO6CuTzyFJjw4jn1V3akPxhKnX2Go73ibPR > phIDHMaD4hqQ+qgPeSqMFh7tZ6Jk4fSVAiNVh6KghMipuCTRIiB8eSvAc0uHRqKt > 4hNRFdcL0ogieJWhGrWH3v//4FswojXhnOeRGfEWUi6f+2n+L9OAf5ifDbafW1sb > Nk1rnLp4yk1RfHOCQkUE > =P6LV > -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 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Self Introduction: Michael Spahn
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hello, my name is Michael Spahn, I'm 24 years old and living in Hamburg, Germany. I'm using and loving Fedora for several years. Starting with Fedora 8 and supporting Fedora since 2009 as an ambassador I decided to start maintaining packages. I'm working as a software engineer for a small company. When I tried to start as a packager for 2 years I could not find any software I would like to maintain which is not already well maintained. I still don't get why some guys are complaining about missing software in Fedora; in my opinion we have some of the best software repositories. But finally I friend of mine created a useful peace of software I'd like to bring to Fedora and packaged it. I have a pending review request and already asked Christoph Wickert about a mentorship. I hope a fulfilled every step according to our wiki to join this group of Fedora packagers :-). See you guys. Regards, Michael -BEGIN PGP SIGNATURE- Version: GnuPG v2 iQIcBAEBAgAGBQJUhLcDAAoJEGtRNj3Wo+zB+N0P/A9hxjMSJRO5FwD/qocdi+kq /LDxbZP30Vv5KTSdv/9juA7VQ8VN4mu+nfS6iyt1x74j+Ly5ZT29qaFDI7T7IyHo rE5IM80Wcd8TOFicfFgtVKzJolaNeSzP868N7mAoUDAqw0Im7PZscewjMYKkB9zR VTSD3+A0RwQDWmDZFtkfnHy+l2XJrR+YWpk/enz5v8+GbM/xTTGo7cpy4MDKwbrF +P2leaaLro1afEbtCZ7KE3PMsign+GnihxLoM6PsxXzQXOh2IDRWGlJdbjoAa869 4271fE+/erfjXIyV81dcnOYYcymUG5mdkUtk54YlosVRWrFfwhRv8pQUZ/Pbmjn+ 98i+7SJISTEERhkvK7Xg9lRIYcqO3FJb/I7aXbbmuhtrKgovqUmfr87qC14Uuuwt rOMtLDBGI4si8p2gBK4yE0vSAETMUXj2Kl8AIaQTSpsG+tn0CRpRc4LJkb0GNlh6 cBraZpK2CbPAMxxaq62kKgKWWC0CUDO6CuTzyFJjw4jn1V3akPxhKnX2Go73ibPR phIDHMaD4hqQ+qgPeSqMFh7tZ6Jk4fSVAiNVh6KghMipuCTRIiB8eSvAc0uHRqKt 4hNRFdcL0ogieJWhGrWH3v//4FswojXhnOeRGfEWUi6f+2n+L9OAf5ifDbafW1sb Nk1rnLp4yk1RfHOCQkUE =P6LV -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: Not-very-reassuring info on FedUp wiki page for F21
I did some testing of fedup on external USB HD- bios boot for #fedora-qa [1]
1-) Backup your work before attempting this
2-) fully update your f20 install (disable any no-fedora repositories)
3-) In root terminal:
yum update
yum install fedup
fedup --network 21 --product workstation
Possible commands:
product [workstation|server|cloud|nonproduct]
use --product nonproduct for KDE ;other spins and minimal :
fedup --network 21 --product nonproduct
reboot system
"System Upgrade Fedup" on boot menu
here is how I did it: (fedup-dracut-0.9.0 )
NOTE: Terminal display stops updating at about 68%
TO FIX: Hit {alt} key or switch to {alt-f2} then {alt-f1}
[1]
http://wiki.sugarlabs.org/go/Fedora_21#fedup_Updating_f20_desktop_to_f21_workstation
Tom Gilliard
satellit on #fedora-qa
On 12/07/2014 11:46 AM, Gerard Ryan wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Hi devel,
On the "Important Changes in the Upgrade process to Fedora 21" on the
FedUp wiki page[1], I see the following:
Apparently there will be a new option "--product=" and
before update you will be required to choose one of the
possibilities. To obtain the old behaviour apparently
--product=nonproduct should be used.
I think this could be improved to give more "sure" directions. I know
it's a wiki, and "just edit/fix it", but I don't know enough about
what it should be to confidently change it. Could someone who is more
sure than I (and the original author, apparently) of what it should be
weigh in? Is it just a case of removing the "apparently"(s)?
[1] https://fedoraproject.org/wiki/FedUp
Thanks a lot,
Gerard.
-BEGIN PGP SIGNATURE-
Version: GnuPG v1
iQIcBAEBCAAGBQJUhK6lAAoJEG7cfkpivEoVIX8QAIC+FDz+dtD8GKFpq+xWOyxj
3JO0GRPw9T4UTbK/GqL30n3SFP0syHDcqIjFHhieQOOtGPslDorpVbEugmhByilj
H+1PXaWu7Di4nLFWsr0oAiO6xld1ZijsHo5das1ELOD/j2M+C7UR9N7VFZqR2PPk
pqhCNGiZiihm75ucoZvIsdkGqBQqqbKGCMeDB/3h2dq6Ph9D/0X1nVDzRQLzOID+
2hCLPeMG0KjBrcDb7jHbSTAJsuhW4pZb3BSjgw/skQnTYhNcV/MiivEVXiiULdOq
4GOlvMiP7OW/d0etIQiOdc1T3VPglyK8O2fNsuvOlYyHTchKghbKc8hyGbF/CUso
NjJn60lXynNHiFsfoE3gGUHXMjpTUcm1XDkKwYANBMj2aJ/vnzCHadQHBsk/4Bxr
GZ3j5hB/NI9nbwmjtZFmsSZzE3Y6N1qcKCJkBaI60uOZ8OWHtz61FM6IIZpHAOPD
dllGCtV9Ua3rd8ngkELZ11HGBFzIqQuCdXAXovEkpz5UlUrdy0FUNFd/hX0937yi
xi0ffwMqyqY3eaVq1pJB8qMMljHr98kN4nrcFtis2Scpg+CGTOm9DtT1ko+LP/7a
cvKJXvVPU/6yqQN2qdU7iuuyxww/F93Hm3YJkl/FMVIoN0xVMbjLUzgFWio7EciH
1VdxNySxevr9tss4d/uX
=plgB
-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
Not-very-reassuring info on FedUp wiki page for F21
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Hi devel, On the "Important Changes in the Upgrade process to Fedora 21" on the FedUp wiki page[1], I see the following: > Apparently there will be a new option "--product=" and > before update you will be required to choose one of the > possibilities. To obtain the old behaviour apparently > --product=nonproduct should be used. I think this could be improved to give more "sure" directions. I know it's a wiki, and "just edit/fix it", but I don't know enough about what it should be to confidently change it. Could someone who is more sure than I (and the original author, apparently) of what it should be weigh in? Is it just a case of removing the "apparently"(s)? [1] https://fedoraproject.org/wiki/FedUp Thanks a lot, Gerard. -BEGIN PGP SIGNATURE- Version: GnuPG v1 iQIcBAEBCAAGBQJUhK6lAAoJEG7cfkpivEoVIX8QAIC+FDz+dtD8GKFpq+xWOyxj 3JO0GRPw9T4UTbK/GqL30n3SFP0syHDcqIjFHhieQOOtGPslDorpVbEugmhByilj H+1PXaWu7Di4nLFWsr0oAiO6xld1ZijsHo5das1ELOD/j2M+C7UR9N7VFZqR2PPk pqhCNGiZiihm75ucoZvIsdkGqBQqqbKGCMeDB/3h2dq6Ph9D/0X1nVDzRQLzOID+ 2hCLPeMG0KjBrcDb7jHbSTAJsuhW4pZb3BSjgw/skQnTYhNcV/MiivEVXiiULdOq 4GOlvMiP7OW/d0etIQiOdc1T3VPglyK8O2fNsuvOlYyHTchKghbKc8hyGbF/CUso NjJn60lXynNHiFsfoE3gGUHXMjpTUcm1XDkKwYANBMj2aJ/vnzCHadQHBsk/4Bxr GZ3j5hB/NI9nbwmjtZFmsSZzE3Y6N1qcKCJkBaI60uOZ8OWHtz61FM6IIZpHAOPD dllGCtV9Ua3rd8ngkELZ11HGBFzIqQuCdXAXovEkpz5UlUrdy0FUNFd/hX0937yi xi0ffwMqyqY3eaVq1pJB8qMMljHr98kN4nrcFtis2Scpg+CGTOm9DtT1ko+LP/7a cvKJXvVPU/6yqQN2qdU7iuuyxww/F93Hm3YJkl/FMVIoN0xVMbjLUzgFWio7EciH 1VdxNySxevr9tss4d/uX =plgB -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
F21 LIve USB failing on Chromebook
usb boots fine on macbook air (WITH holding option key) on Acer 720 Chromebook the install screen shows - then fails (F20 usb boots fine on this machine) I've tried different mem settings mem=1024M mem=1096M mem=2048M mem=2080M none work googling returns mostly garbage Since the whole point of Live CD is for non-Fedora savvy people to try Fedora (and Linux): a) Install either needs to get fixed - or right memory setting needs to be figured out b) instructions / FAQ need to be more clear, easier to understand - they are not - a better FAQ is needed (we're happy to help here if we know where to submit a new draft btw since most new people using newer laptops will have to create an install usb - we have found the dd methods do not seem to create bootable drives and the instructions to make it bootable are obtuse at best (is it toggle N or toggle X - too confusing) - we did find gnome-disk-util works very good both with Nautilus and xfce Thunar - no idea how it works from Windows which many new users might be coming from. -- 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: Duplicate packages in f21-updates
On 07/12/14 14:47, Rex Dieter wrote: Tom Hughes wrote: It seems I had multiple updates for a couple of packages queued for stable on F21 and when the queued updates were processed yesterday all the pending packages were tagged into f21-updates rather than just the most recent versions. Yes, that's a known issue with bodhi. Best practice recommendation to maintainers currently is: don't queue more than one update (of the same package) for stable at a time. I think I was vaguely aware of that, but with things being frozen for a few weeks had missed the fact that I had multiple updates with the same packages pending :-( Is there some way to get the lower numbered packages untagged from f21-updates? Yes, rel-eng can fix problems when they arise when noticed (I'll take care of this time, and it should get fixed when the next updates push happens). Thanks. Tom -- Tom Hughes (t...@compton.nu) http://compton.nu/ -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Duplicate packages in f21-updates
Tom Hughes wrote: > It seems I had multiple updates for a couple of packages queued for > stable on F21 and when the queued updates were processed yesterday all > the pending packages were tagged into f21-updates rather than just the > most recent versions. Yes, that's a known issue with bodhi. Best practice recommendation to maintainers currently is: don't queue more than one update (of the same package) for stable at a time. > Is there some way to get the lower numbered packages untagged from > f21-updates? Yes, rel-eng can fix problems when they arise when noticed (I'll take care of this time, and it should get fixed when the next updates push happens). -- Rex -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Duplicate packages in f21-updates
It seems I had multiple updates for a couple of packages queued for stable on F21 and when the queued updates were processed yesterday all the pending packages were tagged into f21-updates rather than just the most recent versions. The lower numbered versions then seem to be the only ones included in the repository. The updates in question are: https://admin.fedoraproject.org/updates/FEDORA-2014-15144 https://admin.fedoraproject.org/updates/FEDORA-2014-15597 where the first contains these two packages: nodejs-srs-0.4.5-2.fc21 http://koji.fedoraproject.org/koji/buildinfo?buildID=593241 nodejs-mbtiles-0.7.3-1.fc21 http://koji.fedoraproject.org/koji/buildinfo?buildID=593207 and the second has: nodejs-srs-0.4.6-1.fc21 http://koji.fedoraproject.org/koji/buildinfo?buildID=594637 nodejs-mbtiles-0.7.4-1.fc21 http://koji.fedoraproject.org/koji/buildinfo?buildID=594658 Is there some way to get the lower numbered packages untagged from f21-updates? or do I need to do new builds and submit an update to force them out? Tom -- Tom Hughes (t...@compton.nu) http://compton.nu/ -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
rawhide report: 20141207 changes
Compose started at Sun Dec 7 05:15:03 UTC 2014 Broken deps for i386 -- [3Depict] 3Depict-0.0.16-3.fc22.i686 requires libmgl.so.7.2.0 [Sprog] Sprog-0.14-27.fc20.noarch requires perl(:MODULE_COMPAT_5.18.0) [cab] cab-0.1.9-12.fc22.i686 requires cabal-dev [dnssec-check] dnssec-check-1.14.0.1-4.fc20.i686 requires libval-threads.so.14 dnssec-check-1.14.0.1-4.fc20.i686 requires libsres.so.14 [glances] glances-2.1.2-2.fc22.noarch requires python-psutil >= 0:2.0.0 [nwchem] nwchem-openmpi-6.3.2-11.fc21.i686 requires libmpi_usempi.so.1 [openstack-neutron-gbp] openstack-neutron-gbp-2014.2-0.2.acb85f0git.fc22.noarch requires openstack-neutron = 0:2014.2 [perl-DBIx-Class] perl-DBIx-Class-0.082810-1.fc22.noarch requires perl(DBIx::Class::CDBICompat::Relationship) [python-selenium] python3-selenium-2.43.0-1.fc22.noarch requires python3-rdflib [rubygem-wirb] rubygem-wirb-1.0.3-2.fc21.noarch requires rubygem(paint) < 0:0.9 [shogun] shogun-doc-3.2.0.1-0.27.git20140804.96f3cf3.fc22.noarch requires shogun-data = 0:0.8.1-0.18.git20140804.48a1abb.fc22 [sssd] sssd-common-1.12.2-4.fc22.i686 requires libldb(x86-32) = 0:1.1.17 [uwsgi] uwsgi-plugin-gridfs-2.0.7-2.fc22.i686 requires libmongoclient.so uwsgi-stats-pusher-mongodb-2.0.7-2.fc22.i686 requires libmongoclient.so [vfrnav] vfrnav-20140510-2.fc22.i686 requires libpolyclipping.so.16 vfrnav-utils-20140510-2.fc22.i686 requires libpolyclipping.so.16 [wine] wine-1.7.32-1.fc22.i686 requires mingw32-wine-gecko = 0:2.34 Broken deps for x86_64 -- [3Depict] 3Depict-0.0.16-3.fc22.x86_64 requires libmgl.so.7.2.0()(64bit) [Sprog] Sprog-0.14-27.fc20.noarch requires perl(:MODULE_COMPAT_5.18.0) [cab] cab-0.1.9-12.fc22.x86_64 requires cabal-dev [dnssec-check] dnssec-check-1.14.0.1-4.fc20.x86_64 requires libval-threads.so.14()(64bit) dnssec-check-1.14.0.1-4.fc20.x86_64 requires libsres.so.14()(64bit) [glances] glances-2.1.2-2.fc22.noarch requires python-psutil >= 0:2.0.0 [nwchem] nwchem-openmpi-6.3.2-11.fc21.x86_64 requires libmpi_usempi.so.1()(64bit) [openstack-neutron-gbp] openstack-neutron-gbp-2014.2-0.2.acb85f0git.fc22.noarch requires openstack-neutron = 0:2014.2 [perl-DBIx-Class] perl-DBIx-Class-0.082810-1.fc22.noarch requires perl(DBIx::Class::CDBICompat::Relationship) [python-selenium] python3-selenium-2.43.0-1.fc22.noarch requires python3-rdflib [rubygem-wirb] rubygem-wirb-1.0.3-2.fc21.noarch requires rubygem(paint) < 0:0.9 [shogun] shogun-doc-3.2.0.1-0.27.git20140804.96f3cf3.fc22.noarch requires shogun-data = 0:0.8.1-0.18.git20140804.48a1abb.fc22 [sssd] sssd-common-1.12.2-4.fc22.x86_64 requires libldb(x86-64) = 0:1.1.17 [uwsgi] uwsgi-plugin-gridfs-2.0.7-2.fc22.x86_64 requires libmongoclient.so()(64bit) uwsgi-stats-pusher-mongodb-2.0.7-2.fc22.x86_64 requires libmongoclient.so()(64bit) [vfrnav] vfrnav-20140510-2.fc22.i686 requires libpolyclipping.so.16 vfrnav-20140510-2.fc22.x86_64 requires libpolyclipping.so.16()(64bit) vfrnav-utils-20140510-2.fc22.x86_64 requires libpolyclipping.so.16()(64bit) [wine] wine-1.7.32-1.fc22.i686 requires mingw32-wine-gecko = 0:2.34 wine-1.7.32-1.fc22.x86_64 requires mingw64-wine-gecko = 0:2.34 wine-1.7.32-1.fc22.x86_64 requires mingw32-wine-gecko = 0:2.34 Broken deps for armhfp -- [3Depict] 3Depict-0.0.16-3.fc22.armv7hl requires libmgl.so.7.2.0 [Sprog] Sprog-0.14-27.fc20.noarch requires perl(:MODULE_COMPAT_5.18.0) [avro] avro-mapred-1.7.5-9.fc22.noarch requires hadoop-mapreduce avro-mapred-1.7.5-9.fc22.noarch requires hadoop-client [cab] cab-0.1.9-12.fc22.armv7hl requires cabal-dev [dnssec-check] dnssec-check-1.14.0.1-4.fc20.armv7hl requires libval-threads.so.14 dnssec-check-1.14.0.1-4.fc20.armv7hl requires libsres.so.14 [glances] glances-2.1.2-2.fc22.noarch requires python-psutil >= 0:2.0.0 [openstack-neutron-gbp] openstack-neutron-gbp-2014.2-0.2.acb85f0git.fc22.noarch requires openstack-neutron = 0:2014.2 [ostree] ostree-grub2-2014.12-1.fc22.armv7hl requires grub2 [perl-DBIx-Class] perl-DBIx-Class-0.082810-1.fc22.noarch requires perl(DBIx::Class::CDBICompat::Relationship) [python-selenium] python3-selenium-2.43.0-1.fc22.noarch requires python3-rdflib [rubygem-wirb] rubygem-wirb-1.0.3-2.fc21.noarch requires rubygem(paint) < 0:0.9 [shogun] shogun-doc-3.2.0.1-0.27.git20140804.96f3cf3.fc22.noarch requires shogun-data = 0:0.8.1-0.18.git20140804.48a1abb.fc22 [spring-maps-default] spring-maps-default-0.1-12.fc21.noarch requires spring [sssd] sssd-c
