Metacity and GNOME Flashback
Hi Richard, I noticed that in June you updated Metacity to 3.12.0 to Fedora. Thank you for doing so. http://pkgs.fedoraproject.org/cgit/metacity.git/log/?h=f21 As you may know, the upstream GNOME Flashback project is now maintaining Metacity and several other components. https://wiki.gnome.org/Projects/GnomeFlashback I would like to package all of GNOME Flashback and I was wondering if you had any intention of doing so. if not, I'm curious if there is a use case for Metacity outside of a GNOME Flashback session and if you (or anyone else) have any advice. The GNOME Flashback components: gnome-applets (dead package in fedora) gnome-flashback (not in fedora) gnome-panel (dead package in fedora) metacity notification-daemon (still in fedora, but last updated 2012-09-04) The stable release tarballs are under here: http://ftp.gnome.org/pub/GNOME/sources/ And note that I have been able to run GNOME Flashback on Fedora 21 via JHBuild: https://wiki.gnome.org/Projects/GnomeFlashback/JHBuild/3.16 -Mike -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Metacity and GNOME Flashback
Hi Everyone, On Mon, Nov 10, 2014 at 4:02 AM, Richard Hughes wrote: > On 10 November 2014 05:22, Michael DePaulo wrote: >> I would like to package all of GNOME Flashback and I was wondering if >> you had any intention of doing so. if not, I'm curious if there is a >> use case for Metacity outside of a GNOME Flashback session and if you >> (or anyone else) have any advice. > > Not really; mclazy auto-built metacity as part of the GNOME moduleset > for a few releases. I can remove metacity from the modules.xml file if > you want to deal with this as part of the flashback thing. > > Richard. Understood. Once I make more progress with packaging, I'll probably ask you to do that. >> The GNOME Flashback components: >> gnome-applets (dead package in fedora) >> gnome-flashback (not in fedora) >> gnome-panel (dead package in fedora) >> metacity >> notification-daemon (still in fedora, but last updated 2012-09-04) Are there any instructions for (newbie) packagers on reviving dead packages? I found instructions for orphaned packages, but not dead packages: http://fedoraproject.org/wiki/Orphaned_package_that_need_new_maintainers -Mike -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Is systemd within a Docker container still recommended?
Hi, I am developing a Dockerfile for X2Go. I intend to submit a PR to fedora-Dockerfiles within a week. https://github.com/mikedep333/Fedora-Dockerfiles/tree/add-x2go (X2Go was already added in F20) https://fedoraproject.org/wiki/Changes/X2Go Example Dockerfile with systemd: https://github.com/fedora-cloud/Fedora-Dockerfiles/blob/master/systemd/apache/Dockerfile However, I would like to know if the Fedora project still recommends that I use systemd, or if I should resort to using supervisord or a shell script. I merely need to start sshd and x2gocleansessions. Both have systemd unit files, but can be run via an init script too. When I do try systemd, I am experiencing known issues with cgroups and with mounting /run, unless I run a privileged container. It has been a while since there were any comments on the CLOSED NOTABUG bz on these issues. https://bugzilla.redhat.com/show_bug.cgi?id=1033604 -Mike -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Is systemd within a Docker container still recommended?
On Mon, Mar 2, 2015 at 2:33 PM, Daniel J Walsh wrote: > > On 03/02/2015 10:03 AM, Mauricio Tavares wrote: >> On Mon, Mar 2, 2015 at 9:42 AM, Lennart Poettering >> wrote: >>> You'd have to get the kernel changed for that "information leak" to be >>> fixed. >>> >>> That said, containers on Linux are not really about security, the >>> whole thing has more holes than a swiss cheese. Maybe one day the >>> security holes can be fixed, but as of now, it's simply not >>> secure. And this "information leak" is certainly the least of your >>> problems... >>> >> What would then be the recommended solution if containers are insecure? > Well we are trying to fix this, but as Lennart says, there are many > holes in the strategy at this > point. I am working on a presentation that talks about different levels > of security. As soon > as you get to Virtualization you get less security. > > I would say running each service on an individual machine is the most > secure. Running Each Service > on a separate VM is the second most, especially if you are using > SELInux/Svirt for separation of your VM's. > Third level is running each Service in a different container, (Again you > want SELinux for some separation). > Fourth is each Service running on the host, (Wrapped with SELinux). > Fifth setenforce 0. Thanks, that is a very good explanation. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: "Tick-tock" release cadence?
On Dec 4, 2014 9:39 AM, "Matthew Miller" wrote: > > While I'm waiting for an RC5 test install to complete... :) > > At yesterday's FESCo meeting, while discussing the Fedora 22 schedule, > Stephen Gallagher suggested the idea of moving to a release schedule > modeled after Intel's "tick-tock" model for CPUs, where they alternate > between new architectures and new manufacturing process. > > For us, that would mean alternating between concentrating on release > features and on release engineering and QA process and tooling. During > the "tick", we'd focus on new features and minimize unrelated rel-eng > change. During the "tock", we'd focus on the tools, and minimize change > that might affect that. As a consumer of Intel CPUs, it seems like you have the tick-rock reversed. An Intel tock (microarchitecture change) is associated with new features and major performance improvements. Those are analogous to new Fedora features. An Intel tick (manufacturing process improvement) is primarily a "behind the scenes" change that also yields a moderate performance improvement. As a user of Fedora, tools and process improvements seem "behind the scenes." -Mike -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: "Tick-tock" release cadence?
On Sat, Dec 6, 2014 at 1:02 AM, Kevin Kofler wrote: > Richard Hughes wrote: >> On 4 December 2014 at 14:39, Matthew Miller wrote: >>> including holding GNOME and other showcase software to the same >>> version. >> >> I think that would be *very* unpopular with the desktop team. > > And for once I think the KDE SIG and the GNOME Desktop Team will agree on > something. :-) > > We even upgrade KDE software WITHIN a release, we surely aren't going to > stick to some old version for a whole year! > > This "tick-tock" proposal is a complete no-go. > > Kevin Kofler That is not part of the "tick-tock" proposal. That is part of the "polish" release proposal. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: "Tick-tock" release cadence?
On Mon, Dec 8, 2014 at 2:18 PM, Brendan Conoboy wrote: > On 12/04/2014 06:39 AM, Matthew Miller wrote: >> >> What do you think? Would this help towards the goals listed above? >> Would it help _other_ things? What downsides would it bring? > > > It sounds a lot like releasing a new compose of an existing release with > updates included in the repository. Why not do that instead? It would be > more of a stable midpoint release than a tick-tock, but you get a similar > effect without constraining devel. > > -- > Brendan Conoboy / Red Hat, Inc. / b...@redhat.com [...] +1 It looks like this need is partially met by the live respins. The Fedora 20 live Desktop ISO is among them. http://mirrors.kernel.org/fedora/updates/20/Live/x86_64/ https://alt.fedoraproject.org/pub/alt/live-respins/ -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Heads up: F21 LLVM rebase
On Fri, Dec 12, 2014 at 7:01 AM, Marcin Juszkiewicz wrote: > W dniu 11.12.2014 o 18:16, Adam Jackson pisze: >> I've started staging an LLVM 3.5 rebase in F21. I hope to have >> everything built by this Friday and the update available in testing >> by Monday. Test feedback would be particularly appreciated on >> secondary arches and radeonsi 3D hardware. > > Can someone explain to me (like to total idiot would be best) why after > release of stable version developers start to update components? IMHO > time for it was during F21 development and now work should concentrate > on F22 with just stable fixes for released versions. > > But maybe it is just yet another difference between Debian (which world > I was living in for 14 years) and Fedora (year of using) world. [...] Unlike gcc, Isn't LLVM part of ring 2 in Fedora.next? http://fedoramagazine.org/fedora-present-and-future-a-fedora-next-2014-update-part-ii-whats-happening/ If you want a reason for why higher rings are upgraded after release, I think the answer is: http://fedoraproject.org/wiki/Staying_close_to_upstream_projects I wasn't able to find a definitive answer via DDG or Google, but I think that no more LLVM 3.4.x maintenance releases will be released. -Mike -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Heads up: F21 LLVM rebase
On Fri, Dec 12, 2014 at 10:30 AM, Adam Jackson wrote: > On Fri, 2014-12-12 at 13:01 +0100, Marcin Juszkiewicz wrote: >> W dniu 11.12.2014 o 18:16, Adam Jackson pisze: >> > I've started staging an LLVM 3.5 rebase in F21. I hope to have >> > everything built by this Friday and the update available in testing >> > by Monday. Test feedback would be particularly appreciated on >> > secondary arches and radeonsi 3D hardware. >> >> Can someone explain to me (like to total idiot would be best) why after >> release of stable version developers start to update components? IMHO >> time for it was during F21 development and now work should concentrate >> on F22 with just stable fixes for released versions. > > We need to update Mesa in stable releases for hardware enablement, > otherwise people buy new hardware and can't use 3D and then Fedora > sucks. Mesa and LLVM are sufficiently closely entwined these days that > eventually I can't build fully-featured Mesa without updating LLVM. > This isn't the first time the llvm soname has changed within a release, > in fact it's happened at least once per release since F18 afaict. > > Yes, it's disruptive, it's a gigantic pain in the ass, I don't enjoy > doing it at all. llvm upstream seem to have no concept of consumable > interface design, so at this point around half of the llvm-using > components in Fedora have to be built from the same srpm as llvm itself; > most of them are only build-tested with clang, so I also get the joy of > trying to port them to gcc. All this without having much working > knowledge of C++, on account of how I want to be able to look myself in > the mirror in the morning without crying. I'm not a toolchain hacker. > I want not to work on this crap. > > But either someone does it, or Mesa goes stale, so it's gotta get done. > > On the flip side, by synchronizing llvm (and Mesa and friends) across > releases, graphics devel has more time to spend on _everyone_'s issues, > because we don't have to waste time tracking which bug was fixed in > which branch. > > In this particular case I had _wanted_ to get 3.5 into F21 gold in the > first place [1], since it's sort of mandatory to make ppc64le actually > work. The timing didn't quite work out, so it happens in updates > instead. Sorry about that, life doesn't always admit pretty solutions. > > [1] - https://lists.fedoraproject.org/pipermail/devel/2014-October/203463.html > > - ajax [...] 1st, thank you for the contributions you make. I too come from an Ubuntu/Debian background. Like other major pieces of software, Ubuntu and Debian both make multiple 2.x or 3.x versions of LLVM available for each release of their OS. They do the following: 1. The major version is specified in the package name. For example, "llvm-3.4" and "llvm-3.5" are the names of separate packages. The actual package versions are like "3.4.2-13" & "3.5-6" respectively 2. The package "llvm" is a small package that depends on the recommended major version for developers. For example, in Jessie, 3.5 is the recommended major version, and Jessie "llvm" contains symlinks such as: /usr/bin/llvm-extract -> /usr/bin/llvm-extract-3.5 Would Fedora permit someone like myself to contribute an LLVM packaging scheme like that? -Mike -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Heads up: F21 LLVM rebase
On Fri, Dec 12, 2014 at 7:51 PM, Kevin Kofler wrote: > Michael DePaulo wrote: >> I too come from an Ubuntu/Debian background. Like other major pieces >> of software, Ubuntu and Debian both make multiple 2.x or 3.x versions >> of LLVM available for each release of their OS. They do the >> following: >> 1. The major version is specified in the package name. For example, >> "llvm-3.4" and "llvm-3.5" are the names of separate packages. The >> actual package versions are like "3.4.2-13" & "3.5-6" respectively >> >> 2. The package "llvm" is a small package that depends on the >> recommended major version for developers. For example, in Jessie, 3.5 >> is the recommended major version, and Jessie "llvm" contains symlinks >> such as: >> /usr/bin/llvm-extract -> /usr/bin/llvm-extract-3.5 >> >> Would Fedora permit someone like myself to contribute an LLVM >> packaging scheme like that? > > That would NOT be a good idea, for a simple reason: The version of LLVM Mesa > (i.e., libGL) links ends up linked into MANY executables. If you link some > other library against some other version of LLVM, and then an application > ends up directly or indirectly linking both that library and libGL, it ends > up indirectly linking the 2 incompatible versions of LLVM and crashing. We > have already had this happen, and other distributions too, see e.g.: > http://www.valdyas.org/fading/index.cgi/2011/10/08#llvm > and still, months later (when it was already long fixed in Fedora by using a > common shared LLVM, but apparently not on some other distributions): > http://mail.kde.org/pipermail/kimageshop/2012-September/011387.html > > (Now, to be fair, it turns out that OpenGTL has since been removed from > Fedora because Krita no longer uses it, but the exact same problem can > happen with any of the other consumers of LLVM.) > > There can be only one version of LLVM in the whole distribution at a time. > > This topic has already come up several times on this mailing list (basically > each time such a rebase was done), please read the archives, e.g., this > thread: > https://lists.fedoraproject.org/pipermail/devel/2014-March/197227.html > and my reply to a proposal essentially identical to yours: > https://lists.fedoraproject.org/pipermail/devel/2014-March/197278.html > > Kevin Kofler Understood, sorry for not searching the archives. -Mike -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
