Re: [gentoo-dev] Changing order of default virtual/udev provider

[M. J. Everitt]

On 15/02/16 05:28, Mike Frysinger wrote:
> On 15 Feb 2016 02:31, M. J. Everitt wrote:
>> I think people are confusing the fact that there IS no separate
>> 'udev'
> 
> i'm fully aware of this fact and have been since it happened. i
> don't think it changes my point. -mike
> 
It wasn't necessarily aimed at you .. just clarifying the point that
for others the point may not have completely sunk in :)

Re: [gentoo-dev] Changing order of default virtual/udev provider

[Mike Frysinger]

On 15 Feb 2016 02:31, M. J. Everitt wrote:
> I think people are confusing the fact that there IS no separate 'udev'

i'm fully aware of this fact and have been since it happened.
i don't think it changes my point.
-mike


signature.asc
Description: Digital signature

Re: [gentoo-dev] Uncoordinated changes

[Daniel Campbell]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On 02/14/2016 10:53 AM, Patrick Lauer wrote:
> On 02/14/2016 07:44 PM, Andreas K. Hüttel wrote:
>> On Sunday 14 February 2016 13:18:30 Rich Freeman wrote:
>>> Feel free to peruse the various list discussions and council
>>> logs. Most of what you're bringing up has come up before.
>> Thanks rich0, you seem to be reading my mind.
>> 
>> This is turning into a severe case of "I didn't bother to speak
>> up earlier or volunteer to improve something, and now I'm unhappy
>> with what was decided and implemented."
>> 
> Silly me for assuming that changes to metadata would not affect
> me. Or that tools would be adapted to the changes.
> 
> Or that the changes would make sense.
> 
> I don't have time to follow every little change, so it's quite
> annoying to reverse-engineer this change that apparently is a
> compromise that no one actually wanted, and hasn't really been
> finished yet. Sigh.
> 
To be fair, if you're working on a piece of software that depends on
parsing metadata from ebuild directories, it's reasonable to assume
that one would want to keep tabs on metadata.xml or any other topic
dealing with the problem space.

A simple, "My project depends on metadata.xml and I use it in X way;
will I be affected?" may have added to the discussion.

As it stands, I believe we're moving to maintainer types. So selecting
via `type="project"` should be able to fetch the project that an
ebuild belongs to. We (i.e. Gentoo) are in the middle of deciding
whether to keep going with DTD or switch to another method (from what
I gather, to support this very case), so since you actually depend on
these files, why not educate yourself on the conversation and see if
you can contribute? It does nobody any good to sit and sulk while the
world changes around you.

- -- 
Daniel Campbell - Gentoo Developer
OpenPGP Key: 0x1EA055D6 @ hkp://keys.gnupg.net
fpr: AE03 9064 AE00 053C 270C  1DE4 6F7A 9091 1EA0 55D6
-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQIcBAEBCAAGBQJWwUTMAAoJEAEkDpRQOeFwIFsP/1AZH4QcJp0hW7gv4CmO55wd
yzuuwW4iDzswX8cUfmkJdkar/OVapUo0I0xuh/7dniUF9Yoj9vuN1m7f4z9VTQeh
YrzbxKe/YVt8wO+2e2YxohIsybQTycG/0yKdcJN9NjNreo04fA80WUu9NYXEavk5
frfGqVaThhPXjIqQRJAq9V0UraqjU/SNy9xQAHMUtjnW5q4svPs3QTRP93+hqYg6
7Kzr8ssRGhq1N8A9lnZrkXfVkBmHOQ/Pol1d/ci+xRryYerVDlM7pGFW2mEdbtp2
jobryJMUjoUtdp8bxWgt+55X9fu4STPtyvq27n/ac4dXl2hs039iDLIdgyioR+id
X7pa6qmqeDVVT4vKNaFXa6PLF6K/OgNyp5l8M8Yctv9TJ0ppOX4WJ9bosivyAtBX
93w5Gu7G8arkZaJfpZDwf551Zn7qNaeR+ipArfy+kzn81zWogrrvBFPJ4JYP9qdL
iFEPVSH14seh7mRZOKhMzzMvfLAarQF5paZmwqCceCzEzIauMlGVT0xDEjansAUK
qewS2pWJ8yELL2kohq8yuP/3/qplgW2gVUK58b5+PpdOB/i5fdNVX5FwaNg3TBt/
4LALTeNdtgFDXL/5y8YdJu+yn6QlBEgxP2uo8me8CPFexsZRe8XRHO15WNnAhFIL
48rujyhN02LbnsD+0LV1
=onzY
-END PGP SIGNATURE-

Re: [gentoo-dev] Changing order of default virtual/udev provider

[M. J. Everitt]

On 15/02/16 02:16, Mike Frysinger wrote:
> On 14 Feb 2016 15:56, Anthony G. Basile wrote:
>> On 2/14/16 3:47 PM, Mike Frysinger wrote:
>>> On 14 Feb 2016 15:42, Anthony G. Basile wrote:
 On 2/14/16 3:23 PM, Mike Frysinger wrote:
> eudev: no one of any relevance outside of Gentoo runs it.
 that's not true, nor is it the central criticism, imo.
>>> can you list the projects that utilize eudev ?  the repo doesn't
>>> that i can see.  it is the central criticism imo when correct
>>> interaction with other projects is key.  people rely on rules being
>>> parsed & run correctly, as well as information provided by udev
>>> matching what they are running/testing everyday.
>> until patrick brought up the list of distros, i was only aware of
>> alpine which is a musl based distro.  then puppy and slack came
>> forward.  they build their entire system using eudev as the libudev
>> provider.  if there were issues, they would bring forward bug reports
>> like any other project.
>>
>> so when you say "people rely on rules being parsed ..." i don't know
>> why those user bases are dismissed.
> i'm not dismissing them per-se.  i'm being practical here: i think you
> can agree that the combined developer base of alpine/puppy/slack(ware?)
> is significantly smaller as compared to the distros using udev.
> -mike
by "udev" do you mean systemd (as they are losely one-and-the-same) or
the unsupported udev-severed-from-systemd ...
Of course there is no comparison between Anthony's work on eudev and the
systemd 'crowd' it's just a non-question.

I think people are confusing the fact that there IS no separate 'udev'
.. it is the work of a gentoo maintainer to make it work without
systemd. To this end, does it really matter that OpenRC users are
reliant on a gentoo developer applying heavy patching of 'upstream'
udev-for-systemd .. or another gentoo developer working on an
alternative that's roughly API-compatible. The discussion is how you
jump the inevitable shark, and perhaps by switching the default and
having a bit of time ahead to deal with issues, is surely better than
facing a large breakage ahead, when there remains an option to switch
back to the current udev if there are problems with eudev. It also gives
Anthony a chance to have a greater user-base to test and evaluate eudev
so that improvements can be made in a timely fashion before
udev-without-systemd becomes unavailable (for whatever set of reasons).

Re: [gentoo-dev] Changing order of default virtual/udev provider

[Mike Frysinger]

On 14 Feb 2016 15:56, Anthony G. Basile wrote:
> On 2/14/16 3:47 PM, Mike Frysinger wrote:
> > On 14 Feb 2016 15:42, Anthony G. Basile wrote:
> >> On 2/14/16 3:23 PM, Mike Frysinger wrote:
> >>> eudev: no one of any relevance outside of Gentoo runs it.
> >> 
> >> that's not true, nor is it the central criticism, imo.
> > 
> > can you list the projects that utilize eudev ?  the repo doesn't
> > that i can see.  it is the central criticism imo when correct
> > interaction with other projects is key.  people rely on rules being
> > parsed & run correctly, as well as information provided by udev
> > matching what they are running/testing everyday.
> 
> until patrick brought up the list of distros, i was only aware of
> alpine which is a musl based distro.  then puppy and slack came
> forward.  they build their entire system using eudev as the libudev
> provider.  if there were issues, they would bring forward bug reports
> like any other project.
> 
> so when you say "people rely on rules being parsed ..." i don't know
> why those user bases are dismissed.

i'm not dismissing them per-se.  i'm being practical here: i think you
can agree that the combined developer base of alpine/puppy/slack(ware?)
is significantly smaller as compared to the distros using udev.
-mike


signature.asc
Description: Digital signature

Re: [gentoo-dev] Changing order of default virtual/udev provider

[William Hubbs]

On Sun, Feb 14, 2016 at 03:50:38PM -0500, Mike Frysinger wrote:
> On 14 Feb 2016 15:47, Anthony G. Basile wrote:
> > On 2/14/16 3:34 PM, Mike Frysinger wrote:
> > > the bring up of the daemon itself is not nearly as important as the
> > > runtime interaction of people using libudev or rules being executed.
> > 
> > correct and i've been careful with libudev.
> > 
> > anyhow, can we divert this away from udev/eudev.  mike what do you
> > recommend as the future of openrc once systemd-udev can no longer be
> > extracted.
> 
> if/when systemd-udev can't be extract anymore, then sys-fs/udev is dead,
> and this whole thread is fairly moot.
> -mike

+1.

And, as for right now, udev-229 is in the tree, so udev can still be
extracted and run standalone from systemd.

William



signature.asc
Description: Digital signature

Re: [gentoo-dev] Changing order of default virtual/udev provider

[Alex McWhirter]

Why does any discussion revolving around systemd always turn out like this?

For the record, I'm an OpenRC user and intend on keeping it that way for
as long as i can. In that case i need udev to keep things working the
way i want them to. So in the case that the systemd team makes udev
inseparable from systemd, I will then consider using eudev or something
else. The point here is that i will change udev "if and when" that happens.

If that change occurs it's not like all OpenRC users are going to have
dead boxes. We will still have older versions of udev in the tree for
quite a while as we figure out the best approach. The best approach may
very well be to make systemd the default over OpenRC. I'm perfectly fine
with that as long as i can still opt to choose OpenRC / "whateverdev" at
install time.

Now eudev looks good to me and will probably work fine for my use case,
but that may not apply to everyone. In fact, the case may be that the
majority of users are using systemd. If the majority of users use
systemd and udev is pulled out from under our feet then maybe we should
go full on systemd. However, maybe the majority of users are not using
systemd and in that case maybe eudev would be a better option. There may
even be other solutions. Of course, there are other things we will need
to consider as well, but not until we have to make those decisions in
response to an upstream change.

The point is that udev works now, and it probably will for a while
longer. There's no point in changing something that not only works, but
works well. When it does break we can then figure out the rest of the
details. It could be a completely different situation tomorrow compared
to what it is today. Again, i don't really care as long as i can choose
the system i want should i want something different than the default.

This discussion shouldn't be about systemd fanboys forcing systemd down
others throats and conversely it shouldn't be about non-systemd bigots
forcing something else down their throats either. It should be about
which default best reflects the needs of the community should udev be no
longer accessible as a stand alone thing. It's almost a pointless
discussion right now considering people are arguing over trivial
preferences / ideologies and the fact that the situation may be very
different when it actually becomes a problem.

In short...

If it isn't broke, don't fix it.

[gentoo-dev] Automated Package Removal and Addition Tracker, for the week ending 2016-02-14 23:59 UTC

[Robin H. Johnson]

The attached list notes all of the packages that were added or removed
from the tree, for the week ending 2016-02-14 23:59 UTC.

Removals:
app-office/passepartout  20160214-13:04 pacho  4e3a102
dev-ada/gtkada   20160214-13:04 pacho  4e3a102
dev-db/drizzle   20160214-13:04 pacho  4e3a102
dev-java/gjdoc   20160213-13:59 chewi  aab7410
dev-perl/SpeedyCGI   20160214-13:04 pacho  4e3a102
dev-php/pecl-drizzle 20160214-13:04 pacho  4e3a102
dev-python/pyltxml   20160214-13:04 pacho  4e3a102
dev-python/pysyck20160209-09:00 kensington 5bbef50
kde-base/contactthemeeditor  20151230-10:16 kensington ce9e8e3
media-libs/opengtl   20160212-15:36 kensington 19d47b6
media-sound/gnomoradio   20160214-13:04 pacho  4e3a102
media-sound/shoutcast-search 20160209-09:03 kensington 6ba7c3d
media-video/bombono-dvd  20160214-13:04 pacho  4e3a102
net-misc/gip 20160214-13:04 pacho  4e3a102
net-p2p/linuxdcpp20160214-13:04 pacho  4e3a102

Additions:
app-crypt/simp_le20160208-18:53 zx2c4  ddc2b61
dev-db/rqlite20160213-10:42 zmedicobcc6053
dev-go/bee   20160210-08:03 zmedicof5aecc5
dev-go/go-tour   20160211-09:22 zmedicocc180f4
dev-java/commons-imaging 20160213-12:35 chewi  a38ac86
dev-java/jchart2d20160212-20:55 chewi  db23be2
dev-java/jide-oss20160212-20:34 chewi  484e933
dev-java/swingx-beaninfo 20160212-21:01 chewi  477fdf6
dev-java/swingx-ws   20160212-21:24 chewi  572751e
dev-ml/gsl-ocaml 20160214-22:04 soap   5acbfd1
dev-ml/ocaml-redis   20160209-10:51 aballier   8585458
dev-ml/pa_sexp_conv  20160208-13:25 aballier   ef39661
dev-ml/uuidm 20160209-10:41 aballier   a1014e8
dev-python/croniter  20160211-05:05 zmedico841635b
dev-python/libiscsi-python   20160211-13:27 jlec   866139c
dev-python/python-scsi   20160211-13:13 jlec   b613b17
dev-python/tinydb20160208-10:37 jlec   0d227ad
dev-ruby/gh  20160209-18:18 ottxor fb1ed54
mate-base/mate-applets-meta  20160209-02:03 NP-Hardass 81bcdc7
mate-extra/mate-indicator-applet 20160209-01:36 NP-Hardass a8290be
mate-extra/mate-netbook  20160209-01:37 NP-Hardass 87fe393
media-libs/embree20160212-22:43 xarthisius 31291e4
media-libs/libmatemixer  20160209-01:50 NP-Hardass 3359a44
sys-apps/fix-gnustack20160213-22:57 blueness   3ddffc2
sys-apps/gcp 20160214-16:06 soap   dae4710
sys-apps/man2html20160213-06:41 vapier 7f54846
x11-plugins/pidgin-skypeweb  20160211-03:32 NP-Hardass e3d757b

--
Robin Hugh Johnson
Gentoo Linux Developer
E-Mail : robb...@gentoo.org
GnuPG FP   : 11AC BA4F 4778 E3F6 E4ED  F38E B27B 944E 3488 4E85
Removed Packages:
app-office/passepartout,removed,pacho,20160214-13:04,4e3a102
dev-ada/gtkada,removed,pacho,20160214-13:04,4e3a102
dev-db/drizzle,removed,pacho,20160214-13:04,4e3a102
dev-perl/SpeedyCGI,removed,pacho,20160214-13:04,4e3a102
dev-php/pecl-drizzle,removed,pacho,20160214-13:04,4e3a102
dev-python/pyltxml,removed,pacho,20160214-13:04,4e3a102
media-sound/gnomoradio,removed,pacho,20160214-13:04,4e3a102
media-video/bombono-dvd,removed,pacho,20160214-13:04,4e3a102
net-misc/gip,removed,pacho,20160214-13:04,4e3a102
net-p2p/linuxdcpp,removed,pacho,20160214-13:04,4e3a102
dev-java/gjdoc,removed,chewi,20160213-13:59,aab7410
media-libs/opengtl,removed,kensington,20160212-15:36,19d47b6
kde-base/contactthemeeditor,removed,kensington,20151230-10:16,ce9e8e3
media-sound/shoutcast-search,removed,kensington,20160209-09:03,6ba7c3d
dev-python/pysyck,removed,kensington,20160209-09:00,5bbef50
Added Packages:
dev-ml/gsl-ocaml,added,soap,20160214-22:04,5acbfd1
sys-apps/gcp,added,soap,20160214-16:06,dae4710
sys-apps/fix-gnustack,added,blueness,20160213-22:57,3ddffc2
dev-ruby/gh,added,ottxor,20160209-18:18,fb1ed54
dev-java/commons-imaging,added,chewi,20160213-12:35,a38ac86
dev-java/swingx-ws,added,chewi,20160212-21:24,572751e
dev-java/swingx-beaninfo,added,chewi,20160212-21:01,477fdf6
dev-java/jchart2d,added,chewi,20160212-20:55,db23be2
dev-java/jide-oss,added,chewi,20160212-20:34,484e933
dev-db/rqlite,added,zmedico,20160213-10:42,bcc6053
sys-apps/man2html,added,vapier,20160213-06:41,7f54846
media-libs/embree,added,xarthisius,20160212-22:43,31291e4
dev-python/python-scsi,added,jlec,20160211-13:13,b613b17
dev-python/libiscsi-python,added,jlec,20160211-13:27,866139c
dev-go/go-tour,added,zmedico,20160211-09:22,cc180f4
dev-python/croniter,added,zmedico,20160211-05:05,841635b
x11-plugins/pidgin-skypeweb,added,NP-Hardass,20160211-03:32,e3d757b
dev-go/bee,added,zmedico,20160210-08

Re: [gentoo-dev] Changing order of default virtual/udev provider

[Rich Freeman]

On Sun, Feb 14, 2016 at 2:41 PM, Brian Dolbec  wrote:
> On Sun, 14 Feb 2016 11:00:30 -0500
> Rich Freeman  wrote:
>
>> On Sun, Feb 14, 2016 at 10:14 AM, Patrick Lauer 
>> wrote:
>> > If, for any reason, eudev should be abandoned - we can just change
>> > the virtual back. One-line change.
>>
>> Which is precisely the corresponding argument for not switching the
>> default to eudev in the first place.
>>
>
> OH, my, this is looking more like you are being paid by systemd peeps...

Nobody has ever paid me to do anything involving open-source software,
systemd or otherwise.

My point is just that there is no need to change today, because:
1.  udev works just fine today
2.  If udev doesn't work just fine in the future, we can just change
the virtual.  One-line change.

That's all.  I'm not saying that there might not be other reasons to
change the virtual.

I'm just saying that the possibility that udev might break in the
future isn't any more a reason to change the virtual than the
possibility that eudev might be abandoned in the future.

I love it when Patrick violently agrees with me.  :)

-- 
Rich

Re: [gentoo-dev] Changing order of default virtual/udev provider

[Mike Frysinger]

On 14 Feb 2016 11:41, Brian Dolbec wrote:
> On Sun, 14 Feb 2016 11:00:30 -0500 Rich Freeman wrote:
> > On Sun, Feb 14, 2016 at 10:14 AM, Patrick Lauer wrote:
> > > If, for any reason, eudev should be abandoned - we can just change
> > > the virtual back. One-line change.  
> > 
> > Which is precisely the corresponding argument for not switching the
> > default to eudev in the first place.
> 
> OH, my, this is looking more like you are being paid by systemd peeps...

honestly ?  cut the crap man.

> You are just refusing to acknowledge these simple facts.
> 
> systemd.:  irrelevant to this decision
> 
> standalone systemd-udev.:  Vehemently unsupported, support for its
>capability to exist is planned to be punted
>in the future.
> 
> eudev...:  fully functional, actively developed,
>and fully supported, mature project, been
>around for years.

udev: it's the default in every major distro that everyone tests and
develops against.

eudev: no one of any relevance outside of Gentoo runs it.

> Oh and here is one final piece that should blow your reason away
> 
> https://github.com/gentoo/eudev   <== NOTICE that it's upstream is
> within our gentoo domain.

irrelevant.  any Gentoo dev can create any repo in that namespace even
when they shouldn't.  the fact that eudev is in there does *not* mean
the whole Gentoo project has signed on to it, or that it's some sort
of "banner" project.  it means at least one Gentoo dev decided to do X
and our project system doesn't require project consensus before X can
proceed.  do not conflate these.
-mike


signature.asc
Description: Digital signature

Re: [gentoo-dev] Changing order of default virtual/udev provider

[Patrick Lauer]

On 02/14/2016 09:17 PM, Rich Freeman wrote:
> On Sun, Feb 14, 2016 at 2:41 PM, Brian Dolbec  wrote:
>> On Sun, 14 Feb 2016 11:00:30 -0500
>> Rich Freeman  wrote:
>>
>>> On Sun, Feb 14, 2016 at 10:14 AM, Patrick Lauer 
>>> wrote:
 If, for any reason, eudev should be abandoned - we can just change
 the virtual back. One-line change.
>>> Which is precisely the corresponding argument for not switching the
>>> default to eudev in the first place.
>>>
>> OH, my, this is looking more like you are being paid by systemd peeps...
> Nobody has ever paid me to do anything involving open-source software,
> systemd or otherwise.
>
> My point is just that there is no need to change today, because:
> 1.  udev works just fine today
> 2.  If udev doesn't work just fine in the future, we can just change
> the virtual.  One-line change.
>
> That's all.  I'm not saying that there might not be other reasons to
> change the virtual.
>
> I'm just saying that the possibility that udev might break in the
> future isn't any more a reason to change the virtual than the
> possibility that eudev might be abandoned in the future.
>
> I love it when Patrick violently agrees with me.  :)
>
Eh yes. If we can avoid a problem we better wait until there is visible
breakage so we can heroically run around like headless chickens and
people see that we do something.

You're definitely of the "Fireman Sysadmin" type that doesn't want to do
preventative maintenance :)


Why are you so insistent on controlling something that doesn't even
affect you?  I mean ... the only difference for you would be that from a
default stage3 you do "emerge -C eudev" instead of "emerge -C udev" and
then you're on your way.

As far as users are concerned, most don't care and won't see a
difference, and those that care seem to be strongly in support of having
eudev ...

Re: [gentoo-dev] Changing order of default virtual/udev provider

[Alon Bar-Lev]

On 14 February 2016 at 22:23, Mike Frysinger  wrote:
> udev: it's the default in every major distro that everyone tests and
> develops against.
>
> eudev: no one of any relevance outside of Gentoo runs it.

I honestly don't understand this argument that pops over and over.

No "major distro" using udev without systemd, so OpenRC people are
already using udev in unsupported setup.

Better to use a tool that is tested and supported in this setup.

Or maybe I do not understand and mission is for us to switch to systemd?

Systemd users/developers should not mind what the default is as they
are forced to use one variant anyway, these users/developers should
not force their opinion upon others.

Thanks,
Alon

Re: [gentoo-dev] Changing order of default virtual/udev provider

[Patrick Lauer]

On 02/14/2016 09:23 PM, Mike Frysinger wrote:
> On 14 Feb 2016 11:41, Brian Dolbec wrote:
>> On Sun, 14 Feb 2016 11:00:30 -0500 Rich Freeman wrote:
>>> On Sun, Feb 14, 2016 at 10:14 AM, Patrick Lauer wrote:
 If, for any reason, eudev should be abandoned - we can just change
 the virtual back. One-line change.  
>>> Which is precisely the corresponding argument for not switching the
>>> default to eudev in the first place.
>> OH, my, this is looking more like you are being paid by systemd peeps...
> honestly ?  cut the crap man.
>
>> You are just refusing to acknowledge these simple facts.
>>
>> systemd.:  irrelevant to this decision
>>
>> standalone systemd-udev.:  Vehemently unsupported, support for its
>>capability to exist is planned to be punted
>>in the future.
>>
>> eudev...:  fully functional, actively developed,
>>and fully supported, mature project, been
>>around for years.
> udev: it's the default in every major distro that everyone tests and
> develops against.
Not the standalone config we're using, so if you remove all
systemd-using distros which are irrelevant to this discussion you end up
with gentoo, and ~15 distros that use eudev. And of course other
irrelevant weirdos that use mdev, vdev etc.
>
> eudev: no one of any relevance outside of Gentoo runs it.
No one runs udev either. So that's a non-argument


So given the context of this discussion, and your ignorant contribution
... maybe you should cut the crap, man. Being a bit more polite wouldn't
be wrong either.

Re: [gentoo-dev] Changing order of default virtual/udev provider

[Rich Freeman]

On Sun, Feb 14, 2016 at 3:31 PM, Alon Bar-Lev  wrote:
> Systemd users/developers should not mind what the default is as they
> are forced to use one variant anyway, these users/developers should
> not force their opinion upon others.

Posting an opinion on a list isn't forcing anything on anybody.
You're more than welcome to disagree with it.

-- 
Rich

Re: [gentoo-dev] Changing order of default virtual/udev provider

[Mike Frysinger]

On 14 Feb 2016 22:31, Alon Bar-Lev wrote:
> On 14 February 2016 at 22:23, Mike Frysinger wrote:
> > udev: it's the default in every major distro that everyone tests and
> > develops against.
> >
> > eudev: no one of any relevance outside of Gentoo runs it.
> 
> I honestly don't understand this argument that pops over and over.
> 
> No "major distro" using udev without systemd, so OpenRC people are
> already using udev in unsupported setup.
> 
> Better to use a tool that is tested and supported in this setup.

the bring up of the daemon itself is not nearly as important as the
runtime interaction of people using libudev or rules being executed.
-mike


signature.asc
Description: Digital signature

Re: [gentoo-dev] Changing order of default virtual/udev provider

[Mike Frysinger]

On 14 Feb 2016 21:31, Patrick Lauer wrote:
> On 02/14/2016 09:23 PM, Mike Frysinger wrote:
> > On 14 Feb 2016 11:41, Brian Dolbec wrote:
> >> On Sun, 14 Feb 2016 11:00:30 -0500 Rich Freeman wrote:
> >>> On Sun, Feb 14, 2016 at 10:14 AM, Patrick Lauer wrote:
>  If, for any reason, eudev should be abandoned - we can just change
>  the virtual back. One-line change.  
> >>> Which is precisely the corresponding argument for not switching the
> >>> default to eudev in the first place.
> >> OH, my, this is looking more like you are being paid by systemd peeps...
> > honestly ?  cut the crap man.
> >
> >> You are just refusing to acknowledge these simple facts.
> >>
> >> systemd.:  irrelevant to this decision
> >>
> >> standalone systemd-udev.:  Vehemently unsupported, support for its
> >>capability to exist is planned to be punted
> >>in the future.
> >>
> >> eudev...:  fully functional, actively developed,
> >>and fully supported, mature project, been
> >>around for years.
> > udev: it's the default in every major distro that everyone tests and
> > develops against.
> Not the standalone config we're using, so if you remove all
> systemd-using distros which are irrelevant to this discussion you end up
> with gentoo, and ~15 distros that use eudev. And of course other
> irrelevant weirdos that use mdev, vdev etc.
> >
> > eudev: no one of any relevance outside of Gentoo runs it.
> No one runs udev either. So that's a non-argument
> 
> 
> So given the context of this discussion, and your ignorant contribution
> ... maybe you should cut the crap, man. Being a bit more polite wouldn't
> be wrong either.

yes, your e-mails in this thread are a shining example of how to
collobarate and make cogent arguments.  attacking people directly
is definitely how you "win".  it's too bad i haven't actually done
any of what you're attempting to slander me with here.
-mike


signature.asc
Description: Digital signature

Re: [gentoo-dev] Changing order of default virtual/udev provider

[Anthony G. Basile]

On 2/14/16 3:23 PM, Mike Frysinger wrote:
> 
> eudev: no one of any relevance outside of Gentoo runs it.
> 

that's not true, nor is it the central criticism, imo.  the problem is
the project only has one pair of eyes.  people have said all sorts of
stuff but really, there's only one relevant issue.  its a project
limited to my skill and my time.

-- 
Anthony G. Basile, Ph.D.
Gentoo Linux Developer [Hardened]
E-Mail: bluen...@gentoo.org
GnuPG FP  : 1FED FAD9 D82C 52A5 3BAB  DC79 9384 FA6E F52D 4BBA
GnuPG ID  : F52D4BBA

Re: [gentoo-dev] Changing order of default virtual/udev provider

[Anthony G. Basile]

On 2/14/16 3:34 PM, Mike Frysinger wrote:

> 
> the bring up of the daemon itself is not nearly as important as the
> runtime interaction of people using libudev or rules being executed.
> -mike
> 

correct and i've been careful with libudev.

anyhow, can we divert this away from udev/eudev.  mike what do you
recommend as the future of openrc once systemd-udev can no longer be
extracted.

-- 
Anthony G. Basile, Ph.D.
Gentoo Linux Developer [Hardened]
E-Mail: bluen...@gentoo.org
GnuPG FP  : 1FED FAD9 D82C 52A5 3BAB  DC79 9384 FA6E F52D 4BBA
GnuPG ID  : F52D4BBA

Re: [gentoo-dev] Changing order of default virtual/udev provider

[Mike Frysinger]

On 14 Feb 2016 15:42, Anthony G. Basile wrote:
> On 2/14/16 3:23 PM, Mike Frysinger wrote:
> > eudev: no one of any relevance outside of Gentoo runs it.
> 
> that's not true, nor is it the central criticism, imo.

can you list the projects that utilize eudev ?  the repo doesn't that
i can see.  it is the central criticism imo when correct interaction
with other projects is key.  people rely on rules being parsed & run
correctly, as well as information provided by udev matching what they
are running/testing everyday.
-mike


signature.asc
Description: Digital signature

Re: [gentoo-dev] Changing order of default virtual/udev provider

[Mike Frysinger]

On 14 Feb 2016 15:47, Anthony G. Basile wrote:
> On 2/14/16 3:34 PM, Mike Frysinger wrote:
> > the bring up of the daemon itself is not nearly as important as the
> > runtime interaction of people using libudev or rules being executed.
> 
> correct and i've been careful with libudev.
> 
> anyhow, can we divert this away from udev/eudev.  mike what do you
> recommend as the future of openrc once systemd-udev can no longer be
> extracted.

if/when systemd-udev can't be extract anymore, then sys-fs/udev is dead,
and this whole thread is fairly moot.
-mike


signature.asc
Description: Digital signature

Re: [gentoo-dev] Changing order of default virtual/udev provider

[Anthony G. Basile]

On 2/14/16 3:47 PM, Mike Frysinger wrote:
> On 14 Feb 2016 15:42, Anthony G. Basile wrote:
>> On 2/14/16 3:23 PM, Mike Frysinger wrote:
>>> eudev: no one of any relevance outside of Gentoo runs it.
>> 
>> that's not true, nor is it the central criticism, imo.
> 
> can you list the projects that utilize eudev ?  the repo doesn't
> that i can see.  it is the central criticism imo when correct
> interaction with other projects is key.  people rely on rules being
> parsed & run correctly, as well as information provided by udev
> matching what they are running/testing everyday. -mike
> 

until patrick brought up the list of distros, i was only aware of
alpine which is a musl based distro.  then puppy and slack came
forward.  they build their entire system using eudev as the libudev
provider.  if there were issues, they would bring forward bug reports
like any other project.

so when you say "people rely on rules being parsed ..." i don't know
why those user bases are dismissed.

-- 
Anthony G. Basile, Ph.D.
Gentoo Linux Developer [Hardened]
E-Mail: bluen...@gentoo.org
GnuPG FP  : 1FED FAD9 D82C 52A5 3BAB  DC79 9384 FA6E F52D 4BBA
GnuPG ID  : F52D4BBA

Re: [gentoo-dev] libressl: proposing a new project and calling for help

[Devan Franchini]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On 02/14/2016 04:38 PM, Anthony G. Basile wrote:
> Hi everyone,
>
> We discussed the state of libressl today in the council.  Proceeding
> forward with that work, I'm going to propose a new project and getting
> together a team.  Much of the work has already done by hasufell and what
> remain is just following through on his plan.
>
> Before I put up a project page, can I ask who is interested in this?
>
I volunteer as tribute!
-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQEcBAEBCAAGBQJWwPURAAoJEEAKp6Qwg9Y3thAH/3QbBSxoeIVGrcNfhUHRtXRV
m46J+fRmk226BcByeE6iSSZpIgLzrCT44Pnre5tctVBzjXXi+Ym7LhstYOVMAu/B
npNCGSg4ytac9FkP9lxFH89GIRDh7q4M80ovy/O1slo0V/2JFR4NVZclbCn+hXye
/bfFlAA5lr4NQ9ZWeKCQ4VjS2KhBpP3pYFnvMOh30It9CB8A7P4SBaOToGsC1+2a
GoNEeJk963CXrlqs4WXnX4IEqqPj17cnqUfe2tbyS0DHE5VjfCYOz8ytGuGHAG+5
5PK8Qtwmo9peh7WHMvFb1iUX5XMQeSKttt4peaNwkmfVxZjMSixjfTmFn7bpqAk=
=kA4T
-END PGP SIGNATURE-

Re: [gentoo-dev] Uncoordinated changes

[Ciaran McCreesh]

On Sun, 14 Feb 2016 19:53:56 +0100
Patrick Lauer  wrote:
> I don't have time to follow every little change, so it's quite
> annoying to reverse-engineer this change that apparently is a
> compromise that no one actually wanted, and hasn't really been
> finished yet. Sigh.

Why reverse engineer it? It's all documented.

-- 
Ciaran McCreesh

Re: [gentoo-dev] Uncoordinated changes

[Patrick Lauer]

On 02/12/2016 11:02 PM, Michał Górny wrote:
> On Fri, 12 Feb 2016 10:07:10 +0100
> Patrick Lauer  wrote:
>
>> On 02/12/2016 08:48 AM, Michał Górny wrote:
>>> Dear Ignorant Patrick,  
>> Hello human! Your politeness module seems to have crashed.
> Please do not expect politeness when you insult someone.
>
>
>> So now I know that in the future I will
>>
>> (1) categorically deny any change requests coming from you and
>> (2) block/revert any changes that I don't like or understand.
>>
>> Nothing personal, just basic sanity.
> If you want to leave Gentoo, please do that without unnecessary drama.
> That will reduce the load on ComRel and/or QA resulting from your CoC
> violations and childish behavior, and reduce the discouragement you're
> causing to other developers.
>
Now now. That's a severe case of projection, and I should take offense
at it. But that's silly, so please stop being such a drama queen and
maybe don't start yet another project this month until you've finised at
least one of the half dozen unfinished things that you started.


If you feel insulted because I pointed out some breakage caused by you
(which now you claimed you did against your wishes, which is a strange
thing for voluntary work) then I suggest you hide breakage (oh wait,
"differently behaving") better so I don't notice it. And if I
discouraged you from working on more things then that's good too ...

Re: [gentoo-dev] Uncoordinated changes

[Andreas K. Hüttel]

On Sunday 14 February 2016 13:18:30 Rich Freeman wrote:
> 
> Feel free to peruse the various list discussions and council logs.
> Most of what you're bringing up has come up before.

Thanks rich0, you seem to be reading my mind.

This is turning into a severe case of "I didn't bother to speak up earlier or 
volunteer to improve something, and now I'm unhappy with what was decided and 
implemented."

-- 
Andreas K. Hüttel
Gentoo Linux developer (council, perl, libreoffice)
dilfri...@gentoo.org
http://www.akhuettel.de/

Re: [gentoo-dev] Uncoordinated changes

[Patrick Lauer]

On 02/14/2016 07:44 PM, Andreas K. Hüttel wrote:
> On Sunday 14 February 2016 13:18:30 Rich Freeman wrote:
>> Feel free to peruse the various list discussions and council logs.
>> Most of what you're bringing up has come up before.
> Thanks rich0, you seem to be reading my mind.
>
> This is turning into a severe case of "I didn't bother to speak up earlier or 
> volunteer to improve something, and now I'm unhappy with what was decided and 
> implemented."
>
Silly me for assuming that changes to metadata would not affect me.
Or that tools would be adapted to the changes.

Or that the changes would make sense.

I don't have time to follow every little change, so it's quite annoying
to reverse-engineer this change that apparently is a compromise that no
one actually wanted, and hasn't really been finished yet. Sigh.

Re: [gentoo-dev] Changing order of default virtual/udev provider

[Brian Dolbec]

On Sun, 14 Feb 2016 11:00:30 -0500
Rich Freeman  wrote:

> On Sun, Feb 14, 2016 at 10:14 AM, Patrick Lauer 
> wrote:
> > If, for any reason, eudev should be abandoned - we can just change
> > the virtual back. One-line change.  
> 
> Which is precisely the corresponding argument for not switching the
> default to eudev in the first place.
> 

OH, my, this is looking more like you are being paid by systemd peeps...

THIS IS OPEN SOURCE, there is not a single project out there that might
not become abandoned at some point in the future.

Even Microsoft may eventually abandon their crappy windows, Apple
abandon it's current platform, (wait they did that once or twice
already)...


You are just refusing to acknowledge these simple facts.

systemd.:  irrelevant to this decision

standalone systemd-udev.:  Vehemently unsupported, support for its
   capability to exist is planned to be punted
   in the future.

eudev...:  fully functional, actively developed,
   and fully supported, mature project, been
   around for years.


Oh and here is one final piece that should blow your reason away

https://github.com/gentoo/eudev   <== NOTICE that it's upstream is
within our gentoo domain.  That means if Anthony (god forbid) were to
be hit by that proverbial bus.  The project can be easily assigned new
developers.  Not to mention the fact that with 14 downstream
distributions using it as their udev implementation.  That I am sure
some downstream developers would step up and continue its development
too.

Need I go on to list examples of other current projects that have
continued when their main developer had gone for one reason or another.

HINT: they are current Gentoo defaults too.

So PLEASE show us you are capable of seeing and acknoledging the above
simple facts and give up these BS arguments.  This whole BS over a
simple decision is giving me flashbacks of jury duty I did.  But at
least then, it was over something serious.  It was a murder trial.
This is about a simple virtual and the default order of its
providers!!! 

-- 
Brian Dolbec 

Re: [gentoo-dev] Changing order of default virtual/udev provider

[Patrick Lauer]

On 02/09/2016 01:17 PM, Rich Freeman wrote:
> On Tue, Feb 9, 2016 at 3:43 AM, Kent Fredric  wrote:
>
>> And a lot of Gentoo is surprisingly simple: Like our use of bash
>> scripts for recipies to build things, like using rsync to deploy/relay
>> not just those recipies, but security notices and  news items, which
>> are themselves reasonably simple formats.
> Well, one thing about Gentoo that certainly isn't simple is our init.d 
> scripts.
>
> Compare this:
> http://pastebin.com/sSDtpF4t
More stable link:
https://gitweb.gentoo.org/proj/apache.git/tree/2.4/init/apache2.initd
>
> With this:
> http://pastebin.com/Lfn8r7qP
More stable link:
https://gitweb.gentoo.org/repo/gentoo.git/tree/www-servers/apache/files/apache2.2.service
> Systemd does the job in 10% of the code (and half of it is a comment),
> and doesn't implement its own service polling and killer script during
> shutdown independently for every service (not that every init.d script
> even does this - most of them will just leave orphans behind, and
> systemd will catch orphans that even the lengthy init.d script for
> apache misses).
>
Right, that's a bad comparison.

The equivalent OpenRC init script is:

```
#!/sbin/runscript
command="/usr/sbin/apache2"
command_args="${APACHE2_OPTS}"
description_reload="A graceful restart advises the children to exit
after the current request and reloads the configuration."

stop() {
$command $APACHE2_OPTS -k graceful-stop
}
reload() {
$command $APACHE2_OPTS -k graceful
}
```
So that's almost exactly the same (modulo braces and newlines). There's
no equivalent for PrivateTmp, and we ignore the extra data in
/etc/tmpfiles.d (for creating runtime dirs). Which is bad, but that's
another rant ;)

Just that the current initscript does a lot more, and ... uhm ... why is
the systemd unit sourcing /etc/conf.d/apache2 ?
(Oh, and dependencies, but those just slow down startup )

So if you compile the equivalent naive init script there's not much
difference, and the initial argument falls on its face and disappears.

I'm getting tired of having this argument :)

Re: [gentoo-dev] Uncoordinated changes

[Rich Freeman]

On Sun, Feb 14, 2016 at 6:37 AM, Patrick Lauer  wrote:
>
> The new schema collapses herd (err, project!) into maintainers (err,
> sustainers ... staff ... linchpin?)
> And maintainer is defined as:
> 
>
> Which means that only email is mandatory. So instead of search by name
> you are now required to search by email.
> And it leads to inconsistent (partial) duplication: Some metadata.xml
> entries carry Name, some Description, and some are Email only.
>
> For example for gentoolkit this means that instead of search by name now
> it needs to be search by email, and the previous search by name
> functionality requires herds.xml, err, projects.xml to figure out the
> name of a project. Which might not match the one in metadata.xml!

This is all correct and intentional.  I actually didn't care for
having the name in metadata.xml for exactly that reason, but the
intent of having it there (and optional) was to make the file more
human-readable.  Tools that intend to search by name should obtain the
name from the authoritative source (ultimately the Wiki, but mirrored
in projects.xml).

If we made metadata.xml the source of project names then your search
would break anytime a maintainer spells a name differently.  If we
imagine building a bunch of tools to prevent this from happening, we
might as well build a bunch of tools that just references the name
from projects.xml (which is what they'd have to do to prevent the
breakage anyway).

Feel free to peruse the various list discussions and council logs.
Most of what you're bringing up has come up before.

-- 
Rich

Re: [gentoo-dev] Uncoordinated changes

[Kent Fredric]

On 15 February 2016 at 00:37, Patrick Lauer  wrote:
> Or JSON, or YAML, or whatever
> is trendy now.


I would love a JSON form. I tried doing my own stuff with XML and I
gave up in the complexity factory I found myself building around it :(

Just ... not YAML. The YAML spec is much less well defined and much
less "regular", and much less ubiquitous as a transport.

And if you standardize on JSON,  JSON is valid YAML 1.2, but not vice versa.

And so as long as you don't do any cute things like permit different
structures in the same slots like:

{ author => "f...@bar.com" }
{ author => { email => "f...@bar.com" , name => ... }}

You'll be fine, Because you get nice messes when code expects a value
to be a hash instead of a scalar and try to keep the data
self-consistent. Its just not worth the programming expense in every
single implementation just to provide a little sugar syntax.


-- 
Kent

KENTNL - https://metacpan.org/author/KENTNL

Re: [gentoo-dev] Uncoordinated changes

[Patrick Lauer]

On 02/14/2016 02:16 AM, Rich Freeman wrote:
> On Sat, Feb 13, 2016 at 7:58 PM, Raymond Jennings  wrote:
>> So what do you guys think of leaving behind empty stubs for compatibility
>> and then simply filing a tracking bug blocked by any packages that removing
>> herds broke?
> It isn't entirely clear that anything is actually broken at the
> moment, but if distributing an empty herds.xml file makes somebody's
> life easier I have no objections.  I don't think it would have
> alleviated Patrick's original concerns in this case.
>
Nope :)

But it would have made debugging easier.

Re: [gentoo-dev] Uncoordinated changes

[Michał Górny]

On Sun, 14 Feb 2016 12:37:33 +0100
Patrick Lauer  wrote:

> On 02/11/2016 09:15 PM, Patrick Lauer wrote:
> > Now instead of looking up [metadata.xml] -> (herd name) -> [herds.xml]  
> > -> email it goes backwards:  
> > [metadata.xml] -> (maintainer type=project) -> email -> [projects.xml]  
> > -> Project name  
> >
> > Since this involves XML and python's ElementTree library it's a
> > nontrivial change that also removes a few now useless helpers
> > (_get_herd_email has no reason to be, but we'd need a _get_herd_name
> > helper instead. Err, get_proj ... ah well, whatever name works)
> >
> > And all that just so (1) gentoolkit output works and (2) euscan updates
> > properly. Both of which I don't really care about much, but now that
> > I've invested ~4h into debugging and trying to fix it I'm a tiny bit
> > IRRITATED.
> >  
> So this turns out to be more fun than expected.
> 
> Having spent a little bit of time staring at XML, DTDs and wondering why
> we do things the most difficult way ...
> 
> Previously the herd tag was defined as:
> 
> 
> So we end up with, for example:
> kde
> 
> The new schema collapses herd (err, project!) into maintainers (err,
> sustainers ... staff ... linchpin?)
> And maintainer is defined as:
> 
> 
> Which means that only email is mandatory. So instead of search by name
> you are now required to search by email.

Congratulations! After the whole discussion, GLEP, explanatory blog
post and explanatory mails, you finally figured out how things work!

> And it leads to inconsistent (partial) duplication: Some metadata.xml
> entries carry Name, some Description, and some are Email only.
> 
> For example for gentoolkit this means that instead of search by name now
> it needs to be search by email, and the previous search by name
> functionality requires herds.xml, err, projects.xml to figure out the
> name of a project. Which might not match the one in metadata.xml!
> (And you may need to filter out maintainers-that-are-not-projects, and
> what about maintainers that are undefined? So much extra code complexity!)

Everything becomes complex if you try hard to make it sound complex.

Maintainer is a single entity, and it's identified by e-mail. So if you
want to group packages, you just group by e-mail. Simple as that. No
special magic needed. No extra files needed. The basic functionality
works without any special needs. You can also use it straight to
contact the maintainer or assign bugs.

If you want to split maintainers into people and projects, you've got
type="". Which is also in-place, with no extra files needed.

If you want pretty project names, then you can use projects.xml.
Or the name in metadata.xml. Both are fine by definition.

Now, the surprise: current people-maintainers could already have
different (or no) names in different metadata.xml files! You didn't
expect that, did you? In other words, that's not a new issue, neither
a major problem.

> And this is why I avoided the topic and hoped that the 'migration' would
> make sense:
> (1) Using XML is mildly insane. Neither machine- nor human-readable

Wrong. It works for machines well.

> (2) The DTD is even more insane, and few people have the patience to
> figure it out

And what do you need the DTD for? Furthermore, it's in process of being
replaced.

> (3) The recent changes to the DTD change the data model in subtle ways
> so that there's even *more* denormalization possible
> (4) The tooling is, due to XML, wonderfully horrible and requires things
> like XPATH to get the required data (because query by attribute is
> harder than query by tag)

Of course it does. Because no modern programming languages provide such
complex features as conditionals!

> There's fundamental questions that should be handled before doing more
> modifications - for example, should the data be more normalized (e.g.
> name only in projects.xml / maintainers.xml and only email in
> metadata.xml)? If we allow denormalization, do we have tools to check
> and autocorrect (e.g. a maintainer changing name)?
>
> Once we decide to abstract it away so that people should use tools and
> not mangle it manually (have you looked at herds.xml ?! omg ...) there's
> the question ... why XML? It's about the worst format for this job, INI
> format is sufficient and easier to parse. Or JSON, or YAML, or whatever
> is trendy now. Or do we autogenerate from templates?

What is the gain? Who is going to fix all the tools?

> Another funny thing: projects.xml is not in the same repository, so
> synchronizing changes gets more tricky. And the metadata.dtd is in yet
> another place. Wouldn't it make sense to have this organized in a less
> confusing way?

projects.xml is autogenerated from wiki. Yes, the place you refuse to
visit. Which means you'll never exist in projects.xml.

DTDs are not needed for anything, except for doing poor man's
correctness verification.

> You see where this is going - and why I didn't object loud enough to 

Re: [gentoo-dev] Changing order of default virtual/udev provider

[Patrick Lauer]

On 02/09/2016 10:03 AM, Kent Fredric wrote:
> On 9 February 2016 at 18:27, Anthony G. Basile  wrote:
>> all the vitriolic attacks i get about eudev come from the gentoo
>> community.  outside of this community i get praise.
>
> In case my  earlier messages stating a desire to exercise much caution
> gave the wrong impression, I just want to state for the record I think
> its awesome eudev exists, and I think its awesome other distro's are
> using it.
>
> Just when it comes to "Change the defaults", I want to be certain
> about the path we're setting ourselves up for on this very important
> component, because here, a change of defaults paves a broader path for
> eudev to be a potential leading competition to systemd.
If, for any reason, eudev should be abandoned - we can just change the
virtual back. One-line change.
>
> Because if we do that, I feel we must be so sure of ourselves that
> eudev can be a profitable choice for at least a moderately long term,
> even in the event we get no more support from the systemd codebase.
>
> Having it in tree and having users who know what they're doing being
> able to choose their own risk factors and say "yeah, eudev is the
> right choice for what I'm doing" is one thing.
>
> But stating implicitly that "Hey, this is the default", this needs to
> be the *best* recommendation we can make based on all the other
> factors and other defaults Gentoo uses.
Given the options of {systemd, systemd-udevd standalone, eudev} -
Those that choose systemd are not in this discussion.
Systemd-udevd standalone is unsupported, with upstream suggesting that
they want to remove support for it.
Leaves eudev as the only 'sane' option, since we even have an upstream.

And it's the 'mainstream' choice.

And it wins the popular vote:
https://forums.gentoo.org/viewtopic-t-1038696-postdays-0-postorder-asc-highlight-eudev-start-0.html

>
> Because new users *will* be inclined to pick the default, and
> *existing* users of the *current* default are likely to see the
> default change, and reason "well, the default has changed, so the new
> default is the new best thing", and will be inclined to switch.
Existing installs won't have a visible change. Since a provider of
virtual/udev is installed nothing changes, even if we shuffle the
virtual providers around.
>
> And the worst thing we could have is a combination of bad defaults
> that leads new users to have a poor first experience because they used
> all the default recommendations, and their system made magic smoke
> instead of booting.
>
> In short, to change *this* default, it seems pertinent that we *know*
> that the change we're making *is* better and a more reliable long-term
> choice than the *current* default, and if there is *any reasonable
> doubt*, we should delay changing until that reasonable doubt is
> expunged.
>
Since eudev is a drop-in replacement that uses a good part of the
original udev codebase - if you notice any deviation it's either a bug
(which we should fix) or udev misbehaves (e.g. persistent network
naming, which is a wonderful way to make people with more than zero
network cards angry)

And again: It would only affect what gets installed if you do "emerge -C
udev eudev; emerge virtual/udev"
(and, as a positive side-effect, changes the udev implementation of
stage3, which again only affects the default on *new* installs)

I don't see any serious doubts, apart from "we're deviating from
upstream" - but that's exactly what I want to fix! Yes, we deviate
*now*, we should not do that. And there's reasonable doubt that we can
keep sys-fs/udev going.


I like it when people violently agree with me :)

Re: [gentoo-dev] Changing order of default virtual/udev provider

[Patrick Lauer]

On 02/14/2016 05:00 PM, Rich Freeman wrote:
> On Sun, Feb 14, 2016 at 10:14 AM, Patrick Lauer  wrote:
>> If, for any reason, eudev should be abandoned - we can just change the
>> virtual back. One-line change.
> Which is precisely the corresponding argument for not switching the
> default to eudev in the first place.
>
That no sense :)

Since we're, right now, already using an unsupported version ...
Can't get worse.

And since you argued for mainstream earlier you'd have to agree that
eudev is the mainstream solution and Gentoo is lagging behind the others ...

Re: [gentoo-dev] Uncoordinated changes

[Rich Freeman]

On Sun, Feb 14, 2016 at 10:30 AM, Patrick Lauer  wrote:
> On 02/14/2016 02:16 AM, Rich Freeman wrote:
>> On Sat, Feb 13, 2016 at 7:58 PM, Raymond Jennings  wrote:
>>> So what do you guys think of leaving behind empty stubs for compatibility
>>> and then simply filing a tracking bug blocked by any packages that removing
>>> herds broke?
>> It isn't entirely clear that anything is actually broken at the
>> moment, but if distributing an empty herds.xml file makes somebody's
>> life easier I have no objections.  I don't think it would have
>> alleviated Patrick's original concerns in this case.
>>
> Nope :)
>
> But it would have made debugging easier.
>

Well, if debugging is your only concern, on the system you're going to
debug from:
touch herds.xml

-- 
Rich

Re: [gentoo-dev] Changing order of default virtual/udev provider

[Rich Freeman]

On Sun, Feb 14, 2016 at 10:14 AM, Patrick Lauer  wrote:
> If, for any reason, eudev should be abandoned - we can just change the
> virtual back. One-line change.

Which is precisely the corresponding argument for not switching the
default to eudev in the first place.

-- 
Rich

[gentoo-dev] herds.xml removal (was: Re: Uncoordinated changes)

[Ulrich Mueller]

> On Sat, 13 Feb 2016, Rich Freeman wrote:

> It isn't entirely clear that anything is actually broken at the
> moment, but if distributing an empty herds.xml file makes somebody's
> life easier I have no objections.

In fact, GLEP 67 implies that the herds.xml file is to be removed
altogether, which would be a cleaner solution than leaving a stub.
Citing the GLEP: "The Gentoo systems using e.g. CVS checkouts were
already missing the file, and therefore the tools needed to handle
that case gracefully."

Ulrich


pgpjcGBzteztZ.pgp
Description: PGP signature

Re: [gentoo-dev] Uncoordinated changes

[Patrick Lauer]

On 02/11/2016 09:15 PM, Patrick Lauer wrote:
> Now instead of looking up [metadata.xml] -> (herd name) -> [herds.xml]
> -> email it goes backwards:
> [metadata.xml] -> (maintainer type=project) -> email -> [projects.xml]
> -> Project name
>
> Since this involves XML and python's ElementTree library it's a
> nontrivial change that also removes a few now useless helpers
> (_get_herd_email has no reason to be, but we'd need a _get_herd_name
> helper instead. Err, get_proj ... ah well, whatever name works)
>
> And all that just so (1) gentoolkit output works and (2) euscan updates
> properly. Both of which I don't really care about much, but now that
> I've invested ~4h into debugging and trying to fix it I'm a tiny bit
> IRRITATED.
>
So this turns out to be more fun than expected.

Having spent a little bit of time staring at XML, DTDs and wondering why
we do things the most difficult way ...

Previously the herd tag was defined as:


So we end up with, for example:
kde

The new schema collapses herd (err, project!) into maintainers (err,
sustainers ... staff ... linchpin?)
And maintainer is defined as:


Which means that only email is mandatory. So instead of search by name
you are now required to search by email.
And it leads to inconsistent (partial) duplication: Some metadata.xml
entries carry Name, some Description, and some are Email only.

For example for gentoolkit this means that instead of search by name now
it needs to be search by email, and the previous search by name
functionality requires herds.xml, err, projects.xml to figure out the
name of a project. Which might not match the one in metadata.xml!
(And you may need to filter out maintainers-that-are-not-projects, and
what about maintainers that are undefined? So much extra code complexity!)

And this is why I avoided the topic and hoped that the 'migration' would
make sense:
(1) Using XML is mildly insane. Neither machine- nor human-readable
(2) The DTD is even more insane, and few people have the patience to
figure it out
(3) The recent changes to the DTD change the data model in subtle ways
so that there's even *more* denormalization possible
(4) The tooling is, due to XML, wonderfully horrible and requires things
like XPATH to get the required data (because query by attribute is
harder than query by tag)

There's fundamental questions that should be handled before doing more
modifications - for example, should the data be more normalized (e.g.
name only in projects.xml / maintainers.xml and only email in
metadata.xml)? If we allow denormalization, do we have tools to check
and autocorrect (e.g. a maintainer changing name)?

Once we decide to abstract it away so that people should use tools and
not mangle it manually (have you looked at herds.xml ?! omg ...) there's
the question ... why XML? It's about the worst format for this job, INI
format is sufficient and easier to parse. Or JSON, or YAML, or whatever
is trendy now. Or do we autogenerate from templates?

Another funny thing: projects.xml is not in the same repository, so
synchronizing changes gets more tricky. And the metadata.dtd is in yet
another place. Wouldn't it make sense to have this organized in a less
confusing way?

You see where this is going - and why I didn't object loud enough to the
changes: I want to not care about this whole cluster of topics and do
things that are more rewarding. But that choice got taken away when
things broke (oh, they didn't break, they Function Differently now) and
I had to spend some time investigating why things deviate.

Sigh.


Am I grumpy?