Re: FESCo wants to know what you use i686 packages for
Hi, On Tue, 22 Mar 2022 00:57 +0100 Kevin Kofler via devel wrote: > Steven Ellis wrote: > > The issue on our home systems is 3rd party printer drivers. > > > > Eg > > mfc9140cdncupswrapper-1.1.4-0.i386 > > dcpj4120dwlpr-3.0.1-1.i386 > > dcpj4120dwcupswrapper-3.0.1-1.i386 > > mfc9140cdnlpr-1.1.2-1.i386 > > > > These then pull in a whole load of dependencies relating to CUPs > > etc. > > According to https://openprinting.github.io/printers/ , both those > printers allegedly support driverless printing through the Apple > AirPrint standard, which is supported by current CUPS. This SHOULD > include AirPrint over USB, if the standard is correctly and > completely implemented. It may be worth trying, though it may expose > fewer options than using the proprietary CUPS driver RPM. I do not have the above models, but I also need i686 for my Brother printer driver, even though my model (HL-L8250CDN) is also listed on that website. This is because not even the basic functions work correctly using the out-of-the-box support -- the whole "printing options" page is blank. I'm not sure if this is an error on the GNOME side or on the Brother side, but I do know that installing the driver which I have been unofficially packaging sinds ~ F23 makes it work again (at the expense of having the network-discovered printer appear as well, with the non-functional out-of-the-box "driver"). I did not report a bug about the missing options, I guess I can do that somewhere in the OpenPrinting organisation now that that has gained some momentum. In the meantime, the i686 driver is needed on this end. > I do not know whether these printers would also work with some Free > as in Speech CUPS driver such as generic PostScript, PCL, or ESC/P, > or such as the Gutenprint drivers for older Brother printer models, > nor, if they would at all, whether that would lead to more > flexibility than just using AirPrint. No other driver I tried in the ~ F23 timeframe would give me any output at that time. Regards, Stijn ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: FESCo wants to know what you use i686 packages for
Hi, On Wed, 16 Mar 2022 09:54:12 -0400 David Cantrell wrote: > If you use i686 packages for something now, please respond to this > thread. As many others, I need 32-bit printer drivers for my ~10 year old color laser: $ rpm -qa | grep i686 libgcc-11.2.1-9.fc35.i686 glibc-gconv-extra-2.34-28.fc35.i686 glibc-2.34-28.fc35.i686 brother-hl-l8250cdn-1.0-2.fc35.i686 Regards, Stijn ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: F22 System Wide Change: Replace Yum With DNF
On Tue, 17 Jun 2014 08:03:20 -0600 Kevin Fenzi ke...@scrye.com wrote: On Tue, 17 Jun 2014 09:07:39 +0200 Jan Zelený jzel...@redhat.com wrote: Any other suggestions then? Cause `pkg` would be my #1 choice. Personally, I think adding another name just adds another problem. kevin This, please do not invent some generic name and be forced in 10 years to rename yet again with the same arguments. Either keep the dnf name: - and update all documentation basically with s/yum/dnf/g - and make sure it's big in the release notes - and provide a yum frontend with compatibility warnings or rename dnf to yum and call it 4.0: - and warn programmers that the interface has changed - and make sure that obsoleted options warn of changed defaults My preference is the latter, basically because I don't see the wins in the first case, FWIW. --Stijn -- 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: gnome software shell search provider? [Re: Is Gnome Software ready for primetime?]
Hi, On Sun, 03 Nov 2013 14:23:28 +0100 Kevin Kofler kevin.kof...@chello.at wrote: Michael Scherer wrote: When statistics cost you money, yeah, I think that's important to take them in account. Maybe your employer do not care about this, but I strongly suspect mine does, and I strongly suspect that most companies do care about this as well. Company computers should get updated only by the sysadmins (which AFAIK is how it works at his company, him being the CTO, sysadmin and lead developer in one person), or by automated scripts running as root (which is how it's done at my university, there's an autoupdate script running at bootup). Users have no business updating company-managed computers. This is YOUR opinion. Evidently, the direction GNOME is taking conflicts with your opinion. But, maybe it would help to think about people having opinions other than your own? FWIW, at work here we used to do sysadmin-dictated updates and installation but for several reasons that is simply not feasible anymore: - people work remotely more than ever including spotty network performance at the right update time - laptops and their usage (ok audience of 200 students let's wait until my forced-update is done before I give my lecture) - expectations -- people simply installed their own OS once they found out that they could not install their own necessary software, wasting both their and our time Again, not saying that this is typical, or something that YOU should adopt at your work. But the offline updates as will be implemented in F20 will simply make things better for US. And that is ALSO a VALID opinion. Regards, --Stijn -- 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: Software Management call for RFEs
Hi, I would like better integration with domain-specific package managers. By which I mean npm (for node.js), gem (for ruby), pip (for python), cpan (for perl), pecl/pear (for PHP), CRAN (for R), CTAN (for TeX), and many more I'm sure. By integrating RPM with these package managers, I feel it would be possible to provide a consistent view of the system, as well as a consistent management interface for sysadmins as opposed to application developers. The latter I might expect to continue to use the domain specific package managers, simply because they add value to domain experts -- but for the common usecase install this app on the server it would be nice to use RPM only. Another advantage that I see is that it saves Fedora packager manpower -- if the translation is good enough, it should be possible to work with upstream packages and simply automate the fedora rpm process as much as possible. Current examples are R2spec and the TeXLive package scripts. And maybe, in the future, it might even be possible for new domains to rely on RPM itself instead of writing Yet-Another-Package-Manager etc. But again, that is not the goal itself. To succesfully integrate RPM implies (to me) at least the following, some of which are already on the feature page: - convert the basic package metadata from $domain to RPM (it is OK to go back to $domain package manager for exotic use cases, but list/update/remove packages should be doable from RPM) - reproducible environment (Gemfile / pip requirements.txt / ...) - both system- and per-user installation tracked and supported - more I can't think of right now? Regards, --Stijn -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Software Management call for RFEs
On Thu, 23 May 2013 14:02:34 +0200 Jan Zelený jzel...@redhat.com wrote: On 23. 5. 2013 at 10:53:10, Stijn Hoop wrote: I would like better integration with domain-specific package managers. By which I mean npm (for node.js), gem (for ruby), pip (for python), cpan (for perl), pecl/pear (for PHP), CRAN (for R), CTAN (for TeX), and many more I'm sure. The problem is that some of these languages have fundamentally different philosophy than Fedora and unfortunatelly it's not a mix-and-match situation. That being said, there already are different tools to create spec files from those upstream representations (gem2spec, cpan2spec, ...) Yes, it is true that there sometimes is a different philosophy, but fundamentally is in the eye of the beholder. If there are domain2spec tools available NOW, why would it not be possible technically? And if the non-technical philosophical differences are too big, maybe it is also a sign that Fedora needs to change the requirements? After all, an OS that does not help developers with development might not be a good environment to keep. By integrating RPM with these package managers, I feel it would be possible to provide a consistent view of the system, as well as a consistent management interface for sysadmins as opposed to application developers. The latter I might expect to continue to use the domain specific package managers, simply because they add value to domain experts -- but for the common usecase install this app on the server it would be nice to use RPM only. Another advantage that I see is that it saves Fedora packager manpower -- if the translation is good enough, it should be possible to work with upstream packages and simply automate the fedora rpm process as much as possible. Current examples are R2spec and the TeXLive package scripts. You can't really do this because of all the Fedora packaging policies. It might be feasible in some private repositories though. I disagree. Why are the domain2spec and TeXLive approaches in the repository then? I know that some domain2spec tools do need hand-editing, but that is a problem that can be worked on. Either by integrating more knowledge in the tools, or working with upstream on providing more metadata for the package. I do acknowledge that all of this will not be EASY. But then, I did not see that in your list of requirements. If it is really impossible, can you give an practical example why? (Sidenote: I really do appreciate the call for features and the considered feature page. Thank you for that!) Regards, --Stijn -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Expanding the list of Hardened Packages
On Tue, 23 Apr 2013 22:35:41 +0200 Kevin Kofler kevin.kof...@chello.at wrote: It isn't working because it's adding hundreds of new policy bugs in every new Fedora release. citation needed Seriously, can you please stop extrapolating from your personal usecase, and think of both the developers and actual users of the technology that /you/ do not need? Thank you. Note that I am not implying that you are ignoring useful technology so statements about the effectiveness of SELinux are besides the point; which is that useful is in the eye of the beholder, and I am not one to tell you what is useful for you. I am asking you to return that favor. --Stijn -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Proposed F19 Feature: Cinnamon as Default Desktop
On Fri, 08 Feb 2013 07:47:48 +0100 Ralf Corsepius rc040...@freenet.de wrote: On 02/06/2013 08:42 AM, Stijn Hoop wrote: On Tue, 05 Feb 2013 21:46:32 +0100 Ralf Corsepius rc040...@freenet.de wrote: The actual problem is the current Gnome 3 being an entirely different product than Gnome 2, which usability-wise has *nothing* in common with Gnome2 and addresses a completely different target audience. Ralf, could you please stop this generalization. You have been conveniently ignoring posts to the contrary, including mine. Sorry, I don't see what I am generalizing. Gnome3 and Gnome2's GUI working principles are entirely different and therefore are catering the demands of different target audiences. They are similarly different as WinXP and Android are different in their GUIs' working principles. I can not help you if do not understand what I am talking about. Ralf I am providing a datapoint that directly contradicts your original statement, namely that there is a completely different target audience for GNOME 2 vs GNOME 3. I am that datapoint. I know that it is my anecdata, but I am pretty sure that I have not yet read any actual facts supporting your side of the argument as well. Furthermore I am pretty sure that I am not the only one enjoying GNOME 3, while having enjoyed GNOME 2, having read the other posts in this thread. Hopefully that is clearer, regards, --Stijn -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Proposed F19 Feature: Cinnamon as Default Desktop
On Fri, 8 Feb 2013 20:35:56 +0100 Nicolas Mailhot nicolas.mail...@laposte.net wrote: Le Ven 8 février 2013 13:22, Olav Vitters a écrit : On Fri, Feb 08, 2013 at 10:34:58AM +0100, Stijn Hoop wrote: I am providing a datapoint that directly contradicts your original statement, namely that there is a completely different target audience for GNOME 2 vs GNOME 3. I am that datapoint. As are various others during FOSDEM (Vincent Untz asked people to raise their hands). No idea how representative that it. The FOSDEM poll was stacked — no one really wanted to hurt Vincent Untz too much given his obvious efforts to be nice, there was this knot of GNOME people bunched together that were a tad intimidating, and people do not go to FOSDEM to fight. What is telling however is the complete refusal of the audience to put systemd and Gnome 3 in the same bucket. Lennart's efforts to explain his project, understand sysadmin needs, provide a smooth transition and keep current usages working clearly paid off there. So don't overplay the GNOME 3 FOSDEM session, it was an awkward moment for everyone involved (and certainly not representative of the positive energy that permeated other presentations). To be honest, I don't think any poll will ever suffice for this topic. Nor do I think a poll is what's needed. It should simply be easier to switch to a desktop that Works For You, especially after installation, and even before if possible. That way we can keep the anti-GNOME-3 people happy as well. In the end I guess we can't get rid of the fanatical GNOME 3 is for tablets only meme (and others like it that I personally don't agree with), but hey, I don't mind as long as I can ignore those. But I will keep objecting to the single-sided argument that there is no GNOME 2 user that likes GNOME 3. I fully support those who have tried and rejected the new stuff -- as long as they don't impose their opinion on me :-) --Stijn -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Proposed F19 Feature: Cinnamon as Default Desktop
Hi, On Tue, 05 Feb 2013 19:01:49 +0800 Mathieu Bridon boche...@fedoraproject.org wrote: On Tue, 2013-02-05 at 11:12 +0100, Ralf Corsepius wrote: Sigh, let me try again: The Fedora project is pushing away Fedora users from Fedora, because Fedora/RH have missed that it's new DE (Gnome3) is addressing a different audience than Gnome2 did. The Gnome3 audience is not the classical Fedora user base (Linux devs), it's the Android/iOS adicted wipe/tile kidz. I.e. if Fedora wants to keep their old user-base you need to offer them alternatives, and not to be stubborn on Gnome 3 for whatever reasons. This is a gross generalization. I was a GNOME 2 user, and am still a GNOME 3 user. I loved GNOME 2 for their focus on simplicity and not getting in my way, and I love GNOME 3 even more as they went even further in that direction. My $dayjob is to make a RHEL/Fedora derivative distro, does that fall in what you characterize the classical Fedora user base (Linux devs)? I have never owned any Android/iOS device, am I a 'Android/iOS adicted wipe/tile kidz'? Can you please stop pigeonholing people this way? Normally I try not to do this, but: what he said. I would like to add a voice to the people having successfully switched from GNOME 2 to GNOME 3. In fact, I started out with FVWM and have run IRIX and SunOS desktops as well, before I got onto GNOME 1. If that does not make me an old fart, I do not know what will. Compared to GNOME 2 I really like GNOME 3, even with the remaining warts that I still encounter (multiscreen support is not yet *there* for me mostly). And no, I do not even run many extensions, just the ALT-TAB one. I know lots of people are unhappy with being forced to run GNOME 3, but as has been pointed out in this thread that is a stretch if anything. Even before installation it is possible to choose a distro, after installation as well. Valid points in my eyes are that it should maybe be even easier to switch DE's, either before or after install, but there is nothing in there that makes it necessary to switch the *default*. --Stijn -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Proposed F19 Feature: New firstboot
On Tue, 29 Jan 2013 14:30:04 -0800 Adam Williamson awill...@redhat.com wrote: On Tue, 2013-01-29 at 20:20 +0100, Stijn Hoop wrote: On Tue, 29 Jan 2013 14:07:55 -0500 john.flor...@dart.biz wrote: From: Martin Sivak msi...@redhat.com the tool will be started using systemd unit file which can be disabled. It will have to be explicit (even minimal install needs users or root password), but we can figure something out. In my experience, root password is handled by the installer and firstboot is not needed to configure users if puppet is being used to configure them. (Also there are many Fedora systems out there having only root and the system accounts -- i.e., no real users.) Having to disable the firstbooot systemd unit file just to get to a root prompt so that puppet can be installed would be a PITA. The whole idea of puppet is to avoid having to such things because it can automate them. What he said -- forcing a root pw or creating users is going to be a PITA for us. Please add a way to disable it, preferably using kickstart. You're aware that this is already the case in F18 and all previous releases, right? You can't get out of anaconda without setting a root password. He said root password OR users, not root password AND users. Oops, sorry! Misunderstood that part. As you can tell, I need it mostly in kickstart, have not yet run tests without that ;-) --Stijn -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Proposed F19 Feature: Yum Groups as Objects
On Mon, 28 Jan 2013 17:31:33 -0500 James Antill ja...@fedoraproject.org wrote: On Mon, 2013-01-28 at 15:04 +, Daniel P. Berrange wrote: On Mon, Jan 28, 2013 at 12:58:56PM +, Jaroslav Reznik wrote: = Features/YumGroupsAsObjects = https://fedoraproject.org/wiki/Features/YumGroupsAsObjects I don't have an immediate better suggestion, but with my Fedora end user hat on Yum groups as objects is essentially meaningless as a feature title to me. It might as well have said Yum groups as aardvarks. I think it needs a title that reflects what it means to the user, rather than reflecting the internal implementation detail. I agree, and am open to suggestions on a better feature name. But I'd thought most users would be happy if the summary / description / release-notes were something they'd understand. BetterGroupsSupportForYum ? (note that I don't expect people to find these changes to be for the worse) --Stijn -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Proposed F19 Feature: Dracut HostOnly
On Tue, 29 Jan 2013 11:48:01 -0700 Chris Murphy li...@colorremedies.com wrote: On Jan 29, 2013, at 9:44 AM, Matthew Miller mat...@fedoraproject.org wrote: (I'm not sure if the new installer even has an option for password-protecting grub2, offhand.) It doesn't. And this seems to be an area of confusion on the two grub lists for users and distro developers alike, looking to implement it. So I'm not certain that it's strictly an installer limitation. Chris Murphy Not sure about the installer, but the one in kickstart is broken (and has been broken since GRUB2): https://bugzilla.redhat.com/show_bug.cgi?id=840160 It should be fixable though I've not yet found the time to dig into it. I only ran into this last week since I (apparently) skipped F17 / GRUB2. --Stijn -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Proposed F19 Feature: New firstboot
On Tue, 29 Jan 2013 14:07:55 -0500 john.flor...@dart.biz wrote: From: Martin Sivak msi...@redhat.com the tool will be started using systemd unit file which can be disabled. It will have to be explicit (even minimal install needs users or root password), but we can figure something out. In my experience, root password is handled by the installer and firstboot is not needed to configure users if puppet is being used to configure them. (Also there are many Fedora systems out there having only root and the system accounts -- i.e., no real users.) Having to disable the firstbooot systemd unit file just to get to a root prompt so that puppet can be installed would be a PITA. The whole idea of puppet is to avoid having to such things because it can automate them. What he said -- forcing a root pw or creating users is going to be a PITA for us. Please add a way to disable it, preferably using kickstart. --Stijn -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Ruby 2.0 in F19
Hi, On Wed, 02 Jan 2013 10:59:46 +0100 Vít Ondruch vondr...@redhat.com wrote: Dne 21.12.2012 20:58, M. Edward (Ed) Borasky napsal(a): Why don't we just ship 'rvm' or 'rbenv' and force everyone to manage their own Ruby environments? ;-) There used to be RVM in Fedora, but we dropped it, since it cannot be installed system wide while manage Ruby locally, as discussed here https://groups.google.com/forum/#!msg/rubyversionmanager/RuMA7Jl1EDk/8wv5tncWBJkJ Out of curiosity, the RVM page [1] and other google hits [2], [3] talk about mixed mode install that seems to be exactly what you want. I'm not much of a ruby / RVM user, but does it not work? --Stijn [1] https://rvm.io/rvm/install/ [2] https://blog.engineyard.com/2012/rvm-stable-and-more/ [3] http://serverfault.com/questions/424546/rvm-mixed-mode-local-gem-installation -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fixing Puppet in Fedora/EPEL
Hi, On Fri, 19 Oct 2012 16:29:57 -0700 Michael Stahnke stah...@puppetlabs.com wrote: On Fri, Oct 19, 2012 at 4:22 PM, Seth Vidalskvi...@fedoraproject.org wrote: I'm less worried about the people requesting the newness b/c they clearly want change. I'm worried about the people who run rhel b/c they fear change. I'm more worried about people with hybrid environments where RHEL is at the core for Puppet. (and somewhat how RHEL 7 could shake out) Do you consider it ok to not be able to have Fedora agents check into a RHEL master? FWIW, we have exactly this (Fedora clients, CentOS master). And yes, we need to use our local mirror of yum.puppetlabs.com right now. This is nothing more than anecdata, as we are fine with the setup now. Of course, having puppet3 in EPEL would make life a tiny bit easier. Regards, --Stijn -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [Test-Announce] Fedora 18 Alpha is hereby declared GOLD
On Mon, 17 Sep 2012 21:21:00 -0700 Adam Williamson awill...@redhat.com wrote: On Mon, 2012-09-17 at 22:03 -0400, Matthew Miller wrote: On Tue, Sep 18, 2012 at 12:51:00AM +0200, Björn Persson wrote: It's cute, but I think might read a bit bizarre in isolation. 'Ready for testing' is terminally boring, but seems safe... Aren't the terms alpha and beta? Fedora 18 has been declared alpha. Before that it was pre-alpha. After some more testing and fixing it will reach beta status. Right? But how do you say finalized alpha release and finalized beta release, given that these milestones go through a qa and release engineering process themselves? The Alpha release itself is done now. Alpha is Alpha. Alpha is done. All work is towards Beta. We *test* Alpha, but all that testing is towards making Beta and Final better. We test Beta, to make Final better. But Fedora 18 Alpha is a particular thing that is now done and will never change. Fedora 18 Beta will be a particular thing that will be done and will never change. The state of F18 a week after the Alpha unfreeze is no longer Fedora 18 Alpha. It's something else. Yeah but why not rename the _Release_ Candidates as well ? As in: F18 Pre-Alpha 1 (current TC1) F18 Pre-Alpha 2 (current TC2) ... F18 Pre-Alpha 5 (current RC2) F18 Alpha F18 Pre-Beta 1 (current TC1) ... F18 Beta F18 Pre-Release 1 ... F18 Release == Gold ? My EUR 0.02, I don't really care that much about the color of the bikeshed but this suggestion was the most interesting to me ;-) --Stijn -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: rawhide report: 20120728 changes
On Sat, 28 Jul 2012 12:36:26 + Fedora Rawhide Report rawh...@fedoraproject.org wrote: [...] --- * Fri Jul 27 2012 - Andreas Schneider a...@redhat.com - 2:4.0.0-132.beta4 - Don't define an Epoch in RHEL releases. May I ask why? This makes it harder to compare versions between Fedora and RHEL. I know it is not a 1:1 mapping anyway, but it is useful to see branching points etc. Differing Epoch will be confusing later down the road, I think. It's not like it's in the way? Regards, --Stijn -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
update installation timing (was Re: Schedule for Monday's FESCo Meeting (2012-06-18))
Hi,
On Wed, 20 Jun 2012 02:22:26 + (UTC)
Ben Boeckel maths...@gmail.com wrote:
On Mon, Jun 18, 2012 at 13:19:13 GMT, Michal Hlavinka wrote:
I wonder if it would be possible to do it on shutdown instead of
during start up? I usually do not care if shutdown takes ten
seconds or five minutes, but when I start my computer I do so
because I want to use it and not wait several minutes before its
ready.
Hmm. I usually have the other problem, especially with laptops.
Shutting down due to low battery only to have it wait to do updates
while there's a chance the updates won't matter because it's going to
crash soon is scarier than booting up and doing updates (presumably
you have juice available when booting). There's also the I need to
be somewhere case where shutting down fast is more important than
booting fast (airplane take off, losing track of time before class,
etc.).
Either way, it certainly isn't an obvious either-or issue. The obvious
solution, to me, is to have mind-reading computers, but I think that
may have one or two other consequences with it.
I agree that mind reading computers may not be the final answer, but I
do have a data point that might be helpful: we locally implemented
updates-at-reboot for a few years now. At first we had them on startup,
but now we do it at shutdown -- we made this change due to user
complaints as they did not mind the computer doing stuff when they went
away, but did mind longer wait times at the start of the {day,week,...}.
Note though that we only implemented this policy for desktop computers,
not for laptops. I agree that for a laptop, shutting down fast can be
necessary as well -- so maybe distinguishing on on AC power would be
a good substitute for mind reading as to when to run the actual updates?
--Stijn
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Re: update installation timing (was Re: Schedule for Monday's FESCo Meeting (2012-06-18))
On Wed, 20 Jun 2012 10:22:22 +0100 Richard Hughes hughsi...@gmail.com wrote: On 20 June 2012 08:08, Stijn Hoop st...@sandcat.nl wrote: I agree that mind reading computers may not be the final answer... Well, switching to system-update.service from a running desktop should probably kill off everything and start the offline update, so that would be possible with the new scheme too. Good to know, thanks -- although I wonder, in what capacity is this supported then? Would you / others be willing to deal with both update timings in this Feature? --Stijn -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Important kernel update should not break stuff
Hi, On Wed, 13 Jun 2012 14:15:14 +0200 Roman Kennke rken...@redhat.com wrote: Am Mittwoch, den 13.06.2012, 13:05 +0100 schrieb Johannes Lips: I think the reason for shipping the latest upstream kernel is based on the fact that backporting would be too much work. http://fedoraproject.org/wiki/KernelRebases Gives a good overview and probably prevents us from repeating arguments in the discussion. Ok, fair enough. The question remains, how can we avoid such bad things to happen in the future? Should I regularily try out kernel builds on their way to stable, and object to their stable-release when I find a problem? And how would I do that? (I.e. how can I find out when a new kernel is about to go to stable, and when to test it, etc) And what about the other base components of the system? (Although, to be fair, the kernel seems to be the most problematic one..) Check https://admin.fedoraproject.org/updates/kernel for updates. Provide negative karma for them in Bodhi as well: http://fedoraproject.org/wiki/QA/Updates_Testing Regards, --Stijn -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Stop the git abuse
On Mon, 21 May 2012 13:40:55 +0200 Ralf Corsepius rc040...@freenet.de wrote: On 05/21/2012 12:21 PM, Gerd Hoffmann wrote: On 05/21/12 10:23, Ralf Corsepius wrote: On 05/21/2012 09:56 AM, Jaroslav Reznik wrote: - Original Message - On Fri, May 18, 2012 at 07:07:56PM +0200, Remi Collet wrote: And definitvely, for me, (and probably only for me), git is really not a good tool for spec maintenance. Not duplicating the changelog would help. There's little reason to have a changelog in git which is then manually copied into %changelog. +1, for me - GIT is the authority for change logs, not SPEC... -1 changelogs are manually written documents and source files. A database's (git), temporary meta information is irrelvant. Temporary? git commit messages disappearing is news to me ... They may disappear by database operations, by database defects or by ocersights/mistakes when such databases will be converted to the next generation of VCS. While I agree about the target audience being different, and therefore having different changelogs is in some way justified, I disagree with this last assessment. The reasons you mention are just FUD -- this can happen to whatever data you specify and is not cause for different usage (other than backup strategy etc), and furthermore is not specific to RPM changelog data in any way. Regards, --Stijn -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
rawhide compose failing?
Hi, did I miss the last two days of rawhide compose mails or are they failing? If so where can I check? Regards, --Stijn -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: rawhide compose failing?
On Fri, 16 Mar 2012 08:11:24 -0600 Kevin Fenzi ke...@scrye.com wrote: On Fri, 16 Mar 2012 14:02:39 +0100 Stijn Hoop st...@sandcat.nl wrote: Hi, did I miss the last two days of rawhide compose mails or are they failing? If so where can I check? http://lists.fedoraproject.org/pipermail/devel/2012-February/162652.html It looks like they composed, but didn't send email for some reason. Will investigate. kevin Thanks. Actually I do see an error in critpath.log, http://kojipkgs.fedoraproject.org/mash/rawhide-20120316/logs/critpath.log Maybe that explains? Regards, --Stijn -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: /usrmove?
On Wed, 08 Feb 2012 06:37:33 +0100 Kevin Kofler kevin.kof...@chello.at wrote: Adam Williamson wrote: Note that this has not actually been implemented in anaconda yet, so if you do an anaconda upgrade at this time, it will explode horribly. The bug requesting this support be added to anaconda is http://bugzilla.redhat.com/show_bug.cgi?id=787893 . It's totally unacceptable that this feature has been merged in this incomplete state. Working upgrades should have been a prerequisite for merging it! Anaconda upgrades are even part of our release ^^^ criteria! This affects both the DVD upgrades and preupgrade, which are the 2 upgrade methods Fedora claims to support. I did not see a release yet, where did you find it? --Stijn -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Unity For Fedora (As in OpenSUSE or Arch)
On Wed, 01 Feb 2012 17:00:30 -0700 Adam Williamson awill...@redhat.com wrote: I realize this isn't a very constructive mail, and the point has been raised before, but I'm hoping at some point the sheer weight of complaints will cause someone more creative than myself to actually come up with a notification system for GNOME 3 which satisfies the GNOME design team and *also* does not suck. Is there a bug we can vote on? I also agree 100% with this, I rather like gnome-shell except for this 'notification system'. --Stijn -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora 17’s unified filesystem (/usr-move)
Hi, thanks for the detailed instructions for testing. I am not sure though, whether any of this is applicable on a system already running rawhide? Reading this, I surmise that I have to do the following steps once these packages hit rawhide. Can you comment on the correctness? Currently installed systems need some manual steps to convert the current system to match the layout of rawhide/Fedora 17. After that, the system can continue to be updated with YUM as usual. Download and install the most recent dracut package from rawhide: # yum --enablerepo=rawhide update dracut This will hit me soon automatically (as it is in rawhide proper, and I update regularly). Update the installed initramfs image for your current kernel, and instruct dracut to include the dracut module to convert your current filesystem: # dracut --force --add usrmove If dracut detects ‘rd.usrmove’ on the kernel command line at bootup, it starts the filesystem conversion of the root filesystem. Change the following kernel commandline parameter directly in the bootloader menu, which is shown during bootup, or edit the line in /etc/grub*.cfg. - remove “ro” - append “rw” to let dracut mount your root filesystem writeable - remove “rhgb” to hide the graphical bootsplash - append “rd.info” to get a more verbose output from dracut - append “rd.usrmove” to enable the /usr-move conversion script in dracut These two steps are needed as well, however... - append “selinux=0” for now, because the relabeling in a converted F16 system does not seem to work properly at this moment ... do you know if this is applicable for a correctly labeled rawhide as well? Any files with conflicting names, which the conversion could not resolve, will be backed up to files named *.usrmove~ residing in /usr/lib, /usr/lib64, /usr/bin and /usr/sbin. Sidenote: should we file these as bugs? After a successful conversion, revert the changes made to the kernel command line in the bootloader config file /etc/grub*.cfg. This step is needed. SELinux relabelling should take effect after you rebooted your updated system and can take a long time (at least in a VM it takes insanely long and is still not finished). We are currently investigating, what seem to take so long, so you might consider to test with SELinux disabled for now. Again, is this only for hosts based on F16? Until the rawhide repository gets all the converted rpms, use the f17-usrmove repository to update the system after the filesystem conversion and disable rawhide in the file /etc/yum.repos.d/fedora-rawhide.repo When the tag hits rawhide proper, I assume this can be skipped? Can I update dracut now, and wait for the rest of the tag to hit rawhide before adding the rd.usrmove flag? Regards, --Stijn -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Requesting a change to the BugStatusWorkFlow: Closed/UPSTREAM
On Fri, 20 Jan 2012 07:20:20 -0500 Stephen Gallagher sgall...@redhat.com wrote: Well, the proposal I'm making is the one that I've been following personally in my own projects, which I feel is providing better service to my users. Speaking as a (mostly) user: I agree with this statement. I would rather have the bugs kept in the open state until a package with the fix is released, so that I can see when they are fixed in Fedora. Since I am not a package maintainer, I cannot estimate the impact of such a policy on the workload of those busy people. I can live with the current status quo. Just my EUR 0.02, --Stijn -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: mysql is now a critpath package? WTF?
On Thu, 05 Jan 2012 14:38:57 -0600 Rex Dieter rdie...@math.unl.edu wrote: Stijn Hoop wrote: Well it also took them two years to consider 'NFS mounted home' a valid use case, during which the whole 'you really need MySQL!!!' was broken for our site. It's easy to switch (maybe I should blog about it... ) per user: kcmshell4 akonadi per machine/site: create/edit /etc/xdg/akonadi/akonadiserverrc to contain: [%General] Driver=QSQLITE3 -- rex Thank you, that is good to know. In the end we worked around it by moving the MySQL socket to a local directory. This was not perfect because accidentally starting KMail on a second machine, while logged in on the first, caused havoc in fun ways, but it did get rid of the occasional I've lost my mail NFS+MySQL fun. --Stijn -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: mysql is now a critpath package? WTF?
On Thu, 05 Jan 2012 20:20:55 +0100 Kevin Kofler kevin.kof...@chello.at wrote: Rex Dieter wrote: I'm of a mind to revisit this (again). NO, not again!!! Can we please stop this nonsense? Upstream defaults to MySQL for a reason, and strongly recommends NOT using the SQLite backend by default. SQLite doesn't support concurrency (i.e. any Akonadi operation blocks all others) and is slower. I think overriding the upstream default is a very bad idea in this case, and I'm surprised you are pushing for it that much, you're otherwise always the upstream, upstream, upstream guy. Kevin Kofler Well it also took them two years to consider 'NFS mounted home' a valid use case, during which the whole 'you really need MySQL!!!' was broken for our site. I'm not exactly sure that blindly following upstream recommendations on a topic that has been contested before, with good reason, is a good idea either. --Stijn -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Changing kernel API / Breaking VirtualBox - update criteria violation?
On Thu, 08 Dec 2011 11:07:10 +0100 Reindl Harald h.rei...@thelounge.net wrote: but they are often way behind current versions (ffmpeg, x264, open-vm-tools) and then throw out a new x264, rebuild all packages depending on it and rais only from .114 to .115 is a bad joke while .119 exists since months and yes i had the .119 since months running, even with VLC from rpmfusion Maybe you could have submitted your months old changes upstream? --Stijn -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Changing kernel API / Breaking VirtualBox - update criteria violation?
On Thu, 08 Dec 2011 19:02:26 +0100 Reindl Harald h.rei...@thelounge.net wrote: Am 08.12.2011 17:04, schrieb Kevin Kofler: Reindl Harald wrote: my only changes was compile the x264.119 and fake the so-number in the sources to .102 for F13/F14 and to .114/.115 for F15 and currently the .120 to 115 Changing soversions is a very bad idea, upstream probably bumped them for a reason. i know and that is why this are private builds doe snot change the fact that rpmfusion did a so-bump on x264 with all the needed rebuilds and bumped only from 114 to 115 instead 119 while all this apps are working even with 120 perfectly they stayed for nearly 2 years at x264.so.102 what makes compile of newer ffmpeg impossible and so i see not that big glory in the rpmfusion packages since they also never do the fedora-massrebuilds after GLIBC/GCC changes at their side be happy with it - for me the packages are only a nice to start with-SPEC I think you'll find out that either - bumping to .120 makes some other programs not work anymore - they don't have enough manpower to do the proper rebuilds Both of which are solvable problems given more manpower and/or expertise, which you seem to have but chose to invest only privately. Which is fine by me, but then please do not complain about the people who DO share their time, on this list. Regards, --Stijn -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Proposing Fedora Feature for private /tmp and /var/tmp for all systemd services in Fedora 17.
On Tue, 8 Nov 2011 12:55:31 +0100 Lennart Poettering mzerq...@0pointer.de wrote: On Mon, 07.11.11 21:53, Gregory Maxwell (gmaxw...@gmail.com) wrote: On Mon, Nov 7, 2011 at 8:48 PM, Lennart Poettering mzerq...@0pointer.de wrote: If run on the main namespace all they see is that the files are in some randomized subdir of /tmp, instead of /tmp itself. Is the randomization required? If they were named after the user/service that created them (perhaps with some randomization too e.g. /tmp/mount.fooservice.$random would be much more discoverable and maintainable then /tmp/$random. Systemctl show is good and needed for automation, but my brain stores more sysadmin trivial than I like already. Well, that way attackers might still be able fool the admin: i.e. he could create a directory with a service name and some randomized suffix and the admin might blindly believe that this directory belongs to the service, even if it doesn't, but belongs to the evil attacker. Using a fully randomized name is a bit more secure here, since the admin always needs to check the service first for the actual directory. But isn't the point of having namespaced /tmp that no network-facing service is even able to create a directory in the main namespace? In other words, if the attacker is able to create a directory in the main namespace, you've already lost? --Stijn -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
glibc updates (Re: F16: user's secondary groups ignored)
On Fri, 14 Oct 2011 00:36:13 -0700 Adam Williamson awill...@redhat.com wrote: Just Glibc Update Comedy Hour again. https://bugzilla.redhat.com/show_bug.cgi?id=745675 downgrade to glibc -10 fixes it. So, just to ask a rhetorical question, how does this tie in to running rawhide is bad mmkay again? --Stijn -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Intent to package GNOME Shell frippery
Hi, On Fri, 29 Jul 2011 10:57:59 +0200 drago01 drag...@gmail.com wrote: ... Distro packaged extensions are frowned upon upstream. [citation needed] --Stijn -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Intent to package GNOME Shell frippery
On Fri, 29 Jul 2011 11:36:50 +0200 Tomasz Torcz to...@pipebreaker.pl wrote: I would strongly prefer third parties not to reinvent whole packaging and repositories concept. Some companies grasp it (I have yum repos provided for Google Earth and Talk Plugin, Dell BIOSes and firmwares, Adobe Flash and Air, Virtualbox...). This, exactly. Actually, if addons.m.o and extensions.g.o provided yum.repo file, my point would be moot. That would be very nice indeed, and might even be possible to create given that the code for AMO is open (https://github.com/jbalogh/zamboni) Hopefully extensions.gnome.org will at least re-use some of that code instead of doing it yet another way again... --Stijn -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: XDG and default directories (Re: Adding ~/.local/bin to default PATH)
Hi, On Wed, 27 Jul 2011 12:43:09 +0200 Nicolas Mailhot nicolas.mail...@laposte.net wrote: Le mercredi 27 juillet 2011 à 12:26 +0200, Stijn Hoop a écrit : and even better is the fact that I can now put that area somewhere else than on our default stupidly-expensive backupped NFS filesystem. And what will happen to your users when selinux starts enforcing download jails and the directory it applies settings to is not the one you use? Do you really thinks that's hypothetical? Browsers are looking hard at sandboxing nowadays. Note that other security frameworks do not even have the path/label separation they work directly on paths. Why would selinux / apparmor NOT respect the same environment that is used for the live user? If the root cause is because selinux / apparmor is technically not able to use per-user environment variables for non-standard subdirectories of /home, I submit that I simply need to be capable to not only set the environment variable, but also modify our selinux configuration to match. I already accepted the premise that having an NFS mounted /home (where I preferably do not want to store the newest HQ movies) is not a standard Linux environment anymore, by having to set the variable in the first place. Really if there was a need (for nfs users for example) for the download area to reside on a different root it should have been defined on a different root from the start up (like the rest of the filesystem layout was done) instead of trying to variabilize the layout. I agree, that would also work in this specific case. However I note that the defaults make sense in a personal workstation case, which is fine by me. Having /home and /localhome (examples) for a single workstation is more confusing. Now the default locations are just going to be hardcoded right and left with subtle difficult to debug failures when one tries to move one of them like proposed by the spec. Exactly my point as well, let's get those fixed. --Stijn -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
XDG and default directories (Re: Adding ~/.local/bin to default PATH)
Hi, aside from the merits of adding ~/.local/bin, I just wanted to point out: On Wed, 27 Jul 2011 12:19:51 +0200 Nicolas Mailhot nicolas.mail...@laposte.net wrote: It's all been done to make nautilus happy with user-friendly localized names on the user desktop (aping the windows mess). And now gnome3 people have decided shortcuts on the desktop are a bad idea so the whole justification for those choices does not exist anymore. I disagree with this personal assessment; I and some of our users instead like the fact that there is now a standard area where to put downloads, and even better is the fact that I can now put that area somewhere else than on our default stupidly-expensive backupped NFS filesystem. There are a lot better reasons for them than aping windows mess. Now if only more programs understood those reasons as well... --Stijn -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: systemd vice SysV/LSB init systems - what next ?
On Tue, 19 Jul 2011 21:06:03 +0200 Nicolas Mailhot nicolas.mail...@laposte.net wrote: Le mardi 19 juillet 2011 à 18:30 +, Jóhann B. Guðmundsson a écrit : Hum best is to provide you with example which daemon do you maintain I can convert it for you and provide it to you as an example anyway here's an example of a systemd unit that I converted sometime ago for a know application named tomcat6 and I'll leave readers to be the judge of that what is harder to understand the native systemd unit or the legacy sysv init script... First the converted unit file Now the legacy sysv init script that everybody seem to love and cheerish so much... I don't think anyone loves this particular sysv script but you realize I hope that 99% of its complexity is here to make multi-instanciation trivial (because when every user can run an IDE like eclipse that wants its own tomcat instance to play with you *do* need multi-instanciation) and your unit file does not support this use case at all? I think the question is: why should this particular usecase be covered by the SYSTEM init script? In other words, why should the package tomcat6 not provide a better /usr/bin/tomcat6 binary (or shell script, or whatever) that can work out on its own whether to multi-instantiate? --Stijn -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
