Re: Proposed F19 Feature: Cinnamon as Default Desktop
On 02/08/2013 01:39 PM, drago01 wrote: On Fri, Feb 8, 2013 at 7:47 AM, Ralf Corsepius wrote: Gnome3 and Gnome2's GUI working principles are entirely different and therefore are catering the demands of different target audiences. Citation needed for implication "is different" -> "catering the demands of different target audiences" . The main differences are: - Tiled GUI (Gnome3) vs. Menu GUI (Gnome2). - Non-configurable/"dumb" GUI-configuration (Gnome3) vs. highly customizable GUI (Gnome2). - Dynamic workspaces (Gnome3) vs. static workspaces (Gnome2). There'd be other discussworthy/questionable changes details, but I prefer not to mention them here, to avoid this thread to deviate further. Ralf -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Proposed F19 Feature: Cinnamon as Default Desktop
On 02/09/2013 12:39 PM, Michael Scherer wrote: 2) if the fedora forums poll is biased due to "default to gnome 3", then why isn't unity being more represented in the linuxquestion poll ? When talking to Ubuntu users, they are telling Unity is as biasing as Gnome3. Is it because : - Unity, by some magic reason, do not bias anything while gnome-shell does ( ie, your argument is invalidated by the data you cite ) ? AFAICT, most dissatisfied Ubuntu/Unity users quit Ubuntu for Linux MiNT. Ralf -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Add a spec template in rpmdevtools
Hi folks, 8 months ago I opened a ticket on rpmdevtools track to request the integration of a spec template. 5 months later without any response, someone made a ping on the ticket, but there was no response for now. https://fedorahosted.org/rpmdevtools/ticket/20 So my question is: Is there any living developper of rpmdevtools, just to add one file in the git repo ?... Best regards, Matthieu Saulnier -- Pour encrypter vos emails Clef GPG ID : 83288189 @ hkp://pgp.mit.edu:11371 Empreinte : CC26 692F 5205 AC8F 7912 7783 D7A7 F4C5 8328 8189 signature.asc Description: This is a digitally signed message part -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
[perl-YAML-LibYAML] Update to 0.39
commit 0b7d2f5f1520782c5ba5839a5a6d3b55349a5468
Author: Paul Howarth
Date: Tue Feb 12 09:48:52 2013 +
Update to 0.39
- New upstream release 0.39:
- Using the latest libyaml codebase
(https://github.com/yaml/libyaml/tree/perl-yaml-xs)
- Changes have been made to start moving libyaml to 1.2
perl-YAML-LibYAML.spec | 12 +---
sources|2 +-
2 files changed, 10 insertions(+), 4 deletions(-)
---
diff --git a/perl-YAML-LibYAML.spec b/perl-YAML-LibYAML.spec
index d3453fb..53c65be 100644
--- a/perl-YAML-LibYAML.spec
+++ b/perl-YAML-LibYAML.spec
@@ -1,6 +1,6 @@
Name: perl-YAML-LibYAML
-Version:0.38
-Release:4%{?dist}
+Version:0.39
+Release:1%{?dist}
Summary:Perl YAML Serialization using XS and libyaml
License:GPL+ or Artistic
Group: Development/Libraries
@@ -71,6 +71,12 @@ make test
%{_mandir}/man3/YAML::XS::LibYAML.3pm*
%changelog
+* Tue Feb 12 2013 Paul Howarth - 0.39-1
+- Update to 0.39:
+ - Using the latest libyaml codebase
+(https://github.com/yaml/libyaml/tree/perl-yaml-xs)
+ - Changes have been made to start moving libyaml to 1.2
+
* Fri Jul 20 2012 Fedora Release Engineering
- 0.38-4
- Rebuilt for https://fedoraproject.org/wiki/Fedora_18_Mass_Rebuild
@@ -112,7 +118,7 @@ make test
* Wed Sep 29 2010 jkeating - 0.34-2
- Rebuilt for gcc bug 634757
-* Fri Sep 23 2010 Marcela Mašláňová - 0.34-1
+* Fri Sep 24 2010 Marcela Mašláňová - 0.34-1
- update
* Thu Jun 3 2010 Marcela Maslanova - 0.33-1
diff --git a/sources b/sources
index 0c83e44..4100f52 100644
--- a/sources
+++ b/sources
@@ -1 +1 @@
-4aadbcf1afcce9ce087f9bffd293e43e YAML-LibYAML-0.38.tar.gz
+03dda291205c13f0cee8baac022056f7 YAML-LibYAML-0.39.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: Gnome-shell workspaces
On Sun, 2013-02-10 at 15:03 +0100, Kevin Kofler wrote: > Olav Vitters wrote: > > This has been addressed various times. In brief: Advanced buttons do not > > work. They'll be clicked every time. Tweak tool provides a different > > guarantee of stability. For instance: if you change an option in System > > Settings and it results in a bug it must be fixed asap. At the same > > time, the sloppy focus option in Tweak tool is known to have issues. And > > to avoid misunderstandings: sloppy focus has less issues with every > > release. > > Having a separate "tweak tool" is a lame workaround for lack of settings in > the official tools. The only reason such "tweak tools" exist on proprietary > operating systems is because the proprietary companies don't want to > officially support some functionality, Well, that's pretty much the case here. People providing tweaks for underlying settings that shouldn't be there, buttons and tweaks that are usually broken, untested, and unsupported. > so you need a third-party tool to > enable the hidden settings. Having an "official tweak tool" is really really > silly. It's not so much official as de facto. The settings maintainers don't spend their time on it. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Add a spec template in rpmdevtools
Hello, On 12 February 2013 07:18, Casper wrote: > Hi folks, > 8 months ago I opened a ticket on rpmdevtools track to request the > integration of a spec template. 5 months later without any response, > someone made a ping on the ticket, but there was no response for now. > https://fedorahosted.org/rpmdevtools/ticket/20 > So my question is: Is there any living developper of rpmdevtools, just > to add one file in the git repo ?... > The situation is already much better: rpmdev-newinit rpmdev-newspec cpanspec Examples: $ rpmdev-newspec -m -r 4.5 -o package.spec Generates a spec file with all the tags required for RHEL 5 systems; while the following: $ rpmdev-newspec -m -o package.spec Generates a spec file with all the tags required for RHEL 6 and Fedora systems. You can experiment with -r for the various rpm versions and there's also some logic in the command to generate the correct %post and %postun sections if the spec file has "libs" in its name. The same goes for python, etc. For perl; you can use cpanspec: $ cpanspec -m Math-Polygon-Tree This super handy tool generates a spec file that already includes license, description, version, etc. all generated from CPAN; with the "-o" switch you can also generate for older RHEL/Fedora releases. For RHEL SysV init scripts use: $ rpmdev-newinit -o package.init The various init scripts and rpm spec files do follow of course the package guidelines. Regards, --Simone -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Mass Rebuild for Fedora 19
On Mon, Feb 11, 2013 at 10:33:51PM +, Richard W.M. Jones wrote:
> ... and also anything that doesn't have config.guess/config.sub, which
> appears to be a lot of my packages for some reason. IIRC these files
> are only used/needed for cross-compiles aren't they?
I realize I was doing it wrong: these packages put the config.{guess,
sub} files into a subdirectory called build-aux, so I do have them,
and the ones I've updated recently also mention "aarch64" and
"aarch64_be".
Rich.
--
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming blog: http://rwmj.wordpress.com
Fedora now supports 80 OCaml packages (the OPEN alternative to F#)
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
[perl-YAML-LibYAML] Created tag perl-YAML-LibYAML-0.39-1.fc19
The lightweight tag 'perl-YAML-LibYAML-0.39-1.fc19' was created pointing to: 0b7d2f5... Update to 0.39 -- 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: Proposed F19 Feature: Cinnamon as Default Desktop
On 11 February 2013 22:24, Kevin Kofler wrote: > Ian Malone wrote: >> On record? Is there going to be a trial? >> What frustrates me is it's such an uphill battle. >> Step 1: Everything changes. >> Step 2: Users protest, some leave. >> Step 3: Supporters respond there's nothing wrong and essentially >> everyone who doesn't like it is too stupid or lazy. >> Step 4: Users carry on complaining. >> Step 5: Some features are gradually re-added, without ever >> acknowledging there was a problem in the first place. >> Step 6: Minor release? Go to step 4. >> Step 7: Major release? Go to step 5. > ↑ > Go to step 1, you mean? :-) > Ah yes, this'll be fixed in the next release. -- imalone http://ibmalone.blogspot.co.uk -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Proposed F19 Feature: Usermode Migration
On Mon, Feb 11, 2013 at 11:33 PM, Kevin Kofler wrote: > Matthew Miller wrote: >> Is it possible to configure utilities with the equivalent of UGROUPS=wheel >> without per-application javascript policy? Currently, we do this with >> /etc/security/console.apps/config-util. >> >> As I understand it, the javascript policy mechanism is not supposed to be >> used at the OS vendor level. But I don't see a way to do this in the >> .policy XML files either. > > Yeah, kde-settings does this with JavaScript (for kcm_clock) and I don't > think we have an easier method available ever since the support for the > simple .pkla files got dropped. > > Maybe, now that this is handled by plugins, we should write a polkit-pkla > plugin to handle this with the old simple format? I plan to provide some .pkla compatibility for F19, but I haven't decided on an implementation method yet. If anybody would like to help or has specific requirements/use cases, please contact me. Thank you, Mirek -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Proposed F19 Feature: Usermode Migration
Hello, On Mon, Feb 11, 2013 at 11:50 PM, Kevin Kofler wrote: > Jaroslav Reznik wrote: >> These days, most privileged system operations are already controlled by >> polkit, a well-established (I'll just briefly note how much polkit has changed since then...) >> For directly executed tools, polkit provides a setuid-root helper program >> called ‘’pkexec’’. > and in the details: >> python: put a pkexec invocation in the wrapping shell script >> C tools: re-exec with pkexec in C code >> C tools: move original to /usr/lib//, and wrap /usr/bin/ >> with a pkexec shell script (ugly!) > > This is falling WAY short of the advertising! pkexec entirely defeats the > purpose of using PolicyKit! Instead of having a specific permission, such as > org.kde.kcontrol.kcmclock.save, which admins can give to their users in good > conscience (even if they do NOT trust them to do anything OTHER than the > fine-grained allowance the permission represents), you have a > org.freedesktop.policykit.exec permission which is trivially equivalent to > root access (because it allows you to execute arbitrary code as any user > including root). Therefore, you degrade PolicyKit into a device to prompt > for the root password (or a wheel user password, the sudo way). It is > impossible to give out fine-grained permissions this way. I don't see what > "access control policy" other than auth_admin you'd define for > org.freedesktop.policykit.exec in an "enterprise environment"; surely you > aren't planning to give your users root access! pkexec can use fine-grained action configuration limited to a specific executable. It's even described on the feature page in the "How to Convert" section, right below the section you quoted. (True, the feature page describes it as a way to add the ...exec.allow_gui annotation, but the ability to give a separate name and defaults is equally important.) > We need a feature to actually use PolicyKit the way it was > intended, phasing out usermode, consolehelper, kdesu and pkexec all at once > wherever it is possible. That Would Be Nice™ as well, even though it is more work (especially if it also resulted in a stable and documented API for the privileged part). Three years ago bugs were filed against some of the affected components. Mirek -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: the need of "Offline Updates"
On 02/06/2013 12:02 AM, Sam Varshavchik wrote: There is even a documented way for a package to stop its services, before it gets updated, and restart it, after the update, see /var/lib/rpm-state Can you point me to such documentation, please? I found only https://bugzilla.redhat.com/show_bug.cgi?id=771713 Is there more docs about it? -- Miroslav Suchy Red Hat Systems Management Engineering -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Temperature.app orphan -new ownership reg
Hi Devel team I would like to talk up ownership for Temperature.app (devel/f18) I am trying to reach out to previous maintainers/owners/change commits contacts. Thanks and regards Richard Vijay Ambassador & Beats Editor IRC: fedora_richie pub 2048R/6528562A 2011-11-27 [expires: 2012-11-26] Key fingerprint = 6BBF 9B17 024D FFB2 0F7A D074 FB40 B025 6528 562A uid Richard Vijay (Fedora FAS 2011) ID 0x6528562A --- Revoked pub 4096R/EE834823 2011-03-14 [expires: 2012-03-14] Fingerprint = B02E D0DC 8689 CC3C 5D18 FD2E 9268 A3AF EE83 4823 sub 4096R/8CC5E914 2011-03-14 [expires: 2012-03-14] http://pgp.surfnet.nl:11371/pks/lookup?op=index&search=0xEE834823 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Proposed F19 Feature: Cinnamon as Default Desktop
On Tue, Feb 12, 2013 at 08:07:23AM +0100, Ralf Corsepius wrote: > On 02/08/2013 01:39 PM, drago01 wrote: > >On Fri, Feb 8, 2013 at 7:47 AM, Ralf Corsepius wrote: > > >>Gnome3 and Gnome2's GUI working principles are entirely different and > >>therefore are catering the demands of different target audiences. > > > >Citation needed for implication "is different" -> "catering the > >demands of different target audiences" . > > The main differences are: > - Tiled GUI (Gnome3) vs. Menu GUI (Gnome2). GNOME 3.8 will give you a combination. > - Non-configurable/"dumb" GUI-configuration (Gnome3) vs. highly > customizable GUI (Gnome2). Extensions allow for way more changes than GNOME 2.x. > - Dynamic workspaces (Gnome3) vs. static workspaces (Gnome2). You can select if you want to have dynamic workspaces or not. In 3.6 that is in gnome-tweak-tool. In 3.8 it would be part of 'classic mode' (hopefully the name will change). > There'd be other discussworthy/questionable changes details, but I > prefer not to mention them here, to avoid this thread to deviate > further. Do not see how changes result in a different target audience. -- Regards, Olav -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Add a spec template in rpmdevtools
Le mardi 12 février 2013 à 11:08 +0100, Simone Caronni a écrit : > Hello, > > The situation is already much better: > > rpmdev-newinit > rpmdev-newspec > cpanspec > > Examples: > > $ rpmdev-newspec -m -r 4.5 -o package.spec > > Generates a spec file with all the tags required for RHEL 5 systems; while > the following: > > $ rpmdev-newspec -m -o package.spec > > Generates a spec file with all the tags required for RHEL 6 and Fedora > systems. > > You can experiment with -r for the various rpm versions and there's also > some logic in the command to generate the correct %post and %postun > sections if the spec file has "libs" in its name. The same goes for python, > etc. > > For perl; you can use cpanspec: > > $ cpanspec -m Math-Polygon-Tree > > This super handy tool generates a spec file that already includes license, > description, version, etc. all generated from CPAN; with the "-o" switch > you can also generate for older RHEL/Fedora releases. > > For RHEL SysV init scripts use: > > $ rpmdev-newinit -o package.init > > The various init scripts and rpm spec files do follow of course the package > guidelines. You're right but rpmdev-newspec is provided by rpmdevtools, and rpmdev-newspec create new spec based on spectemplate already present in rpmdevtools. $ rpm -qf /usr/bin/rpmdev-newspec rpmdevtools-8.3-1.fc18.noarch $ rpm -ql rpmdevtools-8.3-1.fc18.noarch|grep spectemplate /etc/rpmdevtools/spectemplate-R.spec /etc/rpmdevtools/spectemplate-dummy.spec /etc/rpmdevtools/spectemplate-lib.spec /etc/rpmdevtools/spectemplate-minimal.spec /etc/rpmdevtools/spectemplate-ocaml.spec /etc/rpmdevtools/spectemplate-perl.spec /etc/rpmdevtools/spectemplate-php-pear.spec /etc/rpmdevtools/spectemplate-python.spec /etc/rpmdevtools/spectemplate-ruby.spec My spectemplate is just to package D programs, I would like to include it in rpmdevtools then rpmdev-newpec will be able to use it. Regards -- Pour encrypter vos emails Clef GPG ID : 83288189 @ hkp://pgp.mit.edu:11371 Empreinte : CC26 692F 5205 AC8F 7912 7783 D7A7 F4C5 8328 8189 signature.asc Description: This is a digitally signed message part -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Gnome-shell workspaces
On Mon, Feb 11, 2013 at 11:18:09PM +0100, Kevin Kofler wrote:
> Olav Vitters wrote:
> > I don't get why you reply to me. It seems anything people do is just
> > bad.
> >
> > No tweak tool: bad
> > A tweak tool: bad
>
> Strawman…
>
> What I actually mean is:
> Completely hidden or absent settings ("no tweak tool"): bad
> Settings hidden in a tweak tool: bad
> Settings available and exposed in the normal settings dialog: good
That is exactly what I mean: I explained why it is not in the main
dialog. The setting is available. There is a GUI. Still bad, has to be
done in yet another way.
For instance:
"Settings hidden in a tweak tool": Those settings aren't hidden.
There was a nice post by a developer at Microsoft on settings. First
there would be a request for a setting. Eventually it would be added to
the registry. Then exposed somewhere else. Eventually in the main
program. Every step hugely increases the amount of work that has to be
done. I tried finding the blogpost, but very unfortunately could not.
> > If the only thing you can do is complain about the work that other
> > people do, find another hobby or something.
>
> This ad hominem attack deserves no reply.
You call ad hominem and strawman way too quickly. Suggest not claiming
stuff like "Settings hidden in a tweak tool", as that is just not true.
I could look up what term is used for that, but cannot be bothered.
--
Regards,
Olav
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Gnome-shell workspaces
On Mon, Feb 11, 2013 at 11:20:04PM +0100, Kevin Kofler wrote: > Olav Vitters wrote: > > PS: http://en.wikipedia.org/wiki/Tweak_UI > > It was written by one individual employee and released as an unsupported > tool. It'd have been a third-party tool if the author didn't happen to be an > M$ employee. GNOME tweak tool was written by one developer and released as a unsupported tool. It'd would have been an unsupported tool if we didn't change our mind based on user feedback. The settings itself still might expose bugs. Pretty much the same as same as what happened with tweak UI? M$ is boring btw, use MS or Microsoft. -- Regards, Olav -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Proposed F19 Feature: Cinnamon as Default Desktop
On Mon, Feb 11, 2013 at 11:37:31AM +0100, Reindl Harald wrote: > Am 11.02.2013 11:31, schrieb Olav Vitters: > > On Sun, Feb 10, 2013 at 07:59:22PM +, Ian Malone wrote: > >> In the end, more than any usability quibbles, the best reason to give > >> up on a project is when it refuses to listen to its end users. > > > > The GNOME release notes over various cycles have listed loads of changes > > which have been made based on the things that have been learned. This > > happened during 2.x as well as 3.x. > > > > Although you do not explicitly state it, it seems you were talking about > > GNOME. Vincent Untz phrased it much better than I ever could, but he > > basically pointed at the "Power Off". You can also read the release > > notes for loads of other changes > > this is all fine > > BUT why are things completly re-written and in a pre-alpha state > released replacing and destroying the users workload and after > that it takes years to fix all teh issues in the one or another way? I have a totally different view. Could you show me the bugreport about where GNOME destroyed something on a users machine? GNOME 3 was delayed by 2 cycles. Before that we made loads of releases available for testing. The 3.0 was really stable. > this big mistakes are happening over and over and the speed > these are happening is growing with each compontent instead > learn from mistakes and release software after it is finished > or do not make a rewrite at all Conflicts with release early and release often and the difference between testing by 50 people and releasing it for 500.000+. > it does users not help much if 2-3 years later things starting > to get useable again - why? because in the meantime someone > is changing the next subsystem against a pre-alpha and years > later people are proud to have fixed a lot of issues while > forget that they all were introduced by release unready software That was addressed by Vincent during FOSDEM. I mean: - real usability testing (help welcome!) I mean huge groups, non-biased, representing everyone, etc - real studies on biggest issues (help welcome!) I don't mean an internet survey, or a study where the outcome is 'do what some other OS does'. I mean something which is a followup on what Sun did ages ago. - better communication (help welcome!) Sometimes a huge difference to what is decided/planned and what news sites announce e.g. the poweroff I wanted to see changed more quickly. It could've, but a study would've sped it up greatly. I mean a huge usability study at least every 2 years, and smaller ones after each release. This to address the difference between: - one developer working on something - a few developers (project gets a few developers) - 50+ developers (jhbuild people) - 500+ people (tarballs/unstable packages) - 5000+? people (beta cycle - 3.x.0) - nothing - 500.000+? (distro release) Every time the number of people increases 10-fold, you'll find more issues. Expecting that a few developers will ever release something that would be good enough for 500.000 is just unrealistic. -- Regards, Olav -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Proposed F19 Feature: systemd/udev Predictable Network Interface Names
On Thu, Feb 07, 2013 at 09:22:40PM -0600, Kay Sievers wrote:
> On Thu, Feb 7, 2013 at 7:12 AM, Matt Domsch wrote:
>
> >We
> >will need a method to enable/disable on a per-vendor basis as we
> >added to RHEL in the udev rules that invoke (or don't) biosdevname.
> >The suggestion of linking in (or not) rules files won't work for a
> >distro-wide per-vendor configuration.
>
> Udev rules are installed in /usr/lib and can be "masked" by creating
> empty files in /etc with the same file name. That way entire rules
> files can be enabled/disabled, if needed.
I am concerned about the naming convention at installtime. The
current proposal removes biosdevname from comps @core as mandatory,
and I presume would also remove it from the anaconda install
environment as well. This leaves the kernel default naming scheme,
which we agree is poor. So I also presume this proposal will be
extended to enable systemd/udevd naming at installtime, which for all
network installs the device naming is prompted for on screen and/or
read from kickstart files. In this proposal there is no way to use
biosdevname names at installtime, or disable systemd/udevd names
entirely if so desired (akin to biosdevname=0 on the kernel command
line). The RHEL model of disabling biosdevname by some hardware
vendors, at installtime, is not accounted for in the current proposal.
> If needed, we could add a kernel command line option to the rules too.
We do need this. We also need to be able to enable biosdevname at
installtime, again by kernel command line. The existing biosdevname=1
flag seems a good choice.
I am less concerned about runtime, as actions can be taken at runtime
to enable/disable/change the naming conventions for future boots. I
agree anything can be done at runtime given a smart system
administrator (as much as I would like not to rely on a smart system
administrator for each install).
> > C) There are several cases that biosdevname handles that udev doesn't
> >(yet) - NPAR and SR-IOV at least. These are widely used in Dell
> >and other vendors' servers.
>
> These SR-IOV show up with their own PCI function number in the kernel
> and they are unique that way. From my point of view this is good
> enough and we don't need to do anything here. If people want "pretty"
> names they should provide custom and meaningful names on their own.
> Udev does not want to establish any cross-device relations for naming,
> and only look at the single device it is currently handling.
I disagree that users should provide their own "pretty" names, when we
do have all the information we need about these devices to provide
"pretty" names by default ourselves. By the same argument, I don't
need anything more from systemd/udevd now than I've had for years with
70-persistent-net.rules files.
There are very good reasons to, in the device name, identify the
separate (to the kernel) devices that represent the same physical
cable jack. Dell's engineers have been adding code to the bonding
driver to recognize when someone is bonding two kernel devices that
share a single physical cable jack, as that's not usually the intended
configuration. With the growing set of "applicance distributions"
that auto-configure bonding across all visible network devices, this
is even more important.
The biosdevname convention of using _{1234} to identify such
sub-devices is mirrored in your convention of appending f{1234}.
Which works until you get to single PCI b/d/f devices with multiple
ports (e.g. Mellanox adapters), after which you need further
information to disambiguate the network devices. The biosdevname
maintainers are trying to tackle this right now.
> > D) the udev scheme will run out of characters in IFNAMSIZ (you've got
> >at most 15 chars to work with,
>
> Sure, it's an unfortunate kernel limitation we have to live with. We
> just do not rename anything if the name we composed does not fit. It's
> not really a problem, more an exotic corner case that can be
> covered/fixed by custom config if it really happens.
>
> >really less 5 because decimal-based
> >VLAN tagging is allowed, hence MAC-based won't fit).
>
> VLANS do not need to be named with their number in the network device
> name, they are created by custom config and not by detected hardware,
> so the naming problem can be solved at that level too, instead of the
> hardware-centric view udev has. For now, all VLANs are ignored by
> udev.
VLAN devices are created in userspace by vconfig, with its own naming
policy:
* name-type: VLAN_PLUS_VID (vlan0005), VLAN_PLUS_VID_NO_PAD (vlan5),
DEV_PLUS_VID (eth0.0005), DEV_PLUS_VID_NO_PAD (eth0.5)
I agree udev doesn't need to know about them explicitly, but the
naming convention does need to account for that use of IFNAMSIZ space.
> I think userspace enumeration as a general concept to start with
> cannot work on today's systems. With a few exceptions, no device
> naming should ever look
Re: the need of "Offline Updates"
On 05.02.2013 13:21, Reindl Harald wrote: > the whole discussion abiut offline updates and why yum is not so good > for dist-upgrades is from the wrong point of view, most of the problems > are only existing because with each release working things are mangeled > > actual example: > https://bugzilla.redhat.com/show_bug.cgi?id=907749 > https://bugzilla.redhat.com/show_bug.cgi?id=887763#c20 > > bothing bad would happen if the package would not touch > /etc/mtab > > > the same for updates of services: > > nothing would happen on a webserver with httpd if it would not be > restarted at package-update which goes wrong if you are using PHP > and packages of the dep-tree are not yet all updated which fails > PHP to load, without the hardcoded restart httpd would happily > continue to run with the old php-package from memory > > so all the problems which are statet against yum-upgrades > are introdouced about the last 5-6 years and were not > existing before > > what currently happens is that more and more HARD-WIRED > cross-dependencies are introduced, more and more magic > ist introduced and at the end of the road we will be on > the windows way "you touched anything on the system and > so please reboot now" > > > The real problem is that we don't distinguish updates of packages between distro versions e.g. F17 to F18 and updates "inside" one release. This second kind of updates should never break and need reboot (only service restart). I can agree that after upgrading from one version of Fedora to another reboot is required (e.g. to reload C standard library to newer version or to start with the new kernel). But this requires that there are only non-breaking updates of software or devels precisely know what might blow up which is hard to do. It's because of poor project management lack of stable branches of software and need of new exciting features. It was very different 15 years ago. I can remember Torvalds laughing at Windows software and its need of rebooting and inability to remove opened file. Now Linux is going the same direction. Reboot every time you upgrade text editor. Mateusz Marzantowicz -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [soundtracker/f18] (2 commits) ...Correct desktop file install error
On Mon, Feb 11, 2013 at 10:25:47AM +0100, Brendan Jones wrote: > On 02/11/2013 10:16 AM, Mamoru TASAKA wrote: > >Brendan Jones wrote, at 02/11/2013 05:22 PM +9:00: > >>Summary of changes: > >> > >> faf3146... Remove vendor from desktop file (*) > >> 330426b... Correct desktop file install error (*) > >> > >>(*) This commit already existed in another branch; no separate mail sent > > > >No, removing vendor prefix from desktop file must only on F-19, > >not on stable release (on F-18, F-17). Please revert this, > >thank you. > > > >Regards, > >Mamoru > > > > > > > Why is that, it can't hurt can it? I didn't think the vendor was in > use at all. "Existing packages that use a vendor tag must continue to do so for the life of the package. This is mostly for the sake of menu-editing (which bases off of .desktop file/path names)." (Other pieces of software may also make assumptions about the name of the desktop files being important and stable... we just thought that this was sufficient reason in and of itself). The FPC has recently modified this guideline to allow for removing --vendor in F19. This will cause users to suffer from the above problems when transitioning from F18 to F19 but only between F18 and F19. If we committed the same change to previous releases, then users could suffer from the problems when they upgrade a package inside of a release or when upgrading from an even earlier release in addition to the F18 to F19 breakage. -Toshio pgpiCk4WK2QHE.pgp Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Proposed F19 Feature: Scala 2.10
This Feature has been submitted *before* Feature Submission Deadline and it required input/changes from the owner or was queued. = Features/Scala210 = https://fedoraproject.org/wiki/Features/Scala210 Feature owner(s): Jochen Schmitt Providing the most current relase of Scala a functional programming language based on the JVM. == Detailed description == Scala 2.10 is an update of the scala programming language. This is a functional programming langage based on the JVM. This release contains language enhancements which may affected existing scala progjects of fedora users. This release support jdk-1.7 and contains support of the swing module in opposite of the official upstream release. This was done by a request of fedora users for a previous release on based of a patch from the upstream development repository. Additionally it's requires packages which doesn't available in fedora until yes. ___ 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: the need of "Offline Updates"
Am 12.02.2013 13:52, schrieb Miroslav Suchý: > On 02/06/2013 12:02 AM, Sam Varshavchik wrote: >> There is even a documented way for a package to stop its services, >> before it gets updated, and restart it, after the update, see >> /var/lib/rpm-state the point is that i NEVER EVER want to stop any service by a RPM update and define this GLOBAL for all services with one single config line signature.asc Description: OpenPGP digital signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Proposed F19 Feature: Cinnamon as Default Desktop
Am 12.02.2013 15:47, schrieb Olav Vitters: > On Mon, Feb 11, 2013 at 11:37:31AM +0100, Reindl Harald wrote: >> Am 11.02.2013 11:31, schrieb Olav Vitters: >>> On Sun, Feb 10, 2013 at 07:59:22PM +, Ian Malone wrote: In the end, more than any usability quibbles, the best reason to give up on a project is when it refuses to listen to its end users. >>> >>> The GNOME release notes over various cycles have listed loads of changes >>> which have been made based on the things that have been learned. This >>> happened during 2.x as well as 3.x. >>> >>> Although you do not explicitly state it, it seems you were talking about >>> GNOME. Vincent Untz phrased it much better than I ever could, but he >>> basically pointed at the "Power Off". You can also read the release >>> notes for loads of other changes >> >> this is all fine >> >> BUT why are things completly re-written and in a pre-alpha state >> released replacing and destroying the users workload and after >> that it takes years to fix all teh issues in the one or another way? > > I have a totally different view. > > Could you show me the bugreport about where GNOME destroyed something on > a users machine? > > GNOME 3 was delayed by 2 cycles. Before that we made loads of releases > available for testing. The 3.0 was really stable what are you not understanding in "destroy users workload"? it dies not help if software runs stable if it forces the user to completly re-learn how he used to do things workload = people are runnign their PC for working with it and doing things not only play around with the OS itself signature.asc Description: OpenPGP digital signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Should MariaDB touch my.cnf in %post?
Hi folks,
I'd like to share an idea related to MySQL->MariaDB move, that may be a
bit controversial. Speaking about default case in Fedora, MySQL has used
only one file at /etc/my.cnf to configure server, libraries,
command-line utilities, etc.
MariaDB uses by default /etc/my.cnf and
/etc/my.cnf.d/{client,server,..}.cnf files, while all the /etc/my.cnf.d
directory is included using !includedir statement in /etc/my.cnf.
The problem is, that after replacing MySQL with MariaDB existed my.cnf
won't get updated (uses "%config(noreplace)") and then users will be
confused by having /etc/my.cnf.d/* files, which won't be used.
A solution proposed by MariaDB upstream would be adding !includedir
directive into /etc/my.cnf (if not already done) in mariadb's %post
section. That would mean *modifying user's configuration during RPM update*.
I haven't found any restriction forbidding this solution, but would like
to collect opinions, how bad it is, because we're aware it's not very
clean -- however, it has it's benefits.
In case user won't wish to use !includedir anymore, he'd comment it out
and it won't get added again.
Cheers,
Honza
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Should MariaDB touch my.cnf in %post?
Am 12.02.2013 18:46, schrieb Honza Horak:
> I'd like to share an idea related to MySQL->MariaDB move, that may be a bit
> controversial. Speaking about default
> case in Fedora, MySQL has used only one file at /etc/my.cnf to configure
> server, libraries, command-line utilities,
> etc.
>
> MariaDB uses by default /etc/my.cnf and /etc/my.cnf.d/{client,server,..}.cnf
> files, while all the /etc/my.cnf.d
> directory is included using !includedir statement in /etc/my.cnf.
>
> The problem is, that after replacing MySQL with MariaDB existed my.cnf won't
> get updated (uses
> "%config(noreplace)") and then users will be confused by having
> /etc/my.cnf.d/* files, which won't be used.
>
> A solution proposed by MariaDB upstream would be adding !includedir directive
> into /etc/my.cnf (if not already
> done) in mariadb's %post section. That would mean *modifying user's
> configuration during RPM update*.
>
> I haven't found any restriction forbidding this solution, but would like to
> collect opinions, how bad it is,
> because we're aware it's not very clean -- however, it has it's benefits.
>
> In case user won't wish to use !includedir anymore, he'd comment it out and
> it won't get added again.
please do not touch /etc/my.cnf
any real used mysqld will have a customized /etc/my.cnf and no admin
should do this migartion without take really care what happens and
test this before - unclean soltutions will hurt sooner or later
in moments where this is not expected
signature.asc
Description: OpenPGP digital signature
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Proposed F19 Feature: Cinnamon as Default Desktop
On Tue, Feb 12, 2013 at 03:50:56PM +0100, Reindl Harald wrote: > > > Am 12.02.2013 15:47, schrieb Olav Vitters: > > On Mon, Feb 11, 2013 at 11:37:31AM +0100, Reindl Harald wrote: > >> Am 11.02.2013 11:31, schrieb Olav Vitters: > >>> On Sun, Feb 10, 2013 at 07:59:22PM +, Ian Malone wrote: > In the end, more than any usability quibbles, the best reason to give > up on a project is when it refuses to listen to its end users. > >>> > >>> The GNOME release notes over various cycles have listed loads of changes > >>> which have been made based on the things that have been learned. This > >>> happened during 2.x as well as 3.x. > >>> > >>> Although you do not explicitly state it, it seems you were talking about > >>> GNOME. Vincent Untz phrased it much better than I ever could, but he > >>> basically pointed at the "Power Off". You can also read the release > >>> notes for loads of other changes > >> > >> this is all fine > >> > >> BUT why are things completly re-written and in a pre-alpha state > >> released replacing and destroying the users workload and after > >> that it takes years to fix all teh issues in the one or another way? > > > > I have a totally different view. > > > > Could you show me the bugreport about where GNOME destroyed something on > > a users machine? > > > > GNOME 3 was delayed by 2 cycles. Before that we made loads of releases > > available for testing. The 3.0 was really stable > > what are you not understanding in "destroy users workload"? > it dies not help if software runs stable if it forces the > user to completly re-learn how he used to do things > > workload = people are runnign their PC for working with it and > doing things not only play around with the OS itself Did you read my email at all? In any case: "destroy users workload" In my understanding: 1. You're really angry (aka "destroy": wtf!) 2. I have a totally different view 3. It seems you can speak on every users behalf (related to #2) Note that #2 I already quoted, aside from the things you snipped which gave IMO a friendly explanation. In any case, we can also turn this into a offlist flamewar if you want. -- Regards, Olav -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
ConsoleKit and esound retirement
Heya, since a while now logind has replaced CK in Fedora. I'd like to retire it entirely from the distribution now. Most deps on CK are gone. Holdouts are "cdm", "lightdm", "lxsession", "lxdm". https://fedoraproject.org/wiki/How_to_remove_a_package_at_end_of_life This page doesn't say anything about retiring packages other still depend on... I am tempted to just retire CK ignoring the remaining dependencies, in the hope this will put the pressure on the folks involved to update their stuff... Getting rid of CK in those packages is dead simple BTW. Just disable it in the packages, but make sure pam_systemd is in the PAM stack for your greeter tool. It's basically about removing code, not about adding new code -- adding new code is only necessary if you want to improve your DM to handle multi-seat setups, too (which is a new feature of logind, not available in CK[1]). For details, see: http://www.freedesktop.org/wiki/Software/systemd/writing-display-managers I'd also like to retire "esound" finally. Currently, adplay, ayttm, dopewars, e16, gnome-libs, gnubg, lxdream, moon-buggy, spacechart, xarchon, xmms-esd still use it. esd of course has been deprecated and dead since many years, the packages which still use it really should wake up one day. So here, too, I'd just like to retire the package... Alternatively, somebody else can take these over, but honstely I'd rather see them removed than continue to bitrot in our repository... Lennart Footnotes: [1] If you are interested in adding proper multi-seat support to the DM of your choice, then we might be able to supply you with a free set of multi-seat hardware so that you can actually make it work. Ping me. -- Lennart Poettering - Red Hat, Inc. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Should MariaDB touch my.cnf in %post?
On Tue, Feb 12, 2013 at 06:46:28PM +0100, Honza Horak wrote:
> Hi folks,
>
> I'd like to share an idea related to MySQL->MariaDB move, that may be
> a bit controversial. Speaking about default case in Fedora, MySQL has
> used only one file at /etc/my.cnf to configure server, libraries,
> command-line utilities, etc.
>
> MariaDB uses by default /etc/my.cnf and
> /etc/my.cnf.d/{client,server,..}.cnf files, while all the
> /etc/my.cnf.d directory is included using !includedir statement in
> /etc/my.cnf.
>
> The problem is, that after replacing MySQL with MariaDB existed
> my.cnf won't get updated (uses "%config(noreplace)") and then users
> will be confused by having /etc/my.cnf.d/* files, which won't be
> used.
>
> A solution proposed by MariaDB upstream would be adding !includedir
> directive into /etc/my.cnf (if not already done) in mariadb's %post
> section. That would mean *modifying user's configuration during RPM
> update*.
>
> I haven't found any restriction forbidding this solution, but would
> like to collect opinions, how bad it is, because we're aware it's not
> very clean -- however, it has it's benefits.
>
> In case user won't wish to use !includedir anymore, he'd comment it
> out and it won't get added again.
>
Bad idea.
There are several reasons that user's config files shouldn't be touched:
* Possibility of getting the change to the user's config wrong is very high
as user's can change their config in arbitrary ways. Do you handle the
case where a user has added their own includedirs? Do you handle the case
where a user has commented out their own includedir? Do you handle the
case where a user has a comment about includedir? Do you handle the case
where a user has deleted the includedir line? There are many corner cases
that can be missed here.
* User expectation is currently that their configs aren't going to change on
version upgrade. Instead, they need to look for .rpmnew and .rpmsave
files to tell them if anything has changed that they need to be aware of.
A user updating to F19 won't be expecting that files in /etc/my.cnf.d
should affect their installation if they didn't have to migrate that over
from the my.cnf.rpmnew file themselves.
be sure to add this change and how upgraders should handle it to the release
notes :-)
-Toshio
pgpFopCPQl27B.pgp
Description: PGP signature
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Re: ConsoleKit and esound retirement
On Tue, Feb 12, 2013 at 12:34 PM, Lennart Poettering wrote: > Heya, > > since a while now logind has replaced CK in Fedora. I'd like to retire > it entirely from the distribution now. > > Most deps on CK are gone. Holdouts are "cdm", "lightdm", "lxsession", > "lxdm". > > https://fedoraproject.org/wiki/How_to_remove_a_package_at_end_of_life > > This page doesn't say anything about retiring packages other still > depend on... > > I am tempted to just retire CK ignoring the remaining dependencies, in > the hope this will put the pressure on the folks involved to update > their stuff... > > Getting rid of CK in those packages is dead simple BTW. Just disable it > in the packages, but make sure pam_systemd is in the PAM stack for your > greeter tool. It's basically about removing code, not about adding > new code -- adding new code is only necessary if you want to improve > your DM to handle multi-seat setups, too (which is a new feature of > logind, not available in CK[1]). For details, see: > > http://www.freedesktop.org/wiki/Software/systemd/writing-display-managers > > I'd also like to retire "esound" finally. Currently, adplay, ayttm, > dopewars, e16, gnome-libs, gnubg, lxdream, moon-buggy, spacechart, > xarchon, xmms-esd still use it. esd of course has been deprecated and > dead since many years, the packages which still use it really should > wake up one day. So here, too, I'd just like to retire the package... > > Alternatively, somebody else can take these over, but honstely I'd > rather see them removed than continue to bitrot in our repository... > So to clarify, you're not actually retiring anything currently, just expressing to the community that you'd like to and that we should work toward making that possible? If so, do you have any guidelines on getting rid of esound requirements? -J > Lennart > > Footnotes: > > [1] If you are interested in adding proper multi-seat support to the DM > of your choice, then we might be able to supply you with a free set of > multi-seat hardware so that you can actually make it work. Ping me. > > -- > Lennart Poettering - Red Hat, Inc. > -- > devel mailing list > devel@lists.fedoraproject.org > https://admin.fedoraproject.org/mailman/listinfo/devel -- http://cecinestpasunefromage.wordpress.com/ in your fear, seek only peace in your fear, seek only love -d. bowie -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
File Wx-0.9917.tar.gz uploaded to lookaside cache by spot
A file has been added to the lookaside cache for perl-Wx: 0d398d4c78c86267440ac58d52dc64db Wx-0.9917.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
[perl-Wx] 0.9917
commit 0a6e8b0cfc949dff4d9d8e8fdc8bcb9e56afefe5
Author: Tom Callaway
Date: Tue Feb 12 13:49:07 2013 -0500
0.9917
.gitignore |1 +
perl-Wx.spec |5 -
sources |2 +-
3 files changed, 6 insertions(+), 2 deletions(-)
---
diff --git a/.gitignore b/.gitignore
index e81e398..eb16cef 100644
--- a/.gitignore
+++ b/.gitignore
@@ -13,3 +13,4 @@ Wx-0.92.tar.gz
/Wx-0.9914.tar.gz
/Wx-0.9915.tar.gz
/Wx-0.9916.tar.gz
+/Wx-0.9917.tar.gz
diff --git a/perl-Wx.spec b/perl-Wx.spec
index feb91d2..2ffc496 100644
--- a/perl-Wx.spec
+++ b/perl-Wx.spec
@@ -11,7 +11,7 @@
# cat provides.txt | uniq | sort -n
Name: perl-Wx
-Version:0.9916
+Version:0.9917
Release:1%{?dist}
Summary:Interface to the wxWidgets cross-platform GUI toolkit
Group: Development/Libraries
@@ -704,6 +704,9 @@ chmod -R u+w $RPM_BUILD_ROOT/*
%{_mandir}/man3/*.3pm*
%changelog
+* Tue Feb 12 2013 Tom Callaway - 0.9917-1
+- update to 0.9917
+
* Sun Jan 20 2013 Tom Callaway - 0.9916-1
- update to 0.9916
diff --git a/sources b/sources
index 567285c..f6d087b 100644
--- a/sources
+++ b/sources
@@ -1 +1 @@
-9f67d3935ce0848ec5e361e2e4e9fb3b Wx-0.9916.tar.gz
+0d398d4c78c86267440ac58d52dc64db Wx-0.9917.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: ConsoleKit and esound retirement
On Tue, 12.02.13 12:38, Jon Ciesla (limburg...@gmail.com) wrote: > On Tue, Feb 12, 2013 at 12:34 PM, Lennart Poettering > wrote: > > > Heya, > > > > since a while now logind has replaced CK in Fedora. I'd like to retire > > it entirely from the distribution now. > > > > Most deps on CK are gone. Holdouts are "cdm", "lightdm", "lxsession", > > "lxdm". > > > > https://fedoraproject.org/wiki/How_to_remove_a_package_at_end_of_life > > > > This page doesn't say anything about retiring packages other still > > depend on... > > > > I am tempted to just retire CK ignoring the remaining dependencies, in > > the hope this will put the pressure on the folks involved to update > > their stuff... > > > > Getting rid of CK in those packages is dead simple BTW. Just disable it > > in the packages, but make sure pam_systemd is in the PAM stack for your > > greeter tool. It's basically about removing code, not about adding > > new code -- adding new code is only necessary if you want to improve > > your DM to handle multi-seat setups, too (which is a new feature of > > logind, not available in CK[1]). For details, see: > > > > http://www.freedesktop.org/wiki/Software/systemd/writing-display-managers > > > > I'd also like to retire "esound" finally. Currently, adplay, ayttm, > > dopewars, e16, gnome-libs, gnubg, lxdream, moon-buggy, spacechart, > > xarchon, xmms-esd still use it. esd of course has been deprecated and > > dead since many years, the packages which still use it really should > > wake up one day. So here, too, I'd just like to retire the package... > > > > Alternatively, somebody else can take these over, but honstely I'd > > rather see them removed than continue to bitrot in our repository... > > So to clarify, you're not actually retiring anything currently, just > expressing to the community that you'd like to and that we should work > toward making that possible? Well, I am just checking before I do something whether I can actually do it. That's all. By next week or so I will either have retired the packages (which I'd prefer) or somebody else took them over (which I'd prefer not to do, but which we can do too, if the retro-computing folks step up...) > If so, do you have any guidelines on getting rid of esound requirements? Dunno really. My suspicion is that the packages in question are either obsolete on their own, or should just be compiled with --disable-esd or so. These packages all look pretty much esoteric or obsolete to me, so I am not really that curious what precisely packagers would need to do... Lennart -- Lennart Poettering - Red Hat, Inc. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: ConsoleKit and esound retirement
On Tue, Feb 12, 2013 at 1:12 PM, Lennart Poettering wrote: > On Tue, 12.02.13 12:38, Jon Ciesla (limburg...@gmail.com) wrote: > > > On Tue, Feb 12, 2013 at 12:34 PM, Lennart Poettering > > wrote: > > > > > Heya, > > > > > > since a while now logind has replaced CK in Fedora. I'd like to retire > > > it entirely from the distribution now. > > > > > > Most deps on CK are gone. Holdouts are "cdm", "lightdm", "lxsession", > > > "lxdm". > > > > > > https://fedoraproject.org/wiki/How_to_remove_a_package_at_end_of_life > > > > > > This page doesn't say anything about retiring packages other still > > > depend on... > > > > > > I am tempted to just retire CK ignoring the remaining dependencies, in > > > the hope this will put the pressure on the folks involved to update > > > their stuff... > > > > > > Getting rid of CK in those packages is dead simple BTW. Just disable it > > > in the packages, but make sure pam_systemd is in the PAM stack for your > > > greeter tool. It's basically about removing code, not about adding > > > new code -- adding new code is only necessary if you want to improve > > > your DM to handle multi-seat setups, too (which is a new feature of > > > logind, not available in CK[1]). For details, see: > > > > > > > http://www.freedesktop.org/wiki/Software/systemd/writing-display-managers > > > > > > I'd also like to retire "esound" finally. Currently, adplay, ayttm, > > > dopewars, e16, gnome-libs, gnubg, lxdream, moon-buggy, spacechart, > > > xarchon, xmms-esd still use it. esd of course has been deprecated and > > > dead since many years, the packages which still use it really should > > > wake up one day. So here, too, I'd just like to retire the package... > > > > > > Alternatively, somebody else can take these over, but honstely I'd > > > rather see them removed than continue to bitrot in our repository... > > > > So to clarify, you're not actually retiring anything currently, just > > expressing to the community that you'd like to and that we should work > > toward making that possible? > > Well, I am just checking before I do something whether I can actually do > it. That's all. By next week or so I will either have retired the > packages (which I'd prefer) or somebody else took them over (which I'd > prefer not to do, but which we can do too, if the retro-computing folks > step up...) > > I'd prefer that you orphan them, and mail the list, ccing -owner for each dependency, that you're doing so. That said, I maintain gnugb, and was able to easily remove the esound requirement. If no one else wants to maintain esound, I will, even if only long enough to excise it from the packages that need it. > > If so, do you have any guidelines on getting rid of esound requirements? > > Dunno really. My suspicion is that the packages in question are either > obsolete on their own, or should just be compiled with --disable-esd or > so. These packages all look pretty much esoteric or obsolete to me, so I > am not really that curious what precisely packagers would need to do... > Obsolete is in the eye of the beholder. I don't think games ever truly are. ;) -J > > Lennart > > -- > Lennart Poettering - Red Hat, Inc. > -- > devel mailing list > devel@lists.fedoraproject.org > https://admin.fedoraproject.org/mailman/listinfo/devel -- http://cecinestpasunefromage.wordpress.com/ in your fear, seek only peace in your fear, seek only love -d. bowie -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Add a spec template in rpmdevtools
On 2013-02-12 08:18, Casper wrote: > So my question is: Is there any living developper of rpmdevtools, I'm alive, but haven't been doing much at all wrt rpmdevtools lately. > just to add one file in the git repo ?... I'm afraid it's not quite that simple. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Should MariaDB touch my.cnf in %post?
Hi! On Feb 12, Honza Horak wrote: >> grep -q '!includedir /etc/my.cnf.d' /etc/my.cnf || \ >> (echo; echo '!includedir /etc/my.cnf.d') >> /etc/my.cnf > > Thanks for that idea. It would work, but honestly I'm not sure if we > want touch my.cnf during update. I've shared this idea with other > fedora developers to collect their opinions -- feel free to join the > discussion at: > > http://lists.fedoraproject.org/pipermail/devel/2013-February/178475.html So, here I am, replying... On Feb 12, Reindl Harald wrote > any real used mysqld will have a customized /etc/my.cnf and no admin > should do this migartion without take really care what happens and > test this before - unclean soltutions will hurt sooner or later > in moments where this is not expected The solution in my email was clean, as far as I could see. /etc/my.cnf.d directory is empty in our packages (there are files in it, but they contist of comment lines only), so it cannot break anything if added to my.cnf On Feb 12, Toshio Kuratomi wrote > There are several reasons that user's config files shouldn't be touched: > > * Possibility of getting the change to the user's config wrong is very high > as user's can change their config in arbitrary ways. Do you handle the > case where a user has added their own includedirs? Do you handle the case > where a user has commented out their own includedir? Do you handle the > case where a user has a comment about includedir? Do you handle the case > where a user has deleted the includedir line? There are many corner cases > that can be missed here. Yes, it handles the case where a user has added his own includedirs. Yes, it handles the case where a user has commented out his own includedir. Yes, it handles the case where a user has a comment about includedir. Yes and no. If the user has deleted the includedir line, it will be added back. It is, probably, not what the user wants [thus "no"], but achieves exactly the same effect as the other proposed solution (automatically read files in /etc/my.cnf.d/ no matter what's in /etc/my.cnf) [thus "yes"] > * User expectation is currently that their configs aren't going to change on > version upgrade. Instead, they need to look for .rpmnew and .rpmsave > files to tell them if anything has changed that they need to be aware of. > A user updating to F19 won't be expecting that files in /etc/my.cnf.d > should affect their installation if they didn't have to migrate that over > from the my.cnf.rpmnew file themselves. Okay, so you suggest to do nothing - neither append the includedir line to the existing my.cnf nor let mariadb read /etc/my.cnf.d/ automatically and implicitly. That's fine :) I was only trying to find an alternative to "let mariadb read /etc/my.cnf.d implicitly" - because I don't like an idea of adding more magic to the server, it has more than enough of it already. Regards, Sergei -- MariaDB.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Schedule for Wednesday's FESCo Meeting (2013-02-13)
Following is the list of topics that will be discussed in the FESCo meeting Wednesday at 18:00UTC (1:00pm EST, 19:00 CET) in #fedora-meeting on irc.freenode.net. Links to all tickets below can be found at: https://fedorahosted.org/fesco/report/9 = Followups = #topic #896 Refine feature process .fesco 896 https://fedorahosted.org/fesco/ticket/896 #topic #980 Add "activate contingency" points to the features process .fesco 980 https://fedorahosted.org/fesco/ticket/980 #topic #1005 At f19 branching time, drop inheritance in rawhide .fesco 1005 https://fedorahosted.org/fesco/ticket/1005 #topic #988 F19 Feature: System Configuration Shell - https://fedoraproject.org/wiki/Features/SystemConfigurationShell .fesco 988 https://fedorahosted.org/fesco/ticket/988 #topic #1036 F19 Feature: Enterprise / distributed two-factor authentication - https://fedoraproject.org/wiki/Features/EnterpriseTwoFactorAuthentication .fesco 1036 https://fedorahosted.org/fesco/ticket/1036 #topic #1040 F19 Feature: firewalld Lockdown - https://fedoraproject.org/wiki/Features/FirewalldLockdown .fesco 1040 https://fedorahosted.org/fesco/ticket/1040 = New business = FESCo members please add your list of features to discuss in ticket or have it ready for the meeting at this time. #topic #1085 2013-02-13 meeting feature voting .fesco 1085 https://fedorahosted.org/fesco/ticket/1085 #topic #1078 F19 Feature: Less Brittle Kerberos - https://fedoraproject.org/wiki/Features/LessBrittleKerberos .fesco 1078 https://fedorahosted.org/fesco/ticket/1078 #topic #1079 F19 Feature: QXL/Spice KMS Driver - https://fedoraproject.org/wiki/Features/QXLKMSSupport .fesco 1079 https://fedorahosted.org/fesco/ticket/1079 #topic #1080 F19 Feature: Virt Device Failover - https://fedoraproject.org/wiki/Features/Virt_Device_Failover .fesco 1080 https://fedorahosted.org/fesco/ticket/1080 #topic #1081 F19 Feature: Yesod Web Framework - https://fedoraproject.org/wiki/Features/YesodWebFramework .fesco 1081 https://fedorahosted.org/fesco/ticket/1081 #topic #1082 F19 Feature: Virt Storage Migration - https://fedoraproject.org/wiki/Features/Virt_Storage_Migration .fesco 1082 https://fedorahosted.org/fesco/ticket/1082 #topic #1083 F19 Feature: Virtio RNG - https://fedoraproject.org/wiki/Features/Virtio_RNG .fesco 1083 https://fedorahosted.org/fesco/ticket/1083 #topic #1084 F19 Feature: Usermode Migration - https://fedoraproject.org/wiki/Features/UsermodeMigration .fesco 1084 https://fedorahosted.org/fesco/ticket/1084 = Open Floor = For more complete details, please visit each individual ticket. The report of the agenda items can be found at https://fedorahosted.org/fesco/report/9 If you would like to add something to this agenda, you can reply to this e-mail, file a new ticket at https://fedorahosted.org/fesco, e-mail me directly, or bring it up at the end of the meeting, during the open floor topic. Note that added topics may be deferred until the following meeting. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: ConsoleKit and esound retirement
On 12 Feb 2013 19:53, "Jon Ciesla" wrote: > > > > On Tue, Feb 12, 2013 at 1:12 PM, Lennart Poettering wrote: >> >> On Tue, 12.02.13 12:38, Jon Ciesla (limburg...@gmail.com) wrote: >> >> > On Tue, Feb 12, 2013 at 12:34 PM, Lennart Poettering >> > wrote: >> > >> > > Heya, >> > > >> > > since a while now logind has replaced CK in Fedora. I'd like to retire >> > > it entirely from the distribution now. >> > > >> > > Most deps on CK are gone. Holdouts are "cdm", "lightdm", "lxsession", >> > > "lxdm". >> > > >> > > https://fedoraproject.org/wiki/How_to_remove_a_package_at_end_of_life >> > > >> > > This page doesn't say anything about retiring packages other still >> > > depend on... >> > > >> > > I am tempted to just retire CK ignoring the remaining dependencies, in >> > > the hope this will put the pressure on the folks involved to update >> > > their stuff... >> > > >> > > Getting rid of CK in those packages is dead simple BTW. Just disable it >> > > in the packages, but make sure pam_systemd is in the PAM stack for your >> > > greeter tool. It's basically about removing code, not about adding >> > > new code -- adding new code is only necessary if you want to improve >> > > your DM to handle multi-seat setups, too (which is a new feature of >> > > logind, not available in CK[1]). For details, see: >> > > >> > > http://www.freedesktop.org/wiki/Software/systemd/writing-display-managers >> > > >> > > I'd also like to retire "esound" finally. Currently, adplay, ayttm, >> > > dopewars, e16, gnome-libs, gnubg, lxdream, moon-buggy, spacechart, >> > > xarchon, xmms-esd still use it. esd of course has been deprecated and >> > > dead since many years, the packages which still use it really should >> > > wake up one day. So here, too, I'd just like to retire the package... >> > > >> > > Alternatively, somebody else can take these over, but honstely I'd >> > > rather see them removed than continue to bitrot in our repository... >> > >> > So to clarify, you're not actually retiring anything currently, just >> > expressing to the community that you'd like to and that we should work >> > toward making that possible? >> >> Well, I am just checking before I do something whether I can actually do >> it. That's all. By next week or so I will either have retired the >> packages (which I'd prefer) or somebody else took them over (which I'd >> prefer not to do, but which we can do too, if the retro-computing folks >> step up...) >> > I'd prefer that you orphan them, and mail the list, ccing -owner for each dependency, that you're doing so. That said, I maintain gnugb, and was able to easily remove the esound requirement. If no one else wants to maintain esound, I will, even if only long enough to excise it from the packages that need it. In the case of esound I think we're better killing them because I suspect in all cases the packages are either: - optional packages better served by either native PA or alsa support in other sub/related packages - disable the esd support and just use the native alsa/oss in the package In all cases I strongly doubt the user will lose functionality and we should just get on with it. >> > If so, do you have any guidelines on getting rid of esound requirements? >> >> Dunno really. My suspicion is that the packages in question are either >> obsolete on their own, or should just be compiled with --disable-esd or >> so. These packages all look pretty much esoteric or obsolete to me, so I >> am not really that curious what precisely packagers would need to do... > > > Obsolete is in the eye of the beholder. I don't think games ever truly are. ;) > > -J > >> >> >> Lennart >> >> -- >> Lennart Poettering - Red Hat, Inc. >> -- >> devel mailing list >> devel@lists.fedoraproject.org >> https://admin.fedoraproject.org/mailman/listinfo/devel > > > > > -- > http://cecinestpasunefromage.wordpress.com/ > > in your fear, seek only peace > in your fear, seek only love > > -d. bowie > > -- > 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: ConsoleKit and esound retirement
On Tue, Feb 12, 2013 at 1:34 PM, Lennart Poettering wrote: > I'd also like to retire "esound" finally. Currently, adplay, ayttm, > dopewars, e16, gnome-libs, gnubg, lxdream, moon-buggy, spacechart, > xarchon, xmms-esd still use it. Most of these projects if not all are dead upstream but for now, I have disabled esd support in ayttm and adplay. I will take a look at others when I find time. Rahul -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: ConsoleKit and esound retirement
xfce4-session still wants to use ConsoleKit, however, there are upstream patches to fix that. I was waiting for a release to happen with them, but I can pick them in before them if need be. kevin signature.asc Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: ConsoleKit and esound retirement
Peter Robinson wrote: > In the case of esound I think we're better killing them because I suspect > in all cases the packages are either: > - optional packages better served by either native PA or alsa support in > other sub/related packages > - disable the esd support and just use the native alsa/oss in the package Actually, several of those games support ONLY esd for sound. Disabling esd = disabling sound in those games. Not so nice, considering that PulseAudio still supports the ESD protocol just fine. Now if Lennart is going to drop the protocol support from PulseAudio, then libesd will have to go away as well, but if it's just about Fedora maintainership, then the maintainer(s) of one or more of the affected packages should just take it over. Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: ConsoleKit and esound retirement
On Tue, 12.02.13 13:52, Jon Ciesla (limburg...@gmail.com) wrote: > > > So to clarify, you're not actually retiring anything currently, just > > > expressing to the community that you'd like to and that we should work > > > toward making that possible? > > > > Well, I am just checking before I do something whether I can actually do > > it. That's all. By next week or so I will either have retired the > > packages (which I'd prefer) or somebody else took them over (which I'd > > prefer not to do, but which we can do too, if the retro-computing folks > > step up...) > > I'd prefer that you orphan them, and mail the list, ccing -owner for > each dependency, that you're doing so. That said, I maintain gnugb, and > was able to easily remove the esound requirement. If no one else wants to > maintain esound, I will, even if only long enough to excise it from the > packages that need it. OK, if that's what you want. I have now orphaned esound. Please take it over. Lennart -- Lennart Poettering - Red Hat, Inc. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: ConsoleKit and esound retirement
Hi On Tue, Feb 12, 2013 at 5:51 PM, Lennart Poettering wrote: > OK, if that's what you want. I have now orphaned esound. Please take it > over. > https://bugzilla.redhat.com/show_bug.cgi?id=910600 spacechart https://bugzilla.redhat.com/show_bug.cgi?id=910601 xmms It is not clear why spacechart is picking up esound but it in any case, xmms could disable it easily. Couple of games look they need to be ported over and their needs usually are simple enough Rahul -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: ConsoleKit and esound retirement
On Tue, 12.02.13 18:22, Rahul Sundaram (methe...@gmail.com) wrote: > > OK, if that's what you want. I have now orphaned esound. Please take it > > over. > > https://bugzilla.redhat.com/show_bug.cgi?id=910600 spacechart > https://bugzilla.redhat.com/show_bug.cgi?id=910601 xmms > > It is not clear why spacechart is picking up esound but it in any case, > xmms could disable it easily. Couple of games look they need to be ported > over and their needs usually are simple enough Hmm, we still have xmms in the repo? Both Debian and Gentoo killed it years ago... And I though those were the conservative distributions... Lennart -- Lennart Poettering - Red Hat, Inc. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Add a spec template in rpmdevtools
Le mardi 12 février 2013 à 22:06 +0200, Ville Skyttä a écrit : > On 2013-02-12 08:18, Casper wrote: > > So my question is: Is there any living developper of rpmdevtools, > > I'm alive, but haven't been doing much at all wrt rpmdevtools lately. > > > just to add one file in the git repo ?... > > I'm afraid it's not quite that simple. Thanks for the response. No problem I can help you :) -- Pour encrypter vos emails Clef GPG ID : 83288189 @ hkp://pgp.mit.edu:11371 Empreinte : CC26 692F 5205 AC8F 7912 7783 D7A7 F4C5 8328 8189 signature.asc Description: This is a digitally signed message part -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: ConsoleKit and esound retirement
On Wed, Feb 13, 2013 at 00:26:28 +0100, Lennart Poettering wrote: Hmm, we still have xmms in the repo? Both Debian and Gentoo killed it years ago... And I though those were the conservative distributions... I wanted to keep it in Fedora a little bit longer since I have been using it. But if it is causing problems, I won't stand in the way of dropping it. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Proposed F19 Feature: systemd/udev Predictable Network Interface Names
On Tue, Feb 12, 2013 at 4:44 PM, Matt Domsch wrote:
> I am concerned about the naming convention at installtime. The
> current proposal removes biosdevname from comps @core as mandatory,
> and I presume would also remove it from the anaconda install
> environment as well. This leaves the kernel default naming scheme,
> which we agree is poor.
The default scheme is always the udev names, if they are not
explicitly disabled. Everything else would be customization. We can
add whatever is needed here to help specific requirements.
>> These SR-IOV show up with their own PCI function number in the kernel
>> and they are unique that way. From my point of view this is good
>> enough and we don't need to do anything here. If people want "pretty"
>> names they should provide custom and meaningful names on their own.
>> Udev does not want to establish any cross-device relations for naming,
>> and only look at the single device it is currently handling.
>
> I disagree that users should provide their own "pretty" names, when we
> do have all the information we need about these devices to provide
> "pretty" names by default ourselves. By the same argument, I don't
> need anything more from systemd/udevd now than I've had for years with
> 70-persistent-net.rules files.
Well, we cannot have everything, we either have somewhat fragile
pretty names composed by several sources and properties, spanning
multiple devices, and the overall system state. Or we have the "ugly"
but reliable and predictable names, which are a single device only.
Udev can only do the "ugly" version of the names, but the deal fits
better what we do for other subsystems, and is like "100 times"
simpler than what is required to do the pretty names. And reliability,
predictability, simplicity is actually what we looking for. We just
leave the pretty part to custom configuration.
> There are very good reasons to, in the device name, identify the
> separate (to the kernel) devices that represent the same physical
> cable jack. Dell's engineers have been adding code to the bonding
> driver to recognize when someone is bonding two kernel devices that
> share a single physical cable jack, as that's not usually the intended
> configuration. With the growing set of "applicance distributions"
> that auto-configure bonding across all visible network devices, this
> is even more important.
Sure, but custom config can add custom config for the used names too.
Having tools magically coming up with device names based on other
custom config is really nothing we ever would want to do. As soon as
custom config is in the game, there is really no need to try to be
smart, the tools that create the base config can create that config
along with it.
> The biosdevname convention of using _{1234} to identify such
> sub-devices is mirrored in your convention of appending f{1234}.
> Which works until you get to single PCI b/d/f devices with multiple
> ports (e.g. Mellanox adapters), after which you need further
> information to disambiguate the network devices. The biosdevname
> maintainers are trying to tackle this right now.
This really sounds like the wrong layer of fixing the issue.
If Mellanox adapters create multiple interfaces per parent device, the
kernel driver should set the "dev_id" of the devices, which is an
index per instance to distinguish the devices. Udev will automatically
appended the dev_id to the device name as u1,u2,... and all the names
will be unique again. We already used dev_id for the persistent net
rules in old udev revisions.
This should work all fine without any further logic, as long as the
kernel driver do the right thing here. Inventing new numbers by
checking sibling devices should be avoided here too.
Thanks,
Kay
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Re: how reload udev rules and systemd on F18
On Sat, 09.02.13 13:18, Sérgio Basto (ser...@serjux.com) wrote: > On Sex, 2013-02-08 at 10:08 +0100, Florian Weimer wrote: > > On 02/05/2013 07:43 PM, Sérgio Basto wrote: > > > > > Any advises or opinions ? > > > > I think you haven't yet described the original problem you're trying to > > solve. > > Hi, > > When we install VirtualBox from rpmfusion , I'd like create /dev/vboxusb > proxies to host system without reboot box. I want that ends with: Well, be that as it may. It's not OK to retrigger all devices. That's an admin feature, and a feature for very specific usecases, but it's nothing you are allowed to just call in package post scripts... Basically, you cannot do this. You must either tell the admin to invoke "udevadm trigger" on his own, or just not do it. > > ll /dev/vboxusb -d > drwxr-x--- 4 root vboxusers 80 Fev 5 18:42 /dev/vboxusb > > ll /dev/vboxusb > total 0 > drwxr-x--- 2 root vboxusers 80 Fev 9 11:19 002 > drwxr-x--- 2 root vboxusers 60 Fev 5 18:42 001 > > the actual scriptlet: > # Assign USB devices > if /sbin/udevadm control --reload-rules >/dev/null 2>&1 Redundant. > then >/sbin/udevadm trigger --subsystem-match=usb --action=add >/dev/null Not OK. > 2>&1 || : >/sbin/udevadm settle >/dev/null 2>&1 || : Pointless, unless you are LVM, which you are not. Lennart -- Lennart Poettering - Red Hat, Inc. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: ConsoleKit and esound retirement
> Hmm, we still have xmms in the repo? /me is very glad we still have xmms in the repo -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: the need of "Offline Updates"
On 02/12/2013 02:25 PM, Reindl Harald wrote: > > the point is that i NEVER EVER want to stop any service by a RPM > update and define this GLOBAL for all services with one single > config line > > > Well, although I understand your intention. But, e.g. if openssl is updated for security issues, all dependent services need to be restarted. If not, you're still e.g. vulnerable. That can't be your wish. -- Matthias Runge -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
