Re: What would it take to make Software Collections work in Fedora?

[Radek Vokal]

On 12/06/2012 07:00 AM, Adam Williamson wrote:

On Wed, 2012-12-05 at 22:25 -0600, Michael Ekstrand wrote:

On 12/05/2012 03:06 PM, Bill Nottingham wrote:

Matthew Miller (mat...@fedoraproject.org) said:

Three things:

1) Fedora is big enough that we have concrete situations where one size
doesn't fit all. Puppet being broken on F17 (and probably F18 as well)
is a fine example of something within the distro itself. And, as a
platform for development, offering more version choices to our users
would be a strength.


heretical

Well, then maybe Fedora's too big, and we should move to a model where
Fedora is much smaller, and the grand Fedora universe contains things that
are packaged *for* one or multiple Fedoras.

/heretical


FWIW (probably not much), I also think this is a great idea.  It feels
strange to me that the same thing contains  manages everything from
base system (e.g. kernel through core GNOME stack) and add-on apps (say
Battle for Wesnoth, to pick a relatively obvious example).

Now, there's a bike shed to be painted over where the lines should be drawn.


We could draw them between Core and Extras!



So what if we actually do .. but in a different way - eg. we would 
ensure that we have stable API, no feature breakage in a release for a 
package that do belong to core and allow faster turnaround for 
packages in extras .. it's not like locking it down as it used to be 
but defining more strict rules for certain set of packages.


R
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: ABRT duplicate detection

[Radek Vokal]

2010/4/24 Christoph Höger choe...@cs.tu-berlin.de:
 Hi all,

 I was just wondering: How mature is ABRTs duplicate detection?

 You might all know the MS search for a solution to this problem window
 popping up after an application crashes. I've never seen it doing
 something usefull, though. But if ABRT could detect duplicate crashes
 one could use this to display a workaround or even propose an update via
 packagekit. All we'd need to do would be to tag (or maybe link from, if
 a wiki would be better) an bugzilla entry as containing either a
 workaround or a fix. ABRT could then display the solution just after the
 crash happened. Great, wouldn't it be?

 comments?

 Christoph



I've cced the crash-catcher mailing list. Probably the developers can
comment more about this idea, but in general I really - especially the
part -known bug  known workaround, which might be linked to a
wiki-like database of  user problems and solutions.

Radek
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: [modularity] Building modules works with a little hack

[Radek Vokal]

Great work Adame. Where do these modules end up? Is there a repo now
or just the build jobs/IDs?

Radek

On Thu, Mar 9, 2017 at 11:20 AM, Adam Samalik  wrote:
> Short version:
>
> If you want to build a module, edit your modulemd file, change
> "base-runtime" to "bootstrap" in dependencies, commit your change locally
> and continue as you would before - that means use the "build-module" script
> described on our documentation website [1] .
>
>
> Long version:
>
> We had some troubles recently with building our modules as the
> "base-runtime" module - a (build) dependency for all other modules - has
> been deleted from the infra. That happened because packages in the
> base-runtime module (which wasn't even real base-runtime, explained later)
> has not been tagged into any release - so Koji deleted them after 3 months.
> To prevent this from happening again, Factory 2.0 guys created a special tag
> for modularity, which basically means "Koji, please don't delete these
> packages". So that won't happen again.
>
> As I said, that the base-runtime wasn't a real base-runtime. The thing
> called base-runtime was in fact bootstrap - a self-hosting set of packages
> (= they can build themselves, it's about 2700 packages) which are used as a
> buildroot for the real base-runtime (about 170 packages). And this module
> has been recreated again under the right name, bootstrap.
>
> So to build modules the way we did before, we just need to temporary use the
> "bootstrap" module as a build dependency in our modulemd files instead of
> "base-runtime". And when the real base-runtime is out, we can switch to that
> later.
>
>
> Enjoy builds!
> Adam
>
>
> [1]
> https://docs.pagure.org/modularity/development/building-modules/building-local.html#option-2-docker-image-and-a-helper-script
>
> --
>
> Adam Šamalík
> ---
> Software Engineer
> Red Hat
>
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
>



-- 
--
Radek Vokál
Senior Engineering Manager, Platform

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org