Re: Current minimal base image for containers?

[Martin Langhoff]

On Sun, Jul 11, 2021 at 2:34 PM Daniel Walsh  wrote:
> Take a look at ubi8-micro.  Not Fedora based but downstream of Fedora.

That's super useful thank you! Adding stuff to ubi8-micro from F34 is
awkward (GPG keys, running rebuilddb to get a sqlite rpmdb, etc). I
might copy the build script which I found at -
https://github.com/fatherlinux/ubi-micro/blob/master/ubi8-micro

regards,


m
-- 
 martin.langh...@gmail.com
 - ask interesting questions  ~  http://linkedin.com/in/martinlanghoff
 - don't be distracted~  http://github.com/martin-langhoff
   by shiny stuff
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Current minimal base image for containers?

[Martin Langhoff]

Hi Fedora Devel,

is there any current equivalent of Fedora atomic, or the super-compact
RHEL-7 minimal container images? IIRC those were _really_ small (ie:
~70MB) in size, had been installed with nodocs, etc.

Couldn't find a CoreOS _minimal container_ image either. Current
Fedora 34 minimal container image is 120MB.

regards,


martin
-- 
 martin.langh...@gmail.com
 - ask interesting questions  ~  http://linkedin.com/in/martinlanghoff
 - don't be distracted~  http://github.com/martin-langhoff
   by shiny stuff
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Remote wipe options for Fedora?

[Martin Langhoff]

Are there options for remote-wipe features for Fedora (or RHEL for that
matter)?

Ideally something integrated into the early boot process, as well as a
persistent service that is non-trivial to tamper with. It would naturally
need a network/internet based service as control point.

Googling and searching the mailing list has not turned any leads.

It is a can of worms, naturally, and I am well aware of limitations, and
tricky tradeoffs in remote-wipe schemes. For some use cases, including one
affecting me, it can reduce attack surface. I am hoping that some solutions
exist, I would be happy to improve, package, integrate...

regards,


martin
-- 
 martin.langh...@gmail.com
 - ask interesting questions  ~  http://linkedin.com/in/martinlanghoff
 - don't be distracted~  http://github.com/martin-langhoff
   by shiny stuff
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Aggressive updating (Python 3.9): Are we trying to hard?

[Martin Langhoff]

Agreed. That a lot of Python is such in 2.7 land I know and understand well
and it's not something Fedora can fix without boiling an ocean or two.

Python 3.x is good but not compelling for many codebases. Maintainership
effort for many projects has dwindled, tech debt must now be paid in one
big lump.

But on the 3.x series, the fragmentation over 3.x releases is a tractable
problem, with a current and next stack.

IMHO :)



m


On Thu, May 21, 2020, 9:18 AM Stephen John Smoogen  wrote:

>
>
> On Thu, 21 May 2020 at 08:49, Martin Langhoff 
> wrote:
>
>> On Wed, May 20, 2020 at 3:47 PM Richard Shaw 
>> wrote:
>> > Perhaps, but they are still too cumbersome for the average packager.
>> > So I would have to create a module for Python 3.7, python-pyside2, and
>> freecad, correct?
>>
>> Maybe Fedora needs parallel installable "python" and "python-next" stacks?
>>
>>
> The issue is that a lot of other software would need python-older and
> python-oldest stacks.
>
> There is some amount of software is written for whatever languages is in
> the oldest active Ubuntu LTS and the developers really only look to update
> it to newer stuff AFTER it has gone EOL. There is another amount of
> software written for the latest LTS, and there is another set of software
> which is written for the latest. I expect that each of those groups is
> large enough to think they are the 'majority' of users of the languages in
> question.. so have no urge to move slower/faster because they really don't
> have the time to do so. [If you are focusing on the latest features it
> takes as much time and energy to slow down and find alternative methods
> which work in older stacks.. if you are focusing on long term stability or
> your main job is some other thing.. porting some script you wrote to
> something newer because XYZ now needs foobaz methods is not a high priority
> either.]
>
>
>>
>
> --
> Stephen J Smoogen.
>
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct:
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
>
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Aggressive updating (Python 3.9): Are we trying to hard?

[Martin Langhoff]

On Wed, May 20, 2020 at 3:47 PM Richard Shaw  wrote:
> Perhaps, but they are still too cumbersome for the average packager.
> So I would have to create a module for Python 3.7, python-pyside2, and 
> freecad, correct?

Maybe Fedora needs parallel installable "python" and "python-next" stacks?

Primary goal is that everything works on the "python" ("current")
stack, which powers DNF, etc.

Secondary goal is to get "everything" working on python-next.

Once "almost everything" works on python-next it gets promoted to
current python for the next release.

This description is obviously oversimplified, "almost everything"
would be a criteria with some critical packages/functionality being a
must, and some % of "leaf" packages broken being acceptable at
promotion time.

It also doesn't solve _every_ problem -- when various dependencies'
versions can combine in multiple ways, where some work some don't,
there's not much a distro can do without getting into boiling oceans.
OTOH, it does give you a target -- try to make _this_ set work.

Tooling might be needed to streamline the "promotion" process.

cheers,


m
-- 
 martin.langh...@gmail.com
 - ask interesting questions  ~  http://linkedin.com/in/martinlanghoff
 - don't be distracted~  http://github.com/martin-langhoff
   by shiny stuff
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: armv7l status?

[Martin Langhoff]

James, so you guys still rely on koji for builds?

That's relevant for this thread




m

On Wed, May 13, 2020, 5:31 PM James Cameron  wrote:

> Thanks Martin.
>
> That release was a respin of Fedora 18.  Regressions in Fedora 20, and
> our downsize at OLPC, stopped us tracking Fedora.
>
> Lubomir Rintel has been working on OLPC XO-1.75 and XO-4 support for
> Fedora rawhide.
>
> Alex Perez has mentioned that OLPC XO-1.75 can boot Fedora latest with
> some care.
>
> On Wed, May 13, 2020 at 09:25:54AM -0400, Martin Langhoff wrote:
> > Looping in James Cameron - as recently as Jan 2020 he's made a release
> for
> > armv7l
> >
> > [1]http://lists.laptop.org/pipermail/devel/2020-January/039079.html
> >
> > hth ~ martin
> >
> > On Wed, May 13, 2020 at 9:21 AM Martin Langhoff <[2]
> martin.langh...@gmail.com>
> > wrote:
> >
> > On Wed, May 13, 2020 at 9:14 AM Michael Catanzaro <[3]
> mcatanz...@gnome.org>
> > wrote:
> >
> > Why are we still doing builds for armv7l in koji?
> >
> > Presumably for OLPC packages. That ARM build target is/was the right
> one
> > for the ARM CPUs on those.
> >
> > I haven't been in the loop for a while, but until recently there was
> a
> > group of volunteers still cranking packages for ARM-based XO laptops.
> >
> > cheers,
> >
> > m
> > --
> >  [4]martin.langh...@gmail.com
> >  - ask interesting questions  ~  [5]
> http://linkedin.com/in/martinlanghoff
> >  - don't be distracted~  [6]
> http://github.com/martin-langhoff
> >by shiny stuff
> >
> > --
> >  [7]martin.langh...@gmail.com
> >  - ask interesting questions  ~  [8]
> http://linkedin.com/in/martinlanghoff
> >  - don't be distracted~  [9]http://github.com/martin-langhoff
> >by shiny stuff
> >
> > References:
> >
> > [1] http://lists.laptop.org/pipermail/devel/2020-January/039079.html
> > [2] mailto:martin.langh...@gmail.com
> > [3] mailto:mcatanz...@gnome.org
> > [4] mailto:martin.langh...@gmail.com
> > [5] http://linkedin.com/in/martinlanghoff
> > [6] http://github.com/martin-langhoff
> > [7] mailto:martin.langh...@gmail.com
> > [8] http://linkedin.com/in/martinlanghoff
> > [9] http://github.com/martin-langhoff
>
> --
> James Cameron
> http://quozl.netrek.org/
>
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: armv7l status?

[Martin Langhoff]

Looping in James Cameron - as recently as Jan 2020 he's made a release for
armv7l

http://lists.laptop.org/pipermail/devel/2020-January/039079.html

hth ~ martin

On Wed, May 13, 2020 at 9:21 AM Martin Langhoff 
wrote:

> On Wed, May 13, 2020 at 9:14 AM Michael Catanzaro 
> wrote:
>
>> Why are we still doing builds for armv7l in koji?
>>
>
> Presumably for OLPC packages. That ARM build target is/was the right one
> for the ARM CPUs on those.
>
> I haven't been in the loop for a while, but until recently there was a
> group of volunteers still cranking packages for ARM-based XO laptops.
>
> cheers,
>
>
> m
> --
>  martin.langh...@gmail.com
>  - ask interesting questions  ~  http://linkedin.com/in/martinlanghoff
>  - don't be distracted~  http://github.com/martin-langhoff
>by shiny stuff
>


-- 
 martin.langh...@gmail.com
 - ask interesting questions  ~  http://linkedin.com/in/martinlanghoff
 - don't be distracted~  http://github.com/martin-langhoff
   by shiny stuff
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: armv7l status?

[Martin Langhoff]

On Wed, May 13, 2020 at 9:14 AM Michael Catanzaro 
wrote:

> Why are we still doing builds for armv7l in koji?
>

Presumably for OLPC packages. That ARM build target is/was the right one
for the ARM CPUs on those.

I haven't been in the loop for a while, but until recently there was a
group of volunteers still cranking packages for ARM-based XO laptops.

cheers,


m
-- 
 martin.langh...@gmail.com
 - ask interesting questions  ~  http://linkedin.com/in/martinlanghoff
 - don't be distracted~  http://github.com/martin-langhoff
   by shiny stuff
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Code of Conduct issue

[Martin Langhoff]

On Tue, Mar 24, 2020 at 7:28 AM Daniel Pocock  wrote:
> Sending this to another list is not the solution.  Langhoff unleashed
> this monster on this list and it is time for people to show some respect

Of all the players in this saga, it turns out that I am the unleasher
of monsters?

With apologies for the whole list for extending this thread and topic,
couple facts

- I happen to be subscribed to debian-devel, LWN and fedora-devel,
with good friends in both Debian and Fedora communities.  None of my
good friends seem to have aggrieved Daniel - that I know of.
- I observed the unfortunate discussions in debian-devel and articles in LWN
- Mentioned it here, when Daniel brought his grievances here. My
initial email was unfortunate, and I apologized _and that's the extent
of it_.

Honestly, I think that Daniel may well have reasons for his original
grievance. But this original grievance seems to be used to justify a
lot of stuff that is -- IMHO -- just not ok and keeps escalating and
expanding across development communities.

AIUI, several people have suggested to Daniel to walk away, take some
time off... I can't say I disagree with those recommendations.

This will be my last post on this topic. Thank you all for your patience.



m
-- 
 martin.langh...@gmail.com
 - ask interesting questions  ~  http://linkedin.com/in/martinlanghoff
 - don't be distracted~  http://github.com/martin-langhoff
   by shiny stuff
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: CoC

[Martin Langhoff]

Apologies to Ty. I should have written instead:

Daniel Pocock seems to have created a complicated situation with Debian,
which includes sock puppets and attempts at impersonation.

Here is a good LWN article that tries to cover the topic -
https://lwn.net/Articles/814508/ . It is not the only one -- there's
endless mailing list threads and blogposts.

take care,


martin

On Thu, Mar 19, 2020 at 11:29 PM Ty Young  wrote:

>
> On 3/19/20 10:03 PM, Martin Langhoff wrote:
>
> Oh my - Daniel and his sock puppets come to bring mayhem to Fedora-devel?
>
> some background at https://lwn.net/Articles/814508/
>
> cut off the trolling...
>
>
> I do believe calling people "sock puppets" is a violation of the CoC.
> Specifically, the "be respectful" section at the top.
>
>
> Anyway, not the same person. I'd jump off a cliff before having anything
> to do with or use Debian. Anyone who knows me from Reddit could probably
> tell you that.
>
>
>
>
> m
>
> On Thu, Mar 19, 2020 at 3:37 PM Ty Young  wrote:
>
>>
>> On 3/19/20 2:18 PM, Daniel Pocock wrote:
>> >
>> > On 12/03/2020 22:34, Matthew Miller wrote:
>> >> On Sat, Mar 07, 2020 at 11:33:04PM +0100, Daniel Pocock wrote:
>> >>> It is very, very wrong and I don't feel I should have to make a public
>> >>> request like this.  Nonetheless, there is a certain type of person who
>> >> Daniel, to request re-instatement, please follow the process outlined
>> >> in the original code-of-conduct suspension notice you received. A
>> >> public post is not necessary.
>> >
>> > Personally, I feel offended by your choice of words
>> >
>> > A suspension of a blog may itself be a violation of the Code of Conduct
>> > if the blog was written in good faith
>> >
>> > I never received one complaint about my blog from anybody in the Fedora
>> > world.  Several people noticed when it disappeared though.
>> >
>> > The blog post in question discussed a conflict of interest between the
>> > leaders of two free software organizations, the Debian Project Leader
>> > and the OSI board president.  As I interacted with both of them
>> > personally, I felt that I was qualified to share my observations.
>> >
>> > That topic itself was forced into the public because one of the people
>> > party to the conflict of interest had spread gossip about me and the
>> > other used her speech at an event for humiliating volunteers.
>> >
>> > It feels like Codes of Conduct apply to some people and not others.  As
>> > George Orwell puts it, /All animals are equal but some animals are more
>> > equal than others/.
>>
>>
>> Have you seen Gnome's CoC? It literally allows racism. There was a bit
>> of an uproar about it, and Gnome foundation/developers members refused
>> to change it.
>>
>>
>> (Gnome and Fedora are very incestous projects, so yes, it is relevant)
>>
>>
>> Now that communism is the cool, hip ideology in town, Gnome/Fedora are
>> embracing it. Book burning is the next step, but one might argue the
>> deletion of discussion threads and blogs already *is* that step.
>>
>>
>> >
>> > Fedora's Code of Conduct[1] asks people to be excellent to each other.
>> > When talking about governance issues, being excellent to other
>> > volunteers means telling them the truth about leadership problems in the
>> > free software world.
>> >
>> > Being excellent to leaders who behave badly means keeping a focus on the
>> > issues.  For example, when blogging about two people with a romantic
>> > conflict of interest, I would never speculate about their first date and
>> > other personal details, I would only focus on the way their decision
>> > making was impaired.
>> >
>> > Even this week there are people writing public comments alleging I had a
>> > conflict of interest, but that is false.  I named Chris Lamb and Molly
>> > de Blanc because their conflict of interest was at the root of certain
>> > problems.  At least one member of Debian's mentoring team also had a
>> > conflict of interest with an intern.  I didn't identify them out of
>> > concerns for student privacy.  Nonetheless, when people spread gossip,
>> > leadership figures have a responsibility to stop it, but they didn't,
>> > they added fuel to the fire and they continue to do so even now.
>> >
>> > If the leaders of organizations can behave like that, why should the
>> >

Re: CoC

[Martin Langhoff]

Oh my - Daniel and his sock puppets come to bring mayhem to Fedora-devel?

some background at https://lwn.net/Articles/814508/

cut off the trolling...


m

On Thu, Mar 19, 2020 at 3:37 PM Ty Young  wrote:

>
> On 3/19/20 2:18 PM, Daniel Pocock wrote:
> >
> > On 12/03/2020 22:34, Matthew Miller wrote:
> >> On Sat, Mar 07, 2020 at 11:33:04PM +0100, Daniel Pocock wrote:
> >>> It is very, very wrong and I don't feel I should have to make a public
> >>> request like this.  Nonetheless, there is a certain type of person who
> >> Daniel, to request re-instatement, please follow the process outlined
> >> in the original code-of-conduct suspension notice you received. A
> >> public post is not necessary.
> >
> > Personally, I feel offended by your choice of words
> >
> > A suspension of a blog may itself be a violation of the Code of Conduct
> > if the blog was written in good faith
> >
> > I never received one complaint about my blog from anybody in the Fedora
> > world.  Several people noticed when it disappeared though.
> >
> > The blog post in question discussed a conflict of interest between the
> > leaders of two free software organizations, the Debian Project Leader
> > and the OSI board president.  As I interacted with both of them
> > personally, I felt that I was qualified to share my observations.
> >
> > That topic itself was forced into the public because one of the people
> > party to the conflict of interest had spread gossip about me and the
> > other used her speech at an event for humiliating volunteers.
> >
> > It feels like Codes of Conduct apply to some people and not others.  As
> > George Orwell puts it, /All animals are equal but some animals are more
> > equal than others/.
>
>
> Have you seen Gnome's CoC? It literally allows racism. There was a bit
> of an uproar about it, and Gnome foundation/developers members refused
> to change it.
>
>
> (Gnome and Fedora are very incestous projects, so yes, it is relevant)
>
>
> Now that communism is the cool, hip ideology in town, Gnome/Fedora are
> embracing it. Book burning is the next step, but one might argue the
> deletion of discussion threads and blogs already *is* that step.
>
>
> >
> > Fedora's Code of Conduct[1] asks people to be excellent to each other.
> > When talking about governance issues, being excellent to other
> > volunteers means telling them the truth about leadership problems in the
> > free software world.
> >
> > Being excellent to leaders who behave badly means keeping a focus on the
> > issues.  For example, when blogging about two people with a romantic
> > conflict of interest, I would never speculate about their first date and
> > other personal details, I would only focus on the way their decision
> > making was impaired.
> >
> > Even this week there are people writing public comments alleging I had a
> > conflict of interest, but that is false.  I named Chris Lamb and Molly
> > de Blanc because their conflict of interest was at the root of certain
> > problems.  At least one member of Debian's mentoring team also had a
> > conflict of interest with an intern.  I didn't identify them out of
> > concerns for student privacy.  Nonetheless, when people spread gossip,
> > leadership figures have a responsibility to stop it, but they didn't,
> > they added fuel to the fire and they continue to do so even now.
> >
> > If the leaders of organizations can behave like that, why should the
> > Code of Conduct deny a volunteer a right of reply?
>
>
> Silly Daniel, you aren't supposed to question the supreme leaders. You
> have to fall in line and never question anything.
>
>
> If you need help understanding, I recommend reading up on what's going
> on in China right now. Concentration camps, book burning, police
> brutality, people vanishing, etc...
>
>
> >
> > Regards,
> >
> > Daniel
> >
> > 1. https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> > ___
> > devel mailing list -- devel@lists.fedoraproject.org
> > To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> > Fedora Code of Conduct:
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> > List Archives:
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubsc

Re: Changelog between OS states (ie: VMs)

[Martin Langhoff]

On Tue, Jan 9, 2018 at 12:43 PM, Adam Williamson
<adamw...@fedoraproject.org> wrote:
> https://pagure.io/compose-utils
>
> that may be of interest to the original poster.

Bingo. https://pagure.io/compose-utils/blob/master/f/compose_utils/changelog.py

thank you!



martin
-- 
 martin.langh...@gmail.com
 - ask interesting questions  ~  http://linkedin.com/in/martinlanghoff
 - don't be distracted~  http://github.com/martin-langhoff
   by shiny stuff
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Changelog between OS states (ie: VMs)

[Martin Langhoff]

On Mon, Jan 8, 2018 at 2:52 PM, Jonathan Lebon <jle...@redhat.com> wrote:
> Interestingly, these are both things that Atomic Host make
> easier to query.
>
> E.g. if both VMs are on AH but sitting on different commits,
> you can pull the commit on one of the two and do:
>
> $ rpm-ostree db diff COMMIT1 COMMIT2

oh, that's so very nice. Can it be extracted, split out to a script?
(ie: point it to two rpmdb dirs...)

thanks,




m
-- 
 martin.langh...@gmail.com
 - ask interesting questions  ~  http://linkedin.com/in/martinlanghoff
 - don't be distracted    ~  http://github.com/martin-langhoff
   by shiny stuff
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Changelog between OS states (ie: VMs)

[Martin Langhoff]

On Mon, Jan 8, 2018 at 1:19 PM, Nico Kadel-Garcia <nka...@gmail.com> wrote:
> On Mon, Jan 8, 2018 at 12:59 PM, Martin Langhoff
> <martin.langh...@gmail.com> wrote:
>> I have two VMs, or OS states I can `rpm -qa` on. Is there a script to
>> diff the output of the two listings, and then query the package
>> changelogs to generate an overall OS-wide changelog?
>
> This is so sensitive to individual environment requirements it has
> never been standardized well that I've seen. It *always* gets done by
> the local admin, to fit their requirments.

I fully agree wrt configuration changes. I am scoping my interest
exclusively to rpms.

A bit like saying "I run yum/dnf update on an OS, what bugfixes are
landing/have landed?"

cheers,


m
-- 
 martin.langh...@gmail.com
 - ask interesting questions  ~  http://linkedin.com/in/martinlanghoff
 - don't be distracted~  http://github.com/martin-langhoff
   by shiny stuff
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Changelog between OS states (ie: VMs)

[Martin Langhoff]

I have two VMs, or OS states I can `rpm -qa` on. Is there a script to
diff the output of the two listings, and then query the package
changelogs to generate an overall OS-wide changelog?

Use case: I generated an F26 OVA image using imagefactory 30 days ago,
then I generated a new F26 image today. I'd export rpm -qa listings
from both, and then get a changelog showing all the package updates,
expecting to see the kernel package with the recent CVEs fixed.

Does such a tool exist?




m
-- 
 martin.langh...@gmail.com
 - ask interesting questions  ~  http://linkedin.com/in/martinlanghoff
 - don't be distracted~  http://github.com/martin-langhoff
   by shiny stuff
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Switch a package from noarch to arch - current guidelines?

[Martin Langhoff]

On Thu, Jul 27, 2017 at 11:04 AM, Vít Ondruch <vondr...@redhat.com> wrote:
>
> This was related to rubygem-bson and I switched the rubygem-bson from noarch 
> to arch in this commit:
>
> http://pkgs.fedoraproject.org/cgit/rpms/rubygem-bson.git/commit/?id=f507fa3ee0e8b29e60ef6164c28733691332dea4
>
> I don't think there should be any additional concern ATM.


So no need to obsolete the package itself? yum and dnf should handle
it all transparently?

Sounds easy enough :-)




martin
-- 
 martin.langh...@gmail.com
 - ask interesting questions  ~  http://linkedin.com/in/martinlanghoff
 - don't be distracted    ~  http://github.com/martin-langhoff
   by shiny stuff
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Switch a package from noarch to arch - current guidelines?

[Martin Langhoff]

Turns out that Elixir should not be noarch, as some of its code is
endianness specific. What's best practice to switch away from noarch for
packages in current Fedora? How about EPEL?

I see this outdated and unresolved Packaging Comittee issue...
https://pagure.io/packaging-committee/issue/117

and I see a bunch of bugs referring to specs (and rpms) that fail during
upgrades. Some have obsoletes on their own name, others don't.

https://bugzilla.redhat.com/show_bug.cgi?id=753149
https://bugzilla.redhat.com/show_bug.cgi?id=1230183
https://bugzilla.redhat.com/show_bug.cgi?id=1301306

Is there clarity / consensus on this? Any packages that have made the
transition successfully recently?

cheers,



martin
-- 
 martin.langh...@gmail.com
 - ask interesting questions  ~  http://linkedin.com/in/martinlanghoff
 - don't be distracted~  http://github.com/martin-langhoff
   by shiny stuff
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: journal-triggerd, interest, alternatives?

[Martin Langhoff]

Thanks for the heads up on rsyslog. I've been using it for ages, yet I
didn't know you could trigger commands directly from there.

I see it has omprog, as well as

   :msg, regex, "hellothere" ^/usr/local/bin/hi.bash

good to know. I'll see which path I take. I already have the spec file
working for Fedora.

cheers,


m

On Wed, Feb 15, 2017 at 1:52 PM, Rich Megginson <rmegg...@redhat.com> wrote:
> On 02/15/2017 11:31 AM, Martin Langhoff wrote:
>>
>> On Wed, Feb 15, 2017 at 11:19 AM, Rich Megginson <rmegg...@redhat.com>
>> wrote:
>>>
>>> Probably most Fedora users will use a general purpose tool like rsyslog
>>> (already in Fedora) or fluentd/logstash to read events from journald and
>>> do
>>> custom triggers.
>>
>> thanks for the info! It seems to me that journal-triggerd fits a
>> different use case from the tools mentioned so far, so I'll keep
>> chipping at it :-)
>>
>> journal-triggerd is a tiny utility written in C, meant for
>> local/standalone use, more general purpose than fail2ban (which I
>> use), but otherwise in a similar "simple to install, small footprint,
>> for single node" space.
>
>
> I guess if you want a very small tool written for a very specific purpose,
> then that fits the bill.
>
> If you don't mind using rsyslog, it will do what you want, and much more,
> and it's already in Fedora.
>
>>
>> I've used logstash/kibana (fluentd seems similar), and those are log
>> aggregators, with a much  more involved setup, geared for big traffic.
>>
>> cheers,
>>
>>
>>
>> martin
>
>
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org



-- 
 martin.langh...@gmail.com
 - ask interesting questions  ~  http://linkedin.com/in/martinlanghoff
 - don't be distracted~  http://github.com/martin-langhoff
   by shiny stuff
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: journal-triggerd, interest, alternatives?

[Martin Langhoff]

On Wed, Feb 15, 2017 at 11:19 AM, Rich Megginson <rmegg...@redhat.com> wrote:
> Probably most Fedora users will use a general purpose tool like rsyslog
> (already in Fedora) or fluentd/logstash to read events from journald and do
> custom triggers.

thanks for the info! It seems to me that journal-triggerd fits a
different use case from the tools mentioned so far, so I'll keep
chipping at it :-)

journal-triggerd is a tiny utility written in C, meant for
local/standalone use, more general purpose than fail2ban (which I
use), but otherwise in a similar "simple to install, small footprint,
for single node" space.

I've used logstash/kibana (fluentd seems similar), and those are log
aggregators, with a much  more involved setup, geared for big traffic.

cheers,



martin
-- 
 martin.langh...@gmail.com
 - ask interesting questions  ~  http://linkedin.com/in/martinlanghoff
 - don't be distracted~  http://github.com/martin-langhoff
   by shiny stuff
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

journal-triggerd, interest, alternatives?

[Martin Langhoff]

My applications largely log to system loggers. Looking around for
something that triggers an email when certain log entries appear in
system logs (ie: python stacktraces), I got just one hit,
journal-triggerd. It is not in Fedora.

   https://github.com/jjk-jacky/journal-triggerd

Have I missed anything? Seems like the kind of tool we'd have already,
as we've had systemd/journald for a while.

There's a Mageia package, I'll take a look at its spec file, might
prepare one for consideration for Fedora...


cheers,



martin
-- 
 martin.langh...@gmail.com
 - ask interesting questions  ~  http://linkedin.com/in/martinlanghoff
 - don't be distracted~  http://github.com/martin-langhoff
   by shiny stuff
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

dnf system upgrade has zero progress on text boot (`quiet no rhgb`)

[Martin Langhoff]

One of my laptops has quiet and no rhgb in the grub line, so no pretty UI.

As I wasn't paying attention, I used the fedup commands (download, reboot),
which got routed to dnf. Upon reboot, the on-screen output showed a partial
boot (from systemd messages) and no indication that an upgrade was underway.

Logging in as root and tailing /var/log/dnf*.log does work.

Am I using this wrong? Seems to me like it's essential to have at least
some minimal dnf output in the text mode boot (ie: "Starting system
upgrade, could take forever").

After some googling I did find the option to have debug info on tty9.
Perhaps should be enabled by default?

cheers,



m
-- 
 martin.langh...@gmail.com
 - ask interesting questions  ~  http://linkedin.com/in/martinlanghoff
 - don't be distracted~  http://github.com/martin-langhoff
   by shiny stuff
--
devel mailing list
devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: Debugging NetworkManager-openvpn -- procedure?

[Martin Langhoff]

On Thu, Apr 14, 2016 at 12:41 PM, Thomas Haller  wrote:
> https://wiki.gnome.org/Projects/NetworkManager/Debugging#Debugging_NetworkManager-openvpn
>
> still works for me on F23 (nm-1-0).

good to hear! I'm on F23 right now.

The top of that page says it's all stale due to systemd, so I thought
perhaps nm-openvpn instantiation was mediated through systemd somehow,
and the method you mention wouldn't work right.

Re-tested with your method, same output as my method.

> F24 comes with 1-2-rc1. There it might be different... If your nm-
> openvpn plugin is of version 1.2, you might need to set
>   "supports-multiple-connections=false"
> in both
>   /etc/NetworkManager/VPN/nm-openvpn-service.name
>   /usr/lib/NetworkManager/VPN//nm-openvpn-service.name
> After that, the steps above should work again.

thanks!


m
-- 
 martin.langh...@gmail.com
 -  ask interesting questions
 - don't get distracted with shiny stuff  - working code first
 ~ http://docs.moodle.org/en/User:Martin_Langhoff
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: Debugging NetworkManager-openvpn -- procedure?

[Martin Langhoff]

On Thu, Apr 14, 2016 at 12:16 PM, Martin Langhoff
<martin.langh...@gmail.com> wrote:
> Having a hard time with an OpenVPN network, where logs in journald
> don't show anything of interest yet nm-openvpn quits.

To answer my own question:

 - Create /usr/libexec/nm-openvpn-service-debug, a shell script that
execs  /usr/libexec/nm-openvpn-service --debug

 - killall nm-openvpn-service

 - Edit /etc/NetworkManager/VPN/nm-openvpn-service.name to use
/usr/libexec/nm-openvpn-service-debug

 - Set loglevel=DEBUG in /etc/NetworkManager/NetworkManager.conf

 - Restart NetworkManager

 - Grab output with journald -f -u nm-openvpn -u NetworkManager

Funny enough when nm-openvpn-service is run with --debug, its output
changes from being logged as nm-openvpn to NetworkManager.

Now I have all the log output; can't make heads nor tail of it but
hey. Progress :-)


m
-- 
 martin.langh...@gmail.com
 -  ask interesting questions
 - don't get distracted with shiny stuff  - working code first
 ~ http://docs.moodle.org/en/User:Martin_Langhoff
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Debugging NetworkManager-openvpn -- procedure?

[Martin Langhoff]

Having a hard time with an OpenVPN network, where logs in journald
don't show anything of interest yet nm-openvpn quits.

What is the right procedure to pass the --debug flag to nm-openvpn
these days (i.e.: F23/F24)?

Everything I find is seriously outdated. Recent bz entries I reviewed
didn't offer any hints either...

thank you,



m
-- 
 martin.langh...@gmail.com
 -  ask interesting questions
 - don't get distracted with shiny stuff  - working code first
 ~ http://docs.moodle.org/en/User:Martin_Langhoff
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: librsvg2 breakage in rawhide

[Martin Langhoff]

On Thu, Feb 25, 2016 at 12:56 PM, Kevin Fenzi  wrote:
> We are working on a fix for pkgdb now.

Thank you!



m
-- 
 martin.langh...@gmail.com
 -  ask interesting questions
 - don't get distracted with shiny stuff  - working code first
 ~ http://docs.moodle.org/en/User:Martin_Langhoff
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

librsvg2 breakage in rawhide

[Martin Langhoff]

Hoping to raise the profile of BZ#1311814 ; seems to break anything
that requires graphviz. That's a good chunk of the distro.

It initially broke Elixir builds, I just got notification about ejabberd.

cheers,



m
-- 
 martin.langh...@gmail.com
 -  ask interesting questions
 - don't get distracted with shiny stuff  - working code first
 ~ http://docs.moodle.org/en/User:Martin_Langhoff
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: Erlang busted on i386 on rawhide... workaround for erlang-based packages?

[Martin Langhoff]

Hi Peter(s),

On Wed, Feb 10, 2016 at 5:37 AM, Peter Lemenkov  wrote:
> Yes, that's a known issue I'm trying to address now. I've got a
> possible fix from upstream developers, so things are getting better.

That's great to hear. Am I tracking the right BZ# with  BZ#1240487?

cheers,



m
-- 
 martin.langh...@gmail.com
 -  ask interesting questions
 - don't get distracted with shiny stuff  - working code first
 ~ http://docs.moodle.org/en/User:Martin_Langhoff
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: Erlang busted on i386 on rawhide... workaround for erlang-based packages?

[Martin Langhoff]

Here's a koji build showing FTBFS on i686
http://koji.fedoraproject.org/koji/taskinfo?taskID=12918486

I get the exact same result on my F23/x86_64 laptop with

  fedpkg --dist fedora-rawhide mockbuild --root
/etc/mock/fedora-rawhide-i386.cfg

failure happens on the same compile step.



m

On Tue, Feb 9, 2016 at 7:10 PM, Martin Langhoff <martin.langh...@gmail.com>
wrote:

> Hi folks,
>
> trying to upload a new release of elixir, I am butting into something that
> looks and smells a lot like BZ#1240487 -- the (noarch) rpm builds nicely on
> x86_64 but the erlang runtime segfaults every time on i386.
>
> This FTBS repros for me on koji and under mockbuild locally (x66_64 f23).
>
>  - What's best strategy to bypass this and get it built on x86_64? Setting
> an arch on it seems ugly...
>
>  - Anything we can do to diag?
>
> cheers,
>
>
> m
> --
>  martin.langh...@gmail.com
>  -  ask interesting questions
>  - don't get distracted with shiny stuff  - working code first
>  ~ http://docs.moodle.org/en/User:Martin_Langhoff
>



-- 
 martin.langh...@gmail.com
 -  ask interesting questions
 - don't get distracted with shiny stuff  - working code first
 ~ http://docs.moodle.org/en/User:Martin_Langhoff
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Erlang busted on i386 on rawhide... workaround for erlang-based packages?

[Martin Langhoff]

Hi folks,

trying to upload a new release of elixir, I am butting into something that
looks and smells a lot like BZ#1240487 -- the (noarch) rpm builds nicely on
x86_64 but the erlang runtime segfaults every time on i386.

This FTBS repros for me on koji and under mockbuild locally (x66_64 f23).

 - What's best strategy to bypass this and get it built on x86_64? Setting
an arch on it seems ugly...

 - Anything we can do to diag?

cheers,


m
-- 
 martin.langh...@gmail.com
 -  ask interesting questions
 - don't get distracted with shiny stuff  - working code first
 ~ http://docs.moodle.org/en/User:Martin_Langhoff
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: We want to stop systemd from being added to docker images, because of rpm requiring systemctl.

[Martin Langhoff]

On Tue, Apr 29, 2014 at 4:16 PM, Reindl Harald h.rei...@thelounge.netwrote:


 don't get me wrong but you are talking bullshit


Reindl, your SNR is way way high. Maybe try sending /less/ emails,
concentrating in being clear and helpful?

Don't worry, there is _always_ someone who's wrong on the internet. You
can't address all of them... keep in mind, in some cases you are the one
who isn't fully understanding the topic...

cheers,



m
-- 
 martin.langh...@gmail.com
 -  ask interesting questions
 - don't get distracted with shiny stuff  - working code first
 ~ http://docs.moodle.org/en/User:Martin_Langhoff
-- 
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: We want to stop systemd from being added to docker images, because of rpm requiring systemctl.

[Martin Langhoff]

On Tue, Apr 29, 2014 at 5:12 PM, Reindl Harald h.rei...@thelounge.netwrote:

 defense in depth means limit the attack surface as much as you can


As folks are trying to point out to you, these principles are well
understood in this group.

However, _any minimally usable environment will have a scripting engine_ --
/bin/sh, python, and having _any_ of those general purpose tools available
is enough for the attacker.

On your own machines, you might gain some (limited) advantage removing some
of them.

Fedora and its derivatives, OTOH, are a large enough target that it's worth
for attackers to tailor attacks to it. So removing some tools won't do
much, and removing _all_ tools will ruin everyone's day.



m
-- 
 martin.langh...@gmail.com
 -  ask interesting questions
 - don't get distracted with shiny stuff  - working code first
 ~ http://docs.moodle.org/en/User:Martin_Langhoff
-- 
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: We want to stop systemd from being added to docker images, because of rpm requiring systemctl.

[Martin Langhoff]

On Tue, Apr 29, 2014 at 5:28 PM, Chris Adams li...@cmadams.net wrote:

 Once upon a time, Reindl Harald h.rei...@thelounge.net said:
  however, thank you to show me that any discussion with you is worthless

 Right back at you.


The CoC does say a few things on this topic.

I am finding Reindl's trollish behavior extremely annoying. In my reading,
1% of his emails have some value, 99% are just winding people up :-(

Is there a cool down box available?



m
-- 
 martin.langh...@gmail.com
 -  ask interesting questions
 - don't get distracted with shiny stuff  - working code first
 ~ http://docs.moodle.org/en/User:Martin_Langhoff
-- 
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: F21 Self Contained Change: Remote Journal Logging

[Martin Langhoff]

On Wed, Apr 16, 2014 at 5:08 PM, Zbigniew Jędrzejewski-Szmek
zbys...@in.waw.pl wrote:
 So I'll ask you about this other aspect -- what about stateless
 clients with very limited or no local storage?
 Not supported by this, unfortunately. There needs to be at least
 temporary storage in tmpfs for this scheme to work.

Can the storage space used be limited with a parameter to avoid
ENOSPC? Can journald be told to start discarding the data (oldest or
latest) when it reaches the limit?

cheers,


m
-- 
 martin.langh...@gmail.com
 -  ask interesting questions
 - don't get distracted with shiny stuff  - working code first
 ~ http://docs.moodle.org/en/User:Martin_Langhoff
-- 
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: F21 Self Contained Change: Remote Journal Logging

[Martin Langhoff]

On Mon, Apr 14, 2014 at 9:07 AM, Jaroslav Reznik jrez...@redhat.com wrote:
 The communication between the two daemons is done over standard HTTPS,

Interesting. One quirk of current syslog-style remote logging over UDP
is that it is fairly tolerant to dataloss.

With quite a bit of experience in the field... I have to say that this
is both a bug, and a feature.

The bug is obvious, so let me explain the feature side

 - if the remote server is unreachable or unresponsive, clients
continue running without any adverse effects (other than loss of
logging data)

 - if the network link carrying the logging traffic is overwhelmed by
the traffic, client nodes continue running without any adverse effects
(other than...)  at least from the logging machinery -- other traffic
on that saturated link may lead other sw to misbehave)

I hear you holler OMG you have to build full redundancy in your
logging backend; and... I have not seen a single operation where the
logging backed was fully redundant.

And in fact it may be too much to ask -- in most setups log entries
are not _that_ precious. I know I can reconfigure a syslog server and
restart it without the 1K VMs that talk to it glitching. A recent
loop in our syslog configuration was a relatively minor problem
because it just dropped the traffic it couldn't handle for a brief
time while we fixed things.

This is the reality of system configs I know. Fully redundant,
perfect log servers are very hard to run, might not be worth it, and
anyway such a change won't happen overnight.

To avoid gridlocking operations, IMO this logging will need a local
queue, (for later retry), with a drop anything older than X escape
hatch...

cheers,



m
-- 
 martin.langh...@gmail.com
 -  ask interesting questions
 - don't get distracted with shiny stuff  - working code first
 ~ http://docs.moodle.org/en/User:Martin_Langhoff
-- 
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: F21 Self Contained Change: Remote Journal Logging

[Martin Langhoff]

On Wed, Apr 16, 2014 at 4:40 PM, Zbigniew Jędrzejewski-Szmek
zbys...@in.waw.pl wrote:
 the upload client is like any other journal client -- it is fully asynchronous
 wrt. to journald writing log entries. (It's something like
 'journalctl -o export|curl -X POST https://some.where/upload'.)

Fantastic, so there is a local spool. Somehow I had assumed there
would not be a local storage.

So I'll ask you about this other aspect -- what about stateless
clients with very limited or no local storage?

cheers,


m
-- 
 martin.langh...@gmail.com
 -  ask interesting questions
 - don't get distracted with shiny stuff  - working code first
 ~ http://docs.moodle.org/en/User:Martin_Langhoff
-- 
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: fedora-atomic discussion point: /usr/lib/passwd

[Martin Langhoff]

On Fri, Apr 11, 2014 at 2:33 AM, Colin Walters walt...@verbum.org wrote:
 One way to fix this that goes with my general direction of moving things out
 of %post into systemd: a dynamic uid reservation system that saves state
 persistently.
 Crudely, this would be ExecStartPre=/usr/sbin/useradd -r ...
 except we'd wrap that with something that checked whether the user existed
 first.

If you move in this direction, you have to create files/dirs to be
owned by the daemon user too.

This has quite broad implications.


m
-- 
 martin.langh...@gmail.com
 -  ask interesting questions
 - don't get distracted with shiny stuff  - working code first
 ~ http://docs.moodle.org/en/User:Martin_Langhoff
-- 
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: fedora-atomic discussion point: /usr/lib/passwd

[Martin Langhoff]

On Fri, Apr 11, 2014 at 12:49 PM, Lennart Poettering
mzerq...@0pointer.de wrote:
 On Fri, 11.04.14 16:09, Colin Walters (walt...@verbum.org) wrote:

 On Fri, Apr 11, 2014 at 11:33 AM, Martin Langhoff
 martin.langh...@gmail.com wrote:
 
 If you move in this direction, you have to create files/dirs to be
 owned by the daemon user too.

 Hmm, let's think for a moment what kind of files this actually matters
 for. In which directories do system users actually own files?

 That'd be suid/sgid binaries in /usr/bin. That'd be working directories
 in /run and /var. Anything else?

 The latter don't sound too bad, since we can allocate them during late
 boot. The fomer is the messy bit.

Stuff like /var/lib/{mysql,ldap} is what I was mainly referring to.
The services depend or could/should depend on resolving any mounts
needed to get /var/lib in place.

Not a big deal for systemd, but I want to note -- the creation of
/var/lib/{svc} is often driven by a script that may do additional work
(i.e.: create a template database), and may have interesting error
conditions.

Not sure why you mention suid/sgid -- this applies as long as the
service is run as a particular user. Maybe systemd needs to resolve
those users while parsing the service files?




m
-- 
 martin.langh...@gmail.com
 -  ask interesting questions
 - don't get distracted with shiny stuff  - working code first
 ~ http://docs.moodle.org/en/User:Martin_Langhoff
-- 
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: trimming down Fedora installed size

[Martin Langhoff]

On Wed, Apr 9, 2014 at 10:31 AM, Ralf Corsepius rc040...@freenet.de wrote:
 So, I'd question the usefulness of not installing man-pages, because their
 sizes are comparatively small on today's disk-scales, e.g. on my primary
 system:
 # du -sh /usr/share/man
 89M /usr/share/man

 That's almost neglibile in comparision to the overall size of the
 installation.

Disk usage of many small files can be disproportionate. On some
platforms -- embedded, lightweight VMs, the savings are sometimes
important. They sure were on XO-1 not that long ago, and I'm not sure
what I'd do with docs and manages in an on-demand VMs.

Having said that, exclude_docs and install_langs have worked well for
OLPC and work reasonably well for lightweight VMs too.

I am not arguing for big changes here. The plans outlined seem doable,
but reworking the whole distro into doc packages to fix something that
already works /reasonably well/ seems... not cost effective.

There are some limited use cases that aren't ideal now with
install_lang and exclude_docs. For example, installing missing docs or
langs -- for all or some packages. But that seems like it could be
solved by a script that drives rpm to do just that.

cheers,




m
-- 
 martin.langh...@gmail.com
 -  ask interesting questions
 - don't get distracted with shiny stuff  - working code first
 ~ http://docs.moodle.org/en/User:Martin_Langhoff
-- 
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: trimming down Fedora installed size

[Martin Langhoff]

On Wed, Apr 9, 2014 at 10:49 AM, Jóhann B. Guðmundsson
johan...@gmail.com wrote:
 It's more about getting to the point of being able to remove them and or
 have the option not to install them.

See my other email on this thread. Following on what I wrote there,
instead of reworking all the packages across the distro, a script can
be written to achieve the equivalent of exclude_docs.

 Embedded  + cloud + containers probably want to remove them

Those already work right with exclude_docs --  I have been a primary
user of both use cases (OLPC as embedded, cloud/containers now).

cheers,



m
-- 
 martin.langh...@gmail.com
 -  ask interesting questions
 - don't get distracted with shiny stuff  - working code first
 ~ http://docs.moodle.org/en/User:Martin_Langhoff
-- 
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: systemd bugs in F20/F21 - bug against the distribution?

[Martin Langhoff]

On Thu, Apr 3, 2014 at 3:08 PM, Reindl Harald h.rei...@thelounge.net wrote:
 Am 03.04.2014 20:00, schrieb Adam Jackson:
 On Thu, 2014-04-03 at 19:31 +0200, Reindl Harald wrote:

 and if someone asks why i called Lennart in #1072368
 names

 We didn't, and no justification would matter.  It's not acceptable
 behaviour, and you need to knock it off.

 i know that -

Then do. Your behavior is toxic, don't excuse it with others' behavior.



m
-- 
 martin.langh...@gmail.com
 -  ask interesting questions
 - don't get distracted with shiny stuff  - working code first
 ~ http://docs.moodle.org/en/User:Martin_Langhoff
-- 
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: systemd bugs in F20/F21 - bug against the distribution?

[Martin Langhoff]

On Thu, Apr 3, 2014 at 4:41 PM, Reindl Harald h.rei...@thelounge.net wrote:
 Am 03.04.2014 22:32, schrieb Adam Williamson:
 On Thu, 2014-04-03 at 19:31 +0200, Reindl Harald wrote:
 will that below ever get fixed in F20?

 https://bugzilla.redhat.com/show_bug.cgi?id=1072368

 The developer does not consider it to be a bug. You may disagree, but so
 far, you don't seem to have convinced him or any other systemd
 developers or, well, anyone else.

 than the developer should explain his point of view and
 ask for further input instead react with WONT FIX

Reindl. You are reading to retort, not to understand.

Please take a long moment to try to understand -- many folks that
would in some cases agree with some of your points think that overall
you are way wrong.

You should not answer every email addressed to you. Instead of
answering... read it :-)



m
-- 
 martin.langh...@gmail.com
 -  ask interesting questions
 - don't get distracted with shiny stuff  - working code first
 ~ http://docs.moodle.org/en/User:Martin_Langhoff
-- 
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: F20: what connects the lid switch to triggering suspend?

[Martin Langhoff]

On Thu, Mar 13, 2014 at 8:45 PM, Lennart Poettering mzerq...@0pointer.dewrote:

 Normally when you close the lid logind should log something about Lid
 closed or so... Look around the logs around this to figure out what
 mightbe going on.


Thanks -- this has worked and led me to a local service of mine (an openvpn
service that goes all funky when NM preps the network for suspend).

cheers,



m
-- 
 martin.langh...@gmail.com
 -  ask interesting questions
 - don't get distracted with shiny stuff  - working code first
 ~ http://docs.moodle.org/en/User:Martin_Langhoff
-- 
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: Maybe it's time to get rid of tcpwrappers/tcpd?

[Martin Langhoff]

On Sat, Mar 29, 2014 at 10:54 AM, Orion Poplawski or...@cora.nwra.com wrote:
 What gives you the impression that fail2ban is crusty?  It's being
 actively developed upstream and integrates with firewalld now.  Are
 those particularly onerous dependencies?

and with journal integration, python-inotify can probably go away, or
at least become optional.

cheers,


m
-- 
 martin.langh...@gmail.com
 -  ask interesting questions
 - don't get distracted with shiny stuff  - working code first
 ~ http://docs.moodle.org/en/User:Martin_Langhoff
-- 
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: Maybe it's time to get rid of tcpwrappers/tcpd?

[Martin Langhoff]

On Fri, Mar 21, 2014 at 6:16 PM, Jóhann B. Guðmundsson johan...@gmail.com
 wrote:

 In other words you are telling us that now to get something implemented or
 removed in Fedora we have to not only deal with our usual politics and
 bureaucracy but also all the downstream distribution to us as well...


One way to avoid those pesky details is to not have users... :-)


m
-- 
 martin.langh...@gmail.com
 -  ask interesting questions
 - don't get distracted with shiny stuff  - working code first
 ~ http://docs.moodle.org/en/User:Martin_Langhoff
-- 
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: Maybe it's time to get rid of tcpwrappers/tcpd?

[Martin Langhoff]

On Thu, Mar 20, 2014 at 1:34 PM, Lennart Poettering mzerq...@0pointer.dewrote:

 I wonder whether it wouldn't be time to say goodbye to tcpwrappers in
 Fedora. There has been a request in systemd upstream to disable support


As Stephen points out, they are used. Does systemd+xinetd match their
functionality?

cheers,


m
-- 
 martin.langh...@gmail.com
 -  ask interesting questions
 - don't get distracted with shiny stuff  - working code first
 ~ http://docs.moodle.org/en/User:Martin_Langhoff
-- 
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: Maybe it's time to get rid of tcpwrappers/tcpd?

[Martin Langhoff]

On Thu, Mar 20, 2014 at 8:00 PM, Lennart Poettering mzerq...@0pointer.dewrote:

 A firewall has mechanisms to filter for all domains, however only
 covering a smaller number of generic, low-level matches and actions.


From a usability PoV, /etc/hosts.{allow,deny} is good. I wonder if teaching
firewalld to support some of that functionality would help here.

cheers,


m
-- 
 martin.langh...@gmail.com
 -  ask interesting questions
 - don't get distracted with shiny stuff  - working code first
 ~ http://docs.moodle.org/en/User:Martin_Langhoff
-- 
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: Maybe it's time to get rid of tcpwrappers/tcpd?

[Martin Langhoff]

On Thu, Mar 20, 2014 at 8:04 PM, Martin Langhoff
martin.langh...@gmail.comwrote:

 On Thu, Mar 20, 2014 at 8:00 PM, Lennart Poettering 
 mzerq...@0pointer.dewrote:

 A firewall has mechanisms to filter for all domains, however only
 covering a smaller number of generic, low-level matches and actions.


 From a usability PoV, /etc/hosts.{allow,deny} is good. I wonder if
 teaching firewalld to support some of that functionality would help here.


To clarify: what I mean is that firewalld could parse the legacy files,
interpreting the rules that are translatable, failing safely for those that
are are not.

cheers,



m
-- 
 martin.langh...@gmail.com
 -  ask interesting questions
 - don't get distracted with shiny stuff  - working code first
 ~ http://docs.moodle.org/en/User:Martin_Langhoff



-- 
 martin.langh...@gmail.com
 -  ask interesting questions
 - don't get distracted with shiny stuff  - working code first
 ~ http://docs.moodle.org/en/User:Martin_Langhoff
-- 
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: F20: what connects the lid switch to triggering suspend?

[Martin Langhoff]

On Fri, Mar 14, 2014 at 12:41 PM, Tomasz Torcz to...@pipebreaker.pl wrote:

   systemd-inhibit --list


Fantastic info - Tomasz and Lennart. Thanks!


m
-- 
 martin.langh...@gmail.com
 -  ask interesting questions
 - don't get distracted with shiny stuff  - working code first
 ~ http://docs.moodle.org/en/User:Martin_Langhoff
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

F20: what connects the lid switch to triggering suspend?

[Martin Langhoff]

My Lenovo X220, running up-to-date F20 occasionally gets into a state where
closing the laptop lid does not trigger suspend.

I want to narrow down on the problem, but I'm slightly lost on how
the signal is routed through the stack. udev-?- systemd-suspend -
kernel  ?

thank you!



m
-- 
 martin.langh...@gmail.com
 -  ask interesting questions
 - don't get distracted with shiny stuff  - working code first
 ~ http://docs.moodle.org/en/User:Martin_Langhoff
-- 
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: F20: what connects the lid switch to triggering suspend?

[Martin Langhoff]

On Thu, Mar 13, 2014 at 6:38 PM, Andrew Lutomirski l...@mit.edu wrote:

 I wonder whether this is related to the fact that, on most Lenovos, if
 you press the suspect button twice without waiting long enough, the
 second press is ignored.


Seems unlikelye. I am very careful with double-presses, and my testing was
deliberate.

When it gets the funk, it seems to ignore lid switch and clear individual
presses of the power button.

I need to look more in the logs, but they are bulky/noisy, so if I know
what components are involved, I can narrow down on it.

cheers,


m
-- 
 martin.langh...@gmail.com
 -  ask interesting questions
 - don't get distracted with shiny stuff  - working code first
 ~ http://docs.moodle.org/en/User:Martin_Langhoff
-- 
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: ostree/fedora atomic and impact on the mirror network

[Martin Langhoff]

On Tue, Mar 11, 2014 at 9:10 AM, Colin Walters walt...@verbum.org wrote:
 Remember OSTree is a content-addressed object store (like git), not a chain
 of deltas (like Subversion, and other systems out there such as Chromium
 Autoupdate, and Docker).

Ouch -- so updates fetch EVERY file regardless of whether it has
changed between the snapshot installed and the target snapshot? That
is kind of bad.

Are you aware of the work done on OLPC's os-builder, which used rsync
informed by a per-snapshot metatada file?

 Ultimately while the loose design may seem naïve, it's not hard to scale

As I mentioned, it seems to me that OLPC's os-builder might be of
interest to you.

In our experience, the problem we had was network latency. On a local
network, a small OS image, and with rsync client sending requests
speculatively a bit ahead of receiving the response to its prev
request... the lag for clients updating was horrible.

How long does an update of a full Fedora take when the server is
remote, on a relatively good home connection?

(Is there a good overview I should be reading?)



m
-- 
 martin.langh...@gmail.com
 -  ask interesting questions
 - don't get distracted with shiny stuff  - working code first
 ~ http://docs.moodle.org/en/User:Martin_Langhoff
-- 
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: Per-Product Config file divergence

[Martin Langhoff]

On Mon, Mar 10, 2014 at 3:56 PM, Stephen Gallagher sgall...@redhat.com wrote:
  2) If we allow switching between products, we probably have to treat
 the entire Product configuration of a package as a single unit.

ok.

 Edits to somefile.conf would change whatever's on the other end of the
 link. The alternatives system would change this linkage, to another
 version, but switching it back will give you your edits, not just the
 original defaults.

If this is what we do, then the target of that link must be marked in
the rpm packages as %conf, regardless of where it resides.

For an approach like this, which I'm not yet sure I like, I'd consider
putting some effort on improving alternatives. It's never been used
for editable targets afaict.

cheers,


m
-- 
 martin.langh...@gmail.com
 -  ask interesting questions
 - don't get distracted with shiny stuff  - working code first
 ~ http://docs.moodle.org/en/User:Martin_Langhoff
-- 
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: Per-Product Config file divergence

[Martin Langhoff]

On Mon, Mar 10, 2014 at 4:30 PM, Toshio Kuratomi a.bad...@gmail.com wrote:
 It may be that vanilla alternatives is unsuitable but we want something
 alternatives-like (an external tool that updates the config file) rather
 than something based on rpm metadata (Conflicts which causes you to have
 either one or the other package installed).

Yep, that's exactly my thinking. Hard to think through the scenarios
without some concrete examples.

Is there a listing of concrete use-cases? i.e.: server configuration
with a paranoid settings for sshd_conf / sudoers / securetty , vs more
liberal desktop config?


m
-- 
 martin.langh...@gmail.com
 -  ask interesting questions
 - don't get distracted with shiny stuff  - working code first
 ~ http://docs.moodle.org/en/User:Martin_Langhoff
-- 
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: Per-Product Config file divergence

[Martin Langhoff]

On Mon, Mar 10, 2014 at 11:27 PM, Kevin Kofler kevin.kof...@chello.at wrote:
 What's wrong with just dropping the defaults in /etc in the Product's live
 kickstart? (Yes, that assumes the Product is delivered as a live image. We

For server images, Live isn't so hot. Can anaconda be taught to
execute a %product Foo kickstart file section?

cheers,



m
-- 
 martin.langh...@gmail.com
 -  ask interesting questions
 - don't get distracted with shiny stuff  - working code first
 ~ http://docs.moodle.org/en/User:Martin_Langhoff
-- 
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: ostree/fedora atomic and impact on the mirror network

[Martin Langhoff]

On Mon, Mar 10, 2014 at 10:11 AM, Colin Walters walt...@verbum.org wrote:
 One model I'd like to aim for here is we say the repository will take up at
 most N  GB (where e.g. N=100) and we keep an intelligently-scheduled series
 of snapshots, like backup systems do.

What happens to a client that is more than 100 snapshots behind?

cheers,



m
-- 
 martin.langh...@gmail.com
 -  ask interesting questions
 - don't get distracted with shiny stuff  - working code first
 ~ http://docs.moodle.org/en/User:Martin_Langhoff
-- 
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: F21 System Wide Change: System-wide crypto policy

[Martin Langhoff]

On Thu, Feb 27, 2014 at 11:22 AM, Jaroslav Reznik jrez...@redhat.com wrote:
 Unify the crypto policies used by different applications and libraries. That 
 is
 allow setting a consistent security level for crypto on all applications in a
 Fedora system.

As others have noted, crypto tech compatibility is tricky. Clients and
servers that you want to interoperate with have interesting mixes of
supported crypto suites. And the quality of crypto suites is
very-nonlinear and multidimensional.

Every crypto suite choice is fraught with tricky tradeoffs in threat
vs interoperability, and this is different on each protocol.

Personally, I cannot picture a good way to consolidate this into a
single policy...



m
-- 
 martin.langh...@gmail.com
 -  ask interesting questions
 - don't get distracted with shiny stuff  - working code first
 ~ http://docs.moodle.org/en/User:Martin_Langhoff
-- 
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: F20: Puppet depchain pulls in Java

[Martin Langhoff]

On Mon, Jan 20, 2014 at 10:29 AM, Vít Ondruch vondr...@redhat.com wrote:
 Seems to be bug. Haven't seen any bug report from you yet, so I did one
 for you: https://github.com/bkabrda/rubypick/issues/4


 https://admin.fedoraproject.org/updates/rubypick-1.1.1-1.fc20
 https://admin.fedoraproject.org/updates/rubypick-1.1.1-1.fc19

Thank you -- fantastic! I got dragged into the vortex of the weekend,
and was planning to follow things up this week. You're too quick.

I am also glad to see that the puppet ruby dep has some eyes on it. It
is a far more gnarly topic if you think (as I do) that the depsolve
machinery really needs a way to express preferences (ruby  jruby).

cheers,


m
-- 
 martin.langh...@gmail.com
 -  ask interesting questions
 - don't get distracted with shiny stuff  - working code first
 ~ http://docs.moodle.org/en/User:Martin_Langhoff
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

F20: Puppet depchain pulls in Java

[Martin Langhoff]

Puppet (the client side, at least) should be installable with
relatively thin deps, so it can manage lightweight hosts...

I am having trouble disentangling which deps to file a bug against;
maybe virt-what ?

[martin@tp-martin puppet-rlgold.git]$ sudo yum install puppet
[sudo] password for martin:
Sorry, try again.
[sudo] password for martin:
Loaded plugins: etckeeper, langpacks, refresh-packagekit
Repository 'spotify' is missing name in configuration, using id
Resolving Dependencies
-- Running transaction check
--- Package puppet.noarch 0:3.3.2-1.fc20 will be installed
-- Processing Dependency: hiera = 1.0.0 for package:
puppet-3.3.2-1.fc20.noarch
-- Processing Dependency: facter = 1.6.6 for package:
puppet-3.3.2-1.fc20.noarch
-- Processing Dependency: ruby(shadow) for package: puppet-3.3.2-1.fc20.noarch
-- Processing Dependency: ruby(selinux) for package: puppet-3.3.2-1.fc20.noarch
-- Processing Dependency: ruby(release) for package: puppet-3.3.2-1.fc20.noarch
-- Processing Dependency: ruby(augeas) for package: puppet-3.3.2-1.fc20.noarch
-- Processing Dependency: ruby for package: puppet-3.3.2-1.fc20.noarch
-- Processing Dependency: /usr/bin/ruby for package: puppet-3.3.2-1.fc20.noarch
-- Running transaction check
--- Package facter.x86_64 0:1.6.18-5.fc20 will be installed
-- Processing Dependency: virt-what for package: facter-1.6.18-5.fc20.x86_64
--- Package hiera.noarch 0:1.2.1-1.fc20 will be installed
--- Package jruby.noarch 0:1.7.2-5.fc20 will be installed
-- Processing Dependency: joni = 1.1.2 for package: jruby-1.7.2-5.fc20.noarch
-- Processing Dependency: jnr-posix = 1.1.8 for package:
jruby-1.7.2-5.fc20.noarch
-- Processing Dependency: jnr-ffi = 0.5.10 for package:
jruby-1.7.2-5.fc20.noarch
-- Processing Dependency: jline2 = 2.7 for package: jruby-1.7.2-5.fc20.noarch
-- Processing Dependency: jffi = 1.0.10 for package: jruby-1.7.2-5.fc20.noarch
-- Processing Dependency: jcodings = 1.0.1 for package:
jruby-1.7.2-5.fc20.noarch
-- Processing Dependency: felix-osgi-core = 1.4.0 for package:
jruby-1.7.2-5.fc20.noarch
-- Processing Dependency: bytelist = 1.0.8 for package:
jruby-1.7.2-5.fc20.noarch
-- Processing Dependency: yydebug for package: jruby-1.7.2-5.fc20.noarch
-- Processing Dependency: snakeyaml for package: jruby-1.7.2-5.fc20.noarch
-- Processing Dependency: rubygems for package: jruby-1.7.2-5.fc20.noarch
-- Processing Dependency: objectweb-asm4 for package: jruby-1.7.2-5.fc20.noarch
-- Processing Dependency: nailgun for package: jruby-1.7.2-5.fc20.noarch
-- Processing Dependency: jzlib for package: jruby-1.7.2-5.fc20.noarch
-- Processing Dependency: jruby-yecht for package: jruby-1.7.2-5.fc20.noarch
-- Processing Dependency: joda-time for package: jruby-1.7.2-5.fc20.noarch
-- Processing Dependency: jnr-unixsocket for package: jruby-1.7.2-5.fc20.noarch
-- Processing Dependency: jnr-netdb for package: jruby-1.7.2-5.fc20.noarch
-- Processing Dependency: jnr-enxio for package: jruby-1.7.2-5.fc20.noarch
-- Processing Dependency: jnr-constants for package: jruby-1.7.2-5.fc20.noarch
-- Processing Dependency: jna for package: jruby-1.7.2-5.fc20.noarch
-- Processing Dependency: jansi for package: jruby-1.7.2-5.fc20.noarch
-- Processing Dependency: invokebinder for package: jruby-1.7.2-5.fc20.noarch
-- Processing Dependency: bsf for package: jruby-1.7.2-5.fc20.noarch
-- Processing Dependency: bouncycastle-mail for package:
jruby-1.7.2-5.fc20.noarch
-- Processing Dependency: bouncycastle for package: jruby-1.7.2-5.fc20.noarch
-- Processing Dependency: apache-commons-logging for package:
jruby-1.7.2-5.fc20.noarch
--- Package libselinux-ruby.x86_64 0:2.2.1-6.fc20 will be installed
--- Package ruby.x86_64 0:2.0.0.353-16.fc20 will be installed
-- Processing Dependency: ruby-libs(x86-64) = 2.0.0.353-16.fc20 for
package: ruby-2.0.0.353-16.fc20.x86_64
-- Processing Dependency: rubygem(bigdecimal) = 1.2.0 for package:
ruby-2.0.0.353-16.fc20.x86_64
-- Processing Dependency: libruby.so.2.0()(64bit) for package:
ruby-2.0.0.353-16.fc20.x86_64
--- Package ruby-augeas.x86_64 0:0.5.0-2.fc20 will be installed
--- Package ruby-shadow.x86_64 0:1.4.1-20.fc20 will be installed
--- Package rubypick.noarch 0:1.1.0-2.fc20 will be installed
-- Running transaction check
--- Package apache-commons-logging.noarch 0:1.1.3-7.fc20 will be installed
-- Processing Dependency: mvn(logkit:logkit) for package:
apache-commons-logging-1.1.3-7.fc20.noarch
-- Processing Dependency: mvn(log4j:log4j) for package:
apache-commons-logging-1.1.3-7.fc20.noarch
-- Processing Dependency: mvn(avalon-framework:avalon-framework-api)
for package: apache-commons-logging-1.1.3-7.fc20.noarch
--- Package bouncycastle.noarch 0:1.46-11.fc20 will be installed
--- Package bouncycastle-mail.noarch 0:1.46-11.fc20 will be installed
-- Processing Dependency: javamail for package:
bouncycastle-mail-1.46-11.fc20.noarch
--- Package bsf.noarch 0:2.4.0-17.fc20 will be installed
-- Processing Dependency: xalan-j2 for package: bsf-2.4.0-17.fc20.noarch
--- Package 

Re: F20: Puppet depchain pulls in Java

[Martin Langhoff]

On Fri, Jan 17, 2014 at 5:07 PM, Martin Langhoff
martin.langh...@gmail.com wrote:
 Puppet (the client side, at least) should be installable with
 relatively thin deps, so it can manage lightweight hosts...

 I am having trouble disentangling which deps to file a bug against;
 maybe virt-what ?

Alright, I think I know what's happening: yum resolves the dep on ruby
by installing jruby AND ruby-mri

If I do yum install ruby ; yum install puppet, then things make sense. See

[martin@tp-martin puppet-rlgold.git]$ sudo yum install ruby
Loaded plugins: etckeeper, langpacks, refresh-packagekit
Repository 'spotify' is missing name in configuration, using id
Resolving Dependencies
-- Running transaction check
--- Package ruby.x86_64 0:2.0.0.353-16.fc20 will be installed
-- Processing Dependency: ruby-libs(x86-64) = 2.0.0.353-16.fc20 for
package: ruby-2.0.0.353-16.fc20.x86_64
-- Processing Dependency: rubygem(bigdecimal) = 1.2.0 for package:
ruby-2.0.0.353-16.fc20.x86_64
-- Processing Dependency: ruby(rubygems) = 2.0.3 for package:
ruby-2.0.0.353-16.fc20.x86_64
-- Processing Dependency: /usr/bin/ruby for package:
ruby-2.0.0.353-16.fc20.x86_64
-- Processing Dependency: libruby.so.2.0()(64bit) for package:
ruby-2.0.0.353-16.fc20.x86_64
-- Running transaction check
--- Package ruby-libs.x86_64 0:2.0.0.353-16.fc20 will be installed
--- Package rubygem-bigdecimal.x86_64 0:1.2.0-16.fc20 will be installed
--- Package rubygems.noarch 0:2.1.11-115.fc20 will be installed
-- Processing Dependency: rubygem(rdoc) = 4.0.0 for package:
rubygems-2.1.11-115.fc20.noarch
-- Processing Dependency: rubygem(psych) = 2.0.0 for package:
rubygems-2.1.11-115.fc20.noarch
-- Processing Dependency: rubygem(io-console) = 0.4.1 for package:
rubygems-2.1.11-115.fc20.noarch
--- Package rubypick.noarch 0:1.1.0-2.fc20 will be installed
-- Running transaction check
--- Package rubygem-io-console.x86_64 0:0.4.2-16.fc20 will be installed
--- Package rubygem-psych.x86_64 0:2.0.0-16.fc20 will be installed
-- Processing Dependency: libyaml-0.so.2()(64bit) for package:
rubygem-psych-2.0.0-16.fc20.x86_64
--- Package rubygem-rdoc.noarch 0:4.0.1-2.fc20 will be installed
-- Processing Dependency: rubygem(json)  2 for package:
rubygem-rdoc-4.0.1-2.fc20.noarch
-- Processing Dependency: rubygem(json) = 1.4 for package:
rubygem-rdoc-4.0.1-2.fc20.noarch
-- Processing Dependency: ruby(irb) for package:
rubygem-rdoc-4.0.1-2.fc20.noarch
-- Running transaction check
--- Package libyaml.x86_64 0:0.1.4-5.fc20 will be installed
--- Package ruby-irb.noarch 0:2.0.0.353-16.fc20 will be installed
--- Package rubygem-json.x86_64 0:1.7.7-101.fc20 will be installed
-- Finished Dependency Resolution
Dependencies Resolved
===
 Package  Arch
Version Repository
Size
===
Installing:
 ruby x86_64
2.0.0.353-16.fc20   updates
65 k
Installing for dependencies:
 libyaml  x86_64
0.1.4-5.fc20fedora
54 k
 ruby-irb noarch
2.0.0.353-16.fc20   updates
86 k
 ruby-libsx86_64
2.0.0.353-16.fc20   updates
2.8 M
 rubygem-bigdecimal   x86_64
1.2.0-16.fc20   updates
77 k
 rubygem-io-console   x86_64
0.4.2-16.fc20   updates
48 k
 rubygem-json x86_64
1.7.7-101.fc20  fedora
60 k
 rubygem-psychx86_64
2.0.0-16.fc20   updates
75 k
 rubygem-rdoc noarch
4.0.1-2.fc20fedora
288 k
 rubygems noarch
2.1.11-115.fc20 updates
224 k
 rubypick noarch
1.1.0-2.fc20fedora
6.3 k
Transaction Summary
===
Install  1 Package (+10 Dependent packages)
Total download size: 3.7 M
Installed size: 13 M
Is this ok [y/d/N]:
Exiting on user command
Your transaction was saved, rerun it with:
 yum load-transaction /tmp/yum_save_tx.2014-01-17.17-21.bbvkRY.yumtx
[martin@tp-martin puppet-rlgold.git]$ sudo yum install ruby
Loaded plugins: etckeeper, langpacks, refresh-packagekit
Repository 'spotify' is missing name in configuration, using id
Resolving Dependencies
-- Running transaction check
--- Package ruby.x86_64 0:2.0.0.353-16.fc20 will be installed
-- Processing Dependency: ruby

Re: F20: Puppet depchain pulls in Java

[Martin Langhoff]

On Fri, Jan 17, 2014 at 5:24 PM, Bill Nottingham nott...@redhat.com wrote:
 You need to make sure your transaction is pulling in classic ruby
 rather than jruby.

Well, ideally something in the dep data should indicate a preference,
and the depsolver should handle that.

What's happening however is that I am getting both classic ruby (which
rubypick calls ruby-mri) AND jruby installed.

Interestingly enough, after uninstalling jruby, rubypick still thinks
it's installed!

[martin@tp-martin puppet-rlgold.git]$ ruby --help
This is Fedora's rubypick - a Ruby runtime chooser. You can use it
to execute Ruby programmes with any Fedora Ruby runtime.
These currently include:
Ruby - binary /usr/bin/ruby-mri - Installed
JRuby - binary /usr/bin/jruby -  Installed
To run a specific runtime, use:
ruby _mri_ [params]
ruby _jruby_ [params]
The default is _mri_.
(...)

[martin@tp-martin puppet-rlgold.git]$ stat /usr/bin/jruby
stat: cannot stat ‘/usr/bin/jruby’: No such file or directory

The whole thing seems... suboptimal :-)




m
-- 
 martin.langh...@gmail.com
 -  ask interesting questions
 - don't get distracted with shiny stuff  - working code first
 ~ http://docs.moodle.org/en/User:Martin_Langhoff
-- 
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: dnf versus yum

[Martin Langhoff]

On Thu, Jan 2, 2014 at 3:52 PM, Matthew Miller mat...@fedoraproject.org wrote:
 This one is clearly one of those doomed to repeat history things in
 motion.

It seems to me that dbf has to strike an impossible balance.

Asking that dnf supports every yum behavior would negate the benefit
of having dnf, which is to break from the heavy corset of backwards
compat yum wears.

So the dev team has to pick and choose. Not an easy spot to be in.
Perhaps some civility would help. Remember: every feature has a vocal
fan, but if they appease you and all the others, we're back to where
we started -- yum.



m
-- 
 martin.langh...@gmail.com
 -  ask interesting questions
 - don't get distracted with shiny stuff  - working code first
 ~ http://docs.moodle.org/en/User:Martin_Langhoff
-- 
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: dnf versus yum

[Martin Langhoff]

On Thu, Jan 2, 2014 at 5:21 PM, Reindl Harald h.rei...@thelounge.net wrote:
 with my software-developer hat on the opposite is true

I discussed yum internals quite a bit with Seth in past years. Every
change I proposed met a wall of backwards compatibility. Turns out
that there are many very specific corner cases, and yum has it on its
shoulders to not mess with them.

AIUI, the yum team has refactored quite a bit in place, and that's
what you seem to be referring to.

dnf is a chance to drop some of that backwards compat and move
forward. Users (usually corporate) that have a rigid need of the old
behavior can continue to use yum for as it is maintained; and it is
likely that RH would keep it maintained for a long time.

I expect yum to continue to live as the backwards compat tool, even as
dnf takes center stage.

Please respect that others may have knowledge and experience that you
don't, you are coming across as rather argumentative.

cheers,


m
-- 
 martin.langh...@gmail.com
 -  ask interesting questions
 - don't get distracted with shiny stuff  - working code first
 ~ http://docs.moodle.org/en/User:Martin_Langhoff
-- 
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: mechanism to retain system library versions

[Martin Langhoff]

On Wed, Dec 18, 2013 at 8:19 AM, Neal Becker ndbeck...@gmail.com wrote:
 2) somehow build against f20 libs on an f19 system?

this is trivially done using mock. Actually, what I do, even for
non-public builds, is to have a spec file in a git repository and
build/rebuild the rpm using fedpkg.

fedpkg makes things incredibly easy and practical, and it drives mock
just right.

It does require a bit of setup, naturally, but once it's there... magic.



m
-- 
 martin.langh...@gmail.com
 -  ask interesting questions
 - don't get distracted with shiny stuff  - working code first
 ~ http://docs.moodle.org/en/User:Martin_Langhoff
-- 
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: mechanism to retain system library versions

[Martin Langhoff]

Neal,

look like you've found the one thing fedora devel has consensus on ;-)

Here is a series of git repos that show how I was maintaining some
rpms outside of the fedora infra, but using fedpkg (which I recommend)
-- more specifically mockbuild.

These repos are public, but you can do the same in private git repos.

Given a bit of familiarity with spec files and git, this should be easy.

cheers,



m


On Wed, Dec 18, 2013 at 9:13 AM, Rex Dieter rdie...@math.unl.edu wrote:
 Neal Becker wrote:

 How do others solve this problem

 package your software as rpms too, so such dependencies get tracked.

 -- Rex

 --
 devel mailing list
 devel@lists.fedoraproject.org
 https://admin.fedoraproject.org/mailman/listinfo/devel
 Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct



-- 
 martin.langh...@gmail.com
 -  ask interesting questions
 - don't get distracted with shiny stuff  - working code first
 ~ http://docs.moodle.org/en/User:Martin_Langhoff
-- 
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: mechanism to retain system library versions

[Martin Langhoff]

Ah! http://dev.laptop.org/git/packages/

cheers,



m

On Wed, Dec 18, 2013 at 9:48 AM, Neal Becker ndbeck...@gmail.com wrote:
 Hey thanks!  But did you forget to include a link to the git repos?

 Martin Langhoff wrote:

 Neal,

 look like you've found the one thing fedora devel has consensus on ;-)

 Here is a series of git repos that show how I was maintaining some
 rpms outside of the fedora infra, but using fedpkg (which I recommend)
 -- more specifically mockbuild.

 These repos are public, but you can do the same in private git repos.

 Given a bit of familiarity with spec files and git, this should be easy.

 cheers,



 m


 On Wed, Dec 18, 2013 at 9:13 AM, Rex Dieter rdie...@math.unl.edu wrote:
 Neal Becker wrote:

 How do others solve this problem

 package your software as rpms too, so such dependencies get tracked.

 -- Rex

 --
 devel mailing list
 devel@lists.fedoraproject.org
 https://admin.fedoraproject.org/mailman/listinfo/devel
 Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct





 --
 devel mailing list
 devel@lists.fedoraproject.org
 https://admin.fedoraproject.org/mailman/listinfo/devel
 Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct



-- 
 martin.langh...@gmail.com
 -  ask interesting questions
 - don't get distracted with shiny stuff  - working code first
 ~ http://docs.moodle.org/en/User:Martin_Langhoff
-- 
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: Multiple Loopback Interfaces

[Martin Langhoff]

On Thu, Aug 29, 2013 at 9:47 AM, Juan Orti Alcaine
juan.o...@miceliux.com wrote:
 In IPv4 you can get any IP in the 127.0.0.0/8 subnet for the lo interface.

And in current fedora, they are already assigned to localhost. You can
ping 127.0.0.22 if you want.

AIUI, you can bind to it freely, too.




m
-- 
 martin.langh...@gmail.com
 -  ask interesting questions
 - don't get distracted with shiny stuff  - working code first
 ~ http://docs.moodle.org/en/User:Martin_Langhoff
-- 
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: Fedora as an crowd founded project an additional funding source to our sponsor

[Martin Langhoff]

On Tue, Jul 23, 2013 at 9:50 PM, Jóhann B. Guðmundsson
johan...@gmail.com wrote:
 I gave the quick answer  through donations

Reading through this thread, it seems to me that you are wanting to
change something you don't understand.

While I am not a RH employee, I have been deeply involved in FOSS,
including Debian and Fedora, for many years.

The best I can suggest is: build that funding source, and get it to
grow to an important size _without_ messing with RH as a sponsor. The
cost of running Fedora is likely to be huge. Fundraising is incredibly
hard, and generally fails.

So I suggest you try fundraising under a name or org of your choosing
with like-minded folks. If you succeed you'll be able to fund Fedora
development, and it will evolve organically.

This is important. Grow it organically, show how it's done, doing it
and succeeding. Don't waste everyone's time trying to change how
Fedora runs today, because it _works_ and you just cannot tear down
something that works every time a random person claims to have a
better idea.

If the random person has a better idea, better be able to show how it
works to gain some standing.

 I as a donor donating $20 would like those to run to

$20? It's going to be a long road!



m
--
 martin.langh...@gmail.com
 -  ask interesting questions
 - don't get distracted with shiny stuff  - working code first
 ~ http://docs.moodle.org/en/User:Martin_Langhoff
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Fedora as an crowd founded project an additional funding source to our sponsor

[Martin Langhoff]

On Wed, Jul 24, 2013 at 2:08 PM, Jóhann B. Guðmundsson
johan...@gmail.com wrote:
 Agree that's one way of figuring out but ( share number of
 servers/cpu/storage )  honestly i would have thought the infrastructure team
 would already know this.

Well, luckily you never have to know everything before you start
helping. RH is doing a lot. What can *you* do, with like-minded folks?

My humble suggestion Pick a piece of the elephant and start chewing.
There will surely be pieces that are _complementary_ to what RH is
funding (or RH'ers are doing). Non-corporate developers who can't
travel to Flock for financial reasons as a quick example.

That will get you in motion without forcing a conflict that needn't happen.

Any sponsor/contributor joining a FOSS project helps the most when
they start doing stuff that isn't being done.



m
--
 martin.langh...@gmail.com
 -  ask interesting questions
 - don't get distracted with shiny stuff  - working code first
 ~ http://docs.moodle.org/en/User:Martin_Langhoff
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: F20 System Wide Change: No Default Sendmail

[Martin Langhoff]

On Tue, Jul 23, 2013 at 10:10 AM, Billy Crook billycr...@gmail.com wrote:
 Sendmail or otherwise, an MTA BELONGS in Default.

There is no consensus on that, at all. Very successful competitors to
Fedora have removed it, and their users are happy.



m
--
 martin.langh...@gmail.com
 -  ask interesting questions
 - don't get distracted with shiny stuff  - working code first
 ~ http://docs.moodle.org/en/User:Martin_Langhoff
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: RFC: Proposal for a more agile Fedora.next (draft of my Flock talk)

[Martin Langhoff]

On Mon, Jul 22, 2013 at 11:22 AM, Matthew Miller
mat...@fedoraproject.org wrote:
 This proposal is for a solid core which can be targeted by software stacks,
 which can be targeted by developers.

Oh, initially I understood you were aiming for a fast-moving, highly
integrated core, following systemd's lead.

Maybe I am projecting :-)

Is your goal to have _less_ movement at the core of the stack?

We do have a problem of missed opportunities at this time -- the
kernel moves fairly fast, and allows for new and powerful features. If
we have a small core userland that moves in sync with the kernel,
there is a lot to gain in performance and features.

systemd is an example of a project that has broken a bit with the
ossified core linux userland. In my view, we need more such changes;
carefully executed.

Yes, everyone carps about change, including me. But they still develop
for the winning platform, and the winning platform gets to be the
winning platform by evolving. As I see it, that's Fedora's tradeoff.

cheers,


m
--
 martin.langh...@gmail.com
 -  ask interesting questions
 - don't get distracted with shiny stuff  - working code first
 ~ http://docs.moodle.org/en/User:Martin_Langhoff
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: RFC: Proposal for a more agile Fedora.next (draft of my Flock talk)

[Martin Langhoff]

On Mon, Jul 22, 2013 at 11:18 AM, Miloslav Trmač m...@volny.cz wrote:
 On Mon, Jul 22, 2013 at 3:38 PM, Matthew Miller
 mat...@fedoraproject.org wrote:
 This is a draft of the proposal I'm presenting at Flock, An Architecture
 for a More Agile Fedora (http://sched.co/19ugKGM).
 (The more high-level comment.)

 This essentially explicitly gives up on the idea of Fedora or,
 implicitly, Linux as a platform^W/deployment target/ecosystem

Quite the opposite, I would say.

The BSDs show that you can maintain a highly integrated small core OS
with a tiny team. Android has shown it can be done on top of the Linux
kernel. The traditional Linux distros are comparatively flailing at it
-- throwing a ton more resources at it, badly coordinated.

If Fedora moves to a tightly integrated core, and does it in a way
that other distros follow, Linux could grow a small core that moves in
sync with the kernel and outpaces the competition. systemd is the
example here.

Couple of months ago I have written about this topic here
https://plus.google.com/u/0/104365545644317805353/posts/MgAeGR6Pb8p --
the way I read Matthew's proposal is that it follows the fast moving
core goals...

cheers,



m
--
 martin.langh...@gmail.com
 -  ask interesting questions
 - don't get distracted with shiny stuff  - working code first
 ~ http://docs.moodle.org/en/User:Martin_Langhoff
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: F20 System Wide Change: SSD cache

[Martin Langhoff]

On Mon, Jul 15, 2013 at 7:47 AM, Mihamina Rakotomandimby
miham...@rktmb.org wrote:
 One thing I would recommend would be to correctly detect SSD:
 ATM, I installed my Fedora over an SSD and it did not ajust the mount
 settings nor suggest an appropriate setting for the SSD.
 If we can at least detect SSD and suggest (just suggest) a setting it would
 be great.

you can set IO scheduler to noop for disks that are reported as not
rotational.

Example udev script at
https://github.com/satya164/fedorautils/blob/master/plugins/disk_io_scheduler.misc.sh

It might be a good idea to add this initscripts.

cheers,



m
--
 martin.langh...@gmail.com
 -  ask interesting questions
 - don't get distracted with shiny stuff  - working code first
 ~ http://docs.moodle.org/en/User:Martin_Langhoff
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: F20 System Wide Change: SSD cache

[Martin Langhoff]

On Mon, Jul 15, 2013 at 10:55 AM, Peter Robinson pbrobin...@gmail.com wrote:
 On Mon, Jul 15, 2013 at 3:42 PM, Martin Langhoff
 martin.langh...@gmail.com wrote:
 On Mon, Jul 15, 2013 at 7:47 AM, Mihamina Rakotomandimby
 miham...@rktmb.org wrote:
 One thing I would recommend would be to correctly detect SSD:
 ATM, I installed my Fedora over an SSD and it did not ajust the mount
 settings nor suggest an appropriate setting for the SSD.
 If we can at least detect SSD and suggest (just suggest) a setting it would
 be great.

 you can set IO scheduler to noop for disks that are reported as not
 rotational.

 Example udev script at
 https://github.com/satya164/fedorautils/blob/master/plugins/disk_io_scheduler.misc.sh

 It might be a good idea to add this initscripts.

 A tuned profile I believe is the recommended spot for this sort of
 thing these days.

Would you run tuned on a server?




m
--
 martin.langh...@gmail.com
 -  ask interesting questions
 - don't get distracted with shiny stuff  - working code first
 ~ http://docs.moodle.org/en/User:Martin_Langhoff
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: F20 System Wide Change: SSD cache

[Martin Langhoff]

Right. I am not familiar with it. OTOH, a noop scheduler is simple
enough and non-dynamic rule.

udev seems like a much better fit than a daemon.

But what do I know. I am never in the fashion :-)



m

On Mon, Jul 15, 2013 at 12:27 PM, Matthew Garrett mj...@srcf.ucam.org wrote:
 On Mon, Jul 15, 2013 at 12:21:57PM -0400, Martin Langhoff wrote:

 Would you run tuned on a server?

 It was written with that in mind.

 --
 Matthew Garrett | mj...@srcf.ucam.org
 --
 devel mailing list
 devel@lists.fedoraproject.org
 https://admin.fedoraproject.org/mailman/listinfo/devel



-- 
 martin.langh...@gmail.com
 -  ask interesting questions
 - don't get distracted with shiny stuff  - working code first
 ~ http://docs.moodle.org/en/User:Martin_Langhoff
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: F20 System Wide Change: No Default Syslog

[Martin Langhoff]

On Mon, Jul 15, 2013 at 2:01 PM, Lennart Poettering
mzerq...@0pointer.de wrote:
 (Just to mention this: we are neither the pioneer on the
 no-default-syslog feature nor on no-default-sendmail... A lot of other

As a cross-distro chap, I can attest to this. Specially with sendmail.

Everytime I spot sendmail in a Fedora/RHEL/CentOS box I wonder when
will it happen. Together with sudo-by-default (and root logins
disabled  discouraged by default).

Back to the topic, what happens when I boot from a LiveCD to diagnose
a borked machine? Some FAQs that come to mind that google doesn't
answer:

 - The easy part: I run journalctl -r /path/to/rootpart/ -- what if
/var/lib/ is a mountpoint? Can I point directly to the 'database'
file?

 - What guarantees of completeness/consistency  can we expect in
practice from the journal in a hard poweroff situation? What is the
price in terms of fsync() calls?

 - What if the database file is corrupt? On occasion, I have read
partially corrupted logfiles with less. Sure, there was a chunk of
crud in the middle, but I could read past it. While the un-corrupted
bits were far from reliable, they did provide helpful info.

This last item is my main worry. Perhaps working on prototype XOs,
trying to sort out kernel/driver issues is not a mainstream use
case...

cheers,


m
--
 martin.langh...@gmail.com
 -  ask interesting questions
 - don't get distracted with shiny stuff  - working code first
 ~ http://docs.moodle.org/en/User:Martin_Langhoff
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: F20 System Wide Change: No Default Syslog

[Martin Langhoff]

On Mon, Jul 15, 2013 at 2:45 PM, Lennart Poettering
mzerq...@0pointer.de wrote:
 You'd usually mount your journal files dir, then direct journalctl -D
 /path/to/the/journal/files/dir to it. It will then collect all files in
 that dir, interleave them and present them to you.

Thanks! And that -D would be to the dir normally under
/var/log/journal AIUI. My reference earlier to
/var/lib/systemd/catalog was wrong I believe.

=  - What guarantees of completeness/consistency  can we expect in
 practice from the journal in a hard poweroff situation? What is the
 price in terms of fsync() calls?

 We sync() all journal files to disk 5min after each write the latest

that's new and interesting. AIUI pre-journal, the default was to
sync() on every message for some logs (and overrriden with a hyphen
for some logs). Am I wrong?

Heading offtopic: Are there ways to control sync on a per-service
basis? Or to trigger a sync on things like authentication failures,
OOM shootouts, or kernel oopses?

IOWs, logging potentially catastophic event events is always without
guarantees, but when it works, it logs damn useful info.

(snipped lots of good info, thanks!)

 When the journal starts up and finds a journal file is not marked
 offline it will immediately rotate the file and start a new one, in
 order to make sure we never fiddle with files that have incomplete
 transactions in them.

OK. That's sane and failsafe.

 With the default settings, in the worst case you might lose 4:59s of
 logs, but even that is very unlikely.

The trick with this is... you usually have a short window between the
catastrophic event and the problem.

Sometimes the problem cripples the system irretrievably. Can't win in
that case. But there are plenty of in the middle cases where if logs
written out in time can help diagnose issues.

 Of course, things are different if some other form of corruption takes
 place, i.e. where the fs gets corrupted so badly due to some external
 condition that the middle of the journal files is bad. We do not provide
 any recovery tools for that case currently.

It's gonna happen at some point :-) Anyway, if the file-format is
append-only and indexes and such are rebuildable, then it's within
reach.

Still, not a happy prospect for the first admin to need it.

cheers,




m
--
 martin.langh...@gmail.com
 -  ask interesting questions
 - don't get distracted with shiny stuff  - working code first
 ~ http://docs.moodle.org/en/User:Martin_Langhoff
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: F20 System Wide Change: No Default Syslog

[Martin Langhoff]

On Mon, Jul 15, 2013 at 5:38 PM, Chris Adams li...@cmadams.net wrote:
 And, despite your statement to the contrary, journalctl (without -f)

Hey Chris!

You might be hitting a bug, have a surprising pager envvar or
something. My general experience is that it does page things. I don't
think there's a conspiracy against your pager.

cheers,



m
--
 martin.langh...@gmail.com
 -  ask interesting questions
 - don't get distracted with shiny stuff  - working code first
 ~ http://docs.moodle.org/en/User:Martin_Langhoff
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: F20 System Wide Change: No Default Syslog

[Martin Langhoff]

On Mon, Jul 15, 2013 at 8:26 PM, Chris Adams li...@cmadams.net wrote:
 It's a feature you don't get traditionally because syslog drops the
 priority information from the on-disk format.

 I'd expect that if somebody thought that was an important default, the
 log format would have been updated years ago when rsyslog became the
 default.

It's damn useful.

There are tradeoffs, but you have take in the good aspects.



m
--
 martin.langh...@gmail.com
 -  ask interesting questions
 - don't get distracted with shiny stuff  - working code first
 ~ http://docs.moodle.org/en/User:Martin_Langhoff
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Installing a very old Fedora (FC6) in a chroot?

[Martin Langhoff]

To test / bench / verify old behaviour of PHP4, I need to install FC6
in a chroot.

Mock doesn't seem to work, given a reasoanble config file pointing to
the archive repo. Are there any good / recommended alternatives? Or is
mock expected to work?

cheers,



m
--
 martin.langh...@gmail.com
 -  ask interesting questions
 - don't get distracted with shiny stuff  - working code first
 ~ http://docs.moodle.org/en/User:Martin_Langhoff
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Installing a very old Fedora (FC6) in a chroot?

[Martin Langhoff]

On Wed, Jun 12, 2013 at 8:54 AM, Remi Collet fed...@famillecollet.com wrote:
 Le 12/06/2013 14:44, Martin Langhoff a écrit :
 To test / bench / verify old behaviour of PHP4, I need to install FC6
 in a chroot.

 Perhaps http://3v4l.org/ could help you ?

It does for a quick check, thanks! I will take Dan's idea and use a VM
-- I'm so used to setting up chroots that I didn't think of that.
Silly.

thanks!,



m
--
 martin.langh...@gmail.com
 -  ask interesting questions
 - don't get distracted with shiny stuff  - working code first
 ~ http://docs.moodle.org/en/User:Martin_Langhoff
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Installing a very old Fedora (FC6) in a chroot?

[Martin Langhoff]

On Wed, Jun 12, 2013 at 9:06 AM, Paul Howarth p...@city-fan.org wrote:
 I have working local mock configs for F-6 and a variety of other ancient
 releases. In what way does yours not work?

Great to know it works! I was worried changes in yum/rpm meant it wouldn't.

 The main local changes I have are that I have:

 config_opts['chroot_setup_cmd'] = 'install buildsys-build'
 config_opts['useradd'] = '/usr/sbin/useradd -m -u %(uid)s -g %(gid)s -d
 %(home)s -n %(user)s'

That's probably what I was missing. I sorted a couple of initial
issues and got stuck at 'Could not find useradd in chroot'.

 where the buildsys-build package is in a local repo and can be found here:
 http://www.city-fan.org/ftp/contrib/buildsys/

Will try with that - thanks!



m
--
 martin.langh...@gmail.com
 -  ask interesting questions
 - don't get distracted with shiny stuff  - working code first
 ~ http://docs.moodle.org/en/User:Martin_Langhoff
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Installing a very old Fedora (FC6) in a chroot?

[Martin Langhoff]

On Wed, Jun 12, 2013 at 11:45 AM, Przemek Klosowski
przemek.klosow...@nist.gov wrote:
 My approach for non-standard versions is to pull the relevant source RPM and
 just build it in the existing/convenient environment.

That doesn't always work so well. Try building an old openldap src rpm
(say, 2.4.x) in a current Fedora/RHEL environment for fun.

Modern rpm has deprecated stuff, and barfs at your (builddepends), it
has gotten tighter wrt patch application (so patches that applied with
fuzz now barf), and dependencies have moved and mutated in various
ways.

enjoy :-)


m
--
 martin.langh...@gmail.com
 -  ask interesting questions
 - don't get distracted with shiny stuff  - working code first
 ~ http://docs.moodle.org/en/User:Martin_Langhoff
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Proposed F19 Feature: Dracut HostOnly

[Martin Langhoff]

On Tue, Jan 29, 2013 at 6:22 PM, Dennis Gilmore den...@ausil.us wrote:
 that are built at kernel build time? the issue with building it at
 build time was making sure we knew exactly what sourcs we needed to
 ship to match all the binaries in the initramfs. the initramfs's we
 build and ship as part of teh install tree we know exactly what sources
 because they match what is in the release tree rather than what was in
 the buildroot at build time.

That _is_ a missing piece of the dracut/initramfs toolchain: we need
something in dracut that scans what files have been included from the
buildhost, finds what rpm they belong to and writes down the NEVRA
into a file that goes _into_ the initramfs.

Right now, it is impossible to trace back the origin of an arbitrary
initramfs built by dracut. Unless you find the build host (and it
hasn't changed!).

At OLPC we've had a few incidents of where the hell did you build
this initramfs? and how can I respin this initramfs with only this
patch applied, no other changes whatsoever?.

cheers,


m
--
 martin.langh...@gmail.com
 mar...@laptop.org -- Software Architect - OLPC
 - ask interesting questions
 - don't get distracted with shiny stuff  - working code first
 - http://wiki.laptop.org/go/User:Martinlanghoff
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Anaconda is totally trashing the F18 schedule (was Re: f18: how to install into a LVM partitions (or RAID))

[Martin Langhoff]

On Thu, Nov 1, 2012 at 10:25 AM, Allan Day allanp...@gmail.com wrote:
 It's important to recognise the negative effects of delays to the release.

OLPC is downstream of F18, and planning to ship an OLPC OS version
13.1.0 first week of December 2012 (approx); which will be based on
F18.

We are not affected by Anaconda issues, as our OS is a pre-installed
image, but continued churn does hit us hard.

We control this somewhat by freezing our view of Fedora's repos. Most
of our packages are in Fedora (with exceptions like kernel and BIOS)
-- where we maintain/comaintain quite a few components (Sugar Desktop,
etc).

OLPC development team is watching closely any schedule changes affecting Fedora.

cheers,


m
-- 
 martin.langh...@gmail.com
 mar...@laptop.org -- Software Architect - OLPC
 - ask interesting questions
 - don't get distracted with shiny stuff  - working code first
 - http://wiki.laptop.org/go/User:Martinlanghoff
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Changing date and ntpdate utilities to accomodate systemd's change of rtc handling

[Martin Langhoff]

Changes stemming from the switch to systemd mean that if you set the
system clock with ntpdate or date and you are not running ntpd... your
changes are not recorded in the RTC, ever.

There are some good reasons for this change, but at this time only the
systemd side is done, leaving date, ntpdate, and possibly other
utilities that change the system time broken from the PoV of a
system administrator. As I understand this change, it involves more
parts than just systemd.

I am CC'ing the package maintainers of coreutils and ntpdate, I am
sure there are other tools that change system time and rely on
automagic sync-to-RTC. ntpdate seems to be trivially fixable, as
Miroslav has already pointed out.

Some background discussion at
https://bugzilla.redhat.com/show_bug.cgi?id=816752 --

cheers,


m
-- 
 martin.langh...@gmail.com
 mar...@laptop.org -- Software Architect - OLPC
 - ask interesting questions
 - don't get distracted with shiny stuff  - working code first
 - http://wiki.laptop.org/go/User:Martinlanghoff
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Announcing OLPC OS 12.1.0 for XO-1, XO-1.5 and XO-1.75

[Martin Langhoff]

On Fri, Aug 31, 2012 at 4:12 PM, Daniel Drake d...@laptop.org wrote:
 We're pleased to announce the release of OLPC OS 12.1.0 for XO-1,
 XO-1.5 and XO-1.75. Details of new features, known issues, and how to

Congrats to all the team! Good press coverage at
http://www.engadget.com/2012/09/02/olpc-delivers-big-os-update-with-text-to-speech-displaylink/

cheers,



m
-- 
 martin.langh...@gmail.com
 mar...@laptop.org -- Software Architect - OLPC
 - ask interesting questions
 - don't get distracted with shiny stuff  - working code first
 - http://wiki.laptop.org/go/User:Martinlanghoff
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

A preupgrade adventure - F16 to F17

[Martin Langhoff]

Just an informational anecdote. My main dev machine is a vanilla
Lenovo X220 laptop, running an up-to-date F16. At OLPC, we are damned
close to *shipping* a F17-based distro on our XO laptops, so I thought
it'd be good to update.

Worried about /usr move, I decided to DTRT: use preupgrade.

First, preupgrade completely hides grubby errors, and tells you
everthing's peachy. This cannot be a feature. I managed to hit a few
grubby errors, and without the debug output from preupgrade-cli
showing the grubby command it's running, I'd still be scratching my
head...

So grub configs were not being updated, for two reasons

 - My machine does not have /boot/grub/grub.cfg, it has grub.conf
instead, so I hit BZ#841976 . Unsure why these conffiles are changing
names, this was a fresh F16 install back when F16 was new.

 - Added the missing grub.cfg, grubby segfaults (BZ#841979). Ummpf!

 - The preupgrade wikipage helpfully provides instructions to edit
grub.conf by hand. Completely wrong instructions. You don't want the
/boot prefix there. You don't want savedefault. You probably want to
ensure you see the menu.

I am no expert on what params the preupgrade initrd _really_ needs,
but things did not move forward until I fixed it up and added the
params that preupgrade was giving to the failing grubby.

 - And there I hit BZ#813973 - preupgrade (anaconda) garbles the URL
so you only get 404s.

The adventure continues, but at thistime I am under the impression
that preupgrade gets far less testing and polish than yum upgrades.




m
-- 
 martin.langh...@gmail.com
 mar...@laptop.org -- Software Architect - OLPC
 - ask interesting questions
 - don't get distracted with shiny stuff  - working code first
 - http://wiki.laptop.org/go/User:Martinlanghoff
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: A preupgrade adventure - F16 to F17

[Martin Langhoff]

On Fri, Jul 20, 2012 at 6:55 PM, Adam Williamson awill...@redhat.com wrote:
 Um. I think you might be working from a completely false premise. If you
 did a fresh install of Fedora 16 you should have grub2. Not grub.

Hmmm. This laptop has had F14, but IIRC it got a wipe-and-reinstall
treatment. You may be right on that point...

 The
 way grubby works, if you have a grub2-based system it'll 'complain'
 about the lack of a grub1 config file sometimes, but this isn't a
 problem in itself and can be ignored; if something's going wrong, that
 isn't the reason why. The file that needs to be updated
 is /boot/grub2/grub.cfg (/etc/grub2.cfg is a symlink to it).

/boot/grub2 exists, but is empty.

So preupgrade / grubby don't work with grub, and should bail out if
grub is the bootloader? Should that be my bug report?

 Note that once you reach the point of bootloader configuration,
 preupgrade did its job long ago. You're now just using plain anaconda.

Preupgrade is driving, at least in the prep stage, so I'll file
those bugs against preupgrade. Up to preupgrade maintainers to know
more about who to blame ;-)

 However, due to a bit of an oversight, a preupgrade-based upgrade uses a

TBH, I think that BZ#813973 is a high value bug that affects all
small boot partition users, it should be fixed, or at least then
known workaround noted in the wikipage.

 I'm really a bit confused by exactly what bootloader you actually have

Plain grub. I apologize, this may be a F14-F16 box. Cannot check
right now, it is finally upgrading...

If old grub is no longer the cool thing, I'll try to replace it with
grub2 once my upgrade is complete.

cheers,



m
-- 
 martin.langh...@gmail.com
 mar...@laptop.org -- Software Architect - OLPC
 - ask interesting questions
 - don't get distracted with shiny stuff  - working code first
 - http://wiki.laptop.org/go/User:Martinlanghoff
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: A preupgrade adventure - F16 to F17

[Martin Langhoff]

On Fri, Jul 20, 2012 at 4:09 PM, Adam Williamson awill...@redhat.com wrote:
 On Fri, 2012-07-20 at 19:26 +, Martin Langhoff wrote:
 On Fri, Jul 20, 2012 at 6:55 PM, Adam Williamson awill...@redhat.com wrote:
  Um. I think you might be working from a completely false premise. If you
  did a fresh install of Fedora 16 you should have grub2. Not grub.

 Hmmm. This laptop has had F14, but IIRC it got a wipe-and-reinstall
 treatment. You may be right on that point...

Hmm, now I think it was a F14 install:

ls -lah /root/anaconda-ks.cfg
-rw---. 1 root root 837 Jun 13  2011 /root/anaconda-ks.cfg

Given the date, it could be F15, but I skipped it because OLPC ships
F14 and it was early stages of systemd transition. I prefer to pick my
battles :-)

(Kidding -- systemd is great on our XOs. )

 All preupgrade really does is download a bunch of packages and an
 anaconda image, set the packages up as a repository, write a kickstart

Thanks for the education! Happy to see it re-assigned to anaconda, or
grubby. Assigning it to preupgrade (in my pre-enlightened condition)
worked a charm.

Who calls grubby and ignores its ungraceful death? That needs bubble
up the call stack...

 In practice, yeah, just getting it onto grub2 - either before the
 preupgrade or after - is likely the simplest way out of your problem.

Upgrade completed without any more hiccups. Moving to grub2.



m
-- 
 martin.langh...@gmail.com
 mar...@laptop.org -- Software Architect - OLPC
 - ask interesting questions
 - don't get distracted with shiny stuff  - working code first
 - http://wiki.laptop.org/go/User:Martinlanghoff
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Licensing change: Audacious - GPLv3 -- BSD

[Martin Langhoff]

On Tue, Jul 10, 2012 at 3:33 PM, Nicolas Mailhot
nicolas.mail...@laposte.net wrote:
 Please consider that in the Oracle vs Google case, Oracle ended up with
 9-line copying (plus a few test files), and the judge decided that *as*
 *a* *matter* *of* *law* copyright infringement had occurred for those 9
 lines.

Yes. And also told Oracle that it was very limited what they could
claim as damage caused by the copyright infringement over those 9
lines.

Yes, those 9 lines belong to you my precious butterfly. No, they are
not significant and this is all a waste of time.




m
-- 
 martin.langh...@gmail.com
 mar...@laptop.org -- Software Architect - OLPC
 - ask interesting questions
 - don't get distracted with shiny stuff  - working code first
 - http://wiki.laptop.org/go/User:Martinlanghoff
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Licensing change: Audacious - GPLv3 -- BSD

[Martin Langhoff]

On Mon, Jul 9, 2012 at 2:17 PM, Gregory Maxwell gmaxw...@gmail.com wrote:
 That someone's name wasn't listed in the right places may _explain_ their
 non-inclusion in a copyright change discussion

That seems to be what is being stated.

 Perhaps his contributions were too insignificant to earn copyright
 coverage, or at least too insignificant to make blockading a licensing
 change

And that seems quite possible.

Seems sensible and civilized to not get too nitpicky, unless you are a
major contributor to a project.



m
-- 
 martin.langh...@gmail.com
 mar...@laptop.org -- Software Architect - OLPC
 - ask interesting questions
 - don't get distracted with shiny stuff  - working code first
 - http://wiki.laptop.org/go/User:Martinlanghoff
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Licensing change: Audacious - GPLv3 -- BSD

[Martin Langhoff]

On Mon, Jul 9, 2012 at 10:56 PM, Matthew Garrett mj...@srcf.ucam.org wrote:
 If
 you're not able to keep track of all your copyright holders then
 changing the license is something you should only do with the aid of
 good lawyers.

While the pendantics do have a pendantic point, in practice the mere
*cost* of demonstrating that you have standing should bring some
reasonableness to any potential proceedings. And judges, as
experienced lawyers, are often practical people -- claimants with
trivial patches should, and are very likely to, get a fairly short
hearing.

Mores and community practice matter. So I do what I consider to be
positive and socially-responsible: respect and follow the major
contributors' desires.

cheers,


m
-- 
 martin.langh...@gmail.com
 mar...@laptop.org -- Software Architect - OLPC
 - ask interesting questions
 - don't get distracted with shiny stuff  - working code first
 - http://wiki.laptop.org/go/User:Martinlanghoff
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Python i686 vs x86_64 -- for testing a python library

[Martin Langhoff]

I am diagnosing a bug/odditywith a python library that uses Pyrex and
other oddities. In the course of that, I have installed python.i686 on
my F16 x86_64 system, and I'm trying to run it and... no dice!

According to rpm, python.x86_64 and python.i686 both own
/usr/bin/python and /usr/bin/python2.7 . Those binaries are 64 bits.
Googling around, I cannot find any clue on how to run the 32 bit
binary.

Had optimistically assumed that I'd find python.i686 stashed somewhere
when I looked at rpm -ql python.686 ...

cheers,


m
-- 
 martin.langh...@gmail.com
 mar...@laptop.org -- Software Architect - OLPC
 - ask interesting questions
 - don't get distracted with shiny stuff  - working code first
 - http://wiki.laptop.org/go/User:Martinlanghoff
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Python i686 vs x86_64 -- for testing a python library

[Martin Langhoff]

On Tue, Mar 27, 2012 at 11:18 AM, Adam Jackson a...@redhat.com wrote:
 Welcome to rpm.  ELF files have a wacky concept called color, which means

Color me impressed. That's one thing I didn't know!

 Use a chroot or an i686 vm.  Or possibly just do rpmdev-extract on the i686
 version and run it directly.

I've been toying with a chroot via mock, but was awkward for a number
of reasons. I've used rpmdev-extract and installed just the binary as
/usr/bin/python2.6-i686

Saved my day -- thanks!



m
-- 
 martin.langh...@gmail.com
 mar...@laptop.org -- Software Architect - OLPC
 - ask interesting questions
 - don't get distracted with shiny stuff  - working code first
 - http://wiki.laptop.org/go/User:Martinlanghoff
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: ARM as a primary architecture

[Martin Langhoff]

On Fri, Mar 23, 2012 at 3:50 PM, Pete Zaitcev zait...@redhat.com wrote:
 Buy a trimslice and run it with iSCSI.

 This is not good enough for me to become involved with Fedora on ARM.
 Glad it works for you, but I need a real system, like a Netwinder.

Whatever floats your boat! ARM SoCs are available in every popular form factor.

This whole thread about desktops vs tablets vs laptops has been highly
entertaining... now I know what every developer personally favours and
hates, as well as many of their immediate families. This a matter
which has kept many of us awake for long nights.

It unfortunately shed no light on the ARM topic, because, well,
there's ARM SoCs in all those form factors.

cheers,



martin just kidding langhoff
-- 
 martin.langh...@gmail.com
 mar...@laptop.org -- Software Architect - OLPC
 - ask interesting questions
 - don't get distracted with shiny stuff  - working code first
 - http://wiki.laptop.org/go/User:Martinlanghoff
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: RFC: Primary architecture promotion requirements

[Martin Langhoff]

On Wed, Mar 21, 2012 at 6:07 AM, Jaroslav Reznik jrez...@redhat.com wrote:
 Maybe a distribution of PandaBoards/R-Pi for every FAS account holder could
 help, any sponsor? :D

OLPC is starting mass production of XO-1.75 units, based on an ARMv7
Marvell Armada 610. School kids in Uruguay and Nicaragua will start
their school year with them, using a F14 ARM build. Peter Robinson has
been instrumental in making this happen (and of course thanks to all
the ARM porters).

We have free units for Fedora developers that are interested -- we'll
ship them for free anywhere in the world. The numbers are limited (we
are a non-profit), apply for units here:

  http://wiki.laptop.org/go/Contributors_program#FAQ

Some additional discussion:
http://lists.fedoraproject.org/pipermail/arm/2011-July/001661.html

In the form, you can state that your project is porting Fedora to
ARMv7 ensuring it runs great on XO-1.75 :-) and mention what packages
you're working on, or if you are or intend to be part of the Fedora
ARM porters team, state so. We're on the fedora-arm mailing list,
we'll know you :-)

F17 upgrade is coming midyear, which will give these units a big kick
in the pants in terms of performance. After that, we are cooking some
bold sw+hw plans for the future. All based on ARM.

cheers,



m
-- 
 martin.langh...@gmail.com
 mar...@laptop.org -- Software Architect - OLPC
 - ask interesting questions
 - don't get distracted with shiny stuff  - working code first
 - http://wiki.laptop.org/go/User:Martinlanghoff
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: ARM as a primary architecture

[Martin Langhoff]

On Thu, Mar 22, 2012 at 7:01 AM, Andrew Haley a...@redhat.com wrote:
 Where is the hardware? Do you see signs of ARM boards coming in the
 near future (next 1 year or so) on which users can install operating
 systems of their choice?

 I wonder where you've been.  See Raspberry Pi and Trimslice for a
 couple of recent ones.

And kids in Uruguay and Nicaragua will soon start their school year
equipped with XO-1.75 units running an OS based on Fedora-14 ARM.

Battery life is wicked on these units.

cheers,



martin
-- 
 martin.langh...@gmail.com
 mar...@laptop.org -- Software Architect - OLPC
 - ask interesting questions
 - don't get distracted with shiny stuff  - working code first
 - http://wiki.laptop.org/go/User:Martinlanghoff
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: ARM as a primary architecture

[Martin Langhoff]

On Thu, Mar 22, 2012 at 2:20 PM, drago01 drag...@gmail.com wrote:
 Which is exactly what I am trying to say as soon as you want to create
 content you want a real device. (keyboard!  interface)

Folks! In this mailing list I'd expect people to know: an arch is an
arch is an arch.

Some ARM CPUs will control your fridge, others will be the core SoC in
your laptop, some others in your servers, others in a tablet or ebook
reader.

Form factor != arch.

XO-1.75 is a clamshell laptop, sporting an ARM cpu. 60K units shipping
just to Uy - 
http://blog.laptop.org/2012/03/16/uruguay-is-first-country-to-get-xo-1-75/
- F14-ARM.




m
-- 
 martin.langh...@gmail.com
 mar...@laptop.org -- Software Architect - OLPC
 - ask interesting questions
 - don't get distracted with shiny stuff  - working code first
 - http://wiki.laptop.org/go/User:Martinlanghoff
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Debuginfo package for Python-2.7 on F14 mismatched or (l)user error?

[Martin Langhoff]

Hi Jan,

that's enormously useful -- thanks! I'll make sure we fix our kernel
options so this isn't an issue in the future.

And I'll patch my gdb so I can read the other stacktraces.

cheers -


m

On Sat, Mar 17, 2012 at 4:56 AM, Jan Kratochvil
jan.kratoch...@redhat.com wrote:
 On Fri, 16 Mar 2012 20:46:16 +0100, Martin Langhoff wrote:
 Argh, that could be. But our kernel is a custom built rpm,

 You have a bug for Fedora there, in the core file by readelf -l:
 Program Headers:
  Type           Offset   VirtAddr   PhysAddr   FileSiz MemSiz  Flg Align
 [...]
  LOAD          0x1933000 0xa7703000 0x 0x0 0x174000 R E 0x1000
                                                ^^^
 There is normally 0x1000 on x86* Fedora kernels due to:
 $ cat /proc/self/coredump_filter
 0033

 /usr/share/doc/kernel-doc-*/Documentation/filesystems/proc.txt
  - (bit 4) ELF header pages in file-backed private memory areas (it is
            effective only if the bit 2 is cleared)

 This way build-id for the executable and shared libraries is dumped in the
 core file but it is missing in this OLPC kernel.  Fedora GDB has not yet
 upstreamed patch for build-id which did not expect such core files.

 Going to push a fix for F-15+ but F-14 is EOLed, you can either use FSF GDB or
 patch Fedora GDB by this patch or use F-15+ GDB etc.

 That backtrace of core.522 FYI is at:
        http://people.redhat.com/jkratoch/sandisk.bt


 Thanks,
 Jan

 --- gdb-7.2/gdb/solib-svr4.c.orig       2012-03-17 09:39:54.874090162 +0100
 +++ gdb-7.2/gdb/solib-svr4.c    2012-03-17 09:42:12.561810807 +0100
 @@ -1202,14 +1202,30 @@ svr4_current_sos (void)
            }
          else
            {
 -             struct build_id *build_id;
 +             struct build_id *build_id = NULL;

              strncpy (new-so_original_name, buffer, SO_NAME_MAX_PATH_SIZE - 
 1);
              new-so_original_name[SO_NAME_MAX_PATH_SIZE - 1] = '\0';
              /* May get overwritten below.  */
              strcpy (new-so_name, new-so_original_name);

 -             build_id = build_id_addr_get (LM_DYNAMIC_FROM_LINK_MAP (new));
 +             /* In the case the main executable was found according to its
 +                build-id (from a core file) prevent loading a different build
 +                of a library with accidentally the same SO_NAME.
 +
 +                It suppresses bogus backtraces (and prints ?? there 
 instead)
 +                if the on-disk files no longer match the running program
 +                version.
 +
 +                If the main executable was not loaded according to its
 +                build-id do not do any build-id checking of the libraries.
 +                There may be missing build-ids dumped in the core file and we
 +                would map all the libraries to the only existing file loaded
 +                that time - the executable.  */
 +
 +             if (symfile_objfile != NULL
 +                  (symfile_objfile-flags  OBJF_BUILD_ID_CORE_LOADED) != 
 0)
 +               build_id = build_id_addr_get (LM_DYNAMIC_FROM_LINK_MAP (new));
              if (build_id != NULL)
                {
                  char *name, *build_id_filename;
 @@ -1224,23 +1240,7 @@ svr4_current_sos (void)
                      xfree (name);
                    }
                  else
 -                   {
 -                     debug_print_missing (new-so_name, build_id_filename);
 -
 -                     /* In the case the main executable was found according 
 to
 -                        its build-id (from a core file) prevent loading
 -                        a different build of a library with accidentally the
 -                        same SO_NAME.
 -
 -                        It suppresses bogus backtraces (and prints ?? there
 -                        instead) if the on-disk files no longer match the
 -                        running program version.  */
 -
 -                     if (symfile_objfile != NULL
 -                          (symfile_objfile-flags
 -                              OBJF_BUILD_ID_CORE_LOADED) != 0)
 -                       new-so_name[0] = 0;
 -                   }
 +                   debug_print_missing (new-so_name, build_id_filename);

                  xfree (build_id_filename);
                  xfree (build_id);

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



-- 
 martin.langh...@gmail.com
 mar...@laptop.org -- Software Architect - OLPC
 - ask interesting questions
 - don't get distracted with shiny stuff  - working code first
 - http://wiki.laptop.org/go/User:Martinlanghoff
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Debuginfo package for Python-2.7 on F14 mismatched or (l)user error?

[Martin Langhoff]

On Fri, Mar 16, 2012 at 1:57 AM, Jan Kratochvil
jan.kratoch...@redhat.com wrote:
 And both machines pass rpm -Va just fine. So the binaries should, um,
 be the same.
 +
 It is a core from yesterday,

 There can be difference one of the machines has the files prelink-ed while the
 other one does not.  prelink runs nightly (/etc/cron.daily/prelink).  But it

Thanks!

Prelink is not involved -- I doublechecked. In OLPC builds, we
currently don't prelink due to http://dev.laptop.org/ticket/10898 , we
just don't install prelink and don't run it during OS image creation.
Even back then when we did, we disabled the cronjob :-)

 should be already fixed in your GDB version gdb-7.2-52.fc14,

You got that one right :-)

 If it helps please contact me off-list, with your disk image.  It assumes the
 system generating the core file was not prelinked.

Uploading at
http://dev.laptop.org/~martin/os5rw-brokenimg/Sandisk_1200908562DEN.img

Bear in mind - that'll contain 2 partitions. The 2nd partition is /
but our initrd mounts it, and then chroots into a subdirectory. So
when you mount it, you'll want too look into /versions/run/5/

(WTF is this? Root FS snapshots via hardlinked trees. Until we have
btrfs running on these puppies, it's the best update fail-proof
mechanism we have.)

 That missing file:
 Missing separate debuginfo for
 Try: yum --disablerepo='*' --enablerepo='*-debuginfo' install 
 /usr/lib/debug/.build-id/63/420e48a2edbae61166c708ebd2ff1a5aed1054

 is probably for kernel vDSO (as its name is empty), therefore kernel rpm.

Argh, that could be. But our kernel is a custom built rpm, and we
don't build -debuginfo. Here, have a fistful of my freshly-torn-out
hair.

Now, at the time of this segfault, the dmesg reports a segfault in
python2.7, inside calls to glib... (1) why are we then in the kernel
and (2) why isn't gdb telling us anything about the python/glib part
of the callstack?

still confused -



martin
PS: On a different investigation track we think there may be some
subtle/odd disk corruption that _passes_ rpm -Va and our own
olpc-contents-verify, yet strikes at runtime. Could a subtly corrupt
binary (ie: vmlinuz) lead here?
-- 
 martin.langh...@gmail.com
 mar...@laptop.org -- Software Architect - OLPC
 - ask interesting questions
 - don't get distracted with shiny stuff  - working code first
 - http://wiki.laptop.org/go/User:Martinlanghoff
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel