Xorg crashes detected by ABRT
Hi folks, I ported the ABRT kernel oops detector to journald some time ago, because of NoDefaultSyslog change. I wanted to do the same with the ABRT Xorg stack trace detector (just because I do not like the current implementation and it is possible now [2]), but I am not able to trigger the Xorg's stack trace dumper. I tried a couple of signals, but all my efforts led to a core dump file caught by the ABRT core dump hook. I thought I have the 'NoTrapSignals' option set to 'true', but 'grep NoTrapSignals -r /etc/ /usr/share/X11/' returns no results. Does Xorg handle the fatal signals on its own (it seems it does [3])? If so, how can I trigger it? Otherwise, I would love to remove the ABRT Xorg stack trace detector from Fedora. Regards, Jakub 1: http://fedoraproject.org/wiki/Changes/NoDefaultSyslog 2: http://who-t.blogspot.cz/2014/03/viewing-xorglog-with-journalctl.html 3: https://bugzilla.redhat.com/show_bug.cgi?id=1035508#c1 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Announcing the Fedora 21 Alpha for the Aarch64 architecture!
I'm pleased to announce the arrival of the Fedora Alpha release for the ARM aarch64 architecture. Feel free to take it for a drive [1]. The initial release of Fedora for aarch64 focuses on the Fedora Base and Server product with support for hardware plarforms such as the APM Storm platform including devices like the Mustang board, AMD Seattle and ARM Versatile Express64 including the Foundation emulator and the Juno hardware platform. The aarch64 Server product supports all the features of the product that the mainline primary platforms support. We also support the Base product set and the vast majority of the 15K+ source package set of the entire Fedora release are now built. === Fedora 21 Base === Each of the products will build on the "base" set of packages for Fedora. For instance, each product will use the same packages for the kernel, RPM, yum, systemd, Anaconda, and so forth. The Base Working Group develops the standard platform for all Fedora products, which includes the installer, compose tools, and basic platform for the other products. Base is not a full product intended for use on its own, but to be kept as a small, stable platform for other products to build on. === Fedora 21 Server === The Fedora Server product is a common base platform that is meant to run featured application stacks, which are produced, tested, and distributed by the Server Working Group. Want to use Fedora as a Web server, file server, database server, or platform for an Infrastructure-as-a-Service? Fedora 21 Server is for you. == Issues and Details == This is an Alpha release. As such, we expect that you may encounter bugs or missing features. To report issues encountered during testing, contact the Fedora ARM team via the arm mailing list or in #fedora-arm on freenode. The release can be found on the secondary architecture mirrors [2]. [1] https://fedoraproject.org/wiki/Architectures/AArch64/F21_Alpha/Installation [2] https://mirrors.fedoraproject.org/mirrorlist?repo=fedora-server-21&arch=aarch64 ___ devel-announce mailing list devel-annou...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel-announce -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Improving the offline updates user experience
On 22 October 2014 20:07, Michael Stahl wrote: > On 17.09.2014 13:58, Miroslav Suchý wrote: >> On 09/17/2014 11:54 AM, Bastien Nocera wrote: >>> All those OSes require reboots when updating the OS. >> >> Define OS. >> >> Firefox is definitely not OS. While systemd is OS. >> I am fine with reboot after systemd upgrade, but not after upgrading Firefox. > > the important point in that case is not reboot after upgrading Firefox > but *before* upgrading Firefox, which means that at the time of the > upgrade no Firefox will be running and potentially crashing because one > of the 100s of DSOs it loads on-demand has changed in an incompatible way. > > there used to be quite a few ABRT crashes reported against desktop > applications with impossible looking stack traces (although with the > automatic micro-reports it's less of a problem nowadays as they are > easier to ignore), and sometimes the reporter gives feedback that the > application was running across a yum update... > While it can be a bit confusing the first time it happens to you, the solution is just to start and stop firefox again in that case. If it the goal is just to tidy ABRT crash reports (and I'm not sure it is) then forcing reboots on users wouldn't be very kind. -- imalone http://ibmalone.blogspot.co.uk -- 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: Broken deps in rawhide (coreutils)
On Wed, 2014-10-22 at 12:48 -0600, Jerry James wrote:
> On Tue, Oct 21, 2014 at 12:41 PM, Kevin Fenzi wrote:
> > I am pointing the finger right now at icecat. It seems to be providing
> > all the nss libraries and 'winning' the dependency. It's making all the
> > buildroots a good deal larger than they need to be, and possibly making
> > them link to the wrong nss/nspr, etc. ;(
>
> The icecat spec file needs something like this:
>
> %global __provides_exclude_from ^%{_libdir}/%{name}-%{version}
>
I tried that yesterday in a scratch-build. It didn't work. I've been too
swamped today to try another approach.
> And I believe that "Requires: nspr" and "Requires: nss" should be
> removed. If icecat is linked against the system versions of those
> libraries, then the dependencies should be generated automatically.
> --
> Jerry James
> http://www.jamezone.org/
signature.asc
Description: This is a digitally signed message part
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Improving the offline updates user experience
On 17.09.2014 13:58, Miroslav Suchý wrote: > On 09/17/2014 11:54 AM, Bastien Nocera wrote: >> All those OSes require reboots when updating the OS. > > Define OS. > > Firefox is definitely not OS. While systemd is OS. > I am fine with reboot after systemd upgrade, but not after upgrading Firefox. the important point in that case is not reboot after upgrading Firefox but *before* upgrading Firefox, which means that at the time of the upgrade no Firefox will be running and potentially crashing because one of the 100s of DSOs it loads on-demand has changed in an incompatible way. there used to be quite a few ABRT crashes reported against desktop applications with impossible looking stack traces (although with the automatic micro-reports it's less of a problem nowadays as they are easier to ignore), and sometimes the reporter gives feedback that the application was running across a yum update... -- 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: Broken deps in rawhide (coreutils)
On Tue, Oct 21, 2014 at 12:41 PM, Kevin Fenzi wrote:
> I am pointing the finger right now at icecat. It seems to be providing
> all the nss libraries and 'winning' the dependency. It's making all the
> buildroots a good deal larger than they need to be, and possibly making
> them link to the wrong nss/nspr, etc. ;(
The icecat spec file needs something like this:
%global __provides_exclude_from ^%{_libdir}/%{name}-%{version}
And I believe that "Requires: nspr" and "Requires: nss" should be
removed. If icecat is linked against the system versions of those
libraries, then the dependencies should be generated automatically.
--
Jerry James
http://www.jamezone.org/
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Headsup updating miglayout to 4.2 for F-21+
Hi, I'm working on updating freecol to 0.11 and that needs a new miglayout, so I'm updating miglayout too, and I'll push them in tandem. This should not be a problem, since according to repoquery freecol is the only user of miglayout. Regards, Hans -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Summary/Minutes from today's FESCo Meeting (2014-10-22)
=== #fedora-meeting: FESCO (2014-10-22) === Meeting started by mattdm at 17:00:22 UTC. The full logs are available at http://meetbot.fedoraproject.org/fedora-meeting/2014-10-22/fesco.2014-10-22-17.00.log.html . Meeting summary --- * init process (mattdm, 17:00:27) * #1355 Please select Engineering Representiatve for the new Fedora Council (mattdm, 17:03:20) * LINK: https://fedorahosted.org/fesco/ticket/1355 (mattdm, 17:03:25) * LINK: https://lists.fedoraproject.org/pipermail/devel/2014-October/203391.html (mattdm, 17:03:26) * LINK: https://fedoraproject.org/wiki/User:Jwboyer/Fedora_Council_Engineering_Rep (mattdm, 17:03:52) * AGREED: fedora council engineering representative draft is accepted as official fesco policy (+6 / 0 / -0) (mattdm, 17:06:05) * ACTION: jwb to move draft to somewhere official and add appropriate categories (mattdm, 17:08:38) * AGREED: FESCo selects Josh Boyer (jwb) as Engineering * Representative for Fedora Council (+6,-0,1) (mattdm, 17:17:51) * congratuations josh (mattdm, 17:18:13) * #1322 F21 Changes - Progress at Change Checkpoint: 100% Code Complete Deadline (mattdm, 17:18:43) * LINK: https://fedorahosted.org/fesco/ticket/1322 (mattdm, 17:18:46) * #1357 please consider django-1.7 as late feature for f21 (mattdm, 17:23:05) * LINK: https://fedorahosted.org/fesco/ticket/1357 (mattdm, 17:23:08) * LINK: https://packages.debian.org/jessie/python-django (mrunge, 17:26:06) * AGREED: no exception for 1.7; will stick to 1.6 (since fedora 22 release scheduled to be proper 6-month cycles) (no vote, just general agreement) (mattdm, 17:55:00) * a copr could address 1.7 for people who need it (mattdm, 17:56:17) * Next week's chair (mattdm, 17:56:36) * t8m and kalev to fight for the week AFTER next (mattdm, 17:57:49) * ACTION: sgallagh to chair next week (mattdm, 17:57:56) * updated meeting process at https://fedoraproject.org/wiki/FESCo_meeting_process (mattdm, 17:58:11) * Open Floor (mattdm, 17:58:25) * LINK: https://fedorahosted.org/fesco/ticket/1359 (mattdm, 17:58:49) * AGREED: rel-eng will drop workstation tree so it isn't confusing (currently installs server) (+5,-1) (mattdm, 18:31:19) Meeting ended at 18:32:20 UTC. Action Items * jwb to move draft to somewhere official and add appropriate * categories * sgallagh to chair next week Action Items, by person --- * jwb * jwb to move draft to somewhere official and add appropriate categories * sgallagh * sgallagh to chair next week * **UNASSIGNED** * (none) People Present (lines said) --- * mattdm (160) * sgallagh (84) * dgilmore (78) * mrunge (51) * kalev (49) * jwb (40) * mitr (35) * t8m (19) * stickster (9) * zodbot (7) * jreznik_pp (1) * mmaslano (0) * nirik (0) * thozza (0) Generated by `MeetBot`_ 0.1.4 .. _`MeetBot`: http://wiki.debian.org/MeetBot -- 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
Fedora on Intel Edison
Hi, Is there anyone working on making Fedora work with the Intel Edison? Thx, -- --Jos Vos --X/OS Experts in Open Systems BV | Phone: +31 20 6938364 --Amsterdam, The Netherlands| Fax: +31 20 6948204 -- 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: Improving the offline updates user experience
On 10/22/2014 10:58, drago01 wrote: No the OS is more than just a kernel. Kernel Space contains more than just the kernel. It also contains device drivers, kernel extensions, and other privileged processes that require full system access. User Space exists as a barrier to keep applications separate from the OS itself. Tom -- 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: Improving the offline updates user experience
On Wed, Oct 22, 2014 at 4:45 PM, Tom Rivers wrote: > On 10/22/2014 06:31, Lennart Poettering wrote: >> >> It would be great if we could nicely isolate the apps from the OS so that >> we can restart the apps independently from the OS, but this requires >> isolating things first. > > > Isn't the differentiation between kernel space and user space sufficient for > identifying what is the OS and what is an application? I know Windows > blurred those lines during the Browser Wars with Netscape, but to my > knowledge that separation still exists in Linux. No the OS is more than just a kernel. -- 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: Improving the offline updates user experience
On 10/22/2014 06:31, Lennart Poettering wrote: It would be great if we could nicely isolate the apps from the OS so that we can restart the apps independently from the OS, but this requires isolating things first. Isn't the differentiation between kernel space and user space sufficient for identifying what is the OS and what is an application? I know Windows blurred those lines during the Browser Wars with Netscape, but to my knowledge that separation still exists in Linux. Tom -- 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: Improving the offline updates user experience
On 22 October 2014 04:31, Lennart Poettering wrote:
> On Wed, 17.09.14 13:58, Miroslav Suchý (msu...@redhat.com) wrote:
>
> > On 09/17/2014 11:54 AM, Bastien Nocera wrote:
> > >All those OSes require reboots when updating the OS.
> >
> > Define OS.
> >
> > Firefox is definitely not OS. While systemd is OS.
> > I am fine with reboot after systemd upgrade, but not after upgrading
> > Firefox.
>
> Well, on Fedora and Unixes the apps are just part of the OS, they are
> all dropped into /usr, and not isolated out.
>
> It would be great if we could nicely isolate the apps from the OS so
> that we can restart the apps independently from the OS, but this
> requires isolating things first.
>
> We are working on app sandboxes, and they will make this available,
> but it's the traditional Linux model cannot really deliver this.
>
>
Well it depends on the traditional model that you are going to refer to. In
the model of the Unix systems I had to set up in the late 1980's and the
1990's... there was a separation in that items for the OS were in the root
directories (say /bin and /sbin), and stuff that was not OS critical but
user critical were in /usr/{bin,sbin}. And then local critical were in /opt
or /usr/local depending on the OS.
We (Linux distributions) lost that distinction sometime in the past decade
and then undid it completely with the various /usr/ merges. [This isn't
meant to open that can of worms.. the distinction was broken before the
merge.. the merge just made it clear.]
I am not sure how to best move from here. A complete reinvent of
hierarchies is always tempting.. but it has always been the deathknell of
every OS that has done it in the past due to chasm crossing issues (too
much old stuff needing old things causing any benefits from new stuff to be
actual detriments). Doing a more thorough job of packaging items so that
system only items were in /bin,/lib, etc has never worked because too many
things sit between the two. [its a user component AND a system component!]
At best I can say it comes down to operating systems are too damn
complicated and I need to go back to potato farming :)
> Lennart
>
> --
> Lennart Poettering, Red Hat
> --
> devel mailing list
> devel@lists.fedoraproject.org
> https://admin.fedoraproject.org/mailman/listinfo/devel
> Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
>
--
Stephen J Smoogen.
--
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: Looking for xorg-x11-* package co-maintainers
Hi, On 10/22/2014 01:59 PM, Matthieu Gautier wrote: > Le 22/10/2014 11:25, Hans de Goede a écrit : >> Hi All, >> >> As you probably know the graphics team always has more work to do >> then we've manpower. >> >> As the person taking care of various old xor-x11 apps / utilities >> and utility libraries I'm looking for co-maintainers to help with >> maintaining these. >> >> You do not need to be a hardcore X hacker to help here. 2 things >> with which I really could use help is keeping all the various bits >> and pieces up2date with upstream releases, and taking care of >> simple (packaging) bugs were possible. >> >> To give you an idea, currently I've this list of packages which >> still need to be synced with upstream for rawhide and Fedora-21 : >> >> -xcb-proto 1.11 >> -libxcb 1.11 >> -xrandr 1.4.3 >> -libXfont 1.5.0 >> -twm-1.0.8 >> -imake 1.0.7, gccmakedep 1.0.3 (imake) >> -libICE 1.0.9 >> -libXft 2.3.2 >> -intel-gpu-tools 1.8 >> -xkeyboard-config 2.13 >> -xcb-util 0.4.0 >> >> Note these are the upstream package names, the Fedora package >> names are not always the same. Also in some cases someone else >> may have updated them since I noticed that they were out of date, >> I've not rechecked the list recently. >> >> If you want to help out with maintaining these, please let me >> know! > > Hi, > > I'm not a packager but I'm interesting in helping. > I'm not fully aware of all "rules" but I'm ready to learn :) Sorry, but I don't think that the xorg packages are a good place to start packaging. Regards, Hans -- 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: Looking for xorg-x11-* package co-maintainers
Hi, On 10/22/2014 01:44 PM, Simone Caronni wrote: > Out of the previous list, the only ones that have not been updated yet are: > > -intel-gpu-tools 1.8 (1.7 in rawhide/f21) > -xkeyboard-config 2.13 (2.12 in rawhide/f21) > -xcb-util 0.4.0 (0.3.9 in rawhide/f21) > -libxcb 1.11 (1.10 in f21) > -xrandr 1.4.3 (1.4.2 in f21) > -twm-1.0.8 (1.0.7 in f21) > -imake 1.0.7 (1.0.6 in f21) > -gccmakedep 1.0.3 (1.0.2 in f21) > > On 22 October 2014 12:17, Hans de Goede wrote: > >>> I'm no hacker, but I can help with packaging. >> >> Great! Note I'm still sorting out getting admin rights on these >> packages myself, so that I can grant others access. If you're a >> proven packager, just use your proven packager rights for now, >> if not just get everything ready, do a commit, followed by: >> >> git format-patch HEAD~ >> >> And then send me the resulting patch, and I'll apply it for now. >> If we go this route, please also let me know if I should apply >> this only to rawhide, or also to older releases (see below). >> > > I'm no provenpackager, will send the patches for those later. Sounds good, thanks. > All those libraries can be added to Upstream Tracker, I find it very handy. > I've requested some components already in the past and I find the service > very handy: > > http://upstream-tracker.org/ That is a good idea, feel free to do that. Regards, Hans -- 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: No more deltarpms by default
On Mon, Oct 6, 2014 at 10:41 AM, Rahul Sundaram wrote: > Hi > > One of the long standing features that were enabled by default in yum is > support for delta rpms. dnf developers have disabled this and I think this > change deserves a broader discussion > > https://bugzilla.redhat.com/show_bug.cgi?id=1148208 > > I don't know if this really will happen, but when I read this I had to think about this discussion. http://uk.reuters.com/article/2014/10/22/uk-hungary-internet-tax-idUKKCN0IB0RI20141022 So deltarpm might be a way of actually saving money ;-) -johannes > > Rahul > > -- > 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
[Test-Announce] 2014-10-22 @ 1600 UTC ** Fedora 21 Blocker Review Meeting
# F21 Blocker Review meeting # Date: 2014-10-22 # Time: 16:00 UTC (12:00 EDT, 09:00 PDT) # Location: #fedora-blocker-review on irc.freenode.net We've already had one blocker review meeting this week (which is likely why I forgot to send this email until now), but it's time for another! With Go/No-Go being decided tomorrow we have plenty to do in order to be ready. So far we've got 9 proposed blockers and and 4 proposed freeze exceptions to look through for this meeting. If you want to take a look at the accepted blockers, the full list can be found here: https://qa.fedoraproject.org/blockerbugs/milestone/21/beta/buglist We'll be evaluating these bugs to see if they violate the Beta Release Criteria and warrant the blocking of a release if they're not fixed. Information on the release criteria for F21 can be found on the wiki [0]. For more information about the Blocker and Freeze exception process, check out these links: - https://fedoraproject.org/wiki/QA:SOP_blocker_bug_process - https://fedoraproject.org/wiki/QA:SOP_freeze_exception_bug_process And for those of you who are curious how a Blocker Review Meeting works - or how it's supposed to go and you want to run one - check out the SOP on the wiki: - https://fedoraproject.org/wiki/QA:SOP_Blocker_Bug_Meeting See you in a couple hours! [0] https://fedoraproject.org/wiki/Fedora_Release_Criteria -- // Mike -- Fedora QA freenode: roshi http://roshi.fedorapeople.org ___ 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
Fedora 21 Beta Release Readiness Meeting :: Thursday, Oct. 23, 19:00 UTC
Fedora 21 Beta Release Readiness Meeting. date: 2014-10-23 place: irc.freenode.net in #fedora-meeting-2 time: 19:00 UTC (3 PM EDT, 12 PM PDT, 21:00 CEST) This Thursday, October 23, we will meet to make sure we are coordinated and ready for the Beta release of Fedora 21 on Tuesday, October 28, 2014. Please note that this meeting will occur on October 23 even if the release is delayed at the Go/No-Go meeting on the same day two hours earlier. You may received this message several times, but I was asked to open this meeting to the teams and I'll also hope this will raise awareness and more team representatives will come to this meeting. This meeting works best when we have representatives from all of the teams. Also, there's a Fedora badge for active participants! Jaroslav ___ devel-announce mailing list devel-annou...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel-announce -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Improving the offline updates user experience
On Wed, 22.10.14 14:11, Roberto Ragusa (m...@robertoragusa.it) wrote: > On 10/21/2014 10:02 PM, Lennart Poettering wrote: > > > Maybe > > that's actually a strategy to adopt here: upload the encryption keys > > into the firmware as efi vars, and then pull them out on next boots or > > so (assuming that efi vars can be marked to survive soft reboots > > without making them fully persistent...) > > Hmmm, surrendering your encryption keys to the only software > part which you do not have control on? The firmware runs at the highest priviliges anyway, it can do whatever it wants... You don't have to "surrender" you keys to it. If it wants them it can take them anyway... Lennart -- Lennart Poettering, Red Hat -- 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: No more deltarpms by default
On 10/17/2014 05:52 AM, poma wrote: > On 06.10.2014 16:46, Jaroslav Reznik wrote: >> - Original Message - >>> >>> >>> >>> On Mon, 2014-10-06 at 10:54 +0100, Ian Malone wrote: On 6 October 2014 09:41, Rahul Sundaram wrote: > Hi > > One of the long standing features that were enabled by default in yum is > support for delta rpms. dnf developers have disabled this and I think > this > change deserves a broader discussion > > https://bugzilla.redhat.com/show_bug.cgi?id=1148208 > "I have an internet flatrate at 150 mbs, and downloading the full rpms is ALOT faster than the the work that the delta rpms requires." Wow. Good to see normal users are taken into account. The main argument from a distro point of view is reducing load on servers, but I don't know many people on 150Mbs either. Heck, I've just tested my work janet connection and that's <100Mbs in our office. At home 8Mbps is a good day. (I'm assuming mbs is a typo for Mbps and not milli bit seconds, where the very slow transfer speed declines exponentially as the connection progresses.) >>> >>> >>> The deltarpms were meant to serve two purposes >>> >>> 1) (lesser) Address the needs of users in developing countries (where >>> Fedora is fairly popular) and bandwidth concerns are very considerable. >>> Many of these users have connections that are either metered or >>> extremely slow, so deltarpms provides a way to get the data to them more >>> economically. This of course can be handled with a non-default option, >>> so we can talk about making that more discoverable if we disable them by >>> default. >> >> This is a good point but even in developing countries internet access is >> getting better and better. A few years ago installation DVD was the only >> way how to access Fedora repo. It's not requested anymore. But yeah, I do >> not live there. >> I strongly disagree with this point. The internet access in developing countries may be getting better, but that is primarily city focused, and even in cities, the cost of internet access is still high. In a large developing country like India (where I live), a huge percentage of the population lives away from the cities. Unlike people living in the cities, the people in the small towns are more likely to be open to using Fedora, for reasons of both cost and principles. I work with the Fedora FreeMedia program, and I send out around 50 Fedora DVDs a month, out of which a good number is to individuals and organizations in rural areas. Regarding the use of deltarpms, if it were not for the availability of deltarpms, a large number of Fedora systems in developing countries will remain not updated, or very irregularly updated, which will result in a large number of Fedora users being exposed to security vulnerabilities. The users will not be able to help it, because the cost for internet access here is often tied to bandwidth usage, and even a weekly update of Fedora using the full rpms will be too expensive. Add to that the unreliability of the internet access, leading to download errors for bigger packages, and most users will choose not to update. So from what I know, based on my personal experience, and my experience in the Fedora FreeMedia program, the Fedora install and Live DVDs are still very relevant, and deltarpms are extremely relevant for developing countries. Please do not sound the death knell for these highly essential tools, based just on the experience in developed countries. p.s. Thanks to poma for bringing this mail thread to my attention. I was not on the Fedora devel list so far. I have now subscribed to the Fedora devel list, so as not to miss such important discussions. :-) -- Regards, Rejy M Cyriac (rmc) -- 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-21 Branched report: 20141022 changes
Compose started at Wed Oct 22 07:15:02 UTC 2014 Broken deps for armhfp -- [PyQuante] PyQuante-libint-1.6.4-11.fc21.1.armv7hl requires libint(armv7hl-32) = 0:1.1.6-2.fc21 [audtty] audtty-0.1.12-9.fc20.armv7hl requires libaudclient.so.2 [authhub] authhub-0.1.2-3.fc19.armv7hl requires libjson.so.0 [avro] avro-mapred-1.7.5-9.fc21.noarch requires hadoop-mapreduce avro-mapred-1.7.5-9.fc21.noarch requires hadoop-client [cduce] cduce-0.5.5-9.fc21.armv7hl requires ocaml(Camlp4) = 0:ebd368022fd2bc7b305a42902efa4c90 [cp2k] cp2k-2.5.1-8.fc21.armv7hl requires libint(armv7hl-32) = 0:1.1.6-2.fc21 cp2k-mpich-2.5.1-8.fc21.armv7hl requires libint(armv7hl-32) = 0:1.1.6-2.fc21 cp2k-openmpi-2.5.1-8.fc21.armv7hl requires libmpi_usempi.so.1 cp2k-openmpi-2.5.1-8.fc21.armv7hl requires libint(armv7hl-32) = 0:1.1.6-2.fc21 [deltacloud-core] deltacloud-core-rackspace-1.1.3-1.fc20.noarch requires rubygem(cloudservers) deltacloud-core-rackspace-1.1.3-1.fc20.noarch requires rubygem(cloudfiles) [django-recaptcha] django-recaptcha-0.1-7.20091212svn6.fc21.noarch requires python-django14 [dragonegg] dragonegg-3.4-0.3.rc0.fc21.armv7hl requires gcc = 0:4.8.2-14.fc21 [edelib] edelib-2.1-5.fc21.armv7hl requires libedelib.so edelib-devel-2.1-5.fc21.armv7hl requires libedelib.so [eucalyptus] eucalyptus-common-java-3.3.0-0.5.20130408git32052445.fc20.armv7hl requires hibernate3-jbosscache >= 0:3.6.10-7 [fatrat] 1:fatrat-1.2.0-0.21.beta2.fc21.armv7hl requires libtorrent-rasterbar.so.7 [flush] flush-0.9.12-10.fc21.armv7hl requires libtorrent-rasterbar.so.7 [freesteam] freesteam-ascend-2.1-6.20140724svn753.fc21.armv7hl requires libascend.so.1 [gedit-valencia] gedit-valencia-0.4.0-1.20131223git94442bf.fc21.armv7hl requires libvala-0.24.so.0 [gnome-python2-desktop] gnome-python2-metacity-2.32.0-18.fc21.armv7hl requires libmetacity-private.so.0 [gofer] ruby-gofer-0.77.1-2.fc21.noarch requires rubygem(qpid) >= 0:0.16.0 [leiningen] leiningen-1.7.1-7.fc20.noarch requires maven-ant-tasks leiningen-1.7.1-7.fc20.noarch requires classworlds [libghemical] libghemical-2.99.1-24.fc20.armv7hl requires libf77blas.so.3 libghemical-2.99.1-24.fc20.armv7hl requires libatlas.so.3 [libopensync-plugin-irmc] 1:libopensync-plugin-irmc-0.22-7.fc20.armv7hl requires libopenobex.so.1 [ltsp] ltsp-client-5.4.5-8.fc21.armv7hl requires fuse-unionfs ltsp-server-5.4.5-8.fc21.armv7hl requires cdialog [meshmagick] meshmagick-0.6.0-20.svn2898.fc21.armv7hl requires libOgreMain.so.1.8.1 meshmagick-libs-0.6.0-20.svn2898.fc21.armv7hl requires libOgreMain.so.1.8.1 [monodevelop-vala] monodevelop-vala-2.8.8.1-6.fc21.armv7hl requires vala < 0:0.25.0 [netdisco] netdisco-1.1-7.fc21.noarch requires perl(SNMP::Info::Layer2::Bay) [ocaml-pa-do] ocaml-pa-do-0.8.16-3.fc21.armv7hl requires ocaml(Camlp4) = 0:ebd368022fd2bc7b305a42902efa4c90 [openslides] openslides-1.3.1-3.fc21.noarch requires python-django < 0:1.5 [openstack-nova] openstack-nova-compute-2014.1.2-1.fc21.noarch requires libvirt-daemon-xen [openvas-client] openvas-client-3.0.3-8.fc20.armv7hl requires libopenvas_omp.so.6 openvas-client-3.0.3-8.fc20.armv7hl requires libopenvas_nasl.so.6 openvas-client-3.0.3-8.fc20.armv7hl requires libopenvas_misc.so.6 openvas-client-3.0.3-8.fc20.armv7hl requires libopenvas_hg.so.6 openvas-client-3.0.3-8.fc20.armv7hl requires libopenvas_base.so.6 [perl-RT-Authen-ExternalAuth] perl-RT-Authen-ExternalAuth-0.11-5.fc21.noarch requires rt3 [perl-RT-Extension-CommandByMail] perl-RT-Extension-CommandByMail-0.07-10.fc21.noarch requires perl(RT::Interface::Email) [pipelight-selinux] pipelight-selinux-0.2.1-2.fc21.noarch requires pipelight-common pipelight-selinux-0.2.1-2.fc21.noarch requires pipelight-common pipelight-selinux-0.2.1-2.fc21.noarch requires pipelight pipelight-selinux-0.2.1-2.fc21.noarch requires pipelight [pootle] pootle-2.1.6-8.fc21.noarch requires python-django14 [python-askbot-fedmsg] python-askbot-fedmsg-0.1.0-2.fc21.noarch requires askbot [python-coffin] python-coffin-0.3.7-3.fc21.noarch requires python-django14 [python-django-addons] python-django-addons-0.6.6-2.fc21.noarch requires python-django14 [python-django-longerusername] python-django-longerusername-0.4-5.20130204gite4e85d7d.fc21.noarch requires python-django14 [rubygem-linecache19] rubygem-linecache19-0.5.13-6.fc20.armv7hl requires libruby.so.2.0 [rubygem-rubigen] rubygem-rubigen-1.5.8-3.fc21.noarch requires rubygem(activesupport) < 0:3.2.0 [rubygem-ruby-debug-base19] rubygem-ruby-debug-base19-0.11.26-6.fc20.armv7hl requires libru
Re: Improving the offline updates user experience
On 10/21/2014 10:02 PM, Lennart Poettering wrote: > Maybe > that's actually a strategy to adopt here: upload the encryption keys > into the firmware as efi vars, and then pull them out on next boots or > so (assuming that efi vars can be marked to survive soft reboots > without making them fully persistent...) Hmmm, surrendering your encryption keys to the only software part which you do not have control on? -- Roberto Ragusamail at robertoragusa.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: Looking for xorg-x11-* package co-maintainers
Le 22/10/2014 11:25, Hans de Goede a écrit : > Hi All, > > As you probably know the graphics team always has more work to do > then we've manpower. > > As the person taking care of various old xor-x11 apps / utilities > and utility libraries I'm looking for co-maintainers to help with > maintaining these. > > You do not need to be a hardcore X hacker to help here. 2 things > with which I really could use help is keeping all the various bits > and pieces up2date with upstream releases, and taking care of > simple (packaging) bugs were possible. > > To give you an idea, currently I've this list of packages which > still need to be synced with upstream for rawhide and Fedora-21 : > > -xcb-proto 1.11 > -libxcb 1.11 > -xrandr 1.4.3 > -libXfont 1.5.0 > -twm-1.0.8 > -imake 1.0.7, gccmakedep 1.0.3 (imake) > -libICE 1.0.9 > -libXft 2.3.2 > -intel-gpu-tools 1.8 > -xkeyboard-config 2.13 > -xcb-util 0.4.0 > > Note these are the upstream package names, the Fedora package > names are not always the same. Also in some cases someone else > may have updated them since I noticed that they were out of date, > I've not rechecked the list recently. > > If you want to help out with maintaining these, please let me > know! Hi, I'm not a packager but I'm interesting in helping. I'm not fully aware of all "rules" but I'm ready to learn :) Don't hesitate to ping me on irc (I'm starmad). Regards, Matthieu. > > Regards, > > Hans > -- 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: 20141022 changes
Compose started at Wed Oct 22 05:15:02 UTC 2014 Broken deps for i386 -- [3Depict] 3Depict-0.0.16-3.fc22.i686 requires libmgl.so.7.2.0 [Agda] ghc-Agda-2.3.2.2-5.fc22.i686 requires libHSterminfo-0.3.2.5-ghc7.6.3.so ghc-Agda-2.3.2.2-5.fc22.i686 requires libHShaskeline-0.7.0.3-ghc7.6.3.so ghc-Agda-2.3.2.2-5.fc22.i686 requires ghc(haskeline-0.7.0.3-775b029f16a4b58f3cc6b4cb4f7e7ac5) ghc-Agda-devel-2.3.2.2-5.fc22.i686 requires libHSterminfo-0.3.2.5-ghc7.6.3.so ghc-Agda-devel-2.3.2.2-5.fc22.i686 requires libHShaskeline-0.7.0.3-ghc7.6.3.so ghc-Agda-devel-2.3.2.2-5.fc22.i686 requires ghc-devel(haskeline-0.7.0.3-775b029f16a4b58f3cc6b4cb4f7e7ac5) ghc-Agda-devel-2.3.2.2-5.fc22.i686 requires ghc(terminfo-0.3.2.5-61e0dc43a1465e327dacd9ab37bbe1a3) ghc-Agda-devel-2.3.2.2-5.fc22.i686 requires ghc(haskeline-0.7.0.3-775b029f16a4b58f3cc6b4cb4f7e7ac5) [PyQuante] PyQuante-libint-1.6.4-11.fc22.1.i686 requires libint(x86-32) = 0:1.1.6-2.fc21 [Sprog] Sprog-0.14-27.fc20.noarch requires perl(:MODULE_COMPAT_5.18.0) [audtty] audtty-0.1.12-9.fc20.i686 requires libaudclient.so.2 [authhub] authhub-0.1.2-3.fc19.i686 requires libjson.so.0 [cab] cab-0.1.9-12.fc22.i686 requires cabal-dev [collectd] collectd-onewire-5.4.1-10.fc22.i686 requires libowcapi-2.9.so.7 [condor] condor-plumage-8.1.4-7.a1a7df5.fc22.i686 requires libmongoclient.so [darcs] darcs-2.8.4-5.fc22.i686 requires libHSterminfo-0.3.2.5-ghc7.6.3.so darcs-2.8.4-5.fc22.i686 requires libHShaskeline-0.7.0.3-ghc7.6.3.so darcs-2.8.4-5.fc22.i686 requires ghc(terminfo-0.3.2.5-61e0dc43a1465e327dacd9ab37bbe1a3) darcs-2.8.4-5.fc22.i686 requires ghc(haskeline-0.7.0.3-775b029f16a4b58f3cc6b4cb4f7e7ac5) ghc-darcs-2.8.4-5.fc22.i686 requires libHSterminfo-0.3.2.5-ghc7.6.3.so ghc-darcs-2.8.4-5.fc22.i686 requires libHShaskeline-0.7.0.3-ghc7.6.3.so ghc-darcs-2.8.4-5.fc22.i686 requires ghc(terminfo-0.3.2.5-61e0dc43a1465e327dacd9ab37bbe1a3) ghc-darcs-2.8.4-5.fc22.i686 requires ghc(haskeline-0.7.0.3-775b029f16a4b58f3cc6b4cb4f7e7ac5) ghc-darcs-devel-2.8.4-5.fc22.i686 requires ghc-devel(terminfo-0.3.2.5-61e0dc43a1465e327dacd9ab37bbe1a3) ghc-darcs-devel-2.8.4-5.fc22.i686 requires ghc-devel(haskeline-0.7.0.3-775b029f16a4b58f3cc6b4cb4f7e7ac5) [debconf] debconf-1.5.53-1.fc22.noarch requires perl(:MODULE_COMPAT_5.18.2) [deltacloud-core] deltacloud-core-rackspace-1.1.3-1.fc20.noarch requires rubygem(cloudservers) deltacloud-core-rackspace-1.1.3-1.fc20.noarch requires rubygem(cloudfiles) [django-recaptcha] django-recaptcha-0.1-7.20091212svn6.fc21.noarch requires python-django14 [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 [dragonegg] dragonegg-3.4-0.3.rc0.fc21.i686 requires gcc = 0:4.8.2-14.fc21 [edelib] edelib-2.1-5.fc22.i686 requires libedelib.so edelib-devel-2.1-5.fc22.i686 requires libedelib.so [eucalyptus] eucalyptus-common-java-3.3.0-0.5.20130408git32052445.fc20.i686 requires hibernate3-jbosscache >= 0:3.6.10-7 [fatrat] 1:fatrat-1.2.0-0.21.beta2.fc22.i686 requires libtorrent-rasterbar.so.7 [flush] flush-0.9.12-10.fc22.i686 requires libtorrent-rasterbar.so.7 [gedit-valencia] gedit-valencia-0.4.0-1.20131223git94442bf.fc21.i686 requires libvala-0.24.so.0 [ghc-hjsmin] ghc-hjsmin-0.1.4.7-3.fc22.i686 requires libHSoptparse-applicative-0.9.0-ghc7.6.3.so [glances] glances-2.1.2-2.fc22.noarch requires python-psutil >= 0:2.0.0 [gofer] ruby-gofer-0.77.1-2.fc21.noarch requires rubygem(qpid) >= 0:0.16.0 [gorm] gorm-1.2.18-5.fc20.i686 requires libgnustep-gui.so.0.23 [gqrx] gqrx-2.2.0-12.fc22.i686 requires libgnuradio-runtime-3.7.5.so.0.0.0 gqrx-2.2.0-12.fc22.i686 requires libgnuradio-pmt-3.7.5.so.0.0.0 gqrx-2.2.0-12.fc22.i686 requires libgnuradio-filter-3.7.5.so.0.0.0 gqrx-2.2.0-12.fc22.i686 requires libgnuradio-fft-3.7.5.so.0.0.0 gqrx-2.2.0-12.fc22.i686 requires libgnuradio-blocks-3.7.5.so.0.0.0 gqrx-2.2.0-12.fc22.i686 requires libgnuradio-analog-3.7.5.so.0.0.0 [gr-air-modes] gr-air-modes-0-0.27.20140312gitcc0fa180.fc22.i686 requires libgnuradio-runtime-3.7.5.so.0.0.0 gr-air-modes-0-0.27.20140312gitcc0fa180.fc22.i686 requires libgnuradio-pmt-3.7.5.so.0.0.0 [gr-fcdproplus] gr-fcdproplus-0-0.3.20140920git1edbe523.fc22.i686 requires libgnuradio-runtime-3.7.5.so.0.0.0 gr-fcdproplus-0-0.3.20140920git1edbe523.fc22.i686 requires libgnuradio-blocks-3.7.5.so.0.0.0 gr-fcdproplus-0-0.3.20140920git1edbe523.fc22.i686 requires libgnuradio-audio-3.7.5.so.0.0.0 [gr-iqbal] gr-iqbal-0.37.2-2.fc22.i686 requires libgnuradio-runtime-3.7.5.so
Re: Improving the offline updates user experience
On Wed, Oct 22, 2014 at 08:48:59AM +0200, Miroslav Suchý wrote: > >Offline updates are more for the cases where things need to be > >reliable, because no well educated admin is available to instantly > >fix things. > > I will print it an pin up on my notice board. > > And the implication is that offline updates are not for readers of > devel@lists.fedoraproject.org I don't think that's very fair, without the context. First, of course, we're developing for more than just ourselves. And second, this isn't a reversible statement: just because offline updates primarily target one user type doesn't mean that other user types can't or shouldn't use it. Why do I care about this? The non-techie user wants less rebooting too. I'd love to see the updates toolchain get more smarts about recognizing when an update is "safe" (or at least "safer") and not reboot in those cases. That's possible but would be an investment of work. In the meantime, "offline updates if you want simple and guaranteed", "use yum or dnf online if you're able to handle unlikely but possible consequences" seems workable enough. -- 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: Looking for xorg-x11-* package co-maintainers
Out of the previous list, the only ones that have not been updated yet are: -intel-gpu-tools 1.8 (1.7 in rawhide/f21) -xkeyboard-config 2.13 (2.12 in rawhide/f21) -xcb-util 0.4.0 (0.3.9 in rawhide/f21) -libxcb 1.11 (1.10 in f21) -xrandr 1.4.3 (1.4.2 in f21) -twm-1.0.8 (1.0.7 in f21) -imake 1.0.7 (1.0.6 in f21) -gccmakedep 1.0.3 (1.0.2 in f21) On 22 October 2014 12:17, Hans de Goede wrote: > > I'm no hacker, but I can help with packaging. > > Great! Note I'm still sorting out getting admin rights on these > packages myself, so that I can grant others access. If you're a > proven packager, just use your proven packager rights for now, > if not just get everything ready, do a commit, followed by: > > git format-patch HEAD~ > > And then send me the resulting patch, and I'll apply it for now. > If we go this route, please also let me know if I should apply > this only to rawhide, or also to older releases (see below). > I'm no provenpackager, will send the patches for those later. > > Some packages of those need > > also to be put on par with recent packaging guidelines. > > Yes, cleaning up the specfiles would very much be welcome too. > Will send a separate patch for those components above. After that, maybe I can ask request for commit on the other packages. > Yes, more or less, mostly just look at the changelog and apply common > sense, > also depends on the package a bit, e.g. intel-gpu-tools is part of > xorg-x11-drv-intel bumping the actual driver needs to be done somewhat > carefully, > but bumping the tools is more or less always safe, as they are not that > important. twm also is probably best just kept fully up2date with upstream > in F-21. lib... OTOH may cause breakage (they should not but you never > know), > etc. > I will not be touching the intel driver :) All those libraries can be added to Upstream Tracker, I find it very handy. I've requested some components already in the past and I find the service very handy: http://upstream-tracker.org/ Regards, --Simone -- You cannot discover new oceans unless you have the courage to lose sight of the shore (R. W. Emerson). http://xkcd.com/229/ http://negativo17.org/ -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Proposal for integration tests infrastructure
Fedora lacks integration testing (unit testing done during build is not enough). Taskotron will be able to fill some gaps in the future, so maintainers will be able to set-up various tasks after their component is built. But even before this works we can benefit from having the tests already available (and run them manually if needed). Hereby, I'd like to get ideas and figure out answers for how and where to keep the tests. A similar discussion already took place before, which I'd like to continue in: https://lists.fedoraproject.org/pipermail/devel/2014-January/193498.html And some short discussion already took place here as well: https://lists.fedoraproject.org/pipermail/env-and-stacks/2014-October/000570.html Some high level requirements: * tests will be written by maintainers or broader community, not a dedicated team * tests will be easy to run on anybody's computer (but might be potentially destructive; some secure environment will not be part of tests) * tests will be run automatically after related components get built (probably by Taskotron) Where to keep tests? a/ in current dist-git for related components (problem with sharing parts of code, problem where to keep tests related for more components) b/ in separate git with similar functionality as dist-git (needs new infrastructure, components are not directly connected with tests, won't make mess in current dist-git) c/ in current dist-git but as ordinary components (no new infrastructure needed but components are not directly connected with tests) How to deliver tests? a/ just use them directly from git (we need to keep some metadata for dependencies anyway) b/ package them as RPMs (we can keep metadata there; e.g. Taskotron will run only tests that have "Provides: ci-tests(mariadb)" after mariadb is built; we also might automate packaging tests to RPMs) Structure for tests? a/ similar to what components use (branches for Fedora versions) b/ only one branch Test maintainers should be allowed to behave the same as package maintainers do -- one likes keeping branches the same and uses "%if %fedora" macros, someone else likes specs clean and rather maintain more different branches) -- we won't find one structure that would fit all, so allowing both ways seems better. Which framework to use? People have no time to learn new things, so we should let them to write the tests in any language and just define some conventions how to run them. Cheers, Honza -- 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: Improving the offline updates user experience
On Wed, 17.09.14 13:58, Miroslav Suchý (msu...@redhat.com) wrote: > On 09/17/2014 11:54 AM, Bastien Nocera wrote: > >All those OSes require reboots when updating the OS. > > Define OS. > > Firefox is definitely not OS. While systemd is OS. > I am fine with reboot after systemd upgrade, but not after upgrading > Firefox. Well, on Fedora and Unixes the apps are just part of the OS, they are all dropped into /usr, and not isolated out. It would be great if we could nicely isolate the apps from the OS so that we can restart the apps independently from the OS, but this requires isolating things first. We are working on app sandboxes, and they will make this available, but it's the traditional Linux model cannot really deliver this. Lennart -- Lennart Poettering, Red Hat -- 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: Improving the offline updates user experience
On Tue, 16.09.14 13:35, Petr Pisar (ppi...@redhat.com) wrote: > On 2014-09-16, Richard Hughes wrote: > > The much bigger issues is if you're using a D-Bus service > > like most applications seem to do (and most use quite a few system and > > session, directly and indirectly) then you've also got to co-ordinate > > and handle changing D-Bus API (which typically isn't versioned). > > Maybe it's time to version the API. > > Look at microkernel based systems which utilize messaging heavily and > the API consumers (applications or another subsystems) have to be > prepared for spurious API provider (server) restarts. > > A server can refuse a message any time (especially if it does not > understand the request). Simple operations are usualy implemented as > a sequence of requests and responses where initial request obtains > a descriptor (a session, a handle) and subsequent requests passe it as > context (a session) identifier. If the server is restarted in between, > the context identifier becomes unrecognized and it's up to the > application to deal with it. > > Just the fact that somebody calls functions over dbus instead of jumping > into a shared library do not free them from maintaing API. Well, the theory for this might be great. But reality tells us that code that isn't regularly tested tends to be broken. Hence: the assumption it would be reasonably possible to comprehensively test all kinds of updates between any combination of software versions, executed in any order, simultaneously with the user using the machine, then is simply wrong. You explode the test matrix, and without testing such upgrades will never be reliable. The offline update logic is about making the test matrix smaller, and adding determinism where it normally is missing. Lennart -- Lennart Poettering, Red Hat -- 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: Looking for xorg-x11-* package co-maintainers
Hi, On 10/22/2014 12:09 PM, Simone Caronni wrote: > On 22 October 2014 11:25, Hans de Goede wrote: > >> You do not need to be a hardcore X hacker to help here. 2 things >> with which I really could use help is keeping all the various bits >> and pieces up2date with upstream releases, and taking care of >> simple (packaging) bugs were possible. >> >> To give you an idea, currently I've this list of packages which >> still need to be synced with upstream for rawhide and Fedora-21 : >> >> -xcb-proto 1.11 >> -libxcb 1.11 >> -xrandr 1.4.3 >> -libXfont 1.5.0 >> -twm-1.0.8 >> -imake 1.0.7, gccmakedep 1.0.3 (imake) >> -libICE 1.0.9 >> -libXft 2.3.2 >> -intel-gpu-tools 1.8 >> -xkeyboard-config 2.13 >> -xcb-util 0.4.0 >> >> Note these are the upstream package names, the Fedora package >> names are not always the same. Also in some cases someone else >> may have updated them since I noticed that they were out of date, >> I've not rechecked the list recently. >> >> If you want to help out with maintaining these, please let me >> know! >> > > I'm no hacker, but I can help with packaging. Great! Note I'm still sorting out getting admin rights on these packages myself, so that I can grant others access. If you're a proven packager, just use your proven packager rights for now, if not just get everything ready, do a commit, followed by: git format-patch HEAD~ And then send me the resulting patch, and I'll apply it for now. If we go this route, please also let me know if I should apply this only to rawhide, or also to older releases (see below). > Some packages of those need > also to be put on par with recent packaging guidelines. Yes, cleaning up the specfiles would very much be welcome too. > What's the policy here? Always have the latest pushed to rawhide Yes. > and follow the usual rules for releases in freeze (i.e. no big jumps)? Yes, more or less, mostly just look at the changelog and apply common sense, also depends on the package a bit, e.g. intel-gpu-tools is part of xorg-x11-drv-intel bumping the actual driver needs to be done somewhat carefully, but bumping the tools is more or less always safe, as they are not that important. twm also is probably best just kept fully up2date with upstream in F-21. lib... OTOH may cause breakage (they should not but you never know), etc. Thanks & Regards, Hans -- 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: Looking for xorg-x11-* package co-maintainers
On 22 October 2014 11:25, Hans de Goede wrote: > You do not need to be a hardcore X hacker to help here. 2 things > with which I really could use help is keeping all the various bits > and pieces up2date with upstream releases, and taking care of > simple (packaging) bugs were possible. > > To give you an idea, currently I've this list of packages which > still need to be synced with upstream for rawhide and Fedora-21 : > > -xcb-proto 1.11 > -libxcb 1.11 > -xrandr 1.4.3 > -libXfont 1.5.0 > -twm-1.0.8 > -imake 1.0.7, gccmakedep 1.0.3 (imake) > -libICE 1.0.9 > -libXft 2.3.2 > -intel-gpu-tools 1.8 > -xkeyboard-config 2.13 > -xcb-util 0.4.0 > > Note these are the upstream package names, the Fedora package > names are not always the same. Also in some cases someone else > may have updated them since I noticed that they were out of date, > I've not rechecked the list recently. > > If you want to help out with maintaining these, please let me > know! > I'm no hacker, but I can help with packaging. Some packages of those need also to be put on par with recent packaging guidelines. What's the policy here? Always have the latest pushed to rawhide and follow the usual rules for releases in freeze (i.e. no big jumps)? Regards, --Simone -- You cannot discover new oceans unless you have the courage to lose sight of the shore (R. W. Emerson). http://xkcd.com/229/ http://negativo17.org/ -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Broken deps in rawhide (coreutils)
On Wed, 22 Oct 2014 09:51:36 +0200, Ralf Corsepius wrote: > On 10/21/2014 08:41 PM, Kevin Fenzi wrote: > > > I'm not sure why koji buildroots aren't busted however, unless it's > > somehow the hosts yum (in the case of koji, f20 and copr el6) is doing > > things differently? > > Well, koji buildroots also seem to be affected > > E.g. > https://kojipkgs.fedoraproject.org//packages/perl-Mail-Sender/0.8.23/1.fc22/data/logs/noarch/root.log > > Actually, I don't understand why they don't abort ;) There's something else I don't understand: fontconfig requires "font(:lang=en)" and this pulls in an arbitrary font package, "lyx-fonts" (A collection of Math symbol fonts for lyx). As why this is done, the %changelog points at early 2014: Add Requires: font(:lang=en) (#1025331, #845712) Let's see: Bug 1025331 - Firefox segfaults on headless systems Huh? Installing any font (whether used or not) may fix that indeed if it crashes because of missing fonts, but it still sounds like an ugly hack. Why not install a basic/useful font? And the other ticket? Bug 845712 - missing base fonts if no DE is installed Well, it has been reopened in April, because it is a display problem and is still reproducible. Obviously, "Math symbol fonts" are not really helpful in that case. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Looking for xorg-x11-* package co-maintainers
Hi All, As you probably know the graphics team always has more work to do then we've manpower. As the person taking care of various old xor-x11 apps / utilities and utility libraries I'm looking for co-maintainers to help with maintaining these. You do not need to be a hardcore X hacker to help here. 2 things with which I really could use help is keeping all the various bits and pieces up2date with upstream releases, and taking care of simple (packaging) bugs were possible. To give you an idea, currently I've this list of packages which still need to be synced with upstream for rawhide and Fedora-21 : -xcb-proto 1.11 -libxcb 1.11 -xrandr 1.4.3 -libXfont 1.5.0 -twm-1.0.8 -imake 1.0.7, gccmakedep 1.0.3 (imake) -libICE 1.0.9 -libXft 2.3.2 -intel-gpu-tools 1.8 -xkeyboard-config 2.13 -xcb-util 0.4.0 Note these are the upstream package names, the Fedora package names are not always the same. Also in some cases someone else may have updated them since I noticed that they were out of date, I've not rechecked the list recently. If you want to help out with maintaining these, please let me know! Regards, Hans -- 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: Broken deps in rawhide (coreutils)
On 10/21/2014 08:41 PM, Kevin Fenzi wrote: I'm not sure why koji buildroots aren't busted however, unless it's somehow the hosts yum (in the case of koji, f20 and copr el6) is doing things differently? Well, koji buildroots also seem to be affected E.g. https://kojipkgs.fedoraproject.org//packages/perl-Mail-Sender/0.8.23/1.fc22/data/logs/noarch/root.log Actually, I don't understand why they don't abort ;) Ralf -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
