All of lore.kernel.org
 help / color / mirror / Atom feed
* stable/v2.29.1
@ 2017-01-18 13:12 Karel Zak
  2017-01-19 10:32 ` stable/v2.29.1 Bernhard Voelker
  0 siblings, 1 reply; 6+ messages in thread
From: Karel Zak @ 2017-01-18 13:12 UTC (permalink / raw)
  To: util-linux


The branch stable/v2.29 contains what I want to release as v2.29.1.

Any objections or suggestions? See log below.

    Karel


Andreas Henriksson (3):
      chrt: default to SCHED_RR policy
      sulogin: make getpasswd(...) return NULL on ^D
      sulogin: bail out from getpasswd(...) on timeout

Joe Hansen (1):
      po: update da.po (from translationproject.org)

Karel Zak (18):
      sfdisk: don't be silent when list non-existing device
      sfdisk: cleanup --dump error messages
      docs: nsenter(1): add missing 'see also' for --user
      hwclock: don't check for permissions
      build-sys: prefer pkg-config for ncurses
      fdisk: don't be silent when list non-existing device
      build-sys: cleanup UL_NCURSES_CHECK
      more: avoid double free() on exit
      findmnt: error on --target /non-exist
      lib/linux_version: fix stupid typo
      lscpu: add aarch64 specific names
      libsmartcols: add scols_cell_get_alignment()
      libfdisk: recount size when apply user device properties
      libfdisk: (gpt) make calculations more robust
      po: merge changes
      docs: update AUTHORS file
      docs: update v2.29.1-ReleaseNotes
      build-sys: release++ (v2.29.1)

Michael Kerrisk (25):
      docs: nsenter(1): Describe the 'file' argument used by namespace options
      docs: nsenter(1): Formatting fix
      docs: various pages: Use "system call" not "syscall"
      docs: kill(1): Fix section reference for sigqueue(3) and add to SEE ALSO
      docs: kill(1): Add more detail on use of SIGTERM vs SIGKILL
      docs: kill(1): Rework notes on thread groups
      docs: kill(1): Formatting fixes
      docs: kill(1): Wording fix
      docs: renice(1): Rework discussion of unprivileged users,
      docs: renice(1): Remove obsolete BUGS text
      docs: various pages: Format pathnames as italic (.I)
      docs: various pages: Use consistent terminology (set-user-ID and set-group-ID)
      docs: various pages: Use "ID" not "id" in man pages
      docs: various pages: Use "PID" not "pid" in man-pages
      docs: various pages: Use 'UID" and "GID", not "uid" and "gid" in man pages
      docs: kill(1): Wording fix
      docs: namei(1): SEE ALSO: add symlink(7)
      docs: taskset(1): Wording fix
      docs: last(1): SEE ALSO: add reference to wtmp(5)
      docs: last(1): Eliminate oddball formatting
      docs: lsns(8): SEE ALSO: add namespaces(7)
      docs: ionice(1): SEE ALSO: add ioprio_set(2)
      docs: mount(8): Wording fix
      docs: renice(1): Add SEE ALSO entry for sched(7)
      docs: renice(1): Add credentials(7) to SEE ALSO

Michael Kerrisk (man-pages) (12):
      Fix typo in page cross reference (capabilities(7), not, capability(7))
      Place SEE ALSO entries in order
      Correctly format page cross references
      Fix page cross references
      Fix section number in lockf() page xref
      Fix reference for scheduling discussion
      Fix formatting errors in page cross references
      Replace reference to sigvec(2) with sigaction(2)
      SEE ALSO: add cross reference to namespaces(7)
      Provide better cross references for namespace concepts
      Provide better cross references for namespace concepts
      IPC namespaces also isolate POSIX message queues

Nate Clark (4):
      disk-utils/mkfs.minix: Set ninodes after checking max
      libblkid/minix: Match minix superblock types
      libblkid/minix: Use same checks for version 3
      libblkid/minix: Sanity check superblock s_state for v 1 and 2

OGAWA Hirofumi (1):
      lsns: Fix parser for /proc/<pid>/stat which is including space in comm

Rafael Fontenelle (1):
      po: update pt_BR.po (from translationproject.org)

Ruediger Meier (3):
      build-sys: fix empty package release number
      build-sys: update package release number during development
      build-sys: don't clean *.img files

Stanislav Brabec (1):
      If mtab support is disabled, disable ro/rw mtab checks

Stéphane Aulery (1):
      po: update fr.po (from translationproject.org)



-- 
 Karel Zak  <kzak@redhat.com>
 http://karelzak.blogspot.com

^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: stable/v2.29.1
  2017-01-18 13:12 stable/v2.29.1 Karel Zak
@ 2017-01-19 10:32 ` Bernhard Voelker
  2017-01-19 11:35   ` stable/v2.29.1 Karel Zak
  0 siblings, 1 reply; 6+ messages in thread
From: Bernhard Voelker @ 2017-01-19 10:32 UTC (permalink / raw)
  To: Karel Zak, util-linux

On 01/18/2017 02:12 PM, Karel Zak wrote:
> The branch stable/v2.29 contains what I want to release as v2.29.1.

General question:
Is it worth dealing with maintenance branches in the upstream repo?
I mean, downstream projects can cherry-pick fixes and improvements
to their own needs anyway.  So I think having one upstream mainline
would be sufficient.  WDYT?

Have a nice day,
Berny

^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: stable/v2.29.1
  2017-01-19 10:32 ` stable/v2.29.1 Bernhard Voelker
@ 2017-01-19 11:35   ` Karel Zak
  2017-01-19 12:15     ` stable/v2.29.1 Bernhard Voelker
  2017-01-19 16:09     ` stable/v2.29.1 Bruce Dubbs
  0 siblings, 2 replies; 6+ messages in thread
From: Karel Zak @ 2017-01-19 11:35 UTC (permalink / raw)
  To: Bernhard Voelker; +Cc: util-linux

On Thu, Jan 19, 2017 at 11:32:20AM +0100, Bernhard Voelker wrote:
> On 01/18/2017 02:12 PM, Karel Zak wrote:
> > The branch stable/v2.29 contains what I want to release as v2.29.1.
> 
> General question:
> Is it worth dealing with maintenance branches in the upstream repo?
> I mean, downstream projects can cherry-pick fixes and improvements
> to their own needs anyway.  So I think having one upstream mainline
> would be sufficient.  WDYT?

 I use the branches to create maintenance releases (tarballs), e.g.
 v2.29.1.
 
 The goal is to minimize number of patches in downstream packages. So I
 guess downstream are happy to have .1 and .2 releases.

    Karel

-- 
 Karel Zak  <kzak@redhat.com>
 http://karelzak.blogspot.com

^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: stable/v2.29.1
  2017-01-19 11:35   ` stable/v2.29.1 Karel Zak
@ 2017-01-19 12:15     ` Bernhard Voelker
  2017-01-19 12:46       ` stable/v2.29.1 Karel Zak
  2017-01-19 16:09     ` stable/v2.29.1 Bruce Dubbs
  1 sibling, 1 reply; 6+ messages in thread
From: Bernhard Voelker @ 2017-01-19 12:15 UTC (permalink / raw)
  To: Karel Zak; +Cc: util-linux

On 01/19/2017 12:35 PM, Karel Zak wrote:
> On Thu, Jan 19, 2017 at 11:32:20AM +0100, Bernhard Voelker wrote:
>> On 01/18/2017 02:12 PM, Karel Zak wrote:
>>> The branch stable/v2.29 contains what I want to release as v2.29.1.
>>
>> General question:
>> Is it worth dealing with maintenance branches in the upstream repo?
>> I mean, downstream projects can cherry-pick fixes and improvements
>> to their own needs anyway.  So I think having one upstream mainline
>> would be sufficient.  WDYT?
> 
>  I use the branches to create maintenance releases (tarballs), e.g.
>  v2.29.1.
>  
>  The goal is to minimize number of patches in downstream packages. So I
>  guess downstream are happy to have .1 and .2 releases.

I see: as you're also downstream Redhat/Fedora maintainer, you're
effectively doing the downstream work in the upstream repository and
thus share this to other projects.  That's nice. ;-)

Thanks & have a nice day,
Berny

^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: stable/v2.29.1
  2017-01-19 12:15     ` stable/v2.29.1 Bernhard Voelker
@ 2017-01-19 12:46       ` Karel Zak
  0 siblings, 0 replies; 6+ messages in thread
From: Karel Zak @ 2017-01-19 12:46 UTC (permalink / raw)
  To: Bernhard Voelker; +Cc: util-linux

On Thu, Jan 19, 2017 at 01:15:56PM +0100, Bernhard Voelker wrote:
> On 01/19/2017 12:35 PM, Karel Zak wrote:
> > On Thu, Jan 19, 2017 at 11:32:20AM +0100, Bernhard Voelker wrote:
> >> On 01/18/2017 02:12 PM, Karel Zak wrote:
> >>> The branch stable/v2.29 contains what I want to release as v2.29.1.
> >>
> >> General question:
> >> Is it worth dealing with maintenance branches in the upstream repo?
> >> I mean, downstream projects can cherry-pick fixes and improvements
> >> to their own needs anyway.  So I think having one upstream mainline
> >> would be sufficient.  WDYT?
> > 
> >  I use the branches to create maintenance releases (tarballs), e.g.
> >  v2.29.1.
> >  
> >  The goal is to minimize number of patches in downstream packages. So I
> >  guess downstream are happy to have .1 and .2 releases.
> 
> I see: as you're also downstream Redhat/Fedora maintainer, you're
> effectively doing the downstream work in the upstream repository and
> thus share this to other projects.  That's nice. ;-)

 another downstreams also collaborate on maintenance releases. For
 example right now we want to release 2.29.1 before Debian freeze :-)

    Karel

-- 
 Karel Zak  <kzak@redhat.com>
 http://karelzak.blogspot.com

^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: stable/v2.29.1
  2017-01-19 11:35   ` stable/v2.29.1 Karel Zak
  2017-01-19 12:15     ` stable/v2.29.1 Bernhard Voelker
@ 2017-01-19 16:09     ` Bruce Dubbs
  1 sibling, 0 replies; 6+ messages in thread
From: Bruce Dubbs @ 2017-01-19 16:09 UTC (permalink / raw)
  To: Karel Zak, Bernhard Voelker; +Cc: util-linux

Karel Zak wrote:
> On Thu, Jan 19, 2017 at 11:32:20AM +0100, Bernhard Voelker wrote:
>> On 01/18/2017 02:12 PM, Karel Zak wrote:
>>> The branch stable/v2.29 contains what I want to release as v2.29.1.
>>
>> General question:
>> Is it worth dealing with maintenance branches in the upstream repo?
>> I mean, downstream projects can cherry-pick fixes and improvements
>> to their own needs anyway.  So I think having one upstream mainline
>> would be sufficient.  WDYT?
>
>   I use the branches to create maintenance releases (tarballs), e.g.
>   v2.29.1.
>
>   The goal is to minimize number of patches in downstream packages. So I
>   guess downstream are happy to have .1 and .2 releases.

That is certainly true for Linux From Scratch.

   -- Bruce

^ permalink raw reply	[flat|nested] 6+ messages in thread

end of thread, other threads:[~2017-01-19 16:09 UTC | newest]

Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2017-01-18 13:12 stable/v2.29.1 Karel Zak
2017-01-19 10:32 ` stable/v2.29.1 Bernhard Voelker
2017-01-19 11:35   ` stable/v2.29.1 Karel Zak
2017-01-19 12:15     ` stable/v2.29.1 Bernhard Voelker
2017-01-19 12:46       ` stable/v2.29.1 Karel Zak
2017-01-19 16:09     ` stable/v2.29.1 Bruce Dubbs

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.