Re: polkit-kde-kcmmodules editing /usr
On Fri, 26 Oct 2012, Sebastian Kügler wrote: On Thursday, October 25, 2012 14:38:01 Robby Workman wrote: On Thu, 25 Oct 2012, Kevin Kofler wrote: On Thursday 25 October 2012 at 09:47:08, Andrea Scarpino wrote: I cannot help here as we don't provide it in our repos. We (Fedora) neither. But on Arch Linux we have the same kind of issue with KDM; it stores the configs in /usr/share/config/kdm. How do you handle that? In Fedora, /usr/share/config/kdm is a symlink to /etc/kde/kdm. Ditto for Slackware. The obvious question here is: If everybody changes it, why do we ship it that way? Good question, and it makes me wonder why we've always just "worked around" it instead of sending patches to do it correctly. I'm not in a position to look farther into that right now, so I'll just say that it would seem better for KDE stuff to use /usr/share/config/$whatever/ for packaged defaults (IOW, *exactly* what you currently do) with support for overriding those defaults in $sysconfdir/kde/$whatever/ -RW___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: polkit-kde-kcmmodules editing /usr
On Thu, 25 Oct 2012, Kevin Kofler wrote: On Thursday 25 October 2012 at 09:47:08, Andrea Scarpino wrote: I cannot help here as we don't provide it in our repos. We (Fedora) neither. But on Arch Linux we have the same kind of issue with KDM; it stores the configs in /usr/share/config/kdm. How do you handle that? In Fedora, /usr/share/config/kdm is a symlink to /etc/kde/kdm. Ditto for Slackware. -RW ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: git migration, next steps
On Fri, 3 Jun 2011, Raphael Kubo da Costa wrote: > Eric Hameleers writes: > >> If you want to give people a feeling of unity (pun intended) when >> running KDE it should not be given to packagers as a shambles of small >> un-coordinated source tarballs. > > I'd appreciate it if people interested in the monolithic tarballs could > summarize their concerns so that it is easier to understand their > reasons. > > So far, I can see these: > > * Adding new packages (SRPMs or whatever) is slow in some distros; > * Fear that new tarballs will be released without proper instructions >or not following any criteria, so that creating packages and >following the dependencies gets harder. One of them has already (sorta) happened, though I don't recall the part involved. Suppose several components depend on a particular library, e.g. libsomething, and the libsomething dev team releases a new version with some cool new feature and an API change. Some of the components see that cool new feature and start depending on the new API, while others don't. KDE SC -next includes some of each of those components. Now, which one should packagers ship? As I wrote this, my memory jogged a bit, and I seem to recall that shared-desktop-ontologies was the involved bit mentioned earlier... -RW ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: KDE 4.2.0 tarballs (non-final, try #1)
On Thu, 22 Jan 2009, Dirk Mueller wrote: > PLEASE LET ME KNOW OF ANY SHOW STOPPER ISSUES. Please use the kde-4.2.0- > blocker keyword for bugs on bugs.kde.org that must be fixed before release, > and CC me on commits that must go into KDE 4.2.0. Well, it appears from the bug comments that this does not qualify, but on the off chance that it does, I'd like to see this addressed: https://bugs.kde.org/show_bug.cgi?id=151669 However, if it's not going to happen for 4.2.0, that's at least somewhat understandable, but it raises another concern: is there going to be an unavoidable dependency on PolicyKit for this? If so, that's going to be a problem for us, at least for now... -RW ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: KDE 4.1.0 tarballs (try #1) update
On Wed, 23 Jul 2008, Dirk Mueller wrote: > just finished uploadiung the 4.1.0 tarballs. remember to update soprano, > akonadi, automoc4 and phonon (4.2.0) as well. > > Please let me know of any severe issues that you find. I'm currently not 100% > sure that kdebindings builds at all, I'll look into that now. Everything compiled here, and initial testing looks good. Startup feels a bit slower than I had hoped on my laptop (T41), but is plenty acceptable on my development machine. All things considered, congratulations on a good job, kde devs. All of the major showstopper bugs I had noted in previous releases seem to have been addressed. Thanks! -RW ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: KDE 4.1 Beta1 tarballs (try #1) uploaded
On Wed, 21 May 2008, "Dirk M?ller" wrote: I've finished tagging KDE 4.1 Beta1 (it is mostly r810705) and generating tarballs except for l10n, which is still running. Note that this release again removes kdevplatform and kdewebdev/quanta. There is no replacement. Currently there is also not a kdeplasmoids module even though that was discussed. Perhaps we have that with beta2 :) Please report any issues, especially compile issues or blockers to me. if you have svn revisions that should be included in beta1, please let me know. We plan to publically release the tarballs next week wednesday, please supply binary packages if you have time. Well, unless I'm missing something obvious, kdevelop won't compile without kdevplatform. Cluestick, anyone? :) -RW___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Access to early tarball releases - Slackware
To whom it may concern: I'm a member of the Slackware development team and have been doing (unofficial) kde4 builds for our upcoming 12.1 release. I'm on the kde-packager list, but I don't currently have access to the source tarballs when they're first announced, and I would like to get this access. I understand completely that, if granted, the sources and corresponding binaries may not be released prior to public release of the sources. Is this feasible, and if so, what do you need from me? Thanks in advance, Robby Workman [EMAIL PROTECTED] ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
