Re: [systemd-devel] 220 tarball erroneously ships keyboard-keys-from-name.gperf

2015-05-27 Thread Lennart Poettering
On Wed, 27.05.15 11:52, Martin Pitt (martin.p...@ubuntu.com) wrote:

 Lennart Poettering [2015-05-27 11:42 +0200]:
  Well, but let's not forget that a major part of the issues popping up
  actually were committed weeks ago.
 
 Actually, no. As I said, on May 11 most everything was working just
 fine, the udev regressions landed very late. The path_is_mount_point()
 regression landed much earlier, but is much less visible (and now
 there are tests cases with the patch I sent).

Sure, some of the udev breakage is more recent. But a good chunk of
the other stuff (gperf, EFI, path_is_mount_point()) is much older, and
some of it is easily visible...

 Agreed. The broken tarball issues are not visible when building from
 git (which is what I'm doing all the time). We didn't have that kind
 of issues with 219 or 218 (or at least only negligible ones), but 220
 taught us all that we need to test make dist builds more often.
 
 So we have two indepenent things to fix:
 
  * Regularly test make dist, as nobody does that  during regular
development.

Well, no.

I use make distcheck regularly during regular development, and
that's how I generate the final tarball.

However, make distcheck generates a tarball off the 220 git tree
just fine, if you had all the options enabled on a modern Fedora, like
I do.

Again, this is about testing options and combinations that are
not regularly covered by the core systemd developers. 

My release procedure involves not only doing make distcheck, but
also then building the result in Fedora's koji, which then also involves
another make check run, as part of the RPM build process, on all
architectures Fedora supports. Only after that I tag a new
release. 

Alternative: Stop shipping make dist tarballs altogether and just
tar the tagged git snapshot. Given the amount of patching that most
distros do, we pretty much all run autoreconf anyway (including
Fedora), so not having the pre-generated autoconfiscation and
pre-built manpages etc. in the tarball isn't actually that much of
a deal.

Well, while I sympathize with the idea, this is still not how most
current distros work...

Also, make dist worked fine as mentioned, hence altering this part
of the release process will not improve anything, but instead make
things even more sloppy...

  * Impose a release freeze period with announcing an impending
release, distros do a deep testing (this is a day's work for me, so
can't happen that often). During that time (which really shouldn't
be more than a few days) we really should avoid any commit which
isn't an important bug fix, especially not large refactorings or
new features.

How about this: please run automated tests if you have them in regular
intervals, always tracking git. And a few days before a release I'll
notify the mailing list.

I really don't want to drown development in deep freeze phases, that
are then alternated with crazy merge time phases. Instead, I'd much
rather increase the release frequency, keep a steady stream of changes,
and ask downstreams for more help with testing and keeping git
constantly in a releasable state.

Lennart

-- 
Lennart Poettering, Red Hat
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel


Re: [systemd-devel] 220 tarball erroneously ships keyboard-keys-from-name.gperf

2015-05-27 Thread Martin Pitt
Lennart Poettering [2015-05-27 11:42 +0200]:
 Well, but let's not forget that a major part of the issues popping up
 actually were committed weeks ago.

Actually, no. As I said, on May 11 most everything was working just
fine, the udev regressions landed very late. The path_is_mount_point()
regression landed much earlier, but is much less visible (and now
there are tests cases with the patch I sent).

 Things like the broken gperf generated bits or the missing EFI dirs
 were in git since a lng time.
 
 It would be great if downstream could help us with testing many of the
 build combinations, at any time of the cycle, not just when it comes
 to a release.

Agreed. The broken tarball issues are not visible when building from
git (which is what I'm doing all the time). We didn't have that kind
of issues with 219 or 218 (or at least only negligible ones), but 220
taught us all that we need to test make dist builds more often.

So we have two indepenent things to fix:

 * Regularly test make dist, as nobody does that  during regular
   development.

   Alternative: Stop shipping make dist tarballs altogether and just
   tar the tagged git snapshot. Given the amount of patching that most
   distros do, we pretty much all run autoreconf anyway (including
   Fedora), so not having the pre-generated autoconfiscation and
   pre-built manpages etc. in the tarball isn't actually that much of
   a deal.

 * Impose a release freeze period with announcing an impending
   release, distros do a deep testing (this is a day's work for me, so
   can't happen that often). During that time (which really shouldn't
   be more than a few days) we really should avoid any commit which
   isn't an important bug fix, especially not large refactorings or
   new features.

Thanks,

Martin

-- 
Martin Pitt| http://www.piware.de
Ubuntu Developer (www.ubuntu.com)  | Debian Developer  (www.debian.org)
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel


Re: [systemd-devel] 220 tarball erroneously ships keyboard-keys-from-name.gperf

2015-05-27 Thread Lennart Poettering
On Tue, 26.05.15 20:51, Dave Reisner (d...@falconindy.com) wrote:

 On Tue, May 26, 2015 at 04:17:07PM +0200, Lennart Poettering wrote:
  On Tue, 26.05.15 15:12, Dimitri John Ledkov (dimitri.j.led...@intel.com) 
  wrote:
  
   Or will there be a v220.1 release shortly with releasy fix-ups?
  
  Well, we don't do point releases in systemd. 
 
  In systemd git we already have now the change that makes sd-bus and
  sd-event public APIs, hence v221 is going to be more than just
  bugfixes. 
 
 Is git revert not an option? Does someone depend on this already, making
 a rollback impossible (and why would you allow that)? You say that
 versions are just a label, but a project which adopts semver would be
 able to create a branch in git and produce a dot release with backported
 bugfixes. Surely you're familiar with this concept -- your colleague
 Karel does this routinely with util-linux.

I have no idea what you are talking of. I don't know what semver is
supposed to be? Fedora knows no package by that name. A typo?

 The fact of the matter is, the last 2 releases of systemd have been
 brown bag releases. Neither 219 nor 220 are useable as the tarballs are
 provided. v220 doesn't even build in a large number of configurations.
 v218 wasn't quite as bad, but landed 18 patches in Arch's packaging
 before v219 was released. For the average Arch package, this is unheard
 of, let alone being a *necessity* in order to make software useable.

Well, they do work fine in the Fedora build, which is what I
test. It's a pretty comprehensive test. And the release also does work
fine on FEdora. How I know that, because I run the newest systemd
versions exclusively myself, and I do watch some bugzillas.

I can only encourage you to test git more frequently on Arch, and not
wait for the release to do this. 

As mentioned before, the gperf and EFI issues you are apparently
referring to have been around since a few weeks. They do not appear
with the config options we use upstream or the ones of Fedora. We
*rely* on downstream testing this, otherwise this will *never* work.

Most software does not have as many options we have. Apparently we
have issues we keeping all combinations of the options working. There
are two solutions to this problem:

a) more testing of the combinations of options used by downstream. For
   this we'd have to rely on downstream support though.

b) simply remove the options. i.e. remove configure switches, and be
   more aggressive with requiring current versions of libraries,
   kernel headers, kernels, and so on.

I am open for b), but I guess many people would certainly prefer us
not doing that.

If we'd follow b) then everybody would run things in the same
combination, and ew test this from upstream we can be sufficiently
sure that it will work for everybody else, too.

But for a) we'd need support from projects like Ubuntu or Arch: for
example, a Jenkins instance or so that builds systemd git continouesly
for those systems and boots them. 

We currently have Davi Strauss' Jenkins instance, and I am very
thankful for that, but this tests only one specific configuration of
things. If you want ArchLinux' configuration to be tested regularly,
then this means that ArchLinux would have to provide something in the
area, we can never do that from upstream.

  Also, next week I'll be travelling and I doubt I will be able to
  finish a new release by then. Maybe in the middle of June we can get
  out a new release.
 
 I'm sorry to hear this too. Please find someone else who's paid to work
 on systemd and teach them how to package releases. The current state of
 affairs absolutely sucks for downstreams. Currently, packaging systemd
 takes more of my time than all of my other packaging responsibilities
 combined.

Well, I see noone volunteering unfortunately.

Like most Open Source project we are understaffed. I wished it wasn't
that way, but that's how it is.

 At LPC in New Orleans, you asked me how you could make systemd easier to
 work with on the downstream side. I told you that I wanted more frequent
 releases. You seemed amenable to this, but it really never happened.

 I'm asking again: can we have more frequent releases? Can you take the
 steps to actually make this happen and not gate releases on your own
 personal availability?

Oh yes, I'd like 3 week cycles, too. And I'd like to pass release
management to somebody else, because I am unhappy with this too, and
the ridiculous amount of work this brings for me. 

However, this simply falls short due to limited manpower. We need
a skilled full-time person for this, and I don't see that growing on
trees unfortunately. 

Lennart

-- 
Lennart Poettering, Red Hat
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel


Re: [systemd-devel] 220 tarball erroneously ships keyboard-keys-from-name.gperf

2015-05-27 Thread Martin Pitt
Lennart Poettering [2015-05-27 12:56 +0200]:
  Sounds good. I actually did this twice (not sure if you saw my IRC
  pings about that) I just didn't do it at the right time. I think
  this would have helped to find most issues indeed (except for the
  keys-from-name.gperf thing, but meh -- happens seldomly enough), so
  let's try this for 221!
 
 Any chance to automate that in a cron-job on some server?

Yes, that has been on my wishlist for quite a while. We have
a fairly comprehensive set of integration tests now which give systemd
quite some beating; the main thing that's causing throuble is that
they won't completely succeed without porting patches, but there's
certainly some heuristics/leeway there (e. g. find the ones which are
required and ignore failure to apply the others).

 Ideally we'd really have a Jenkins instance for that, like David
 Strauss' one, but testing the .deb packages Ubuntu (or Debian)
 builds.

*nod*

Martin

-- 
Martin Pitt| http://www.piware.de
Ubuntu Developer (www.ubuntu.com)  | Debian Developer  (www.debian.org)
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel


Re: [systemd-devel] 220 tarball erroneously ships keyboard-keys-from-name.gperf

2015-05-27 Thread Martin Pitt
Hey Lennart,

Lennart Poettering [2015-05-27 12:26 +0200]:
   * Regularly test make dist, as nobody does that  during regular
 development.
 
 Well, no.

You just said before that we (distros) need to check tarball
generation/build more often. So I'm a bit confused by the no (but
see below).

 I use make distcheck regularly during regular development, and
 that's how I generate the final tarball.

True, the auto-generated header bug wouldn't have helped if I were to
do it on e. g. Debian sid and then build packages from that very
tarball, as it stemmed from being autogenerated from different kernel
includes etc.

So in that case the only thing that would have discovered this was
distros testing a tarball that you generated. So, back to RC tarball,
plz test a few days before you want to release?

 Alternative: Stop shipping make dist tarballs altogether and just
 tar the tagged git snapshot. Given the amount of patching that most
 distros do, we pretty much all run autoreconf anyway (including
 Fedora), so not having the pre-generated autoconfiscation and
 pre-built manpages etc. in the tarball isn't actually that much of
 a deal.
 
 Well, while I sympathize with the idea, this is still not how most
 current distros work...

OK. It was just a thought for completeness.

 How about this: please run automated tests if you have them in regular
 intervals, always tracking git. And a few days before a release I'll
 notify the mailing list.

Sounds good. I actually did this twice (not sure if you saw my IRC
pings about that) I just didn't do it at the right time. I think
this would have helped to find most issues indeed (except for the
keys-from-name.gperf thing, but meh -- happens seldomly enough), so
let's try this for 221!

 I really don't want to drown development in deep freeze phases, that
 are then alternated with crazy merge time phases. Instead, I'd much
 rather increase the release frequency, keep a steady stream of changes,
 and ask downstreams for more help with testing and keeping git
 constantly in a releasable state.

Also sounds good. With getting rid of a few large patches (like the
chkconfig → update-rc. ones, or the man page paths), doing CI more
often on my distro side will also become a much less manual process.

Thanks for having this post-mortem discussion, this is useful!

Martin
-- 
Martin Pitt| http://www.piware.de
Ubuntu Developer (www.ubuntu.com)  | Debian Developer  (www.debian.org)
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel


Re: [systemd-devel] 220 tarball erroneously ships keyboard-keys-from-name.gperf

2015-05-27 Thread Lennart Poettering
On Wed, 27.05.15 12:37, Martin Pitt (martin.p...@ubuntu.com) wrote:

 Hey Lennart,
 
 Lennart Poettering [2015-05-27 12:26 +0200]:
* Regularly test make dist, as nobody does that  during regular
  development.
  
  Well, no.
 
 You just said before that we (distros) need to check tarball
 generation/build more often. So I'm a bit confused by the no (but
 see below).

The no was mostly about the part nobody does that during regular
development. I actually do.

  I use make distcheck regularly during regular development, and
  that's how I generate the final tarball.
 
 True, the auto-generated header bug wouldn't have helped if I were to
 do it on e. g. Debian sid and then build packages from that very
 tarball, as it stemmed from being autogenerated from different kernel
 includes etc.
 
 So in that case the only thing that would have discovered this was
 distros testing a tarball that you generated. So, back to RC
 tarball, plz test a few days before you want to release?

Well, the other option is to simply accept that some bugs are not
easily testable for...

I mean, we can of course build tar balls on all distros and then build
them on all others, but this explodes the test matrix for only limited
benefit...

  How about this: please run automated tests if you have them in regular
  intervals, always tracking git. And a few days before a release I'll
  notify the mailing list.
 
 Sounds good. I actually did this twice (not sure if you saw my IRC
 pings about that) I just didn't do it at the right time. I think
 this would have helped to find most issues indeed (except for the
 keys-from-name.gperf thing, but meh -- happens seldomly enough), so
 let's try this for 221!

Any chance to automate that in a cron-job on some server?

Ideally we'd really have a Jenkins instance for that, like David
Strauss' one, but testing the .deb packages Ubuntu (or Debian)
builds. If Ubuntu could provide that this would be very welcome, and
of course it would be something I#d check before I do releases.

Lennart

-- 
Lennart Poettering, Red Hat
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel


Re: [systemd-devel] 220 tarball erroneously ships keyboard-keys-from-name.gperf

2015-05-27 Thread Dimitri John Ledkov
On 27 May 2015 at 10:52, Martin Pitt martin.p...@ubuntu.com wrote:
 Lennart Poettering [2015-05-27 11:42 +0200]:
 Well, but let's not forget that a major part of the issues popping up
 actually were committed weeks ago.

 Actually, no. As I said, on May 11 most everything was working just
 fine, the udev regressions landed very late. The path_is_mount_point()
 regression landed much earlier, but is much less visible (and now
 there are tests cases with the patch I sent).

 Things like the broken gperf generated bits or the missing EFI dirs
 were in git since a lng time.

 It would be great if downstream could help us with testing many of the
 build combinations, at any time of the cycle, not just when it comes
 to a release.

 Agreed. The broken tarball issues are not visible when building from
 git (which is what I'm doing all the time). We didn't have that kind
 of issues with 219 or 218 (or at least only negligible ones), but 220
 taught us all that we need to test make dist builds more often.

 So we have two indepenent things to fix:

  * Regularly test make dist, as nobody does that  during regular
development.

Alternative: Stop shipping make dist tarballs altogether and just
tar the tagged git snapshot. Given the amount of patching that most
distros do, we pretty much all run autoreconf anyway (including
Fedora), so not having the pre-generated autoconfiscation and
pre-built manpages etc. in the tarball isn't actually that much of
a deal.


+1 for dropping make dist support... git archive is really ought to be
the release tarball.


  * Impose a release freeze period with announcing an impending
release, distros do a deep testing (this is a day's work for me, so
can't happen that often). During that time (which really shouldn't
be more than a few days) we really should avoid any commit which
isn't an important bug fix, especially not large refactorings or
new features.

 Thanks,

 Martin

 --
 Martin Pitt| http://www.piware.de
 Ubuntu Developer (www.ubuntu.com)  | Debian Developer  (www.debian.org)
 ___
 systemd-devel mailing list
 systemd-devel@lists.freedesktop.org
 http://lists.freedesktop.org/mailman/listinfo/systemd-devel



-- 
Regards,

Dimitri.
Pura Vida!

https://clearlinux.org
Open Source Technology Center
Intel Corporation (UK) Ltd. - Co. Reg. #1134945 - Pipers Way, Swindon SN3 1RJ.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel


Re: [systemd-devel] 220 tarball erroneously ships keyboard-keys-from-name.gperf

2015-05-27 Thread Marc-Antoine Perennou
On 27 May 2015 at 12:26, Lennart Poettering lenn...@poettering.net wrote:

 I use make distcheck regularly during regular development, and
 that's how I generate the final tarball.


What about generating a preview tarball before tagging, and letting us
downstreams a couple of days to test it before you do the actual
tagging and put it in the official location?

Regards,
Marc-Antoine
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel


Re: [systemd-devel] 220 tarball erroneously ships keyboard-keys-from-name.gperf

2015-05-27 Thread Lennart Poettering
On Wed, 27.05.15 13:03, Martin Pitt (martin.p...@ubuntu.com) wrote:

 Lennart Poettering [2015-05-27 12:56 +0200]:
   Sounds good. I actually did this twice (not sure if you saw my IRC
   pings about that) I just didn't do it at the right time. I think
   this would have helped to find most issues indeed (except for the
   keys-from-name.gperf thing, but meh -- happens seldomly enough), so
   let's try this for 221!
  
  Any chance to automate that in a cron-job on some server?
 
 Yes, that has been on my wishlist for quite a while. We have
 a fairly comprehensive set of integration tests now which give systemd
 quite some beating; the main thing that's causing throuble is that
 they won't completely succeed without porting patches, but there's
 certainly some heuristics/leeway there (e. g. find the ones which are
 required and ignore failure to apply the others).

And of course: try to reduce them. As the discussion of the last days
has shown I am sure that quite a number of them can be merged upstream
or solved in a different way.

Lennart

-- 
Lennart Poettering, Red Hat
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel


Re: [systemd-devel] 220 tarball erroneously ships keyboard-keys-from-name.gperf

2015-05-27 Thread Lennart Poettering
On Wed, 27.05.15 12:42, Marc-Antoine Perennou (marc-anto...@perennou.com) wrote:

 On 27 May 2015 at 12:26, Lennart Poettering lenn...@poettering.net wrote:
 
  I use make distcheck regularly during regular development, and
  that's how I generate the final tarball.
 
 What about generating a preview tarball before tagging, and letting us
 downstreams a couple of days to test it before you do the actual
 tagging and put it in the official location?

I'd really prefer if downstreams would do this continously, and not
just close to the time of release.

Again, we should try to keep things in a releasable state in git,
every single day if possible.

Any chance you can automate testing like this for your distro? And of
course, hook this up with some but that notifies us about breakages,
maybe via IRC or so...

Lennart

-- 
Lennart Poettering, Red Hat
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel


Re: [systemd-devel] 220 tarball erroneously ships keyboard-keys-from-name.gperf

2015-05-26 Thread Dave Reisner
On Tue, May 26, 2015 at 04:17:07PM +0200, Lennart Poettering wrote:
 On Tue, 26.05.15 15:12, Dimitri John Ledkov (dimitri.j.led...@intel.com) 
 wrote:
 
  Or will there be a v220.1 release shortly with releasy fix-ups?
 
 Well, we don't do point releases in systemd. 

 In systemd git we already have now the change that makes sd-bus and
 sd-event public APIs, hence v221 is going to be more than just
 bugfixes. 

Is git revert not an option? Does someone depend on this already, making
a rollback impossible (and why would you allow that)? You say that
versions are just a label, but a project which adopts semver would be
able to create a branch in git and produce a dot release with backported
bugfixes. Surely you're familiar with this concept -- your colleague
Karel does this routinely with util-linux.

The fact of the matter is, the last 2 releases of systemd have been
brown bag releases. Neither 219 nor 220 are useable as the tarballs are
provided. v220 doesn't even build in a large number of configurations.
v218 wasn't quite as bad, but landed 18 patches in Arch's packaging
before v219 was released. For the average Arch package, this is unheard
of, let alone being a *necessity* in order to make software useable.

Please, let's figure out a way to lower the amount of work that gets
sharded out and duplicated by downstream packagers.

 Also, next week I'll be travelling and I doubt I will be able to
 finish a new release by then. Maybe in the middle of June we can get
 out a new release.

 Sorry,

I'm sorry to hear this too. Please find someone else who's paid to work
on systemd and teach them how to package releases. The current state of
affairs absolutely sucks for downstreams. Currently, packaging systemd
takes more of my time than all of my other packaging responsibilities
combined.

At LPC in New Orleans, you asked me how you could make systemd easier to
work with on the downstream side. I told you that I wanted more frequent
releases. You seemed amenable to this, but it really never happened.
I'm asking again: can we have more frequent releases? Can you take the
steps to actually make this happen and not gate releases on your own
personal availability?

d
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel


Re: [systemd-devel] 220 tarball erroneously ships keyboard-keys-from-name.gperf

2015-05-26 Thread Michael Biebl
2015-05-27 2:51 GMT+02:00 Dave Reisner d...@falconindy.com:
 The fact of the matter is, the last 2 releases of systemd have been
 brown bag releases. Neither 219 nor 220 are useable as the tarballs are
 provided. v220 doesn't even build in a large number of configurations.
 v218 wasn't quite as bad, but landed 18 patches in Arch's packaging
 before v219 was released. For the average Arch package, this is unheard
 of, let alone being a *necessity* in order to make software useable.

 Please, let's figure out a way to lower the amount of work that gets
 sharded out and duplicated by downstream packagers.

Glad to know that I'm not the only one who feels this way. Let me
quote myself from #systemd:

mbiebl_ zbyszek: looks like we want a v221 release soon
mbiebl_ fwiw, I think our QA for doing releases sucks
zbyszek mbiebl_: I'm working on the selinux bug currently...
zbyszek mbiebl_: I think the releases are possibly the point of
highest instability
mbiebl_ a bit more official planning and giving people time to test
would be a great start
zbyszek I suggested doing a week of cooling off before a release
before, but somehow that didn't stick.
mbiebl_ just telling people, when the release is planned, would help
mbiebl_ right now, that feels really amateurish
zbyszek mbiebl_: yeah, that would help. But without a rule that only
bugfix and cosmetic or documentation changes go in, it's hard to test
stuff properly.
mbiebl_ absolutely, just saying that atm we don't even have that
mbiebl_ i.e. we know when a release is planned
mbiebl_ that's imo the absolute minimum
mbiebl_ the result is broken dist tarballs
mbiebl_ and distros having to ship 50+ patches until it get's usable
mbiebl_ that sucks bigs time

-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel


Re: [systemd-devel] 220 tarball erroneously ships keyboard-keys-from-name.gperf

2015-05-26 Thread Michael Biebl
2015-05-26 17:57 GMT+02:00 Reindl Harald h.rei...@thelounge.net:
 There's a stable git tree maintained by Zbigniew, Lukas and friends,
 that carries backports for the stable releases. Most vendors should
 consider following that repo I figure.

 I try to help the backporting business by tagging the commits I
 personally consider backport-worthy with git notes and the
 Backport: field


 it just works poor

 * https://bugzilla.redhat.com/show_bug.cgi?id=1185278
   never got fixed in F20 but is fixed in Fedora 21
 * https://bugzilla.redhat.com/show_bug.cgi?id=1185277 open for months

 and in general a bunch of git commits don't replace a upstream changelog of
 a minor release where as user you never have any idea what your current
 installed package really is

 with a 220.1 and a usptream download of 220.1 containing a changelog things
 are entirely different (besides that the version numbers for a project
 existing just a few years are strange to say it nicely)

Maybe we(distro maintainers included) could work together with
Zbigniew and cut releases from the stable-branches?



-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel


Re: [systemd-devel] 220 tarball erroneously ships keyboard-keys-from-name.gperf

2015-05-26 Thread Lennart Poettering
On Tue, 26.05.15 17:57, Reindl Harald (h.rei...@thelounge.net) wrote:

 
 Am 26.05.2015 um 17:29 schrieb Lennart Poettering:
 On Tue, 26.05.15 16:39, Reindl Harald (h.rei...@thelounge.net) wrote:
 which shows that a important project like systemd playing on the same level
 as the linux kernel *just needs* point releases, there is a reason that the
 kernel has point-releases and not only for the latest and greatest version,
 systemd as well as the kernel are not a random webbrowser
 
 There's a stable git tree maintained by Zbigniew, Lukas and friends,
 that carries backports for the stable releases. Most vendors should
 consider following that repo I figure.
 
 I try to help the backporting business by tagging the commits I
 personally consider backport-worthy with git notes and the
 Backport: field
 
 it just works poor
 
 * https://bugzilla.redhat.com/show_bug.cgi?id=1185278
   never got fixed in F20 but is fixed in Fedora 21

Well, it's not really a bug. We require util-linux to be around. If
you make it unavailable then you get to to keep the pieces. It's that
simple.

 * https://bugzilla.redhat.com/show_bug.cgi?id=1185277 open for
   months

I wasn't aware there was a reproducer for this issue now. Good to
know.

 and in general a bunch of git commits don't replace a upstream changelog of
 a minor release where as user you never have any idea what your current
 installed package really is.

Nah, this is not how this works. We simply do not provide turn-key
ready versions of systemd. systemd is not an app, it needs to be
integrated by the distributions, and they will have to adapt it to
their needs. Hence: if you want minor release information check the
RPM changelog, but don't expect that from us. We are not a product, we
are just a building block others may build a product from, and thus
need to polish it.

 with a 220.1 and a usptream download of 220.1 containing a changelog things
 are entirely different (besides that the version numbers for a project
 existing just a few years are strange to say it nicely)

Well, I certainly have enough things to do. We have trouble keeping up
with he amount of work that we already get, and I have no intention to
make things even more complex by maintaining multiple branches for
you, if the distros already do this anyway.

And again, there's already the stable tree maintained by Zbigniew and
friends. It comes with a change history git log and it's constantly
updated. Zbigniew doesn't tag releases in it, but if that's what you
need you can just tag it yourself and count each commit up that is
applied based on a stable branch...

Lennart

-- 
Lennart Poettering, Red Hat
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel


Re: [systemd-devel] 220 tarball erroneously ships keyboard-keys-from-name.gperf

2015-05-26 Thread Martin Pitt
Lennart Poettering [2015-05-26 18:22 +0200]:
 Well, I certainly have enough things to do. We have trouble keeping up
 with he amount of work that we already get, and I have no intention to
 make things even more complex by maintaining multiple branches for
 you, if the distros already do this anyway.

Honestly, git format-patch (or even more convenient proper packaging
tools like Debian's git-buildpackages pq) make it a trivial
operation to get one or several upstream fixes, it's not more work
(usually less) than packaging an entire new upstream release.

Bugs that affect the tarball are a tad harder, but adding

  rm -f src/journal/audit_type-to-name.h src/udev/keyboard-keys-from-name.gperf

to the build script until we get 221 isn't rocket science either.

So I agree that maintaining more branches and upstream releases would
cause a lot of low-benefit work. I'd much rather get some distro-side
testing before we do an upstream release (see my other reply).

Martin

-- 
Martin Pitt| http://www.piware.de
Ubuntu Developer (www.ubuntu.com)  | Debian Developer  (www.debian.org)
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel


Re: [systemd-devel] 220 tarball erroneously ships keyboard-keys-from-name.gperf

2015-05-26 Thread Lennart Poettering
On Tue, 26.05.15 15:12, Dimitri John Ledkov (dimitri.j.led...@intel.com) wrote:

 Or will there be a v220.1 release shortly with releasy fix-ups?

Well, we don't do point releases in systemd. 

In systemd git we already have now the change that makes sd-bus and
sd-event public APIs, hence v221 is going to be more than just
bugfixes. 

Also, next week I'll be travelling and I doubt I will be able to
finish a new release by then. Maybe in the middle of June we can get
out a new release.

Sorry,

Lennart

-- 
Lennart Poettering, Red Hat
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel


Re: [systemd-devel] 220 tarball erroneously ships keyboard-keys-from-name.gperf

2015-05-26 Thread Lennart Poettering
On Fri, 22.05.15 17:28, Martin Pitt (martin.p...@ubuntu.com) wrote:

 Hello,
 
 while packaging 220, I got the audit related build failure that was
 already reported [1], but also another one:

I think this has been fixed now with Tom's commit
ee3c31bf69746c5afc764c3d0337feec1bf25f0e contributed my Marc-Antoine.

Please verify.

Lennart

 
 | In file included from ../src/udev/udev-builtin-keyboard.c:29:0:
 | ./src/udev/keyboard-keys-from-name.h: In function 'keyboard_lookup_key':
 | ./src/udev/keyboard-keys-from-name.h:253:21: error: 'KEY_NUMERIC_A' 
 undeclared (first use in this function)
 |{numeric_a, KEY_NUMERIC_A},
 |  ^
 | ./src/udev/keyboard-keys-from-name.h:253:21: note: each undeclared 
 identifier is reported only once for each function it appears in
 | ./src/udev/keyboard-keys-from-name.h:275:21: error: 'KEY_NUMERIC_C' 
 undeclared (first use in this function)
 |{numeric_c, KEY_NUMERIC_C},
 |  ^
 | ./src/udev/keyboard-keys-from-name.h:347:21: error: 'KEY_NUMERIC_D' 
 undeclared (first use in this function)
 |{numeric_d, KEY_NUMERIC_D},
 |  ^
 | ./src/udev/keyboard-keys-from-name.h:420:21: error: 'KEY_NUMERIC_B' 
 undeclared (first use in this function)
 |{numeric_b, KEY_NUMERIC_B},
 |  ^
 | ./src/udev/keyboard-keys-from-name.h:464:26: error: 'KEY_ROTATE_DISPLAY' 
 undeclared (first use in this function)
 |{rotate_display, KEY_ROTATE_DISPLAY},
 
 This is because unlike 219 and earlier, the 220 tarball ships a
 pregenerated src/udev/keyboard-keys-from-name.gperf. In Debian sid,
 the above constants are not defined (in the kernel headers, I
 presume). I think src/udev/keyboard-keys-from-name.gperf is supposed
 to be built during package build? I see that somewhere between 219 and
 220 this happened in Makefile.am:
 
 -CLEANFILES += \
 -   src/udev/keyboard-keys-from-name.gperf \
 -   src/udev/keyboard-keys.txt \
 -   src/udev/net/link-config-gperf.c
 
 but apparently this wasn't put back someplace else?
 
 Thanks,
 
 Martin
 
 [1] http://lists.freedesktop.org/archives/systemd-devel/2015-May/032148.html
 -- 
 Martin Pitt| http://www.piware.de
 Ubuntu Developer (www.ubuntu.com)  | Debian Developer  (www.debian.org)
 ___
 systemd-devel mailing list
 systemd-devel@lists.freedesktop.org
 http://lists.freedesktop.org/mailman/listinfo/systemd-devel


Lennart

-- 
Lennart Poettering, Red Hat
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel


Re: [systemd-devel] 220 tarball erroneously ships keyboard-keys-from-name.gperf

2015-05-26 Thread Martin Pitt
Lennart Poettering [2015-05-26 16:06 +0200]:
 I think this has been fixed now with Tom's commit
 ee3c31bf69746c5afc764c3d0337feec1bf25f0e contributed my Marc-Antoine.

Confirmed this morning. Sorry, I should have followed up to the ML
immediately. Thanks Tom!

Martin
-- 
Martin Pitt| http://www.piware.de
Ubuntu Developer (www.ubuntu.com)  | Debian Developer  (www.debian.org)
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel


Re: [systemd-devel] 220 tarball erroneously ships keyboard-keys-from-name.gperf

2015-05-26 Thread Lennart Poettering
On Tue, 26.05.15 16:39, Reindl Harald (h.rei...@thelounge.net) wrote:

 
 Am 26.05.2015 um 16:17 schrieb Lennart Poettering:
 On Tue, 26.05.15 15:12, Dimitri John Ledkov (dimitri.j.led...@intel.com) 
 wrote:
 
 Or will there be a v220.1 release shortly with releasy fix-ups?
 
 Well, we don't do point releases in systemd.
 
 and why?
 
 just because don't do is not enough

it's just a label after all and I like my bikesheds green without
points.

 In systemd git we already have now the change that makes sd-bus and
 sd-event public APIs, hence v221 is going to be more than just
 bugfixes.
 
 that don't fix 220
 
 Also, next week I'll be travelling and I doubt I will be able to
 finish a new release by then. Maybe in the middle of June we can get
 out a new release
 
 which shows that a important project like systemd playing on the same level
 as the linux kernel *just needs* point releases, there is a reason that the
 kernel has point-releases and not only for the latest and greatest version,
 systemd as well as the kernel are not a random webbrowser

There's a stable git tree maintained by Zbigniew, Lukas and friends,
that carries backports for the stable releases. Most vendors should
consider following that repo I figure.

I try to help the backporting business by tagging the commits I
personally consider backport-worthy with git notes and the
Backport: field.

Lennart

-- 
Lennart Poettering, Red Hat
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel


Re: [systemd-devel] 220 tarball erroneously ships keyboard-keys-from-name.gperf

2015-05-26 Thread Dimitri John Ledkov
On 26 May 2015 at 15:10, Martin Pitt martin.p...@ubuntu.com wrote:
 Lennart Poettering [2015-05-26 16:06 +0200]:
 I think this has been fixed now with Tom's commit
 ee3c31bf69746c5afc764c3d0337feec1bf25f0e contributed my Marc-Antoine.

 Confirmed this morning. Sorry, I should have followed up to the ML
 immediately. Thanks Tom!

Can stable-v220 branch be started with these please?

Or will there be a v220.1 release shortly with releasy fix-ups?
-- 
Regards,

Dimitri.
Pura Vida!

https://clearlinux.org
Open Source Technology Center
Intel Corporation (UK) Ltd. - Co. Reg. #1134945 - Pipers Way, Swindon SN3 1RJ.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel


Re: [systemd-devel] 220 tarball erroneously ships keyboard-keys-from-name.gperf

2015-05-26 Thread Reindl Harald


Am 26.05.2015 um 16:17 schrieb Lennart Poettering:

On Tue, 26.05.15 15:12, Dimitri John Ledkov (dimitri.j.led...@intel.com) wrote:


Or will there be a v220.1 release shortly with releasy fix-ups?


Well, we don't do point releases in systemd.


and why?

just because don't do is not enough


In systemd git we already have now the change that makes sd-bus and
sd-event public APIs, hence v221 is going to be more than just
bugfixes.


that don't fix 220


Also, next week I'll be travelling and I doubt I will be able to
finish a new release by then. Maybe in the middle of June we can get
out a new release


which shows that a important project like systemd playing on the same 
level as the linux kernel *just needs* point releases, there is a reason 
that the kernel has point-releases and not only for the latest and 
greatest version, systemd as well as the kernel are not a random webbrowser




signature.asc
Description: OpenPGP digital signature
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel


Re: [systemd-devel] 220 tarball erroneously ships keyboard-keys-from-name.gperf

2015-05-26 Thread Lennart Poettering
On Tue, 26.05.15 19:13, Reindl Harald (h.rei...@thelounge.net) wrote:

 
 Am 26.05.2015 um 18:22 schrieb Lennart Poettering:
 On Tue, 26.05.15 17:57, Reindl Harald (h.rei...@thelounge.net) wrote:
 
 Am 26.05.2015 um 17:29 schrieb Lennart Poettering:
 On Tue, 26.05.15 16:39, Reindl Harald (h.rei...@thelounge.net) wrote:
 which shows that a important project like systemd playing on the same 
 level
 as the linux kernel *just needs* point releases, there is a reason that 
 the
 kernel has point-releases and not only for the latest and greatest 
 version,
 systemd as well as the kernel are not a random webbrowser
 
 There's a stable git tree maintained by Zbigniew, Lukas and friends,
 that carries backports for the stable releases. Most vendors should
 consider following that repo I figure.
 
 I try to help the backporting business by tagging the commits I
 personally consider backport-worthy with git notes and the
 Backport: field
 
 it just works poor
 
 * https://bugzilla.redhat.com/show_bug.cgi?id=1185278
never got fixed in F20 but is fixed in Fedora 21
 
 Well, it's not really a bug. We require util-linux to be around. If
 you make it unavailable then you get to to keep the pieces. It's that
 simple
 
 sftp-chroot worked fine until Fedora 20 and started to work again with
 Fedora 21 so please don't pretend anything else than systemd is (or was)
 responsible to fail proper shutdown and termination of the recently by
 systemd invented user-session processes

Well, we still require /usr/bin/kill from util-linux to be around. We
did not fix your bug... Maybe this doesn't trip up anymore, but we
didn't specifically fix anything...

Lennart

-- 
Lennart Poettering, Red Hat
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel


Re: [systemd-devel] 220 tarball erroneously ships keyboard-keys-from-name.gperf

2015-05-26 Thread Reindl Harald


Am 26.05.2015 um 17:29 schrieb Lennart Poettering:

On Tue, 26.05.15 16:39, Reindl Harald (h.rei...@thelounge.net) wrote:

which shows that a important project like systemd playing on the same level
as the linux kernel *just needs* point releases, there is a reason that the
kernel has point-releases and not only for the latest and greatest version,
systemd as well as the kernel are not a random webbrowser


There's a stable git tree maintained by Zbigniew, Lukas and friends,
that carries backports for the stable releases. Most vendors should
consider following that repo I figure.

I try to help the backporting business by tagging the commits I
personally consider backport-worthy with git notes and the
Backport: field


it just works poor

* https://bugzilla.redhat.com/show_bug.cgi?id=1185278
  never got fixed in F20 but is fixed in Fedora 21
* https://bugzilla.redhat.com/show_bug.cgi?id=1185277 open for months

and in general a bunch of git commits don't replace a upstream changelog 
of a minor release where as user you never have any idea what your 
current installed package really is


with a 220.1 and a usptream download of 220.1 containing a changelog 
things are entirely different (besides that the version numbers for a 
project existing just a few years are strange to say it nicely)




signature.asc
Description: OpenPGP digital signature
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel


Re: [systemd-devel] 220 tarball erroneously ships keyboard-keys-from-name.gperf

2015-05-26 Thread Reindl Harald


Am 26.05.2015 um 18:22 schrieb Lennart Poettering:

On Tue, 26.05.15 17:57, Reindl Harald (h.rei...@thelounge.net) wrote:


Am 26.05.2015 um 17:29 schrieb Lennart Poettering:

On Tue, 26.05.15 16:39, Reindl Harald (h.rei...@thelounge.net) wrote:

which shows that a important project like systemd playing on the same level
as the linux kernel *just needs* point releases, there is a reason that the
kernel has point-releases and not only for the latest and greatest version,
systemd as well as the kernel are not a random webbrowser


There's a stable git tree maintained by Zbigniew, Lukas and friends,
that carries backports for the stable releases. Most vendors should
consider following that repo I figure.

I try to help the backporting business by tagging the commits I
personally consider backport-worthy with git notes and the
Backport: field


it just works poor

* https://bugzilla.redhat.com/show_bug.cgi?id=1185278
   never got fixed in F20 but is fixed in Fedora 21


Well, it's not really a bug. We require util-linux to be around. If
you make it unavailable then you get to to keep the pieces. It's that
simple


sftp-chroot worked fine until Fedora 20 and started to work again with 
Fedora 21 so please don't pretend anything else than systemd is (or was) 
responsible to fail proper shutdown and termination of the recently by 
systemd invented user-session processes




signature.asc
Description: OpenPGP digital signature
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel


[systemd-devel] 220 tarball erroneously ships keyboard-keys-from-name.gperf

2015-05-22 Thread Martin Pitt
Hello,

while packaging 220, I got the audit related build failure that was
already reported [1], but also another one:

| In file included from ../src/udev/udev-builtin-keyboard.c:29:0:
| ./src/udev/keyboard-keys-from-name.h: In function 'keyboard_lookup_key':
| ./src/udev/keyboard-keys-from-name.h:253:21: error: 'KEY_NUMERIC_A' 
undeclared (first use in this function)
|{numeric_a, KEY_NUMERIC_A},
|  ^
| ./src/udev/keyboard-keys-from-name.h:253:21: note: each undeclared identifier 
is reported only once for each function it appears in
| ./src/udev/keyboard-keys-from-name.h:275:21: error: 'KEY_NUMERIC_C' 
undeclared (first use in this function)
|{numeric_c, KEY_NUMERIC_C},
|  ^
| ./src/udev/keyboard-keys-from-name.h:347:21: error: 'KEY_NUMERIC_D' 
undeclared (first use in this function)
|{numeric_d, KEY_NUMERIC_D},
|  ^
| ./src/udev/keyboard-keys-from-name.h:420:21: error: 'KEY_NUMERIC_B' 
undeclared (first use in this function)
|{numeric_b, KEY_NUMERIC_B},
|  ^
| ./src/udev/keyboard-keys-from-name.h:464:26: error: 'KEY_ROTATE_DISPLAY' 
undeclared (first use in this function)
|{rotate_display, KEY_ROTATE_DISPLAY},

This is because unlike 219 and earlier, the 220 tarball ships a
pregenerated src/udev/keyboard-keys-from-name.gperf. In Debian sid,
the above constants are not defined (in the kernel headers, I
presume). I think src/udev/keyboard-keys-from-name.gperf is supposed
to be built during package build? I see that somewhere between 219 and
220 this happened in Makefile.am:

-CLEANFILES += \
-   src/udev/keyboard-keys-from-name.gperf \
-   src/udev/keyboard-keys.txt \
-   src/udev/net/link-config-gperf.c

but apparently this wasn't put back someplace else?

Thanks,

Martin

[1] http://lists.freedesktop.org/archives/systemd-devel/2015-May/032148.html
-- 
Martin Pitt| http://www.piware.de
Ubuntu Developer (www.ubuntu.com)  | Debian Developer  (www.debian.org)
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel


Re: [systemd-devel] 220 tarball erroneously ships keyboard-keys-from-name.gperf

2015-05-22 Thread Zbigniew Jędrzejewski-Szmek
On Fri, May 22, 2015 at 05:28:01PM +0200, Martin Pitt wrote:
 Hello,
 
 while packaging 220, I got the audit related build failure that was
 already reported [1], but also another one:
 
 | In file included from ../src/udev/udev-builtin-keyboard.c:29:0:
 | ./src/udev/keyboard-keys-from-name.h: In function 'keyboard_lookup_key':
 | ./src/udev/keyboard-keys-from-name.h:253:21: error: 'KEY_NUMERIC_A' 
 undeclared (first use in this function)
 |{numeric_a, KEY_NUMERIC_A},
 |  ^
 | ./src/udev/keyboard-keys-from-name.h:253:21: note: each undeclared 
 identifier is reported only once for each function it appears in
 | ./src/udev/keyboard-keys-from-name.h:275:21: error: 'KEY_NUMERIC_C' 
 undeclared (first use in this function)
 |{numeric_c, KEY_NUMERIC_C},
 |  ^
 | ./src/udev/keyboard-keys-from-name.h:347:21: error: 'KEY_NUMERIC_D' 
 undeclared (first use in this function)
 |{numeric_d, KEY_NUMERIC_D},
 |  ^
 | ./src/udev/keyboard-keys-from-name.h:420:21: error: 'KEY_NUMERIC_B' 
 undeclared (first use in this function)
 |{numeric_b, KEY_NUMERIC_B},
 |  ^
 | ./src/udev/keyboard-keys-from-name.h:464:26: error: 'KEY_ROTATE_DISPLAY' 
 undeclared (first use in this function)
 |{rotate_display, KEY_ROTATE_DISPLAY},
 
 This is because unlike 219 and earlier, the 220 tarball ships a
 pregenerated src/udev/keyboard-keys-from-name.gperf. In Debian sid,
 the above constants are not defined (in the kernel headers, I
 presume). I think src/udev/keyboard-keys-from-name.gperf is supposed
 to be built during package build? I see that somewhere between 219 and
 220 this happened in Makefile.am:
 
 -CLEANFILES += \
 -   src/udev/keyboard-keys-from-name.gperf \
 -   src/udev/keyboard-keys.txt \
 -   src/udev/net/link-config-gperf.c
 
 but apparently this wasn't put back someplace else?
This was replaced by uniform rules for all gperf files.
Those generic rules probably need fixing.

Zbyszek
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel