Re: xattr.h wonkiness
Quoting Carlos O'Donell (car...@systemhalted.org): > On Fri, Mar 7, 2014 at 12:31 AM, Serge Hallyn wrote: > > Quoting Carlos O'Donell (car...@systemhalted.org): > >> On Thu, Mar 6, 2014 at 6:06 PM, Serge Hallyn > >> wrote: > >> > Quoting Carlos O'Donell (car...@systemhalted.org): > >> >> On Fri, Feb 21, 2014 at 6:42 PM, Serge Hallyn > >> >> wrote: > >> >> > Hi, would a simple patchl ike this to misc/sys/xattr.h be > >> >> > acceptable? This showed up in a failure to build (of at least > >> >> > qemu, and aiui lots of other pkgs) after merging a new libcap2 > >> >> > where sys/capability.h #included linux/xattr.h. It's being > >> >> > worked around by patching libcap2 to #include sys/xattr.h > >> >> > first, but presumably this will cause other breakages. > >> >> > >> >> Please follow the accepted practice for fixing coordination between > >> >> userspace and Linux kernel headers. > >> >> > >> >> Upstream glibc and the Linux kernel have already worked out a > >> >> mechanical solution to this problem, and we need people to work out > >> >> the patches and post them upstream. > >> >> > >> >> The solution is to coordinate the conflicting headers following this > >> >> template: > >> >> https://sourceware.org/glibc/wiki/Synchronizing_Headers > >> > > >> > Thanks for the information. I tested the two patches at > >> > http://people.canonical.com/~serge/xattr-kernel-libc-fix/ and they > >> > seem to do the right thing. I'll send them out if they look ok. > >> > >> Let me warn you that the glibc patch won't get accepted as-is. > >> > >> You are adding a #ifdef for a Linux-specific define in OS-agnostic code. > >> > >> Look at: https://sourceware.org/ml/libc-alpha/2013-08/msg00209.html > >> > >> See how we adjust a Linux-specific header to define an OS-agnostic > >> variable to use in the OS-agnostic code e.g. __USE_FOO. > > > > There isn't currently a bits/xattr.h file. Would it be preferred that > > I create one, or that I just set __USE_KERNEL_XATTR_DEFS in the > > linux kernel header? > > I don't know, you'll have to take a stab at an implementation and see > what upstream likes. > > I haven't reviewed this thoroughly so I can't comment yet. Ah ok, thanks. I'll just start with the kernel patch then, with the define in there. thanks, -serge -- To UNSUBSCRIBE, email to debian-glibc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140307055128.GA20460@sergelap
Re: xattr.h wonkiness
Quoting Carlos O'Donell (car...@systemhalted.org): > On Thu, Mar 6, 2014 at 6:06 PM, Serge Hallyn wrote: > > Quoting Carlos O'Donell (car...@systemhalted.org): > >> On Fri, Feb 21, 2014 at 6:42 PM, Serge Hallyn > >> wrote: > >> > Hi, would a simple patchl ike this to misc/sys/xattr.h be > >> > acceptable? This showed up in a failure to build (of at least > >> > qemu, and aiui lots of other pkgs) after merging a new libcap2 > >> > where sys/capability.h #included linux/xattr.h. It's being > >> > worked around by patching libcap2 to #include sys/xattr.h > >> > first, but presumably this will cause other breakages. > >> > >> Please follow the accepted practice for fixing coordination between > >> userspace and Linux kernel headers. > >> > >> Upstream glibc and the Linux kernel have already worked out a > >> mechanical solution to this problem, and we need people to work out > >> the patches and post them upstream. > >> > >> The solution is to coordinate the conflicting headers following this > >> template: > >> https://sourceware.org/glibc/wiki/Synchronizing_Headers > > > > Thanks for the information. I tested the two patches at > > http://people.canonical.com/~serge/xattr-kernel-libc-fix/ and they > > seem to do the right thing. I'll send them out if they look ok. > > Let me warn you that the glibc patch won't get accepted as-is. > > You are adding a #ifdef for a Linux-specific define in OS-agnostic code. > > Look at: https://sourceware.org/ml/libc-alpha/2013-08/msg00209.html > > See how we adjust a Linux-specific header to define an OS-agnostic > variable to use in the OS-agnostic code e.g. __USE_FOO. There isn't currently a bits/xattr.h file. Would it be preferred that I create one, or that I just set __USE_KERNEL_XATTR_DEFS in the linux kernel header? -serge -- To UNSUBSCRIBE, email to debian-glibc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140307053111.GA17475@sergelap
Re: xattr.h wonkiness
On Fri, Mar 7, 2014 at 12:31 AM, Serge Hallyn wrote: > Quoting Carlos O'Donell (car...@systemhalted.org): >> On Thu, Mar 6, 2014 at 6:06 PM, Serge Hallyn wrote: >> > Quoting Carlos O'Donell (car...@systemhalted.org): >> >> On Fri, Feb 21, 2014 at 6:42 PM, Serge Hallyn >> >> wrote: >> >> > Hi, would a simple patchl ike this to misc/sys/xattr.h be >> >> > acceptable? This showed up in a failure to build (of at least >> >> > qemu, and aiui lots of other pkgs) after merging a new libcap2 >> >> > where sys/capability.h #included linux/xattr.h. It's being >> >> > worked around by patching libcap2 to #include sys/xattr.h >> >> > first, but presumably this will cause other breakages. >> >> >> >> Please follow the accepted practice for fixing coordination between >> >> userspace and Linux kernel headers. >> >> >> >> Upstream glibc and the Linux kernel have already worked out a >> >> mechanical solution to this problem, and we need people to work out >> >> the patches and post them upstream. >> >> >> >> The solution is to coordinate the conflicting headers following this >> >> template: >> >> https://sourceware.org/glibc/wiki/Synchronizing_Headers >> > >> > Thanks for the information. I tested the two patches at >> > http://people.canonical.com/~serge/xattr-kernel-libc-fix/ and they >> > seem to do the right thing. I'll send them out if they look ok. >> >> Let me warn you that the glibc patch won't get accepted as-is. >> >> You are adding a #ifdef for a Linux-specific define in OS-agnostic code. >> >> Look at: https://sourceware.org/ml/libc-alpha/2013-08/msg00209.html >> >> See how we adjust a Linux-specific header to define an OS-agnostic >> variable to use in the OS-agnostic code e.g. __USE_FOO. > > There isn't currently a bits/xattr.h file. Would it be preferred that > I create one, or that I just set __USE_KERNEL_XATTR_DEFS in the > linux kernel header? I don't know, you'll have to take a stab at an implementation and see what upstream likes. I haven't reviewed this thoroughly so I can't comment yet. Cheers, Carlos. -- To UNSUBSCRIBE, email to debian-glibc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/CAE2sS1ii2=2z7bg3xzxsfc5oq-ms9josgk3gyujlvzvyzww...@mail.gmail.com
eglibc_2.18-4_arm64.changes ACCEPTED
Maintainer: GNU Libc Maintainers Uploader: buildd autosigning key turfan Host: leda.debian.net Accepted: eglibc_2.18-4_arm64.changes Files: libc6_2.18-4_arm64.deb libc6-dev_2.18-4_arm64.deb libc6-pic_2.18-4_arm64.deb libc-bin_2.18-4_arm64.deb libc-dev-bin_2.18-4_arm64.deb multiarch-support_2.18-4_arm64.deb libc6-prof_2.18-4_arm64.deb locales-all_2.18-4_arm64.deb nscd_2.18-4_arm64.deb libc6-dbg_2.18-4_arm64.deb libc6-udeb_2.18-4_arm64.udeb libnss-dns-udeb_2.18-4_arm64.udeb libnss-files-udeb_2.18-4_arm64.udeb -- To UNSUBSCRIBE, email to debian-glibc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/e1wlldo-0001dm...@leda.debian.net
Re: xattr.h wonkiness
Quoting Carlos O'Donell (car...@systemhalted.org): > On Thu, Mar 6, 2014 at 6:06 PM, Serge Hallyn wrote: > > Quoting Carlos O'Donell (car...@systemhalted.org): > >> On Fri, Feb 21, 2014 at 6:42 PM, Serge Hallyn > >> wrote: > >> > Hi, would a simple patchl ike this to misc/sys/xattr.h be > >> > acceptable? This showed up in a failure to build (of at least > >> > qemu, and aiui lots of other pkgs) after merging a new libcap2 > >> > where sys/capability.h #included linux/xattr.h. It's being > >> > worked around by patching libcap2 to #include sys/xattr.h > >> > first, but presumably this will cause other breakages. > >> > >> Please follow the accepted practice for fixing coordination between > >> userspace and Linux kernel headers. > >> > >> Upstream glibc and the Linux kernel have already worked out a > >> mechanical solution to this problem, and we need people to work out > >> the patches and post them upstream. > >> > >> The solution is to coordinate the conflicting headers following this > >> template: > >> https://sourceware.org/glibc/wiki/Synchronizing_Headers > > > > Thanks for the information. I tested the two patches at > > http://people.canonical.com/~serge/xattr-kernel-libc-fix/ and they > > seem to do the right thing. I'll send them out if they look ok. > > Let me warn you that the glibc patch won't get accepted as-is. > > You are adding a #ifdef for a Linux-specific define in OS-agnostic code. > > Look at: https://sourceware.org/ml/libc-alpha/2013-08/msg00209.html Yeah I had noticed that that patch (part of the linux part of which was reverted :) used __USE_KERNEL_*, but I didn't see where that was defined, and https://sourceware.org/glibc/wiki/Synchronizing_Headers specifically said to use #if !__UAPI*. No biggie, if I'm otherwise on the right track, I'll change that before submitting. thanks, -serge > See how we adjust a Linux-specific header to define an OS-agnostic > variable to use in the OS-agnostic code e.g. __USE_FOO. > > Cheers, > Carlos. -- To UNSUBSCRIBE, email to debian-glibc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140307032253.GA4605@sergelap
Re: xattr.h wonkiness
On Thu, Mar 6, 2014 at 6:06 PM, Serge Hallyn wrote: > Quoting Carlos O'Donell (car...@systemhalted.org): >> On Fri, Feb 21, 2014 at 6:42 PM, Serge Hallyn >> wrote: >> > Hi, would a simple patchl ike this to misc/sys/xattr.h be >> > acceptable? This showed up in a failure to build (of at least >> > qemu, and aiui lots of other pkgs) after merging a new libcap2 >> > where sys/capability.h #included linux/xattr.h. It's being >> > worked around by patching libcap2 to #include sys/xattr.h >> > first, but presumably this will cause other breakages. >> >> Please follow the accepted practice for fixing coordination between >> userspace and Linux kernel headers. >> >> Upstream glibc and the Linux kernel have already worked out a >> mechanical solution to this problem, and we need people to work out >> the patches and post them upstream. >> >> The solution is to coordinate the conflicting headers following this >> template: >> https://sourceware.org/glibc/wiki/Synchronizing_Headers > > Thanks for the information. I tested the two patches at > http://people.canonical.com/~serge/xattr-kernel-libc-fix/ and they > seem to do the right thing. I'll send them out if they look ok. Let me warn you that the glibc patch won't get accepted as-is. You are adding a #ifdef for a Linux-specific define in OS-agnostic code. Look at: https://sourceware.org/ml/libc-alpha/2013-08/msg00209.html See how we adjust a Linux-specific header to define an OS-agnostic variable to use in the OS-agnostic code e.g. __USE_FOO. Cheers, Carlos. -- To UNSUBSCRIBE, email to debian-glibc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/cae2ss1ibiaanwbwqhadmzqg_-1ukeg74ndozc_6ygvm2gou...@mail.gmail.com
Re: xattr.h wonkiness
Quoting Carlos O'Donell (car...@systemhalted.org): > On Fri, Feb 21, 2014 at 6:42 PM, Serge Hallyn wrote: > > Hi, would a simple patchl ike this to misc/sys/xattr.h be > > acceptable? This showed up in a failure to build (of at least > > qemu, and aiui lots of other pkgs) after merging a new libcap2 > > where sys/capability.h #included linux/xattr.h. It's being > > worked around by patching libcap2 to #include sys/xattr.h > > first, but presumably this will cause other breakages. > > Please follow the accepted practice for fixing coordination between > userspace and Linux kernel headers. > > Upstream glibc and the Linux kernel have already worked out a > mechanical solution to this problem, and we need people to work out > the patches and post them upstream. > > The solution is to coordinate the conflicting headers following this template: > https://sourceware.org/glibc/wiki/Synchronizing_Headers Thanks for the information. I tested the two patches at http://people.canonical.com/~serge/xattr-kernel-libc-fix/ and they seem to do the right thing. I'll send them out if they look ok. thanks, -serge -- To UNSUBSCRIBE, email to debian-glibc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140306230616.GA31170@ac100
Bug#740973: sprof(1): Some typographical changes in the manual
Package: libc-dev-bin
Version: 2.17-97
Severity: minor
Tags: patch
Dear Maintainer,
* What led up to the situation?
Testing a man page
* What exactly did you do (or not do) that was effective (or
ineffective)?
groff -b -e -mandoc -t -z -ww < sprof.1
* What was the outcome of this action?
:46: warning: macro `Tr' not defined
:95: warning: number register `F' not defined
:223: warning: macro `IX' not defined
Input file is sprof.1 (/usr/share/man/man1/sprof.1.gz)
* What outcome did you expect instead?
No warnings
It looks like the manual was created by using pod2man. Latest version
of that program should be used as it corrects some constructs causing
groff to issue warnings.
Changes:
String "Tr" defined for groff
Character \(bv (bold (big) vertical?), translated from |, is displayed by
"man" as a question mark. Therefore only used in "troff" output.
Space at end of line removed
Register F and macro IX defined for groff
-- changed to \-\- if it means an option
Patch:
--- sprof.1 2013-11-29 19:31:48.0 +
+++ sprof.1.new 2014-03-02 21:53:45.0 +
@@ -40,7 +40,12 @@
.\" string Tr holds user defined translation string.
.\" Bell System Logo is used as a dummy character.
.\"
-.tr \(*W-|\(bv\*(Tr
+.\" Avoid warning from groff about undefined string
+.if \n(.g \{\
+. if !dTr .ds Tr
+.\}
+.ie t .tr \(*W-|\(bv\*(Tr
+.el .tr \(*W-\*(Tr
.ie n \{\
.ds -- \(*W-
.ds PI pi
@@ -82,13 +87,19 @@
'br\}
.\"If the F register is turned on, we'll generate
.\"index entries out stderr for the following things:
-.\"TH Title
+.\"TH Title
.\"SH Header
-.\"Sh Subsection
+.\"Sh Subsection
.\"Ip Item
.\"X<> Xref (embedded
.\"Of course, you have to process the output yourself
.\"in some meaningful fashion.
+.\" Avoid warning from groff about undefined register and macro
+. de IX
+..
+.if \n(.g \{\
+. if !rF . nr F 0
+.\}
.if \nF \{
.de IX
.tm Index:\\$1\t\\n%\t"\\$2"
@@ -195,17 +206,17 @@ sprof \- Read and display shared object
.SH "SYNOPSIS"
\fBsprof\fR \fB\-p\fR|\fB\-c\fR [\fB\-q\fR]
.SH "DESCRIPTION"
-\fB--call-pairs\fR, \fB\-c\fR
+\fB\-\-call-pairs\fR, \fB\-c\fR
.PP
.Vb 1
\&print list of count paths and their number of use
.Ve
-\fB--flat-profile\fR, \fB\-p\fR
+\fB\-\-flat-profile\fR, \fB\-p\fR
.PP
.Vb 1
\&generate flat profile with counts and ticks
.Ve
-\fB--graph\fR, \fB\-q\fR
+\fB\-\-graph\fR, \fB\-q\fR
.PP
.Vb 1
\&generate call graph
-- System Information:
Debian Release: jessie/sid
APT prefers stable-updates
APT policy: (500, 'stable-updates'), (500, 'proposed-updates'), (500,
'testing'), (500, 'stable')
Architecture: i386 (i586)
Kernel: Linux 3.2.53-rt75-1
Locale: LANG=is_IS, LC_CTYPE=is_IS (charmap=ISO-8859-1)
Shell: /bin/sh linked to /bin/dash
Versions of packages libc-dev-bin depends on:
ii libc6 2.17-97
Versions of packages libc-dev-bin recommends:
ii manpages-dev 3.58-1
libc-dev-bin suggests no packages.
-- no debconf information
--
Bjarni I. Gislason
--
To UNSUBSCRIBE, email to debian-glibc-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20140306192509.ga8...@rhi.hi.is
Bike Week Starts Here at Space Coast Harley-Davidson!
View this message in a browser. http://archives.subscribermail.com/msg/e06249d1cc5c4fa4a8bceb6f30de375e.htm To view this message in a browser. Copy and Paste the following URL in your web address bar: http://www.spacecoastharley.com/default.asp?page=e-blast Unsubscribe or update your email preferences. http://app.subscribermail.com/unsub.cfm?tempid=e06249d1cc5c4fa4a8bceb6f30de375e&mailid=f64f163398fe47f0a3a5eb6f30de375e Powered by SubscriberMail http://www.subscribermail.com 1440 Sportsman Lane NE | Palm Bay, FL 32905
