How to specify explicit requires on library
Hello,
I was looking at the gdal spec [1] and noticed the following lines in %prep
# libproj is dlopened; upstream sources point to .so, which is usually
not present
# http://trac.osgeo.org/gdal/ticket/3602
sed -i 's|libproj.so|libproj.so.0|g' ogr/ogrct.cpp
The problem is that a libproj soname bump will be silently missed unless
a maintainer remembers the existence of this particular line - and
indeed, the libproj soname was bumped in proj-4.9.1 to libproj.so.9.
I was about to file a bug suggesting
# Major digit of the proj so version
%global proj_somaj 9
[...]
# proj DL-opened in ogrct.cpp, see also fix in %%prep
Requires: libproj.so.%{proj_somaj}
[...]
sed -i 's|libproj.so|libproj.so.%{proj_somaj}|g' ogr/ogrct.cpp
but I haven't found how to correctly specify the explicit arch-correct
requires on the library. I suppose I want something which will
ultimately results in something like
Konsole output
libproj.so.9()(64bit)
but how can the "()(64bit)" part be specified?
Thanks,
Sandro
[1] http://pkgs.fedoraproject.org/cgit/gdal.git/tree/gdal.spec
--
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: Enable Wake-On-LAN in current Fedora
On Tue, Apr 14, 2015 at 05:59:46PM +0200, Sergio Pascual wrote: > I was wondering what is the "correct" way of enabling WOL on a network card. > If you use systemd-networkd (not default in Fedora), you can use WakeOnLan= property. Man systemd.link -- Tomasz Torcz "Never underestimate the bandwidth of a station xmpp: zdzich...@chrome.plwagon filled with backup tapes." -- Jim Gray -- 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 replacing yum and dnf-yum
- Original Message - > From: "Pete Travis" > To: "Development discussions related to Fedora" > > Sent: Tuesday, April 14, 2015 5:18:15 PM > Subject: Re: dnf replacing yum and dnf-yum > On Apr 13, 2015 5:07 AM, "Radek Holy" < rh...@redhat.com > wrote: > > > > > > > >> > >> From: "Pete Travis" < li...@petetravis.com > > >> To: "Development discussions related to Fedora" < > >> devel@lists.fedoraproject.org > > >> Sent: Friday, April 10, 2015 5:31:08 PM > >> Subject: Re: dnf replacing yum and dnf-yum > >> > >> > >> > >> On Apr 10, 2015 4:39 AM, "Radek Holy" < rh...@redhat.com > wrote: > >> > > >> > >> > > >> > Hm, I think that it depends on the use case. AFAIK, distro-sync is > >> > mostly used to upgrade Fedora (an unsupported approach AFAIK) and to > >> > replace some testing/3rd-party versions of package with the "official" > >> > ones. (BTW, I'd appreciate if anyone will share their use case) While > >> > in the first case, I think that the upgrade's behaviour is preferred, > >> > in the other case, the install's behaviour is better IMO. (Which > >> > dangerously indicates that the --skip-broken switch is a good solution > >> > :( ) > >> > > >> > Anyway, file an RFE (if it isn't filed already) please. We can > >> > track/discuss it there. > >> > > >> > Thank you in advance > >> > -- > >> > Radek Holý > >> > > >> > >> (lots of trimming, and skipping an RFE, as this just pertains to the > >> distro-sync use case question) > >> > >> distro-sync is useful for getting to a sane state after temporarily > >> enabling some repo that interacts with the primary ones. This can happen > >> with third party repos, but we can consider an entirely in-house > >> situation: > >> > >> The user finds a bug in widget-2.5.7 and reports it. A fix for widget is > >> shipped and the user is asked to test via `dnf update widget --enablerepo > >> updates-testing`. The transaction pulls in many requires from > >> updates-testing (although at this point, I realize dnf may not be > >> upgrading the requires in this transaction if they are not versioned). > >> The new widget is tested, life goes on. > >> > >> Later, the user wants to install or update some package whizbang that > >> shares requires with widget. That package has versioned requires on > >> packages from the updates repo, but some of the installed packages are > >> from updates-testing and don't provide what whizbang needs. > >> > >> Something like `dnf --allowerasing install whizbang` might be the > >> appropriate and precise tool to get through that transaction. `dnf > >> distro-sync` is the less precise, big-hammer tool for the user that > >> doesn't know or care to track down the intricacies of widget and whizbang > >> dependencies. They ran some command from a bug report a while ago and > >> moved on, and now they run distro-sync to return their system to a > >> known-good state and move on. > >> > >> This sort of thing is most common during the prerelease cycle, when users > >> will have updates-testing on then off, and there are freezes, and > >> branching, and lots of activity that might leave early adopters in an > >> unsane state. > >> > >> And yeah, it is very useful for upgrades. Even when ran after a proper > >> fedup upgrade. > >> > >> --Pete > >> > >> > > Yeah, that's basically what I meant by 'replace some testing versions of > > package with the "official" ones'. Anyway, thank you for elaborating on > > it. I'll definitely make a test case from it. > > > > I'd like to let those doing the actions described above know that there is > > also a not very well known command "dnf repository-packages > > remove-or-distro-sync" which is specifically designed for switching from > > packages installed from testing/3rd-party repositories > > -- > > Radek Holý > > Associate Software Engineer > > Software Management Team > > Red Hat Czech > > > > -- > Nice! That's as the stable/updates repo, not the > testing/3rd-party/problem repo, right? I'll add this to my dnf writeup. > --Pete No, as the testing/3rd-party/problem repo. It selects the packages installed from and runs distro-sync or remove on them while the upgrades/downgrades are taken from all the enabled repositories except . So, in the end, it's very likely that you'll end up with an RPMDB that does not contain any package installed from . This command was taken from YUM and although it is not sometimes clear what the command should do without looking into man pages, I think that it's good as it is. If you want to control from which repositories are the upgrades/downgrades taken, combine it with --disablerepo, --enablerepo. -- Radek Holý Associate Software Engineer Software Management Team Red Hat Czech -- 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: bodhi buildroot override takes how long?
On Tue, 14 Apr 2015 17:51:22 +0200 Michael Schwendt wrote: > It's some time since I've had to submit a koji buildroot override via > the bodhi web interface. It has become much more slower. First of all, > the admin.fedoraproject.org server answers slower. And the koji > wait-repo command has yet to end. > > What is the current estimate on how long it takes for bodhi to process > a buildroot override request? > > koji lists a tag "f22-override" for the build, but that's not the tag > I need to query. bodhi says "f22-build". I see other requests that > have not been processed yet with the same symptoms. How long does it > take nowadays? It varies. The package is tagged into the override tag. The kojira process sees that the build target needs regenerating. However, it only does 6 newrepos at a time (used to be 3). All the side tags need this, so since we have f21-build, f21-gnome, f21-kde, f21-whhatever, there's a lot of tags to regen. Best case is that it sees it and starts the newrepo right then, and then it's been taking about 6 minutes or so. Worst case is that it has to wait for another few to finish normally. However, in this case, it appears a f22-build newrepo got stuck, so it's not doing anymore waiting for that one. This is very likely related to db issues I have spent all morning trying to track down. :( I will clear that newrepo and get f22-build back on track in the mean time. kevin pgpalR6Rgxjje.pgp Description: OpenPGP digital signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Enable Wake-On-LAN in current Fedora
On Tue, 2015-04-14 at 09:12 -0700, Samuel Sieb wrote: > On 04/14/2015 09:06 AM, Chris Adams wrote: > > Once upon a time, Sergio Pascual said: > >> I was wondering what is the "correct" way of enabling WOL on a network > >> card. > > > > I think it is enabled by default. At least, I didn't do anything to > > enable it on a couple of computers at home and it "just works". > > > Make sure it's enabled in the BIOS. On the NetworkManager side there isn't any checkbox for enable/disable since that's a bit lower-level than NM right now, but NM won't screw anything up if you enable WoL with ethtool through some other mechanism, like a systemd unit file. Dan -- 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: Enable Wake-On-LAN in current Fedora
On 04/14/2015 09:06 AM, Chris Adams wrote: Once upon a time, Sergio Pascual said: I was wondering what is the "correct" way of enabling WOL on a network card. I think it is enabled by default. At least, I didn't do anything to enable it on a couple of computers at home and it "just works". Make sure it's enabled in the BIOS. -- 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: Enable Wake-On-LAN in current Fedora
Once upon a time, Sergio Pascual said: > I was wondering what is the "correct" way of enabling WOL on a network card. I think it is enabled by default. At least, I didn't do anything to enable it on a couple of computers at home and it "just works". -- Chris Adams -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Enable Wake-On-LAN in current Fedora
I was wondering what is the "correct" way of enabling WOL on a network card. This Arch document [1] describes several methods (which basically are different methods on running "ethtool -s eth0 wol g"). * run ethtool in udev * run a cron on reboot * run a systemd unit This Fedora bug [2] suggests that you can make NetworkManager run a script in /etc/NetworkManager/dispatcher.d And finally you can use good old /etc/rc.d/rc.local and put there the ethtool command. Notice that all of this requires editing files, there isn't a check box somewhere in the NetworkManager GUI to enable this option, for example. Regards, Sergio [1] https://wiki.archlinux.org/index.php/Wake-on-LAN [2] https://bugzilla.redhat.com/show_bug.cgi?id=826652 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
bodhi buildroot override takes how long?
It's some time since I've had to submit a koji buildroot override via the bodhi web interface. It has become much more slower. First of all, the admin.fedoraproject.org server answers slower. And the koji wait-repo command has yet to end. What is the current estimate on how long it takes for bodhi to process a buildroot override request? koji lists a tag "f22-override" for the build, but that's not the tag I need to query. bodhi says "f22-build". I see other requests that have not been processed yet with the same symptoms. How long does it take nowadays? -- 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: hibernation support - lack of distro-wide coordination between systemd, dracut, anaconda, pm-utils and maybe more?
On Tue, Apr 14, 2015 at 3:07 AM, Bastien Nocera wrote: > > > - Original Message - >> OK not everyone is on the same page, apparently. This bug was just >> closed by Anaconda as WONTFIX. >> >> suggested swap for laptop seems low >> https://bugzilla.redhat.com/show_bug.cgi?id=1037472 >> >> I don't see how hibernation works reliably with such a low default swap size. > > This isn't the way to fix it. The hibernation file/partition should really be > independent > of swap, because 1) you can't be sure how much swap will actually be used by > the applications > so you can't be sure you'll ever have enough swap to save the RAM 2) Too much > swap and the > (lack of) interactivity will make you want to advocate physical violence when > your machine > is unusable for an hour because of a hungry Javascript in your 50th Firefox > tab. Windows and OS X both use swapfiles rather than swap partition, and a sleep image file rather than a partition. OS X's swapfiles are dynamically created on demand in variable size increments. Recently, Windows on UEFI systems with the proper hardware uses Intel Rapid Start [1], which is firmware managed suspend-to-disk. It depends on both a unique partition and SSD, and by default a shutdown uses this. Cold boots are really fast, like ~1.5 seconds. Faster than reboots. Both OS's have a feature that I find invaluable on a laptop which is the automatic switch from suspend-to-RAM to suspend-to-disk. Because of this, I never do shutdowns. I can always rely on just closing the laptop lid to get suspend-to-RAM and if necessary (time or low battery) the system wakes and suspends-to-disk. I can't rely on suspend-to-RAM on linux because I can't guarantee I'll remember to wake it and do a proper shutdown before the battery dies. I'd put suspend-to-disk in the same category as video problems. It's yet another reason to just not fight things, give up, and use what works which is either Windows or OS X, and put Linux in a VM. *shrug* > I requested a hibernation partition that wasn't a swap partition: > https://wiki.gnome.org/BastienNocera/KernelWishlist > but it was deemed unnecessary by kernel devs (or work-aroundable maybe): > http://thread.gmane.org/gmane.linux.kernel/1810083/focus=1813873 > > We need to fix the kernel first, then we can ask for support in Anaconda. If kernel developers don't see working suspend-to-disk to be important, then in my view Linux on the desktop is just short of pointless and is just treading water with the existing behavior. The two other OS's simply do this way way better and more reliably to the point it's bulletproof and completely trustworthy. How is this working on Chromebooks? [1] http://mjg59.dreamwidth.org/26022.html -- 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
[Test-Announce] Fedora 22 Beta Go/No-Go Meeting #2, Thursday, April 16 @ 17:00 UTC
Join us on irc.freenode.net in #fedora-meeting-2 for this important meeting, wherein we shall determine the readiness of the Fedora 22 Beta. Thursday, April 16, 2015 17:00 UTC (1 PM EDT, 10 AM PDT, 19:00 CEST) "Before each public release Development, QA and Release Engineering meet to determine if the release criteria are met for a particular release. This meeting is called the Go/No-Go Meeting." "Verifying that the Release criteria are met is the responsibility of the QA Team." For more details about this meeting see: https://fedoraproject.org/wiki/Go_No_Go_Meeting In the meantime, keep an eye on the Fedora 22 Beta Blocker list: http://qa.fedoraproject.org/blockerbugs/milestone/22/beta/buglist Jaroslav ___ test-announce mailing list test-annou...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/test-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: dnf replacing yum and dnf-yum
On Apr 13, 2015 5:07 AM, "Radek Holy" wrote: > > > >> >> From: "Pete Travis" >> To: "Development discussions related to Fedora" < devel@lists.fedoraproject.org> >> Sent: Friday, April 10, 2015 5:31:08 PM >> Subject: Re: dnf replacing yum and dnf-yum >> >> >> >> On Apr 10, 2015 4:39 AM, "Radek Holy" wrote: >> > >> >> > >> > Hm, I think that it depends on the use case. AFAIK, distro-sync is mostly used to upgrade Fedora (an unsupported approach AFAIK) and to replace some testing/3rd-party versions of package with the "official" ones. (BTW, I'd appreciate if anyone will share their use case) While in the first case, I think that the upgrade's behaviour is preferred, in the other case, the install's behaviour is better IMO. (Which dangerously indicates that the --skip-broken switch is a good solution :( ) >> > >> > Anyway, file an RFE (if it isn't filed already) please. We can track/discuss it there. >> > >> > Thank you in advance >> > -- >> > Radek Holý >> > >> >> (lots of trimming, and skipping an RFE, as this just pertains to the distro-sync use case question) >> >> distro-sync is useful for getting to a sane state after temporarily enabling some repo that interacts with the primary ones. This can happen with third party repos, but we can consider an entirely in-house situation: >> >> The user finds a bug in widget-2.5.7 and reports it. A fix for widget is shipped and the user is asked to test via `dnf update widget --enablerepo updates-testing`. The transaction pulls in many requires from updates-testing (although at this point, I realize dnf may not be upgrading the requires in this transaction if they are not versioned). The new widget is tested, life goes on. >> >> Later, the user wants to install or update some package whizbang that shares requires with widget. That package has versioned requires on packages from the updates repo, but some of the installed packages are from updates-testing and don't provide what whizbang needs. >> >> Something like `dnf --allowerasing install whizbang` might be the appropriate and precise tool to get through that transaction. `dnf distro-sync` is the less precise, big-hammer tool for the user that doesn't know or care to track down the intricacies of widget and whizbang dependencies. They ran some command from a bug report a while ago and moved on, and now they run distro-sync to return their system to a known-good state and move on. >> >> This sort of thing is most common during the prerelease cycle, when users will have updates-testing on then off, and there are freezes, and branching, and lots of activity that might leave early adopters in an unsane state. >> >> And yeah, it is very useful for upgrades. Even when ran after a proper fedup upgrade. >> >> --Pete >> >> > Yeah, that's basically what I meant by 'replace some testing versions of package with the "official" ones'. Anyway, thank you for elaborating on it. I'll definitely make a test case from it. > > I'd like to let those doing the actions described above know that there is also a not very well known command "dnf repository-packages remove-or-distro-sync" which is specifically designed for switching from packages installed from testing/3rd-party repositories > -- > Radek Holý > Associate Software Engineer > Software Management Team > Red Hat Czech > > -- Nice! That's as the stable/updates repo, not the testing/3rd-party/problem repo, right? I'll add this to my dnf writeup. --Pete -- 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: hibernation support - lack of distro-wide coordination between systemd, dracut, anaconda, pm-utils and maybe more?
On 04/13/2015 11:34 PM, Zbigniew Jędrzejewski-Szmek wrote: OK, so swap 2x memory seems excessive. Actually swap with the same as memory should work *most* of the time. There's no guarantee that any amount swap will be enough, since it could all be filled by the time hibernation is requested, but we should try to cover most normal usage. But considering that swap will be slow on HDD, so users will most likely avoid using more than a small amount, and SDD are small, so it's expensive to provide bigger swap, the default that anaconda uses seems OK. An exception is for computers with small amount of RAM (<= 2GB?). There swaps is more likely to be filled and the default size for swap should imho be higher than the amount of RAM. Exactly! remember that a typical disk speed is few tens of MB/s, i.e. about 1 GB/min. I came to the conclusion that anything more than 4GB is just counterproductive. Large swap just deceives us into thinking that we can run jobs larger than the physical memory but that is really not the case, just like Seymour Cray said [1]. Maybe swap space should simply be max(4GB, $PhysicalMemory). Actually, isn't 'swap to filesystem' still an option? if so, maybe swap should be a constant 4GB, and hibernation should create an appropriately sized file on the fly, join it to the swap and use both. The details can be worked out. But I don't understand the justification for closing of the bug: (In reply to David Lehman from comment #1) Anaconda does not automatically configure systems for hibernation at this time. Hibernation is important for many use cases, including graphical environments, and anaconda should support them. Absolutely agree. [1] http://hackersays.com/68b2b7 -- 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: Fwd: Why Isn't NFS Working?
On Mon, 13 Apr 2015, Kelly Miller wrote: > I managed to figure it out. nfs-lock doesn't seem to be starting through > systemd, and I'm not sure why. I can start it using start manually, but > when I try to enable it to start on system load, it claims "No file or > directory". That sounds like it might this problem: 'rpc-statd won't start for user mounts' http://marc.info/?t=14231431302&r=1&w=2 Except that the error message is a bit different.. Is this a user mount? Ben > On Mon, Apr 13, 2015 at 6:15 PM, Kelly Miller > wrote: > > > Let's see... > > The server is CentOS 6. There's nothing fancy about the setup; rather > > than running an account sync like NIS or LDAP, I just make sure that both > > computers have the same users with the same user id's on both computers > > (it's a home network setup with both computers sitting right next to each > > other with a switch between them, so I can guarantee that). I'm using the > > same fstab options I normally use: hard, intr, rsize=8192, wsize=8192, tcp, > > nfsvers=3 . But for whatever reason, I get this message whenever I try to > > mount the drive. > > > > On Mon, Apr 13, 2015 at 12:54 PM, Jason L Tibbitts III > math.uh.edu> > > wrote: > > > >> > "KM" == Kelly Miller writes: > >> > >> KM> I just tried to mount my home folders using NFS as I usually do, but > >> KM> no matter what I get the error mount.nfs: requested NFS version or > >> KM> transport protocol is not supported. Did something change in the > >> KM> Alpha of Fedora 22 to suddenly break NFS mounting? I've tried a > >> KM> bunch of mount options, but nothing seems to work. > >> > >> I know that a kernel update in Fedora 21 broke kerberized NFS4 export > >> (on the server) when selinux is enabled, but I'm guessing that's not > >> your issue. Perhaps you could provide more details. > >> > >> - J< > >> > > > > > -- next part -- > An HTML attachment was scrubbed... -- 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: Fwd: Why Isn't NFS Working?
No, it isn't. On Tue, Apr 14, 2015 at 5:22 AM, Benjamin Coddington wrote: > On Mon, 13 Apr 2015, Kelly Miller wrote: > > > I managed to figure it out. nfs-lock doesn't seem to be starting through > > systemd, and I'm not sure why. I can start it using start manually, but > > when I try to enable it to start on system load, it claims "No file or > > directory". > > That sounds like it might this problem: > > 'rpc-statd won't start for user mounts' > http://marc.info/?t=14231431302&r=1&w=2 > > Except that the error message is a bit different.. > > Is this a user mount? > > Ben > > > On Mon, Apr 13, 2015 at 6:15 PM, Kelly Miller gmail.com> > > wrote: > > > > > Let's see... > > > The server is CentOS 6. There's nothing fancy about the setup; rather > > > than running an account sync like NIS or LDAP, I just make sure that > both > > > computers have the same users with the same user id's on both computers > > > (it's a home network setup with both computers sitting right next to > each > > > other with a switch between them, so I can guarantee that). I'm using > the > > > same fstab options I normally use: hard, intr, rsize=8192, wsize=8192, > tcp, > > > nfsvers=3 . But for whatever reason, I get this message whenever I > try to > > > mount the drive. > > > > > > On Mon, Apr 13, 2015 at 12:54 PM, Jason L Tibbitts III math.uh.edu> > > > wrote: > > > > > >> > "KM" == Kelly Miller writes: > > >> > > >> KM> I just tried to mount my home folders using NFS as I usually do, > but > > >> KM> no matter what I get the error mount.nfs: requested NFS version or > > >> KM> transport protocol is not supported. Did something change in the > > >> KM> Alpha of Fedora 22 to suddenly break NFS mounting? I've tried a > > >> KM> bunch of mount options, but nothing seems to work. > > >> > > >> I know that a kernel update in Fedora 21 broke kerberized NFS4 export > > >> (on the server) when selinux is enabled, but I'm guessing that's not > > >> your issue. Perhaps you could provide more details. > > >> > > >> - J< > > >> > > > > > > > > -- next part -- > > An HTML attachment was scrubbed... > -- 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: New Upstream Release Monitoring Systems
On 02/24/2015 05:58 PM, Ralph Bean wrote: On Tue, Feb 24, 2015 at 12:33:29PM +0100, Petr Hracek wrote: In our project called rebase-helper https://github.com/phracek/rebase-helper we would like to analyze a new upstream version against an old upstream version and let user now what is changed. E.g. Binaries are missing, soname bump change, header files are missing etc. Is there any possibility how to integrate a tool (e.g. rebase-helper) to upstream release monitoring system? Wow. This looks great and I'd love to have it integrated into the-new-hotness (that's the Fedora-specific daemon that files bugs and tries scratch builds). The relevant code is here: https://github.com/fedora-infra/the-new-hotness/blob/develop/hotness/buildsys.py#L78-L123 Want to try your hand at adding it in? Stop by #fedora-apps when you have time to chat about it and we can work on the details if you like. We're entering infrastructure Alpha freeze later today, so we wouldn't be able to push this out for a few weeks at the earliest. Well, new version of rebase-helper (0.5.0) is going to be available soon. I have looked at the relevant code and seems to be fine to integrated rebase-helper to the-new-hotness. I will provide a API to rebase-helper soon. I will inform you about it, though. What rebase-helper needs is a directory with package and version. -- Petr Hracek Software Engineer Developer Experience Red Hat, Inc Mob: +420777056169 email: phra...@redhat.com -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
F-22 Branched report: 20150414 changes
Compose started at Tue Apr 14 07:15:02 UTC 2015 Broken deps for armhfp -- [Sprog] Sprog-0.14-27.fc20.noarch requires perl(:MODULE_COMPAT_5.18.0) [aeskulap] aeskulap-0.2.2-0.19beta1.fc22.armv7hl requires libofstd.so.3.6 aeskulap-0.2.2-0.19beta1.fc22.armv7hl requires liboflog.so.3.6 aeskulap-0.2.2-0.19beta1.fc22.armv7hl requires libijg8.so.3.6 aeskulap-0.2.2-0.19beta1.fc22.armv7hl requires libijg16.so.3.6 aeskulap-0.2.2-0.19beta1.fc22.armv7hl requires libijg12.so.3.6 aeskulap-0.2.2-0.19beta1.fc22.armv7hl requires libdcmnet.so.3.6 aeskulap-0.2.2-0.19beta1.fc22.armv7hl requires libdcmjpeg.so.3.6 aeskulap-0.2.2-0.19beta1.fc22.armv7hl requires libdcmimgle.so.3.6 aeskulap-0.2.2-0.19beta1.fc22.armv7hl requires libdcmimage.so.3.6 aeskulap-0.2.2-0.19beta1.fc22.armv7hl requires libdcmdata.so.3.6 [avro] avro-mapred-1.7.5-9.fc22.noarch requires hadoop-mapreduce avro-mapred-1.7.5-9.fc22.noarch requires hadoop-client [bro] broccoli-2.3-1.fc22.armv7hl requires bro-2.3 python-broccoli-2.3-1.fc22.armv7hl requires bro-2.3 [crystal] crystal-2.2.1-2.fc22.armv7hl requires libkdecorations.so.4 [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 [gcc-python-plugin] gcc-python2-debug-plugin-0.13-2.fc22.armv7hl requires gcc = 0:4.9.2-1.fc22 gcc-python2-plugin-0.13-2.fc22.armv7hl requires gcc = 0:4.9.2-1.fc22 gcc-python3-debug-plugin-0.13-2.fc22.armv7hl requires gcc = 0:4.9.2-1.fc22 gcc-python3-plugin-0.13-2.fc22.armv7hl requires gcc = 0:4.9.2-1.fc22 [kde-style-skulpture] kde-style-skulpture-0.2.4-9.fc22.armv7hl requires libkdecorations.so.4 [kfilefactory] kfilefactory-0.1.1-8.fc21.noarch requires kdebase-workspace [leksah] ghc-leksah-devel-0.12.1.3-16.fc22.armv7hl requires ghc-devel(utf8-string-0.3.7-013ef9ad8ac70ebb11df31f487b74f26) ghc-leksah-devel-0.12.1.3-16.fc22.armv7hl requires ghc-devel(unix-2.6.0.1-7550b9ae9dbc74e4d6570cc239a29030) ghc-leksah-devel-0.12.1.3-16.fc22.armv7hl requires ghc-devel(transformers-0.3.0.0-23508e0b4a1c1bc1cf2c2de3bb13e90c) ghc-leksah-devel-0.12.1.3-16.fc22.armv7hl requires ghc-devel(time-1.4.0.1-970760bdd865d8b6cafac382276795a2) ghc-leksah-devel-0.12.1.3-16.fc22.armv7hl requires ghc-devel(text-0.11.3.1-17cae9ba49c3f3d533bf78a6e387f543) ghc-leksah-devel-0.12.1.3-16.fc22.armv7hl requires ghc-devel(strict-0.3.2-04f0cc1e99eff2196c0a7cd16d748b37) ghc-leksah-devel-0.12.1.3-16.fc22.armv7hl requires ghc-devel(regex-tdfa-1.1.8-0b03687c4e38c00ef92e9445170081e2) ghc-leksah-devel-0.12.1.3-16.fc22.armv7hl requires ghc-devel(regex-base-0.93.2-6a541a53412d1d7d310fa69bca50c85f) ghc-leksah-devel-0.12.1.3-16.fc22.armv7hl requires ghc-devel(pretty-1.1.1.0-2de27f83b2c1c65d629a564e9e01b27d) ghc-leksah-devel-0.12.1.3-16.fc22.armv7hl requires ghc-devel(parsec-3.1.3-a8bebef411959de671abb0f1f7da556f) ghc-leksah-devel-0.12.1.3-16.fc22.armv7hl requires ghc-devel(old-time-1.1.0.1-29c02e2b3bbdfd9a5756f0c46f4d6071) ghc-leksah-devel-0.12.1.3-16.fc22.armv7hl requires ghc-devel(network-2.4.1.2-82f6bcf79fe0252b3ab387e8dcb82e71) ghc-leksah-devel-0.12.1.3-16.fc22.armv7hl requires ghc-devel(mtl-2.1.2-2f2cd438035824ec2bed4811930bc232) ghc-leksah-devel-0.12.1.3-16.fc22.armv7hl requires ghc-devel(ltk-0.12.1.0-2fbb10498719be9dbdbb3d9f8adedbec) ghc-leksah-devel-0.12.1.3-16.fc22.armv7hl requires ghc-devel(leksah-server-0.12.1.2-7dbd70c9f5e4dd8b3b5efcb6597b3bfd) ghc-leksah-devel-0.12.1.3-16.fc22.armv7hl requires ghc-devel(hslogger-1.2.1-43834164508859009a3cc8aef7fd1e84) ghc-leksah-devel-0.12.1.3-16.fc22.armv7hl requires ghc-devel(gtksourceview2-0.12.5.0-588b179d0562576f9afa46559cebf79f) ghc-leksah-devel-0.12.1.3-16.fc22.armv7hl requires ghc-devel(gtk-0.12.5.0-2342a114ec8897cecfdda15ac92aed08) ghc-leksah-devel-0.12.1.3-16.fc22.armv7hl requires ghc-devel(glib-0.12.5.0-1b94df160e141377711a221615168695) ghc-leksah-devel-0.12.1.3-16.fc22.armv7hl requires ghc-devel(gio-0.12.5.0-b012293268f349d8f05c73d053798c7b) ghc-leksah-devel-0.12.1.3-16.fc22.armv7hl requires ghc-devel(ghc-7.6.3-18fc786f8ad3478b9bb568d865b0e48d) ghc-leksah-devel-0.12.1.3-16.fc22.armv7hl requires ghc-devel(filepath-1.3.0.1-62570c67b40fb99e7078c0d179220531) ghc-leksah-devel-0.12.1.3-16.fc22.armv7hl requires ghc-devel(enumerator-0.4.19-a164f71ed1088e349dd8bc4cdee8e449) ghc-leksah-devel-0.12.1.3-16.fc22.armv7hl requires ghc-devel(directory-1.2.0.1-504c99535d64699e20e001d81b577d06) ghc-leksah-devel-0.12.1.3-16.fc22.armv7hl requires ghc-devel(deepseq-1.3.0.1-aa1be128186a233c7290faf88620ffe5) ghc-leksah-devel-0.12.1.3-16.fc22.
Re: dnf replacing yum and dnf-yum
- Original Message - > From: "Rave it" > To: devel@lists.fedoraproject.org > Sent: Tuesday, April 14, 2015 12:45:41 PM > Subject: Re: dnf replacing yum and dnf-yum > > > Message: 13 > > Date: Tue, 14 Apr 2015 03:35:50 +0200 > > From: Kevin Kofler > > To: devel@lists.fedoraproject.org > > Subject: Re: dnf replacing yum and dnf-yum > > Message-ID: > > Content-Type: text/plain; charset="ISO-8859-1" > > > > Kevin Fenzi wrote: > > > * dnf-yum is installed by default. By that I mean it is in the 'core' > > > group in comps next to dnf. > > [snip] > > > * If you wish to still use yum, the yum package provides now > > > a /usr/bin/yum-deprecated command that is the old yum > > > command renamed. It also has the notice message as above > > > on it. > > > > IMHO, this is a really bad solution. yum should be yum, dnf should be dnf. > > > > Kevin Kofler > > +1 for reverting this > > Currently dnf-yum package provide /usr/bin/yum to force users to redirect to > dnf. > But unfortunately dnf doesn't find a local repo path, see > https://bugzilla.redhat.com/show_bug.cgi?id=1205341 . > I use a local repo to test all my packages in f22 VMs. > Shure, i can install packages by hand, but i have a lot of them and this slow > down my daily work. > In addition of missing plugins (ie. version-lock) dnf isn't usable for me in > this early stage. > I fixed that with downgrading/locking yum to last working release. > In my opinion fedora should not force users to use dnf if so much things > aren't working, currently. Hi, please, see my comment in the bug. It turned out that librepo doesn't handle 'file:/path'-like (note the missing double slash) URLs. As a workaround, you can convert it to a 'file:///path'-like URL. If further discussion is needed, let's discuss it here: https://github.com/Tojaj/librepo/issues/55 -- Radek Holý Associate Software Engineer Software Management Team Red Hat Czech -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
[Test-Announce] Fedora 22 Beta Release Candidate 2 (RC2) Available Now!
As per the Fedora 22 schedule [1], Fedora 22 Beta Release Candidate 2 (RC2) is now available for testing. Content information, including changes, can be found at https://fedorahosted.org/rel-eng/ticket/6132#comment:17 . Pleasesee the following pages for download links and testing instructions. Normally dl.fedoraproject.org should provide the fastest download, but download-ib01.fedoraproject.org is available as a mirror (with an approximately 1 hour lag) in case of trouble. To use it, just replace "dl" with "download-ib01" in the download URL. Installation: https://fedoraproject.org/wiki/Test_Results:Current_Installation_Test Base: https://fedoraproject.org/wiki/Test_Results:Current_Base_Test Workstation and Desktop: https://fedoraproject.org/wiki/Test_Results:Current_Desktop_Test Server: https://fedoraproject.org/wiki/Test_Results:Current_Server_Test Cloud: https://fedoraproject.org/wiki/Test_Results:Current_Cloud_Test Summary: https://fedoraproject.org/wiki/Test_Results:Current_Summary All Beta priority test cases for each of these test pages [2] must pass in order to meet the Beta Release Criteria [3]. For the Fedora 22 cycle we are also trying to run the Final tests at this time, to try and identify later release blocker bugs as early as possible. Help is available on #fedora-qa on irc.freenode.net [4], or on the test list [5]. Create Fedora 22 Beta test compose (TC) and release candidate (RC) https://fedorahosted.org/rel-eng/ticket/6132 Current Blocker and Freeze Exception bugs: http://qa.fedoraproject.org/blockerbugs/current [1] http://fedorapeople.org/groups/schedule/f-22/f-22-quality-tasks.html [2] https://fedoraproject.org/wiki/QA:Release_validation_test_plan [3] https://fedoraproject.org/wiki/Fedora_22_Beta_Release_Criteria [4] irc://irc.freenode.net/fedora-qa [5] https://admin.fedoraproject.org/mailman/listinfo/test -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net http://www.happyassassin.net ___ test-announce mailing list test-annou...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/test-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
[Test-Announce] ABRT Test Day Today
Hello, we'd like to invite you to take part in testing of cool new ABRT features such as: * restarting crashed application from ABRT notifications * handling of crashes in Docker containers If you want to participate, please have a look at the Test Day page: https://fedoraproject.org/wiki/Test_Day:2015-04-14_ABRT and follow the instructions. If you don't have much time, don't be discouraged by the huge number of test cases and go through only the new and important features. Thanks! Regards, Jakub Filak The ABRT Team ___ test-announce mailing list test-annou...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/test-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: dnf replacing yum and dnf-yum
> Message: 13 > Date: Tue, 14 Apr 2015 03:35:50 +0200 > From: Kevin Kofler > To: devel@lists.fedoraproject.org > Subject: Re: dnf replacing yum and dnf-yum > Message-ID: > Content-Type: text/plain; charset="ISO-8859-1" > > Kevin Fenzi wrote: > > * dnf-yum is installed by default. By that I mean it is in the 'core' > > group in comps next to dnf. > [snip] > > * If you wish to still use yum, the yum package provides now > > a /usr/bin/yum-deprecated command that is the old yum > > command renamed. It also has the notice message as above > > on it. > > IMHO, this is a really bad solution. yum should be yum, dnf should be dnf. > > Kevin Kofler +1 for reverting this Currently dnf-yum package provide /usr/bin/yum to force users to redirect to dnf. But unfortunately dnf doesn't find a local repo path, see https://bugzilla.redhat.com/show_bug.cgi?id=1205341 . I use a local repo to test all my packages in f22 VMs. Shure, i can install packages by hand, but i have a lot of them and this slow down my daily work. In addition of missing plugins (ie. version-lock) dnf isn't usable for me in this early stage. I fixed that with downgrading/locking yum to last working release. In my opinion fedora should not force users to use dnf if so much things aren't working, currently. regards, Wolfgang -- 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: hibernation support - lack of distro-wide coordination between systemd, dracut, anaconda, pm-utils and maybe more?
- Original Message - > OK not everyone is on the same page, apparently. This bug was just > closed by Anaconda as WONTFIX. > > suggested swap for laptop seems low > https://bugzilla.redhat.com/show_bug.cgi?id=1037472 > > I don't see how hibernation works reliably with such a low default swap size. This isn't the way to fix it. The hibernation file/partition should really be independent of swap, because 1) you can't be sure how much swap will actually be used by the applications so you can't be sure you'll ever have enough swap to save the RAM 2) Too much swap and the (lack of) interactivity will make you want to advocate physical violence when your machine is unusable for an hour because of a hungry Javascript in your 50th Firefox tab. I requested a hibernation partition that wasn't a swap partition: https://wiki.gnome.org/BastienNocera/KernelWishlist but it was deemed unnecessary by kernel devs (or work-aroundable maybe): http://thread.gmane.org/gmane.linux.kernel/1810083/focus=1813873 We need to fix the kernel first, then we can ask for support in Anaconda. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
