Moving lspci and setpci from /sbin to /usr/sbin?
Hi all,
in Fedora we have pciutils binaries (lspci and setpci) in /sbin, both of them
use pciutils-libs (/usr/lib/...) and afaik this is how it works for "ages".
I'd like to move them from /sbin to /usr/sbin to have them with the same prefix
as library has. Do you think it can break anything?
A few facts:
1)library is already in /usr/lib and lspci/setpci won't work without it
2)pci.ids (lives in hwdata package) is in /usr/share/hwdata
3)yum remove pciutils will remove only system-config-{firewall,network} as
dependencies
Do you think moving this is a bad idea? I think it should not break anything,
only problem can be with separate /usr partition but because of library in
/usr it would be already broken and I've not seen any complain about it ever.
If there are no complains, I'll move it next week (in rawhide only).
Cheers,
Michal Hlavinka
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Moving lspci and setpci from /sbin to /usr/sbin?
On Wednesday 27 January 2010 14:51:15 Maxim Burgerhout wrote:
> Hi Michal,
>
> A few thoughts on this:
>
> - on RHEL boxes, the dependency on libpci does not exist and lspci is
> in /sbin. Therefore, on RHEL boxes, lspci will still work with a
> broken /usr partition. I haven't heard of anyone absolutely needing
> lspci on a system with a broken /usr partition, but it *is* possible
> to use it. Moving it also breaks a pretty long tradition, but that
> should matter too much. I actually prefer lspci to be in my path as a
> normal user.
well, on RHEL5 there is no pciutils-libs, so it does not depend on any library
in /usr/lib, but it depends at least on /usr/share/hwdata/pci.ids and without
it lspci is not that useful
>
> - it would be consistent if lsusb would make the same move to
> /usr/sbin, if lspci goes that way.
on the other hand lsusb requires library from /usr/lib (on RHEL5) so it is in
/sbin but won't work without mounted /usr (and there are also usb.ids)
>
> - I noticed Debian puts lspci in /usr/bin. I'm curious about the
> reason lspci is to remain in a sbin directory if it's being moved
> anyway.
good question
> I haven't been involved in Fedora for that long, but I'd like to
> participate in this discussion a bit, if that's ok :-)
>
> Regards,
>
> Maxim Burgerhout
> ma...@wzzrd.com
> ----
> GPG Fingerprint
> EB11 5E56 E648 9D99 E8EF 05FB C513 6FD4 1302 B48A
>
> On Wed, Jan 27, 2010 at 14:17, Michal Hlavinka wrote:
> > Hi all,
> >
> > in Fedora we have pciutils binaries (lspci and setpci) in /sbin, both of
> > them use pciutils-libs (/usr/lib/...) and afaik this is how it works for
> > "ages". I'd like to move them from /sbin to /usr/sbin to have them with
> > the same prefix as library has. Do you think it can break anything?
> >
> > A few facts:
> > 1)library is already in /usr/lib and lspci/setpci won't work without it
> > 2)pci.ids (lives in hwdata package) is in /usr/share/hwdata
> > 3)yum remove pciutils will remove only system-config-{firewall,network}
> > as dependencies
> >
> > Do you think moving this is a bad idea? I think it should not break
> > anything, only problem can be with separate /usr partition but because
> > of library in /usr it would be already broken and I've not seen any
> > complain about it ever.
> >
> > If there are no complains, I'll move it next week (in rawhide only).
> >
> > Cheers,
> > Michal Hlavinka
> >
> > --
> > devel mailing list
> > devel@lists.fedoraproject.org
> > https://admin.fedoraproject.org/mailman/listinfo/devel
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Moving lspci and setpci from /sbin to /usr/sbin?
On Friday 29 January 2010 06:35:21 Ralf Corsepius wrote: > On 01/28/2010 04:06 PM, Chris Adams wrote: > > Once upon a time, Ralf Corsepius said: > >> On 01/27/2010 02:17 PM, Michal Hlavinka wrote: > >>> Do you think moving this is a bad idea? > >> > >> Yes. > >> > >> The pciutils are valuable tools when trying to recover from situations > >> when "things go utterly wrong". > > > > So what difference does it make where they are (e.g. why do you say this > > is a bad idea)? > > Consider having /usr on a separate partition and /usr failing to mount > at bootup and times at system bootup, during which /usr is not yet > available, because it has not been mounted, yet. > > These scenarios are the key scenarios to separate those parts of a > distros which need to be considered "essential" (have to go into /lib, > /bin, /sbin) and which to be consider "non-essential". right, the point is lspci wont work without /usr, but can you give me any real world scenario where not having working pciutils on system with not mounted /usr can make any trouble that you won't be able to mount /usr without it? > > > They don't work without other stuff in /usr, so they > > should be in /usr. > > Rsp. this "other stuff currently in /usr" needs to move, too. > > >>> only problem can be with separate /usr partition but because of library > >>> in /usr it would be already broken and I've not seen any complain > >>> about it ever. > >> > >> Well, a separate /usr-partition has never worked on RH-based distros. > > > > I beg to differ; I've been using a separate /usr (mounted read-only > > except during maintenance) on RHL, RHEL, and Fedora for at least 13 > > years. > > Really? The situation definitely has improved over times, but I recall > times, when not even "rpm" was able to run without /usr. > > Consider taking out /usr from your fstab and to check how far you can get. > With /sbin/lspci you will be able to check your pci setup, with > /usr/sbin/lspci, you wouldn't. > > Should setpci be used somewhere in bootup scripts, you likely won't be > able to boot up your system at all. and because libpci is in /usr for a long time and there was not any complain so far, it probably is not used > > Ralf -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora Notifications System.
On Monday, August 23, 2010 08:19:13 Kevin Kofler wrote: > Kevin Fenzi wrote: > > I'm not sure a notification applet by itself is going to be the best > > answer here... as people may be busy or not see the notice and a few > > seconds later it goes away and they miss it. > > That's why the notification should not time out unless/until the user > clicks it away! disagree, have you seen your notifications after leaving your computer alone for several hours with IM client connected (with whatever status)? You'll get tons of "User XY has changed status to: blah blah" or even when you have opened 2+ chat windows (so there are some without focus), you'll get tons of 'User XY is typing' and 'User XY send new message: Blah blah' https://bugs.kde.org/show_bug.cgi?id=244589 https://bugs.kde.org/show_bug.cgi?id=244931 > > In KDE, the old-style notifications just stay on the screen until clicked > away, the new-style Plasma notifications (which are the default) retract > (after some timeout) to an (i) button in the systray, which will only move > to the hidden part of the systray if the notifications in it are clicked > away by the user. > does not work for all usecases, sometimes it's pain in the ass -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora Notifications System.
On Tuesday, August 24, 2010 21:11:56 Kevin Kofler wrote: > Michal Hlavinka wrote: > > disagree, have you seen your notifications after leaving your computer > > alone for several hours with IM client connected (with whatever status)? > > > > You'll get tons of "User XY has changed status to: blah blah" > > Well, IMHO Kopete shouldn't spam notifications for this type of non- > exceptional event at all. Is this enabled by default? If so, maybe we > should disable it by default in kde-settings? afaik it's enabled by default and not only for kopete. Kopete as many other apps uses kde notifications subsystem for a long time. You can check it in system settings->notifications. I don't think it should go to different kind of notifications or where/how do you think these notifications should be displayed? IMHO kde notifications miss at least timeout settings for notifications, because some notifications should be permanent (closed by user), some of them should "die" after some time and some of them should be obsoleted (done by application sending the notification) - for example kopete - there's deffinitely no need to have both "9:35:04 User Xyz is typing" and "9:35:08 User Xyz send new message:" notifications -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora Notifications System.
On Wednesday, August 25, 2010 11:13:29 Kevin Kofler wrote: > Michal Hlavinka wrote: > >> Well, IMHO Kopete shouldn't spam notifications for this type of non- > >> exceptional event at all. Is this enabled by default? If so, maybe we > >> should disable it by default in kde-settings? > > > > afaik it's enabled by default and not only for kopete. Kopete as many > > other apps uses kde notifications subsystem for a long time. > > The problem is not that notifications are enabled by default (of course > they are), but what kind of notifications are enabled. The ones Kopete > issues don't make sense. > > > You can check it in system settings->notifications. > > > > I don't think it should go to different kind of notifications or > > where/how do you think these notifications should be displayed? > > Not at all. A change in online status of a contact should be reflected in > your contact list, but is otherwise irrelevant. it's not irrelevant if you are trying to catch online someone who is online only time to time > > for example kopete - there's deffinitely no need to have both "9:35:04 > > User Xyz is typing" and "9:35:08 User Xyz send new message:" > > notifications > > That "User Xyz is typing" notification is also unhelpful and redundant and > should just be disabled by default. also has use case for me, so even this is disabled by default, I'll turn it on again > I'll bring this up in the KDE SIG meetings, I think we should really > disable that stuff by default in kde-settings. disabling something won't fix it, also I don't think this is that bad that it requires extra patch to turn it off by default and diverge from upstream -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: fedora mission (was Re: systemd and changes)
On Thursday 26 of August 2010 21:21:53 Garrett Holmstrom wrote: > Kevin Kofler wrote: > > We probably need to attack this trend more aggressively, like putting > > expiration dates into the installer after which it'll just refuse to > > install, stuffing fedora-release-n+1 into the Fedora n updates repository > > at Fedora n's EOL date etc. > > Not only is this disingenuous, but it also contradicts Fedora's > "Freedom" policy. Adding a big fat warning message to the installer, > however, is much less of a problem and gets the message across just as > effectively. Just make sure that the "expiration date" is far enough > out in the future that we can be certain that it will occur after the > release's EOL date since we don't know when that will be at the time of > image creation. I don't think it should be far enough. It should be some time before EOL happens. What's the point installing and configuring new system that will EOL tomorrow / after one week? But still... +1 to warning message in the installer -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: fedora mission (was Re: systemd and changes)
On Friday 27 of August 2010 07:03:06 Garrett Holmstrom wrote: > On 8/26/2010 11:53 PM, Michal Hlavinka wrote: > > On Thursday 26 of August 2010 21:21:53 Garrett Holmstrom wrote: > >> Kevin Kofler wrote: > >>> We probably need to attack this trend more aggressively, like putting > >>> expiration dates into the installer after which it'll just refuse to > >>> install, stuffing fedora-release-n+1 into the Fedora n updates > >>> repository at Fedora n's EOL date etc. > >> > >> Not only is this disingenuous, but it also contradicts Fedora's > >> "Freedom" policy. Adding a big fat warning message to the installer, > >> however, is much less of a problem and gets the message across just as > >> effectively. Just make sure that the "expiration date" is far enough > >> out in the future that we can be certain that it will occur after the > >> release's EOL date since we don't know when that will be at the time of > >> image creation. > > > > I don't think it should be far enough. It should be some time before EOL > > happens. What's the point installing and configuring new system that will > > EOL tomorrow / after one week? But still... +1 to warning message in the > > installer > > At the time the install images are composed the release's EOL date has > not yet been decided, so we would be stuck with guessing a date and > hoping it will be somewhat close. > > Fedora releases are either "Supported" or "Unsupported." Unless the > community wants to define some third, "Sort-of-supported" state then > there should be no functional changes in the installer's and > repositories' behaviors until after the release goes "Unsupported." Yes, but the message does not have to be "Warning: Fedora N is no longer supported", it can be something like "Warning: Fedora relase is usualy supported 13 months, you are probably going to install unsupported version or version that is going to be unsupported after a few days. You can check this on fedoraproject.org Check get.fedoraproject.org for more recent version." I think the wording is not the main problem -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: fedora mission (was Re: systemd and changes)
... > So in other words, dependency 1.6 to 1.6.1 is okay as it is likely a > bug fix, but 1.6 to 1.8 is not okay because it is a new release. there's no reason why 1.8 won't be ok after 2-3 weeks in updates-testing > >So, web developers want latest httpd/PHP/Rails/MySQL; GNOME developers > >want latest gtk/libgnome*; and so on. > > I wouldn't be so sure about that. > > If I was developing a web application I would want my version of > httpd/PHP/Rails/MySQL to remain stable - the last thing I want is a > bug to appear in the application I am writing and have to wonder if it > is a problem with my code or did the update in my framework change > something on me. If you develop some app you want to catch bugs in your app as fast as possible because you don't want release something that is broken just because there is newer library out there. Also my own experience: I wanted webmail client with some set of features the only client (except too big hordce imp) was latest roundcube. I had to package it myselfs because it was not even in latest fedora and then update all dendencies because it was not working with ancient php centos5 provides. I know Fedora is much "faster" than CentOS, but still... there's no reason why we should not update packages to newer *stable* release > >Similarly, everyone who cares about the tools they use daily (which > >developers tend to), wants the best versions of these tools, as soon as > >it is practical. So, newest version of emacs/vim/kdevelop/... > > Again, as a developer I would disagree. Again, as a developer I would agree with Miloslav > >The result is a distribution on which it is reasonably easy to develop > >current software, and a distribution on which one might not update > >critical system updates on the night before giving a presentation on a > >conference (FWIW, I can't recall a really bad updates experience). That > >doesn't seem to be a bad tradeoff - for a developer. > > So lets see, you are going to give a presentation or attend a > conference, where you will likely be using an unsecured network with > many threats that likely don't exist in your home or office > environment, and you are saying that because we have a distrubition > where anything can change and possibly break things you think it is > okay that you have to forgo critical system updates that might prevent > your system from being hacked? How can that be viewed as an > acceptable tradeoff? That package won't be ancient old, so the risk is small to almost zero. You'd understand the tradeoff better after first not working presentation you've tried to do. I won't update nothing day or two before presentation even from current fedora/centos/... -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: fedora mission (was Re: systemd and changes)
On Tuesday, August 31, 2010 16:14:39 Matthew Miller wrote: > On Tue, Aug 31, 2010 at 03:57:47PM +0200, Michal Hlavinka wrote: > > > So in other words, dependency 1.6 to 1.6.1 is okay as it is likely a > > > bug fix, but 1.6 to 1.8 is not okay because it is a new release. > > > > there's no reason why 1.8 won't be ok after 2-3 weeks in updates-testing > > I hope you are kidding. nope, I'm 100 % serious > Of course, these imaginary numbers aren't very helpful -- some programs > make only minor changes between whole-version-number releases, whereas > others revolutionize the whole project beteen 0.88 and 0.89. > > The policy can't be based on version numbers -- it has to be on potential > risk. Note: I agree there should be no updates breaking something - for example when configuration files from old version does not work with new version. That's out of the question. Fedora is not the only distro using (and testing) some program/library. Also there is very low potential risk to have some problem in F n-1 if the package works fine in F n. I really don't see any problem with: new version in rawhide and Fn updates-testing (after two weeks) updates for Fn, updates-testing for F n-1 (after two weeks) updates for F n-1, updates-testing for F n-2 Fedora = “Freedom, Friends, Features, *First*” -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: fedora mission (was Re: systemd and changes)
On Tuesday, August 31, 2010 17:36:39 Matthew Miller wrote: > On Tue, Aug 31, 2010 at 05:31:43PM +0200, Michal Hlavinka wrote: > > > > > So in other words, dependency 1.6 to 1.6.1 is okay as it is likely > > > > > a bug fix, but 1.6 to 1.8 is not okay because it is a new release. > > > > > > > > there's no reason why 1.8 won't be ok after 2-3 weeks in > > > > updates-testing > > > > > > I hope you are kidding. > > > > nope, I'm 100 % serious > > Unfortunately, then: this does not currently match reality. that's not any usefull information for discussion. If you can only offend instead of bringing some new information/arguments, please do not spam this thread, there is a lot of posts already. thanks -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: fedora mission (was Re: systemd and changes)
On Tuesday, August 31, 2010 17:39:11 Jesse Keating wrote: > On 8/31/10 6:57 AM, Michal Hlavinka wrote: > > there's no reason why 1.8 won't be ok after 2-3 weeks in updates-testing > > An update that changes behavior for the end user would never be > acceptable as an update to a stable release. Only severe exceptions > should be made to this rule, where the time/effort to backport the > important fixes from a new upstream release are cost prohibitive and too > complicated to do on our own. I don't thing there is so much updates that change behaviour, see firefox, thunderbird, kopete, usually there are only new features with old functionality intact. What I wrote was not a rule, there is always a lot of space for maintainer's decission. > rawhide is not to F-n as debian unstable is to debian testing. > > F-n is not to F-(n-1) as debian testing is to debian stable. no, but I think rawhide is to F-n as debian unstable is to debian stable. What I wrote as an example was expecting all versions in F-x are stable not that one version is more stable than another one. That delay was only for being "really sure" package is stable, because there are not too much users testing updates-testing packages if it's not new firefox/kernel/... but after a two weaks in F-n any package is tested quite well -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Selinux: SSH broken after F-13 --> F-14 upgrade
Hi all,
I've recently upgraded my system, but after that I was not able to connect
through ssh. More things are wrong (from my POV):
1)SELinux blocks all nondefault ports for ssh
I have ssh confugured to use different port than 22 for security reasons and I
think there is a lot of people doing that.
Question: Is it worth blocking all ports for ssh?
2)SELinux did not show any sealert warning about this. Running sealert -b shows
no problem. There is one message in /var/log/messages:
kernel: [90346.301108] type=1400 audit(1286901219.350:29): avc: denied {
name_bind } for pid=6830 comm="sshd" src=6520
scontext=unconfined_u:system_r:sshd_t:s0-s0:c0.c1023
tcontext=system_u:object_r:port_t:s0 tclass=tcp_socket
Question: This should be reported afaik, so it's a bug, right?
3)After checking /var/log/boot.log there is "Starting ssh ... [ OK ]".
I get the same success info after "service sshd start", but immediate service
sshd status returns "openssh-daemon is stopped", but I'm not sure if this is
fixable because all that daemonize and other stuff.
Question: What does other network daemons (httpd,...) do? Do they start
successfully (from initscript's POV) when they can't use configured port?
I'm really glad I've found this out before updating my headless F-12 server.
2 of 3 questions are about SELinux, ccing Dan.
Michal
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Selinux: SSH broken after F-13 --> F-14 upgrade
- "Daniel J Walsh" wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> On 10/12/2010 01:49 PM, Michal Hlavinka wrote:
> > Hi all,
> >
> > I've recently upgraded my system, but after that I was not able to
> connect through ssh. More things are wrong (from my POV):
> > 1)SELinux blocks all nondefault ports for ssh
> >
> > I have ssh confugured to use different port than 22 for security
> reasons and I think there is a lot of people doing that.
> >
> You need to tell SELinux which port to use for sshd.
>
> semanage port -a -t sshd_port_t -p tcp 6520
>
> > Question: Is it worth blocking all ports for ssh?
> >
> > 2)SELinux did not show any sealert warning about this. Running
> sealert -b shows no problem. There is one message in
> /var/log/messages:
> > kernel: [90346.301108] type=1400 audit(1286901219.350:29): avc:
> denied { name_bind } for pid=6830 comm="sshd" src=6520
> scontext=unconfined_u:system_r:sshd_t:s0-s0:c0.c1023
> tcontext=system_u:object_r:port_t:s0 tclass=tcp_socket
> >
> > Question: This should be reported afaik, so it's a bug, right?
> >
> No. Hacker gets some control over ssh and is able to make it bind to
> port 80, now he can read apache content.
"this should be reported, so it's a bug?" was related to sealert should show
this denial in systray or at least in sealert -b window. Or this denial should
be really more silent compared to others reported by sealert?
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Re: rawhide report: 20101019 changes
On Tuesday, October 19, 2010 15:56:54 Matthew Garrett wrote: > On Tue, Oct 19, 2010 at 02:43:33PM +0100, Paul Howarth wrote: > > This despite the FHS says (right at the top of Chapter 3, the Root > > > > Filesystem): > >/usr, /opt, and /var are designed such that they may be located on > >other partitions or filesystems. > > > > Do we *really* want to head this way, ignoring bugs resulting from > > having /usr on a different partition such as > > http://bugzilla.redhat.com/#626007, which is what led to this? > > What's the benefit in having /usr or /opt as separate filesystems? another benefit (not yet mentioned) is for filesystem encryption. I have / and /home encrypted and /usr not encrypted (for better performance of my laptop) -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Systemd transition prevents updating older release branches??
On 07/25/2011 09:07 PM, Tom Lane wrote:
> In
> https://fedoraproject.org/wiki/Packaging:ScriptletSnippets#Systemd
> I read that conversion of a package using a SysV initscript to systemd
> units requires a trigger with a "< NEVR" condition, and that
>
> # Note: the NEVR in trigger scripts should all be the version in
> # which the package switched to systemd unit files and the comparision
> # should be less than. Using<= the last version with the sysV script won't
> # work for several reasons:
> # 1) disttag is different between Fedora releases
> # 2) An update in an old Fedora release may create a newer NEVR
> #Note that this means an update in an older Fedora release must be NEVR
> #lower than this. Freezing the version and release of the old package and
> #using a number after the disttag is one way to do this. Example:
> #httpd-1.0-1%{?dist} => httpd-1.0-1%{?dist}.1
>
> IOW, once I push a mysql update with native systemd support into
> rawhide, I'll be forbidden from ever rebasing mysql in F15 up to
> a newer upstream patch release. Considering that upstream issues
> bug-fix releases about once a month, this is hardly acceptable.
>
> I'll have the same problem with postgresql, too.
>
> What's seeming like a better option is to bump the package's Epoch
> for the systemd-native release.
I don't like epoch changes too much. So, I've used different approach.
In %post section I have script that checks for old init script presence.
Something like:
if [ -f %{_initddir}/
Re: Adding ~/.local/bin to default PATH
On 07/27/2011 04:05 PM, Miloslav Trmač wrote: > On Wed, Jul 27, 2011 at 4:01 PM, Lennart Poettering > wrote: >> I think the right approach here is to prep a patch for the spec and make >> the dir official given that a) it probably makes sense to have a >> standardized dir like this, > I can't really see who is the expected user of ~/.local/bin . From my > POV the whole point of ~/.local is to store data that is hidden from > users - it is "application" data, not "user data". > > Programs within the home directory were, presumably, explicitly > installed and created by the user, so they are "user data" - and > should be visible. > Mirek I disagree. If you want to use extra programs, you should be skilled enough to use ~/.local/bin directory, it's not that hard to use it. So called hidden directories are not trying to be invisible. They are hidden just so they don't pollute users "Open file" or "Save as..." dialogs, we have hidden .config, .gconf and even .wine so your ~/.wine/drive_c is "hidden". bin directory is not directory for random files, files are not stored there frequently, those files are not removed nor modified frequently. Don't forget to tell your users "do not store random files in ~/bin" and things like that. Also if you want something "bigger" than just one executable, where would do you put other files? Another directory in in $HOME ? ~/.local prefix is much better, you can add there other directories and keep your $HOME clean. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Adding ~/.local/bin to default PATH
On 07/27/2011 10:09 PM, Reindl Harald wrote: > > > Am 27.07.2011 21:59, schrieb Marc-André Lureau: >> I don't understand the security risks. If something is allowed to >> write to ~/.local/bin (or ~/bin etc..), then surely it's able to read >> elsewhere or do something else nasty. Could someone detail it? > > Depends on the PATH-Order yes, and if attacker wants to do something, there are better options than putting 'ls' file in ~/.local/bin or ~/bin, which will be executed only if global ls is missing. If he can put file somewhere, why don't just write ~/.bash_profile with own content? you can change PATH, aliases, add there 'ls' function or anything else you want... -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fwd: [Fedora Update] [CRITPATH] [old_testing_critpath] mdadm-3.1.3-0.git20100804.3.fc14
On 08/10/2011 03:02 PM, Doug Ledford wrote: > Can we please either disable these nag messages or give developers the > ability to push a package regardless of testing when it reaches nag age? I'm getting the same mail for some time now for my critpath security update. I'm just wondering how long it takes before update reaches users, so I'm not going to beg any proventester for help this time (yet). On 08/12/2011 09:28 AM, Adam Williamson wrote: > - FESCo came up with the current update approval process. Anyone can > propose a change to it, you have as much standing as me (if not more) to > do that. FESCo would have to discuss and approve it. We've seen this flame^Wdiscussion already and my experience says: don't bother with it. Add mail filtering rule to delete this mail. It's more efficient way you can spent your time. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: UsrMove feature (was Re: FESCo meeting minutes for 2011-10-24)
On 10/25/2011 09:30 AM, Harald Hoyer wrote: > On 10/25/2011 09:15 AM, Harald Hoyer wrote: >> It's not only an aesthetic issue. This enables possibilities, which were >> not doable before. ... > - mount rootfs encrypted > - mount /usr not encrypted (no secrets here) this is already possible, I use this setup for a long time. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: UsrMove feature
On 10/27/2011 10:34 AM, Harald Hoyer wrote: > On 10/26/2011 06:21 PM, Toshio Kuratomi wrote: >> On Wed, Oct 26, 2011 at 03:18:42PM +0200, Harald Hoyer wrote: >>> On 10/26/2011 03:07 PM, Chris Adams wrote: Once upon a time, Richard W.M. Jonessaid: > Having said that, the split between /sbin and /bin is not a truly > historical one, ie. it didn't exist in V7. I think it was added by > System V which did a lot of other strange stuff too. Well, historically, a bunch of system utilities were in odd places like /etc and /usr/lib. The idea of /sbin and /usr/sbin was to get compiled executables out of those places (and to not clutter up the "normal" bin directories with stuff users didn't need). >>> >>> For daemons, which should not be called directly on the command line, I >>> would suggest to move them to /usr/lib// anyway. >>> >> In context, at least, this is wrong advice as it's a violation of the FHS: >> >> http://pathname.com/fhs/pub/fhs-2.3.html#PURPOSE22 >> >> """ >> Purpose >> /usr/lib includes object files, libraries, and internal binaries that are >> not intended to be executed directly by users or shell scripts. >> [..] >> Specific Options >> >> For historical reasons, /usr/lib/sendmail must be a symbolic link to >> /usr/sbin/sendmail if the latter exists. >> """ >> >> The daemons and such were in places like /usr/lib to begin with. This was >> deemed to be the wrong place for them. Instead they were placed into /sbin. >> >> You may be quibbling over the use of "shell scripts" in that section as you >> might think that daemons aren't run from shell scripts in systemd and that >> illustrates that shell scripts were only an implementation detail in sysv. >> In doing so, however, you miss out on "internal binaries". A daemon >> executable is the public entry point into a service so they aren't internal. >> >> -Toshio >> > > And I want to point to > http://pathname.com/fhs/pub/fhs-2.3.html#FTN.AEN1394 , which you omitted: > > Applications may use a single subdirectory under /usr/lib. If an > application uses a subdirectory, all architecture-dependent data > exclusively used by the application must be placed within that > subdirectory. [23] That would also mean that libreoffice (using /usr/lib*/libreoffice) should have all binaries there? I guess not. I can be wrong, but "used by the application" seems different from "application itself". -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: mass rebuild of mysql packages in F-15
On Wednesday, March 23, 2011 12:11:36 Marcela Maslanova wrote: > Because many packages in F-15 have broken dependencies there will be needed > mass rebuild. > > dhorak will build these, which are not rebuild yet. just note that update script needs some modifications for future usages. It should check whether update exists git and/or koji, because there is quite "long" time before getting the list of packages and real update. Checking git last modification should be really easy. Also F15 can be a little behind of rawhide packages, so using the same list (F15 list for rawhide) is not sufficient (but git check would fix it). Just my comments so it works better next time and there are no updates like this: """""""""""""""""" Package: dovecot-2.0.11-3.fc16 Tag: dist-f16 Started: Wed, 23 Mar 2011 18:14:09 UTC Changelog: * Wed Mar 23 2011 Dan Horák - 1:2.0.11-3 - rebuilt for mysql 5.5.10 (soname bump in libmysqlclient) * Wed Mar 23 2011 Michal Hlavinka - 1:2.0.11-2 - rebuild because of updated dependencies """""""""""""""""""""""""""""""""" Time between first and second rebuild is 5 hours. Michal -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Systemd unit file implementation questions (ypbind)
Hi,
I have similar question (sorry for stealing this thread). I have package
that has 3 services (they somehow depend on each other). Based on
configuration in /etc/sysconfig/.. file it starts 2 or 3 services. This is
handled by init script, but I don't know how to do it in systemd service
file.
AFAIK:
a)
EnvironmentFile=...
ExecStart=[ -n "$DRIVER" ] && /start/driver/...
ExecStart=[ -n "$BACKEND" ] && /start/backend/...
ExecStart=[ -n "$MONITOR" ] && /start/monitor/...
won't work, because ExecStart must be path, not shell command
b)
ExecStart=/usr/libexec/%{name}/startifset "$DRIVER" /start/driver
ExecStart=/usr/libexec/%{name}/startifset "$BACKEND" /start/backend
ExecStart=/usr/libexec/%{name}/startifset "$MONITOR" /start/monitor
won't work, because there ExecStart can't be used more than once,
except with type=oneshot, which does not work here
c)
ExecStart=/usr/libexec/nut/startthemall
this is only workable solution I know (for now), but I don't know if it's the
best one
d) split it to more service files and make dependency there
this would be incompatible change in configuration and hard to do, because
dependency can change with configuration
Is there a good solution for this?
Michal
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Systemd unit file implementation questions (ypbind)
On Thursday, April 14, 2011 09:54:59 Jóhann B. Guðmundsson wrote: > > > Is there a good solution for this? > > Which service ( file ) is this. > > I can take a look at to see which way is best to approach it. It's package nut : /etc/init.d/ups, there are 3 services: driver, upsd and upsmon. All three services usually run on the same machine, but it's not the only use case. There is going to be slight change for yet another use case. Better not to get inspired by init script, but think about situation where there are three services and some/all of them should be started based on variable in config file (so existing configuration works). -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Systemd unit file implementation questions (ypbind)
On Thursday, April 14, 2011 13:26:02 Michal Schmidt wrote: > On 04/14/2011 11:14 AM, Michal Hlavinka wrote: > > d) split it to more service files and make dependency there > > > > this would be incompatible change in configuration and hard to do, > > Hard maybe, but solvable. Incompatibility happens from time to time. > That's what release notes are for. Upstream has their cross-distribution packaging "guidelines" / effort / ... (I can't find the proper description.) Making configuration work different way then on other systems won't make anyone happy. If there is a way to keep current configuration working, then it's the way it will be done. Option c) would work, I'm just looking for another possibility to make it work the same way but also more systemd-like way. > > > because dependency can change with configuration > > Can you elaborate on this? a) ups driver - runs when you have ups attached to that host b) upsd - runs when you have ups attached to that host c) upsmon (master/slave mode) - usualy runs on machine where you have ups, but it can run on machine without ups or work with different ups than the attached one > > What kind of dependencies exist between the three services? Are they 3 > separate daemons? How exactly do they communicate with each other? upsd requires ups driver, upsmon requires upsd (but can be upsd from different machine), on machine where upsd and ups driver run there usualy is upsmon, but it can be on different machine. > Can > they be patched to use socket activation? Because then you could simply > stop thinking about expressing the dependencies manually. Somehow, but you still need to decide whether to start upsmon (which maybe starts upsd and the driver) or start just upsd and driver "manualy" without upsmon. And as I said above, this must be done the way that won't break existing configuration. > Also note that there are two distinct kinds of dependencies: > requirements and ordering. I don't think ordering dependencies change > depending on the configuration, or do they? Somehow. Upsmon can require upsd or not based on configuration, but it does not say anything whether upsd should run or not (if it is not required). -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Systemd unit file implementation questions (ypbind)
On Thursday, April 14, 2011 15:48:09 Lennart Poettering wrote: > On Thu, 14.04.11 14:51, Michal Hlavinka (mhlav...@redhat.com) wrote: > > > > > On Thursday, April 14, 2011 13:26:02 Michal Schmidt wrote: > > > On 04/14/2011 11:14 AM, Michal Hlavinka wrote: > > > > d) split it to more service files and make dependency there > > > > > > > > this would be incompatible change in configuration and hard to do, > > > > > > Hard maybe, but solvable. Incompatibility happens from time to time. > > > That's what release notes are for. > > > > Upstream has their cross-distribution packaging "guidelines" / effort / ... > > (I can't find the proper description.) Making configuration work different > > way then on other systems won't make anyone happy. If there is a way to > > keep current configuration working, then it's the way it will be done. > > Option c) > > would work, I'm just looking for another possibility to make it work the > > same > > way but also more systemd-like way. > > I presume their guidelines just cover SysV-style bootups? It's not only about SysV, but also says something like: when user starts nut, it should start exactly those services that are needed based on /etc/sysconfig/nut MODE=? option In old script one just say he wants to use mode foo and script starts required services (one of the free). Also I don't see how is this different from for example dovecot (pop3 and imap server) where master process starts auth, imapd, pop3d,... there just is no master process. This was handled by init script, because it was sufficient for this job. So it seems that systemd is not capable of doing this and "master" script will solve this. > > > > > > What kind of dependencies exist between the three services? Are they 3 > > > separate daemons? How exactly do they communicate with each other? > > > > upsd requires ups driver, upsmon requires upsd (but can be upsd from > > different machine), > > on machine where upsd and ups driver run there usualy is upsmon, but > > it can be on different machine. > > If upsd strictly requires ups driver, then a Requires= directive in its > unit file is a good idea. If I use Requires= directive, it starts driver for upsd, but is it possible to specify to stop the driver when upsd stops? -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Systemd unit file implementation questions (ypbind)
On Thursday, April 14, 2011 14:46:01 Jóhann B. Guðmundsson wrote: > On 04/14/2011 12:51 PM, Michal Hlavinka wrote: > > > >> Can you elaborate on this? > > a) ups driver - runs when you have ups attached to that host > > b) upsd - runs when you have ups attached to that host > > c) upsmon (master/slave mode) - usualy runs on machine where you have ups, > > but it can run > > on machine without ups or work with different ups than the attached one > > > > Looking at the old sysv it only does 2 things... As I said above - don't look at init script for analyzation because there are some options missing right now, there was going to be some change to support other use cases. It's better to focus on theoretical situation where you have 3 daemons started by one script based on one option in config file. That's all -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Systemd unit file implementation questions (ypbind)
On Thursday, April 14, 2011 19:54:36 Lennart Poettering wrote: > On Thu, 14.04.11 16:15, "Jóhann B. Guðmundsson" (johan...@gmail.com) wrote: > > > > > On 04/14/2011 03:36 PM, Lennart Poettering wrote: > > >> In man systemd.unit > > >> > > > >> > BindTo= > > >> > Configures requirement dependencies, very similar in > > >> > style > > >> > to Requires=, however in addition to this behaviour it also > > >> > declares that this unit is stopped when any of the units > > >> > listed suddenly disappears. Units can suddenly, unexpectedly > > >> > disappear if a service terminates on its own choice, a > > >> > device is unplugged or a mount point unmounted without involvement of > > >> > systemd. > > >> > > > >> > ExecStop=-/bin/systemctl stop upsd-device.service > > >> > ExecStop=-/bin/systemctl stop upsd-monitor.service > > > Why ExecStop= here? > > > > It was meant as an either or. > > > > The BindTo= reference in the man page does not mention that it will take > > down with it any service bound to it when the service is stop. > > Requires= and BindTo= both do that. > > The difference between the two switches is mostly an ordering issue: > > Let's say you have a unit A and a unit B. B requires A, and should be > started after A is up. So in B you say: > > Requires=A > After=A Why is "After=" required here? If B Requires A it seem obvious that B should be started After A (if there is no socket magic). > > now, if you shut down A with "systemctl stop A", this will also stop B, > and it will do so in the inverse starting order. i.e. stop B first, stop > A second. BindTo= would do exactly the same here. The difference now > comes if for some reason A dies independently of anybody running > "systemctl stop A": should we then shut down B retroactviely? The > ordering would normally suggest that B goes down before A, but if A just > goes away on its own, then should we still shut down B? If you use > BindTo= that's what would happen. If you use Requires= it wouldn't. That's not exactly what I'd like to know. Lets say there are services A and B. When B is started, A must be running, so B requires A, but when B is stopped, it should stop A. So A is started only on demand, but it should not be running if there is nothing that requires it. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Systemd unit file implementation questions (ypbind)
> > > now, if you shut down A with "systemctl stop A", this will also stop B, > > > and it will do so in the inverse starting order. i.e. stop B first, stop > > > A second. BindTo= would do exactly the same here. The difference now > > > comes if for some reason A dies independently of anybody running > > > "systemctl stop A": should we then shut down B retroactviely? The > > > ordering would normally suggest that B goes down before A, but if A just > > > goes away on its own, then should we still shut down B? If you use > > > BindTo= that's what would happen. If you use Requires= it wouldn't. > > > > That's not exactly what I'd like to know. Lets say there are services A and > > B. > > When B is started, A must be running, so B requires A, but when B is > > stopped, > > it should stop A. So A is started only on demand, but it should not be > > running > > if there is nothing that requires it. > > In general we try to avoid work if we can. That includes that we don't > stop services unless we have to. Often it is nicer to just leave a > service running when it hangs in a poll() and is swapped out than to > start/stop it all the time. > > That said, systemd wouldn't be systemd if it wouldn't cover your case > too, if you really want. Set "StopWhenUnneeded=yes" in a unit and it > will be stopped as soon as nothing runs anymore that needs it. Defaults > to "no". > > But I think in the general case this isn't really something you want to > use much. There is a good reason for case where service need exclusive access to some resources (device,port,...), because you can't start different service until first one stops. For example with nut (ups daemon) driver must release ups device so when you want to try different ups daemon (for example apcupsd) ups device is not used by anything -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
systemd questions
Hi, I'm working with nut upstream to test sysv->systemd changes, but I found some problems and they've came up with a few questions too. 1) does systemd support alternative to "service sthd configtest" or other special actions? 2) does systemd have support for conditions in service files? It seem it's not supported right now. Is there any plan for this? 3) in which cases I should ommit [Install] section in service file? 4) Is there any difference between a) A.service: After=B.service and b) B.service: Before=A.service or both a) and b) are required? We have service A and service B. Service B requires service A, but it can require service A from different host (depends on configuration). So we've added After=A in service B and also Before=B in service A, but it did not help. Expected result was B is started and if A is configured to start too, it should be started before B. Actual result is that B is started before A if both of them should start (when using systemctl start B.service A.service). 5) in old initscripts, there was /etc/init.d/halt with section for ups shutdown. With that script gone, was that functionality ported to systemd somehow? Thanks Michal -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: systemd questions
> > 2) does systemd have support for conditions in service files? It seem > > it's not supported right now. Is there any plan for this? > > I am not entirely sure what you understand by "condition", for example condition based on string/variable in file, so: a) EnvironmentFile=/etc/sysconfig/something; ExecStart=[ $MODE = master ] && /usr/sbin/xyz_master || /usr/sbin/xyz_slave or b) ExecStart=grep -q something /etc/sysconfig/something && /usr/sbin/xyz_master || /usr/sbin/xyz_slave or based on exit status of some command c) xyz_required && /usr/sbin/xyz but I guess I need to use shell script for this so following question: is there going to be any standard place for those scripts? I'm using /usr/libexec//script_file > > 5) in old initscripts, there was /etc/init.d/halt with section for ups > > shutdown. With that script gone, was that functionality ported to > > systemd > > somehow? > > Well, any such code is just inherently broken. It *cannot* work. but it does work for more than a decade > A > number of kernel subsystems hook into the shutdown code of the > kernel. For example storage code syncs meta data to disk after the > reboot() syscall is invoked. If you however turn off power before > reaching reboot(), then this step is omitted which might trigger data > loss. when ups recieves command for shutdown, it does not shutdown power immediately, but after 30 seconds. Given that this command should be executed after umount, synced disks,... when everything is ready for power off... 30 seconds proved to be enough time for this. > UPS code like that needs to sit in the kernel itself to properly > work. Adding userspace kludges which invokes this from userspace is a > recipe for desaster. If *you* wan't to write kernel drivers for tons of UPS models using serial/usb/network/... connections with tons of protocols (with incomplete documentation)... it's your freedom to do so ;) > (That all said you may drop binaries into /lib/systemd/system-shutdown > which are executed right before invoking reboot(). But if you package > anything that drops binaries into that dir for UPS uses, then I will > personally track you down and tell you mom how bad you are!) That'd hardly scare my mom :D -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: systemd questions
> > 5) in old initscripts, there was /etc/init.d/halt with section for ups > > shutdown. With that script gone, was that functionality ported to > > systemd > > somehow? > > Well, any such code is just inherently broken. It *cannot* work. A > number of kernel subsystems hook into the shutdown code of the > kernel. For example storage code syncs meta data to disk after the > reboot() syscall is invoked. If you however turn off power before > reaching reboot(), then this step is omitted which might trigger data > loss. UPS code like that needs to sit in the kernel itself to properly > work. Adding userspace kludges which invokes this from userspace is a > recipe for desaster. The point of UPS is to prevent data loss after all, > and if you turn off the power before the kernel dealt with reboot() you > invite data loss. (And no, just adding random sleeps, is not a fix, it > just delays the problem.) > > (That all said you may drop binaries into /lib/systemd/system-shutdown > which are executed right before invoking reboot(). But if you package > anything that drops binaries into that dir ... how can automake & friends use this directory? FOO=$(pkg-config --variable=systemdsystemunitdir systemd)/../system-shutdown (or FOO=$(dirname $(pkg-config --variable=systemdsystemunitdir systemd) )/system-shutdown or is there a better way for this? -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: F15 "Error mounting eCryptfs: [-5] Input/output error" on different disks
On 06/17/2011 04:02 PM, Eric Sandeen wrote: > On 6/17/11 6:28 AM, Michael Schwendt wrote: >> On Thu, 16 Jun 2011 21:45:01 +0200, MP wrote: >> >>> W dniu 16 czerwca 2011 21:43 użytkownik Eric Sandeen napisał: On 6/16/11 2:37 PM, Michał Piotrowski wrote: > Hi, > > Do anyone noticed any problems with mounting eCryptfs recently on F15? > It seems to me unlikely that I have an I/O errors on few disks. > Especially if only eCryptfs reports them. > Anything in dmesg? >>> >>> Nothing unusual >>> -Eric >> >> In /var/log/messages: >> >> Jun 17 13:24:46 localhost mount.ecryptfs: Failed to write to the mount table > > likely a result of /etc/mtab pointing to /proc/mounts now > > Can you file an ecryptfs-utils bug for that? I don't know how it'll > be fixed but it looks like an issue. It's already reported and fixed. Submitted for stable since 2011-06-16 https://admin.fedoraproject.org/updates/ecryptfs-utils-87-3.fc15 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: The behaviour of systemctl.
On 06/17/2011 10:16 PM, Aaron Sowry wrote: > Hello, > > I'd like to discuss the behaviour of systemctl. See RH bug 713567 for > context. To summarise: > > - 'systemctl --all' pages by default when the output is to tty. This consumes > 50-60+ lines of potentially bug-prone code, and irks the crap out of me as a > system administrator. systemctl's jurisdiction ends at stdout. > > - The same command outputs column headers on tty, and no headers otherwise. > This is inconsistent. If I am outputting to a file, or perhaps a printer, and > want headers on my non-tty output, I have to add them myself since there is > no flag to force them on non-tty channels. If I don't want them and they are > present, I tail. > > - Currently, if I run 'systemctl --all' and have no pager (at least no pager > that systemctl knows of) available, I get an error message and no output. > This is horribly bad form, and forces me to use --no-pager or pipe to cat in > order to get output. This issue is acknowledged in RH bug 713707. > > - Another bright idea (RH bug 713567) is that --full should be applied to > non-tty output automatically, and not to tty output. > > All of these peculiarities stem from poor UNIX programming practise. Do not > try to make decisions for me as a user (especially not based on output > channels), about how I want my output formatted. No other Linux/UNIX tools > make this assumption (with perhaps the exception of git-log et. al.), and if > you are wanting administrators to feel comfortable with your new > soon-to-be-ubiquitous tools, then I suggest you try to be consistent with > existing convention. I don't want to have to check man pages to see if piping > output gives me different results than tty, and I would rather use existing, > well-proven tools to format my output than a bunch of flags I have to > re-learn just to be able to deal with systemctl. The type of people using > systemctl are not the type of people that are going to need hand-holding. > > Thanks. > I'll add one (small) inconsistency: # systemctl is-active has following output: > active and sets exit code. If you don't wont any output, you need to use "--quiet" # systemctl is-enabled just sets exit code. I'd prefer if the behaviour of "is-active" and "is-enabled" is the same: simple output and "--quiet" option. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora rawhide FTBFS status 2011-06-16 x86_64
On Wednesday 22 of June 2011 19:17:45 Matt Domsch wrote: > Fedora Fails To Build From Source Results for x86_64 > using rawhide from 2011-06-16 > > Good hunting! > > Full logs at http://linux.dell.com/files/fedora/FixBuildRequires/ ... > Total packages: 10614 > Number failed to build: 603 > Number expected to fail due to ExclusiveArch or ExcludeArch: 27 > Leaving: 576 > > Of those expected to have worked... > Without a bug filed: 531 > -- ... > mhlavink: mksh this should not be on the list: ... Wrote: /builddir/build/RPMS/mksh-39c-4.fc16.x86_64.rpm Wrote: /builddir/build/RPMS/mksh-debuginfo-39c-4.fc16.x86_64.rpm ... build.log shows it works fine -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Heads-up: net-snmp soname bump in rawhide
On Thursday 07 of July 2011 15:23:19 Jan Safranek wrote: > net-snmp-5.7 is heading to rawhide, please rebuild your packages if you > depend on it. > > $ repoquery --whatrequires net-snmp-libs net-snmp net-snmp-devel > net-snmp-perl net-snmp-python --alldeps -s | sort | uniq > ... > apcupsd done ... and ... > nut done -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: glibc 2.14-4 eats my data (Re: F15 ext3, eCryptfs + samba = data corruption (Re: F15 "Error mounting eCryptfs: [-5] Input/output error" on different disks))
>>>> W dniu 8 lipca 2011 18:21 użytkownik Michał Piotrowski >>>> >>>> napisał: >>>>> Hi, >>>>> >>>>> 2011/7/8 Andreas Schwab: >>>>>> Use valgrind. >>>>> >>>>> I attach valgrind output. >>>>> >>>>> ==1312== 1 errors in context 1 of 116: >>>>> ==1312== Source and destination overlap in memcpy(0xaef1590, 0xaef1593, >>>>> 76) ==1312==at 0x4C283B6: memcpy@@GLIBC_2.14 >>>>> (mc_replace_strmem.c:653) ==1312==by 0x401835: ??? (in >>>>> /sbin/mount.ecryptfs) >>>>> ==1312==by 0x5E3039C: (below main) (in /lib64/libc-2.14.so) >>>> >>>> I installed ecryptfs-utils-debuginfo package and now it's more readable >>>> >>>> ==1815== 1 errors in context 1 of 116: >>>> ==1815== Source and destination overlap in memcpy(0xaef1590, 0xaef1593, 76) >>>> ==1815== at 0x4C283B6: memcpy@@GLIBC_2.14 (mc_replace_strmem.c:653) >>>> ==1815==by 0x401835: main (string3.h:52) >>>> >>>>> Could this be related to >>>>> - Fix static linking with checking x86/x86-64 memcpy (BZ#12653) >>>>> or is it an eCryptfs problem? >> W dniu 8 lipca 2011 20:08 użytkownik Michal Hlavinka >> napisał: >>> Hi, >>> >>> please check if this package changes anything for you: >>> >>> http://kojipkgs.fedoraproject.org/scratch/mhlavink/task_3187528/ >> >> unfortunately there is no difference > > I'm attaching valgrind output. I checked your patch and it removes > correctly all uses of memcpy so it seems that memcpy only covered the > root of the problem. ok, complain about memcpy in ecryptfs-utils is gone. I've checked all of them and I think I've fixed those which needed it. I was not able to reproduce original problem nor valgrind complaint, so please test if following package produces memcpy complain in valgrind output or not: http://kojipkgs.fedoraproject.org/scratch/mhlavink/task_3190860/ Anyway, I don't think there is any problem in ecryptfs-utils, because it's just mount helper. It's not running when files are being encrypted/decrypted and you said it works fine when you use ecryptfs directly (without samba). We've fixed memcpy bug in ecryptfs which is definitely a good think, but problem is elsewhere. If you want, you can test following build of samba which has all occurrences of memcpy replaced by memmove. I don't dare to guess if it changes anything, but give it a try if you want: http://kojipkgs.fedoraproject.org/scratch/mhlavink/task_3190918/ Could you describe your environment in more details so we can try to reproduce it? For example what ecryptfs options you use (including fstab line if you have any), samba configuration etc... Michal -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: glibc 2.14-4 eats my data (Re: F15 ext3, eCryptfs + samba = data corruption (Re: F15 "Error mounting eCryptfs: [-5] Input/output error" on different disks))
On 07/11/2011 05:40 PM, Michał Piotrowski wrote: > Hi, > > W dniu 11 lipca 2011 17:09 użytkownik Michal Hlavinka > napisał: >> ok, complain about memcpy in ecryptfs-utils is gone. I've checked all of >> them and I think I've fixed those which needed it. I was not able to >> reproduce original problem nor valgrind complaint, so please test if >> following package produces memcpy complain in valgrind output or not: >> >> http://kojipkgs.fedoraproject.org/scratch/mhlavink/task_3190860/ > > Your mtab handling patch fixed both issues - mount warning and data > corruption :) Huge thanks! I can't imagine *how* it could affect this, so I'd advice to monitor it carefully if it is fixed for real. Btw, there is not only mtab patch, but 2x memcpy -> memmove too, just not all of them as in previous test package (which did not help). >> Could you describe your environment in more details so we can try to >> reproduce it? For example what ecryptfs options you use (including fstab >> line if you have any), samba configuration etc... > > I do not think that it had any significance - it seems to me that > these options are pretty standard > mount -t ecryptfs /home/$SHARE/ /home/$SHARE/ -o > key=passphrase,ecryptfs_cipher=aes,ecryptfs_key_bytes=16,ecryptfs_passthrough=n,ecryptfs_fnek_sig=some_value > > It's a little strange that you could not reproduce that mount warning. AFAIK that memcpy warning from valgrind gets triggered only if you use "correct" -o ... option -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: glibc 2.14-4 eats my data (Re: F15 ext3, eCryptfs + samba = data corruption (Re: F15 "Error mounting eCryptfs: [-5] Input/output error" on different disks))
On 07/11/2011 06:05 PM, Michał Piotrowski wrote: > W dniu 11 lipca 2011 17:57 użytkownik Michal Hlavinka > napisał: >> On 07/11/2011 05:40 PM, Michał Piotrowski wrote: >>> >>> Hi, >>> >>> W dniu 11 lipca 2011 17:09 użytkownik Michal Hlavinka >>> napisał: >>>> >>>> ok, complain about memcpy in ecryptfs-utils is gone. I've checked all of >>>> them and I think I've fixed those which needed it. I was not able to >>>> reproduce original problem nor valgrind complaint, so please test if >>>> following package produces memcpy complain in valgrind output or not: >>>> >>>> http://kojipkgs.fedoraproject.org/scratch/mhlavink/task_3190860/ >>> >>> Your mtab handling patch fixed both issues - mount warning and data >>> corruption :) Huge thanks! >> >> I can't imagine *how* it could affect this, so I'd advice to monitor it >> carefully if it is fixed for real. > > Ok, so I will do. Before each time I mounted ecryptfs I get this > "Error mounting eCryptfs: [-5] Input/output error" error. Now it's > gone - I tried a few times. yes, this is related to mtab patch, but it mounted it anyway. I was able to reproduce this warning. It should not affect smb+ecryptfs data corruption in any way. Btw, did you test if this version works in valgrind or not? (the "Source and destination overlap in memcpy" warning). btw, we should move this conversation off list if it's related only to ecryptfs. Michal -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: glibc 2.14-4 eats my data (Re: F15 ext3, eCryptfs + samba = data corruption (Re: F15 "Error mounting eCryptfs: [-5] Input/output error" on different disks))
>> ok, complain about memcpy in ecryptfs-utils is gone. I've checked all >> of >> them and I think I've fixed those which needed it. I was not able to >> reproduce original problem nor valgrind complaint, so please test if >> following package produces memcpy complain in valgrind output or not: >> >> http://kojipkgs.fedoraproject.org/scratch/mhlavink/task_3190860/ > > Your mtab handling patch fixed both issues - mount warning and data > corruption :) Huge thanks! I can't imagine *how* it could affect this, so I'd advice to monitor it carefully if it is fixed for real. >>> >>> Ok, so I will do. Before each time I mounted ecryptfs I get this >>> "Error mounting eCryptfs: [-5] Input/output error" error. Now it's >>> gone - I tried a few times. >> >> yes, this is related to mtab patch, but it mounted it anyway. I was able to >> reproduce this warning. It should not affect smb+ecryptfs data corruption in >> any way. > > I uploaded another large file (> 1 GB) and unfortunately data > corruption problem still exist - I do not know why it worked > previously. > this was expected. ecryptfs-utils is really just a mount helper, but thanks memcpy bug in ecryptfs-utils was fixed, glibc/samba can get its attention without distractions You can test that samba build I've sent you. I'll try to reproduce this too, but this requires someone with better knowledge of glibc/samba where I can't help too much. Michal -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Heads up: X server configuration changes
Hi, > So you're running an X server? Well, my lad or lass, sit down and let me > tell you about the neverending story of X server input configuration > changes that has hopefully ended now. > I'm just pushing the latest X server goodness into rawhide and enabling > udev, completing (from the X server's POV) the excision of the hardware > abstraction layer that shall not be named. > > >From F9 to including F12 (and rawhide until today) we've used hal to > > discover the input devices. For lack of better options, this means that > many configurations have moved into fdi files. As you may know, hal is > deprecated and as much as fdi files may be pleasing to the eyes, there's > just no future in them. You'll just have to let it go, even if it hurts. > > Instead, we have the newest latest and greatest bits, namely xorg.conf.d > support and InputClasses. You can drop configuration files into the new > directory and the server will pick it up on startup. > e.g. /etc/xorg.conf.d/foobar.conf > "A configuration directory? Is this even possible?" you say? I know, it > sounds mightily advanced but we have to keep surfing the wave of new > technological achievements. > > The existing section types in xorg.conf(5) weren't really suitable, so we > now have something that resembles the functionality provided by hal's fdi > files. A section of type InputClass will match against multiple devices and > even hotplugged ones - depending on the match rules. An example section > looks like this: > > Section "InputClass" > Identifier "superhero mouse config" > MatchIsPointer "on" > MatchProduct "Mighty Mouse" > Driver "evdev" > Option "X-Ray vision" "on" > EndSection > > Any pointer device that contains "Mighty Mouse" in its product name will > match against this section and be added with the evdev driver and the > options as specified. That's just one example, I've tried to detail the new > configurations on our wiki. > https://fedoraproject.org/wiki/Input_device_configuration > If you think there's anything missing, please let me know or add it > yourself. How is this going to affect some users that don't read release notes nor fedora devel list? Also, I have some configuration in fdi files (for touchpad for example). Will it still work with some (not too much visible?) complains in logs "this is deprecated"? Will it stop working without any information in logs? ... > Because the match rules are different to hal's matching rules, we don't > have an automatic conversion from your custom fdi files into xorg.conf > format. If you have custom rules, I recommend porting them to the new > format before updating to ensure a smooth upgrade. > > Cheers, > Peter Cheers, Michal -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Heads up: X server configuration changes
On Tuesday 16 February 2010 08:47:20 Peter Hutterer wrote: > On Tue, Feb 16, 2010 at 08:25:54AM +0100, Michal Hlavinka wrote: > > Hi, > > > > > So you're running an X server? Well, my lad or lass, sit down and let > > > me tell you about the neverending story of X server input > > > configuration changes that has hopefully ended now. > > > I'm just pushing the latest X server goodness into rawhide and enabling > > > udev, completing (from the X server's POV) the excision of the hardware > > > abstraction layer that shall not be named. > > > > > > >From F9 to including F12 (and rawhide until today) we've used hal to > > > > > > discover the input devices. For lack of better options, this means that > > > many configurations have moved into fdi files. As you may know, hal is > > > deprecated and as much as fdi files may be pleasing to the eyes, > > > there's just no future in them. You'll just have to let it go, even if > > > it hurts. > > > > > > Instead, we have the newest latest and greatest bits, namely > > > xorg.conf.d support and InputClasses. You can drop configuration files > > > into the new directory and the server will pick it up on startup. > > > e.g. /etc/xorg.conf.d/foobar.conf > > > "A configuration directory? Is this even possible?" you say? I know, it > > > sounds mightily advanced but we have to keep surfing the wave of new > > > technological achievements. > > > > > > The existing section types in xorg.conf(5) weren't really suitable, so > > > we now have something that resembles the functionality provided by > > > hal's fdi files. A section of type InputClass will match against > > > multiple devices and even hotplugged ones - depending on the match > > > rules. An example section looks like this: > > > > > > Section "InputClass" > > > > > > Identifier "superhero mouse config" > > > MatchIsPointer "on" > > > MatchProduct "Mighty Mouse" > > > Driver "evdev" > > > Option "X-Ray vision" "on" > > > > > > EndSection > > > > > > Any pointer device that contains "Mighty Mouse" in its product name > > > will match against this section and be added with the evdev driver and > > > the options as specified. That's just one example, I've tried to > > > detail the new configurations on our wiki. > > > https://fedoraproject.org/wiki/Input_device_configuration > > > If you think there's anything missing, please let me know or add it > > > yourself. > > > > How is this going to affect some users that don't read release notes nor > > fedora devel list? Also, I have some configuration in fdi files (for > > touchpad for example). Will it still work with some (not too much > > visible?) complains in logs "this is deprecated"? Will it stop working > > without any information in logs? ... > > hmm, at this point, yes, pretty much. > The fdi files are merged in by HAL itself and their content is part of the > information that HAL provides to the server. since the server doesn't > listen to HAL anymore, this information gets ignored. > All you'll see in the log is that it now says "udev" where it used to say > "HAL". > > I can put a giant warning into the log that if input devices don't work > then the users should have a look at the website above for > reconfiguration. How does that sound? Do you have any better suggestions? Are existing *.fdi files going to be used by something (except hal itself)? If not, hal should be complaining during start up about "deprecated configuration found". Also, is this 1:1 change or was something "improved", so we can see changes in behavior for touchpad or anything else? > > Cheers, > Peter -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: F13 -EGPUDRIVERNOWORKIE
On Wednesday 10 March 2010 17:14:41 Michał Piotrowski wrote: > Hi, > > I tried to install this new Goddard thing on my laptop and it seems to be > b0rken https://bugzilla.redhat.com/show_bug.cgi?id=572243 > > Any chance to get graphical installer with vesa driver? > > Regards, > Michal afaik you have to use xdriver=vesa as additional boot parameter Michal -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Upstream bugs vs. Fedora bugs: KDE people do it wrong
On Wednesday 31 March 2010 12:50:10 Jaroslav Reznik wrote: > On Wednesday 31 March 2010 12:26:17 Rahul Sundaram wrote: > > On 03/31/2010 03:45 PM, Frank Murphy wrote: > > > which will make fixing bugs in current even more important. > > > > Not at all. Either the bug is important to fix in the current release > > or it is not. Telling users to get it from Rawhide was never a valid > > resolution. It is a workaround in some very small cases. > > For example bug report - typo in SPEC file - it should be fixed in Rawhide, > but no need to push this update to current releases. Well, I was thinking about example too, but for this case I usually fix all releases, and leave bug in modified. This way all people get the fix later when something more important comes. Michal -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Thunderbird bz 579023 still not fixed even though there is an upstream fix available
On Friday 23 of April 2010 09:03:37 Martin Stransky wrote: > Hi, > > we're patching mozilla packages only for really critical issues because > of mozilla trademarks. We can't put any patch we want to the mozilla > package and ship it as 'Firefox' or 'Thunderbird'. just curious: is it possible to ship snapshots or trademarks does not allow this too? > > I've asked for inclusion at upstream bug, > https://bugzilla.mozilla.org/show_bug.cgi?id=550455, if you want to > speed up the process you can reply there too. > > ma. > > On 04/22/2010 08:39 PM, Felix Schwarz wrote: > > Hi, > > > > I'm concerned about bz 579023 [1] which is a Thunderbird crasher bug. > > This bug was fixed upstream [2] for about 3-4 weeks. I ran a thunderbird > > koji build version [3] with an adapted version of that patch since then > > without any problems. Other users confirmed that this patch fixes their > > problems as well. > > > > The Fedora bug has a number of duplicates with quite some number of cc'd > > users so I guess a lot of people experiencing these crashes. > > > > However it is still not fixed in Thunderbird F-12 CVS. Can you please > > push the fix to CVS and push builds to testing/stable? > > > > fs > > > > [1] https://bugzilla.redhat.com/show_bug.cgi?id=579023 > > [2] https://bugzilla.mozilla.org/show_bug.cgi?id=550455 > > [3] http://koji.fedoraproject.org/koji/taskinfo?taskID=2092397 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Bad coding practices in Fedora packages
On 01/03/2012 05:21 PM, Sérgio Basto wrote: On Tue, 2012-01-03 at 11:15 -0500, Genes MailLists wrote: On 01/03/2012 09:16 AM, Denys Vlasenko wrote: # cat /proc/meminfo>/tmp/1; killall tracker-store; sleep 1; cat /proc/meminfo>/tmp/2; cat /tmp/1 /tmp/2 | grep MemFree MemFree: 1940372 kB MemFree: 1963860 kB As you see, killing it on my machine freed over 23 megs worth of pages. As far as I know tracker is a feature of Gnome 3 - there may be a way to turn it off tho it may need a gnome registry tweak ... yeah other day this tracker or other from gnome , note that I use KDE , begins track down my external hdd via NAS , which have 1 Tera , IIRC . I notice because can't unmount my smbfs . rpm -ql tracker /etc/xdg/autostart/tracker-miner-flickr.desktop /etc/xdg/autostart/tracker-miner-fs.desktop /etc/xdg/autostart/tracker-store.desktop I agree, at least for non-gnome users , tracker shouldn't be in autostart. https://bugzilla.redhat.com/show_bug.cgi?id=771601 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: does /etc/sysctl.d/ really obeyed and does really override /etc/sysctl.conf
On 03/16/2012 02:28 PM, Lennart Poettering wrote: On Fri, 16.03.12 14:54, Muayyad AlSadi (als...@gmail.com) wrote: but this does not make sense the idea behind all .d is to allow packages to provide default (either kernel defaults or distro defaults) because the other choice is to use %post and sed eg. let's say I made a firewall package that needs to enable forwarding, it would put it in a sysctl.d If a package places a sysctl file in /etc/sysctl.d/ then you can override it with /etc/sysctl.conf, hence everything is as it should, no? This whole logic is designed so that the admin's configuration always takes precedence over vendor configuration. Which is the right thing to do. That said, note that it's probably a good idea if packages stick their sysctl files in /usr/lib/sysctl.d instead, so that that users can use /etc/sysctl.d/ to override that. /etc/sysctl.conf is read mostly for compatibility reasons only. As I understand it, Muayyad has different problem. Right now, the /etc/sysctl.conf we ship is not empty. It has several values set, one of them is sysrq=0 he used in his example. No one set this is value, it's just default value and yet, no package can change it by placing its file in /etc/sysctl.d This would work only if sysctl.conf is empty and all default configuration is moved to /etc/sysctl.d/00-systemdefault.conf Michal -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
What are differences between real and rpmbuild's environment?
Hi, I'm trying to find out what are differences between environment for local rpm build and usual user's environment. I've added regression tests to %check section of ksh spec file. These tests never fails when executed in user's environment, but some of them always fail when executed as part of rpm build process. I've tried to compare variable in the environment and ulimit values, but there does not seem to be any significant difference. I've also tried to use the same script generated by rpmbuild for %check section (from /var/tmp/rpm.*), but still it does not reproduce the problem. Any ideas? Michal -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: What are differences between real and rpmbuild's environment?
On Monday, November 08, 2010 16:26:22 Rex Dieter wrote:
> Michal Hlavinka wrote:
> > I'm trying to find out what are differences between environment for local
> > rpm build and usual user's environment.
>
> You mean the difference between rpmbuild and... a manual "./configure;
> make"?
something like that but without configure and make. Just the %check section.
Executed by rpmbuild at the end of rpm build process VS running %check section
script by hand with the same ksh binary.
>
> For starters, see rpm's output from
>
> rpm --eval "%{configure}" which sets variance build/optimization flags.
configure makes no difference here, because I'm always using the same ksh binary
>
> and rpmbuild also does:
> LANG=C ; export LANG
> unset DISPLAY
I tried this, no difference
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Re: What are differences between real and rpmbuild's environment?
On Monday, November 08, 2010 19:34:14 Richard W.M. Jones wrote:
> On Mon, Nov 08, 2010 at 03:49:28PM +0100, Michal Hlavinka wrote:
> > I'm trying to find out what are differences between environment for
> > local rpm build and usual user's environment. I've added regression
> > tests to %check section of ksh spec file. These tests never fails
> > when executed in user's environment, but some of them always fail
> > when executed as part of rpm build process. I've tried to compare
> > variable in the environment and ulimit values, but there does not
> > seem to be any significant difference. I've also tried to use the
> > same script generated by rpmbuild for %check section (from
> > /var/tmp/rpm.*), but still it does not reproduce the problem. Any
> > ideas?
>
> Is the spec file using %configure? That adds a lot of flags to the
> configure script. Similarly make _vs_ make %{_smp_flags}.
I'm always using the same ksh binary, so this does not make any difference
> Have you tried 'printenv' at the top of the %check section?
tried, but there does not seem to be significant difference. Also the %check
script I used was the same script rpmbuild creates from the %check section (in
/var/tmp/rpm*) and it defines the same environment:
---
#!/bin/sh
RPM_SOURCE_DIR="/home/mhlavink/gitf/ksh"
RPM_BUILD_DIR="/home/mhlavink/gitf/ksh"
RPM_OPT_FLAGS="-O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -
fstack-protector --param=ssp-buffer-size=4 -m64 -mtune=generic"
RPM_ARCH="x86_64"
RPM_OS="linux"
export RPM_SOURCE_DIR RPM_BUILD_DIR RPM_OPT_FLAGS RPM_ARCH RPM_OS
RPM_DOC_DIR="/usr/share/doc"
export RPM_DOC_DIR
RPM_PACKAGE_NAME="ksh"
RPM_PACKAGE_VERSION="20101026"
RPM_PACKAGE_RELEASE="1.fc14"
export RPM_PACKAGE_NAME RPM_PACKAGE_VERSION RPM_PACKAGE_RELEASE
LANG=C
export LANG
unset CDPATH DISPLAY ||:
RPM_BUILD_ROOT="/home/mhlavink/rpmbuild/BUILDROOT/ksh-20101026-1.fc14.x86_64"
export RPM_BUILD_ROOT
PKG_CONFIG_PATH="/usr/lib64/pkgconfig:/usr/share/pkgconfig"
export PKG_CONFIG_PATH
set -x
umask 022
cd "/home/mhlavink/gitf/ksh"
cd 'ksh-20101026'
unset DISPLAY
SHELL=$(ls $(pwd)/arch/*/bin/ksh)
cp $SHELL ${SHELL}4check
export SHELL=${SHELL}4check
cd src/cmd/ksh93/tests/
ulimit -c unlimited
if [ ! -e /dev/fd ]
then
echo "ERROR: /dev/fd does not exist, regression tests skipped"
exit 0
fi
$SHELL ./shtests 2>&1 | tee testresults.log
killall ksh4check -s SIGKILL
...
---
> Are you specifically running rpmbuild as the same user?
rpmbuild vs. just %check script executed by the same user on the same machine
> Or are we
> talking about rpmbuild in some other environment (mock or Koji)?
> There is a Koji bug which affects ksh %check in particular
> (RHBZ#639275).
I know. I reported that bug
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Re: What are differences between real and rpmbuild's environment?
On Monday, November 08, 2010 15:49:28 Michal Hlavinka wrote:
> Hi,
>
> I'm trying to find out what are differences between environment for local
> rpm build and usual user's environment. I've added regression tests to
> %check section of ksh spec file. These tests never fails when executed in
> user's environment, but some of them always fail when executed as part of
> rpm build process. I've tried to compare variable in the environment and
> ulimit values, but there does not seem to be any significant difference.
> I've also tried to use the same script generated by rpmbuild for %check
> section (from
> /var/tmp/rpm.*), but still it does not reproduce the problem. Any ideas?
>
> Michal
Ok, I've forgot to mention a few things and I'll also add new information I've
found.
- Tests that are failing are all about pipe and sigpipe/pipefail.
- I've tried to reproduce this just with "empty" spec file - I've moved the
tests in %prep section just after sources are unpacked and patched (required
for running tests) and it still fails
- I've prepared simple script with just the first failing test and. I've
modified this test slightly so it can be used with bash too. BASH has no
problem with this test when executed from terminal. When it's executed from
prep section in rpmbuild it fails too.
This is the test script (defined as Source6:)
#
s=$SECONDS
set -o pipefail
for ((i=0; i < 30; i++))
do printf hello 2>/dev/null
sleep .1
done | /bin/sleep 1
(( (SECONDS-s) < 2 )) || printf >&2 'early termination not causing broken
pipe'
#
and it's being executed from %prep section:
#
%prep
export SHELL=/bin/bash
time $SHELL %{SOURCE6}
exit 1
#
Correct real time is 1 sec something, when broken, time is 3 seconds something
and error message is produced.
So it seems rpmbuild has a bug and breaks sigpipe somehow...
Any comments before I file bug?
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Re: What are differences between real and rpmbuild's environment?
On Tuesday, November 09, 2010 16:30:17 Panu Matilainen wrote:
> On Tue, 9 Nov 2010, Michal Hlavinka wrote:
> > On Monday, November 08, 2010 15:49:28 Michal Hlavinka wrote:
> >> Hi,
> >>
> >> I'm trying to find out what are differences between environment for
> >> local rpm build and usual user's environment. I've added regression
> >> tests to %check section of ksh spec file. These tests never fails when
> >> executed in user's environment, but some of them always fail when
> >> executed as part of rpm build process. I've tried to compare variable
> >> in the environment and ulimit values, but there does not seem to be any
> >> significant difference. I've also tried to use the same script
> >> generated by rpmbuild for %check section (from
> >> /var/tmp/rpm.*), but still it does not reproduce the problem. Any ideas?
> >>
> >> Michal
> >
> > Ok, I've forgot to mention a few things and I'll also add new information
> > I've found.
> >
> > - Tests that are failing are all about pipe and sigpipe/pipefail.
> >
> > - I've tried to reproduce this just with "empty" spec file - I've moved
> > the tests in %prep section just after sources are unpacked and patched
> > (required for running tests) and it still fails
> >
> > - I've prepared simple script with just the first failing test and. I've
> > modified this test slightly so it can be used with bash too. BASH has no
> > problem with this test when executed from terminal. When it's executed
> > from prep section in rpmbuild it fails too.
> >
> >
> > This is the test script (defined as Source6:)
> > #
> > s=$SECONDS
> > set -o pipefail
> > for ((i=0; i < 30; i++))
> > do printf hello 2>/dev/null
> >
> >sleep .1
> >
> > done | /bin/sleep 1
> > (( (SECONDS-s) < 2 )) || printf >&2 'early termination not causing broken
> > pipe'
> > #
> >
> > and it's being executed from %prep section:
> > #
> > %prep
> > export SHELL=/bin/bash
> > time $SHELL %{SOURCE6}
> > exit 1
> > #
> >
> > Correct real time is 1 sec something, when broken, time is 3 seconds
> > something and error message is produced.
> >
> > So it seems rpmbuild has a bug and breaks sigpipe somehow...
> > Any comments before I file bug?
>
> Oh, SIGPIPE. That explains... nspr (to which rpm is indirectly married to
> through nss) quietly sets SIG_IGN on SIGPIPE on initialization, triggering
> these kind of obscure misbehaviors in rpm-related scripts. Ain't the first
> time for sure, but the first time somebody manages to trigger the issue in
> build.
>
> Fixing is easy enough, but do file a bug so I wont forget. Extra bonus for
> minimal reproducer.
Thanks, filed as #651463
Michal
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Updates Criteria Summary/Brainstorming
On Saturday, November 20, 2010 23:35:43 Kevin Fenzi wrote: > ok, I dug through the devel list for the last month or two and wrote > down all the various ideas folks have come up with to change/improve > things. > > Here (in no particular order) are the ideas and some notes from me on > how we could enable them. Please feel free to add new (actual/concrete > ideas or notes): > > * Just drop all the requirements/go back to before we had any updates > criteria. I like this idea, but I'm pretty sure this won't happen. I don't like the bureaucracy you can see all around you. Fixing problems caused by individual failure (or individual's failure) with new policy/law does not make happy contributors/people. This is the exact behavior of Civil Aviation Authority in my country - after 50 years of no problems there is one a***ole that kills himself because of ignoring physics and self-preservation, as result all sane normal people have to do more paperwork and are more restricted. The only result is pilots are more and more fed up every year. And know what, there are still people willingly breaking the rules so it does not solve anything. Another comment: When I started to work for Fedora, I tried to do my best. You know, there are some comparisons of OSes and distributions. One of the comparisons being "How many days OS was vulnerable (with known exploitable security bug)". So when there was new CVE-- bug, I tried to fix it as fast as possible, because I wanted to make Fedora The Best Distro. But what happened after I fixed this bug? It took whole week before new build was tagged. Should I work hard if there is no visible result? I was disappointed. Now, packages are tagged quickly and reliably, great improvement (thanks to everyone who helped with this). But again, after things were better we have new policy that delays all bug fixes from being delivered quickly and I'm disappointed again. > * Change FN-1 to just security and major bugfix > > This may be hard to enforce or figure out if something is a major bugfix. This idea would make users less happy, at least from what I see. I manage a few Fedora systems for my friends/relatives who have almost no IT knowledge nor they can use English. They don't care about open-source and other "freedoms". They use Linux just because it's free and usable (they always compare it with m$ windoze they used before). In real world, bugs happen, they don't care too much about bugs in sw, if there is visible progress. If they found a bug, they complain to me and I file it in bugzilla. Once the bug is fixed, I report these wonderful news to them and they are really happy. But... remove the "bug fix delivered to Fn-1" and they won't be happy, in fact they would think that Linux sucks. Restriction to most critical bugs only is not enough. And no, updating all machines every 6 months is too much disturbing (for them) and time consuming (for me). > * allow packages with a %check section to go direct to stable %check can be simple, %check can be complex, but where would you draw the line? Also very limited number of GUI apps has %check (only guess) > * setup a remote test env that people could use to test things. I don't think this would make significant difference. People don't test packages because they don't have time, they are lazy, they don't know how to test it or they are just consumers (not enough IT/english knowledge). > * require testing only for packages where people have signed up to be > testers this could help a little for some cases > * Ask maintainers to provide test cases / test cases in wiki for each > package? this could help, but it's not always possible to add these test cases. One example: imap server package - new bug that can corrupt mail folders in some circumstances. Maintainer updates package and sets 'type=bugfix' in bodhi, but not always it's possible to write down any test case. It's still a bug fix and it's better to be delivered sooner than wait if anyone out there get's his mail folders corrupted. Actual policy does not help proactivity. > * reduced karma requirement on other releases when one has gone stable better than nothing :) > Other concrete ideas? let maintainer decide, punish (enforce any policy) only those maintainers who breaks something, not all innocent group -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: abrt wishlist
Adding my whishlist 1) /etc/abrt/conf.d/ directory - like httpd ones. So I can drop there configuration for my packages. For example when dovecot crashes, I'd like to see doveconf -n output 2) better notification for crashes. I have one application that crashes when I'm ending desktop session, but because abrt-gui is not running at that time (or it's just terminated when it shows up) I'm not notified about that crash and when I log in next time, nothing happens. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [HEADS-UP] util-linux[-ng] and mtab
On Wednesday, January 19, 2011 18:35:52 Karel Zak wrote: > I have pushed new util-linux into rawhide. The project has been > renamed from util-linux-ng back to util-linux. koji did not hadle this change well, because it was not required to specify util-linux-ng as buildrequire, but util-linux nor util-linux-ng is not installed now. So packages that require anything from util-linux(-ng) fails building now. For example: http://koji.fedoraproject.org/koji/getfile?taskID=2732727&name=build.log&offset=-4000 simple test to verify: http://koji.fedoraproject.org/koji/getfile?taskID=2732779&name=build.log -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora 13 continuing the tradition of being an update monster
> Thankfully all the giant flamewars and new policies didn't make anyone > think twice about the users, as we already have 140 updates with a > combined size of _over_ 750MB on x86_64, biggest 5 are: yeah, over 750 MB where 584 MB belongs to wesnoth and openarena. So without these two games it's only 166 MB and that's not that bad (also don't forget about deltarpms). > > 6.2M wesnoth-1.8.1-1.fc13.x86_64.rpm > 12M hanazono-fonts-20100222-2.fc13.noarch.rpm > 48M xmoto-0.5.3-1.fc13.x86_64.rpm > 260M wesnoth-data-1.8.1-1.fc13.noarch.rpm > 318M openarena-0.8.5-1.fc13.noarch.rpm > > ...the last being particularly "nice", in that the package hasn't been > updated for almost a year but now we get 2 300MB+ presents at once. > Welcome to the new Fedora updates, much like the old Fedora updates. why are you so scared about updates? Now we have some packages in Fedora that are broken or outdated (for online multi-player games - you usually can't play with other players when your version is not up2date, so it becomes unusable even the update itself is enhancement only). And what should maintainers do? a) update only in F-14 so users will get broken F-13 and they will have to wait another 6 months for new version? b) wait at least two weeks after F-13 GA, so we won't have too much 0-day updates? Does anyone really think lower 0-day update size is much cool than delivering fixed packages? c) wait until there is critical/security bug only? So bug reporter has to wait three months for getting the fix for bug he reported? It'll just disappoint the reporter and his conclusion would be that bug reporting is useless. Even when the reporter can have the fix from updates-testing using the update command pasted in the bug report by bodhi, there would be other users facing the bug complaining about buggy fedora while waiting for the fix. >From my pov I'm happy we have maintainers working hard to get fixes and features to our users. I'm fine with huge 0-day updates, because despite it's not optimal, it's still much better than having broken packages. If there are really a lot of 0-day updates it does not mean we have wrong update policy, it just means release date should be postponed > Hey, at least Kevin should be happy. well, I am happy ;) Michal --- this is my first and last post to this flamebait thread -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: F13: nouveau driver seems to swap video streams on NVIDIA NVS-290.
On Thursday, June 10, 2010 00:31:20 Charles Butterfield wrote: > I suspect the nouveau driver is swapping or mislabeling the two video > streams that the NVS-290 card generates. Here are my clues: > > Setup > - Fedora-13 and nouveau driver (latest yum updates as of midnight) > - NVIDIA NVS-290 video card > - nouveau exposes 2 outputs to XRandR (DVI-I-1 and DVI-I-2) > - The NVS-290 video card has a DMS-59 connector, with a > short DMS-59 to Dual VGA cable with VGA connectors > labeled 1 and 2. > - VGA connectors #1 and #2 are connected to monitors #1(Left) > and #2(Right). > > Behavior > 1) At boot time, before the nouveau driver is involved, the boot text is >output on the VGA connector labeled "1", which is connected to > monitor >#1 (on my left). > 2) At GDM login time, monitor #1 is clearly assigned to the right of the >Virtual screen (its right edge is "impenetrable") while monitor #2 is >on the left side. Weird, but in theory just an odd default. But > wait. > 3) Inspecting the "xrandr" output, it is clear that pixels on the > virtual >screen that are directed to "DVI-I-1" are going to monitor #2 and >vice versa (DVI-I-2 goes to monitor #1). I checked the default >situation, then flipped the two halves of the virtual screen back >and forth with xrandr, checking the xrandr status each time. > 4) The last bit of weirdness is that the xrandr geometry setting > commands >seemed reversed from what would be expected. Maybe that is the >inevitable result of mislabeling the data stream, or perhaps it is an >important clue in its own right. My head hurts at the point. > > Misc > 5) Oh yes, I buzzed out the cable, just in case it was mis-wired or >mis-labled. It's fine, that is DMS59:VGA2_RED -> VGA#2:RED, etc. > > > Please advise if this should be posted somewhere else. I guess you've hit the same bug as me, I even have the same video card. Bug was reported here: https://bugzilla.redhat.com/show_bug.cgi?id=582582 but it was closed as notabug Michal -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Non-responsive maintainer fast track procedure for libsndfile
On Tuesday, July 06, 2010 01:05:57 Orcan Ogetbil wrote: > On Mon, Jul 5, 2010 at 6:17 PM, Michel Alexandre Salim wrote: > > Hi all, > > > > I'm initiating a fast track procedure for libsndfile -- a security bug > > has been reported for over a year, and there has been no response from > > maintainer I've added patch to that bugzilla. I have all changes ready, only commit acl required :) > > We made many attempts to reach him last year. See: > https://www.redhat.com/archives/fedora-devel-list/2009-November/msg00102.ht > ml > > I asked for comaintainership on Fedora branches about 10 months ago, > and didn't hear back until now. My request is still open. "me too" but not 10 months ago If current maintainer is no longer interested in libsndfile I'm willing to become maintainer for this package. I already maintain it for rhel6 > > I ended up updating the Fedora packages, and hence closing the > security bugs with my proven powers. I didn't touch the EPEL package > since > 1- I don't even know if the force is strong enough with my proven > powers in the EPEL arena. > 2- I am basically not much interested in EPEL. > > Orcan -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Licensing Guidelines Update - Please Read
On Wednesday 07 of July 2010 22:29:01 Tom "spot" Callaway wrote: > Okay. Here's the list of packages that I think might be affected by > this. Reminder: You need to check these packages and fix any which need > fixing, then email me and let me know which ones you checked/fixed. > Thanks! > > ~spot > > [mhlavink] cyrus-imapd: cyrus-imapd-devel-2.3.16-4.fc14.x86_64 > cyrus-imapd-perl-2.3.16-4.fc14.x86_64 fixed > [mhlavink] nut: nut-hal-2.4.3-3.fc14.x86_64 nut-client-2.4.3-3.fc14.x86_64 nut-client fixed, nut-hal is false positive > [mhlavink] pciutils: pciutils-libs-3.1.6-4.fc13.x86_64 fixed -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Question regarding dist-git aesthetics with branches
On Wednesday, July 21, 2010 11:19:54 Hans Ulrich Niedermann wrote:
> On Wed, 2010-07-21 at 10:55 +0200, Hans Ulrich Niedermann wrote:
> > On Tue, 2010-07-20 at 22:15 -0700, Jesse Keating wrote:
> > > On 07/20/2010 08:55 PM, Garrett Holmstrom wrote:
> > > > Using names like f13, el5, and so forth would also keep dist-git
> > > > consistent with git branch naming conventions. If we were to do
> > > > something like that we might as well just use the value of %{dist}.
> > >
> > > That was going to be my next question, although that would bring back
> > > the "c" in fc13 and fc14 since that's what the dist value is. We could
> > > bite the bullet and change the dist value to remove the c, and just
> > > manually keep track of making sure that builds on older releases won't
> > > be "newer" than builds on the newer branches. not sure if we want to
> > > go through that pain at this point.
> >
> > Don't we have a (few) mass rebuilds in front of us before F-14 anyway?
> > gold and similar stuff? That would increase the R of N-V-R anyway, so we
> > could switch %{dist} from fc14 to f14 at the same time for probably the
> > majority of packages.
> >
> > Oh. Darn. We still need to make sure that *.fc12 and *.fc13 packages do
> > not have the same N-V-R modulo %{dist} as F14 has, until F13 is EOLed,
> > i.e. until F15 comes out. That still sounds ugly. Well, all of that is
> > ugly regarding the "c", whatever we do or do not do.
>
> Ugly potential fix for this ugly issue: Patch rpm and yum to compare
> N-V-R.fc13 exactly like N-V-R.f13, and carry that patch until F-15.
another less ugly (but still ugly) solution would be adding:
Obsoletes: N-V-R.fc13
Obsoletes: N-V-R.fc12
in koji automatically for the same NVR as the package has, but I don't know if
this would not make yum's depsolver cry
Michal
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora 14 branching and dist-git roll out
On Saturday, July 24, 2010 08:54:53 Jesse Keating wrote: > Hey all! It's that time again, we're gearing up to branch for Fedora 14 > this coming Tuesday! There is a major twist this time around, we're > going to attempt a roll out of dist-git! What we will find in git? Only rawhide? F-14? All not EOLed Fedora versions? Or everything? -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: The move to git!
On Friday 30 of July 2010 05:55:09 Jesse Keating wrote: > ... Wiki > pages will get filled out as knowledge of how to interact with dist-git > starts to spread ( https://fedoraproject.org/wiki/Using_Fedora_GIT is a > good start ). Thanks for your hard work! Could you describe this in more details: OLD CVS | NEW GIT | Notes make tag | N/A | Explicitly tagging source states for package builds is no longer necessary. how this exactly works? What will happen in following cases? : 1) commit some changes with release number change, commit another changes, build 2) commit some changes with release number change, scratch build, commit rest of the changes, build 3) commit some changes with release number change, someone else starts build, commit rest of the changes, build 4) commit some changes with release number change, build - fails because of typo/missing updated sources, commit fix, build Michal -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Schedule for Monday's FESCo Meeting (2012-06-18)
On 06/17/2012 06:06 PM, Richard Hughes wrote: On 17 June 2012 10:53, Richard W.M. Jones wrote: So this is a problem that needs to be solved, but does it require a reboot? Not really ... it's possible to list all processes using zlib, convert that back into a list of packages, then instruct those packages to restart themselves. Job done, BETTER than Windows / OS X. That's simply not possible. Some processes like dbus-daemon and gnome-session just cannot be restarted in this way. It's a complete fallacy to believe you can update core libraries on a modern Linux system without rebooting. Add btrfs snapshotting to the mix (to be able to do updates safely) and doing updates in-situ becomes impossible. If Fedora wants to statically link everything, then it's certainly possible to workaround, but that's not acceptable to Fedora for perfectly understandable reasons. 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. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Schedule for Monday's FESCo Meeting (2012-06-18)
On 06/18/2012 01:09 AM, drago01 wrote: On Mon, Jun 18, 2012 at 12:24 AM, Benny Amorsen wrote: Richard Hughes writes: It takes me 4 seconds to POST, boot the kernel, get into system-update.service, and then reboot. Using a new rpm version, applying several dozen test updates takes another 20 seconds. Your hardware is too cheap. BIOS boot time is proportional to price when the hardware was introduced. More generally, the fact that your hardware happens to boot fast does not mean that extra reboots are not a problem. If boot time is your concern we can make it (after BIOS) way faster by simply not enable lots of stuff that sits there unused after boot. Another concern is that this type of update is not always completely automatic - some users have different default options in grub like windows or different linux distro. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Schedule for Monday's FESCo Meeting (2012-06-18)
On 06/18/2012 01:22 PM, Richard Hughes wrote: On 18 June 2012 12:03, Benny Amorsen wrote: Why testing the daemons? Any daemon which cannot be restarted by systemctl restart foo.daemon is broken already. Try booting a few VMs and then doing "systemctl restart libvirtd.daemon" -- libvirtd restarts okay (hopefully) but all the clients are disconnected and all the VMs are no longer running. Restarting a daemon really means "pause, dump all in-process-stuff-to-disk, exit-cleaning-up, load-and-detect-saved-state-and-convert-if-required, un-pause" -- that's a different thing entirely to "reload". Requiring a log out is ok IMHO, if there are processes in the session still having the old library mapped after the upgrade. If there are processes which are neither daemons nor part of a session, we should probably have a good look at why. Although I agree with your last statement, if you have more than one user logged in (or use fast-user-switching), the premise of a session re-login allowing all the open applications to relink against new library versions breaks down. How is the above different from restarting a computer? If you can "aggressively" reboot computer with daemons or (different user) sessions running, you can also restart (or even stop-update-start) them all with the same effect. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
(re)starting of a daemon after package update
Hi, I'm trying to find out what is the best place to restart service after update. Dovecot have runs several binaries, has some plugins,... in short, it does not like when it's running during update. I was asked by upstream to modify rpm package to stop it before update and start it afterwards (it does try-restart in %postun now). Looks simple. I check whether it's running in %pre script, create a flag and stop it. After update, I check the flag and start it again. The problem is where to put this second script? Correct approach would be to save state before installation of new version starts and start dovecot (if flag is set) after old version is removed - that would mean %postun script. This does not seem to work on reinstall (the same version is installed) - %postun script is not executed. So I'm considering 3 options right now 1)ignore reinstall scenario 2)start dovecot in %post script - when there are all new files, but old ones were not removed yet. This can cause trouble for example if dovecot changes config files in conf.d/*.conf and some file gets renamed/removed. 3)start dovecot in %posttrans script - all files are removed, but it's after all packages are updated and old removed. It can take half to five minutes (or even more) - between dovecot is stopped and started again. Is there any other (and better) solution? Michal -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: (re)starting of a daemon after package update
On 06/20/2012 02:37 PM, Reindl Harald wrote: Am 20.06.2012 14:32, schrieb Björn Persson: Michal Hlavinka wrote: Correct approach would be to save state before installation of new version starts and start dovecot (if flag is set) after old version is removed - that would mean %postun script. This does not seem to work on reinstall (the same version is installed) - %postun script is not executed. Please also consider what happens when the new version of Dovecot requires a new version of some library. RPM will ensure that both packages are updated in the same transaction, but if I understand correctly it's not until %posttrans that you can be sure that the new library is in place. %postun is sufficient, but it's not executed on package reinstall one reason more why the cuurent behavior re-starting services on updates is simply wrong: You complained that service is restarted during update. Well, in this case, restart is not sufficient. We even have to be sure, the service is not running when there are both old and new files in place. Not restarting the service would be "simply wrong" -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: (re)starting of a daemon after package update
On 06/21/2012 11:01 PM, Reindl Harald wrote: Am 21.06.2012 22:52, schrieb Michal Hlavinka: On 06/20/2012 02:37 PM, Reindl Harald wrote: Am 20.06.2012 14:32, schrieb Björn Persson: Michal Hlavinka wrote: Correct approach would be to save state before installation of new version starts and start dovecot (if flag is set) after old version is removed - that would mean %postun script. This does not seem to work on reinstall (the same version is installed) - %postun script is not executed. Please also consider what happens when the new version of Dovecot requires a new version of some library. RPM will ensure that both packages are updated in the same transaction, but if I understand correctly it's not until %posttrans that you can be sure that the new library is in place. %postun is sufficient, but it's not executed on package reinstall one reason more why the cuurent behavior re-starting services on updates is simply wrong: You complained that service is restarted during update. Well, in this case, restart is not sufficient. We even have to be sure, the service is not running when there are both old and new files in place. Not restarting the service would be "simply wrong" is is NOT simpy wrong * i am the admin * i decide the time when a service is restarted * you have no clue what implication a restart of whatever service has in my environment you have no clue what implication a non-restarted service has There are not only one-binary-services, some services have several binaries running in the same time. For example with master process spawning worker processes. They have internal API, when old master process starts new worker expecting different API, possibly using different configuration or just old worker with updated plugin using different api... you'll get your requested disaster and it's what *I* call "simply wrong". Anyway, this discussion in this thread is off-topic. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Schedule for Monday's FESCo Meeting (2012-06-18)
On 06/22/2012 01:16 PM, Ralf Ertzinger wrote: Hi. On Fri, 22 Jun 2012 10:28:14 +0200, Nicolas Mailhot wrote: And instead of making the system adapt to system problems (inhibit reboot during updates) we're making the user adapt to system problems (add forced reboots were they were none before??) Inhibiting reboots? I cannot wait to see how well that one will go down. Well, there is difference between inhibited reboot and "are you really sure you want to reboot and break your system" questions. Anyway, what would happen when user press power button or ctrl-alt-delete in yum-update-in-extra-target case? Would it shutdown/reboot (breaking the system) or would it ignore the request? -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Orphaning apcupsd
Hi, my APC UPS died and as I won't be buying new APC UPS, I can no longer test and investigate bugs. So apcupsd is free for taking if anyone wants it. Cheers, Michal -- devel mailing list devel@lists.fedoraproject.org https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: Should MariaDB touch my.cnf in %post?
On 02/12/2013 06:46 PM, Honza Horak wrote:
Hi folks,
I'd like to share an idea related to MySQL->MariaDB move, that may be a
bit controversial. Speaking about default case in Fedora, MySQL has used
only one file at /etc/my.cnf to configure server, libraries,
command-line utilities, etc.
MariaDB uses by default /etc/my.cnf and
/etc/my.cnf.d/{client,server,..}.cnf files, while all the /etc/my.cnf.d
directory is included using !includedir statement in /etc/my.cnf.
The problem is, that after replacing MySQL with MariaDB existed my.cnf
won't get updated (uses "%config(noreplace)") and then users will be
confused by having /etc/my.cnf.d/* files, which won't be used.
Just add README file to /etc/my.cnf.d/ mentioning that /etc/my.cnf must
contain that includedir line or those file won't be used
Michal
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
