Re: Packagers - Flag day 2016 Important changes
On Wed, 2016-12-14 at 09:43 -0700, Kevin Fenzi wrote: > > I think we got this sorted out on IRC. Indeed we did. It required newer versions of the packages that had been listed, which presumably will be in stable updates some time soon. > David: if you still see a problem, please let us know. Thanks. -- dwmw2 smime.p7s Description: S/MIME cryptographic signature ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Announcement: Fedora Docker Layered Image Build Service is GO!
On Wed, Dec 14, 2016 at 1:06 AM, Adam Miller wrote: > Contributors will go through a simliar process as what they currently do > with RPM Review Requests. There will be Container Reviews as well as > Container Guidelines: Absolutely great news. I have couple of questions regarding Container review process. After container build are we going to request updates for fedora release braches using Bodhi? As discussed in 15-12-2016 Atomic-wg meeting we are going to have taskotron automated testcases as well. Are these all going to use Bodhi interface like it happens for RPM packages? -- Regards, Trishna Guha trishnaguh...@gmail.com trishnag.wordpress.com ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: future of official optical media support in Fedora
> Now that Fedora 25 is out of the door, I'd like to start a discussion about > the future of officially-supported (meaning rigorously tested) optical media > for future Fedora releases. The discussion died off, so let me summarize and propose a plan. We haven't received as much feedback as I hoped for. Maybe people don't care enough about optical disks to even respond, or it might be a different reason. But we also didn't receive as much negative feedback as I feared. So hopefully this does not negatively impact too many people. The comments under the Phoronix article [1] weren't too helpful either, a few rants but no-one cared to follow up with some explanation or system specification which would be negatively affected for his/her use case. Some of them, I believe, just read the article title without realizing this only affects Alpha/Beta media or certain flavors of Final media. [1] http://phoronix.com/scan.php?page=news_item&px=Fedora-Post-25-Optical-Future > Idea #1: Do not block on optical media issues for Alpha and Beta releases > ~ This is the less controversial idea, I believe. We received a concern from Matthew, who was worried that we might find out too late if we don't check it for Alpha/Beta. I partly agree, but believe we should solve it with an improved QA processes, instead of bumping the release criteria to apply earlier. He did not object to this, and nobody else did, so I assume everyone agrees :-) If there are no further concerns, I'll prepare a criterion adjustment proposal for this. > > Idea #2: Do not block on optical media issues for Final release for certain > flavors/image types (Server, netinst) > ~ > > This is a bolder variant of the previous idea and can be done separately or > combined with it. It makes optical media functionality not guaranteed even > for Final release, but just for certain Fedora flavors or image types for > which it makes sense (not all of them). Which images to cover, that's the > heart of the discussion. If you look into our test matrix again, we > currently block on 6 of them: > * Workstation Live + netinst > * KDE Live > * Server DVD + netinst > * Everything netinst This was received with reasonably positive reception as well. But it's harder to compile a list which images should be covered by criteria and which not. - Workstation Live will be covered, that's clear - we give out these DVDs at events, it's sent out to the developing world - Everything netinst is the most universal and generic netinst, so covering that one means we don't need to cover Workstation netinst and Server netinst. People seem to agree to this. - Nobody argued for KDE Live. We probably don't bulk press KDE Live DVDs. If we cover Workstation Live, it's improbable that only KDE Live would break, but not impossible. If such thing happens, are people OK with releasing Fedora XX KDE Live only bootable over USB? - Server DVD is a mixed bag. Matthew didn't include it in his block-list, Adam did. Neal uses it over IMPI (but netinst would be good enough for him IIUIC, sans some package deps issue which can be solved using a kickstart). I would appreciate more feedback from Server folks. Again, we'll cover netinst so it's improbable DVD would break, but not impossible. Are people OK releasing it only bootable over USB (and PXE)? Thanks. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
fedpkg new-sources: Could not execute new_sources:
Hi I'm getting this: [martin@fc25 vdr-epg-daemon]$ fedpkg new-sources vdr-epg-daemon-1.1.70.tar.bz2 Could not execute new_sources: 302 Found Found The document has moved https://src.fedoraproject.org/repo/pkgs/upload.cgi";>here. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: fedpkg new-sources: Could not execute new_sources:
more informations: [martin@fc25 vdr-epg-daemon]$ koji -d hello 2016-12-15 15:28:53,365 [DEBUG] koji: Opening new requests session 2016-12-15 15:28:53,366 [DEBUG] koji: Opening new requests session 2016-12-15 15:28:54,011 [DEBUG] koji: Opening new requests session Kerberos authentication failed: No credentials cache found (-1765328189) [martin@fc25 vdr-epg-daemon]$ fedora-cert -v Verifying Certificate cert expires: 2017-03-08 Traceback (most recent call last): File "/usr/bin/fedora-cert", line 85, in main(opts) File "/usr/bin/fedora-cert", line 63, in main fedora_cert.verify_cert() File "/usr/lib/python2.7/site-packages/fedora_cert/__init__.py", line 69, in verify_cert revoked = crl.get_revoked() File "/usr/lib/python2.7/site-packages/OpenSSL/crypto.py", line 1921, in get_revoked revoked_stack = self._crl.crl.revoked AttributeError: '_cffi_backend.CData' object has no attribute 'crl' ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: future of official optical media support in Fedora
On Mon, Dec 12, 2016 at 8:22 AM, Kamil Paral wrote: >> Admittedly, I have not gone through the whole thread, but I'd like to >> point out that I *do* use the DVD and netinstall ISOs for optical >> media boot on real hardware, though in a somewhat indirect manner. >> Many of the servers I use have IPMI, which allows me to have it boot a >> remote DVD device with an ISO or a real DVD drive. Due to certain > > This is interesting. Does IPMI also allow you boot from a "remote USB device"? > Not any of the servers I've worked with. Only remote DVD boot. I've never heard of anyone being able to do remote USB or disk device, as I think the ability to write over the network is considered not desirable... >> bugs[1], I've increasingly relied on the DVD vs netinstall. From the >> system's perspective, it's a regular DVD startup, just like with VMs. > > Well, unfortunately DVD boot on bare metal is different from DVD boot in VMs. > The former is proposed to be less tested, the latter would remain fully > tested. The question is what form of boot IPMI uses, and that information is > probably difficult to find out. > > I wonder, why do you prefer remote DVD boot over something like PXE boot, > boot.fedoraproject.org or booting the iso directly from grub? The environment I'm working in doesn't allow us to have a PXE boot server. boot.fedoraproject.org doesn't seem to work, and even if it did, that would likely be the equivalent of a netinstall, and netinstalls are broken until someone does something about how kernel package flavors are selected and installed. Booting the iso from grub implies I have something to boot from first (I usually don't), and also setting up grub is a non-trivial task for this stuff. -- 真実はいつも一つ！/ Always, there's only one truth! ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: fedpkg new-sources: Could not execute new_sources:
On 15/12/16 12:20, Martin Gansser wrote: Hi I'm getting this: [martin@fc25 vdr-epg-daemon]$ fedpkg new-sources vdr-epg-daemon-1.1.70.tar.bz2 Could not execute new_sources: 302 Found Found The document has moved https://src.fedoraproject.org/repo/pkgs/upload.cgi";>here. You need to update your tools. See: https://fedoraproject.org/wiki/ReleaseEngineering/FlagDay2016#What_do_I_have_to_do Tom -- Tom Hughes (t...@compton.nu) http://compton.nu/ ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Self Introduction: Benjamin Kircher (bkircher)
Hi there! I want to get sponsored into the packager group. About myself: I am a programmer by trade working in the UTC+0100 timezone. I contribute regularly to Open Source projects but nothing of any great significance. In fact my current employer lets me put most new code I write these days on GitHub. You find my profile here [1]. I use CentOS and RHEL systems quite regularly since a few years now and usually stick to Fedora VMs for development purposes. I never really had any contact to Fedora development before other than sometimes lurking around in IRC asking questions. However, I read and understood the project’s guidelines and processes, mostly I think, and want to become a maintainer for some packages I care about. Link to my first review request: [2] uftrace - User-space function call tracer for C and C++ programs [3]. A nice little program I use quite often recently and is not in Fedora yet. So, if you have little time to spare, shouldn’t be too much, I hope I can persuade you to sponsor me. BK [1]: https://github.com/bkircher [2]: https://bugzilla.redhat.com/show_bug.cgi?id=1398922 [3]: https://github.com/namhyung/uftrace 325F3B76.asc Description: Binary data ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: future of official optical media support in Fedora
On Thu, Dec 15, 2016 at 07:08:13AM -0500, Kamil Paral wrote: > > Idea #1: Do not block on optical media issues for Alpha and Beta releases > > ~ > This is the less controversial idea, I believe. We received a concern > from Matthew, who was worried that we might find out too late if we > don't check it for Alpha/Beta. I partly agree, but believe we should > solve it with an improved QA processes, instead of bumping the > release criteria to apply earlier. He did not object to this, and > nobody else did, so I assume everyone agrees :-) If there are no > further concerns, I'll prepare a criterion adjustment proposal for > this. +1 > This was received with reasonably positive reception as well. But > it's harder to compile a list which images should be covered by > criteria and which not. > - Workstation Live will be covered, that's clear - we give out these > DVDs at events, it's sent out to the developing world > - Everything netinst is the most universal and generic netinst, so > covering that one means we don't need to cover Workstation netinst > and Server netinst. People seem to agree to this. +1 > - Nobody argued for KDE Live. We probably don't bulk press KDE Live > DVDs. If we cover Workstation Live, it's improbable that only KDE > Live would break, but not impossible. If such thing happens, are > people OK with releasing Fedora XX KDE Live only bootable over USB? I continue to believe we need the ability to release Spins independent of the main release cycle. If there's a KDE-specific problem, rather than that holding up the release *or* waiting six to eight months for it to work again, there should be the ability to have it fixed a week later. Or for that matter, if Workstation slips a month and KDE doesn't want to, should be fine. I know that we're not there yet, but I'll keep repeating it as a desired state. :) > - Server DVD is a mixed bag. Matthew didn't include it in his > block-list, Adam did. Neal uses it over IMPI (but netinst would be > good enough for him IIUIC, sans some package deps issue which can > be solved using a kickstart). I would appreciate more feedback from > Server folks. Again, we'll cover netinst so it's improbable DVD > would break, but not impossible. Are people OK releasing it only > bootable over USB (and PXE)? I think netinst + USB covers the Server case well enough. -- Matthew Miller Fedora Project Leader ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: fedpkg new-sources: Could not execute new_sources:
thanks for your quick response. after updating the mentioned program version and running kinit @FEDORAPROJECT.ORG the fedpkg new-sources ... works again. :-) ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: future of official optical media support in Fedora
On Thu, Dec 15, 2016 at 07:31:29AM -0500, Neal Gompa wrote: > > This is interesting. Does IPMI also allow you boot from a "remote > > USB device"? > Not any of the servers I've worked with. Only remote DVD boot. I've > never heard of anyone being able to do remote USB or disk device, as I > think the ability to write over the network is considered not > desirable... IBM Bladecenters can mount USB images remotely — although that's just a disk image file, same as you can do with an .ISO. No physical media involved in either case. -- Matthew Miller Fedora Project Leader ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: future of official optical media support in Fedora
On Thu, Dec 15, 2016 at 6:08 AM, Kamil Paral wrote: > > Now that Fedora 25 is out of the door, I'd like to start a discussion > about > > the future of officially-supported (meaning rigorously tested) optical > media > > for future Fedora releases. > > The discussion died off, so let me summarize and propose a plan. > > We haven't received as much feedback as I hoped for. Maybe people don't > care enough about optical disks to even respond, or it might be a different > reason. But we also didn't receive as much negative feedback as I feared. > So hopefully this does not negatively impact too many people. The comments > under the Phoronix article [1] weren't too helpful either, a few rants but > no-one cared to follow up with some explanation or system specification > which would be negatively affected for his/her use case. Some of them, I > believe, just read the article title without realizing this only affects > Alpha/Beta media or certain flavors of Final media. > > [1] http://phoronix.com/scan.php?page=news_item&px=Fedora-Post- > 25-Optical-Future > > > > Idea #1: Do not block on optical media issues for Alpha and Beta releases > > > ~ > > This is the less controversial idea, I believe. We received a concern from > Matthew, who was worried that we might find out too late if we don't check > it for Alpha/Beta. I partly agree, but believe we should solve it with an > improved QA processes, instead of bumping the release criteria to apply > earlier. He did not object to this, and nobody else did, so I assume > everyone agrees :-) If there are no further concerns, I'll prepare a > criterion adjustment proposal for this. > > > > > Idea #2: Do not block on optical media issues for Final release for > certain > > flavors/image types (Server, netinst) > > > ~ > > > > This is a bolder variant of the previous idea and can be done separately > or > > combined with it. It makes optical media functionality not guaranteed > even > > for Final release, but just for certain Fedora flavors or image types for > > which it makes sense (not all of them). Which images to cover, that's the > > heart of the discussion. If you look into our test matrix again, we > > currently block on 6 of them: > > * Workstation Live + netinst > > * KDE Live > > * Server DVD + netinst > > * Everything netinst > > This was received with reasonably positive reception as well. But it's > harder to compile a list which images should be covered by criteria and > which not. > - Workstation Live will be covered, that's clear - we give out these DVDs > at events, it's sent out to the developing world > - Everything netinst is the most universal and generic netinst, so > covering that one means we don't need to cover Workstation netinst and > Server netinst. People seem to agree to this. > - Nobody argued for KDE Live. We probably don't bulk press KDE Live DVDs. > If we cover Workstation Live, it's improbable that only KDE Live would > break, but not impossible. If such thing happens, are people OK with > releasing Fedora XX KDE Live only bootable over USB? > - Server DVD is a mixed bag. Matthew didn't include it in his block-list, > Adam did. Neal uses it over IMPI (but netinst would be good enough for him > IIUIC, sans some package deps issue which can be solved using a kickstart). > I would appreciate more feedback from Server folks. Again, we'll cover > netinst so it's improbable DVD would break, but not impossible. Are people > OK releasing it only bootable over USB (and PXE)? > > Thanks. > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > >We haven't received as much feedback as I hoped for. Maybe people don't care enough about optical disks to even respond, or it might be a different reason. I must have missed this and deleted it by mistake. I had something weird happen when F23 was the latest release. Somehow, probably through user error, I deleted my partition table and bricked my only USB stick. I think I corrupted the USB stick firmware somehow. I have only one computer so using another to get another copy wasn't an option. I did have a back up Fedora DVD because an earlier experience in life when I found myself without an OS and a broken installation. I think that having a read only media option with physical damage as the only failure mode is valuable. I continue to keep a Fedora DVD even though I prefer installing through USB. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Announcement: Fedora Docker Layered Image Build Service is GO!
On Thu, Dec 15, 2016 at 5:49 AM, Trishna Guha wrote: > On Wed, Dec 14, 2016 at 1:06 AM, Adam Miller > wrote: >> Contributors will go through a simliar process as what they currently do >> with RPM Review Requests. There will be Container Reviews as well as >> Container Guidelines: > > Absolutely great news. > > I have couple of questions regarding Container review process. > After container build are we going to request updates for fedora > release braches using Bodhi? > As discussed in 15-12-2016 Atomic-wg meeting we are going to have > taskotron automated testcases as well. > Are these all going to use Bodhi interface like it happens for RPM packages? > At this time there will not be Bodhi updates, but there will be a RelEng process that will perform releases every other week (alternating with the weeks that we do Two Week Atomic Releases). Once the Taskotron work is in place (being released soon), we'll have automated testing happening on every container build in koji and then there will be fedmsg data stored in datagrepper that we can query to find out the latest version of a container that is successfully passing all it's tests. I'll update the wiki page with information about this. -AdamM > > -- > Regards, > Trishna Guha > > trishnaguh...@gmail.com > trishnag.wordpress.com > ___ > cloud mailing list -- cl...@lists.fedoraproject.org > To unsubscribe send an email to cloud-le...@lists.fedoraproject.org ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: future of official optical media support in Fedora
> I had something weird happen when F23 was the latest release. Somehow, > probably through user error, I deleted my partition table and bricked my > only USB stick. I think I corrupted the USB stick firmware somehow. I have > only one computer so using another to get another copy wasn't an option. I > did have a back up Fedora DVD because an earlier experience in life when I > found myself without an OS and a broken installation. > I think that having a read only media option with physical damage as the only > failure mode is valuable. I continue to keep a Fedora DVD even though I > prefer installing through USB. If you keep Workstation Live or Server netinst, you should be still covered under the current proposal. That doesn't mean other media won't work as spinning discs, just won't be guaranteed to work. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Rawhide-20161215.n.0 compose check report
Missing expected images: Workstation live i386 Kde live x86_64 Workstation live x86_64 Kde live i386 Failed openQA tests: 11/80 (x86_64), 5/15 (i386), 1/2 (arm) New failures (same test did not fail in Rawhide-20161214.n.1): ID: 51331 Test: x86_64 Workstation-boot-iso install_default URL: https://openqa.fedoraproject.org/tests/51331 ID: 51332 Test: x86_64 Workstation-boot-iso install_default@uefi URL: https://openqa.fedoraproject.org/tests/51332 ID: 51333 Test: i386 Workstation-boot-iso install_default URL: https://openqa.fedoraproject.org/tests/51333 ID: 51403 Test: x86_64 universal upgrade_2_desktop_encrypted_64bit URL: https://openqa.fedoraproject.org/tests/51403 ID: 51414 Test: i386 universal install_package_set_minimal URL: https://openqa.fedoraproject.org/tests/51414 ID: 51422 Test: i386 universal upgrade_desktop_32bit URL: https://openqa.fedoraproject.org/tests/51422 ID: 51423 Test: i386 universal upgrade_2_desktop_32bit URL: https://openqa.fedoraproject.org/tests/51423 Old failures (same test failed in Rawhide-20161214.n.1): ID: 51334 Test: arm Minimal-raw_xz-raw.xz install_arm_image_deployment_upload URL: https://openqa.fedoraproject.org/tests/51334 ID: 51347 Test: x86_64 Server-dvd-iso server_role_deploy_domain_controller URL: https://openqa.fedoraproject.org/tests/51347 ID: 51382 Test: x86_64 universal install_package_set_kde URL: https://openqa.fedoraproject.org/tests/51382 ID: 51397 Test: x86_64 universal upgrade_kde_64bit URL: https://openqa.fedoraproject.org/tests/51397 ID: 51398 Test: x86_64 universal upgrade_desktop_encrypted_64bit URL: https://openqa.fedoraproject.org/tests/51398 ID: 51400 Test: x86_64 universal upgrade_2_desktop_64bit URL: https://openqa.fedoraproject.org/tests/51400 ID: 51402 Test: x86_64 universal upgrade_2_kde_64bit URL: https://openqa.fedoraproject.org/tests/51402 ID: 51412 Test: x86_64 universal install_rescue_encrypted URL: https://openqa.fedoraproject.org/tests/51412 ID: 51413 Test: x86_64 universal install_rescue_encrypted@uefi URL: https://openqa.fedoraproject.org/tests/51413 ID: 51424 Test: i386 universal install_package_set_kde URL: https://openqa.fedoraproject.org/tests/51424 Passed openQA tests: 66/80 (x86_64), 10/15 (i386) New passes (same test did not pass in Rawhide-20161214.n.1): ID: 51336 Test: x86_64 Server-boot-iso install_default URL: https://openqa.fedoraproject.org/tests/51336 Skipped openQA tests: 1 of 97 -- Mail generated by check-compose: https://pagure.io/fedora-qa/check-compose ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Command git commit -m import_srpm -a returned code 1 in COPR
Hello, I'm a newbie and I'm trying to use COPR for the first time. I built sucessfully a package on my machine, but when I upload the SRPM on COPR it fails the build. I can't understand what "rpkgError: Command git commit -m import_srpm -a returned code 1 with error: " means. What is wrong? The full log is here: http://copr-dist-git.fedorainfracloud.org/per-task-logs/489695-f25.log Can someone explain if it's my fault? if yes, can you drive me to understand the reason? Cheers, Gregorio ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: future of official optical media support in Fedora
On Thu, 2016-12-15 at 07:31 -0500, Neal Gompa wrote: > and even if it > did, that would likely be the equivalent of a netinstall, and > netinstalls are broken until someone does something about how kernel > package flavors are selected and installed. Sorry, what do you mean by this? And how is it different on DVDs? -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net http://www.happyassassin.net ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: future of official optical media support in Fedora
On Thu, Dec 15, 2016 at 1:03 PM, Adam Williamson wrote: > On Thu, 2016-12-15 at 07:31 -0500, Neal Gompa wrote: >> and even if it >> did, that would likely be the equivalent of a netinstall, and >> netinstalls are broken until someone does something about how kernel >> package flavors are selected and installed. > > Sorry, what do you mean by this? And how is it different on DVDs? I mean this bug[1] that became a thing ever since we split up the kernel into lots of subpackages. Anaconda/DNF will install the wrong variant (like debug instead of regular) of any kernel subpackage because they all provide (and rightfully so) the same name. It breaks stuff as simple as having Wi-Fi in Fedora Workstation after netinstall, or makes it so that you can't rely on the "kernel-devel" requirement for dkms. It's a natural consequence of how our kernel packaging works, and how yum and dnf cannot infer the correct default flavor of kernel packages from the environment. I haven't installed from the DVD in a while, but last I recall, something about DVD installs prevents this from happening. It may very well occur now with DVD installs, too. [1]: https://bugzilla.redhat.com/show_bug.cgi?id=1228897 -- 真実はいつも一つ！/ Always, there's only one truth! ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: future of official optical media support in Fedora
On Thu, 2016-12-15 at 13:22 -0500, Neal Gompa wrote: > On Thu, Dec 15, 2016 at 1:03 PM, Adam Williamson > wrote: > > On Thu, 2016-12-15 at 07:31 -0500, Neal Gompa wrote: > > > and even if it > > > did, that would likely be the equivalent of a netinstall, and > > > netinstalls are broken until someone does something about how kernel > > > package flavors are selected and installed. > > > > Sorry, what do you mean by this? And how is it different on DVDs? > > I mean this bug[1] that became a thing ever since we split up the > kernel into lots of subpackages. Anaconda/DNF will install the wrong > variant (like debug instead of regular) of any kernel subpackage > because they all provide (and rightfully so) the same name. It breaks > stuff as simple as having Wi-Fi in Fedora Workstation after > netinstall, or makes it so that you can't rely on the "kernel-devel" > requirement for dkms. It's a natural consequence of how our kernel > packaging works, and how yum and dnf cannot infer the correct default > flavor of kernel packages from the environment. Oh, right, that one. Isn't it basically the same as https://bugzilla.redhat.com/show_bug.cgi?id=1192189 ? > I haven't installed from the DVD in a while, but last I recall, > something about DVD installs prevents this from happening. It may very > well occur now with DVD installs, too. The difference would just be in which of the kernel packages are present on the DVD for it to install, I suppose. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net http://www.happyassassin.net ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Planned outage: pagure.io - 2016-12-16 16:00 UTC
There will be an outage starting at 2016-12-16 16:00 UTC, which will last approximately 4 hours. To convert UTC to your local time, take a look at https://fedoraproject.org/wiki/UTCHowto or run: date -d '2016-12-16 16:00 UTC' Reason for outage: We will be moving backend storage for pagure.org to a larger volume and increasing it's size to handle further growth in the coming year. Affected Services: All services on .pagure.org / .pagure.io Contact Information: infrastructure @lists.fedoraproject.org Please join #fedora-admin in irc.freenode.net or add comments to the ticket for this outage above. pgpKmd3sKFE5u.pgp Description: OpenPGP digital signature ___ devel-announce mailing list -- devel-annou...@lists.fedoraproject.org To unsubscribe send an email to devel-announce-le...@lists.fedoraproject.org ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: future of official optical media support in Fedora
On Thu, Dec 15, 2016 at 1:49 PM, Adam Williamson wrote: > On Thu, 2016-12-15 at 13:22 -0500, Neal Gompa wrote: >> On Thu, Dec 15, 2016 at 1:03 PM, Adam Williamson >> wrote: >> > On Thu, 2016-12-15 at 07:31 -0500, Neal Gompa wrote: >> > > and even if it >> > > did, that would likely be the equivalent of a netinstall, and >> > > netinstalls are broken until someone does something about how kernel >> > > package flavors are selected and installed. >> > >> > Sorry, what do you mean by this? And how is it different on DVDs? >> >> I mean this bug[1] that became a thing ever since we split up the >> kernel into lots of subpackages. Anaconda/DNF will install the wrong >> variant (like debug instead of regular) of any kernel subpackage >> because they all provide (and rightfully so) the same name. It breaks >> stuff as simple as having Wi-Fi in Fedora Workstation after >> netinstall, or makes it so that you can't rely on the "kernel-devel" >> requirement for dkms. It's a natural consequence of how our kernel >> packaging works, and how yum and dnf cannot infer the correct default >> flavor of kernel packages from the environment. > > Oh, right, that one. Isn't it basically the same as > https://bugzilla.redhat.com/show_bug.cgi?id=1192189 ? > It is essentially the same core issue, yes. It can happen with Yum, but for some reason, it happens less often. >> I haven't installed from the DVD in a while, but last I recall, >> something about DVD installs prevents this from happening. It may very >> well occur now with DVD installs, too. > > The difference would just be in which of the kernel packages are > present on the DVD for it to install, I suppose. Most likely. -- 真実はいつも一つ！/ Always, there's only one truth! ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: future of official optical media support in Fedora
On Thu, 2016-12-15 at 14:37 -0500, Neal Gompa wrote: > It is essentially the same core issue, yes. It can happen with Yum, > but for some reason, it happens less often. yum had rather different logic for resolving ambiguous dependencies than libsolv does. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net http://www.happyassassin.net ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: future of official optical media support in Fedora
Once upon a time, Adam Williamson said: > On Thu, 2016-12-15 at 14:37 -0500, Neal Gompa wrote: > > It is essentially the same core issue, yes. It can happen with Yum, > > but for some reason, it happens less often. > > yum had rather different logic for resolving ambiguous dependencies > than libsolv does. Is the current behavior documented? IIRC yum used the shortest package name, and then an alphabetic sort. For the particular case of the kernel vs. kernel-debug packages, shortest package name would solve the issue. -- Chris Adams ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: future of official optical media support in Fedora
On Thu, 2016-12-15 at 14:04 -0600, Chris Adams wrote: > Once upon a time, Adam Williamson said: > > On Thu, 2016-12-15 at 14:37 -0500, Neal Gompa wrote: > > > It is essentially the same core issue, yes. It can happen with Yum, > > > but for some reason, it happens less often. > > > > yum had rather different logic for resolving ambiguous dependencies > > than libsolv does. > > Is the current behavior documented? IIRC yum used the shortest package > name, and then an alphabetic sort. For the particular case of the > kernel vs. kernel-debug packages, shortest package name would solve the > issue. I don't think it is, no. You could possibly find it with the clue that it changed substantially between 0.6.13 and 0.6.14 (see https://bugzilla.redhat.com/show_bug.cgi?id=1192182 ). I've looked at it before, but don't remember where it is any more. The libsolv repo is https://github.com/openSUSE/libsolv . -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net http://www.happyassassin.net ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Fedora Rawhide-20161215.n.0 compose check report
On Thu, 2016-12-15 at 15:08 +, Fedora compose checker wrote: > Missing expected images: > > Workstation live i386 > Kde live x86_64 > Workstation live x86_64 > Kde live i386 > > Failed openQA tests: 11/80 (x86_64), 5/15 (i386), 1/2 (arm) > > New failures (same test did not fail in Rawhide-20161214.n.1): > > ID: 51331 Test: x86_64 Workstation-boot-iso install_default > URL: https://openqa.fedoraproject.org/tests/51331 > ID: 51332 Test: x86_64 Workstation-boot-iso install_default@uefi > URL: https://openqa.fedoraproject.org/tests/51332 > ID: 51333 Test: i386 Workstation-boot-iso install_default > URL: https://openqa.fedoraproject.org/tests/51333 > ID: 51403 Test: x86_64 universal upgrade_2_desktop_encrypted_64bit > URL: https://openqa.fedoraproject.org/tests/51403 These are all due to LibreOffice not being installable at present, which makes the Workstation package set not installable or upgradeable. LO maintainers have been trying to rebuild it, but the armv7hl build seems to be killed after running for a long time; not sure if its timeout is simply not long enough, or if the build process is actually hanging or something. > ID: 51414 Test: i386 universal install_package_set_minimal > URL: https://openqa.fedoraproject.org/tests/51414 Hung during post-install. Hrm. > ID: 51422 Test: i386 universal upgrade_desktop_32bit > URL: https://openqa.fedoraproject.org/tests/51422 > ID: 51423 Test: i386 universal upgrade_2_desktop_32bit > URL: https://openqa.fedoraproject.org/tests/51423 Same LibreOffice issue. > Old failures (same test failed in Rawhide-20161214.n.1): > > ID: 51334 Test: arm Minimal-raw_xz-raw.xz > install_arm_image_deployment_upload > URL: https://openqa.fedoraproject.org/tests/51334 I looked into this a bit more recently, details are in https://phab.qadevel.cloud.fedoraproject.org/T873 . Basically an fsck that happens during boot seems to be taking far longer than it used to; not sure why, yet. I've asked garretraziel to look into it. > ID: 51347 Test: x86_64 Server-dvd-iso server_role_deploy_domain_controller > URL: https://openqa.fedoraproject.org/tests/51347 This is https://bugzilla.redhat.com/show_bug.cgi?id=1403352 . > ID: 51382 Test: x86_64 universal install_package_set_kde > URL: https://openqa.fedoraproject.org/tests/51382 > ID: 51397 Test: x86_64 universal upgrade_kde_64bit > URL: https://openqa.fedoraproject.org/tests/51397 > ID: 51398 Test: x86_64 universal upgrade_desktop_encrypted_64bit > URL: https://openqa.fedoraproject.org/tests/51398 > ID: 51400 Test: x86_64 universal upgrade_2_desktop_64bit > URL: https://openqa.fedoraproject.org/tests/51400 > ID: 51402 Test: x86_64 universal upgrade_2_kde_64bit > URL: https://openqa.fedoraproject.org/tests/51402 These are all dependency issues; the Workstation one mentioned above, and a couple of dep issues that prevent KDE from installing or upgrading. I see builds from today that ought to fix the KDE issues, so hopefully we'll get working KDE tests (and a KDE live) in the next nightly. > ID: 51412 Test: x86_64 universal install_rescue_encrypted > URL: https://openqa.fedoraproject.org/tests/51412 > ID: 51413 Test: x86_64 universal install_rescue_encrypted@uefi > URL: https://openqa.fedoraproject.org/tests/51413 These are https://bugzilla.redhat.com/show_bug.cgi?id=1376638 . > ID: 51424 Test: i386 universal install_package_set_kde > URL: https://openqa.fedoraproject.org/tests/51424 KDE dep issues again. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net http://www.happyassassin.net ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
GStreamer zero day, round 2...
It's not actually round 2, but more like round 5 or something, because Chris has been publishing an awful lot of these: https://scarybeastsecurity.blogspot.com/2016/12/redux-compromising-linux-using-snes.html He shows how to exploit tracker-extract (hopefully mitigated by the new seccomp sandbox, thanks Carlos!), gnome-video-thumbnailer, and totem itself. Guess these are just going to keep on coming. It's actually very refreshing to know that somebody besides the bad guys is finally looking at our code Michael ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Packagers - Flag day 2016 Important changes
On Sunday, December 11, 2016 6:34:38 PM EST Dennis Gilmore wrote: > Greetings. > > As previously announced, releng has made a number of changes as part of > it's 2016 "flag day". > > All package maintainers will want to make sure they have updated to > the following package versions (some may be in testing as of this email): > > python-cccolutils-1.4-1 > fedpkg-1.26-2 > fedora-packager-0.6.0.0-1 > pyrpkg-1.47-3 > koji-1.11.0-1 > > Please also see the following links for up to date information: > > https://fedoraproject.org/wiki/ReleaseEngineering/FlagDay2016 I have been trying to build a package for a couple hours to no avail. There are a whole bunch of emails saying how it doesn't work for various configurations. Could this page please be updated with what the final recipe is? I need to build packages and do other things instead of debug this. The packages are not even in stable yet and we block building? -Steve ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: future of official optical media support in Fedora
Kamil Paral wrote: > - Nobody argued for KDE Live. We probably don't bulk press KDE Live DVDs. > If we cover Workstation Live, it's improbable that only KDE Live would > break, but not impossible. If such thing happens, are people OK with > releasing Fedora XX KDE Live only bootable over USB? Yet another step towards making Fedora KDE a second-class citizen. :-( Either we continue supporting DVD media for all spins/editions or for none. Kevin Kofler ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: future of official optical media support in Fedora
On December 15, 2016 9:32:36 PM PST, Kevin Kofler wrote: >Kamil Paral wrote: >> - Nobody argued for KDE Live. We probably don't bulk press KDE Live >DVDs. >> If we cover Workstation Live, it's improbable that only KDE Live >would >> break, but not impossible. If such thing happens, are people OK with >> releasing Fedora XX KDE Live only bootable over USB? > >Yet another step towards making Fedora KDE a second-class citizen. :-( > >Either we continue supporting DVD media for all spins/editions or for >none. > >Kevin Kofler >___ >devel mailing list -- devel@lists.fedoraproject.org >To unsubscribe send an email to devel-le...@lists.fedoraproject.org I don't see why we can't just say the requirement is that we test "at least one release blocking live image". I can't see any reason we have to specify which one we test. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin DOT net http://www.happyassassin.net ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Packagers - Flag day 2016 Important changes
On December 15, 2016 8:06:00 PM PST, Steve Grubb wrote: >On Sunday, December 11, 2016 6:34:38 PM EST Dennis Gilmore wrote: >> Greetings. >> >> As previously announced, releng has made a number of changes as part >of >> it's 2016 "flag day". >> >> All package maintainers will want to make sure they have updated to >> the following package versions (some may be in testing as of this >email): >> >> python-cccolutils-1.4-1 >> fedpkg-1.26-2 >> fedora-packager-0.6.0.0-1 >> pyrpkg-1.47-3 >> koji-1.11.0-1 >> >> Please also see the following links for up to date information: >> >> https://fedoraproject.org/wiki/ReleaseEngineering/FlagDay2016 > >I have been trying to build a package for a couple hours to no avail. >There >are a whole bunch of emails saying how it doesn't work for various >configurations. Could this page please be updated with what the final >recipe is? >I need to build packages and do other things instead of debug this. The > >packages are not even in stable yet and we block building? > >-Steve >___ >devel mailing list -- devel@lists.fedoraproject.org >To unsubscribe send an email to devel-le...@lists.fedoraproject.org Well, no, plenty of people have built plenty of packages since yesterday, as is obvious from koji if you just look at it. If you give more details I'm sure people can help, but it's clearly not true that anyone is "blocking building". -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin DOT net http://www.happyassassin.net ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Announcement: Fedora Docker Layered Image Build Service is GO!
On Tue, Dec 13, 2016 at 4:18 PM, Adam Miller wrote: > On Tue, Dec 13, 2016 at 2:52 PM, Igor Gnatenko wrote: >> On Tue, Dec 13, 2016 at 8:36 PM, Adam Miller >> wrote: >>> It is with great pleasure that the Fedora Project Announces the availability >>> of the Fedora Docker Layered Image Build Service[0] to the Fedora >>> Contributor >>> Community! >>> >>> With this announcement we are opening availability of the Docker Layered >>> Image Build Service for the Docker Layered Images[1] that the Fedora Cloud >>> SIG[2] has been the primary maintainers[3] of on GitHub into DistGit as >>> official components of Fedora. From there we will be extending an invitation >>> to all Fedora Contributors to maintain Docker Layered Image Containers for >>> official release by the Fedora Project. Currently this effort is to enable >>> the Fedora Cloud/Atomic WG[2] goals which target Fedora Atomic Host[4] as a >>> primary deliverable to power the future of Cloud. This is also to enable the >>> Fedora Modularity[5] work be delivered as Containers in the future as Fedora >>> becomes fundamentally more modular in nature. >>> >>> How do I get started? >>> >>> Contributors will go through a simliar process as what they currently do >>> with RPM Review Requests. There will be Container Reviews as well as >>> Container Guidelines: >>> >>> https://fedoraproject.org/wiki/Container:Review_Process >>> https://fedoraproject.org/wiki/Container:Guidelines >> Nice job! >> >> I have couple of questions: >> * why "FROM fedora:25", how do I choose version on which I want to >> base container? > > The 'FROM fedora:25' line should coordinate with the branch of DistGit > you're working in. Since Docker doesn't have a mechanism like RPMs do > with macros where we can parameterize things like that, we just have > to define it for now (we may later change it to where the 'FROM > fedora:$version' is inferred and something makes a modification to the > Dockerfile before building. > >> * is there containers in registry for rawhide? > > There are not at this moment, only for Fedora 24 and Fedora 25. I hope > to have rawhide enabled very soon though. The layout of DistGit > branches correlated to Fedora release information fed into the Build > System is something that needs be sorted since "branched" Fedora > Releases have a version number tied to DistGit but Rawhide is > technically f26 right now. I'll update as soon as this is live. Rawhide is now live, you can 'fedpkg container-build' from DistGit master branch just like you can 'fedpkg build' for rawhide RPMs. Apologies for the delay, -AdamM > > -AdamM > >>> >>> At this time the Cloud/Atomic WG[2] will maintain the Guidelines as well as >>> the Review Process along with input from all Fedora Contributors. This may >>> change later with the formation of a Fedora Container Committee (similar to >>> the Fedora Packaging Committee[6]). >>> >>> Please note that both the Guidelines and the Review Process are likely to >>> evolve along with the Container technologies as we move into the future so >>> we encourage community members to check the documentation for updates. >>> >>> For more information, please see the following Fedora Community Blog: >>> >>> >>> https://communityblog.fedoraproject.org/fedora-docker-layered-image-build-service-now-available/ >>> >>> [0] - >>> https://fedoraproject.org/wiki/Changes/Layered_Docker_Image_Build_Service >>> [1] - https://fedoraproject.org/wiki/Cloud >>> [2] - >>> https://docs.docker.com/engine/userguide/storagedriver/imagesandcontainers/ >>> [3] - https://github.com/fedora-cloud/Fedora-Dockerfiles >>> [4] - https://getfedora.org/en/atomic/download/ >>> [5] - https://fedoraproject.org/wiki/Modularity >>> [6] - https://fedoraproject.org/wiki/Packaging_Committee >>> ___ >>> devel mailing list -- devel@lists.fedoraproject.org >>> To unsubscribe send an email to devel-le...@lists.fedoraproject.org >> >> >> >> -- >> -Igor Gnatenko >> ___ >> devel mailing list -- devel@lists.fedoraproject.org >> To unsubscribe send an email to devel-le...@lists.fedoraproject.org ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: GStreamer zero day, round 2...
On Thu, 2016-12-15 at 19:41 -0600, Michael Catanzaro wrote: > It's not actually round 2, but more like round 5 or something, > because > Chris has been publishing an awful lot of these: > > https://scarybeastsecurity.blogspot.com/2016/12/redux-compromising-li > nux-using-snes.html There's a new upstream release of game-music-emu that fixes this particular bug, with a bugzilla report at: https://bugzilla.redhat.com/show_bug.cgi?id=1405024 I've attached a patch to the bug that will actually allow the new release to build. I'm off to push this build to my systems at my school. Don't want any of my students getting any bright ideas. Jonathan ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
