=== Signoff report for [testing] ===
https://www.archlinux.org/packages/signoffs/
There are currently:
* 15 new packages in last 24 hours
* 0 known bad packages
* 0 packages not accepting signoffs
* 11 fully signed off packages
* 38 packages missing signoffs
* 0 packages older than 14 days
(Note: the word 'package' as used here refers to packages as grouped by
pkgbase, architecture, and repository; e.g., one PKGBUILD produces one
package per architecture, even if it is a split package.)
== New packages in [testing] in last 24 hours (15 total) ==
=== Signoff report for [community-testing] ===
https://www.archlinux.org/packages/signoffs/
There are currently:
* 23 new packages in last 24 hours
* 0 known bad packages
* 0 packages not accepting signoffs
* 0 fully signed off packages
* 24 packages missing signoffs
* 0 packages older than 14 days
(Note: the word 'package' as used here refers to packages as grouped by
pkgbase, architecture, and repository; e.g., one PKGBUILD produces one
package per architecture, even if it is a split package.)
== New packages in [community-testing] in last 24 hours (23 total) ==
Pablo Neira Ayuso discovered that avahi and
potentially NetworkManager accept spoofed Netlink messages because of a
kernel bug. The kernel passes all-zero SCM_CREDENTIALS ancillary data
to the receiver if the sender did not provide such data, instead of not
including any such data at all or including the correct data from the
peer (as it is the case with AF_UNIX).
This bug was introduced in commit 16e572626961
(af_unix: dont send SCM_CREDENTIALS by default)
This patch forces passing credentials for netlink, as
before the regression.
Another fix would be to not add SCM_CREDENTIALS in
netlink messages if not provided by the sender, but it
might break some programs.
With help from Florian Weimer & Petr Matousek
This issue is designated as CVE-2012-3520
Signed-off-by: Eric Dumazet <edumazet@google.com>
Cc: Petr Matousek <pmatouse@redhat.com>
Cc: Florian Weimer <fweimer@redhat.com>
Cc: Pablo Neira Ayuso <pablo@netfilter.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
(cherry picked from commit e0e3cea46d31d23dc40df0a49a7a2c04fe8edfea)
--
kernel-team mailing list
kernel-team@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/kernel-team
09-18-2012, 03:14 AM
Oon-Ee Ng
On Tue, Sep 18, 2012 at 3:47 AM, Dave Reisner <d@falconindy.com> wrote:
> On Mon, Sep 17, 2012 at 09:38:30PM +0200, Robert Knauer wrote:
>> Hello,
>> please disown nvidia-pae[1], it's outdated for more than a month now
>> and I mailed the maintainer on 1st of September and got no answer.
>>
>> Thanks,
>> Robert
>>
>> [1] https://aur.archlinux.org/packages.php?ID=40101
>
> Don't take this personally... you're just the one who happened to bring
> it up. Do we _really_ need all this duplication? Does every kernel in
> the AUR needs its own _from_ _source_ instructions to build kernel
> modules? Really, these should all be about 3-4 lines to change in the
> extra/nvidia PKGBUILD. Instead, we have...
>
> nvidia-apparmor
> nvidia-bede
> nvidia-bfs
> nvidia-bl
> nvidia-ck
> nvidia-custom
> nvidia-fbcondecor
> nvidia-ice
> nvidia-ll
> nvidia-lqx
> nvidia-mainline
> nvidia-pae
> nvidia-pf
> nvidia-rifs
> nvidia-rt
> nvidia-uksm
> nvidia-zen
>
> I'm sure these are all unique and beautiful in their own way, but
> really, they're all duplicates as far as I'm concerned. nvidia is the
> biggest offender of this, but it certainly applies to other modules as
> well.
>
> </rant>
>
> dave
Firstly - full disclosure - I'm the author and maintainer of the
hackish nvidia-beta-all package (someone else based nvidia-all from
that). It basically builds the nvidia module for every exiting kernel
(including specific patches if needed).
When initially submitting the package there was some discussion about
whether such a PKGBUILD which is non-reproducable (would produce
different results on different machines) violates the AUR's
guidelines. The only alternative to that (if reproducability is
important) would be the various nvidia packages as we currently have.
Of course, I never really agreed with that line of reasoning simply
because as it is compiling any random package on two different
machines could produce different results due to autotools or similar.
09-18-2012, 08:07 AM
Arch Website Notification
=== Signoff report for [community-testing] ===
https://www.archlinux.org/packages/signoffs/
There are currently:
* 2 new packages in last 24 hours
* 0 known bad packages
* 0 packages not accepting signoffs
* 0 fully signed off packages
* 26 packages missing signoffs
* 0 packages older than 14 days
(Note: the word 'package' as used here refers to packages as grouped by
pkgbase, architecture, and repository; e.g., one PKGBUILD produces one
package per architecture, even if it is a split package.)
== New packages in [community-testing] in last 24 hours (2 total) ==
=== Signoff report for [testing] ===
https://www.archlinux.org/packages/signoffs/
There are currently:
* 6 new packages in last 24 hours
* 0 known bad packages
* 0 packages not accepting signoffs
* 11 fully signed off packages
* 34 packages missing signoffs
* 0 packages older than 14 days
(Note: the word 'package' as used here refers to packages as grouped by
pkgbase, architecture, and repository; e.g., one PKGBUILD produces one
package per architecture, even if it is a split package.)
== New packages in [testing] in last 24 hours (6 total) ==
Hi, I noticed I'm getting a [FAIL] message for SIGTERM on system
shutdown[0], how can I debug it? I already checked /var/log but found
nothing
[0] Some additional info: SIGKILL do the job (so the system
shutdowns/reboot after a few seconds) and on the next boot everything is
clean.
09-19-2012, 07:02 AM
Tom Gundersen
On Wed, Sep 19, 2012 at 6:56 AM, Martín Cigorraga <msx@archlinux.us> wrote:
> Hi, I noticed I'm getting a [FAIL] message for SIGTERM on system
> shutdown[0], how can I debug it? I already checked /var/log but found
> nothing
This means that some process did not terminate before the timeout
ended. To find out which, you could insert a call to "ps aux >
/root/my-processes" just after the SIGTERM in rc.shutdown.
-t
09-19-2012, 07:17 AM
Morris
On Wed, Sep 19, 2012 at 9:02 AM, Tom Gundersen <teg@jklm.no> wrote:
> On Wed, Sep 19, 2012 at 6:56 AM, Martín Cigorraga <msx@archlinux.us>
> wrote:
> > Hi, I noticed I'm getting a [FAIL] message for SIGTERM on system
> > shutdown[0], how can I debug it? I already checked /var/log but found
> > nothing
>
> This means that some process did not terminate before the timeout
> ended. To find out which, you could insert a call to "ps aux >
> /root/my-processes" just after the SIGTERM in rc.shutdown.
>
> -t
>
if you are using networkmanager, you could be affected by
https://bugs.archlinux.org/task/31115
Morris
09-19-2012, 07:17 AM
Lukas Jirkovsky
On 19 September 2012 09:02, Tom Gundersen <teg@jklm.no> wrote:
> On Wed, Sep 19, 2012 at 6:56 AM, Martín Cigorraga <msx@archlinux.us> wrote:
>> Hi, I noticed I'm getting a [FAIL] message for SIGTERM on system
>> shutdown[0], how can I debug it? I already checked /var/log but found
>> nothing
>
> This means that some process did not terminate before the timeout
> ended. To find out which, you could insert a call to "ps aux >
> /root/my-processes" just after the SIGTERM in rc.shutdown.
>
> -t
Just a minor correction: it is in /etc/rc.d/functions