FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor


 
 
LinkBack Thread Tools
 
Old 12-16-2011, 01:21 PM
Ian Campbell
 
Default

On Fri, 2011-12-16 at 07:06 -0700, Tim Gardner wrote:
> On 12/16/2011 01:27 AM, Ian Campbell wrote:
> > On Thu, 2011-12-15 at 20:39 -0700, Tim Gardner wrote:
> >> On 12/14/2011 11:18 PM, Ben Hutchings wrote:
> >>> Xen performance kernel patches backported to 3.2 for Precise
> >>
> >> I'm still kind of waiting on these. Stefan Bader had some concerns and
> >> encouraged Citrix to work on getting them upstream, but I haven't seen a
> >> lot of movement on them.
> >
> > Konrad (CCd) is working on upstreaming these patches. He posted to LKML
> > see "Exporting ACPI Pxx/Cxx states to other kernel
> > subsystems" (<1322673664-14642-1-git-send-email-konrad.wilk@oracle.com>)
> > on 30/11.
> >
> > The only comment I saw on that posting was from Jan. I saw a comment
> > from Stefan to ask why it hadn't been sent upstream which is what
> > reminded Konrad to send the post to LKML, were there others?
> >
> > Ian.
>
> I've seen no substantive comment since Konrad posted the patches, which
> is why I noted above that "I haven't seen a lot of movement on them".
> Maybe you should poke some upstream dudes, stir the pot a little.

Sure.

I'm also interested in the concerns which Stefan raised though -- I've
not seen them.

Ian.

--
Ian Campbell
Current Noise: Ufomammut - Ammonia

Nothing cures insomnia like the realization that it's time to get up.


--
To UNSUBSCRIBE, email to debian-kernel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 1324045279.20077.602.camel@zakaz.uk.xensource.com" >http://lists.debian.org/1324045279.20077.602.camel@zakaz.uk.xensource.com
 
Old 12-16-2011, 01:33 PM
Konrad Rzeszutek Wilk
 
Default

On Fri, Dec 16, 2011 at 07:06:59AM -0700, Tim Gardner wrote:
> On 12/16/2011 01:27 AM, Ian Campbell wrote:
> >On Thu, 2011-12-15 at 20:39 -0700, Tim Gardner wrote:
> >>On 12/14/2011 11:18 PM, Ben Hutchings wrote:
> >>>Xen performance kernel patches backported to 3.2 for Precise
> >>
> >>I'm still kind of waiting on these. Stefan Bader had some concerns and
> >>encouraged Citrix to work on getting them upstream, but I haven't seen a
> >>lot of movement on them.
> >
> >Konrad (CCd) is working on upstreaming these patches. He posted to LKML
> >see "Exporting ACPI Pxx/Cxx states to other kernel
> >subsystems" (<1322673664-14642-1-git-send-email-konrad.wilk@oracle.com>)
> >on 30/11.
> >
> >The only comment I saw on that posting was from Jan. I saw a comment
> >from Stefan to ask why it hadn't been sent upstream which is what
> >reminded Konrad to send the post to LKML, were there others?
> >
> >Ian.
>
> I've seen no substantive comment since Konrad posted the patches,
> which is why I noted above that "I haven't seen a lot of movement on
> them". Maybe you should poke some upstream dudes, stir the pot a
> little.

<laughs>Witches brew, eh?

I think a big part of this is that Rafael, Len, and Matthew are all
focused on the ACPI v5.0 drop. Which is suppose to happen _now_ so they are
busy trying to make sure it works without disaster.

Either way, I've some ideas on "stirring the pot" some more so let
send an email out.


--
To UNSUBSCRIBE, email to debian-kernel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 20111216143319.GC31755@phenom.dumpdata.com">http://lists.debian.org/20111216143319.GC31755@phenom.dumpdata.com
 
Old 12-16-2011, 02:51 PM
Svante Signell
 
Default

On Fri, 2011-12-16 at 14:20 +0000, Ian Jackson wrote:
> Svante Signell writes ("Re: [Fwd: [ISC-Bugs #25979] What happened to the dhcp patch in ISC-Bugs #24697 (Debian Bug #616290)?]"):
> > On Thu, 2011-12-15 at 14:15 +0000, Ian Jackson wrote:
> > > Where can I find the detailed explanation of why this patch is
> > > required and how it works to fix the problems ? At the moment I can't
> > > even seem to find an error message from an FTBFS log.
>
> This was really my key question.

Looks like there is no old FTBFS build log, but since the build will
fail due to PATH_MAX issues, why is a failed build log so important?

Since the patch was created this package was built using the patch in
Debian bug #616290 and is available in debian-ports since March 2011.
That is the reason for not queuing this package to the buildds, it would
be a waste of time. Please refer to Samuel Thibault, he is the buildd
admin, also a DM and DD. I am neither!

> Any submission of a patch allegedly fixing a bug (by which I mean to
> include a portability problem), to any project, should include a clear
> description, in detail, of what the bug is thought to be and how the
> patch solves it.

I wrote in parts of my previous mail (which you removed) about the two
issues: PATH_MAX and lpf.c. And PATH_MAX is not only a problem with this
package!

> > More information can be found at the debian-hurd and bug-hurd ML
> > archives:
> >
> > http://lists.gnu.org/archive/html/bug-hurd/2011-02/threads.html
> > http://lists.gnu.org/archive/html/bug-hurd/2011-03/threads.html
>
> A reference to a mailing list thread may helpful as background
> reading, but I'm afraid it does not meet the standard I would expect
> for a patch submission.

You asked for more information, and it is there. It is also available
from the debian-hurd mailing list. I cannot rewrite history, can I?

Are there any rules for what to include in a patch? I've never seen one.

> I'm afraid you need to go back and revise your submissions to isc-dhcp
> upstream. You need to:
> * Identify what the separate problems are
>

Note: I have not submitted any patch to upstream ISC-DHCP, read the bug
log! Neither has Samuel, all communication was via the DM in this bug
report! The patch was submitted upstream by the Debian Maintainer,
Andrew Pollock.

> * For each individual problem:
> - Research applicable best practices and standards

Done already!

> - Decide accordingly whether the fault lies with isc-dhcp or hurd

See above, PATH_MAX and lpf.c!

> - Decide how to fix the problem

The patch is already there! It could be revised if upstream had any
interest in communicating, either with the patch submitters or the DM.

> - Create and test a separate patch, either against isc-dhcpd or
> hurd or perhaps both

There is no patch against Hurd, only against isc-dhcp!

> - Write a clear and detailed explanation; this explanation
> should cover all of the matters I've just mentioned.

We will do that (in addition to the previous mail) if upstream was
interested in communicating.

> So far our (Debian's) communications with dhcpd upstream on this topic
> seem to be lacking in this area. If you like I would be happy to
> review your next submissiosn to upstream, before you send them.

As said before: _ALL_(the very limited) communication with upstream has
been via the DM, and the Debian bug. There has been _no_ submission
upstream of _any_ patches, either by me or Samuel. And the DM is Andrew
Pollock, at least this is what the package webpage says. Who are in the
Debian ISC DHCP Maintainers group I don't have any idea, where is that
found?

I think Samuel should reply on this matter, I just happen to be the
person submitting the bug report. And I am very grateful for his help in
creating the patch to make isc-dhcp working for GNU/Hurd. Otherwise we
would not have come as far as we have on the Debian-Installer port for
GNU/Hurd.


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 1324050688.12680.152.camel@s1499.it.kth.se">http://lists.debian.org/1324050688.12680.152.camel@s1499.it.kth.se
 
Old 12-16-2011, 03:27 PM
Ben Hutchings
 
Default

On Fri, 2011-12-16 at 14:31 +0100, Adam Borowski wrote:
> On Fri, Dec 16, 2011 at 12:41:39AM +0000, Ben Hutchings wrote:
> > On Fri, 2011-12-16 at 00:15 +0000, brian m. carlson wrote:
> > > Hurd doesn't support PATH_MAX. So trying to allocate memory based on
> > > PATH_MAX isn't going to work on Hurd. However, with glibc (and with
> > > POSIX 1003.1-2008) we can simply mark the destination buffer to realpath
> > > as NULL and the appropriate amount of memory will be automatically
> > > allocated. Not all systems support this, though.
> > >
> > > I cannot comment on the remainder of the patch, but the PATH_MAX issue
> > > is a pretty common one for Hurd, and assuming PATH_MAX is a compile-time
> > > constant is a bad idea anyway, since it's not allowed by POSIX.
> >
> > Indeed, for any system with an extensible VFS it makes a lot more sense
> > to implement only pathconf() than to specify a constant value that
> > covers all possible filesystems.
>
> Except there is no reasonable value pathconf() can return as well. It can
> either say the truth which is typically (size_t)(-1), or return some made up
> value.
[...]

Yeah, you're right. It's NAME_MAX that can generally be specified
per-volume but not globally.

Ben.

--
Ben Hutchings
Computers are not intelligent. They only think they are.
 
Old 12-16-2011, 05:10 PM
Ian Jackson
 
Default

Svante Signell writes ("Re: [Fwd: [ISC-Bugs #25979] What happened to the dhcp patch in ISC-Bugs #24697 (Debian Bug #616290)?]"):
> [ stuff ]

It looks like I'm not expressing myself well enough. Or at any rate,
I'm not getting through. Perhaps someone else would like to try to
explain ?

I'll have one more go:

> Please refer to Samuel Thibault, he is the buildd
> admin, also a DM and DD. I am neither!
...
> Note: I have not submitted any patch to upstream ISC-DHCP, read the bug
> log! Neither has Samuel, all communication was via the DM in this bug
> report! The patch was submitted upstream by the Debian Maintainer,
> Andrew Pollock.

By "you" I meant "the people in Debian who are trying to get this
problem fixed". That might include you personally (I guess you are a
hurd porter?) but it also includes the various DMs, sponsors, etc.

> You asked for more information, and it is there. It is also available
> from the debian-hurd mailing list. I cannot rewrite history, can I?

You can summarise and digest it. An upstream developer does not want
to read a long mailing list thread; they need a clear and integrated
summary of the situation.

> > Any submission of a patch allegedly fixing a bug (by which I mean to
> > include a portability problem), to any project, should include a clear
> > description, in detail, of what the bug is thought to be and how the
> > patch solves it.
>
> I wrote in parts of my previous mail (which you removed) about the two
> issues: PATH_MAX and lpf.c. And PATH_MAX is not only a problem with this
> package!

Reading between the lines I think you mean "hurd does not supply a
definition of PATH_MAX and isc-dhcp relies on PATH_MAX being defined".

But you aren't saying that. Instead you're just waving your arms
vigorously and shouting the single word "PATH_MAX" louder and louder.
For example, you haven't explained why you think it is the fault of
isc-dhcp for wanting PATH_MAX rather than the fault of hurd for not
providing it.

(I agree that PATH_MAX is a bad interface but I would be inclined
simply to #define it as 4096 and be done with it.)

I have no idea what you are referring to when you say "lpf.c". Your
patch submission need to explain things to someone who is unfamiliar
with the background (for example, a submissionn to isc-dhcp should
not assume that the reader knows anything much about Hurd or Debian)
and be complete and comprehensible. Evidently you don't have such a
summary or I guess you would have pasted into your emails here. But
you (collectively) need to write one.

> > - Decide how to fix the problem
>
> The patch is already there! It could be revised if upstream had any
> interest in communicating, either with the patch submitters or the DM.

I'm afraid that my opinion is that upstream's failure to engage
here is entirely understandable.

> > A reference to a mailing list thread may helpful as background
> > reading, but I'm afraid it does not meet the standard I would expect
> > for a patch submission.
>
> Are there any rules for what to include in a patch? I've never seen one.

Many projects have their own documents, but the general principles are
the same across many free software projects.

Ian.


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 20203.35218.410765.960163@chiark.greenend.org.uk"> http://lists.debian.org/20203.35218.410765.960163@chiark.greenend.org.uk
 
Old 12-16-2011, 05:12 PM
Ian Jackson
 
Default

Russ Allbery writes ("Re: [Fwd: [ISC-Bugs #25979] What happened to the dhcp patch in ISC-Bugs #24697 (Debian Bug #616290)?]"):
> I haven't looked at the patch in this thread, but most of the time that
> I've seen PATH_MAX used in software, it's indicated a design flaw in an
> interface: use of static buffers for file paths rather than adjusting to
> arbitrary length of file names. You can arguably "fix" it by defining
> PATH_MAX to something arbitrary, but usually the better fix is to go back
> and fix the incorrect choice of API to use a caller-provided buffer or to
> do memory allocation instead.

Indeed so. But if upstream won't take the memory allocation patch
then a "big enough" #define is surely better than not having a dhcp
client.

Ian.


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 20203.35334.662797.400729@chiark.greenend.org.uk"> http://lists.debian.org/20203.35334.662797.400729@chiark.greenend.org.uk
 
Old 12-16-2011, 05:46 PM
 
Default

On Dec 16, Ian Jackson <ijackson@chiark.greenend.org.uk> wrote:

> Indeed so. But if upstream won't take the memory allocation patch
> then a "big enough" #define is surely better than not having a dhcp
> client.
If Hurd developers would suddenly start to act pragmatically, then
they may suddenly question what they are doing with their life. :-)

--
ciao,
Marco
 
Old 12-16-2011, 06:13 PM
Svante Signell
 
Default

On Fri, 2011-12-16 at 19:46 +0100, Marco d'Itri wrote:
> On Dec 16, Ian Jackson <ijackson@chiark.greenend.org.uk> wrote:
>
> > Indeed so. But if upstream won't take the memory allocation patch
> > then a "big enough" #define is surely better than not having a dhcp
> > client.
> If Hurd developers would suddenly start to act pragmatically, then
> they may suddenly question what they are doing with their life. :-)

Defining PATH_MAX as a temporary workaround would sometimes be OK for
Debian packages, but definitely not for GNU/Hurd. I'm not an advocate of
this decision, you have to get explanations from the core developers.
One recent message about this issue is from Guillem Jover:

http://lists.debian.org/debian-hurd/2011/12/msg00044.html


That PATH_MAX is not a POSIX defined constant is a fact, no doubt :-)

rsyslog upstream has already adjusted their code to avoid using
PATH_MAX, and even solved two error conditions by doing this, and
resulting in less code (the message does not seem to be in the
debian-hurd archives yet but here is a reply):

http://lists.debian.org/debian-hurd/2011/12/msg00048.html


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 1324062830.12680.164.camel@s1499.it.kth.se">http://lists.debian.org/1324062830.12680.164.camel@s1499.it.kth.se
 
Old 12-17-2011, 08:07 AM
Arch Website Notification
 
Default

=== Signoff report for [community-testing] ===
https://www.archlinux.org/packages/signoffs/

There are currently:
* 0 new packages in last 24 hours
* 0 known bad packages
* 0 packages not accepting signoffs
* 2 fully signed off packages
* 8 packages missing signoffs
* 8 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.)



== Incomplete signoffs for [community] (6 total) ==

* fail2ban-0.8.4-4 (any)
1/2 signoffs
* expac-0.07-1 (i686)
0/2 signoffs
* lilypond-2.14.2-3 (i686)
0/2 signoffs
* packagekit-0.6.19-3 (i686)
0/2 signoffs
* lilypond-2.14.2-3 (x86_64)
1/2 signoffs
* packagekit-0.6.19-3 (x86_64)
1/2 signoffs

== Incomplete signoffs for [unknown] (2 total) ==

* percona-server-5.5.17_rel22.1-1 (i686)
0/2 signoffs
* percona-server-5.5.17_rel22.1-1 (x86_64)
1/2 signoffs


== Completed signoffs (2 total) ==

* pacman-contrib-4.0.1-1 (any)
* expac-0.07-1 (x86_64)


== All packages in [community-testing] for more than 14 days (8 total) ==

* expac-0.07-1 (i686), since 2011-10-13
* expac-0.07-1 (x86_64), since 2011-10-13
* pacman-contrib-4.0.1-1 (any), since 2011-11-25
* percona-server-5.5.17_rel22.1-1 (i686), since 2011-11-27
* percona-server-5.5.17_rel22.1-1 (x86_64), since 2011-11-27
* fail2ban-0.8.4-4 (any), since 2011-11-30
* packagekit-0.6.19-3 (i686), since 2011-11-30
* packagekit-0.6.19-3 (x86_64), since 2011-11-30


== Top five in signoffs in last 24 hours ==

1. tomegun - 2 signoffs
 
Old 12-17-2011, 08:07 AM
Arch Website Notification
 
Default

=== Signoff report for [testing] ===
https://www.archlinux.org/packages/signoffs/

There are currently:
* 0 new packages in last 24 hours
* 0 known bad packages
* 0 packages not accepting signoffs
* 9 fully signed off packages
* 28 packages missing signoffs
* 7 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.)



== Incomplete signoffs for [core] (6 total) ==

* ca-certificates-20111211-1 (any)
0/2 signoffs
* initscripts-2011.12.1-1 (any)
3/6 signoffs
* nilfs-utils-2.1.0-1 (i686)
0/2 signoffs
* openldap-2.4.28-1 (i686)
0/2 signoffs
* nilfs-utils-2.1.0-1 (x86_64)
0/2 signoffs
* openldap-2.4.28-1 (x86_64)
0/2 signoffs

== Incomplete signoffs for [extra] (22 total) ==

* texlive-bibtexextra-2011.24688-1 (any)
1/2 signoffs
* texlive-games-2011.24714-1 (any)
0/2 signoffs
* texlive-genericextra-2011.24609-1 (any)
0/2 signoffs
* texlive-htmlxml-2011.24013-1 (any)
0/2 signoffs
* texlive-humanities-2011.24631-1 (any)
0/2 signoffs
* texlive-langcjk-2011.24689-1 (any)
0/2 signoffs
* texlive-langcyrillic-2011.24029-1 (any)
0/2 signoffs
* texlive-langextra-2011.23959-1 (any)
0/2 signoffs
* texlive-langgreek-2011.24147-1 (any)
0/2 signoffs
* texlive-music-2011.24518-1 (any)
0/2 signoffs
* texlive-pictures-2011.24715-1 (any)
1/2 signoffs
* texlive-plainextra-2011.23567-1 (any)
0/2 signoffs
* texlive-pstricks-2011.24695-1 (any)
0/2 signoffs
* texlive-publishers-2011.24723-1 (any)
0/2 signoffs
* fontforge-20111214-1 (i686)
0/2 signoffs
* ghc-7.2.2-1 (i686)
1/2 signoffs
* texlive-bin-2011.3-1 (i686)
0/2 signoffs
* twisted-11.1.0-1 (i686)
0/2 signoffs
* fontforge-20111214-1 (x86_64)
1/2 signoffs
* ghc-7.2.2-1 (x86_64)
1/2 signoffs
* texlive-bin-2011.3-1 (x86_64)
1/2 signoffs
* twisted-11.1.0-1 (x86_64)
0/2 signoffs


== Completed signoffs (9 total) ==

* pacman-4.0.1-1 (i686)
* pacman-4.0.1-1 (x86_64)
* namcap-3.2.1-1 (any)
* texlive-core-2011.24722-1 (any)
* texlive-fontsextra-2011.24706-1 (any)
* texlive-latexextra-2011.24718-1 (any)
* texlive-science-2011.24724-1 (any)
* pyalpm-0.5.3-1 (i686)
* pyalpm-0.5.3-1 (x86_64)


== All packages in [testing] for more than 14 days (7 total) ==

* pyalpm-0.5.3-1 (i686), since 2011-10-15
* pyalpm-0.5.3-1 (x86_64), since 2011-10-15
* namcap-3.2.1-1 (any), since 2011-10-20
* ghc-7.2.2-1 (i686), since 2011-11-19
* ghc-7.2.2-1 (x86_64), since 2011-11-19
* pacman-4.0.1-1 (i686), since 2011-11-21
* pacman-4.0.1-1 (x86_64), since 2011-11-21


== Top five in signoffs in last 24 hours ==

1. tomegun - 2 signoffs
 

Thread Tools




All times are GMT. The time now is 07:02 PM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright 2007 - 2008, www.linux-archive.org