Re: F20 System Wide Change: No Default Syslog
On Tue, Jul 16, 2013 at 11:08 PM, Ding Yi Chen wrote: > Don't tell me that you have not seen people writing multiple platform > scripts like this: > > case $OS) > Windows* ) >some_windows_scripts > .. > Linux* ) >grep /var/log/messages > . > > > For them: What? Fedora 20 does not work while Fedora 19 does? Blame Fedora > then. > > And for fedora specific 3rd party scripts, now they need to add additional > check logic on their script. > Sometime that's just too much to ask. How about this idea. Before "No Defualt Syslog", systemd needs to completely replicate all functionality provided by syslog, including /var/log/messages, by default. Syslog emulation would be an option, and if people don't want it, they can still turn that option off. But by default, everyone can still grep /var/log/messages. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: F20 System Wide Change: No Default Syslog
On Tue, Jul 16, 2013 at 09:26:22PM -0700, Eric Smith wrote: > On Tue, Jul 16, 2013 at 6:13 PM, Matthew Miller > wrote: > > On Tue, Jul 16, 2013 at 08:58:40PM -0400, Ding Yi Chen wrote: > >> You still have not addressed the third party programs and scripts > >> that monitor /var/log/messages > > A) If someone is installing a program that expects this file, they can also > > install rsyslog. > > So? The same argument could be made for programs that expect the binary > journal. No it isn't. It was already said: journald is here always, rsyslog is optional. The question is: should we install optional rsyslog by default? -- Tomasz Torcz Morality must always be based on practicality. xmpp: zdzich...@chrome.pl-- Baron Vladimir Harkonnen -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: F20 System Wide Change: Change Packaging Guidelines to discourage requires into /bin and /sbin
I don't really appreciate the discussion this has started. All I had to say about this is summed up here: https://fedorahosted.org/fpc/ticket/314#comment:7 From a position of someone who works on packaging tools and someone who clashed with UsrMove several times already, this is my best shot at making Fedora a bit less broken. I won't waste any more time on this though: if the opinion of the "expert masses" and FESCO is against, you won't hear me arguing for this twice. How can we expect the same decision process that gets us break things with each new release to be able to fix them? Ales -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: F20 System Wide Change: No Default Syslog
On Tue, Jul 16, 2013 at 6:13 PM, Matthew Miller wrote: > On Tue, Jul 16, 2013 at 08:58:40PM -0400, Ding Yi Chen wrote: >> You still have not addressed the third party programs and scripts >> that monitor /var/log/messages > A) If someone is installing a program that expects this file, they can also > install rsyslog. So? The same argument could be made for programs that expect the binary journal. Eric -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: F20 System Wide Change: No Default Syslog
- Original Message - > On Tue, Jul 16, 2013 at 08:58:40PM -0400, Ding Yi Chen wrote: > > You still have not addressed the third party programs and scripts > > that monitor /var/log/messages > > A) If someone is installing a program that expects this file, they can also > install rsyslog. a) From what command they know they need to install rsyslog if they want yum -y whatprovides /var/log/messages gives no result. If I did not follow the fedora-devel, I would not know why the scripts failed. b) For user that do upgrade from backup user data/scripts->fresh install->restore data/scrips How they suppose to know that /var/log/messages is gone without checking the Release-Notes? Not everyone have time to go through all the changes. c) why add the complexity on the script when you don't have to? > > B) Fedora, RHEL, and most Red Hat derived distributions use > /var/log/messages, but not all do -- for example, Rocks (common in HPC) > breaks out syslog messages into individual files per facility. Debian and > Ubuntu? Totally diferent. (/var/log/syslog) > > So, these third-party scripts need to be flexible anyway. I don't think this > is a very strong point in the conversation. You falsely assume that: a) 3rd party developers support every operating systems under the sun, including all version of Windows, DOS and MacOS. b) 3rd party developers aware the changes c) 3rd party developers can and will diligently update their script just for Fedora. Don't tell me that you have not seen people writing multiple platform scripts like this: case $OS) Windows* ) some_windows_scripts .. Linux* ) grep /var/log/messages . For them: What? Fedora 20 does not work while Fedora 19 does? Blame Fedora then. And for fedora specific 3rd party scripts, now they need to add additional check logic on their script. Sometime that's just too much to ask. > -- > Matthew Miller ☁☁☁ Fedora Cloud Architect ☁☁☁ > -- > devel mailing list > devel@lists.fedoraproject.org > https://admin.fedoraproject.org/mailman/listinfo/devel -- Ding-Yi Chen Software Engineer Internationalization Group DID: +61 7 3514 8239 Email: dc...@redhat.com Red Hat, Asia-Pacific Pty Ltd Level 1, 193 North Quay Brisbane 4000 Office: +61 7 3514 8100 Fax: +61 7 3514 8199 Website: www.redhat.com Red Hat, Inc. Facebook: Red Hat APAC | Red Hat Japan | Red Hat Korea | JBoss APAC Twitter: Red Hat APAC | Red Hat ANZ LinkedIn: Red Hat APAC | JBoss APAC -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: F20 System Wide Change: No Default Syslog
On Tue, 2013-07-16 at 15:06 -0500, Chris Adams wrote: > Once upon a time, john.flor...@dart.biz said: > > While I'm no more important than the next guy, I'll defend the auto-pager > > feature of both git and journalctl. I love it, in fact. I'm no stranger > > to very long pipelines and sub-shells but I see nothing but benefit in not > > having to add "| less" routinely to things that are UI in nature. > > My primary objection is that I don't like things that have differing > behavior between a TTY and a pipe. One problem is if you are writing a > script to process output from something, you'll probably run the command > in a TTY to check the output, but you'll get different results. > > There are not many programs that have such TTY/pipe behavior. The only > ones that come to mind are "ps" (where output is truncated at screen > width) Indeed, I've always thought it would be wonderful if "ps" could auto-page its output when run on TTY if the output is larger/longer than a screen. It's just plain annoying to run a command, realize that the one piece of information you wanted is truncated out of the screen, and then have to run it second time with " | less" added. -- Mathieu -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: gnome-shell issue when ThinkPad T60 connected to dock with extra monitor
On Sat, Jul 13, 2013 at 9:21 AM, Dave Johansen wrote: > On Sat, Jul 13, 2013 at 8:45 AM, Matthew Miller > wrote: >> On Sat, Jul 13, 2013 at 08:05:19AM -0700, Dave Johansen wrote: >>> I have a ThinkPad T60 that I recently upgraded to Fedora 19 from >>> CentOS 6. With CentOS 6, I could connect to the dock with an extra >>> monitor connected to the VGA port just fine, but with Fedora 19 it has >>> issues. >>> >>> It used to crash when I connected it to the dock with the monitor connected: >>> https://retrace.fedoraproject.org/faf/reports/142339/ >>> https://bugzilla.redhat.com/show_bug.cgi?id=982442 >>> >>> I've updated using yum and now it doesn't crash, but I can't start any >>> programs. When I click on a program icon to launch it, nothing >>> happens. What can I do to help diagnose this issue and hopefully fix >>> it? >> >> I have no idea, but this may get better results on the user list rather than >> the devel list, now that F19 is released. >> >> https://admin.fedoraproject.org/mailman/listinfo/users > > Ok, I'll try the users list. > >> That said, what happens when you use the keyboard? Can you launch programs >> that way? Have you tried double-clicking? It's possible some arcane setting >> has carried forward (just guessing). Also, what happens if you create a new >> test user account -- does that desktop environment work fine? > > The keyboard works and I can hit Ctrl-Alt-F2 and then login and run > commands on the console. I also tried creating a new account and it > has the same issue. I also tried pressing the Windows Key and the > Activities Overview doesn't pop up like it's supposed to and the only > thing that I can get to do anything is right clicking on the desktop > and then about a minute later the setting context menu will pop up. I took a look in /var/log/messages and saw these two outputs right after connecting to the dock with second monitor connected: Jul 16 19:35:15 JohansenDev /etc/gdm/Xsession[1241]: (gnome-settings-daemon:1425): GnomeDesktop-CRITICAL **: gnome_rr_output_info_get_geometry: assertion `GNOME_IS_RR_OUTPUT_INFO (self)' failed Jul 16 19:35:15 JohansenDev /etc/gdm/Xsession[1241]: (gnome-settings-daemon:1425): GnomeDesktop-CRITICAL **: gnome_rr_output_info_get_geometry: assertion `GNOME_IS_RR_OUTPUT_INFO (self)' failed Are there any other logs I can take a look at? Or anything else I can do to help diagnose the cause of this issue? Thanks, Dave -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: F20 System Wide Change: ARM as primary Architecture
On Tue, Jul 16, 2013 at 07:33:48PM -0700, Brendan Conoboy wrote: > On 07/16/2013 07:16 PM, Matthew Garrett wrote: > >For instance, it seems to be missing both the stack protector and > >llvmpipe issues. > > Finishing scope of stack protector issue- it'll be there in a day or > so. Idea is to get upstream reports in, then link to them. Sure, I'm not saying that they're not being worked on. I'm just pointing out that the ARM tracker bug doesn't list every known ARM issue. -- Matthew Garrett | mj...@srcf.ucam.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: F20 System Wide Change: ARM as primary Architecture
On 07/16/2013 07:16 PM, Matthew Garrett wrote: On Wed, Jul 17, 2013 at 12:16:04AM +0100, Peter Robinson wrote: On Wed, Jul 17, 2013 at 12:09 AM, Matthew Miller wrote: On Tue, Jul 16, 2013 at 04:07:39PM -0700, Brendan Conoboy wrote: I don't want to move the goalposts on the ARM effort, but I think it's reasonable to expect that a list of "Known Broken/Deficient items" be available. Does such a list exist? The list of outstanding ARM bugs is tracked here: https://bugzilla.redhat.com/show_bug.cgi?id=245418 alias https://bugzilla.redhat.com/show_bug.cgi?id=ARMTracker And we're working to sure it's completely up to date, sorry but the last couple of days have been some what hectic for me in other realms. For instance, it seems to be missing both the stack protector and llvmpipe issues. Finishing scope of stack protector issue- it'll be there in a day or so. Idea is to get upstream reports in, then link to them. -- Brendan Conoboy / Red Hat, Inc. / b...@redhat.com -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: F20 System Wide Change: No Default Syslog
On Tue, Jul 16, 2013 at 07:25:10PM -0500, Andrew McNabb wrote: > On Tue, Jul 16, 2013 at 10:09:19PM +0200, Zbigniew Jędrzejewski-Szmek wrote: > > Yes, this is still the case, that plain 'systemctl' truncates unit > > names. It's a tough choice, but in this specific case it's hard to > > find a format that would work without truncation. There are two fields > > with potentially very long values (unit name and unit description). We > > can let the second one flow in the right side, but if we left the first > > one in full width, on normal terminal width of ~100 columns, even this > > *first* column would not fit. And the truth is that the units which > > are usually truncated are the device units (they tend to have the longest > > names), and they are not the most interesting usually. So in this case > > truncation makes it much nicer to look at the interesting .service > > and .target units. Truncation has been removed from a few other places, > > but in this case it just doesn't seem feasible. > > The "..." in the middle of the line makes the output completely > unusable. That might be a bit of an exagerration, no? > On my current machine, I see 6 service units whose names are > middle-truncated (it's not just device units). The problem is that > there's no way to scroll or adjust the terminal size to get the full > output. I would much rather have the description field completely > omitted or at least extend off to the right (it's much less essential > than the service name anyway). Hey, it's pretty straighforward code in http://cgit.freedesktop.org/systemd/systemd/tree/src/systemctl/systemctl.c#n314. If you can design a better way to split available columns, go for it. Zbyszek -- they are not broken. they are refucktored -- alxchk -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: F20 System Wide Change: ARM as primary Architecture
On Wed, Jul 17, 2013 at 12:16:04AM +0100, Peter Robinson wrote: > On Wed, Jul 17, 2013 at 12:09 AM, Matthew Miller > wrote: > > On Tue, Jul 16, 2013 at 04:07:39PM -0700, Brendan Conoboy wrote: > >> >I don't want to move the goalposts on the ARM effort, but I think it's > >> >reasonable to expect that a list of "Known Broken/Deficient items" be > >> >available. Does such a list exist? > >> The list of outstanding ARM bugs is tracked here: > >> https://bugzilla.redhat.com/show_bug.cgi?id=245418 > > > > alias https://bugzilla.redhat.com/show_bug.cgi?id=ARMTracker > > And we're working to sure it's completely up to date, sorry but the > last couple of days have been some what hectic for me in other realms. For instance, it seems to be missing both the stack protector and llvmpipe issues. -- Matthew Garrett | mj...@srcf.ucam.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: More unhelpful update descriptions
On 6/29/13, T.C. Hollingsworth > Perhaps the real fix here would be to just remove that placeholder > text (and double-check that the bodhi CLI rejects updates with blank > descriptions)? Personally I just find it really annoying to have to > backspace that out and fill in proper information every time I use > `fedpkg update`. It would make a lot more sense to me if it were just > blank and screamed bloody murder if it's not filled out. Nobody had anything bad (or good) to say about this, so I went ahead and sent a patch to fedpkg that does this: https://fedorahosted.org/fedpkg/ticket/7 Also, I wrote a bodhi patch that rejects updates with the placeholder text, in case fedpkg doesn't get fixed for awhile and so it still gets rejected even with older fedpkgs: https://fedorahosted.org/bodhi/ticket/730 -T.C. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: F20 System Wide Change: No Default Syslog
On Tue, 16.07.13 20:58, Ding Yi Chen (dc...@redhat.com) wrote: > > > He/She will be very frustrated if he/she cannot find it. > > > > This is not really an argument, or it is valid for any changes. > > What about the switch from up2date to yum years ago? I know, I first > > tried > > to run up2date before being shout at that it's normal it does not work > > anymore since yum is there. What about the future change from yum to > > dnf? > > Should we try to keep both in place just because google has more > > reference > > to yum? > > > > So, the fact that tutorials and blogs are mentioning /var/log/messages > > is > > not a valid argument :) > > You still have not addressed the third party programs and scripts > that monitor /var/log/messages As mentioned before, if people run programs that require /var/log/messages they should simply install rsyslog and be done with it. Lennart -- Lennart Poettering - Red Hat, Inc. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: F20 System Wide Change: No Default Syslog
On Tue, Jul 16, 2013 at 08:58:40PM -0400, Ding Yi Chen wrote: > You still have not addressed the third party programs and scripts > that monitor /var/log/messages A) If someone is installing a program that expects this file, they can also install rsyslog. B) Fedora, RHEL, and most Red Hat derived distributions use /var/log/messages, but not all do -- for example, Rocks (common in HPC) breaks out syslog messages into individual files per facility. Debian and Ubuntu? Totally diferent. (/var/log/syslog) So, these third-party scripts need to be flexible anyway. I don't think this is a very strong point in the conversation. -- Matthew Miller ☁☁☁ Fedora Cloud Architect ☁☁☁ -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: F20 System Wide Change: No Default Syslog
- Original Message - > On 07/16/2013 02:56 AM, Ding Yi Chen wrote: > >> Also, most > >> >distributions do include it in some way or another, and you do not need > >> >to boot systemd to use to it access your journal files. > > Not true, > > RHEL 6 and its friends do not include journalctl. > > So if I want to cover both Fedora default and RHEL default, > > now I do have to look at two places instead of one. > > Or simply install rsyslog or syslog-ng and afaik you cant run rsyslog on > AIX so same logic applies there and any other log solution are not > available cross linux distros and cross another os. AIX has logger, which outputs to /var/log/messages http://pic.dhe.ibm.com/infocenter/aix/v6r1/index.jsp?topic=%2Fcom.ibm.aix.cmds%2Fdoc%2Faixcmds3%2Flogger.htm Regards, -- Ding-Yi Chen Software Engineer Internationalization Group DID: +61 7 3514 8239 Email: dc...@redhat.com Red Hat, Asia-Pacific Pty Ltd Level 1, 193 North Quay Brisbane 4000 Office: +61 7 3514 8100 Fax: +61 7 3514 8199 Website: www.redhat.com Red Hat, Inc. Facebook: Red Hat APAC | Red Hat Japan | Red Hat Korea | JBoss APAC Twitter: Red Hat APAC | Red Hat ANZ LinkedIn: Red Hat APAC | JBoss APAC -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: F20 System Wide Change: No Default Syslog
- Original Message - > On , Ding Yi Chen wrote: > > Even if you do, you cannot change the exist tutorial, blog, and forums > > that > > refer /var/log/messages. > > > > Image the following scenario: > > Suppose a Fedora newbie (or linux newbie) encounters a problem, > > most of the search results state: Check /var/log/messages > > > > He/She will be very frustrated if he/she cannot find it. > > This is not really an argument, or it is valid for any changes. > What about the switch from up2date to yum years ago? I know, I first > tried > to run up2date before being shout at that it's normal it does not work > anymore since yum is there. What about the future change from yum to > dnf? > Should we try to keep both in place just because google has more > reference > to yum? > > So, the fact that tutorials and blogs are mentioning /var/log/messages > is > not a valid argument :) You still have not addressed the third party programs and scripts that monitor /var/log/messages -- Ding-Yi Chen Software Engineer Internationalization Group DID: +61 7 3514 8239 Email: dc...@redhat.com Red Hat, Asia-Pacific Pty Ltd Level 1, 193 North Quay Brisbane 4000 Office: +61 7 3514 8100 Fax: +61 7 3514 8199 Website: www.redhat.com Red Hat, Inc. Facebook: Red Hat APAC | Red Hat Japan | Red Hat Korea | JBoss APAC Twitter: Red Hat APAC | Red Hat ANZ LinkedIn: Red Hat APAC | JBoss APAC -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: F20 System Wide Change: No Default Syslog
On Tue, Jul 16, 2013 at 10:09:19PM +0200, Zbigniew Jędrzejewski-Szmek wrote: > Yes, this is still the case, that plain 'systemctl' truncates unit > names. It's a tough choice, but in this specific case it's hard to > find a format that would work without truncation. There are two fields > with potentially very long values (unit name and unit description). We > can let the second one flow in the right side, but if we left the first > one in full width, on normal terminal width of ~100 columns, even this > *first* column would not fit. And the truth is that the units which > are usually truncated are the device units (they tend to have the longest > names), and they are not the most interesting usually. So in this case > truncation makes it much nicer to look at the interesting .service > and .target units. Truncation has been removed from a few other places, > but in this case it just doesn't seem feasible. The "..." in the middle of the line makes the output completely unusable. On my current machine, I see 6 service units whose names are middle-truncated (it's not just device units). The problem is that there's no way to scroll or adjust the terminal size to get the full output. I would much rather have the description field completely omitted or at least extend off to the right (it's much less essential than the service name anyway). -- Andrew McNabb http://www.mcnabbs.org/andrew/ PGP Fingerprint: 8A17 B57C 6879 1863 DE55 8012 AB4D 6098 8826 6868 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: anaconda / initial-setup / gnome-initial-setup: can we do this better?
On Mon, 2013-07-15 at 22:26 +0100, David Woodhouse wrote: > > Thanks. Delayed response... I've finally got everything else working > nicely on Fedora 19 and I'm looking at this. I see firstboot is still > available, but it doesn't seem to *work*. > > First it wants python-ethtool to be installed but didn't have the > appropriate dependency, and then it's still using pygtk while my own > code has been updated to pygobject and gtk3. (Which was done because > some other code I was *importing* had been upgraded, so I couldn't mix > the two. I don't think you get far with pygtk these days, do you?) > > So I'm guessing that it's probably not worth looking at firstboot any > harder, and I should proceed straight to using initial-setup. FWIW after working around bug 984932 by making my *own* package depend on the packages that firstboot should have required for itself, and after downgrading my UI code from Gtk3 to pygtk2 (which required that I stop using pyanaconda.users), I now have a firstboot module that works. I'd still like to convert it to initial-setup at some point, but it's working for now. -- dwmw2 smime.p7s Description: S/MIME cryptographic signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: F20 System Wide Change: ARM as primary Architecture
On Wed, Jul 17, 2013 at 12:09 AM, Matthew Miller wrote: > On Tue, Jul 16, 2013 at 04:07:39PM -0700, Brendan Conoboy wrote: >> >I don't want to move the goalposts on the ARM effort, but I think it's >> >reasonable to expect that a list of "Known Broken/Deficient items" be >> >available. Does such a list exist? >> The list of outstanding ARM bugs is tracked here: >> https://bugzilla.redhat.com/show_bug.cgi?id=245418 > > alias https://bugzilla.redhat.com/show_bug.cgi?id=ARMTracker And we're working to sure it's completely up to date, sorry but the last couple of days have been some what hectic for me in other realms. Peter -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: F20 System Wide Change: ARM as primary Architecture
On Tue, Jul 16, 2013 at 10:55 PM, Adam Williamson wrote: > On Mon, 2013-07-15 at 22:42 +0100, Peter Robinson wrote: >> On Thu, Jul 11, 2013 at 8:53 PM, Adam Williamson wrote: >> > On Thu, 2013-07-11 at 09:17 +, "Jóhann B. Guðmundsson" wrote: >> > >> >> > I'm afraid I can't agree. I like the simplicity of the model you're >> >> > proposing, but from a practical point of view, there is still a commonly >> >> > held perception that there is a 'product' called Fedora which is >> >> > basically composed of what you get if you go to get.fedoraproject.org, >> >> > download one of the things we push at you there, and install it. >> >> > Practically speaking, I believe we have to QA that 'thing called Fedora' >> >> > as a whole. I don't think your model quite matches what people perceive >> >> > Fedora to be. >> >> >> >> What's your definition of what people perceive Fedora to be? >> > >> > "What do we talk about when we talk about Fedora?" :) >> > >> > Well, we just did a major release. Go look on news.google.com for >> > "Fedora 19", or search for "Fedora 19 review", or just poke through a >> > few popular tech sites and forums. >> > >> > What do people do when they want to 'try Fedora 19'? They download the >> > primary image on the download page, which is the desktop live, and run >> > it. This is what they've _always_ done. >> >> Hmm I wouldn't be surprised if we had more Fedora users running on >> cloud instances now than we do on the desktop but there's no way to >> tell really. > > Might be the sites I'm reading, but I have yet to see a single post > anywhere even mentioning the cloud image, while I've replied to dozens > of posts of people testing the desktop live. Well it's live on at least amazon and rackspace so who would know Peter -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: F20 System Wide Change: ARM as primary Architecture
On Tue, Jul 16, 2013 at 04:07:39PM -0700, Brendan Conoboy wrote: > >I don't want to move the goalposts on the ARM effort, but I think it's > >reasonable to expect that a list of "Known Broken/Deficient items" be > >available. Does such a list exist? > The list of outstanding ARM bugs is tracked here: > https://bugzilla.redhat.com/show_bug.cgi?id=245418 alias https://bugzilla.redhat.com/show_bug.cgi?id=ARMTracker -- Matthew Miller ☁☁☁ Fedora Cloud Architect ☁☁☁ -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: F20 System Wide Change: ARM as primary Architecture
On 07/16/2013 11:36 AM, Bill Nottingham wrote: Well, what else is broken? It's a matter of approach - you seem to be saying "what are the minimum requirements, listed so that we can meet them". In terms of a minimum viable platform, for all its faults, the interfaces specified by the LSB might be a worthwhile starting point. But even in that case... if an arch implemented the entire LSB, and 90% of the rest of the distribution did not build, that's obviously not good enough. So I'm more in favor of "tell us what you don't have, and we can discuss whether that's good enough." I don't want to move the goalposts on the ARM effort, but I think it's reasonable to expect that a list of "Known Broken/Deficient items" be available. Does such a list exist? The list of outstanding ARM bugs is tracked here: https://bugzilla.redhat.com/show_bug.cgi?id=245418 -- Brendan Conoboy / Red Hat, Inc. / b...@redhat.com -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: F20 System Wide Change: Visible Cloud
On Tue, Jul 16, 2013 at 03:14:24PM -0700, Adam Williamson wrote: > > But yes, adding potentially-release-blocking criteria is part of the plan. > Who will be working on this, what is the time frame, and what will they > be? Me, as change proposal owner, working with the QA team, I hope including you. (Isn't this why we have these change proposal pages?) Timeframe is F20. I'm expecting we'll start reasonably small for this release, probably starting with the existing EC2 validation testcase (https://fedoraproject.org/wiki/QA:Testcase_EC2_AMI_Validation) and maybe adding one for OpenStack as well. -- Matthew Miller ☁☁☁ Fedora Cloud Architect ☁☁☁ -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: F20 System Wide Change: Change Packaging Guidelines to discourage requires into /bin and /sbin
On Tue, Jul 16, 2013 at 10:22:01PM +0200, Reindl Harald wrote: > /bin/sh is *not* a bash script > /bin/sh is *whatever* your default shell would be Says who or what? I think we're _probably_ striving to be functionally compatible with the Posix standard whereby 'sh' follows this specification: http://pubs.opengroup.org/onlinepubs/009695399/utilities/xcu_chap02.html That's not bash, but bash does in fact strive to be (at least mostly) compatible when called as sh. By that standard, by the way, the location doesn't need to be fixed at /bin/sh. But, I think we'd be doing some seriously quixotic work to patch everything for a pretty low return. -- Matthew Miller ☁☁☁ Fedora Cloud Architect ☁☁☁ -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: F20 System Wide Change: Visible Cloud
On Mon, 2013-07-15 at 13:35 -0400, Matthew Miller wrote: > On Mon, Jul 15, 2013 at 11:55:09AM -0500, Bruno Wolff III wrote: > > >With Fedora 19's First Class Cloud Images feature [1], we have Amazon EC2 > > >and > > >downloadable cloud images (in qcow2 and raw.xz format) produced and > > >released > > >together with the traditional desktop installer and and livecd images. Now, > > >let's go to the next level and present the cloud images as equal options. > > Are problems with these images going to block releases? > > Ideally, that will never happen. :) > > But yes, adding potentially-release-blocking criteria is part of the plan. Who will be working on this, what is the time frame, and what will they be? -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora http://www.happyassassin.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: dracut hang in %posttrans of Rawhide kernel install?
On Tue, Jul 16, 2013 at 4:07 PM, Dan Mashal wrote: > I just upgraded to rawhide with 3.11.0-0.rc0.git7.1.fc20. I didnt get > any issues with dracut but Fedora would not boot. I am currently on > 3.10.0-0.rc7.git0.2.fc20: > > No dracut or post trans errors when upgrading to this: > > Dependencies Resolved > > > > Package Arch Version > Repository > > Size > > > Installing: > kernel x86_64 3.11.0-0.rc0.git7.1.fc20 rawhide > 31 M > kernel-devel x86_64 3.11.0-0.rc0.git7.1.fc20 rawhide > 8.4 M > > I'll try and build the kernel manually and report back. > On my Rawhide VMs, both x86_64 and i686, attempting to boot that kernel results in immediate 100% CPU usage. Nothing interesting happens if I left it go for a few minutes. On the other hand, the previous kernel, 3.11.0-0.rc0.git3.1.fc20, does boot normally. I haven't yet gotten around to checking for a bugzilla report on the newer kernel. -- Jerry James http://www.jamezone.org/ -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: dracut hang in %posttrans of Rawhide kernel install?
On Sat, Jul 13, 2013 at 12:09 AM, Adam Williamson wrote: > Hey, folks - I have my desktop on Rawhide now, and on trying to install > the latest kernel build from Koji today - > http://koji.fedoraproject.org/koji/buildinfo?buildID=433327 - the yum > process seemed to hang indefinitely at ' Cleanup: > kernel-3.10.0-1.fc20.x86_64 3/3' . I > saw several stuck dracut processes: > > root 22006 0.0 0.0 113752 2188 pts/0S+ Jul12 > 0:00 /bin/bash /sbin/dracut > -f /boot/initramfs-3.11.0-0.rc0.git7.1.fc20.x86_64.img > 3.11.0-0.rc0.git7.1.fc20.x86_64 > > all that same command, apparently spawned by: > > root 21986 0.0 0.0 113316 1720 pts/0S+ Jul12 > 0:00 /bin/bash /sbin/new-kernel-pkg --package kernel --mkinitrd --dracut > --depmod --update 3.11.0-0.rc0.git7.1.fc20.x86_64 > > I left them for several hours, none ever finished. Then I kill'ed them > all - kill -9 was not necessary - and the yum process completed, > complaining of: > > /sbin/dracut: line 871: /etc/crypttab: No such file or directory > /sbin/new-kernel-pkg: line 496: 22006 Terminated $tool > mkinitrd failed > warning: %posttrans(kernel-3.11.0-0.rc0.git7.1.fc20.x86_64) scriptlet > failed, exit status 1 > Non-fatal POSTTRANS scriptlet failure in rpm package > kernel-3.11.0-0.rc0.git7.1.fc20.x86_64 > > and indeed, no initramfs existed for the new kernel. > > Has anyone else seen this? Any ideas on the cause, for a bug report? I just upgraded to rawhide with 3.11.0-0.rc0.git7.1.fc20. I didnt get any issues with dracut but Fedora would not boot. I am currently on 3.10.0-0.rc7.git0.2.fc20: No dracut or post trans errors when upgrading to this: Dependencies Resolved Package Arch Version Repository Size Installing: kernel x86_64 3.11.0-0.rc0.git7.1.fc20 rawhide 31 M kernel-devel x86_64 3.11.0-0.rc0.git7.1.fc20 rawhide 8.4 M I'll try and build the kernel manually and report back. Dan -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
[licensing] python yolk license changed from GPLv2 to BSD
Hi, i'm updating yolk from 0.4.1 to 0.4.3 which brings a license change: GPLv2 to BSD. The new license is the new BSD variant aka BSD 3 clauses (no advertising) aka "kosher BSD" (compatible with GPLv2+) According repoquery, no other packages requires it, just let me know if it matters to you. Best regards, H. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: F20 System Wide Change: ARM as primary Architecture
On Mon, 2013-07-15 at 22:42 +0100, Peter Robinson wrote: > On Thu, Jul 11, 2013 at 8:53 PM, Adam Williamson wrote: > > On Thu, 2013-07-11 at 09:17 +, "Jóhann B. Guðmundsson" wrote: > > > >> > I'm afraid I can't agree. I like the simplicity of the model you're > >> > proposing, but from a practical point of view, there is still a commonly > >> > held perception that there is a 'product' called Fedora which is > >> > basically composed of what you get if you go to get.fedoraproject.org, > >> > download one of the things we push at you there, and install it. > >> > Practically speaking, I believe we have to QA that 'thing called Fedora' > >> > as a whole. I don't think your model quite matches what people perceive > >> > Fedora to be. > >> > >> What's your definition of what people perceive Fedora to be? > > > > "What do we talk about when we talk about Fedora?" :) > > > > Well, we just did a major release. Go look on news.google.com for > > "Fedora 19", or search for "Fedora 19 review", or just poke through a > > few popular tech sites and forums. > > > > What do people do when they want to 'try Fedora 19'? They download the > > primary image on the download page, which is the desktop live, and run > > it. This is what they've _always_ done. > > Hmm I wouldn't be surprised if we had more Fedora users running on > cloud instances now than we do on the desktop but there's no way to > tell really. Might be the sites I'm reading, but I have yet to see a single post anywhere even mentioning the cloud image, while I've replied to dozens of posts of people testing the desktop live. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora http://www.happyassassin.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: F20 System Wide Change: Change Packaging Guidelines to discourage requires into /bin and /sbin
Once upon a time, Reindl Harald said: > Am 16.07.2013 22:18, schrieb Chris Adams: > > #!/bin/sh is the cannonical first line for a Bourne(-compatible) shell > > script, and nothing should change that. Even on other Unix OSes with a > > /bin->/usr/bin symlink, all the shell scripts referenced /bin/sh > > /bin/sh is *not* a bash script I said nothing about bash. > /bin/sh is *whatever* your default shell would be No, /bin/sh is a Bourne compatible shell. Your default shell may be bash, ksh, tcsh, etc., not all of which are Bourne compatible. /bin/sh is a Bourne-compatible shell for running scripts. -- Chris Adams -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: F20 System Wide Change: Change Packaging Guidelines to discourage requires into /bin and /sbin
On Tue, 2013-07-16 at 14:31 -0600, Eric Smith wrote: > On Tue, Jul 16, 2013 at 2:22 PM, Reindl Harald wrote: > > /bin/sh is *not* a bash script > > /bin/sh is *whatever* your default shell would be > > I certainly hope not. I've worked on plenty of Unix machines where > the default shell was csh or tcsh, but if /bin/sh had been csh or a > link to it, all hell would have broken loose. > > /bin/sh had bloody well better be something that is compatible with > the Bourne shell. > > Eric On F17, and on the last solaris I used (5 years ago), /bin/sh was a link and has been one for many years in Unix land. For example on my system right now: ls -al /bin/sh lrwxrwxrwx. 1 root root 4 Mar 18 11:28 /bin/sh -> bash -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: F20 System Wide Change: No Default Syslog
Am 16.07.2013 22:02, schrieb Simo Sorce: > On Tue, 2013-07-16 at 21:50 +0200, Reindl Harald wrote: >> Am 16.07.2013 21:45, schrieb john.flor...@dart.biz: From: h.rei...@thelounge.net i am *strictly* against all this truncate and autopaging and for me "GIT does the same" is no argument - a mistake is not better because others do the same. if i want paging i do " | less" or " | more" *this* is the unix way of work but who am i... >>> While I'm no more important than the next guy, I'll defend the auto-pager >>> feature of both git and journalctl. I >>> love it, in fact. I'm no stranger to very long pipelines and sub-shells >>> but I see nothing but benefit in not >>> having to add "| less" routinely to things that are UI in nature. These >>> auto-pagers get out of the way immediately >>> if you need a pipeline, so what's the harm? In fact, you can still >>> "journalctl | less" or the like if you really >>> want to. >> >> you could also do >> alias journalctl="journalctl | less" >> to achive the same >> >> hence my konsole has scrollbars, i do not like autopaging and whatever >> is not pure unix because there are mechs to achieve whatever you need >> and with GIt and systemctl/journalctl whe have a inconsistent behavior >> >> in any case *truncate* outputs is a absolutely no-go >> >> the ordinary user does not look at all this things and the >> advanced which have a reson to look get stripped informations > > alias journalctl='journalctl --no-pager' > an live happy and now explain me why i should need to set aliases for random commands to achieve the well known default which has any over decades known unix tool? * if you want a non-standard behavior set a alias * if you want the standard behavior do nothing what here happens is make the exception to a standard for a consistent system behavior you would need to patch ls, cat, dir, whatever and *then* explain people this is the standard and they need aliases for all of them - the wrong direction my friend signature.asc Description: OpenPGP digital signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: F20 System Wide Change: Change Packaging Guidelines to discourage requires into /bin and /sbin
On Tue, Jul 16, 2013 at 2:22 PM, Reindl Harald wrote: > /bin/sh is *not* a bash script > /bin/sh is *whatever* your default shell would be I certainly hope not. I've worked on plenty of Unix machines where the default shell was csh or tcsh, but if /bin/sh had been csh or a link to it, all hell would have broken loose. /bin/sh had bloody well better be something that is compatible with the Bourne shell. Eric -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
[perl-Package-Stash-XS] Update to 0.28
commit d3a39fbcd309e185c5aa0211c0b48aaecc9837e0
Author: Paul Howarth
Date: Tue Jul 16 21:29:48 2013 +0100
Update to 0.28
- New upstream release 0.28
- Fix test issue
Package-Stash-XS-0.27-test-XS.patch | 15 ---
perl-Package-Stash-XS.spec | 10 +-
sources |2 +-
3 files changed, 6 insertions(+), 21 deletions(-)
---
diff --git a/perl-Package-Stash-XS.spec b/perl-Package-Stash-XS.spec
index a086607..3218e73 100644
--- a/perl-Package-Stash-XS.spec
+++ b/perl-Package-Stash-XS.spec
@@ -1,5 +1,5 @@
Name: perl-Package-Stash-XS
-Version: 0.27
+Version: 0.28
Release: 1%{?dist}
Summary: Faster and more correct implementation of the Package::Stash API
Group: Development/Libraries
@@ -7,7 +7,6 @@ License:GPL+ or Artistic
URL: http://search.cpan.org/dist/Package-Stash-XS/
Source0:
http://search.cpan.org/CPAN/authors/id/D/DO/DOY/Package-Stash-XS-%{version}.tar.gz
Patch1:Package-Stash-XS-0.27-old-Test::More.patch
-Patch4:Package-Stash-XS-0.27-test-XS.patch
BuildRoot: %{_tmppath}/%{name}-%{version}-%{release}-root-%(id -nu)
BuildRequires: perl >= 3:5.8.1
BuildRequires: perl(base)
@@ -48,9 +47,6 @@ installed, and should be preferred in all environments with a
compiler.
%prep
%setup -q -n Package-Stash-XS-%{version}
-# Avoid need for base Package::Stash package (Github Pull #1)
-%patch4
-
# Patch test suite to work with old Test::More versions if necessary
%if "%{?rhel}" == "5"
%patch1 -p1
@@ -85,6 +81,10 @@ rm -rf %{buildroot}
%{_mandir}/man3/Package::Stash::XS.3pm*
%changelog
+* Tue Jul 16 2013 Paul Howarth - 0.28-1
+- Update to 0.28
+ - Fix test issue
+
* Tue Jul 16 2013 Paul Howarth - 0.27-1
- Update to 0.27
- Handle magic more correctly in add_symbol and get_or_add_symbol
diff --git a/sources b/sources
index 9a28e99..c03d33e 100644
--- a/sources
+++ b/sources
@@ -1 +1 @@
-738b4afe0554b43368e743284803176c Package-Stash-XS-0.27.tar.gz
+9664356ec3be02626cbd3081ec246b70 Package-Stash-XS-0.28.tar.gz
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-de...@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel
Re: F20 System Wide Change: Change Packaging Guidelines to discourage requires into /bin and /sbin
On Tue, 2013-07-16 at 12:18 -0700, Toshio Kuratomi wrote:
> I think that the best course of action would to rethink UsrMove as
> UsrMerge which I would then take to the rest of the FPC as getting rid of
> the prohibition on packages listing /bin, /sbin/ lib, /lib64 as the location
> in the file.
Yes.
> * Have package maintainers patch upstreams to use /usr/{bin,lib,[..]}
> instead of /{bin,lib[...]} (for instance, shebang lines)
This is extreme, almost entirely pointless busywork. The cost of
the /bin -> usr/bin symbolic link on the filesystem is very very small.
Let me phrase it this way: I doubt anyone can come up with a workload
where the symlink traversal is a measurable part of a real application.
Particularly when compared to the other inefficiencies and outright
buggy crap[1] in the vast swaths of even core userspace.
> * Have packages which traditionally provide /{bin,sbin,possibly lib but
> I can't think of something in /lib that's actually causing breakage}
> create Virtual Provides for those older file paths.
Or again, have RPM synthesize them automatically if the build
environment has that magical rpmlib(X-Something) that I can't find in a
quick search.
[1] Some of that buggy crap is my code; it makes more sense for me to
spend scarce engineering time on fixing issues that affect actual real
world scenarios than to go on a global search and replace for /bin
-> /usr/bin and dealing with the fallout when I later need to backport
something to RHEL6 for example. Same applies to everyone else.
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
File Package-Stash-XS-0.28.tar.gz uploaded to lookaside cache by pghmcfc
A file has been added to the lookaside cache for perl-Package-Stash-XS: 9664356ec3be02626cbd3081ec246b70 Package-Stash-XS-0.28.tar.gz -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-de...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
Re: F20 System Wide Change: Change Packaging Guidelines to discourage requires into /bin and /sbin
Am 16.07.2013 22:18, schrieb Chris Adams:
> Once upon a time, Toshio Kuratomi said:
>> * Have package maintainers patch upstreams to use /usr/{bin,lib,[..]}
>> instead of /{bin,lib[...]} (for instance, shebang lines)
>
> #!/bin/sh is the cannonical first line for a Bourne(-compatible) shell
> script, and nothing should change that. Even on other Unix OSes with a
> /bin->/usr/bin symlink, all the shell scripts referenced /bin/sh
/bin/sh is *not* a bash script
/bin/sh is *whatever* your default shell would be
/bin/bash would be the first line of a *bash*-script
if you work with your bash-scripts on a machine where
„/bin/sh“ -> „bash“ is „/bin/sh“ -> „dash“ you would
notice the difference.
signature.asc
Description: OpenPGP digital signature
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Re: F20 System Wide Change: No Default Syslog
Am 16.07.2013 22:10, schrieb Lennart Poettering: > No you can't really. The auto-paging is smarter than you might > think. For example, "journalctl -e" can only really work if we spawn the > pager ourselves, and there's more like that. > > But anyway, the auto-paging thing is going to stay, you can talk about > it as much as you want. Why? Simply because *I* love it. It's one > awesome feature. You are welcome to disagree, but discussing this forth > and back on fedora-devel is highly unlikely to change my mind on > this. As long as I maintain it, this one feature definitely stays > in. Sorry for that! and if everybody starts to introduce random behavior instead respect well known standards becaus he loves it we end in a completly mess because *everything* behaves different signature.asc Description: OpenPGP digital signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: F20 System Wide Change: No Default Syslog
Am 16.07.2013 22:10, schrieb john.flor...@dart.biz: >> From: h.rei...@thelounge.net >> >> Am 16.07.2013 21:45, schrieb john.flor...@dart.biz: >> >> From: h.rei...@thelounge.net >> >> >> >> i am *strictly* against all this truncate and autopaging and for >> >> me "GIT does the same" is no argument - a mistake is not better >> >> because others do the same. >> >> >> >> if i want paging i do " | less" or " | more" >> >> *this* is the unix way of work >> >> >> >> but who am i... >> >> >> > While I'm no more important than the next guy, I'll defend the >> auto-pager feature of both git and journalctl. I >> > love it, in fact. I'm no stranger to very long pipelines and sub- >> shells but I see nothing but benefit in not >> > having to add "| less" routinely to things that are UI in nature. >> These auto-pagers get out of the way immediately >> > if you need a pipeline, so what's the harm? In fact, you can >> still "journalctl | less" or the like if you really >> > want to. >> >> you could also do >> alias journalctl="journalctl | less" >> to achive the same > > Of course I could ... just as easily as you can set the systemd/git pager env > variables, or aliases to pipe thru cat and tomorrow a, b and c comes also with autopaging/truncate and the next day d only with trunacte but no autopaging and you have to read manpages for any random command to look how behave anything you type in a terminal the same way shiny new world... signature.asc Description: OpenPGP digital signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: F20 System Wide Change: Change Packaging Guidelines to discourage requires into /bin and /sbin
Am 16.07.2013 22:07, schrieb Toshio Kuratomi:
> On Tue, Jul 16, 2013 at 09:25:37PM +0200, Reindl Harald wrote:
>>
>>
>> Am 16.07.2013 21:18, schrieb Toshio Kuratomi:
>>> I think that the best course of action would to rethink UsrMove as
>>> UsrMerge which I would then take to the rest of the FPC as getting rid of
>>> the prohibition on packages listing /bin, /sbin/ lib, /lib64 as the location
>>> in the file. The caveats of package maintainers having to think in terms of
>>> the dependencies and canonical locations instead of whether it was symlinked
>>> on the path on their own system would still apply.
>>>
>>> Posible alternatives for FPC to consider if FESCo decides we really want to
>>> think in terms of /usr/{bin,sbin,[..]} being the canonical correct place and
>>> in the distant future, /bin might go away:
>>>
>>> * Have package maintainers patch upstreams to use /usr/{bin,lib,[..]}
>>> instead of /{bin,lib[...]} (for instance, shebang lines)
>>
>> if UsrMove would have been planned properly RPM/rpmbuild would
>> have the capabilities ot fix this at the buildtime instead
>> insist that anybody rewrites and patches anything
>>
> This is not a rpm or rpmbuild issue
tell that yum and RPM with *repeatly* broken deps
of packages which used "/usr/sbin/ldconfig" what
is the *correct* real path after UsrMove and made
more than once troubles at a random time
translate "Requires: /bin/whatever" to "Requires: /usr/bin/whatever"
translate "Provides: /bin/whatever" to "Provides: /usr/bin/whatever"
and you are done for a lot of cases
__
i have the following in a meta-package on any machine since
a year and all this troubles have stopped from one moment
to the next which must not be needed on a overall consistent
environment
Provides: /bin/perl
Provides: /usr/sbin/ldconfig
signature.asc
Description: OpenPGP digital signature
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Re: F20 System Wide Change: No Default Syslog
On Tue, 16.07.13 15:06, Chris Adams (li...@cmadams.net) wrote: > Once upon a time, john.flor...@dart.biz said: > > While I'm no more important than the next guy, I'll defend the auto-pager > > feature of both git and journalctl. I love it, in fact. I'm no stranger > > to very long pipelines and sub-shells but I see nothing but benefit in not > > having to add "| less" routinely to things that are UI in nature. > > My primary objection is that I don't like things that have differing > behavior between a TTY and a pipe. One problem is if you are writing a > script to process output from something, you'll probably run the command > in a TTY to check the output, but you'll get different results. > > There are not many programs that have such TTY/pipe behavior. The only > ones that come to mind are "ps" (where output is truncated at screen > width) and "ls" (where "--color=tty" changes between TTY and pipe). The > ls behavior makes sense (and doesn't change the information displayed, > formatting, etc.); the "ps" behavior is annoying. I guess "man" has > similar auto-pager behavior to systemctl/journalctl (although IMHO man > is a different type of thing, since it is a documentation reader). ls, ps, man, git, wget, gcc, grep, pstree, bash, lsblk, lslocks, ... And this is where I got bored and stopped looking. > We already have pipes, and anyone that knows how to use a Unix shell > knows how to use them. IMHO it is extra complication (and code > duplication) for programs to change behavior between a TTY and a pipe, > unless there are specific things that can't easily be accomplished with > a simple pipe (such as "ls --color=tty"). Pagination, truncation, etc. > are easy using pipes, and should not be done in regular programs. But anyway, this subthread is pointless. You won't convince me that auto-paging is awful, you can just drop the thread entirely, it's pointless. Lennart -- Lennart Poettering - Red Hat, Inc. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: F20 System Wide Change: No Default Syslog
On Tue, Jul 16, 2013 at 2:06 PM, Chris Adams wrote: > I don't like things that have differing > behavior between a TTY and a pipe. I don't either, but that battle was lost many years ago with the 'ls' command, which defaults to columnar output to a tty but not to a pipe. Eric -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: F20 System Wide Change: Change Packaging Guidelines to discourage requires into /bin and /sbin
Once upon a time, Toshio Kuratomi said:
> * Have package maintainers patch upstreams to use /usr/{bin,lib,[..]}
> instead of /{bin,lib[...]} (for instance, shebang lines)
#!/bin/sh is the cannonical first line for a Bourne(-compatible) shell
script, and nothing should change that. Even on other Unix OSes with a
/bin->/usr/bin symlink, all the shell scripts referenced /bin/sh.
--
Chris Adams
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Re: F20 System Wide Change: No Default Syslog
On Tue, 16.07.13 21:50, Reindl Harald (h.rei...@thelounge.net) wrote: > > While I'm no more important than the next guy, I'll defend the auto-pager > > feature of both git and journalctl. I > > love it, in fact. I'm no stranger to very long pipelines and sub-shells > > but I see nothing but benefit in not > > having to add "| less" routinely to things that are UI in nature. These > > auto-pagers get out of the way immediately > > if you need a pipeline, so what's the harm? In fact, you can still > > "journalctl | less" or the like if you really > > want to. > > you could also do > alias journalctl="journalctl | less" > to achive the same No you can't really. The auto-paging is smarter than you might think. For example, "journalctl -e" can only really work if we spawn the pager ourselves, and there's more like that. But anyway, the auto-paging thing is going to stay, you can talk about it as much as you want. Why? Simply because *I* love it. It's one awesome feature. You are welcome to disagree, but discussing this forth and back on fedora-devel is highly unlikely to change my mind on this. As long as I maintain it, this one feature definitely stays in. Sorry for that! Lennart -- Lennart Poettering - Red Hat, Inc. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: F20 System Wide Change: No Default Syslog
> From: h.rei...@thelounge.net > > Am 16.07.2013 21:45, schrieb john.flor...@dart.biz: > >> From: h.rei...@thelounge.net > >> > >> i am *strictly* against all this truncate and autopaging and for > >> me "GIT does the same" is no argument - a mistake is not better > >> because others do the same. > >> > >> if i want paging i do " | less" or " | more" > >> *this* is the unix way of work > >> > >> but who am i... > >> > > While I'm no more important than the next guy, I'll defend the > auto-pager feature of both git and journalctl. I > > love it, in fact. I'm no stranger to very long pipelines and sub- > shells but I see nothing but benefit in not > > having to add "| less" routinely to things that are UI in nature. > These auto-pagers get out of the way immediately > > if you need a pipeline, so what's the harm? In fact, you can > still "journalctl | less" or the like if you really > > want to. > > you could also do > alias journalctl="journalctl | less" > to achive the same Of course I could ... just as easily as you can set the systemd/git pager env variables, or aliases to pipe thru cat. > hence my konsole has scrollbars, i do not like autopaging and whatever > is not pure unix Now see, I'd argue *pure Unix* won't have scroll bars. However, I do the same for commands that don't have an auto-pager, but I find it mildly annoying to have to reach for the mouse or wish that konsole had some feature that my pager does. One could argue that git is not pure cvs too, but they don't because it brings a fresh take on an old problem. The authors thought they had a better approach. Many agree. Obviously some do not, but that's just a fact of life. I simply choose to adapt and enjoy the ride. > in any case *truncate* outputs is a absolutely no-go I'm not fond of the truncation method either, but I do appreciate knowing that I'm not seeing the whole line, nor do I much care for wrapped lines with semi-structured output. So until my pager grows a throbbing indicator per line to hint there's more I find it a reasonable approach. -- John Florian -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: F20 System Wide Change: No Default Syslog
On Tue, Jul 16, 2013 at 01:37:14PM -0500, Andrew McNabb wrote: > On Tue, Jul 16, 2013 at 08:09:27PM +0200, Zbigniew Jędrzejewski-Szmek wrote: > > Could you be more specific as to what you would like to see changed? > > systemctl uses the the pager in long outputs like list-units, and > > it is the same pager that journalctl uses. > > On Fedora 18, I see lines truncated in the middle with "..." and it > drives me crazy because there's no way to scroll to get the missing > information. For example, just running "systemctl" with no arguments > gives insanely truncated output. The other emails in this thread > implied that journalctl doesn't do this truncation, which sounds like a > huge improvement. Yes, this is still the case, that plain 'systemctl' truncates unit names. It's a tough choice, but in this specific case it's hard to find a format that would work without truncation. There are two fields with potentially very long values (unit name and unit description). We can let the second one flow in the right side, but if we left the first one in full width, on normal terminal width of ~100 columns, even this *first* column would not fit. And the truth is that the units which are usually truncated are the device units (they tend to have the longest names), and they are not the most interesting usually. So in this case truncation makes it much nicer to look at the interesting .service and .target units. Truncation has been removed from a few other places, but in this case it just doesn't seem feasible. Zbyszek -- they are not broken. they are refucktored -- alxchk -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: F20 System Wide Change: Change Packaging Guidelines to discourage requires into /bin and /sbin
On Tue, Jul 16, 2013 at 09:25:37PM +0200, Reindl Harald wrote:
>
>
> Am 16.07.2013 21:18, schrieb Toshio Kuratomi:
> > I think that the best course of action would to rethink UsrMove as
> > UsrMerge which I would then take to the rest of the FPC as getting rid of
> > the prohibition on packages listing /bin, /sbin/ lib, /lib64 as the location
> > in the file. The caveats of package maintainers having to think in terms of
> > the dependencies and canonical locations instead of whether it was symlinked
> > on the path on their own system would still apply.
> >
> > Posible alternatives for FPC to consider if FESCo decides we really want to
> > think in terms of /usr/{bin,sbin,[..]} being the canonical correct place and
> > in the distant future, /bin might go away:
> >
> > * Have package maintainers patch upstreams to use /usr/{bin,lib,[..]}
> > instead of /{bin,lib[...]} (for instance, shebang lines)
>
> if UsrMove would have been planned properly RPM/rpmbuild would
> have the capabilities ot fix this at the buildtime instead
> insist that anybody rewrites and patches anything
>
This is not a rpm or rpmbuild issue.
-Toshio
pgpNfOL4VmqQ1.pgp
Description: PGP signature
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Re: no mention of interface naming in Fedora 19 Release Notes
On Tue, Jul 16, 2013 at 12:45:43PM -0600, Pete Travis wrote: > > Yes, it is too late to change this. I might take time away from other work > for outright factual errors and such, but not for an aesthetic > reorganization. By the way, there is one of those: the same entry mentions /etc/system/network-scripts/ instead of /etc/sysconfig/network-scripts/. But most people who are using this information probably know the layout well enough to not get too confused. -- Andrew McNabb http://www.mcnabbs.org/andrew/ PGP Fingerprint: 8A17 B57C 6879 1863 DE55 8012 AB4D 6098 8826 6868 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: F20 System Wide Change: No Default Syslog
Once upon a time, john.flor...@dart.biz said: > While I'm no more important than the next guy, I'll defend the auto-pager > feature of both git and journalctl. I love it, in fact. I'm no stranger > to very long pipelines and sub-shells but I see nothing but benefit in not > having to add "| less" routinely to things that are UI in nature. My primary objection is that I don't like things that have differing behavior between a TTY and a pipe. One problem is if you are writing a script to process output from something, you'll probably run the command in a TTY to check the output, but you'll get different results. There are not many programs that have such TTY/pipe behavior. The only ones that come to mind are "ps" (where output is truncated at screen width) and "ls" (where "--color=tty" changes between TTY and pipe). The ls behavior makes sense (and doesn't change the information displayed, formatting, etc.); the "ps" behavior is annoying. I guess "man" has similar auto-pager behavior to systemctl/journalctl (although IMHO man is a different type of thing, since it is a documentation reader). We already have pipes, and anyone that knows how to use a Unix shell knows how to use them. IMHO it is extra complication (and code duplication) for programs to change behavior between a TTY and a pipe, unless there are specific things that can't easily be accomplished with a simple pipe (such as "ls --color=tty"). Pagination, truncation, etc. are easy using pipes, and should not be done in regular programs. -- Chris Adams -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: F20 System Wide Change: No Default Syslog
On Tue, 2013-07-16 at 21:50 +0200, Reindl Harald wrote: > > Am 16.07.2013 21:45, schrieb john.flor...@dart.biz: > >> From: h.rei...@thelounge.net > >> > >> i am *strictly* against all this truncate and autopaging and for > >> me "GIT does the same" is no argument - a mistake is not better > >> because others do the same. > >> > >> if i want paging i do " | less" or " | more" > >> *this* is the unix way of work > >> > >> but who am i... > >> > > While I'm no more important than the next guy, I'll defend the auto-pager > > feature of both git and journalctl. I > > love it, in fact. I'm no stranger to very long pipelines and sub-shells > > but I see nothing but benefit in not > > having to add "| less" routinely to things that are UI in nature. These > > auto-pagers get out of the way immediately > > if you need a pipeline, so what's the harm? In fact, you can still > > "journalctl | less" or the like if you really > > want to. > > you could also do > alias journalctl="journalctl | less" > to achive the same > > hence my konsole has scrollbars, i do not like autopaging and whatever > is not pure unix because there are mechs to achieve whatever you need > and with GIt and systemctl/journalctl whe have a inconsistent behavior > > in any case *truncate* outputs is a absolutely no-go > > the ordinary user does not look at all this things and the > advanced which have a reson to look get stripped informations alias journalctl='journalctl --no-pager' an live happy Simo. -- Simo Sorce * Red Hat, Inc * New York -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: F20 System Wide Change: No Default Syslog
Am 16.07.2013 21:45, schrieb john.flor...@dart.biz: >> From: h.rei...@thelounge.net >> >> i am *strictly* against all this truncate and autopaging and for >> me "GIT does the same" is no argument - a mistake is not better >> because others do the same. >> >> if i want paging i do " | less" or " | more" >> *this* is the unix way of work >> >> but who am i... >> > While I'm no more important than the next guy, I'll defend the auto-pager > feature of both git and journalctl. I > love it, in fact. I'm no stranger to very long pipelines and sub-shells but > I see nothing but benefit in not > having to add "| less" routinely to things that are UI in nature. These > auto-pagers get out of the way immediately > if you need a pipeline, so what's the harm? In fact, you can still > "journalctl | less" or the like if you really > want to. you could also do alias journalctl="journalctl | less" to achive the same hence my konsole has scrollbars, i do not like autopaging and whatever is not pure unix because there are mechs to achieve whatever you need and with GIt and systemctl/journalctl whe have a inconsistent behavior in any case *truncate* outputs is a absolutely no-go the ordinary user does not look at all this things and the advanced which have a reson to look get stripped informations signature.asc Description: OpenPGP digital signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: F20 System Wide Change: Change Packaging Guidelines to discourage requires into /bin and /sbin
Am 16.07.2013 21:18, schrieb Toshio Kuratomi:
> I think that the best course of action would to rethink UsrMove as
> UsrMerge which I would then take to the rest of the FPC as getting rid of
> the prohibition on packages listing /bin, /sbin/ lib, /lib64 as the location
> in the file. The caveats of package maintainers having to think in terms of
> the dependencies and canonical locations instead of whether it was symlinked
> on the path on their own system would still apply.
>
> Posible alternatives for FPC to consider if FESCo decides we really want to
> think in terms of /usr/{bin,sbin,[..]} being the canonical correct place and
> in the distant future, /bin might go away:
>
> * Have package maintainers patch upstreams to use /usr/{bin,lib,[..]}
> instead of /{bin,lib[...]} (for instance, shebang lines)
if UsrMove would have been planned properly RPM/rpmbuild would
have the capabilities ot fix this at the buildtime instead
insist that anybody rewrites and patches anything
the current state is the result of "well, we propose the feature
and somewhere in time we fix leftovers" which should not have
happened if FESCo would have learned from F15/systemd
the difference in "making mistakes and learn" and "repeat the mistakes"
signature.asc
Description: OpenPGP digital signature
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Why can't ExecStopPre= be used to abort stopping a (broken) service?
On Tue, Jul 16, 2013 at 09:10:28PM +0200, Miroslav Lichvar wrote: > On Mon, Jul 15, 2013 at 10:55:59PM +0200, Lennart Poettering wrote: > > If I grok correctly what you are asking for, you are actually looing for > > an ExecRestartPre=, not an ExecStopPre=. You want somthing that is run > > before we stop a service when we intend to restart it. But when we > > shutdown the system and stop the service for that, or if the user wants > > to stop it manually, we shouldn't run it, correct? > > > > If that's what you want, then yes, it is on the TODO list to add > > something like this, but ExecStopPre= is not what you want, it would > > have very different semantics. > > Possibly related question: Is there a way to start a daemon with > different options on restart than on start, something like > ExecRestart? > > This would allow restarting chronyd with the -r option to load old > samples and speed up the initial synchronization. Can't you use ”-r” always? -- Tomasz Torcz "God, root, what's the difference?" xmpp: zdzich...@chrome.pl "God is more forgiving." -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Why can't ExecStopPre= be used to abort stopping a (broken) service?
On Tue, 16.07.13 21:10, Miroslav Lichvar (mlich...@redhat.com) wrote: > On Mon, Jul 15, 2013 at 10:55:59PM +0200, Lennart Poettering wrote: > > If I grok correctly what you are asking for, you are actually looing for > > an ExecRestartPre=, not an ExecStopPre=. You want somthing that is run > > before we stop a service when we intend to restart it. But when we > > shutdown the system and stop the service for that, or if the user wants > > to stop it manually, we shouldn't run it, correct? > > > > If that's what you want, then yes, it is on the TODO list to add > > something like this, but ExecStopPre= is not what you want, it would > > have very different semantics. > > Possibly related question: Is there a way to start a daemon with > different options on restart than on start, something like > ExecRestart? No. And I am not convinced that that's a good idea to have. > This would allow restarting chronyd with the -r option to load old > samples and speed up the initial synchronization. Hmm, this sounds like something to maybe just solve based on a simple time scheme? i.e. reuse if the old samples are not older than 1h or so? Lennart -- Lennart Poettering - Red Hat, Inc. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: F20 System Wide Change: No Default Syslog
> From: h.rei...@thelounge.net > > i am *strictly* against all this truncate and autopaging and for > me "GIT does the same" is no argument - a mistake is not better > because others do the same. > > if i want paging i do " | less" or " | more" > *this* is the unix way of work > > but who am i... > While I'm no more important than the next guy, I'll defend the auto-pager feature of both git and journalctl. I love it, in fact. I'm no stranger to very long pipelines and sub-shells but I see nothing but benefit in not having to add "| less" routinely to things that are UI in nature. These auto-pagers get out of the way immediately if you need a pipeline, so what's the harm? In fact, you can still "journalctl | less" or the like if you really want to. -- John Florian -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: F20 System Wide Change: No Default Syslog
On Tue, Jul 16, 2013 at 01:31:53PM -0500, Andrew McNabb wrote: > The way git does it is to only set the LESS environment variable if it's > not set. If the LESS environment variable is set, then git doesn't > touch it. This seems like a nice balanced way to approach the > situation, and it would be wonderful if systemd/journalctl did the same > thing as git. That's actually what it did originally. This doesn't work, because the colored output of journalctl needs -R, and several other options are important. I have my LESS variable normally set to -MX, which is great for most things but doesn't work right for this special case. I think the current approach is probably the best compromise. -- Matthew Miller ☁☁☁ Fedora Cloud Architect ☁☁☁ -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: F20 System Wide Change: Change Packaging Guidelines to discourage requires into /bin and /sbin
On Tue, Jul 16, 2013 at 04:46:26PM +0200, Jan Zelený wrote:
> On 16. 7. 2013 at 13:57:02, Björn Persson wrote:
> > > Related FPC ticket [1]: FPC wanted this change to be created.
> >
> > Oh really?
> >
> > > [1] https://fedorahosted.org/fpc/ticket/314
> >
> > In that ticket I see one FPC member being for and two being against
> > the change.
>
> Yeah, the original message from Ales was incorrect. It was FESCO that
> recommended this change to be created so it can be discussed more widely. We
> certainly don't want to go around FPC or anything.
>
With my FPC hat on, thanks!
> Note that we don't necessarily insist on this change to be implemented. Ales
> was just pointing out that there is a potential problem caused by leftovers
> of
> /usr move. What to do with the information is up to you.
>
I think that the best course of action would to rethink UsrMove as
UsrMerge which I would then take to the rest of the FPC as getting rid of
the prohibition on packages listing /bin, /sbin/ lib, /lib64 as the location
in the file. The caveats of package maintainers having to think in terms of
the dependencies and canonical locations instead of whether it was symlinked
on the path on their own system would still apply.
Posible alternatives for FPC to consider if FESCo decides we really want to
think in terms of /usr/{bin,sbin,[..]} being the canonical correct place and
in the distant future, /bin might go away:
* Have package maintainers patch upstreams to use /usr/{bin,lib,[..]}
instead of /{bin,lib[...]} (for instance, shebang lines)
* Have packages which traditionally provide /{bin,sbin,possibly lib but
I can't think of something in /lib that's actually causing breakage}
create Virtual Provides for those older file paths. (Note: This could
also be done in the case of thinking of things in terms of a merge instead
of a move but it wouldn't be as needed as most upstreams will simply
work out of the box if default values are used for both the package providing
the file in /{bin,sbin,[...]} ) and the package using those files.
* Possibly create an exception list to go along with either of these
alternatives. For instance, I know someone mentioned moving the dynamic
loader
out of /lib{,64} would be an extraordinarily bad idea (OTOH, I don't think
rpm dependencies embed the fully pathed dynamic linker so this may not be
a concern).
FPC alternatives if FESCo were to decide that UsrMove was a mistake and
should be reverted:
* FPC would remove the prohibition from packages listing files in
/{bin,sbin,[...]}
* Guidelines would be checked to be sure that references to
programs used the correct path.
-Toshio
pgplXDODkONi7.pgp
Description: PGP signature
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Re: F20 System Wide Change: ARM as primary Architecture
On 07/16/2013 05:28 AM, Peter Robinson wrote: All the remix images to date have been created on the users own devices. If you are internal to Red Hat there's process to get access to internal infrastructure... There are 3 things I would like to add here: 1. As Peter mentioned elsewhere in his reply, not even the ARM team has access to the ARM builders in PHX. Just like we don't have x86_64. Access is handled by the infrastructure team, builds are handled by koji. These are closed systems without remote access provisions. 2. Kevin Fenzi is working on setting up a limited pool community-accessible ARM builders. Join in the weekly fedora-arm meeting on Wendesdays at 20:00 UTC in #fedora-meeting-1 for updates about his progress (And other ARM topics). As of last week it was being considered and worked on, but not immediately ready to go. 3. If you are a Red Hat employee I can provide access to ARM systems of the same caliber as what is in the Fedora colo. Drop me a line and let me know what you need- I will make it happen. Thanks, -- Brendan Conoboy / Red Hat, Inc. / b...@redhat.com -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Rawhide tree now includes install images
On Tue, Jul 16, 2013 at 12:58:11 -0600, Kevin Fenzi wrote: Yep. Dennis was going to look into doing some kind of weekly dvd iso compose. Great! -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Why can't ExecStopPre= be used to abort stopping a (broken) service?
On Mon, Jul 15, 2013 at 10:55:59PM +0200, Lennart Poettering wrote: > If I grok correctly what you are asking for, you are actually looing for > an ExecRestartPre=, not an ExecStopPre=. You want somthing that is run > before we stop a service when we intend to restart it. But when we > shutdown the system and stop the service for that, or if the user wants > to stop it manually, we shouldn't run it, correct? > > If that's what you want, then yes, it is on the TODO list to add > something like this, but ExecStopPre= is not what you want, it would > have very different semantics. Possibly related question: Is there a way to start a daemon with different options on restart than on start, something like ExecRestart? This would allow restarting chronyd with the -r option to load old samples and speed up the initial synchronization. -- Miroslav Lichvar -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: F20 System Wide Change: No Default Syslog
Am 16.07.2013 20:37, schrieb Andrew McNabb: > On Tue, Jul 16, 2013 at 08:09:27PM +0200, Zbigniew Jędrzejewski-Szmek wrote: >> Could you be more specific as to what you would like to see changed? >> systemctl uses the the pager in long outputs like list-units, and >> it is the same pager that journalctl uses. > > On Fedora 18, I see lines truncated in the middle with "..." and it > drives me crazy because there's no way to scroll to get the missing > information. For example, just running "systemctl" with no arguments > gives insanely truncated output. The other emails in this thread > implied that journalctl doesn't do this truncation, which sounds like a > huge improvement i am *strictly* against all this truncate and autopaging and for me "GIT does the same" is no argument - a mistake is not better because others do the same. if i want paging i do " | less" or " | more" *this* is the unix way of work but who am i... signature.asc Description: OpenPGP digital signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: F20 System Wide Change: ARM as primary Architecture
On 07/16/2013 01:49 AM, Bastien Nocera wrote: I'm interested in Fedora on phones, tablets, tiny dongly media centers, set-top boxes, Wi-Fi routers and eBook readers. Personally, I'm interested in running Fedora on ARM everywhere, so if you want to contribute toward the above, by all means do so. Join us in #fedora-arm, join the mailing list, and we'll do what we can to support your pursuit. If it can be done within Fedora package guidelines and spin set it can be an official part of the next release. If it can't, it can be a remix. In either case you are most welcome to join in and pursue your interest. -- Brendan Conoboy / Red Hat, Inc. / b...@redhat.com -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Hard link to root-owned file now fails (since Fedora 19)
On 15.07.2013 19:35, Chris Adams wrote: > Once upon a time, Richard W.M. Jones said: >> Why? > http://docs.fedoraproject.org/en-US/Fedora/19/html/Release_Notes/sect-Release_Notes-Changes_for_Sysadmin.html#idm263811933136 > There is a BUG it the documentation or in my Fedora 19 system! This lines mentioned in documentation: fs.protected_hardlinks = 1 fs.protected_symlinks = 1 are in /usr/lib/sysctl.d/50-default.conf file and not in /usr/lib/sysctl.d/00-system.conf file as it's written. Is someone checking this before releasing invalid documentation or this new feature was so hot and finally landed in different file than it was initially designed? Mateusz Marzantowicz -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Rawhide tree now includes install images
On Tue, 16 Jul 2013 13:47:01 -0500 Bruno Wolff III wrote: > On Tue, Jul 16, 2013 at 10:41:22 -0600, >Kevin Fenzi wrote: > >Greetings. > > > >After consulting with various teams, release engineering has > >re-enabled rawhide composes to create install images again. These > >images were dropped as part of the 'no frozen rawhide' proposal > >several years ago. > > Is there still a plan to do builds of the normal install iso, > analagous to the nightly composes for live images? Yep. Dennis was going to look into doing some kind of weekly dvd iso compose. kevin signature.asc Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Rawhide tree now includes install images
On Tue, Jul 16, 2013 at 10:41:22 -0600, Kevin Fenzi wrote: Greetings. After consulting with various teams, release engineering has re-enabled rawhide composes to create install images again. These images were dropped as part of the 'no frozen rawhide' proposal several years ago. Is there still a plan to do builds of the normal install iso, analagous to the nightly composes for live images? -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Hard link to root-owned file now fails (since Fedora 19)
On Tue, Jul 16, 2013 at 01:37:33PM -0400, Colin Walters wrote: > But ok, so as you said in the followup, the real root issue here is > libvirt calling chown [on the kernel and initrd]. It's not clear > to me why it does so. It's a good question, and trying to formulate an answer made me question some fundamental assumptions. I'm CC-ing libvir-list to see if anyone has some ideas. Some background: We've got three users involved here. novalibvirtd qemu -- invokes --> -- invokes --> some $UID root qemu.qemu The reason for this dance of three users is security. It provides extra separation in case a rogue filesystem that we're examining exploits the guest kernel and qemu (which is reckoned to be rather easy). We don't want that rogue qemu process to be able to escalate this to an attack on either the host or the process (nova) running libguestfs. SELinux is used too for extra extra security, but you may be amazed that it's not unknown for people to turn SELinux off. Now does libvirtd need to chown kernel & initrd? Ideally (and something that's slowly being worked towards) libvirtd would open all resources on qemu's behalf, and pass opened file descriptors down to qemu. In the case of kernel and initrd libvirtd could do this already by passing /dev/fd/ paths to qemu. This, I think, would avoid any need to chown those. For the appliance disk, /dev/fd/ also works, but only because we're not hot-plugging this disk. (When you have to hot-plug a disk, you are talking to qemu over the qemu monitor, so the only way to pass fd's over is to use SCM_RIGHTS). Could we just rely on Unix permissions? I think the answer is yes for kernel & initrd (make them world readable), at least in this case. If kernel & initrd had private data, you wouldn't want to do this. The appliance disk is a little more tricky. Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones libguestfs lets you edit virtual machines. Supports shell scripting, bindings from many languages. http://libguestfs.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: no mention of interface naming in Fedora 19 Release Notes
On Jul 16, 2013 11:22 AM, "Andrew McNabb" wrote: > > Fedora 19 has gone through yet another change to how network interfaces > are renamed (biosdevname, etc.). This isn't mentioned in the "Changes > in Fedora for System Administrators" section of the Release Notes, > though it does seem to be in the Changes for Desktop Users section. > It is mentioned in the Networking section. The entire document is arguably relevant to a sysadmin, but I can see where placing that in the higher level Desktop category might be confusing. This bears examination for the next release, IMO. > Is there any reason that this isn't mentioned in the "Changes in Fedora > for System Administrators" section of the Release Notes, and is it too > late to add it there? Many changes could arguably fit into multiple beats - subcategories in the document - and we try to pick the most appropriate one. Desktop changes vs system administrator changes is mostly a way to organize content rather than define scope, and perhaps an unneeded one. Yes, it is too late to change this. I might take time away from other work for outright factual errors and such, but not for an aesthetic reorganization. By the way, d...@lists.fedoraproject.org might be more appropriate. > > -- > Andrew McNabb > http://www.mcnabbs.org/andrew/ > PGP Fingerprint: 8A17 B57C 6879 1863 DE55 8012 AB4D 6098 8826 6868 > -- > --Pete -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: F20 System Wide Change: No Default Syslog
On Tue, Jul 16, 2013 at 08:09:27PM +0200, Zbigniew Jędrzejewski-Szmek wrote: > Could you be more specific as to what you would like to see changed? > systemctl uses the the pager in long outputs like list-units, and > it is the same pager that journalctl uses. On Fedora 18, I see lines truncated in the middle with "..." and it drives me crazy because there's no way to scroll to get the missing information. For example, just running "systemctl" with no arguments gives insanely truncated output. The other emails in this thread implied that journalctl doesn't do this truncation, which sounds like a huge improvement. -- Andrew McNabb http://www.mcnabbs.org/andrew/ PGP Fingerprint: 8A17 B57C 6879 1863 DE55 8012 AB4D 6098 8826 6868 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: F20 System Wide Change: ARM as primary Architecture
Brendan Conoboy (b...@redhat.com) said: > Hypothetically speaking, if libGL is fixed in the next few days, do > you have any objections to armv7hl being moved to primary koji? Or > is that the tip of the iceberg? > > >And I'm saying that threshold should be that the major libraries work. That > >includes libGL. > > Okay, so it's not just libGL, it's major libraries. Which are those? Well, what else is broken? It's a matter of approach - you seem to be saying "what are the minimum requirements, listed so that we can meet them". In terms of a minimum viable platform, for all its faults, the interfaces specified by the LSB might be a worthwhile starting point. But even in that case... if an arch implemented the entire LSB, and 90% of the rest of the distribution did not build, that's obviously not good enough. So I'm more in favor of "tell us what you don't have, and we can discuss whether that's good enough." I don't want to move the goalposts on the ARM effort, but I think it's reasonable to expect that a list of "Known Broken/Deficient items" be available. Does such a list exist? Bill -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: F20 System Wide Change: No Default Syslog
On Tue, 16.07.13 12:19, Kevin Fenzi (ke...@scrye.com) wrote: > On Tue, 16 Jul 2013 20:09:19 +0200 > Lennart Poettering wrote: > > > On Tue, 16.07.13 12:49, Andrew McNabb (amcn...@mcnabbs.org) wrote: > > > > > On Tue, Jul 16, 2013 at 01:56:44AM +0200, Lennart Poettering wrote: > > > > > > > > We didn't override LESS initially, but we got bugs about that, > > > > and after a while of forth and back we followed again what git > > > > does here and override it. You find the discussions in bugzilla. > > > > > > How do you turn this off? Overriding user configuration can be > > > extremely annoying to users, but if there's an easy well-documented > > > way to turn off overriding, it's easier to deal with. > > > > Set $SYSTEMD_PAGE to the pager of your choice along with any command > > line arguments you like. > > This is a bit anoying for a lot of uses as permissions only allow root > (or the 'adm' group), so many people would use sudo with their journal > commands. > > BTW, should we change 'adm' to 'wheel' to match our other admin group? The files are owned by the group "systemd-journal" now. If you want to grant a user access to the system journals and nothing else, add him/her to this group. Via file system ACLs the groups "adm" and "wheel" also get read access to the journal files, "adm" being more a group of "folks who can see but not do", and "wheel" being a group of folks "who can see and do". Of course, wheel and adm might enable you to see and do much more than just granting access to the system journals. Lennart -- Lennart Poettering - Red Hat, Inc. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: F20 System Wide Change: No Default Syslog
On Tue, Jul 16, 2013 at 08:09:19PM +0200, Lennart Poettering wrote: > On Tue, 16.07.13 12:49, Andrew McNabb (amcn...@mcnabbs.org) wrote: > > > On Tue, Jul 16, 2013 at 01:56:44AM +0200, Lennart Poettering wrote: > > > > > > We didn't override LESS initially, but we got bugs about that, and after > > > a while of forth and back we followed again what git does here and > > > override it. You find the discussions in bugzilla. > > > > How do you turn this off? Overriding user configuration can be > > extremely annoying to users, but if there's an easy well-documented way > > to turn off overriding, it's easier to deal with. > > Set $SYSTEMD_PAGE to the pager of your choice along with any command > line arguments you like. The way git does it is to only set the LESS environment variable if it's not set. If the LESS environment variable is set, then git doesn't touch it. This seems like a nice balanced way to approach the situation, and it would be wonderful if systemd/journalctl did the same thing as git. -- Andrew McNabb http://www.mcnabbs.org/andrew/ PGP Fingerprint: 8A17 B57C 6879 1863 DE55 8012 AB4D 6098 8826 6868 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: F20 System Wide Change: No Default Syslog
On Tue, 16 Jul 2013 20:09:19 +0200 Lennart Poettering wrote: > On Tue, 16.07.13 12:49, Andrew McNabb (amcn...@mcnabbs.org) wrote: > > > On Tue, Jul 16, 2013 at 01:56:44AM +0200, Lennart Poettering wrote: > > > > > > We didn't override LESS initially, but we got bugs about that, > > > and after a while of forth and back we followed again what git > > > does here and override it. You find the discussions in bugzilla. > > > > How do you turn this off? Overriding user configuration can be > > extremely annoying to users, but if there's an easy well-documented > > way to turn off overriding, it's easier to deal with. > > Set $SYSTEMD_PAGE to the pager of your choice along with any command > line arguments you like. This is a bit anoying for a lot of uses as permissions only allow root (or the 'adm' group), so many people would use sudo with their journal commands. BTW, should we change 'adm' to 'wheel' to match our other admin group? kevin signature.asc Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: F20 System Wide Change: No Default Syslog
On Tue, Jul 16, 2013 at 12:43:31PM -0500, Andrew McNabb wrote: > On Mon, Jul 15, 2013 at 11:28:48PM +0200, Lennart Poettering wrote: > > > > (also: journalctl doesn't truncate lines when doing auto-paging) > > Could sane auto-paging be backported to systemctl? Things like this can > make all the difference between a lovable and an unlovable tool. Could you be more specific as to what you would like to see changed? systemctl uses the the pager in long outputs like list-units, and it is the same pager that journalctl uses. Zbyszek -- they are not broken. they are refucktored -- alxchk -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: F20 System Wide Change: No Default Syslog
On Tue, 16.07.13 12:49, Andrew McNabb (amcn...@mcnabbs.org) wrote: > On Tue, Jul 16, 2013 at 01:56:44AM +0200, Lennart Poettering wrote: > > > > We didn't override LESS initially, but we got bugs about that, and after > > a while of forth and back we followed again what git does here and > > override it. You find the discussions in bugzilla. > > How do you turn this off? Overriding user configuration can be > extremely annoying to users, but if there's an easy well-documented way > to turn off overriding, it's easier to deal with. Set $SYSTEMD_PAGE to the pager of your choice along with any command line arguments you like. Lennart -- Lennart Poettering - Red Hat, Inc. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: F20 System Wide Change: No Default Syslog
On Tue, 16.07.13 12:43, Andrew McNabb (amcn...@mcnabbs.org) wrote: > On Mon, Jul 15, 2013 at 11:28:48PM +0200, Lennart Poettering wrote: > > > > (also: journalctl doesn't truncate lines when doing auto-paging) > > Could sane auto-paging be backported to systemctl? Things like this can > make all the difference between a lovable and an unlovable tool. systemctl uses pretty much the same code as journalctl these days in this regard. Lennart -- Lennart Poettering - Red Hat, Inc. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: F20 System Wide Change: ARM as primary Architecture
On 07/16/2013 11:01 AM, Bill Nottingham wrote: Brendan Conoboy (b...@redhat.com) said: If not now, when? When libGL is ready to go? ... when someone fixes it? Hypothetically speaking, if libGL is fixed in the next few days, do you have any objections to armv7hl being moved to primary koji? Or is that the tip of the iceberg? And I'm saying that threshold should be that the major libraries work. That includes libGL. Okay, so it's not just libGL, it's major libraries. Which are those? -- Brendan Conoboy / Red Hat, Inc. / b...@redhat.com -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: F20 System Wide Change: ARM as primary Architecture
Brendan Conoboy (b...@redhat.com) said: > On 07/15/2013 11:09 AM, Bill Nottingham wrote: > >If I'm understanding you, you would prefer that ARM be blessed with the > >stamp of being a 'primary' arch at the cost of dropping release targets, > >images, and featuresets that are made by and for the community now. > > I wouldn't put it like that. The ARM team isn't asking for a > blessing, we're asking to have builds that block ARM also block x86. > At a technical level, that is a fundamental part of what being > primary is. Yes, there are other aspects, both practical (what is > released) and philosophical (What is Fedora). It's the next logical > step. If not now, when? When libGL is ready to go? ... when someone fixes it? > >I don't think I can support that - it seems awfully unfriendly to the > >community that exists now. > > You are proceeding from a misconception: This is a thought exercise- > If ARM devices didn't have graphics would it still be essential for > PA promotion that libGL for ARM work and be accelerated? There is > no proposal to throw out the baby or the bathwater. This is about > defining the threshold at which point armv7hl gets built along side > i686 and x86_64. And I'm saying that threshold should be that the major libraries work. That includes libGL. After all, IT WORKS ON S390. This is not a high bar, and I wouldn't consider it a requirement for that arch. Sure, the hardware you care about doesn't include graphics. But the hardware the community cares about does. Bill -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: F20 System Wide Change: No Default Syslog
On Tue, Jul 16, 2013 at 01:56:44AM +0200, Lennart Poettering wrote: > > We didn't override LESS initially, but we got bugs about that, and after > a while of forth and back we followed again what git does here and > override it. You find the discussions in bugzilla. How do you turn this off? Overriding user configuration can be extremely annoying to users, but if there's an easy well-documented way to turn off overriding, it's easier to deal with. -- Andrew McNabb http://www.mcnabbs.org/andrew/ PGP Fingerprint: 8A17 B57C 6879 1863 DE55 8012 AB4D 6098 8826 6868 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: F20 System Wide Change: No Default Syslog
On Mon, Jul 15, 2013 at 11:28:48PM +0200, Lennart Poettering wrote: > > (also: journalctl doesn't truncate lines when doing auto-paging) Could sane auto-paging be backported to systemctl? Things like this can make all the difference between a lovable and an unlovable tool. -- Andrew McNabb http://www.mcnabbs.org/andrew/ PGP Fingerprint: 8A17 B57C 6879 1863 DE55 8012 AB4D 6098 8826 6868 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Hard link to root-owned file now fails (since Fedora 19)
On Tue, 2013-07-16 at 17:59 +0100, Richard W.M. Jones wrote:
> There's a lock (building_lock) which stops two threads from the same
> process from entering the appliance building code in parallel.
>
> There's also a lock (fcntl held on the file 'checksums') which stops
> two processes owned by the same user from trying to rebuild the
> appliance in parallel.
What we're trying to achieve with this is that if I do e.g.
guestmount from two separate shells, only one of them will create the
appliance?
That makes sense.
> And different users have their own directory ($UID == euid is
> different), so those don't interfere.
Though there's the usual DoS problem from predicably-named directories
in /{,var/}tmp. Consider /run/user/$UID/libguestfs-cache/ being a
symbolic link to a randomly named /var/tmp/libguestfs.XX.
> BUT after we've built the appliance, we have to pass it over (by
> reference to the filename) to qemu. Now qemu runs in its own sweet
> time a bit later on, and we can never know when qemu will actually
> read these files (and because qemu may run for an indefinitely long
> period of time, we can't block other processes here). That's where
> the hard link comes in: it gives qemu effectively its own copy of the
> kernel, initrd and root files, while letting us safely erase [the
> hard-linked alias] from another process.
qemu *could* export some signaling interface to the effect of "I have
called open() on all file arguments specified on the command line".
That seems like it'd be generally useful.
But ok, so as you said in the followup, the real root issue here is
libvirt calling chown. It's not clear to me why it does so. It seems
fine if a user suitably privileged to create VMs can crash them
afterwards by writing to or unlinking the kernel/initramfs.
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
no mention of interface naming in Fedora 19 Release Notes
Fedora 19 has gone through yet another change to how network interfaces are renamed (biosdevname, etc.). This isn't mentioned in the "Changes in Fedora for System Administrators" section of the Release Notes, though it does seem to be in the Changes for Desktop Users section. Is there any reason that this isn't mentioned in the "Changes in Fedora for System Administrators" section of the Release Notes, and is it too late to add it there? -- Andrew McNabb http://www.mcnabbs.org/andrew/ PGP Fingerprint: 8A17 B57C 6879 1863 DE55 8012 AB4D 6098 8826 6868 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: F20 System Wide Change: SSD cache
On Tue, 16 Jul 2013 10:36:55 +0200 Florian Weimer wrote: > On 07/15/2013 09:25 PM, Conrad Meyer wrote: > > > By default, bcache runs a write-through cache -- it only > > caches clean data. If the caching SSD dies, the bcache > > layer can just forward requests to spinning drive. No > > data is lost. > > > > (Bcache has a writeback mode where data loss is possible. > > I do not recommend this mode.) > > What's the benefit of bcache, compared to just sticking > more RAM in the machine? That you can get more cache, > especially on systems that are short on memory sockets? Or > that the cache persits across reboots (something that can > be tricky because it requires synchronizing writes to the > cache and the disk)? From 5 minutes of research: - 512 GB SSD on newegg -- $390. - 512 GB of RAM on newegg -- $4200*. * Doesn't include the cost of a server board that has 32 ram slots. So bcache is a more cost-effective way (than RAM) to expand the working set of disk you can access very quickly. bcache in write-back mode must persist or else you suffer data loss on any power failure. So, I think that answers that question. Getting the syncing right isn't actually that hard. Regards, Conrad -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Rawhide tree now includes install images
On Tue, Jul 16, 2013 at 10:41:22AM -0600, Kevin Fenzi wrote: > After consulting with various teams, release engineering has re-enabled > rawhide composes to create install images again. These images were > dropped as part of the 'no frozen rawhide' proposal several years ago. > This allows users to use the latest boot.iso or pxe images to install > rawhide instances or point to rawhide as a install-able tree. This is awesome. Thanks Kevin! -- Matthew Miller ☁☁☁ Fedora Cloud Architect ☁☁☁ -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Hard link to root-owned file now fails (since Fedora 19)
On Tue, Jul 16, 2013 at 05:42:00PM +0100, Richard W.M. Jones wrote: > On Tue, Jul 16, 2013 at 11:50:10AM -0400, Colin Walters wrote: > > On Tue, 2013-07-16 at 15:59 +0100, Richard W.M. Jones wrote: > > > I'm not even sure > > > how to do that because we want the atomic behaviour of hard links, and > > > we want to have qemu running as a different user (for security, oh the > > > irony), so there's no other obvious way to code it. > > > > Can you link to or describe the relevant algorithm/code? The file > > https://github.com/openstack/nova/blob/master/nova/virt/disk/vfs/guestfs.py#L94 > > doesn't contain an obvious call to link(). > > Thanks for any input. It's this code below. The big comment at the > top explains roughly what's going on, but misses out a crucial detail: > If you are using libvirt in a certain way, then libvirtd [which runs > as root] will chown the 'kernel' and 'initrd' files to root.root. If > that chown didn't happen, then none of this would be a problem. > > https://github.com/libguestfs/libguestfs/blob/master/src/appliance.c#L68 I'll just add a bit about how the locking works in this code since it may not be obvious. There's a lock (building_lock) which stops two threads from the same process from entering the appliance building code in parallel. There's also a lock (fcntl held on the file 'checksums') which stops two processes owned by the same user from trying to rebuild the appliance in parallel. And different users have their own directory ($UID == euid is different), so those don't interfere. BUT after we've built the appliance, we have to pass it over (by reference to the filename) to qemu. Now qemu runs in its own sweet time a bit later on, and we can never know when qemu will actually read these files (and because qemu may run for an indefinitely long period of time, we can't block other processes here). That's where the hard link comes in: it gives qemu effectively its own copy of the kernel, initrd and root files, while letting us safely erase [the hard-linked alias] from another process. These files are huge so copying them isn't an alternative. Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones virt-p2v converts physical machines to virtual machines. Boot with a live CD or over the network (PXE) and turn machines into KVM guests. http://libguestfs.org/virt-v2v -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Rawhide tree now includes install images
Greetings. After consulting with various teams, release engineering has re-enabled rawhide composes to create install images again. These images were dropped as part of the 'no frozen rawhide' proposal several years ago. This allows users to use the latest boot.iso or pxe images to install rawhide instances or point to rawhide as a install-able tree. kevin signature.asc Description: PGP signature ___ devel-announce mailing list devel-annou...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel-announce-- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Hard link to root-owned file now fails (since Fedora 19)
On Tue, Jul 16, 2013 at 11:50:10AM -0400, Colin Walters wrote: > On Tue, 2013-07-16 at 15:59 +0100, Richard W.M. Jones wrote: > > I'm not even sure > > how to do that because we want the atomic behaviour of hard links, and > > we want to have qemu running as a different user (for security, oh the > > irony), so there's no other obvious way to code it. > > Can you link to or describe the relevant algorithm/code? The file > https://github.com/openstack/nova/blob/master/nova/virt/disk/vfs/guestfs.py#L94 > doesn't contain an obvious call to link(). Thanks for any input. It's this code below. The big comment at the top explains roughly what's going on, but misses out a crucial detail: If you are using libvirt in a certain way, then libvirtd [which runs as root] will chown the 'kernel' and 'initrd' files to root.root. If that chown didn't happen, then none of this would be a problem. https://github.com/libguestfs/libguestfs/blob/master/src/appliance.c#L68 Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones Fedora Windows cross-compiler. Compile Windows programs, test, and build Windows installers. Over 100 libraries supported. http://fedoraproject.org/wiki/MinGW -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: F20 System Wide Change: No Default Syslog
On Tue, 16.07.13 18:09, Till Maas (opensou...@till.name) wrote: > On Tue, Jul 16, 2013 at 01:43:04PM +0200, Lennart Poettering wrote: > > On Tue, 16.07.13 09:42, Till Maas (opensou...@till.name) wrote: > > > > > > journalctl only supports local time specifications when you > > > > specify calendar times. Unfortunately there's no nice API to map > > > > calendar times that include time zone specifications back to UTC, in > > > > particular because the time zone names are not unique... > > > > While it will be hard to support arbitrary timezone specs in --since= it > > > > should be relatively easy to support UTC in addition to the local > > > > timezone. Added this to the TODO list. > > > > > > You only need to add or subtract hours and minutes from the local time, > > > because ISO 8601 dates contain the UTC offset: > > > > > > | $ date --iso-8601=seconds > > > | 2013-07-15T22:37:04+0200 > > > > Well, we can certainly add support for such numeric timezone specs > > (added to the TODO list), but I have my doubts that this is actually > > what people want to use in their day-to-day use, given that the numbers > > are hard to remember. > > Thank you. > > > I am pretty sure that most folks would like to specify symbolic timezone > > names, but that's hard to do due to lack of APIs for that, and the > > non-uniqueness of the names. > > I guess for most use cases using the local time zone is enough. > > Btw. can journalctl output ISO 8601 dates instead of the US formated > date without a year? I really expected journalctl to cleanup this as > well. In the default output we stay true to the formatting that has been used in /var/log/messages since always. We currently do not use the ISO date format anywhere, it's not really readable, I think. Great way to serialize dates, recurring and duration events to ascii strings for computers to read, but not really for humans. Note that in all other places we tend to use date format like this: "Tue 2013-07-16 18:41:57 CEST" Which is close to ISO, but not ISO. Lennart -- Lennart Poettering - Red Hat, Inc. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: F20 System Wide Change: No Default Syslog
On Tue, Jul 16, 2013 at 06:39:53PM +0200, Lennart Poettering wrote: > On Tue, 16.07.13 18:26, Tomasz Torcz (to...@pipebreaker.pl) wrote: > > > On Tue, Jul 16, 2013 at 06:09:54PM +0200, Till Maas wrote: > > > > > > Btw. can journalctl output ISO 8601 dates instead of the US formated > > > date without a year? I really expected journalctl to cleanup this as > > > well. > > > > That would be nice, ”journalctl” output would match rsyslog: > > > > % tail -1 /var/log/messages > > 2013-07-16T17:57:27.903228+02:00 mother postfix/smtpd[3452]: DC6A1600B6: > > client=bastion01.fedoraproject.org[209.132.181.2] > > That's not the default output we ship, is it? Or did rsyslog defaults > change recently? Classic /var/log/messages output does not include ISO > dates. That's after adding one ”#” in rsyslog.conf we ship. I don't know how ”classic” matches latest Syslog RFC document in case of timestamp. -- Tomasz Torcz "God, root, what's the difference?" xmpp: zdzich...@chrome.pl "God is more forgiving." -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: F20 System Wide Change: No Default Syslog
On Tue, Jul 16, 2013 at 06:33:23PM +0200, drago01 wrote: > On Tue, Jul 16, 2013 at 6:26 PM, Tomasz Torcz wrote: > > On Tue, Jul 16, 2013 at 06:09:54PM +0200, Till Maas wrote: > >> > >> Btw. can journalctl output ISO 8601 dates instead of the US formated > >> date without a year? I really expected journalctl to cleanup this as > >> well. > > > > That would be nice, ”journalctl” output would match rsyslog: > > > > % tail -1 /var/log/messages > > 2013-07-16T17:57:27.903228+02:00 mother postfix/smtpd[3452]: DC6A1600B6: > > client=bastion01.fedoraproject.org[209.132.181.2] > > > journalctl -n 1 ? No, it's the timestamp which is imporant; speaking of time, did anyone mention that journal is quite slow on rotating HDDs? % time journalctl -u postfix -n 1 -- Logs begin at Sat 2012-12-08 19:45:43 CET, end at Tue 2013-07-16 18:34:45 CEST. -- Jul 16 18:34:45 mother.pipebreaker.pl postfix/qmgr[1675]: 0F945601C0: removed real0m24.873s user0m0.008s sys 0m0.201s I know that SSD are current storage technology, but there are some people with HDDs left, and they will complain. They already complain “systemctl status foo” takes half a minute to pull logs back. (above ”time journalctl …” comes from system with Intel Sandy Bridge CPU, ext4 over dm-crypt over 4xSATA 7200 mdraid). -- Tomasz Torcz "God, root, what's the difference?" xmpp: zdzich...@chrome.pl "God is more forgiving." -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: F20 System Wide Change: No Default Syslog
On Tue, 16.07.13 18:26, Tomasz Torcz (to...@pipebreaker.pl) wrote: > On Tue, Jul 16, 2013 at 06:09:54PM +0200, Till Maas wrote: > > > > Btw. can journalctl output ISO 8601 dates instead of the US formated > > date without a year? I really expected journalctl to cleanup this as > > well. > > That would be nice, ”journalctl” output would match rsyslog: > > % tail -1 /var/log/messages > 2013-07-16T17:57:27.903228+02:00 mother postfix/smtpd[3452]: DC6A1600B6: > client=bastion01.fedoraproject.org[209.132.181.2] That's not the default output we ship, is it? Or did rsyslog defaults change recently? Classic /var/log/messages output does not include ISO dates. Lennart -- Lennart Poettering - Red Hat, Inc. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: F20 System Wide Change: No Default Syslog
journalctl -n 1 ? On Tue, Jul 16, 2013 at 6:26 PM, Tomasz Torcz wrote: > On Tue, Jul 16, 2013 at 06:09:54PM +0200, Till Maas wrote: >> >> Btw. can journalctl output ISO 8601 dates instead of the US formated >> date without a year? I really expected journalctl to cleanup this as >> well. > > That would be nice, ”journalctl” output would match rsyslog: > > % tail -1 /var/log/messages > 2013-07-16T17:57:27.903228+02:00 mother postfix/smtpd[3452]: DC6A1600B6: > client=bastion01.fedoraproject.org[209.132.181.2] > > > -- > Tomasz Torcz "God, root, what's the difference?" > xmpp: zdzich...@chrome.pl "God is more forgiving." > > -- > 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: F20 System Wide Change: No Default Syslog
On Tue, Jul 16, 2013 at 06:09:54PM +0200, Till Maas wrote: > > Btw. can journalctl output ISO 8601 dates instead of the US formated > date without a year? I really expected journalctl to cleanup this as > well. That would be nice, ”journalctl” output would match rsyslog: % tail -1 /var/log/messages 2013-07-16T17:57:27.903228+02:00 mother postfix/smtpd[3452]: DC6A1600B6: client=bastion01.fedoraproject.org[209.132.181.2] -- Tomasz Torcz "God, root, what's the difference?" xmpp: zdzich...@chrome.pl "God is more forgiving." -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: dracut hang in %posttrans of Rawhide kernel install?
On Mon, 2013-07-15 at 12:42 -0700, Adam Williamson wrote: > On Sat, 2013-07-13 at 08:30 -0500, Bruno Wolff III wrote: > > On Sat, Jul 13, 2013 at 00:09:26 -0700, > >Adam Williamson wrote: > > > > > >Has anyone else seen this? Any ideas on the cause, for a bug report? > > > > I didn't see the problem, but I have /etc/crypttab on my system. > > Hum. Well, still can't make it fly here. Here's what I get from 'strace > -o dracut.strace > dracut /boot/initramfs-3.11.0-0.rc0.git7.1.fc20.x86_64.img > 3.11.0-0.rc0.git7.1.fc20.x86_64' . So this seems to be caused by the same thing that's giving me problems shutting down and suspending: an NFSv4 mount I have in /etc/fstab . Trying to figure out what's going on with that now. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora http://www.happyassassin.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: F20 System Wide Change: No Default Syslog
On Tue, 16.07.13 17:57, Till Maas (opensou...@till.name) wrote: > > > Will journalctl also mention that there is a broken jorunal file? Does > > > it support to "fsck" the journal or to show the not properly referenced > > > data to the admin? > > > > journalctl will not show you that, but libraries do see this. The reason > > we don't show this in journalctl is that when you "live" follow the > > output of a journal being written then the file frequently has > > half-written entries, which however will quickly be corrected as the > > entry is completed. > > But in case journald decided to rotate a journal because it is not clean > now new entries are to be expected there. Therefore journalctl should > know that the journal is broken. journalctl actually has an inotify watch on the journal dir. It will notice when a file is rotated and will immeidately add the new journal file that has been created as replaced to the files it watches and interleaves. This is all hidden inside the library btw, to ensure that clients do not need to be aware of rotation or anything and always see the full set of logs, regardless what is currently going on. > > There's "journalctl --verify" whose main purpose is to verify FSS > > seals. It will also check the integraty of the data structures in a > > journal however. > > What can be done if the verification fails? How can one get the > incomplete data in case journald rotated a journal? The tool will tell you how much of the file could be verified, starting from the beginning. For tail corruptions your normal journalctl tool will provide you with as much information as is possible to salvage from the file. It will output the last complete log line and then finish. This is pretty close to how good you can get. Things are different for corruptions in the middle. We have no nice tool for salvaging data from such corruption, but they could be written relatively easily. However, since they are highly unlikely due to the "append-only" model of the journal this hasn't been on our TODO list. Lennart -- Lennart Poettering - Red Hat, Inc. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: F20 System Wide Change: No Default Syslog
On Tue, Jul 16, 2013 at 01:43:04PM +0200, Lennart Poettering wrote: > On Tue, 16.07.13 09:42, Till Maas (opensou...@till.name) wrote: > > > > journalctl only supports local time specifications when you > > > specify calendar times. Unfortunately there's no nice API to map > > > calendar times that include time zone specifications back to UTC, in > > > particular because the time zone names are not unique... > > > While it will be hard to support arbitrary timezone specs in --since= it > > > should be relatively easy to support UTC in addition to the local > > > timezone. Added this to the TODO list. > > > > You only need to add or subtract hours and minutes from the local time, > > because ISO 8601 dates contain the UTC offset: > > > > | $ date --iso-8601=seconds > > | 2013-07-15T22:37:04+0200 > > Well, we can certainly add support for such numeric timezone specs > (added to the TODO list), but I have my doubts that this is actually > what people want to use in their day-to-day use, given that the numbers > are hard to remember. Thank you. > I am pretty sure that most folks would like to specify symbolic timezone > names, but that's hard to do due to lack of APIs for that, and the > non-uniqueness of the names. I guess for most use cases using the local time zone is enough. Btw. can journalctl output ISO 8601 dates instead of the US formated date without a year? I really expected journalctl to cleanup this as well. > > > Note that the journal actually knows a concept called "cursors". The > > > cursors are a way to refer to a specific log line (or the closest > > > available one) in a stable way. by using this you can make a logic like > > > the above work nicely, and even remove any inaccuracy regarding > > > timestamps... > > > > The manpage only mentions how to specify which cursor to use but not how > > to get the cursor of the last read line. > > journalctl -o verbose will give you that (and so will -o json, -o export > and others), but the rest of the output is very low-level then. Maybe we > can add a switch that prints the final cursor as last line if you > specify some switch. The extra switch sounds useful. Regards Till -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: F20 System Wide Change: Visible Cloud
On Tue, 16 Jul 2013 10:55:40 +0200 Florian Weimer wrote: > On 07/15/2013 12:34 PM, Daniel P. Berrange wrote: > > > I'm not suggesting we need to rebuild images for every update, but > > at a minimum, when we issue CVE / security errata that affects an > > image, I'd expect us to also rebuild and publish new cloud images > > pretty much synchronously. > > Secure Boot support could benefit from image respins as well, if we > ever start blacklisting kernels which threaten (our interpretation > of) the Secure Boot security model. Right now, this isn't necessary > because other distributions allegedly grant unrestricted ring 0 > access by design, but this might change in the future. If we do decide to do this, it would need releng/infra/qa/fesco buyin at least. I suspect it would also require more people stepping up in those areas to make it happen (unless we were willing to delay new releases to push out new security related images for existing releases). kevin signature.asc Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: F20 Self Contained Change: FreeIPA OTP UI
On Tue, 16 Jul 2013, Matthias Clasen wrote: On Tue, 2013-07-16 at 13:48 +0200, Jaroslav Reznik wrote: = Proposed Self Contained Change: FreeIPA OTP UI = https://fedoraproject.org/wiki/Changes/IPAv3OTPUI Change owner(s): Nathaniel McCallum FreeIPA will gain a user interface for managing users' OTP tokens. == Detailed description == In Fedora 19 we introduced rudimentary support for OTP in krb5 and FreeIPA. Building on this work, we are creating a management system so that tokens can be managed alongside other user attributes. Not a lot of detail in this page, but I assume the UI here is a web ui for managing this ? I would be interested in discussing the implication for the client-side UI (control-center user panel, login screen, etc). E.g.: Can we know that OTPs are in use, and disable the password change UI ? Yes, this is about FreeIPA's web UI. I think realmd could detect that OTP is enabled for the user as it will be visible in 'ipa' command line commands and in LDAP entry for the user. -- / Alexander Bokovoy -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: F20 System Wide Change: Change Packaging Guidelines to discourage requires into /bin and /sbin
On Tue, Jul 16, 2013 at 12:24:17PM +0200, Jaroslav Reznik wrote: > = Proposed System Wide Change: Change Packaging Guidelines to discourage > requires into /bin and /sbin = > https://fedoraproject.org/wiki/Changes/NoBinDeps > == Scope == > Proposal owners: None > Other developers: replace all explicit /bin/ requires with > /usr/bin/. IMHO it would be nicer if there was a rough estimate about how many packages are affected. Also it might be more efficient to just let provenpackagers do this for everyone who does not want to do it. Regards Till -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: F20 System Wide Change: No Default Syslog
On Tue, Jul 16, 2013 at 04:21:43PM +0200, Lennart Poettering wrote: > On Tue, 16.07.13 14:41, Till Maas (opensou...@till.name) wrote: > > > On Tue, Jul 16, 2013 at 01:25:54PM +0200, Lennart Poettering wrote: > > > > > I am pretty sure that is just a misunderstanding. Note that journald > > > (i.e. the *server* side) will immediately move away (i.e. "rotate") all > > > journal files that it finds have not been set to "offline" when it > > > starts up before writing, in order to make sure that it will not > > > interfere with journal files that are incompletely written (possibly > > > further corrupting them). However journalctl (i.e. the *client* side) > > > will still access the file, and interleave it with all others it finds, > > > and show it to you as far as that's possible. > > > > > > So yeah, you could say that journald will 'ignore' the file. But > > > journalctl won't, it will show them to you. And that's *good* that > > > way. That's how it *should* be. > > > > Will journalctl also mention that there is a broken jorunal file? Does > > it support to "fsck" the journal or to show the not properly referenced > > data to the admin? > > journalctl will not show you that, but libraries do see this. The reason > we don't show this in journalctl is that when you "live" follow the > output of a journal being written then the file frequently has > half-written entries, which however will quickly be corrected as the > entry is completed. But in case journald decided to rotate a journal because it is not clean now new entries are to be expected there. Therefore journalctl should know that the journal is broken. > There's "journalctl --verify" whose main purpose is to verify FSS > seals. It will also check the integraty of the data structures in a > journal however. What can be done if the verification fails? How can one get the incomplete data in case journald rotated a journal? Regards Till -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Hard link to root-owned file now fails (since Fedora 19)
On Tue, 2013-07-16 at 15:59 +0100, Richard W.M. Jones wrote: > I'm not even sure > how to do that because we want the atomic behaviour of hard links, and > we want to have qemu running as a different user (for security, oh the > irony), so there's no other obvious way to code it. Can you link to or describe the relevant algorithm/code? The file https://github.com/openstack/nova/blob/master/nova/virt/disk/vfs/guestfs.py#L94 doesn't contain an obvious call to link(). -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
