Bug#631743: O: gdb -- The GNU Debugger
Package: wnpp Severity: normal I intend to orphan the gdb package. I will continue to intermittently follow upstream development, and upstream is pretty active; not a lot of Debian-local work is needed. There's a couple of local patches (bad Dan!) which could be submitted. Or possibly dropped with the latest upstream. Please, if you adopt this, also take gdb-doc; a script in the GDB source package produces DFSG sanitized source packages for both packages from the FSF release tarball. The package description is: GDB is a source-level debugger, capable of breaking programs at any specific line, displaying variable values, and determining where errors occurred. Currently, it works for C, C++, Fortran, Modula 2 and Java programs. A must-have for any serious programmer. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110626173730.23897.54084.reportbug@localhost
Re: Bug#560786: gdb: Please make the python dependency optional
On Sun, Jan 10, 2010 at 07:06:05PM +1030, Ron wrote: > > You've already said you don't have the space for GDB+Python. So file > > a wishlist bug to split gdbserver out to its own package, and I'll do > > that for you happily. > > I haven't seen anyone object to that idea yet, so we seem to have a > rough consensus that would be a good plan independently of any other > issues here, yeah. I'm working on this. I'll see what the build time costs of a gdb-minimal are at the same time (it's still pretty large). I still find your arguments unconvincing, but I may as well measure the cost of the compromise. > > Then you don't need to put the detached debug > > info files on your target either. If you are putting them on your > > target, well, that explains why you can't fit GDB! > > "If I didn't have all that data which was actually useful to me, then > I'd have plenty of space for whole subsystems I will never need ;?" > That's probably not the most productive argument we could entertain :) You can make strawman arguments at me as long as you want to. I'm quite familiar with resource-constrained systems - I work in the embedded industry. There are several ways to avoid keeping debug info files on your target system, and still recover traces or conduct debug sessions. At work, we advise all our customers to use stripped target filesystems. > Ok. If it's still needed, that's mostly what I was wondering. > Surely we can also do the "takes almost no additional buildd time" trick > with --without-python though, no? It looked like only a couple of files > would get touched by that at all. Did I miss something there? No, you have to reconfigure GDB from scratch to disable it. It's probably possible to change this, but it'd be fragile; I don't think it's a good idea. > The range of systems is however larger than what gdbserver is suitable > for, by its own description. Yes, it's a useful tool, for some problems, > but it's not a magic bullet, without any cost of its own. FYI, if you have any way to run GDB on your target, you have a way to run gdbserver. For instance, you can multiplex it over a single serial console. I agree there's complex setup involved. > I have a vague sense of what you are remembering, but common sense > should basically sum it up. Is there no way upstream would accept > doing this as a runtime plugin, that only gets used if it's there? I have no idea. It would be a big pain to implement. -- Daniel Jacobowitz CodeSourcery -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Bug#560786: gdb: Please make the python dependency optional
Picking some arbitrary messages in this thread to respond to. On Sun, Dec 20, 2009 at 03:30:20AM +1030, Ron wrote: > I do appreciate, and share, your concern for not bloating the archive > needlessly, but my concern is balancing that against the needs of small > Debian systems, where the extra deps this drags in are of themselves a > quite substantial and needless extra bloat. They are considerably larger > than gdb is itself, and needing to put extra flash on a board, just to > install python, which the board itself will never use, hits a much harder > limit than an extra 4MB package in the archive would. There is not just one GDB package in the archive. Many platforms have two, and the build logic is tricky enough to produce all the variants already... I really don't see the justification for another binary. You've already said you don't have the space for GDB+Python. So file a wishlist bug to split gdbserver out to its own package, and I'll do that for you happily. Then you don't need to put the detached debug info files on your target either. If you are putting them on your target, well, that explains why you can't fit GDB! > Ideally this should really be some sort of runtime dependency, otherwise > what happens when people also add perl, lua, ruby, etc. etc. bindings to > do the same thing as this python dep does? It's not going to happen. We (the GDB developers) spent a long time picking one language under the firm plan that we wanted exactly one. We don't want to fragment available GDB scripts by language; that defeats the point of making it scriptable. > - libgdb-dev appears to be unused, and itself recommends that it never >should be. That's the size of 2 gdb .debs itself, so if you really >want to remain "archive neutral", we could trade it for a gdb-minimal >package, and wind up using less archive space in the deal. It exists for the benefit of the Free Pascal IDE. Also, it takes almost no additional build daemon time. > I've cc'd -devel, as others may have even better or simpler solutions, > but I'd appreciate your guidance on the best way to move forward with > solving this from here. I just don't see why a solution to this is necessary in the archive. Nothing you've said has changed that. Either we install gdbserver, or else you can just throw a GDB binary around from system to system. I don't think the range of systems which don't need and can't fit Python, but can fit a GDB executable (and its substantial RAM requirements, and the huge debuginfo files it needs to be useful) is very large. Remote debugging is easy, and this is exactly what it's for. On Sun, Dec 20, 2009 at 11:45:00AM +0100, Eduard Bloch wrote: > And people who don't care shouldn't be forced against their will. I am not holding a gun to your head and making you install GDB. I don't think this is an appropriate description. Debian isn't in the business of providing every possible combination of configure options; there are some other distros with that philosophy. Didn't there used to be a statement in policy or the developer's reference that optional dependencies should generally be enabled, which had some special words about X11? I can't find it any more. > Why don't we provide a gdb-tiny package, in the same fashion as > vim-tiny? Or is the python support that much hardcoded into gdb source > now that it can never separated? It can be separated. -- Daniel Jacobowitz CodeSourcery -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Better tracebacks for C/C++ (and probably Ada & Fortran, too)
On Sun, Jul 26, 2009 at 12:42:46AM +0200, Florian Weimer wrote: > I've built a small proof-of-concept library which creates Java-style > tracebacks for C and C++ programs. In contrast to libc's backtrace() > function, it uses DWARF debugging information when available, so the > output is generally quite useful. Debugging information is extracted > from the main executable and any loaded DSOs, or from the shadow debug > tree in /usr/lib/debug. Can't you do this just by forking addr2line and providing a shim layer that knows shared library load offsets? That saves you the really grotty bits. -- Daniel Jacobowitz CodeSourcery -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Override changes standard -> optional
On Tue, Dec 30, 2008 at 10:48:04PM +, Neil Williams wrote: > I'd rather see strace and gdb leave Standard. If one has to stay, let > it *not* be gdb. > > It's not as if there is a gdb-tiny. Agreed. There could be a gdb-tiny - but it would still be about 3.5MB installed, as opposed to the 8MB+ that the main GDB package will grow to in Lenny+1. Still not small. It's a matter of stripping out the TUI, along with expat and Python support. I'm not planning to do that without a good reason. -- Daniel Jacobowitz CodeSourcery -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Policy or best practices for debug packages?
On Mon, Jul 07, 2008 at 06:45:23PM -0400, Theodore Tso wrote: > On Mon, Jul 07, 2008 at 06:16:22PM -0400, Daniel Jacobowitz wrote: > >For various reasons we don't use it at work - instead we added some GCC > >command line options to relocate the debug info at compile time. In > >the end, it comes down to the same result. > > Were these private hacks to GCC? I tried looking at the gcc info > file, and I didn't see any options to force the debug info to a > different pathname; maybe I missed it, or the info file I was looking > for was too out of date (gcc 4.1.3). The latter. They'll be in GCC 4.4. You can find -fdebug-prefix-map here: http://gcc.gnu.org/onlinedocs/gcc/Debugging-Options.html#Debugging-Options There are also some configure options for the bootstrapping problem, i.e. getting libgcc's debug info in the right place. -- Daniel Jacobowitz CodeSourcery -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Policy or best practices for debug packages?
On Mon, Jul 07, 2008 at 06:01:15PM -0400, Theodore Tso wrote: > On Mon, Jul 07, 2008 at 05:42:47PM -0400, Daniel Jacobowitz wrote: > > I think they do this, using "debugedit". We (CodeSourcery) do it for > > our libraries too. It's incredibly useful - but very spoiling; every > > time I'm without the automatic debug sources and source paths I get > > grumpy about it. > > > > Where can you find "debugedit"? I did a google search and it looks > like Gentoo as packaged it, and it looks like it might be an auxiliary > program inside the rpm source packages? Is that what you were > referring to? Yes, that's the one. For various reasons we don't use it at work - instead we added some GCC command line options to relocate the debug info at compile time. In the end, it comes down to the same result. > So in order to do this, we would need hack the debian/rules file to > create a -dbgsrc package which contains a copy of the source tree > after a successful build (but with all of the generated binary files > stripped out). We would also need to agree on a standardized location > where the *-dbgsrc files would install the source trees --- something > like /usr/lib/debug/usr/src, perhaps? And then we would need to use > the debugedit tool to edit the dbg files to point at the sources in > /usr/src/lib/usr/src (or where we decide to have the *-dbgsrc packages > install the source files). I think /usr/src/debian/ would be traditional. It really doesn't make a difference, though :-) -- Daniel Jacobowitz CodeSourcery -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Policy or best practices for debug packages?
On Mon, Jul 07, 2008 at 11:45:14PM +0200, Mike Hommey wrote: > On Mon, Jul 07, 2008 at 05:42:47PM -0400, Daniel Jacobowitz wrote: > > I wouldn't want them in the archive for everything, but it would be > > nice to be able to generate automatically usable source packages. > > Also debug packages without having to create them in debian/control > > and debian/rules. That would enable build daemons to generate and > > stash the packages somewhere if we decide to make them available. > > Only problem with this scheme is that there is always one arch that is > not autobuilt. Well yes... I hear there are these other people who have a solution to that, but that's all I'm going to say about it :-) -- Daniel Jacobowitz CodeSourcery -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Policy or best practices for debug packages?
On Mon, Jul 07, 2008 at 05:50:15PM -0400, Theodore Tso wrote: > Do programs like gdb take advantage of the .debug_macinfo in a useful > way if it's there? (I guess I should try it and see how big the dbg > packages get, and how useful it is for me in practice.) Yes, GDB will automatically expand macros in expressions and can display them. -- Daniel Jacobowitz CodeSourcery -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Policy or best practices for debug packages?
On Mon, Jul 07, 2008 at 01:42:43PM +, Sune Vuorela wrote: > On 2008-07-07, Mike Hommey <[EMAIL PROTECTED]> wrote: > > > > /usr/lib/debug/$pathoforiginalfile > > > > This is where gdb is going to look for these debug info. > > > > I thought gdb was looking at the .gnu_debuglink section as created with > objcopy? Yes, but that just determines the basename to search for. The places searched are $(dirname $origfile)/$debugname, $(dirname $origfile)/.debug/$debugname, and /usr/lib/debug/$origfile. -- Daniel Jacobowitz CodeSourcery -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Policy or best practices for debug packages?
On Mon, Jul 07, 2008 at 05:39:00PM +0200, Mike Hommey wrote: > On Mon, Jul 07, 2008 at 10:56:14AM -0400, Theodore Tso <[EMAIL PROTECTED]> > wrote: > > True, although it means there's a bit more work to actually install > > the source package, and then running "./debian/rules build" in order > > to make sure the sources are unpacked and patches appropriately > > applied. With Red Hat all you have to do is unpack the debuginfo > > package, and the sources that were used to build the binaries are made > > available with no muss and no fuss in > > /usr/lib/debug/usr/src/". (And an obvious thing for Red Hat > > to have done is to hack gdb to automatically figure out the location > > of the source files, possibly by encoding it in the build-id --- > > although I don't know if they have done it.0 I think they do this, using "debugedit". We (CodeSourcery) do it for our libraries too. It's incredibly useful - but very spoiling; every time I'm without the automatic debug sources and source paths I get grumpy about it. > There are 3 kind of people who need -dbg packages. > - Users, when they are asked to provide proper backtraces in bug reports > - Developers, when they need to debug stuff > - Maintainers > > Obviously, the latter will be able to get the sources themselves, so do > the second, most of the time, though the debian/rules patch thing might be > a problem, especially when you need to install cdbs or some other stuff to > get it working (only to apply dumb patches, d'uh). There are a number of other complications. One of them is generated files; you need to extract some sources from the object directory. Another is manual setup of paths. GDB's recently added set substitute-path command makes this easier than it used to be, but it's still a hassle. I wouldn't want them in the archive for everything, but it would be nice to be able to generate automatically usable source packages. Also debug packages without having to create them in debian/control and debian/rules. That would enable build daemons to generate and stash the packages somewhere if we decide to make them available. -- Daniel Jacobowitz CodeSourcery -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Policy or best practices for debug packages?
On Mon, Jul 07, 2008 at 10:06:40PM +0100, Roger Leigh wrote: > Correct line numbers when dealing with inline templates, for one. > There were some other niceties, but I can't recall what they were off > the top of my head. Sorry, but this is either someone's uncontributed gcc patches, or (more likely) hearsay. The difference between -g (same as -g2) and -g3 is whether .debug_macinfo is generated - debug info for C/C++ preprocessor macros. It's off by default because the generated data is huge. -- Daniel Jacobowitz CodeSourcery -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Large data packages in the archive
On Tue, May 27, 2008 at 03:54:25PM -0500, Raphael Geissert wrote: > Daniel Jacobowitz wrote: > > > > FYI, the most recent CVS snapshots of GDB can read zlib-compressed > > debug info. If someone gets around to an objcopy patch to create it, > > then we can change debhelper to use it... > > > > What's the runtime cost? > Usually things get slower with such kind of changes. Seems roughly null, given some RAM to spare; zlib is a bit cheaper than the extra disk IO on many modern systems. Mike is right that this won't affect archive size much, though. -- Daniel Jacobowitz CodeSourcery -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Large data packages in the archive
On Mon, May 26, 2008 at 05:52:13PM +0100, Darren Salt wrote: > I demand that Alexander E. Patrakov may or may not have written... > > > Joerg Jaspert wrote: > >> That already has a problem: How to define "large"? One way, which we > >> chose for now, is simply "everything > 50MB". > > > Random thought: some architecture-dependent -dbg packages are also > 50 MB > > in size. Shouldn't they get some special treatment, too? > > -Zlzma? :-) FYI, the most recent CVS snapshots of GDB can read zlib-compressed debug info. If someone gets around to an objcopy patch to create it, then we can change debhelper to use it... -- Daniel Jacobowitz CodeSourcery -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Default value for CFLAGS/LDFLAGS set by dpkg
On Mon, Mar 31, 2008 at 10:23:59PM +, brian m. carlson wrote: > LD_PRELOAD would still be able to override it, because by default, ELF > shared libraries use relocations that must be serviced by ld.so. That part is incorrect. A hidden symbol binds at link time; ld.so is never given the chance to resolve anything to it. You end up with relative relocations or fixed PC-relative offsets. -- Daniel Jacobowitz CodeSourcery -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: disassembling machine code
On Thu, Mar 20, 2008 at 09:25:00AM -0700, PETER EASTHOPE wrote: > Folk, > > There was no answer to this question in debian-user. > Is this the appropriate list? > > I have these 5 bytes of machine code to disassemble. > > b8 12 00 cd 10 > > I've looked at gdb and objdump. Appears they > need a complete object file. What tool can disassemble > this string? Try objdump -b binary -D. -- Daniel Jacobowitz CodeSourcery -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: dpkg semi-hijack - an announcement (also, triggers)
On Sun, Mar 09, 2008 at 07:09:39PM +0100, Pierre Habouzit wrote: > Well, I read it that way: > > An integer constant expression with the value 0 (or such an > expression) cast to type void *, is called a null pointer constant.55) Well, don't read it that way - the commas in the original version are correct and intentional :-) -- Daniel Jacobowitz CodeSourcery -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: dpkg semi-hijack - an announcement (also, triggers)
On Sun, Mar 09, 2008 at 06:34:48PM +0100, Pierre Habouzit wrote: > Here is the relevant C99 quote: > > > § 7.17 Common definitions > [...] > 3 The macros are > NULL > which expands to an implementation-defined null pointer constant; and > > > 0 is not a pointer, hence disqualifies. Just to confirm Kurt's point, 0 is a "null pointer constant" in C. But it is not necessarily a pointer. You can't terminate a varargs list of pointers (e.g. execl) with NULL unless you cast it. -- Daniel Jacobowitz CodeSourcery -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: dpkg semi-hijack - an announcement (also, triggers)
On Sun, Mar 09, 2008 at 11:28:13AM +, Ian Jackson wrote: > With this message I am unilaterally declaring myself a maintainer of > dpkg, and also declaring that Guillem is no longer a maintainer. How can you possibly consider this justified, without even passing through the TC? I find your decision to do this in appallingly bad taste. If I could produce a ten page essay on why I would be a superior maintainer for one of your packages could I simply hijack it? > [4] Why not ask the Technical Committee to rule ? > > The TC has not shown great dynamism in recent months. I have tried > quite hard as a TC member to get various questions that were put to > the TC decided, and the results have not been encouraging. > > In any case, asking the TC about this at this stage would probably > take at least a month or more. This would make it that much harder > for other packages' maintainers to make good use of triggers in lenny. > It would also allow Guillem to continue making his undesirable > wholesale edits in the meantime. > > Finally, of course, I am on the Technical Committee. For me to appeal > this dispute to it in this way would seem too much like me using it as > a personal bludgeon. You want to talk about appearances. It appears that you're acting as inherently superior to another developer without involving the TC because of the fact that you're already on it. -- Daniel Jacobowitz CodeSourcery -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Default mail-transport-agent
On Wed, Oct 24, 2007 at 08:00:20PM +0200, Nico Golde wrote: > Just tried by doing an aptitude purge reportbug && aptitude > install reportbug since I haven't installed a fresh system > for quite some time, but it didn't ask at least on this > system here. I would imagine it's in $HOME/.reportbugrc. -- Daniel Jacobowitz CodeSourcery -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bug#445866: ITP: perforce -- closed source revision control system
On Mon, Oct 08, 2007 at 03:41:21PM -0400, Roberto C. S?nchez wrote: > Given the great abundance of revision control systems already packaged > for Debian, what is the point of adding another? Especially when it is > non-free. How about "people use it"? There's plenty of installations of perforce; I think making it easier to use Debian with them is within the mandate for non-free. -- Daniel Jacobowitz CodeSourcery -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Packaging a library that requires cross-compiled code
On Sun, Sep 30, 2007 at 12:25:51AM +0200, Bernd Zeimetz wrote: > What about the following plan: > > - the first version of the package will build-dep. on the gcc source, > build the compiler and build the firmware. > - all new versions of the package will build-depend on the old package > and just copy the binary blob from it. > > Any objections to this? That's pointless. Why bother? -- Daniel Jacobowitz CodeSourcery -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Packaging a library that requires cross-compiled code
On Thu, Sep 27, 2007 at 02:59:16AM +0200, David Anderson wrote: > 1) Ship a built copy of the code in the package's .diff.gz, and DTRT > at package creation time to move the .bin from debian/ to the right > place in the staging tree. The source code for the .bin is in > .orig.tar.gz, under a free license. Anyone is free to modify or > rebuild the .bin, provided they obtain an arm7 cross-compiler by > non-debian means (instructions provided). People who just want to > rebuild the package can do so, without caring that there is > cross-compiled code involved. I think this is the way to go unless you get some concrete objections. There is certainly precedent - see for instance the ia32-libs / amd64-libs packages (which are frowned upon for whole different reasons). -- Daniel Jacobowitz CodeSourcery -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: RFC: changes to default password strength checks in pam_unix
On Mon, Sep 03, 2007 at 07:01:38AM +0200, Christian Perrier wrote: > > > Given modern processor power availability, I can't think of one; > > > > How about modern brain availability? You'll just get a lot of annoyed > > people changing it back; for example, makepasswd still uses a minimum > > length of six. > > > My weak English makes me think your comment is rude. Please excuse > me then if this is not. I apologize if my meaning was unclear; it was not meant to be rude. I think that looking at only the power of modern CPUs - how long it takes to crack a password - misses the point. If you enforce longer passwords than people are comfortable with, you get weaker passwords (or poor password management practices). It's the humans that matter, not the machines. -- Daniel Jacobowitz CodeSourcery -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: RFC: changes to default password strength checks in pam_unix
On Sun, Sep 02, 2007 at 02:39:25PM -0700, Steve Langasek wrote: > On Mon, Sep 03, 2007 at 12:04:52AM +0300, Lars Wirzenius wrote: > > su, 2007-09-02 kello 12:47 -0700, Steve Langasek kirjoitti: > > > Does anyone else have a reasoned argument why Debian should have a weaker > > > password length check than upstream (4 chars instead of 6)? If not, this > > > will be changed in the next upload of pam. > > > What's the justification of not using a minimum password length of 8? > > Given modern processor power availability, I can't think of one; How about modern brain availability? You'll just get a lot of annoyed people changing it back; for example, makepasswd still uses a minimum length of six. -- Daniel Jacobowitz CodeSourcery -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Considerations for 'xmms' removal from Debian
On Tue, Jul 10, 2007 at 07:13:03PM -0500, David Moreno Garza wrote: > Daniel Jacobowitz wrote: > > When last I looked (some time ago), none of the different XMMS > > successors were ready for prime time. Are bmpx, audacious, and xmms2 > > all usable now? > > What's exactly a XMMS successor? All three of the ones I listed are descended from the XMMS code base, the XMMS developers, or both. As far as I can tell, anyway. -- Daniel Jacobowitz CodeSourcery -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Considerations for 'xmms' removal from Debian
On Mon, Jul 02, 2007 at 11:58:02AM -0400, José Miguel Parrella Romero wrote: > The maintainers of the xmms package in Debian are proposing the removal > of the aforementioned package. Please read on. When last I looked (some time ago), none of the different XMMS successors were ready for prime time. Are bmpx, audacious, and xmms2 all usable now? -- Daniel Jacobowitz CodeSourcery -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Mandatory -dbg packages for libraries?
On Tue, Apr 24, 2007 at 11:43:02PM +0200, Pierre THIERRY wrote: > Scribit Daniel Jacobowitz dies 23/04/2007 hora 16:19: > > Another possible way to change glibc would be to have libc6-dbg > > contain full debug symbols, libc6-dev contain -g1 symbols only, and > > have the -dbg divert the -dev. > > Why not do that for every library? Just doesn't seem useful enough to go through the hassle. -- Daniel Jacobowitz CodeSourcery -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: spam from bugs.debian.org
On Wed, Apr 25, 2007 at 12:45:06PM -0400, Kamaraju S Kusumanchi wrote: > I have been dealing with gcc's bugzilla, KDE's bugs.kde.org, mozilla's bug > tracking system etc., I never ever received any spam messages from these > bug tracking systems. The spam emails seem to come only from BTS. May be we > can learn from them as to what they are doing (mandatory registration?) > better. Unfortunately spammers seem to have learned how to register with bugzilla, lately. -- Daniel Jacobowitz CodeSourcery -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Mandatory -dbg packages for libraries?
On Mon, Apr 23, 2007 at 03:19:23PM -0400, Joey Hess wrote: > Hmm, I hope this isn't a potential security hole.. I'd be happy if there > were a way to remove that info from the package, actually. I have done some work with debugedit, which is shipped with RPM - it's supposed to be able to do this, but it needs a little love and to be integrated into the post-install process. -- Daniel Jacobowitz CodeSourcery -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Mandatory -dbg packages for libraries?
On Mon, Apr 23, 2007 at 03:08:41PM -0400, Joey Hess wrote: > Daniel Jacobowitz wrote: > > Yes, it's deliberate. People rarely need them just because they're > > debugging something linked to libc.so.6. Having them slows down GDB > > startup and increases its memory usage, for _every_ debug session. > > Ok. Of course, this is also generally an argument against having -dbg > packages for libraries with separated symbols.. Yes. It's a tradeoff question. Pretty much any other library will affect a smaller overall percentage of users :-) > > You'll notice if you look closely that libc6-dbg contains two things. > > One of them is a set of libraries you can use if you want to debug > > libc6. The other is a set of separate symbol files, but they contain > > only frame unwind information, no symbolic or line number information. > > This keeps the size and performance impact of the package down, but > > makes backtraces out of libc6 hugely more reliable. > > What are your feelings on only including the -g1 information in library > -dbg packages in general? It does save a lot of space, but the potential > utility also goes way down. I don't remember exactly what -g1 produces, but I think libc6-dbg is even less - it's only .debug_frame and .symtab, nothing else at all. I think libc6-dbg is a special case here, and we should use -g (-g2) in general. Another possible way to change glibc would be to have libc6-dbg contain full debug symbols, libc6-dev contain -g1 symbols only, and have the -dbg divert the -dev. -- Daniel Jacobowitz CodeSourcery -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Mandatory -dbg packages for libraries?
On Sun, Apr 22, 2007 at 07:29:55PM -0400, Joey Hess wrote: > Even with separated debugging symbols, -dbg packages are frequently > larger than the package they provide debugging symbols for. See for > example xserver-xorg-core-dbg. Looking through the 227 lib*-dbg > packages, I found few contain separated debugging symbols, except for > packages maintained by the xorg team[1]. I'm not sure if this is due > many people still not knowing about separated debugging symbols, or due > to technical reasons. For example, is there a tecnical reason why > libc6-dbg does not contain separated debugging symbols? Yes, it's deliberate. People rarely need them just because they're debugging something linked to libc.so.6. Having them slows down GDB startup and increases its memory usage, for _every_ debug session. You'll notice if you look closely that libc6-dbg contains two things. One of them is a set of libraries you can use if you want to debug libc6. The other is a set of separate symbol files, but they contain only frame unwind information, no symbolic or line number information. This keeps the size and performance impact of the package down, but makes backtraces out of libc6 hugely more reliable. > I've considered before trying to set up a separate, parallel archive > that would only hold the -dbg packages, but implementing that without > initially using the Debian infrastructure would be tough, and my > experiences with setting up[2]/maintaining the separate udeb section of > the archive is that it adds a lot of complexity. FWIW, I still think this is the way to go, though it would be hard. They wouldn't need nearly as much mirroring. e.g. they could go into a separate pool directory... -- Daniel Jacobowitz CodeSourcery -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: *dbg pakages
On Wed, Apr 11, 2007 at 07:21:53PM +0300, costin c wrote: > But running /usr/lib/openoffice/program/soffice.bin under gdb, with > openoffice.org-dbg package installed, doesn't give any additional > information toward running same executable without openoffice.org-dbg > installed. You get extra information. What this output means is that it's not enough debugging information to do line number mapping. That is probably the maintainer's deliberate choice; check the source package. -- Daniel Jacobowitz CodeSourcery -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: *dbg pakages
On Wed, Apr 11, 2007 at 06:31:00PM +0300, costin c wrote: > Hello > > How should be used pakages containing debugging symbols/informations, > like openoffice.org-dbg > When I try to run > /usr/lib/debug/usr/lib/openoffice/program/soffice.bin bash show an > unexpected error message "cannot execute binary file". Just install it, don't try to run it. GDB will pick it up automatically. -- Daniel Jacobowitz CodeSourcery -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: On maintainers not responding to bugs
On Mon, Feb 26, 2007 at 05:31:49PM +0100, Klaus Ethgen wrote: > Sure. For doing some Work on such projects as glibc (Low level tools, > I'm not the frontend programmer). But then come to another problem, (and > yes, I know there is the possibility to have a sponsor) how to just help > without being a DD? Very easily. Subscribe to the package's mailing list or PTS entry, respond to easily answerable bug reports, and attach patches in the BTS. Believe me - many maintainers appreciate it! At least, they will unless you have a tendency to answer incorrectly. If that happens several times, consider sending patches to the mailing list or maintainer rather than responding to the bug submitter with possibly incorrect information. This is the only major pitfall of trying to help out. -- Daniel Jacobowitz CodeSourcery -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Where did Bacula 1.38.11-7+b1 come from?
On Thu, Feb 22, 2007 at 12:32:58PM -0600, John Goerzen wrote: > Yes. I wasn't aware that buildds ever modify the changelog or do > binNMUs though. Aren't buildds simply there to build the existing > sources on other platforms? Automatic bin-NMU support was added, I believe within the last year. The release team uses it extensively. -- Daniel Jacobowitz CodeSourcery -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Not depending on shlibs because of plugins?
On Fri, Jan 05, 2007 at 06:44:49PM +0100, Kurt Roeckx wrote: > >From the subject, I seem to understand that those are added by shlibs? > This seems to suggest that something in the package is linked to all the > libraries, and I don't see how you could remove it. The package contains plugins which are linked to each library; the plugins get dlopened, not the database libraries. This is pretty typical for plugins. -- Daniel Jacobowitz CodeSourcery -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: db.debian.org (and related infrastructure) updates
On Sat, Dec 30, 2006 at 04:37:15PM +0100, Joerg Jaspert wrote: > I personally would love, if you go and whitelist, that you also > whitelist the following set of hosts: Wouldn't this be useful in the greylistd configuration on master, then? -- Daniel Jacobowitz CodeSourcery -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Conditionally applying an architecture-dependent patch
On Mon, Nov 27, 2006 at 04:04:41PM -0800, Steve Langasek wrote: > I would normally recommend quilt, but I'm not sure it has a concept of > conditional patches, which may make things awkward later if further patches > are required. It doesn't. I think I've seen this done before by processing the series file. But it's not pretty. -- Daniel Jacobowitz CodeSourcery -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Debian Installer etch RC1 released
On Tue, Nov 14, 2006 at 08:58:00AM -0500, Roberto C. Sanchez wrote: > I understand that the line must be drawn somewhere. However, I am > concerned about Etch shipping with a 2.6.17 kernel because of Xen. Please read further down, to where the next rc is expected to include 2.6.18. -- Daniel Jacobowitz CodeSourcery -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bug#398601: ITP: retty -- lets you attach processes running on other terminals
On Tue, Nov 14, 2006 at 02:33:14PM +0100, Christoph Berg wrote: > Programming Lang: C and i386 asm (it doesn't work on amd64) > Description : lets you attach processes running on other terminals To anyone else who was curious about this: What it seems to be doing is injecting code onto the stack which causes the target process to open your terminal and dup2 it onto stdout, stderr, et cetera. Interesting. -- Daniel Jacobowitz CodeSourcery -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Question regarding maintainer email
On Mon, Oct 16, 2006 at 07:51:04PM +0200, Tobias Frost wrote: > My question, is, if this is ok with the debian packaging policy chapter > 3.3, or not (that is should I file a bug?) It is not considered acceptable. It's the default settings on alioth, and instructions on how to fix them are posted to this list periodically. -- Daniel Jacobowitz CodeSourcery -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Making SELinux standard for etch
On Thu, Oct 12, 2006 at 02:12:54PM +0100, Ian Jackson wrote: > Indeed, if you're willing to take my word as a computer security > expert[1] for it, I can say with confidence that selinux is not the > right approach to fixing the security problems with our systems. > It probably does more harm than good. > > ([1] I have a PhD in computer security from Cambridge University, > 8 years' practical experience in the computer security industry, and a > similar period of experience as an author of Free security software.) Ian, why are you doing this? You must surely know better by now. Trying to pull you credentials isn't going to do you any good; SELinux is developed by plenty of people with solid credentials, as I hope you realize if you did even a cursory investigation. All it does is make you sound presumptuous. It absolutely blows my mind that you can sit here and calmly assert that a project as thoroughly designed and audited (and generally respected) as SELinux is simply "more harm than good", whatever the quality of the Debian-specific patches, and expect to be taken seriously. -- Daniel Jacobowitz CodeSourcery -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#388052: mplayer-nogui: mplayer segfaults (ld at fault)
On Tue, Sep 19, 2006 at 10:24:34AM +0200, Josselin Mouette wrote: > warning: Can't read pathname for load map: Input/output error. > > warning: .dynamic section for "/usr/lib/libasound.so.2" is not at the > expected address > > warning: difference appears to be caused by prelink, adjusting > expectations > > Two things here: > 1. Are you using prelink? If you are, that may be a prelink bug. > 2. Otherwise, the I/O error can be caused by a hardware or > filesystem problem. You should read the dmesg output to look for > error messages there. Actually, this particular I/O error has nothing to do with hardware; it has to do with the kernel's "virtual DSO" page, if I remember right. -- Daniel Jacobowitz CodeSourcery -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Compatibility between Debian amd64 and other distributions
On Sat, Sep 23, 2006 at 05:40:42PM +0200, Goswin von Brederlow wrote: > So what you seem to say is: If you copy the libc6 or static libraries > between distributions you deserve to fail. Thats fine if you say it > straight out. That's what I was trying to do! > Does the same apply to libX11. Or can we do the compile for lib64, use > lib trick there as it is not frozen? I don't think it matters, but it's up to the X maintainers. -- Daniel Jacobowitz CodeSourcery -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Compatibility between Debian amd64 and other distributions
On Sat, Sep 23, 2006 at 10:29:37AM +0200, Goswin von Brederlow wrote: > Daniel Jacobowitz <[EMAIL PROTECTED]> writes: > > > On Sat, Sep 23, 2006 at 02:50:35AM +0200, Goswin von Brederlow wrote: > >> But running Debian binaries on other distributions remains a > >> problem. For example static binaries that use libnss* plugins will > >> fail to find those plugins on other systems. Copying the debian libc6 > >> to your ~/lib/ dir on another distribution will break locale plugins. > > > > Do you have any less contrived examples? FWIW, I think in either of > > these cases you deserve to keep both pieces. > > How do you keep both pieces if you are not root? That has nothing to do with it. Copying libc.so.6 to something other than its configured location breaks in plenty of other ways. Static binaries using nss are a long-standing and known source of problems, and if you copy them to any other version of glibc - configured differently or not - you're liable to crash. -- Daniel Jacobowitz CodeSourcery -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Compatibility between Debian amd64 and other distributions
On Sat, Sep 23, 2006 at 02:50:35AM +0200, Goswin von Brederlow wrote: > But running Debian binaries on other distributions remains a > problem. For example static binaries that use libnss* plugins will > fail to find those plugins on other systems. Copying the debian libc6 > to your ~/lib/ dir on another distribution will break locale plugins. Do you have any less contrived examples? FWIW, I think in either of these cases you deserve to keep both pieces. > The fix is really simple. Compile glibc with libc_[s]libdir = > [/usr]/lib64 but move [/usr]/lib64 to [/usr]/lib and add the > compatibility links after the build. That results in libc6 using the > FHS paths [/usr]/lib64 when looking for plugins, which means following > the [/usr]/lib64 link on Debian, just like every other distributions > glibc does on amd64. Nothing else changes. I'm perfectly happy to do this. After etch. -- Daniel Jacobowitz CodeSourcery -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: svn package maintenance
On Sun, Jul 23, 2006 at 01:06:28PM +0200, Marcus Better wrote: > Hello, > > I've recently started to use svn for package maintenance, both in order to > enable team maintenance and because it's a great way to keep track of the > code. > > Previously I used dpatch or quilt for the Debian changes. However with svn > (or any other version control system) it really doesn't make sense to use > that. The VCS is great at keeping track of changesets. Keeping patches in > svn effectively circumvents the whole point of VCS. (This is probably > obvious to anyone who has tried it, so I won't elaborate on it here.) Entirely disagree. Not only isn't it obvious, but IMO it's wrong :-) > I'm now trying to replicate the advantages of quilt with svn. Some of these > advantages are: I replicate the advantages of quilt by keeping quilt patches in Subversion. This allows me to use svn-inject -o, which doesn't put the upstream sources in version control at all - just the Debian directory. I like this much more than any alternative I've seen. The same principle as StGIT - I've never met a version control system whose support for managing lots of individual patches all feeding into one final result was as good as quilt. -- Daniel Jacobowitz CodeSourcery -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: CDBS and dh_install
On Fri, Jun 09, 2006 at 02:02:48PM -0500, Manoj Srivastava wrote: > I am surprised to hear you say so, since CDBS is one of the > most configurable build systems out there. You can add commands to > any phase of the build, by just adding targets/dependencies/variables. If you can figure out where they go. The last time I had to adjust my (CDBS-using) build process I wasted an hour grepping around in /usr/share/cdbs. I think what CDBS could really use would be an improved manual. The examples don't cover a lot of things you can do with it. -- Daniel Jacobowitz CodeSourcery -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: LSB init scripts and multiple lines of output
On Thu, Jun 01, 2006 at 06:51:54PM +0200, martin f krafft wrote: > In my ideal world, this is what it would look like: > > Starting RAID devices ... > /dev/md0 has been started with 3 drives. > /dev/md1 has been started with 3 drives. > /dev/md2 assembled from 2 drives - need all 3 to start it > /dev/md3 assembled from 1 drive - not enough to start the array. > /dev/md4 has been started with 3 drives. > ... done assembling RAID devices: failed. Have you considered: Starting RAID device md0 ... 3 drives, done Starting RAID device md1 ... 3 drives, done Starting RAID device md2 ... 2/3 drives, degraded Starting RAID device md3 ... 1/3 drives, failed Starting RAID device md4 ... 3 drives, done -- Daniel Jacobowitz CodeSourcery -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: ITP: elfutils
On Sat, May 20, 2006 at 10:12:24PM +0200, Kurt Roeckx wrote: > - The license is now GPL for most files. The libelf, libebl, libdw,and > libdwfl libraries have additional exceptions. Add reference toOIN. > > (This allow to link with any open source license approved by OSI) > > It contains other libraries which have something simular in Debian > already. > > libelf (with binary package libelfg0) seems to do exactly the same, so > maybe we should look at only providing one of them. I have no idea why > it has the g in it's name though. They are roughly ABI compatible, but they are neither license compatible (you can link libelfg0 with whatever you please) nor completely quirk compatible (I've reported bugs in using the elfutils version to modify files where it would corrupt output, I have no idea if they've been fixed). -- Daniel Jacobowitz CodeSourcery -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: timezone data packaged separately and in volatile?
On Tue, Feb 07, 2006 at 02:30:01PM +1100, Anand Kumria wrote: > But that doesn't mean that we can issue an update to a stable package. > > Currently they are mainly done for security purposes -- but stable updates > should not be confined to only that. They should be done to keep the > system functional. > > I also think volatile is precisely the wrong place to put this kind of > data -- it isn't part of the default apt.sources for one thing; and it > places an extra burden on the maintainer(s) (who know have to track > three different upgrade paths, etc.). > > It would be good to hear from the glibc maintainers if there are any > issues addressing bugs such as: 345479, 351049 with an update for > stable. It's not us, but the stable maintainer, that you'd have to talk to; he has traditionally not been interested in these sorts of updates to stable as far as I know. -- Daniel Jacobowitz CodeSourcery -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: yet another mass bug filing on GFDL issues ?
On Sun, Jan 22, 2006 at 09:58:58AM -0500, Anthony DeRobertis wrote: > Holger Levsen wrote: > > > Hm, on a second thought this (*) _might_ be a feature: the GFDL says > > invariant > > sections need to be listed, but there aren't any, as a template has been > > used. Yay ?! > > I suspect that many of those cases might just be an accidental ommission > in the copyright file... > > OTOH, it is hillarious that after typing 'info gdb' I was unable to > actually find the statement saying the documentation is under the GFDL; > it appears that the FSF has once again mis-applied their own license... Incorrect. I clarified this with the GDB documentation expert; for some reason the license is in the Info file (you can find it with a text editor) but deliberately does not show up in an Info browser. Which makes fair sense; normally the license is in the source code, not in the binary. http://sourceware.org/ml/gdb/2005-12/msg00126.html -- Daniel Jacobowitz CodeSourcery -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: buildd administration
On Sat, Dec 10, 2005 at 11:46:50AM +1000, Anthony Towns wrote: > On Fri, Dec 09, 2005 at 10:19:46AM -0500, Daniel Jacobowitz wrote: > > I'm not saying that this all needs to be publicly logged. I don't give > > a rat's ass whether it is or not. But please don't stand there saying > > that the process is completely transparent. > > I don't believe I said that. I don't believe it's remotely fair to set > the standard at the unreachable level of perfection, either. You said that the logs tell you what the buildd admins are doing with the buildd. I disagree. > The major task of buildd maintenance (aiui) is handlings logs though, > and that's certainly what was being complained about earlier. I'd > be interested to see you name an area that's had anything like the > transparency w-p provides the build process though. I guess there's > britney, which gives public logs of what's going on, but also requires > a degree of handholding every now and then that isn't particularly logged. The majority of "handling" logs is monkeywork - very easy, mostly automated. The main jobs of the buildd admin are to (A) provide a human sanity check on what's getting built successfully; I am and always have been somewhat dubious of the value of this, even when I was doing it; and (B) doing something about the failures. What buildd.debian.org logs is the output of the sbuild runs. We have great visibility into what _sbuild_ is doing. But what the _buildd admin_ is doing is, by and large, taking care of the failures: whether that means dep-waiting them, filing bugs because of them, poking anything obscure that caused the buildd environment to get broken (e.g. when a package fails to uninstall, or a broken package fills the disk with logs). This stuff doesn't get logged, nor would it be particularly easy to log. The current buildd admins don't seem to be very responsive about filing bugs for the failures; they tend to sit for rather a long time unless porters, or package maintainers, go out and stare at the logs on their own. But my sample size for this last bit is small, so take it with a grain of salt. I don't think that the human step of signing the successful logs has any value nowadays. The closest a human can go to checking the volume of mail a buildd produces is running it through some clever procmail filters, anyway. Or reading through any logs that strike them as particularly interesting. I don't have handy stats about the volume of mail produced by the buildd anymore, but voltaire's currently pumping out about eighty thousand lines a day over the last week and a half, if I'm looking at the right logs. -- Daniel Jacobowitz CodeSourcery, LLC -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: buildd administration
On Fri, Dec 09, 2005 at 11:49:05PM +1000, Anthony Towns wrote: > On Thu, Dec 08, 2005 at 10:16:37PM -0800, Thomas Bushnell BSG wrote: > > Anthony Towns writes: > > > That's non-sensical. Everything the buildds do is logged pretty much > > > immediately onto http://buildd.debian.org/, which also provides long > > > running statistics on how effective the buildds are, and even a schedule > > > of what the buildds will be working on next. > > That tells us what the buildds are doing. It doesn't tell us anything > > about what the buildd admins are doing. > > It tells you what the buildd admins are doing with the buildds. No, sorry, it tells you what the admins are doing with the build logs. I'm sure there's less of it nowadays than there used to be, but there's always been a certain amount of handholding in the buildd system configuration, et cetera. I'm not saying that this all needs to be publicly logged. I don't give a rat's ass whether it is or not. But please don't stand there saying that the process is completely transparent. -- Daniel Jacobowitz CodeSourcery, LLC -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bug#336698: dh_strip: debug data going to the wrong place
On Tue, Nov 01, 2005 at 08:33:23PM +0100, Kurt Roeckx wrote: > Those are real libraries that were not stripped, and those should > go away in favour of the detached version. [Yes, I realize this is a really old thread... I haven't been reading -devel lately. Not necessarily true. - They may be compiled with lower optimization. - They may be compiled with behavior-altering debugging options. I believe the former is true for libc6-dbg and I know the latter is true for libncurses5-dbg; it can record trace files for later debugging, which has some runtime overhead. [I've been thinking about enabling it by default anyway, but it's the sort of thing that needs to be measured first.] -- Daniel Jacobowitz CodeSourcery, LLC -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Automatically sending test suite results from buildds to upstream
On Tue, Oct 11, 2005 at 01:35:06AM +0200, Florian Ragwitz wrote: > Therefor I'd like to automatically upload these results to > http://smoke.pugscode.org after the packages are built on the buildds. > Is it an acceptable behaviour of source packages to upload informations > to various places without asking the user for permission like the > polularity-contest package for example? Of course, it could be disabled > by default and may be activated using environment hooks or other hacks. > But that would prevent us from using the buildd results, that are > produced anyway, to improve the quality of the upstream software. > > How should I proceed? Another option is to either leave the information in the buildd log files (i.e. send it to stdout), or to include test results in the .deb files and retrieve them after the build. That latter is what the GCC packages do. -- Daniel Jacobowitz CodeSourcery, LLC -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: When is the C++ transition needed?
On Thu, Oct 06, 2005 at 09:24:19PM -0400, Nathanael Nerode wrote: > Brian Carlson wrote: > >> You must not pass by reference with an extern "C" declaration, because C > >> doesn't support that. > Dan Jacobowitz wrote: > >Why not? An extern C definition doesn't mean that it needs to be > >usable from C. It just means to use the C calling convention. > Perhaps because there is no C calling convention for passing by reference? > How to pass arguments is part of the calling convention. :-P You can pass > C++-only objects, certainly, but you have to be able to pass them in a way > which is understood in the C calling convention. That's incorrect. The C++ ABI uses a defined convention for passing by reference, and with a different prototype and some care, or from assembly, you can duplicate the effect. The primary effect of extern "C" is just disabling mangling. -- Daniel Jacobowitz CodeSourcery, LLC -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: When is the C++ transition needed?
On Thu, Oct 06, 2005 at 05:35:34PM +, Brian M. Carlson wrote: > On Thursday 06 October 2005 12:45, Henning Makholm wrote: > > I notice that the newest upload of pstoedit has reverted the C++ > > transition name change; instead of libpstoedit0c2 sid now contains > > libpstoedit0, as in sarge. > > This is, IMHO, incorrect. > > > However, the library exports things with interfaces such as > > > > #ifdef __cplusplus > > extern "C" DLLEXPORT > > int pstoeditwithghostscript(int argc, > > const char * > > const argv[], > > ostream& errstream, > > You must not pass by reference with an extern "C" declaration, because C > doesn't support that. Why not? An extern C definition doesn't mean that it needs to be usable from C. It just means to use the C calling convention. -- Daniel Jacobowitz CodeSourcery, LLC -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: editing library's soname (was Re: Fixed in upload of curl 7.14.1-1 to experimental)
On Sat, Sep 24, 2005 at 04:52:31PM +0200, Domenico Andreoli wrote: > yes, i'm aware of this. it is due to the libcurl-gnutls.so.3 soname > still being libcurl.so.3. everything else is in place for a good upload. > > as of today, i've not found a solution different from patching the > makefiles. i'd like a tool to modify this kind of things in the elf, > probably elfsh is what i'm looking for. something to run after the > build process. any idea? In general you can't do this unless you're replacing it with a shorter soname. I highly recommend fixing the build system instead. -- Daniel Jacobowitz CodeSourcery, LLC -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
[OT] Names
On Thu, Sep 22, 2005 at 06:45:35PM +0930, Debian-armeb Porting Team wrote: > -- Signed, the debian-armeb porting team. We've always had a policy of asking people to use real names on this list. Usually we invoke this for people using pseudonyms, but I think it's appropriate for role addresses, too. Whenever you write a message, you speak for yourself, in addition to any group of people you represent. So I would appreciate it if you at least signed messages with a name. Thanks. -- Daniel Jacobowitz CodeSourcery, LLC -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Debian binutils dependency policy
On Tue, Sep 20, 2005 at 11:42:06AM -0400, Camm Maguire wrote: > OK, but this is a pity. I still don't understand why this need be the > case. Because the interface between BFD and binutils is subject to change and does on a regular basis, and there are not enough users to bother doing anything more complicated. -- Daniel Jacobowitz CodeSourcery, LLC -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Debian binutils dependency policy
I have no idea why you've copied this to the binutils upstream list, debian-devel, et cetera... On Tue, Sep 20, 2005 at 10:09:03AM -0400, Camm Maguire wrote: > Greetings! > > Do we have a plan or policy regarding packages which need to depend on > binutils-dev? Is there now or will there ever be in the future a > stable binary api, by which I mean one that might be good for a year > or more of development on average? In such a case, would binary api > compatibility be guaranteed by the soname of the shared library as > with other libs? Could Debian consider maintaining old and new shared > lib versions to ease transitions, as with other libraries? No way. dpkg -s binutils-dev: Description: The GNU binary utilities (BFD development files) This package includes header files and static libraries necessary to build programs which use the GNU BFD library, which is part of binutils. Note that building Debian packages which depend on the shared libbfd is Not Allowed. The same thing applies to any other form of dependency on the binutils shared libraries. > If the answer to the first question is no, then the only sensible > policy would appear to be that everyone fork and locally maintain > their own binutils snapshot for static linking. This appears terribly > inefficient from a system design point of view. On the other hand, > forcing a rebuild of gcl,maxima,acl2 and axiom on all platforms > because of a binutils change which might in fact be completely > innocuous is untenable as well. Use binutils-dev, link to libbfd.a? The source API changes relatively rarely, it probably won't bite you. -- Daniel Jacobowitz CodeSourcery, LLC -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Managing users and groups within multiple devel chroots.
On Sun, Sep 18, 2005 at 11:52:09PM -0400, Daniel Jacobowitz wrote: > Here's the code, hardcoded paths and all: > http://return.false.org/~drow/fuse/shadow-etc.c Slightly better, but not much: http://return.false.org/~drow/fuse/ -- Daniel Jacobowitz CodeSourcery, LLC -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Managing users and groups within multiple devel chroots.
On Thu, Sep 15, 2005 at 06:29:12AM -0500, Peter Samuelson wrote: > > [Ernestas V.] > > Perhaps hard/symlinking original /etc/passwd, /etc/shadow and > > /etc/group to chrooted environments would help? > > Symlinks won't work. Think about what a chroot environment *is*. > > Hardlinks will only work if the programs that edit /etc/passwd and > /etc/group overwrite them rather than copy / unlink. > > Bind mounts will work > (mount --bind /etc/passwd /mnt/sarge-chroot/etc/passwd) > but apparently don't support locking all of a file's representations, > so you would need to be careful not to run adduser in multiple chroots > at once (like doing several dist-upgrades in parallel, or having users > log in to different chroots and all try to change their passwords at > once). Ooh ooh, an excuse to share my new toy... I was setting up a chroot a couple of weeks ago and wanted it to reflect my system configuration. So the first thing I tried were bind mounts for shareable directories - /home, /tmp, /etc, et cetera. There are a couple of problems with this for /etc. The biggest one, for me, was that the chroot was i386 and the base system was amd64. Which in itself works fine, except it points out one of those files which can't be shared in this way: ld.so.cache. And if you bind mount a different ld.so.cache on top of the bind mounted /chroot/etc, then you can no longer rename /etc/ld.so.cache - this has to do with the way the Linux VFS works, as I understand it. So I took FUSE, and the included demo which proxies one filesystem to another location. And I hacked it to support bringing specific files from other locations, based on name. It's not the most robust thing in the universe - FUSE is not "good enough" to share / this way, things just won't work right. By "good enough" I don't know whether the limitations are in FUSE or in the nature of what I was trying to do, though. And don't try this on /proc or /dev. But for /etc, it works well enough for 32-bit firefox and OpenOffice.org. I've got the feeling this could handle flock() locking correctly, but doesn't - does FUSE even implement that? Anyway it should be fine for /etc/.pwd.lock. Here's the code, hardcoded paths and all: http://return.false.org/~drow/fuse/shadow-etc.c -- Daniel Jacobowitz CodeSourcery, LLC -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Apps linked with old libstdc++ dlopening modules linked with the new one
On Wed, Sep 14, 2005 at 04:47:46AM -0700, Steve Langasek wrote: > so, the problem is caused by template instantiation shoving > this symbol into the library that uses it > the two possible solutions are (a) stop doing that, or (b) > version the symbol > so that's a g++ bug? > maybe > there are several other unversioned libstdc++ symbols > in this library > so it's not just a corner case, this is a recurring > problem > fun > we will only notice it during a libstdc++ transition though > yep > I think we start by assuming it's a libstdc++ bug and let > the g++ folk chew on it > > So: g++ is embedding an unversioned weak symbol in the library in some > cases, which causes the linker to resolve it to the version from the lib > used by the app, not the one that the library is linked against. > Segfault. Yes. Not, strictly speaking, a compiler bug. Versioned symbols are not the right tool for solving this; however, the right tool for solving it was presented in a paper at the last GCC summit. I believe by some ICC developers. I don't know if any implementation's come of that. -- Daniel Jacobowitz CodeSourcery, LLC -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Build problem with Courier (#327162), need help
On Mon, Sep 12, 2005 at 12:52:45PM +0200, Willi Mann wrote:
>
> >I'm not able to build Courier packages for unstable which are intended
> >to fix security problems due to a curious FTBFS bug (#327162):
> >
> >find /tmp/courier-0.47/debian/tmp -perm +u+x -type f | xargs chmod
> >u+rwx,go+rx
> >chmod: too few arguments
> >Try `chmod --help' for more information.
> >make: *** [install] Error 123
> >
> >There _are_ files with this permission and building the package within
> >sarge
> >works and issuing the above command from outside of the sid chroot works as
> >well.
>
> The reason is that findutils 4.2.2{4,5}-1 behave differently. (I don't
> know why exactly). If you change the -perm argument to
> -perm -u+x
> it works.
That means something different. There's still an example using +g+w on
the find man page; if it's broken, isn't it a bug in find?
--
Daniel Jacobowitz
CodeSourcery, LLC
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Steve Kemp <[EMAIL PROTECTED]> Please check your Debian E-Mail.
On Mon, Aug 08, 2005 at 03:31:40AM +0100, Steve Kemp wrote: > On Sun, Aug 07, 2005 at 10:12:56PM -0400, Daniel Jacobowitz wrote: > > > > The SSP compiler is a patch against GCC and offers "Stack Smashing > > > Protection". In short it gives protection against buffer overflow > > > bugs, and attacks. > > > > Steve, you are aware that GCC 4.1 will include a complete > > reimplementaton of this feature, right? Wouldn't time be better spent > > with that than with the obsolete SSP patches? > > The GCC 4.1 implementation, mudflap, appears to do an entirely > different thing. No, mudflap is not what I'm talking about. That's in GCC 4.0. It's a heavyweight, featureful bounds checker. But in GCC 4.1, there is a new option: -fstack-protector. It's by principle roughly the same as the IBM ProPolice feature, although Richard reimplemented it from the ground up. This should be basically the same as what you're testing, except already included in GCC. -- Daniel Jacobowitz CodeSourcery, LLC -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Steve Kemp <[EMAIL PROTECTED]> Please check your Debian E-Mail.
On Wed, Aug 03, 2005 at 12:00:33PM +0100, Steve Kemp wrote: > On Tue, Aug 02, 2005 at 03:58:33PM -0400, Greg Folkert wrote: > > > I was finally able to acquire an SSP Build Host for you. > > If you are still interest. Please contact me. > > A bit quick off the mark there, Greg! I think I've replied to all > your previous mails within a day or two...? > > Anyway for anybody else watching. This host is going to be used > for rebuilding Debian's Stable release, Sarge, with the SSP > compiler. > > The SSP compiler is a patch against GCC and offers "Stack Smashing > Protection". In short it gives protection against buffer overflow > bugs, and attacks. Steve, you are aware that GCC 4.1 will include a complete reimplementaton of this feature, right? Wouldn't time be better spent with that than with the obsolete SSP patches? -- Daniel Jacobowitz CodeSourcery, LLC -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: OT: No unsubscribe signature?
On Tue, Jun 28, 2005 at 10:14:33AM -0400, Josh Metzler wrote: > On Tuesday 28 June 2005 08:25 am, Olaf van der Spek wrote: > ... > > So they expect something to be available without depending on a > > package that provides it? Sounds like a bug. > > Message-ID: <[EMAIL PROTECTED]> > ended after the text quoted above, without the usual signature describing how > to unsubscribe from debian-devel. Was this the case for everyone, or is > there something between the debian servers and my mail client that > occasionally (but very rarely) strips signatures? Hmmm... same thing here. -- Daniel Jacobowitz CodeSourcery, LLC -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: ftp-master, ftp and db .debian.org moving - hosting sought
On Sun, Jun 26, 2005 at 12:14:44PM -0400, sean finney wrote: > On Sun, Jun 26, 2005 at 06:05:25PM +0200, Joerg Jaspert wrote: > > It was sent right after the hosting died. > > Should he sent "The hosting may die somewhere in the future, please > > offer something just in case we need it"? > > well, i guess i don't know the details of the situation, but i would > hope that hosting providers for such important projects/services would > consider to give some advance warning, like "in one month we will no > longer be able to provide hosting services". perhaps that did not > happen? You found out when we did. -- Daniel Jacobowitz CodeSourcery, LLC -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Debian concordance
On Fri, Jun 17, 2005 at 03:58:35AM +1000, Daniel Stone wrote: > Hoary (like sarge) is built against 2.3.2. > > Breezy (like current sid) is built against 2.3.5. No, 2.3.5 is still in experimental. -- Daniel Jacobowitz CodeSourcery, LLC -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bug#311997: ITP: gaim-latex -- gaim plugin wich translate LaTeX code into image in conversation
On Mon, Jun 06, 2005 at 02:21:26PM -0700, Daniel Burrows wrote: > On Monday 06 June 2005 01:11 pm, H. S. Teoh wrote: > > > Make a version which generates the image on the sending side? > > > > [...] > > > > That would be a *very* nice plugin. The bad thing about the current > > plugin isn't only the security concern: it requires that the recipient > > have the plugin installed. If the image is generated on the sending > > side, it solves the security problem, and also makes it possible to > > send (La)TeX fragments to arbitrary recipients with no additional > > hassle. I think this is worth considering. > > But then you can only use the plugin if you can send images, which is > almost > never the case for me (image-sending never seems to work even if I'm using > AIM, maybe because I'm behind a firewall). This I don't know anything about, but it seems like a good thing to fix instead of shoehorning LaTeX into the textual portion. -- Daniel Jacobowitz CodeSourcery, LLC -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bug#311997: ITP: gaim-latex -- gaim plugin wich translate LaTeX code into image in conversation
On Mon, Jun 06, 2005 at 08:45:11PM +0200, Martin Braure de Calignon wrote: > Le lundi 06 juin 2005 à 14:28 -0400, Anthony DeRobertis a écrit : > > Roberto C. Sanchez wrote: > > Ummm, I think you've missed my point. The thread is discussing a GAIM > > (instant message client) plugin. So that script is not run by you, it is > > run by an arbitrary stranger sending you an instant message, but on your > > machine and as you. That's why its a problem. > > > > Looks like if you installed this package, I could send you an IM and > > overwrite an arbitrary file on your machine. > > > > [This is just judging from the code snippet posted; don't have time to > > fully audit the software.] > > > > > Well, you're right. > So I think I won't package it. Do I have to do something special with > the BTS ? Close the bug ? add a wont-fix tag ? Make a version which generates the image on the sending side? -- Daniel Jacobowitz CodeSourcery, LLC -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: depending on shared libbfd from binutils-dev
On Tue, May 24, 2005 at 01:43:12PM +0100, Andrew Suffield wrote: > On Mon, May 23, 2005 at 07:54:53PM -0400, Daniel Jacobowitz wrote: > > > Because libbfd does not have a stable ABI suitable for public use, nor is > > > there currently a way to express a dependency on this library without > > > things breaking (you can't depend on "binutils" and have any guarantee of > > > getting the correct lib). > > > > Does make me wonder why we ship libbfd.so and libopcodes.so, instead of > > just the static libraries. > > To reduce the size of the binutils package, iirc. It has about a dozen > binaries, all of which need libbfd. No, that's why we ship libbfd-2.15.so; I was wondering why we need to ship the libbfd.so symlink. Yes, I'm familiar with how much space it saves to use a shared libbfd :-) -- Daniel Jacobowitz CodeSourcery, LLC -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: depending on shared libbfd from binutils-dev
On Sun, May 22, 2005 at 10:36:05AM -0700, Steve Langasek wrote: > On Sun, May 22, 2005 at 12:24:28PM -0500, Micah Anderson wrote: > > The package description for binutils-dev says the following: > > > >Description: The GNU binary utilities (BFD development files) This > > > package includes header files and static libraries necessary to build > > > programs which use the GNU BFD library, which is part of binutils. > > > Note that building Debian packages which depend on the shared libbfd > > > is Not Allowed. > > > I see this in the binutils-dev package description, however I dont see > > it anywhere else, not in the policy, not in lintian/linda checks, not > > on any mailing lists I see a couple of people on debian-devel > > asking (a couple years ago) what the deal is with this, but no > > informative responses. Does anyone know *why* this is and why this > > isn't documented somewhere more visible? > > Because libbfd does not have a stable ABI suitable for public use, nor is > there currently a way to express a dependency on this library without > things breaking (you can't depend on "binutils" and have any guarantee of > getting the correct lib). Does make me wonder why we ship libbfd.so and libopcodes.so, instead of just the static libraries. -- Daniel Jacobowitz CodeSourcery, LLC -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Prods to the ftpmasters
On Wed, May 18, 2005 at 12:32:54AM +0200, martin f krafft wrote: > I just wanted to say a big thank you to the ftpmasters for improving > the NEW queue situation in such a noticable manner. Despite all the > stress that sarge must be causing on y'all, I was very happy (and > joyfully surprised) to find two of my NEW packages being approved > within just three days. > > Thanks a lot for your work, and for making Debian a more pleasurable > place for developers! That sounds like props, not like prods... -- Daniel Jacobowitz CodeSourcery, LLC -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Urgently need GPL compatible libsnmp5-dev replacement :-(
On Wed, May 11, 2005 at 03:50:29PM +0200, Tollef Fog Heen wrote: > * Andreas Barth > > | Agreed. We should IMHO make such a requirement to be part of etchs > | release policy. > > How are you going to solve the problem ia32-libs solves if not in this > way? > > (Unless we want to make etch fully multiarchified, which I don't think > we will.) I didn't see the previous message, so I'm not sure exactly what problem you're referring to - but regardless of multiarch, I want the -libs packages to die in etch. They should be built from biarch source packages instead. I just didn't have time to work on that before sarge. -- Daniel Jacobowitz CodeSourcery, LLC -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: /usr/lib vs /usr/libexec
On Mon, May 09, 2005 at 02:33:32PM -0700, Thomas Bushnell BSG wrote: > Daniel Jacobowitz <[EMAIL PROTECTED]> writes: > > > On Mon, May 09, 2005 at 02:21:35PM -0700, Thomas Bushnell BSG wrote: > >> Daniel Jacobowitz <[EMAIL PROTECTED]> writes: > >> > >> > The number of directory entries in /usr/lib should not make any > >> > difference to a modern GNU linker on a modern filesystem, unless > >> > you have thousands or millions of them. > >> > >> Why? Is there magic now? > > > > What magic do you need? Most filesystems can open a file without > > doing an O(n) lookup, especially from the dentry cache. > > Huh? The dentry cache turns ls into O(n) instead of O(n^2), but that > doesn't mean that searching every item in the directory isn't still > necessary, unless the directory is hashed or stored in as a tree. You asked why the GNU linker, which does not need to be 'ls' and does not need to look at the list of files in any directory, scaled well with the size of the directory. That's the question I answered. > Surely the reason who have these different directories is to make > logical distinctions, keeping different kinds of things in different > directories. If the argument for combining libexec and lib is that > "it does no harm", then I see why we should not put *everything* into > lib. It would make it simpler. > > So the question is: why is it useful to make some distinctions > (including non-sensical ones like /usr vs. /) but not this one? That's a completely different question... which I don't think I need to answer. I was responding to your invalid criticism of the linker. -- Daniel Jacobowitz CodeSourcery, LLC -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: /usr/lib vs /usr/libexec
On Mon, May 09, 2005 at 02:21:35PM -0700, Thomas Bushnell BSG wrote: > Daniel Jacobowitz <[EMAIL PROTECTED]> writes: > > > The number of directory entries in /usr/lib should not make any > > difference to a modern GNU linker on a modern filesystem, unless > > you have thousands or millions of them. > > Why? Is there magic now? What magic do you need? Most filesystems can open a file without doing an O(n) lookup, especially from the dentry cache. -- Daniel Jacobowitz CodeSourcery, LLC -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: /usr/lib vs /usr/libexec
On Mon, May 09, 2005 at 08:39:10AM -0700, Thomas Bushnell BSG wrote: > Martin Dickopp <[EMAIL PROTECTED]> writes: > > >> It seems that Red Hat has a lot of programs under /usr/libexec that are > >> under /usr/lib in Debian. One example is /usr/lib/postfix > >> vs /usr/libexec/postfix. > >> > >> It seems to me that /usr/libexec is a better name for such things, > > > > I disagree. Why is it important to distinguish between shared libraries > > and internal binaries (i.e. programs not supposed to be called directly > > by a user)? > > lib is the place where ld searches for libraries. Linking is not > speedy, and a non-trivial amount of the time is spent slogging through > /usr/lib looking for the libraries wanted. The number of directory entries in /usr/lib should not make any difference to a modern GNU linker on a modern filesystem, unless you have thousands or millions of them. -- Daniel Jacobowitz CodeSourcery, LLC -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Minimizing ld dependencies with --as-needed
On Fri, Apr 01, 2005 at 03:09:13AM -0800, Steve Langasek wrote: > On Fri, Apr 01, 2005 at 12:53:27PM +0200, Josselin Mouette wrote: > > Le vendredi 01 avril 2005 à 02:34 -0600, Ron Johnson a écrit : > > > What are the opinions of d-d's of --as-needed? > > > > http://www.ubuntuforums.org/showthread.php?t=17287 > > > > According to this thread, the number of dependencies can sometimes > > > be slashed drastically. > > > I'm moving all my packages to use it. > > Please don't. Last I knew, this option was still labelled *experimental* > upstream -- there's no possible damage that stray lib dependencies can do to > sarge that competes with the certain damage of having *missing* library > dependencies. For the record, it isn't actually labelled as experimental upstream - but there have been some problems with it, and they were fixed in versions of binutils not yet included in Debian. I second Steve's advice; if you want to use this ld feature, wait a little longer. -- Daniel Jacobowitz CodeSourcery, LLC -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bits (Nybbles?) from the Vancouver release team meeting
On Thu, Mar 17, 2005 at 05:58:21PM +1000, Anthony Towns wrote: > Daniel Jacobowitz wrote: > >My basic idea is to have something similar to the testing migration > >scripts, which takes the decisions of the "master" copy running on > >ftp-master as an input. At a minimum: > > I think it's easiest just to assume everything's on ftp-master; for > mirroring, stuff's already planned to be split onto ftp.d.o and scc.d.o > anyway. The only reasons that wouldn't happen is if ports need > non-developers to be able to upload, or are using up lots of disk really > wastefully. OK. I'm going to keep the two logically separated, to answer possible resource constraints, but it would certainly be easier this way. > > - Packages in sub-testing should not be newer than the versions in > >testing, except on purpose. Porters need to be able to use newer > >versions when a particular version does not work on their > >architecture, but I want a by-hand element involved in that. In > >normal, non-schedule-pressured, non-crippling-bug mode, they would > >just fix the copy in the main archive and propogate that to > >testing, and from their to sub-testing. > > Okay, so we've got a new suite; is that global for all scc arches, or > separate, a la "subtesting-s390", say? The question there is "Will s390 > have a different version of the package to m68k, if one or the other is > being more aggressively maintained?" I don't know. This depends mostly on the dynamics of the ports teams and on the amount of work it turns out to be. It may be that holding up for other architectures would be just as much a problem for the s390 mantainers as it is for the core release managers; or it may be that the overhead is too high to justify doing it for less than the full set. > So, say you have "foobar 1.0" in subtesting for s390, and "foobar 2.0" > in testing and "foobar 3.0" in unstable for i386. Your buildd's been > somewhat broken for a few weeks, and you haven't built foobar 2.0 or 3.0 > yet, but you've got it working again now. What happens then? > > Do you build foobar 3.0, find out there are some s390 specific bugs, > watch it go into testing anyway, not accept it to subtesting because > those bugs need fixing, get 3.1 uploaded to unstable, built it, watch it > go into testing, and then have it go into subtesting too? > > Or do you build foobar 2.0, upload your debs to unstable, find it works > perfectly, and get into subtesting, then wait 'til 3.0 gets into testing > before building it and finding out it has problems? Both of these are plausible; the difference is whether you autobuild from unstable or testing. I would prefer the former, which means your former case. > Do you use the testing scripts, and thus aim to ensure subtesting's > dependencies are consistent, or do you just copy debs across and hope? > If the former, why bother looking at testing at all, instead of just > pulling from unstable, and calling it, say, "scc-testing-s390"? OTOH, > only pulling from testing makes it simpler to end up with something you > could call "etch" for s390. Right. I'd want to use the testing scripts, somewhat brutalized. My hope for using testing as an input is that, come freeze time, the ports would be relatively close in versions to the release architectures. In particular, it would prevent them from getting ahead. The remaining differences can be patched up by hand. > > - Internal consistency and installability would be maintained for > >the sub-testing repository in the same way we maintain them for > >testing. > >This allows the port to leverage the excellent work done by the release > >team, and not get in their way - it's completely unidirectional, > >nothing feeds back to the "parent" repository. And it allows leverage > >of the testing scripts - with some changes, that someone would have > >to pony up the time to implement, of course. > > One of the problems with this is that you wouldn't benefit from the > "hints" the release team prepares for britney; which might screw you > over completely. OTOH, dealing with smaller numbers of architectures is > easier, so maybe some of the existing automation would be more > effective; and maybe the other britney features we planned at the > meeting will make this irrelevant anyway. This is definitely a real problem. Architectures which stay very close to up-to-date might be able to take advantage of hints; I don't know how often that would work in practice. Maybe it would motivate additional work on the automation
Re: Bug#263743: Call For Help - Please support the ppc64 architecture
On Thu, Mar 17, 2005 at 01:07:05AM +, Scott James Remnant wrote: > On Thu, 2005-03-17 at 01:57 +0100, Andreas Jochens wrote: > > > On 05-Mar-17 00:10, Scott James Remnant wrote: > > > No, I would just prefer consistency. You've deliberately chosen an > > > architecture name that's jarringly different from your 32-bit variant; > > > that's a rather bold thing to do, and I think you need to justify that. > > > > The decision to use the name 'ppc64' is based on the LSB and it is > > consistent with the decision of all other distributions I know of. > > > But it isn't consistent with Debian's previous decision on the PowerPC > port. In particular, the LSB mandates "ppc32" for what we call > "powerpc". Debian did not really make a previous decision on "powerpc" port; it evolved. At the time, none of these issues existed, and powerpc seemed like the logical thing to call it. I think Andreas has given good justification for using ppc64. -- Daniel Jacobowitz CodeSourcery, LLC -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bits (Nybbles?) from the Vancouver release team meeting
On Wed, Mar 16, 2005 at 12:50:31PM +0100, Martin Schulze wrote: > > We project that applying these rules for etch will reduce the set of > > candidate architectures from 11 to approximately 4 (i386, powerpc, ia64 > > and amd64 -- which will be added after sarge's release when mirror space > > is freed up by moving the other architectures to scc.debian.org). > > This will drastically reduce the architecture coordination required in > > testing, giving us a more limber release process and (it is hoped) a > > much shorter release cycle on the order of 12-18 months. > > Since this is the first time I hear that so much of "architecture > coordination" is required for testing, could you elaborate how much > time this is referring to and which problems the release team has > faced in particular? I'd be glad if somebody could propose an > alternative solution, as dropping most architectures would be a large > regression for Debian and its community. I think that all they mean is "the complicated act of getting, and keeping, all architectures in sync in testing". For instance, getting large packages built in the same version on every architecture, discovering an architecture-specific bug, and redoing the whole thing before it or any of its dependencies can migrate to testing. Not a new problem, especially for anyone reading debian-release. > It's also an interesting thought how many architectures will suffer > from the _all dependency trap when maintainers don't care about crap > architectures anymore that won't be released at all. I imagine most of the ports would have their own copy of binary-all in this scenario. Or additional binaries would be maintained in the main binary-all. -- Daniel Jacobowitz CodeSourcery, LLC -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bits (Nybbles?) from the Vancouver release team meeting
On Wed, Mar 16, 2005 at 06:57:56PM +1000, Anthony Towns wrote: > Daniel Jacobowitz wrote: > >I've suggested (briefly) a slaved testing which tries to enforce sync > >with the main testing archive. > > Hrm, I don't think I've got any idea what that means. I hadn't thought about the details yet, but here's a stab at it. It may be completely impractical. I have zilch experience with the testing scripts themselves, just the basic principle. My basic idea is to have something similar to the testing migration scripts, which takes the decisions of the "master" copy running on ftp-master as an input. At a minimum: - Packages in sub-testing should not be newer than the versions in testing, except on purpose. Porters need to be able to use newer versions when a particular version does not work on their architecture, but I want a by-hand element involved in that. In normal, non-schedule-pressured, non-crippling-bug mode, they would just fix the copy in the main archive and propogate that to testing, and from their to sub-testing. - Some other criteria would be used to prevent migration of new packages, in addition to those used by the primary testing script. Architecture-tagged bugs in the BTS might do well for this purpose; or separate by-hand lists. - Internal consistency and installability would be maintained for the sub-testing repository in the same way we maintain them for testing. This allows the port to leverage the excellent work done by the release team, and not get in their way - it's completely unidirectional, nothing feeds back to the "parent" repository. And it allows leverage of the testing scripts - with some changes, that someone would have to pony up the time to implement, of course. -- Daniel Jacobowitz CodeSourcery, LLC -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bits (Nybbles?) from the Vancouver release team meeting
On Tue, Mar 15, 2005 at 04:00:13PM -0800, Steve Langasek wrote: > Once you start talking about having divergent packages between > architectures, a lot of the reasons I'm hearing from people about why > they want Debian to *do* releases for these archs seem to dissipate, > because they no longer have assurances that the OS is "the same" on > different hardware. If unstable-only ports aren't enough, and the > sources aren't going to match in the testing/stable versions, maybe we > start to think about wanting to implement parallel infrastructure for > these other ports, as well -- and maybe it's under the Debian umbrella, > and maybe it isn't; I think it's better if it *is* still "Debian", but I > think we need to be realistic about the fact that once we have to trim > those architectures from the list of architectures being released in > lockstep, we've removed the pressure that keeps the sources in sync and > it's no longer going to match the stable Debian that we're providing on > other architectures. I don't buy the first half of this paragraph. For me, the killer features of Debian stable releases are: - Been through some amount of settling-in time, either via a freeze or testing. This acts as an effective quality floor. - Support (medium-term, I know first hand that long-term is less than doable) from the security team. - "Is Debian". Even if it isn't the same versions of everything as some other Debian box in that other place, it's still going to work basically the same. I work on woody, sarge, and sid boxes; they all share the fuzzy Is-Debian feeling. Unstable-only ports don't do the first two. Stable ports, even if they diverge somewhat from other Debian stable releases, do all three. The more infrastructure we can provide to allow porters to take advantage of Debian's fewer-arch stabilization, the better quality the port releases will be. I've suggested (briefly) a slaved testing which tries to enforce sync with the main testing archive. Similar things could be done for stable. It's been a long time since I was on the front lines of a port, so I don't know how much manpower the ports have to work with nowadays; but I bet they could manage this much. -- Daniel Jacobowitz CodeSourcery, LLC -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: SCC proposal (was: Re: Questions for the DPL candidates)
On Mon, Mar 14, 2005 at 07:51:05PM -0600, John Goerzen wrote: > On Mon, Mar 14, 2005 at 08:14:47PM -0500, Daniel Jacobowitz wrote: > > On Mon, Mar 14, 2005 at 07:02:05PM -0600, John Goerzen wrote: > > > Really, I don't really understand all the difficulty of running > > > apt-get -b source, or pbuilder, or some such for n+1 archs as opposed > > > to just n. With a little use of ssh keys, the whole thing should be > > > completely automated. And I thought that's basically what the > > > security team does, anyway. If we keep them with a useable machine > > > (which DOES make sense as a requirement), then where is the issue? > > > > How often this works, however, is the problem. The source may not > > build cleanly everywhere. Some dependency may be broken, or not > > install properly in the build daemon, or so forth. > > Is not this supposed to be fixed before a package ever enters testing, > let alone stable? Things evolve. It may have built against an earlier version, for instance. > OK. Assuming that they are open to that. I have no reason to assume > either way, I guess. I think I can safely assure you that we are :-) > > I think what this is crying out for is a second testing setup, covering > > Perhaps, but then why not just use the existing testing setup? Because, as has been explained several times, it doesn't scale. This allows the sub-testing to be coordinated separately. Managed separately. Run on a separate archive even. -- Daniel Jacobowitz CodeSourcery, LLC -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bits (Nybbles?) from the Vancouver release team meeting
On Mon, Mar 14, 2005 at 05:12:31PM -0800, Thomas Bushnell BSG wrote: > Steve Langasek <[EMAIL PROTECTED]> writes: > > > > How can they be, since they will be off in another archive? You can't > > > decide now to put an arch in scc and at the same time say you won't > > > know whether it's in tier1 or tier2 until etch is close to release. > > > > Please re-read the proposal. Not all the architectures proposed for > > release with etch are architectures that have enough download share to > > justify keeping them on the primary mirror network; these are > > *separate*, if heirarchically related, requirements. > > Ok, I think I understand. Suppose that we have an arch that does have > enough download share, and meets every requirement but the existence > of sufficient buildds to keep up and developer machines, and that only > because hardware hasn't come available. Then it comes available, > partway through the release cycle. > > All the stuff is on scc; how do we transfer it back? Will it be easy, > or a major obstacle? > > I'm sorry if these questions are too elementary or seem obvious to > you, but it will help me understand better. The only differentiating requirement for scc, as opposed to the other "part of Debian" architectures, seems to be download share. That won't suddenly change. -- Daniel Jacobowitz CodeSourcery, LLC -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: SCC proposal (was: Re: Questions for the DPL candidates)
On Mon, Mar 14, 2005 at 07:02:05PM -0600, John Goerzen wrote: > Really, I don't really understand all the difficulty of running > apt-get -b source, or pbuilder, or some such for n+1 archs as opposed > to just n. With a little use of ssh keys, the whole thing should be > completely automated. And I thought that's basically what the > security team does, anyway. If we keep them with a useable machine > (which DOES make sense as a requirement), then where is the issue? How often this works, however, is the problem. The source may not build cleanly everywhere. Some dependency may be broken, or not install properly in the build daemon, or so forth. For security updates, using a separate pbuilder infrastructure instead of the buildd infrastructure is an interesting idea. I am not sure whether it would be workable. If someone wanted to try it, and coordinate with the buildd admins and security team about it, we could find out. > I am not even opposed to building security updates from source if I > must. However, the SCC idea seems to negate that, since their source > may no longer be the same as the official source due to per-arch > fixes. > > Not to mention that the SCC archs will *always* have later security > updates under this proposal, because they don't have access to the > same early warning that the official security team does. This isn't a useful objection. The security team could add additional members focusing on SCC; if there are a small number of responsible, interested developers, then there is no reason not to. The current members aren't magical. > > >3) For the release problem: not requiring all archs to release at once > > > > Uh, that's what we're doing. > > No, you're not permitting most archs to release at all. > > That is different from allowing them to release, but at different > times. As I read it, they are allowed to release - but they have to do their own release management. I think what this is crying out for is a second testing setup, covering the remaining architectures. Get a corporate sponsor for one of the non-release architectures to provide adequately beefy hardware. Have a team of interested people do release management on that second set of testing, possibly "slaving" it to the main "testing" - I haven't considered the technical details of that in depth, but I'd bet it could be done. Then, *poof*, a Debian/etch/Ports release is made! -- Daniel Jacobowitz CodeSourcery, LLC -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: NPTL support in 2.4 kernel series?
On Thu, Jan 27, 2005 at 10:37:34AM +0900, GOTO Masanori wrote: > (We have plan to add NPTL support for alpha, ppc and ppc64 in the > next glibc update. However, currently NPTL is not supported even > in upstream cvs on arm (EABI update), mips (tls register > discussion), hppa (Hurrah Carlos O'Donell), m68k (slow speed is > everytime big problem in computer history). It's sure that hurd > and *bsd are out of scope with NPTL.) By the time we actually do this, I hope to have both ARM and MIPS support pushed out. It's all been written, and we're starting the submission process over the next couple of weeks, I hope. -- Daniel Jacobowitz -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Linux Core Consortium
On Thu, Dec 09, 2004 at 04:42:29PM -0500, Ian Murdock wrote: > On Thu, 2004-12-09 at 15:10 -0500, Daniel Jacobowitz wrote: > > As one of the maintainers involved in Debian's toolchain, I think this > > is a terrible idea. Our needs are different than other distributions, > > we already know that from experience. The core needs are conceptually > > the same - everyone needs working libraries and tools - but the details > > we consider worth fixing are not. > > Can you provide examples? I'm not trying to be dense--I'm simply > trying to understand what, if anything, is so irreconcilable, as > some of you seem to be suggesting is the case here. I'll try. My first concern is the architectures issue. Bruce made a comment along the lines of "LCC would have to accept patches for architectures it didn't care about, but would not be required to build them". But it's not that simple; there are always tradeoffs. Some of the issues are rate of change (esp. w.r.t. release schedules), modifications to common code, and increased pressure on patch review/approval. Debian has a different set of use cases than most Linux distributions. The first example that comes to mind is in-place upgrading, and some packages have horrible hacks in them to support this. Other LCC members might reasonably object to the baggage. > > So during the sarge release > > cycle, when we need to make updates to fix an RC bug in glibc that > > doesn't affect any platform shipped by any other member of the LCC, > > which has moved on to new development according to some other member's > > release schedule, what would we do? We'd have to rebuild them anyway. > > There goes our "common binaries" advantage. > > > > >From the web site, I see that LCC has a limited set of architectures > > targeted anyway. Debian will continue to use common source for all > > architectures. That will make working with the LCC difficult. > > First, because the four founding members are commercial entities, > we're mainly interested in the architectures that are predominant > in commercial environments. That's all about aligning resources > with relative priorities and certainly isn't a statement that we > will never support anything else. If resources and priorities > change, the set of supported architectures could change as well. Of course. I understand the point of supporting commercially viable architectures; Debian is the alternate extreme. > Second, the common core will have a release schedule corresponding to > the release schedule of the LSB standard (roughly every 12-18 months), > and the members' release schedules will be synchronized to match that. Precisely. You've signed Debian up for "externally" (quotes, because we would be participants, but there will be strong external pressures) managed schedules for dozens of core packages. And some external pressure on overall release schedule, because of the sharp dropoff in staleness. For example, suppose GNOME is part of this managed set. The other members, primarily commercial distributions with greater control over their schedules than Debian has, want to wait off on upgrading to GNOME 3.4 until their next release cycle. Debian is going to be releasing in three months and two dozen active GNOME developers are heartbroken by the idea. It's not an idle example - that happened for this release cycle. Heroic effort on the part of both GNOME maintainers and release managers got it in under the wire, and it will make an IMHO big difference to the out-of-the-box usability of sarge. Right now, if you have a brilliant idea that you want to implement and integrate all through Debian, there's a clear set of the relevant maintainers to convince. Expanding that set to include lots more people, and people with sharply different needs and pressures, is not something I consider good for the future of Debian. The reason I am a Debian developer is because Debian is responsive to my needs; it's (relatively speaking) easily swayed onto a better course when one presents itself. As long as there's someone willing to do the work, the work can be done. Also, the multiple-architectures issue is a big one for the imposed schedules. Architectures that only Debian, out of all the LCC members, cares about will be only lightly tested by the time any given LCC release is made. I estimate a dozen or more substantial changes to any "released" packages before Debian could use them, taking many months to come together. > > Using binaries from LCC would also run against the Debian principle of > > always building Debian packages from their source before uploading > > them. That's a big deal. > > I'm not sure I fo
Re: Linux Core Consortium
On Thu, Dec 09, 2004 at 12:40:29PM -0500, Ian Murdock wrote: > I've been thinking about the "obstacles" for a long time, and I'm > convinced they're not as large as they might appear at first glance. > The end goal of the LCC is actually very simple: to create a single > set of binaries that constitute an implementation of the LSB > standard; to use that single set of binaries as a "common core" > for as many Linux distributions as possible; and to develop the > common core in an open and collaborative fashion, so the end result > is owned by the community, not by one or two commercial players. > > There's only one preconceived notion: that we need a single set of > binaries, because that's what ISVs and IHVs require for the result to be > viable. The LCC doesn't mandate the use of RPM (only to the extent the > LSB does, which Debian can already address). The LCC doesn't mandate > what "compatibility" means as regards package naming or library > versioning or anything else--it only says we need to agree on > *something*, because agreeing on something buys us a lot, whereas > continuing to differ on such minor things doesn't serve any purpose > other than to divide us and set the stage for one or two companies > to run away with commercial Linux via ISV/IHV certification lock-in. Disclaimer: I have not gone looking for any information about the Linux Core Consortium outside of this thread. It would have been nice to include a link: http://www.mandrakesoft.com/lcc Of course, there's not much there. Oh, here's some more: http://componentizedlinux.org/lsb As one of the maintainers involved in Debian's toolchain, I think this is a terrible idea. Our needs are different than other distributions, we already know that from experience. The core needs are conceptually the same - everyone needs working libraries and tools - but the details we consider worth fixing are not. Common binaries are only useful with fixed releases and versioning of the common binaries, because otherwise you have a dozen different sets of your "common" binaries running around. So during the sarge release cycle, when we need to make updates to fix an RC bug in glibc that doesn't affect any platform shipped by any other member of the LCC, which has moved on to new development according to some other member's release schedule, what would we do? We'd have to rebuild them anyway. There goes our "common binaries" advantage. >From the web site, I see that LCC has a limited set of architectures targeted anyway. Debian will continue to use common source for all architectures. That will make working with the LCC difficult. Using binaries from LCC would also run against the Debian principle of always building Debian packages from their source before uploading them. That's a big deal. I'm sure other members of the LCC have similar concerns - or will. What are they doing about them? Are the other companies listed as "supporting" the Linux Core Consortium interested in this "common binaries" plan? Their support quotes only explicitly support the Linux Standard Base. I see primarily scheduling, maintenance, coordination, and change control problems. > Technical details aside, it all comes down to the question: Is getting > involved worthwhile? As I said at the outset, the LCC has a lot to > offer Debian, and likewise, Debian has a lot to offer the LCC as well. > > How does Debian benefit from LCC? It's a route to the ISV and IHV > certifications that Debian has always lacked, and it is the lack of > these certifications that's preventing Debian from standing alongside > Red Hat and Novell/SuSE in the commercial space despite comparable > (and arguably greater) popularly. The industry simply doesn't know how > to engage us, and LCC provides them with a vehicle for doing that. We would never have a common kernel with these vendors anyway - they don't even have a common kernel with each other. My experience tells me that would be a big barrier to certification of any kind. There's plenty more than certification keeping Debian from standing along side enterprise distributions in the commercial space. If there is merit to the common binaries, I think we would get more mileage from it by supporting them as we do the LSB: with separate packages on top of the Debian base system. -- Daniel Jacobowitz
Re: Why are there no /usr/lib/debug/*.so in *-dbg packages ?
On Tue, Nov 09, 2004 at 07:46:21PM +0100, Raphael Bossek wrote: > Hi all, > > I've checked many *-dbg packages and can not avow oneself > why only /usr/lib/debian/*.a files are provided by *-dbg > pacakges? It would be a advantage to have also *.so files > as non-striped version for development purposes. See dh_strip --dbg-package for the correct way to do this now. > Is there a policy which prohebit *.so files in /usr/lib/debug ? > What is the real reason ? > > The same is for *-prof packages. There are only *_p.a files > but no *_p.so. Habit, I suppose. -- Daniel Jacobowitz
Re: udev and /sys mounting [was: mounting tmpfs (and sysfs) defaultly in sarge?]
On Thu, Dec 18, 2003 at 06:39:13PM +0100, Marco d'Itri wrote: > On Dec 18, GOTO Masanori <[EMAIL PROTECTED]> wrote: > > >OK, I would like to rename from /etc/init.d/devpts.sh to > >/etc/init.d/mountfs, because (1) for example there is mountnfs which > >mounts nfs (2) umountfs in initscripts un-mounts filesystems, so > >"mountfs" makes a name pair. Any comments? > Looks good. OTOH, maybe it's not a good idea to pair mountfs with > umountfs, as they operate on different kinds of file systems, so > mountkernfs could be a possible alternative. Yes, I agree with Marco. -- Daniel Jacobowitz MontaVista Software Debian GNU/Linux Developer
Re: Failed build on mips target: need help
On Sun, Dec 14, 2003 at 08:43:53PM +0530, Amit Shah wrote: > Hi, > > I'm the maintainer of the libfilesys-smbclient-perl module. The mips build > fails with this error: > > dpkg-deb: building package `libfilesys-smbclient-perl' in > `../libfilesys-smbclient-perl_1.5-1_mipsel.deb'. > dpkg-genchanges -B -mDebian/MIPSEL Build Daemon <[EMAIL PROTECTED]> > dpkg-genchanges: arch-specific upload - not including arch-independent > packages > dpkg-parsechangelog: error: cannot open debian/changelog to find format: > Permission denied > dpkg-genchanges: error: syntax error in parsed version of changelog at line > 0: > empty file > > The entire log is here: > http://buildd.debian.org/fetch.php?&pkg=libfilesys-smbclient-perl&ver=1.5-1&arch=mipsel&stamp=1071078382&file=log&as=raw > > What could be the error here? It seems to build fine on all other archs other > than mipsel and mips. This is normally a transient error; something got confused. -- Daniel Jacobowitz MontaVista Software Debian GNU/Linux Developer
Re: Revival of the signed debs discussion
On Thu, Dec 04, 2003 at 02:41:43PM -0500, Matt Zimmerman wrote: > On Thu, Dec 04, 2003 at 12:28:41PM -0600, Manoj Srivastava wrote: > > > On Thu, 4 Dec 2003 11:47:50 -0500, Matt Zimmerman <[EMAIL PROTECTED]> said: > > > > > What kind of real world attacks do signed debs prevent? Not a > > > compromised buildd, or a compromised maintainer's workstation. > > > > It would allow me to copy .debs around with other people, or > > use .debs not made available through the usual chain of security; as > > long as the author hapens to be in my web of trust. > > What kind of real world attacks do signed debs prevent? > > The only one which comes to mind is a rogue Debian developer that you do not > wish to trust, even though the project trusts him. Someone pretending to be someone Manoj trusts, offering him a corrupted .deb offline? -- Daniel Jacobowitz MontaVista Software Debian GNU/Linux Developer
Re: MIPS port backlog, autobuilder machines and some arrogance
On Sun, Nov 16, 2003 at 12:10:14PM -0600, Marcelo E. Magallon wrote: > On Mon, Nov 17, 2003 at 12:53:39AM +1100, Martin Michlmayr - Debian Project > Leader wrote: > > [ Responding to this since I've been BCCed. ] > > Oh, nice. If hadn't been Bcc'ed you wouldn't respond? That's > reasuring, since you seem to be one of the few persons who's got some > information on the subject and are somewhat willing to talk. > > > Also, while we are covering this topic, let me mention that mips is > > not a "door stop" architecture. While most machines which were > > _very_ powerful in the past are fairly dated now (e.g. SGI Indy), > > mips CPUs are actively being developed. There are CPUs with 2 cores > > and > 1 GHz frequency. > > Care to give an example of one of this "_very_ powerful" machines, > which are in production and where Linux actually runs? The "_very_ > powerful" SGI Indy was attractive at its time only because of some of > the graphics boards it supported, none of which are supported on Linux. > There are some newer "_very_ powerful" machines with MIPS processors, > but AFAIK noone has actually ported Linux to them. There's one "_very_ > powerful" machine using MIPS processors which supposedly will be made > available with Linux on it in the future, yet it's already shadowed by > machines using AMD64 processors which happen to be available now and > where Linux runs now with support for all the functionality of the > hardware. > > Just curious... There's one on my desk. It's an embedded board produced by Broadcom, complete with dual cores, IDE, and dual gigabit ethernet. MIPS, Inc. has a similar board; Debian has one of these somewhere, IIRC. These little fellows have more computing power than our PPC build daemon. The machines you are likely to be thinking of are things like the SGI R12000; the conventional workstation-type MIPS platforms have much worse support than the embedded ones, but the embedded ones pack a serious punch nowadays. -- Daniel Jacobowitz MontaVista Software Debian GNU/Linux Developer
Re: POSIX capabilities patch
On Tue, Nov 11, 2003 at 07:11:47PM -0700, Hans Fugal wrote: > In order to get realtime capabilities, jackd can be run with a suid > wrapper (jackstart), instead of being run as root, if the following > patch is applied to the kernel: > > --- capability.h.old2003-11-11 19:57:49.0 -0700 > +++ capability.h2003-11-11 19:56:55.0 -0700 > @@ -303,8 +303,8 @@ > > #define CAP_EMPTY_SET to_cap_t(0) > #define CAP_FULL_SETto_cap_t(~0) > -#define CAP_INIT_EFF_SETto_cap_t(~0&~CAP_TO_MASK(CAP_SETPCAP)) > -#define CAP_INIT_INH_SETto_cap_t(0) > +#define CAP_INIT_EFF_SETto_cap_t(~0) > +#define CAP_INIT_INH_SETto_cap_t(~0) > > #define CAP_TO_MASK(x) (1 << (x)) > #define cap_raise(c, flag) (cap_t(c) |= CAP_TO_MASK(flag)) > > Would it be inappropriate to create a kernel-patch package for this > patch? What should I call it? (I'm thinking kernel-patch-rtcap or > kernel-patch-capability) I would want considerably more information on the security implications of allowing CAP_SETPCAP than either of those documents provides, if I were you. The POSIX capability code is notoriously subtle and prone to anger. -- Daniel Jacobowitz MontaVista Software Debian GNU/Linux Developer
Re: Problem with libc6 and 'chgrp / chown' remains ...
On Tue, Nov 11, 2003 at 03:11:50PM -0600, Jesse Yurkovich wrote: > Seems that we have: > ii libc6 2.3.2-9GNU C Library: Shared libraries and Timezone > ii libc6-dev 2.3.2-9GNU C Library: Development Libraries and Hea > > I'm guessing this was released in err then? A new apt-get update doesn't > indicate > any other upgrades. This is again with both a testing and an unstable machine. > > Reading Package Lists... Done > Building Dependency Tree... Done > The following packages have been kept back > imagemagick libpango1.0-0 libpango1.0-common libxft2 w3m > 0 upgraded, 0 newly installed, 0 to remove and 5 not upgraded. > > Thanks for looking back into this! > -Jesse > > P.S. Hope the mail gets threaded right ... as I was not CC'd but happened to > notice the discussion. Then your unstable mirror is broken. Might want to investigate that. -- Daniel Jacobowitz MontaVista Software Debian GNU/Linux Developer
