Bug#278027: RFP: ibm-acpi -- Driver for IBM laptops to extend ACPI support
Package: wnpp Severity: wishlist * Package name: ibm-acpi Version : 0.7 Upstream Author : Borislav Deianov <[EMAIL PROTECTED]> * URL : http://ibm-acpi.sourceforge.net/ * License : GPL Description : Driver for IBM laptops extending ACPI support on Linux This driver extends the ACPI subsystem of IBM Thinkpads running Linux to support new features that wouldn't otherwise be available.
Re: Bug#278027: RFP: ibm-acpi -- Driver for IBM laptops to extend ACPI support
Matthew Garrett <[EMAIL PROTECTED]> - Sun, Oct 24, 2004: > This has been integrated into the acpi.sf.net patch, so is fairly likely > to end up in the mainstream kernel before too long. Oh never read of that, do you have some pointers? Are you sure it's the same driver? Thanks! Regards, [ BTW: your email didn't reach debian-devel, but I see it was Cc:ed, is this normal? ] -- Loïc Minier <[EMAIL PROTECTED]>
Re: ACPI problems with kernel 2.6.x for Dell Inspiron 4100
Hi, Svante Signell <[EMAIL PROTECTED]> - Mon, Nov 15, 2004: > For kernels 2.4.x ACPI is automatically disabled: > ACPI: Subsystem revision 20040326 > ACPI: Interpreter disabled. > while kernels 2.6.x enables it: > ACPI: Subsystem revision 20040816 > ACPI: Interpreter enabled I think you're slightly off-topic, I don't see the point of harassing debian-devel with such messages, there's a debian-kernel list, or acpi and kernel related lists outside of Debian. Did you check the upstream BTS? > The battery monitor shows the following problem: > Can't access ACPI events in /var/run/acpid.socket! > Make sure the ACPI subsystem is working and acpid daemon is running. And? Did you check wether acpid was running? Anyway, try disabling ACPI IRQ detection with "acpi=noirq", I have no idea wether that will help though. Regards, [ reply-to set to myself ] -- Loïc Minier <[EMAIL PROTECTED]>
Re: SVG icons
Eric Lavarde <[EMAIL PROTECTED]> - Wed, Dec 08, 2004: > To summarize, I think recommending SVG would require a change to the policy. It's defined in the _Menu_ Policy. I think the people maintaining the Debian menu system are best placed to tell what should be allowed or not. Additionally, there are other menu systems parallel to the Debian menu system, and SVG use might be permitted by other systems, hence the OP should clarify his question. Regards, -- Loïc Minier <[EMAIL PROTECTED]>
Re: strange (or unexplainable) permissions on /var/log/*
martin f krafft <[EMAIL PROTECTED]> - Sun, Dec 12, 2004: > I am trying to make sense of /var/log/*. I noticed the following > peculiarities: > - user.log is 0640. However, aren't "user" messages possibly > relevant to users? If so, I suggest making the file 0644. I think this is "user" as in "userland", simply because this is the default level for programs. > - uucp.log, mail.* and news/* are 0644. I would say that these > should be 0640. I think these are 0640 with syslog-ng! ;) > - why is dmesg 0644? This is not really a problem, but do users > need access to the boot messages? May be because the information is available via syslog(2) too? (This might be false with selinux, no idea.) -- Loïc Minier <[EMAIL PROTECTED]>
Re: self-depending packages
On Mon, Feb 28, 2005, Frank Küster wrote: > What's the bug number? <http://bugs.debian.org/296175> -- Loïc Minier <[EMAIL PROTECTED]> "Neutral President: I have no strong feelings one way or the other." -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Please use ${misc:Depends} in all your packages
On Wed, Nov 16, 2005, Josselin Mouette wrote:
> These packages should use
> dh_gconf, build-depend on debhelper >= 4.2.13 and depend on
> ${misc:Depends}. Packages using cdbs just have to use the gnome.mk
> template to benefit of it.
Thanks Joss, I hijack this perfect occasion to remind people they
should use ${misc:Depends} whenever possible (almost always, except
maybe on meta-packages), even if it causes warnings. Please see the
debhelper(7) man page for details on why this is useful. This is what
caused the most RC bugs in GNOME packages lately.
(PS: Please note that even if you use CDBS' gnome.mk, you have to add
${misc:Depends} to your deps.)
Cheers,
--
Loïc Minier <[EMAIL PROTECTED]>
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Uploading amd64 packages
On Mon, Nov 21, 2005, Goswin von Brederlow wrote: > There are some implementation details that someone would have to fix > first [...] > So while theoretically source only uploads would be great practically > there are problems. I sure hope patches would be welcome though. Well, if Ubuntu implemented it, it might be wiser to try resyncing with their improvements instead. -- Loïc Minier <[EMAIL PROTECTED]> -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: poppler maintenance
On Wed, Dec 28, 2005, Frank Küster wrote: > Now I've learned that poppler has just been orphaned > (http://bugs.debian.org/344738) and that the sources are already in the > pkg-gnome svn repository. Will you maintain the package as a team? (It seems this question is now answered by the adoption of the package by ondrej.) -- Loïc Minier <[EMAIL PROTECTED]> -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Need for launchpad
On Fri, Jan 06, 2006, Frans Jessop wrote: > Ubuntu's launchpad is amazing. Do you think it would be helpful if all > DD's worked through it on their projects? Wouldn't that keep things more > organized and efficient? Or perhaps Debian could build its own version of > launchpad which is better. Again, I think it would do a good job keeping > everything organized an efficient. In my experience of last week, some parts are still buggy; the software needs to mature a bit. I dream of the day I'll see patches from Fedora or Ubuntu one click away from the list of bugs of Debian packages. (I don't think the "non-free" argument is here of importance considering it's a web service, in the same way as Google or buildd.net. I shall get flamed for these remarks.) -- Loïc Minier <[EMAIL PROTECTED]> Current Earth status: NOT DESTROYED -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: gconf transition
Hi, On Fri, Jan 06, 2006, Alejandro Bonilla wrote: > /usr/lib/libgconf2-4/gconf-sanity-check-2: error while loading shared > libraries: libpangocairo-1.0.so.0: cannot open shared object file: No such > file or dir > gconf-sanity-check-2 did not pass, logging back out I've filed a serious bug on gconf for now, but this might not be a _gconf_ bug. Thanks for your report, -- Loïc Minier <[EMAIL PROTECTED]> -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bug#346528: ITP: gnome-clipboard-daemon -- keeps the content of your X clipboard in memory so the clipboard won't get lost even after you close the application you copied from
On Sun, Jan 08, 2006, Joe Wreschnig wrote: > You probably also meant 'Debian GNOME Maintainers > <[EMAIL PROTECTED]>'. preferably: [EMAIL PROTECTED]; pkg-gnome-maints is more of a bug subscription list. -- Loïc Minier <[EMAIL PROTECTED]> Current Earth status: NOT DESTROYED -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#348775: general: terminal emulators' alternatives settings' priorities annoy users
Hi, On Wed, Jan 18, 2006, Simon Richter wrote: > I'm unconvinced that bumping the priority on the other terminal > emulators is an adequate solution, hence I'm opening this "general" bug > for discussion on how to reflect individual users' choices properly. We had a similar problem for GNOME recently, but not on the terminal emulator front, it was with web browsers. Rationale: you don't want to see konqueror launched as the default browser in GNOME but you want GNOME to be integrated with Debian. The www-browser and x-www-browser alternatives provide an useful mean for classing browsers system-wide with a priority. The sensible-browser script is an useful entry point to launch the most suitable browser from the current environment. sensible-browser will use the environment to guess what browser or alternative to launch (browsers in $BROWSER, x-www-browser, www-browser in xterm, www-browser). It is simple to extend this scheme with: - gnome-www-browser for browsers with GNOME support (epiphany-browser, galeon, firefox-gnome-support, ...) - check for $DISPLAY and eg. $GNOME_DESKTOP_SESSION_ID in sensible-browser to decide to launch gnome-www-browser or default to x-www-browser These changes were commited in galeon and epiphany's SVN, the changes to sensible-browser and to firefox remain to be done. Of course, this could be followed for KDE too. Simon, would this help with the problem you mentionned? Cheers, -- Loïc Minier <[EMAIL PROTECTED]> Current Earth status: NOT DESTROYED
Re: Implicition declarations of functions and bugs
Hi, On Fri, Jan 20, 2006, Samuel Thibault wrote: > Maybe the debian policy should require > -Werror-implicit-function-declaration in CFLAGS so as to avoid such > issue? Following that path would lead to -Wall -Werror :-P I personally received some bug reports by Dann Frazier (dannf) for warnings in build logs likely to cause runtime problems. I think it's the way to do it: someone maintains scripts parsing buildd logs for mistakes and reporting bugs when appropriate. Thanks dannf for your work in this matter. It might be nice to maintain such scripts under some .debian.org machine to share the burden and ensure long-term availability of the tool, I have no idea whether this is already the case or not. Bye, -- Loïc Minier <[EMAIL PROTECTED]> Current Earth status: NOT DESTROYED -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#348775: general: terminal emulators' alternatives settings' priorities annoy users
Hi, On Fri, Jan 20, 2006, Simon Richter wrote: > And GNOME would by default be configured to launch gnome-www-browser, > thus solving the problem for GNOME users who do not set any other > browser in gnomecc. The question for me would be whether this affects > people who use neither GNOME nor KDE (the browsers optimized for a > specific environment could then be demoted to some lower priority than > the non-specific ones, perhaps?) GNOME could then be configured to launch either sensible-browser or gnome-www-browser (my preference would go to sensible-browser because it makes sense system-wide, not only under GNOME). I'm not sure about demoting the priorities. I think priorities should decrease with the number of users because the more specific a package is (in terms of number of users) the more likely you want it to be the default, but I suppose there's no general rule, and it's difficult to measure the importance of launching a browser matching the current environment with respect to its popularity. > > These changes were commited in galeon and epiphany's SVN, the changes > > to sensible-browser and to firefox remain to be done. > You mean, that they now register as an alternative for gnome-www-browser? epiphany-browser and galeon do, yes. > > Of course, this could be followed for KDE too. > It should not be difficult to get that done. I had somehow expected that > the bug report and any followups are forwarded to -devel to spark > discussion, so I'm explicitly forwarding it there. My response went through debian-devel when I Cc: the bug report, so I'm continuing this way. > Not entirely, since it isn't limited to browsers or terminals. Many > users have personal preferences about things that are currently handled > through the alternatives system, and the sysadmin's choice (or > non-choice, as in the "bumping priorities" scenario) will affect them. Yes. However, I consider that the system command sensible-browser is user-configurable (via $BROWSER) and the GNOME environment is user-configurable (via gconf settings), so for the browser choice front system-wide and in GNOME, I'm satisfied with the way of things. > For example, everytime a GNOME or KDE application launches, a lot of > dotfiles will be created for me, so I'd like to avoid this as much as > possible as I will only have to clean up afterwards. Hmm, this sounds like a whole new class of problems. Cheers, -- Loïc Minier <[EMAIL PROTECTED]> Current Earth status: NOT DESTROYED
Re: [Pbuilder-maint] Re: A bit of experience after having updated some packages to use pbuilder-test testsuite engine.
Hi, On Tue, Jan 24, 2006, Junichi Uekawa wrote: > I've checked out xnee, I've noticed that the info documentation was > not properly installed, and provided a patch. Looked over the BTS, > tried running, found the same error as bug 315736. Curious of xnee, I installed it to try out too, I was hit by the same error, launching in -v suggested the program was stopping after "closing down while loop in async loop", I grepped for that in the source and found it would exit after a variable (presumably the number of events to record) would reach 0, this var being initialized to 100. Try running: xnee --record --mouse --keyboard --future-clients --out rec.xnl \ --100k-log you should have room for more events. In general, keyboard and mouse record and replay worked fine here, but I did not particularly configure xnee for special cases like compose keys or meta keys, the biggest problem being that the documentation is a bit confuse to me. I think that this program is a bit low-level for the tests you might want to achieve, and it exposes various problems to the test suite that are not very interesting: it has to follow strict timings, and might not be able to replay what you did as fast as you want it to. I've found dogtail[1] to be quite interesting, perhaps it is the good layer for the integration of functional checks in your packages? Cheers, [1] <http://people.redhat.com/zcerza/dogtail/> -- Loïc Minier <[EMAIL PROTECTED]> Current Earth status: NOT DESTROYED -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#349693: ITP: gst-fluendo-mp3 -- MP3 decoder plugin for GStreamer
Package: wnpp Severity: wishlist Owner: Loic Minier <[EMAIL PROTECTED]> * Package name: gst-fluendo-mp3 Version : 0.10.0 Upstream Author : Jan Schmidt <[EMAIL PROTECTED]> * URL : http://www.fluendo.com/resources/fluendo_mp3.php * License : MIT Description : Fluendo mp3 decoder GStreamer plugin This GStreamer plugin permits decoding of MPEG 1 audio layer III streams. It is derived from the ISO MPEG dist10 reference package. . This plugin differs from the GStreamer MAD plugin in that it doesn't depend on a GPL library. . http://www.fluendo.com/resources/fluendo_mp3.php -- Loïc Minier <[EMAIL PROTECTED]> Current Earth status: NOT DESTROYED
Re: Bug#349693: ITP: gst-fluendo-mp3 -- MP3 decoder plugin for GStreamer
Hi, On Tue, Jan 24, 2006, Joe Wreschnig wrote: > AFAIK that's only if you want to distribute their binary. If you want to > distribute their source, then that's just the MIT license. Yes, that's how I see it too. > Plenty of GPLd applications in Debian still use GStreamer, so this > doesn't solve a real problem. I think MAD support is in the "ugly" plugins precisely because it has a GPL dep (libmad). The fluendo mp3 plugin does not "taint" GStreamer. #317129 relates a similar problem. > 1) -ugly get past NEW, we get MAD, users get MP3 decoding, situation > stays as its been for years, or > 2) We take the patent issue seriously, and drop all MP3 support. > (Speaking with my hat as a DD, and as upstream maintainer of an MP3 > player that uses GStreamer and doesn't want to deal with two sets of MP3 > decoding bugs.) I agree in general with your opinion, but I want to emphasize that I'm not preparing fluendo-mp3 _because_ ugly is still in NEW. It's only the more open license of fluendo-mp3 which motivated this decision. Cheers, -- Loïc Minier <[EMAIL PROTECTED]> Current Earth status: NOT DESTROYED -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Reset of limits with su / new session
Hi, On Tue, Jan 17, 2006, Reuti wrote: > while wondering about missing ulimits for an interactive session > scheduled by SGE (SUN GridEngine) to a node in a cluster running on > Debian (which is working fine with other Linux distributions), I also > found, that each user can increase his limits again by a simple su to > his own account: Please file a bug against the relevant package and open a discussion with the maintainer. If this causes problem in a mixed Linux environment, it's worth reporting it. Beside, I couldn't find any documentation of the reason for that patch being only in Debian nor why it was included in the first place (I checked the Debian changelog, and the package itself, all I saw was "Allow explicit limits for root. Also, remove limits on su."). Cheers, -- Loïc Minier <[EMAIL PROTECTED]> Current Earth status: NOT DESTROYED -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Change in Katie's messages
> > It seems the headers Katie included when closing bugs of an uploaded > > .changes file have been removed, they used to be: To clarify, I meant the message the submitter receives. > [1] > http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=352047;msg=24;mbox=yes I can't find any x-debian* header in there, even when I download the bug's mbox and look for x-debian* headers. -- Loïc Minier <[EMAIL PROTECTED]> Current Earth status: NOT DESTROYED -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Change in Katie's messages
Hi, It seems the headers Katie included when closing bugs of an uploaded .changes file have been removed, they used to be: X-Debian-PR-Message: they-closed 348721 X-Debian-PR-Package: xen-tools X-Debian-PR-Keywords: These messages included a copy of the original report verbatim in the body, now the original report is attached as message/rfc822. Did I miss the announce? If not, could some Katie-Message-Type header be added? Thanks, -- Loïc Minier <[EMAIL PROTECTED]> Current Earth status: NOT DESTROYED -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#354443: ITP: gnonlin -- non-linear editing module for gstreamer
Package: wnpp Severity: wishlist Owner: Loic Minier <[EMAIL PROTECTED]> Hi, I intend to package gnonlin. * Package name: gnonlin Version : 0.10.0.5 Upstream Author : Wim Taymans <[EMAIL PROTECTED]>, Steve Baker <[EMAIL PROTECTED]>, Edward Hervey <[EMAIL PROTECTED]> * URL : http://gnonlin.sourceforge.net/ * License : LGPL Description : non-linear editing module for gstreamer Gnonlin is a set of GStreamer elements to ease the creation of non-linear multimedia editors. It works together with the GStreamer multimedia framework to give developers a powerfull and flexible set of tools for quickly assembling applications which needs to handle non-linear multimedia editing. Please note this package is required to build pitivi (#291069). I intend to start from the Ubuntu packages and to host the packaging files under pkg-gstreamer, maintainers or prospective maintainers are welcome. Cheers, -- System Information: Debian Release: testing/unstable APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.15-1-686 Locale: [EMAIL PROTECTED], [EMAIL PROTECTED] (charmap=ISO-8859-15) -- Loïc Minier <[EMAIL PROTECTED]> Current Earth status: NOT DESTROYED
Re: Incomplete Upload
Hi, On Tue, Mar 07, 2006, Marco Bertorello wrote: > I've recived this mail > http://pastebin.com/588778 > about an incomplete upload. Someone probably tagetted the upload to Debian, while it should have been uploaded to an internal host. Given the version number (2.1-1law1) this looks like a local rebuild (perhaps with custom changes), and might have been done by someone named Law or for an organisation named Law. There's at least a maintainer named Law, so this is quite likely. Don't worry about it, your sponsor can remove the files by uploading a commands file to rm the rests, or wait until these are automatically removed. Cheers, -- Loïc Minier <[EMAIL PROTECTED]> Current Earth status: NOT DESTROYED -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: library packaging doc...
Hi, Andreas Metzler <[EMAIL PROTECTED]> - Wed, Jan 26, 2005: > It is already linked from deveopers reference. It would be nice to have a package for this guide, for example to request fixes and to make something official out of it. The author seems to be Junichi Uekawa, dancer at debian, and is hence a logical packaging candidate. O:-) Junichi, do you have packaging plans for your guide? Should I fill an RFP on it? Bye, -- Loïc Minier <[EMAIL PROTECTED]> "Neutral President: I have no strong feelings one way or the other." -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: library packaging doc...
Hi, "Marcelo E. Magallon" <[EMAIL PROTECTED]> - Sat, Jan 29, 2005: > What I'm saying is that -- in the same way that some people insist on > Debian Policy to be followed blindly -- there are already some people > insisting that this document be followed blindly. "Raising" the status > of it to something more "official" would make things only worse. It's a vicious circle: the actual document can't be the official reference in its current state, so you don't want a package / debian.org web page / BTS entry for the document, so the documentation can't be corrected easily etc. (Sorry if I misunderstood some parts of the discussion). I feel documentation lacks in this domain, and this documentation is better than nothing. I agree it might be wrong on some points (or so I was told), and I propose that this guide should start with a warning that is is currently worked on, and did not reach an official state yet (something like "BETA" in red in the name should do). Would this documentation with a warning it's still beta be acceptable to enter the archive and be linked to in the devel/ section? This might allow others to contribute to the doc constructively by submitting patches, or filing bugs on the various topics that might be discussed. Bye, -- Loïc Minier <[EMAIL PROTECTED]> -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Getting rid of circular dependencies
On Fri, Jun 24, 2005, Bill Allombert wrote: > Following a post to Debian-Devel-Announce, I would like to > discuss getting rid of circular dependencies. FYI, I've removed the galeon/galeon-common in galeon 1.3.21-4 in may, and the gedit/gedit-common in 2.10.3-2 (pending an upload). Shame on me for not doing this pre-sarge when Nicolas Boullis reported the bug. Bye, -- Loïc Minier <[EMAIL PROTECTED]> "Neutral President: I have no strong feelings one way or the other." -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: GCC 4.0 as the default GCC / C++ ABI change
Hi, On Thu, Jul 07, 2005, Steve Langasek wrote: > > A package which I am about to sponsor (plotutils) has CFLAGS += -mieee > > for alpha. Does the above mean it is ok to remove that now? > * Apply revised patch to make -mieee the default on alpha-linux, > and add -mieee-disable switch to turn the default off (closes: #212912). > (Tyson Whitehead) I had that very same customization for alpha *and* for sh builds, I didn't see the same customization for sh. Is it safe to assume gcc-4.0 will work at its best under sh too? (The package is Galeon.) Bye, -- Loïc Minier <[EMAIL PROTECTED]> "Life is like a sewer - what you get out of it depends on what you put into it." -- Hen3ry -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Why does Ubuntu have all the ideas?
On Fri, Jul 28, 2006, Manoj Srivastava wrote: > When everyone is responsible for something, no one is > responsible. If everyone is motivated to work on the distribution and fix bugs in the distribution, it doesn't change the global amount of work that we can produce in fixing bugs. The release team will always give the green flag for a release anyway, so they will be the final judge, and if something is not perfect, and they think it is important, they will say so, and one of the gazillions of developers motivated enough by the release will fix it. -- Loïc Minier <[EMAIL PROTECTED]> -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Why does Ubuntu have all the ideas?
On Sat, Jul 29, 2006, Manoj Srivastava wrote: > Nice state of Utopia. Bu of course, everyone is not uniformly > motivated, and people's motivation is not static, it changes over > time, real life has a trendency to sometimes intrude, --- so the > reality is far from everyone is all equal and interchangeable cogs in > the happy happy debian machine. Utopia which is working pretty nicely with Ubuntu... And the argument that you advance are more in favor of my mode of working: if people's motivation is not static, it is even better not to have to rely on people to work on their packages and to let everyone do so. > > The release team will always give the green flag for a release > > anyway, so they will be the final judge, and if something is not > > perfect, and they think it is important, they will say so, and one > > of the gazillions of developers motivated enough by the release > > will fix it. > I don't know how this applies to the team-or-no-team question > one way or the other. Are you implying one may fuck up to one's > hearts content since the super-uber release team shall fly in to save > the day? No, I already mentionned that I think some people are fucking things too greatly and why I wouldn't consider open NMU a good thing right now in Debian; I won't repeat the arguments here, but I simply think it's not possible "as is" in Debian right now. However, would this be possible, I consider it would be the rold of the release team to block the release until the bugs which matter are fixed: surprise, this is what they do right now! I think you're imaginating things based on what I said which are not correct simply because we are both talking on a to high level. In other words, we're both loosing our time if we can make so stupide misunderstandings. -- Loïc Minier <[EMAIL PROTECTED]> -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: lilypond and python
On Sat, Jul 29, 2006, Thomas Bushnell BSG wrote: > Actually, I didn't make those "packaging mistakes"; the previous > maintainer did. « "The previous maintainer did the mistakes" is the refrain of people who don't want to fix their packages. » :-P > You seem to think this is a battle, in which there is a winner and a > loser. I don't. You seem to read my brain. Seriously, WTF are you writing? > > I heard from multiple sources that the problem with the new upstream > > release was not at all caused by the default python version -- as you > > claimed -- but either by a higher guile requirement. > No, it requires *both* the newer Python *and* the newer Guile. I wrote "the default python version", and I maintain that my original fix would work with the new upstream release. > You > are not paying attention. You are instead trying to get by with > minimal understanding, proclaiming how deficient I am, reporting so > far *three* bugs, one of which is not a bug, and the other two of > which are *clearly* wishlist items; indeed, in one of the reports > *you yourself* indicate that it's a wishlist item. Grow up. COUNTER-RETORT. Basically, my remarks match those in the complete report of Pierre Habouzit in <[EMAIL PROTECTED]> which you didn't reply to except to claim that you were already knew about the guile issue (yet you failed to mention it!). Since my messages are not bringing anything new to the discussion and will end up only bashing you over and over, I'll stop my contribution to this thread. PS: I cut the obvious personal attacks out of your messages; I suggest you take a break and stop calling people names. -- Loïc Minier <[EMAIL PROTECTED]> -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: lilypond and python
On Sat, Jul 29, 2006, Thomas Bushnell BSG wrote: > > So what? If you know how to fix that issue, then why don't you upload a > > package based on Pierre's work with the fix? Why don't you do it RIGHT > > NOW and get DONE with this madness? > I don't know a fix for that issue except to use Guile 1.8. Why do you insist on not fixing e.g. the gcc build failure right now with the version in Debian which builds with the guile in Debian and the default python in Debian? When this thread started, you had decided to bind the fix with the new upstream release and you had blocked the new upstream release with the switch of the default Python version. Now you're also blocking this new upstream release with a major new guile version. -- Loïc Minier <[EMAIL PROTECTED]> -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: More dh_python questions
Hi, (Could you please stop cross-posting to debian-devel? The discussion belongs to debian-python@ and the list is low traffic.) On Sun, Jul 30, 2006, Manoj Srivastava wrote: > I have only one version in XS-Python-Version (say, 2.4) I think the patch in #378604 enhance this situation with "XS-Python-Version: 2.4", but I had trouble too with "XS-Python-Version: 2.3", see thread on debian-python@, "Generation of "python" dependencies for public extensions versus python2.3". Also, the behavior seems completely clean for "XS-Python-Version: current", have a look at "flumotion" which has private modules which are compiled in place (in /usr/lib/flumotion) for the current version of python on install, and are recompiled on upgrades. Bye, -- Loïc Minier <[EMAIL PROTECTED]> -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: dh_python and python policy analysis
On Mon, Jul 31, 2006, Manoj Srivastava wrote: > 2.1. [5]XS-Python-Version: > 2.2. [6]XB-Python-Version: Your document keeps mentionning these, even as "requirements", but XB- isn't required for packages using python-support, and XS can be replaced by debian/pyversions. Is your document targetted at inclusion in the dev-ref? PS: I really don't see the point in cross-posting to debian-devel@, please either post to one or the other, thanks. -- Loïc Minier <[EMAIL PROTECTED]> -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: dh_python and python policy analysis
On Tue, Aug 01, 2006, Manoj Srivastava wrote: > Could you point me to documentation on python-support, what it > does, how to use it, and how it differs from python-central? Well, python-support is documented at the expected /usr/share/doc/python-support and in the dh_pysupport man page. Perhaps the wiki page http://wiki.debian.org/DebianPython/NewPolicy is the best place where you can see how the two tools differ? -- Loïc Minier <[EMAIL PROTECTED]> -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Python Transition, Mass Bug fill and NMUs...
On Wed, Aug 02, 2006, Pierre Habouzit wrote: > Yesterday, a last round of bugs has been filled against packages that > may need an upgrade to comply with the recent python policy[1]. That's great! We all want python to be python2.4 in etch, thanks for your work. We already discussed together why it would be nice to announce / discuss future mass bug filings to allow peer review (also when reporting bugs that were missed by the initial filing). Here are some suggestions of things I think would have improved the Python transition: - status of the transition Wiki page: a summary of steps which are in progress (pointer to python transition pseudo-bug, pointers to the list of bugs to be fixed in the mass bug filing, description of the step) - collection of things to do and no to do: this is both intended as a reference of things that we have discussed and decided to be good or wrong, and might help in defining the exact criteria prior to e.g. a mass bug filing; this probably belong to the FAQ on the Wiki - test suite I've found some Wiki pages approaching these, such as the DebianPythonTODO, DebianPythonFAQ, or the DebianPython/NewPolicy pages, but they didn't cover the results of discussions that happened on the debian-python@ lists before, during, or after the implementation of the python packaging tools. It seems to me it's a bit late to do this now, but if people find some of the above interesting, I might take some time during my holidays (starting friday) for this. -- Loïc Minier <[EMAIL PROTECTED]> -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Python Transition, Mass Bug fill and NMUs...
On Wed, Aug 02, 2006, Pierre Habouzit wrote: > that could have been more clear, but I do have such tools to follow the > transition, I use[1]. The two rounds of mass bug have been package that > build public modules and extensions, and then all the other ones (+ > some missed one at the first stage). Ok, some things I consider bugs with the current state of the transition and I would have expected in a "Status of the Python transition" page: - way of expressing dependencies on a particular version of python modules (#379455) - support of rtupdate scripts - support of pure python2.3 modules (raised on debian-python@ last week) - reports of upgrade testing > this seems to be quite well documented on the DebianPython/NewPolicy > pages, buxy added some full examples, and I added some more things > about cdbs recenlty. The page was also updated for private modules > before the second mass bug fill. An example of what I would have expected to find on the page I describe is: what to do when your package ships both private extensions and private modules; solution a) could be to configure the package with a --libexecdir or similar containing the name of the python runtime and build it multiple times, solution b) could be to only build for one version of python. -- Loïc Minier <[EMAIL PROTECTED]> -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Code of Conduct on the Debian mailinglists
On Fri, Aug 04, 2006, Josselin Mouette wrote: > This would be absolutely horrible. Most list subscribers use the headers > to put list email in separate directories, and this would make some > mails miss from the discussion. It's an end-user configurable feature of mailman, so you can turn it on or off if you don't like it. -- Loïc Minier <[EMAIL PROTECTED]> -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Setting up pbuilder or sbuild like experimental buildds
Hi there, I'd like to setup a pbuilder or sbuild (preferably pbuilder, but I'm not sure it's possible) in the way I understand experimental buildds are setup: to only pull experimental software when it's required by the build-deps, but keep only unstable software when possible. I would also like experimental software purged after builds of course. Would someone share an APT + pbuilder / sbuild config to achieve this? Thanks, -- Loïc Minier <[EMAIL PROTECTED]> -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Setting up pbuilder or sbuild like experimental buildds
On Tue, Aug 08, 2006, Mike Hommey wrote: > Wouldn't pbuilder with a basic apt pinning setup be enough ? It didn't work in the first place with pinning (it would either not try installing packages from experimental or install them on upgrades too). Then I thought I might have forgotten APT::Default-Release, and with APT::Default-Release set to "unstable", I could pin experimental higher than 500, 700 for example, and it wouldn't upgrade the packages automatically, however it still doesn't work. These are the scores of the package I'm interested in: bee# apt-cache policy libglib2.0-dev libglib2.0-dev: Installed: 2.10.3-3 Candidate: 2.10.3-3 Version table: 2.12.0-1 0 600 http://ftp.de.debian.org experimental/main Packages *** 2.10.3-3 0 990 http://ftp.de.debian.org sid/main Packages 100 /var/lib/dpkg/status I checked the code of pbuilder-satisfydepends, and I see it tries all versions of "apt-cache show" output to see whether one of them would be enough, but I see no place where it would request a particular version. -- Loïc Minier <[EMAIL PROTECTED]> -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
MIME type of OCaml source files
Hi, Inclusion of the OCaml syntax highlighting file in GtkTextView is blocked until FreeDesktop includes the MIME type in its shared-mime-info database, but I don't know the MIME type of OCaml source files. Would someone happen to know what the MIME type of OCaml files is? I couldn't find it in Google, and the tools I tried reported text/plain. And BTWn are there multiple possible extensions for source files? (I mailed [EMAIL PROTECTED], but didn't receive any reply.) Thanks, -- Loïc Minier <[EMAIL PROTECTED]> -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: MIME type of OCaml source files
On Thu, Aug 10, 2006, George Danchev wrote: > > (I mailed [EMAIL PROTECTED], but didn't receive any reply.) > both from d-o-m ;-) I should have requested to be Cc:ed, but forgot to do so, thanks! -- Loïc Minier <[EMAIL PROTECTED]> -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: VMware packaging
On Sun, Aug 13, 2006, Peter Collingbourne wrote: > I found there were no VMware-related packages in the official > repository, nor any way of creating them. Thus I propose to create > a tool that will build (for example for VMware Server) vmware-server > and vmware-modules-source packages based on an installation tarball > (a la java-package). Would be nice if we could go as far as shipping binary packages for e.g. vmware-player, as Ubuntu does: <http://packages.ubuntu.com/cgi-bin/search_packages.pl?keywords=vmware&searchon=sourcenames&subword=1&version=all&release=all> (But I didn't check whether this qualifies for non-free.) -- Loïc Minier <[EMAIL PROTECTED]> -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Common handling of browser plugins?
On Mon, Sep 18, 2006, Fabian Greffrath wrote: > - flashplugin-nonfree > - totem-mozilla > - java-gjc-compat-plugin > (1) As you can see, each of these packages follows a different naming > pattern which makes it difficult for the user to find the browser plugin > of his needs. I suggest to introduce a suffix which will be added to the > package name and makes clear that it contains a plugin. My suggestions > are 'foo-mozilla' or even better 'foo-browserplugin'. Sure, that's an interesting point. We discussed this in #gnome-debian when the totem-mozilla plugin was introduced. It was hard to find a good name because the plugin works in firefox, mozilla, xulrunner, and seamonkey based browsers. Mozilla seemed a good name as being the distributor of all these sources. Xulrunner also sounded good, since it's used to build totem, but it would sound strange for people using firefox or even for ubuntu which probably continues buidling against firefox-dev. You might also encounter conflicting policies: e.g. what if the plugin is written in Java? Does it need to follow the mozilla plugin naming policy of the java one? > (2) Another fact that disturbes my is that all of these packages contain > different plugin directories for the different browsers in Debian. > These are: > flashplugin-nonfree: /usr/lib/mozilla/plugins > /usr/lib/mozilla-firefox/plugins > /usr/lib/firefox/plugins mozilla-firefox sounds obsolete and duplicated. > totem-mozilla:/usr/lib/xulrunner/plugins > /usr/lib/mozilla/plugins > /usr/lib/firefox/plugins Upstream told me once that installing in /usr/lib/mozilla/plugins would be enough, but it's not: I think firefox only loads plugins from it's plugins dir. Xulrunner based browsers will obviously only load plugins searched by the libxul library, so /usr/lib/xulrunner/plugins I suppose. Mozilla is for the aging mozilla-browser, soon to be removed. It seems correct to me. > java-gjc-compat-plugin: /usr/lib/mozilla/plugins > /usr/lib/mozilla-firefox/plugins > /usr/lib/mozilla-snapshot/plugins mozilla-firefox should be firefox, mozilla-snapshot is probably obsolete as the package was removed. > In the totem-mozilla package, all linking is done before packaging, so > all the directories already contain the plugin. Yes, the plugin is below /usr/lib/totem, and regular symlinks are shipped in the .deb. > (3) Another thing in which all those packages differ is the > recommendation and suggestion of compatible browsers: > flashplugin-nonfree suggests: mozilla-browser (>= 2:1.1) | > mozilla-firefox | firefox mozilla-firefox is probably obsolete, and this doesn't permit e.g. xulrunner based browsers (such as epiphany, galeon...). > totem-mozilla recommends: epiphany-browser | www-browser Sadly, there's no "mozilla-browser" provides. There's www-browser, and gnome-www-browser. I suppose we should aim at x-www-browser as well. Perhaps a provide expressing "mozilla-pluginaware-browser" would be nice? Thanks for looking into this, it would be nice if this could result in some lintian warnings and / or bug reports if there's consensus on these. Bye, -- Loïc Minier <[EMAIL PROTECTED]> -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Top 20 unnecessary dependencies [was: Re: A plan to get rid of unnecessary package dependencies]
On Tue, Sep 26, 2006, Josselin Mouette wrote: > for file in $(wildcard debian/$(cdbs_curpkg)/usr/lib/*.la); do \ > sed -i "/dependency_libs/ s/'.*'/''/" $$file ; \ > done To use this feature, if you use CDBS, simply: include /usr/share/gnome-pkg-tools/1/rules/clean-la.mk and build-dep on gnome-pkg-tools >= 0.7. I'm using it as follow in my non-CDBS packages: sed -i "/dependency_libs/ s/'.*'/''/" debian/$(DEV_PKG)/usr/lib/*.la -- Loïc Minier <[EMAIL PROTECTED]> -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Top 20 unnecessary dependencies [was: Re: A plan to get rid of unnecessary package dependencies]
On Thu, Sep 28, 2006, Tollef Fog Heen wrote: > >Which is all crap. Yes, this is the list you need for static, but > >pkg-config is recursing through modules even for dynamic linking which > >is wrong. Now either pkg-config of the gtk+2 pc file needs to be > >fixed, then you can start recompiling all the affected programs... > The gtk+2 .pc file needs to be changed to mark a bunch of those Requires > as Requires.private, pkg-config provides all the necessary > infrastructure now. (If not, please do file bugs.) Patching of gtk+-2.0.pc and friends is on the TODO, but will be implemented in the 2.10.x series, not in 2.8. pango*.pc would have been my guinea pigs, but I'm not sure it's worth the risk so close to release now. Thanks for the reminder! -- Loïc Minier <[EMAIL PROTECTED]> -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Request for Discussion about Account Handling in Maintainer Scripts Wiki Page
On Fri, Sep 29, 2006, Marc Haber wrote: > Whether an account created by a package should be deleted or not has > been discussed a million times. But it looks like the results of these > discussions were never written down. The removal of users / groups is not the only thing often debated for purges. I propose to enlarge the debate on purging to: - log files - databases - caches - other perhaps valuable data Perhaps thoughts on these subjects are connected (I for example think that we should let the admin decide, perhaps in /etc/dpkg/purges.conf, what he wants to delete on purges) and should be grouped in implementation and/or policy updates? . o O ( It's funny, I discussed this no later than yesterday on a Debianish channel again. ) -- Loïc Minier <[EMAIL PROTECTED]> -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bug#389053: apache2-common: API module structure `perl_module' in file /usr/lib/apache2/modules/mod_perl.so is garbled
On Sat, Sep 30, 2006, Russ Allbery wrote: > I never build packages outside of pbuilder, so it takes a bit more work > than that. I have a similar problem, which I currently workaround as follows: - bind mount a local APT repository in pbuilder - copy / symlink only the relevant *.debs from experimental in this repository This works nicely, but it means I have to symlink manually the correct list of packages on each build. -- Loïc Minier <[EMAIL PROTECTED]> -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: A plan to get rid of unnecessary package dependencies
On Sun, Oct 01, 2006, Peter Samuelson wrote: > > A first step in that direction would be to fix .la, .pc and -config > > files so that they only give the needed libraries. > binary-arch: build-arch > # [something like '$(MAKE) install DESTDIR=$(shell pwd)/debian/tmp'] > # > sed -i 's:/usr/lib/lib\([^ ]*\).la:-l\1:g' debian/tmp/usr/lib/*.la Can't we just tell people to not use *.la files for static linking? -- Loïc Minier <[EMAIL PROTECTED]> -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: A plan to get rid of unnecessary package dependencies
On Mon, Oct 02, 2006, Peter Samuelson wrote:
> The problem is that .la files provide a way to pull in all the
> dependent libraries for static linking, and unless you also ship .pc
> files, there is no other automated way to do this. Some people
> apparently care about this capability, which is why we can't just
> delete _all_ .la files _now_.
I think we're already aiming at the removal of *.la files, at least
some maintainers are. I'm removing them from leaf packages or as soon
as the rdeps permit it, and I'm also using the "dependency_libs
erasing" that was introduced in libxml2 when I can't remove the *.la
files -- this renders *.la files useless but at least not harmful.
On the other hand, with your proposal, we end up keeping the *.la
files. I certainly understand that they ease static linking, but this
also means that we need to depend on all libraries down the dependency
tree (${la:Depends}) of each package to ensure that its *.la files are
functional for static linking, even with the modified dependency_libs
line.
Since there are other ways to offer a static linking solution (adding
pkg-config files) and since not all packages use libtool, I think it
might be time to suggest people not to rely on *.la files for static
linking.
--
Loïc Minier <[EMAIL PROTECTED]>
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Setting up pbuilder or sbuild like experimental buildds
On Sat, Sep 16, 2006, Junichi Uekawa wrote:
> > I checked the code of pbuilder-satisfydepends, and I see it tries all
> > versions of "apt-cache show" output to see whether one of them would be
> > enough, but I see no place where it would request a particular version.
> Yup, that's not supported in current pbuilder-satisfydepends codebase.
> You're welcome to submit a patch, however.
I just did, it's in #390888 for people following this discussion via
debian-devel@; testers welcome!
--
Loïc Minier <[EMAIL PROTECTED]>
diff -urN pbuilder-0.159/debian/changelog pbuilder-0.160/debian/changelog
--- pbuilder-0.159/debian/changelog 2006-09-26 00:49:04.0 +0200
+++ pbuilder-0.160/debian/changelog 2006-10-03 15:20:25.0 +0200
@@ -1,3 +1,18 @@
+pbuilder (0.160) unstable; urgency=low
+
+ * Non-maintainer upload.
+ * Drop an useless awk invocation in pbuilder-satisfydepends.
+ * Add and use new package_versions() and candidate_version() helpers; the
+former returns all versions of a package available via APT, the later
+APT's candidate version.
+ * For versionned build-deps, when building the "apt-get install" command,
+try APT's candidate version or all available versions available from APT
+in ascending order (the reverse order of apt-cache's output);
+checkbuilddep_versiondeps() isn't used for this part of the process
+anymore, but it is still used to honor build-conflicts.
+
+ -- Loic Minier <[EMAIL PROTECTED]> Tue, 3 Oct 2006 14:32:58 +0200
+
pbuilder (0.159) unstable; urgency=low
[Junichi Uekawa]
diff -urN pbuilder-0.159/pbuilder-satisfydepends
pbuilder-0.160/pbuilder-satisfydepends
--- pbuilder-0.159/pbuilder-satisfydepends 2006-05-31 01:45:45.0
+0200
+++ pbuilder-0.160/pbuilder-satisfydepends 2006-10-03 15:19:43.0
+0200
@@ -21,11 +21,21 @@
set -e
+function package_versions() {
+ local PACKAGE="$1"
+ ( $CHROOTEXEC /usr/bin/apt-cache show "$PACKAGE" ) | sed -n
's/^Version: \(.*\)$/\1/p'
+}
+
+function candidate_version() {
+ local PACKAGE="$1"
+ LC_ALL=C $CHROOTEXEC apt-cache policy "$PACKAGE" | sed -n 's/
*Candidate: *\(.*\)/\1/p'
+}
+
function checkbuilddep_versiondeps () {
local PACKAGE="$1"
local COMPARESTRING="$2"
local DEPSVERSION="$3"
-local PACKAGEVERSIONS=$( ( $CHROOTEXEC /usr/bin/apt-cache show "$PACKAGE"
) | sed -n 's/^Version: \(.*\)$/\1/p' | xargs)
+local PACKAGEVERSIONS=$( package_versions "$PACKAGE" | xargs)
# no versioned provides.
if [ "${FORCEVERSION}" = "yes" ]; then
return 0;
@@ -92,6 +102,8 @@
local INSTALLPKGMULTI
local CURRENTREALPKGNAME
local SATISFIED
+local PACKAGEVERSIONS
+local CANDIDATE_VERSION
echo " -> Attempting to parse the build-deps $Id:
pbuilder-satisfydepends,v 1.28 2006/05/30 23:45:45 dancer Exp $"
for INSTALLPKGMULTI in $(cat ${DEBIAN_CONTROL} | \
awk '
@@ -104,7 +116,7 @@
sed 's/^[^: ]*://' | \
tr " " "/" | \
awk 'BEGIN{RS=","} {print}'); do
- echo " -> Considering $(echo "$INSTALLPKGMULTI" | tr "/" " " | awk
'{print $0}' )"
+ echo " -> Considering build-dep$(echo "$INSTALLPKGMULTI" | tr "/" " " )"
SATISFIED="no"
for INSTALLPKG in $(echo "$INSTALLPKGMULTI" | \
awk 'BEGIN{RS="|"} {print}'); do
@@ -116,23 +128,40 @@
continue;
fi
fi
+
+ # the default is to try to install without any version constraint
+ CURRENTREALPKGNAME_WITHVERSION="$CURRENTREALPKGNAME"
+
if echo "$INSTALLPKG" | grep '[(]' > /dev/null; then
- #echo "Debug: $INSTALLPKG"
- if ! checkbuilddep_versiondeps ${CURRENTREALPKGNAME} \
- $(echo "$INSTALLPKG" | tr "/" " " | sed 's/^.*([
]*\(<<\|<=\|>=\|=\|<\|>>\|>\)[ ]*\(.*\)).*$/\1/') \
- $(echo "$INSTALLPKG" | tr "/" " " | sed 's/^.*([
]*\(<<\|<=\|>=\|=\|<\|>>\|>\)[ ]*\(.*\)).*$/\2/') ; then
- echo " -> Does not satisfy version, not trying"
- continue;
- fi
+ # package versions returned by APT, in reversed order
+ PACKAGEVERSIONS="$( package_versions "$CURRENTREALPKGNAME" | tac |
xargs )"
+ CANDIDATE_VERSION="$( candidate_version "$CURRENTREALPKGNAME" )"
+
+ # try the ca
Re: [Debian Installer] General release plan for RC1
On Sun, Oct 08, 2006, Attilio Fiandrotti wrote: > Just today mike emmel fixed the "boom" bug, it should technically > possible switching to GTK+ 2.10.x. Repeating this here for other readers: 2.10.6-2 in experimental was uploaded today with the fix. -- Loïc Minier <[EMAIL PROTECTED]> -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#396611: ITP: mach -- make a chroot of a rpm-based distribution
Package: wnpp Severity: wishlist Owner: Loic Minier <[EMAIL PROTECTED]> * Package name: mach Version : 0.9.0.2 Upstream Authors : Thomas Vander Stichele, Ville Skyttä, Jeff Pitman, Rudi Chiarito, Matthias Saou, Nigel Metheringham * URL : http://thomas.apestaart.org/projects/mach/ * License : GPL Programming Lang: Python and C Description : make a chroot of a rpm-based distribution mach allows you to set up clean roots from scratch for any distribution or distribution variation supported. . This clean build root can be used for several goals: - making clean packages - set up chroots for services to run it - make disk images of clean roots (for example for UML) . Currently, mach works for rpm-based distributions that can work with apt for rpm. . Included at this moment is the necessary information to set up: - Fedora 1, 2, 3, 4, 5, 6, and development - Red Hat 7.0, 7.1, 7.2, 7.3, 8, and 9 - CentOS 4 - Dave/Dina - Conectiva 9 - SuSE 8.1, 8.2, and 9.0 - Yellowdog 2.3, and 3.0 . Some handy features of mach include: - "caching" of downloaded packages using the build hosts's apt the build root - ensures clean packages by reverting to the base set of build packages - uses apt to resolve dependencies - parsing of BuildRequires to install necessary packages for building - build ordering when doing multiple builds - support for flavours of distribution - multiple build roots - locking of buildroot to avoid concurrent builds - optional signing of built packages While the packaging is relatively advanced, I face problems with non-root usage and yum (I'm trying to override RPM's --dbpath via Yum), and apt-rpm currently lacks apt-rpm-client, so the APT backend isn't available right now either. Help is welcome, I can hand you my current diff if you want to help. -- System Information: Debian Release: 4.0 APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.18-1-686 Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8) -- Loïc Minier <[EMAIL PROTECTED]>
Re: Bug#396611: ITP: mach -- make a chroot of a rpm-based distribution
> This sounds like rpmstrap? > ... though with much better coverage. Check the "features" bullet points. The biggest differentiating features are probably: - based on yum or apt-rpm-client (I think rpmstrap calls rpm directly), both to bootstrap and to resolve build-requires - has logic to build SRPMs, IOW act as a buildd: . can resolve SRPM's build-requires . ensures clean packages by reverting to the base set of build packages . build ordering when doing multiple builds (i.e. proper use of locks) . support for flavours of distribution . signing of builds with GPG -- Loïc Minier <[EMAIL PROTECTED]> -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bug#397291: ITP: php-tidy -- tidy module for php[45]
On Mon, Nov 06, 2006, Jan Wagner wrote: > Description : tidy module for php[45] > PHP is an HTML-embedded scripting language. Much of its syntax is borrowed > from C, Java and Perl with a couple of unique PHP-specific features thrown > in. The goal of the language is to allow web developers to write > dynamically generated pages quickly. This is the description of PHP, not of php-tidy I guess. While it might be useful to explain what PHP is, I expect the description of php-tidy to tell me what php-tidy is... -- Loïc Minier <[EMAIL PROTECTED]> -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bug#397291: ITP: php-tidy -- tidy module for php[45]
On Mon, Nov 06, 2006, Jan Wagner wrote: > Version : 5.1.6 > * URL : http://www.php.net/downloads.php I don't understand: will you upload the php5 source a second time to Debian just for the tidy extension? What about the bugs below? http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=332763 http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=355976 > Description : tidy module for php[45] Is this really for PHP4 and PHP5? The upstream site offers a download for PHP4, and I think tidy is now bundled in PHP5. -- Loïc Minier <[EMAIL PROTECTED]> -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bug#397291: ITP: php-tidy -- tidy module for php[45]
On Mon, Nov 06, 2006, Jan Wagner wrote: > I did split ext/tidy out of the php5 package. That doesn't sound like a good idea; did you already discuss building it as part of the php5 package? I could not find hints of such a discussion in #332763 nor #355976. Why would you want to upload a separate source package? -- Loïc Minier <[EMAIL PROTECTED]> -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bug#397291: ITP: php-tidy -- tidy module for php[45]
On Mon, Nov 06, 2006, Jan Wagner wrote: > > That doesn't sound like a good idea; did you already discuss building > > it as part of the php5 package? I could not find hints of such a > > discussion in #332763 nor #355976. > See > http://lists.alioth.debian.org/pipermail/pkg-php-maint/2006-November/001286.html > > Why would you want to upload a separate source package? > That seems to be used to do. See php-imap or php-pspell! I find that weird, but thanks for reassuring me that this was discussed. -- Loïc Minier <[EMAIL PROTECTED]> -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#397780: ITP: sparse -- semantic parser of source files
Package: wnpp Severity: wishlist Owner: Loic Minier <[EMAIL PROTECTED]> Hi, * Package name: sparse Version : 0.1 Upstream Author : Linus Torvalds and others * URL : http://kernel.org/pub/linux/kernel/people/josh/sparse/ * License : Open Software License v1.1 Programming Lang: C and Perl Description : semantic parser of source files Sparse, the semantic parser, provides a compiler frontend capable of parsing most of ANSI C as well as many GCC extensions, and a collection of sample compiler backends, including a static analyzer also called "sparse". Sparse provides a set of annotations designed to convey semantic information about types, such as what address space pointers point to, or what locks a function acquires or releases. . Sparse can be invoked directly as "sparse" or via the "cgcc" wrapper around the C compiler. This is targetted at non-free due to a choice of venue clause and at experimental since it is the first release. I'm attaching the debian/copyright which has the details. Cheers, -- System Information: Debian Release: 4.0 APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.18-2-686 Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8) -- Loïc Minier <[EMAIL PROTECTED]>
Re: #397716 - please provide a debian-icon on the default desktop install, not an ubuntu one
On Fri, Nov 10, 2006, Holger Levsen wrote: > I filled this as #397716 and have received no reply yet (One reason is that the pkg-gnome-maintainers list wasn't subscribed to the PTS.) -- Loïc Minier <[EMAIL PROTECTED]> -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Proposed new POSIX sh policy
On Sat, Nov 11, 2006, Manoj Srivastava wrote: > Why don't we do that? Because people wanted to have a > different shell that can serve as /bin/sh. What purpose does it > serve to allow that? We can't, in all honesty, say that any disk > space is conserved, since bash is essential, it is too deeply rooted > in all places in our system to be casually ripped out. You mention only one reason for switching, which is to use a faster shell. I think there's also the fact that we want to know whether shell scripts are POSIX shell scripts or bash scripts. If you start sending the message that /bin/sh is bash compatible, we will lose valuable information. You may now wonder *why* we need the distinction, what the information will be useful for. First, we might switch any such scripts to being run by a different POSIX implementation; speed was mentionned, but the problem might also be of running these scripts in constrained environments, such as the initramfs. Second, not making the distinction *gains us nothing*, quite the contrary! Anyone who wants bash functionality can simply use bash! Now, how to define what /bin/sh is? I would go for something relatively minimal, such as POSIX, and add the general expectations of script writers on top of it. For example, if test -a and test -e is commonly supported in the shells that Debian ships, and a lot of script writers need to use test -a and -e, then we should aim at saying /bin/sh supports test -a and test -e, perhaps verifying that shells in Debian support this. If most script writers expect support of "local" in /bin/sh scripts, and shells in Debian support it, we might add such support to the policy definition of /bin/sh capabilities. This serves both shell scripts writers, as shell packages in Debian which would like to be installed as a /bin/sh alternatives. In summary, please keep the distinction between /bin/sh and /bin/bash. I suggest defining /bin/sh starting with something like POSIX or XSG and adding additional constraints based on common expectations on what /bin/sh should reasonably support. -- Loïc Minier <[EMAIL PROTECTED]> -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: RFC: behaviour of "bts show" command with new BTS default behaviour
On Sun, Nov 12, 2006, Julian Gilbey wrote: > Thinking of changing the default behaviour of the devscripts "bts show" > (aka "bts bugs") command, and want to ask for opinions before I do so. Perhaps you can use versions instead? http://bugs.debian.org/foo;version=x.y resolves to pkgreport with pkg=foo, version=x.y, and dist=unstable, and shows the bugs as closed if these were closed with version=x.y. -- Loïc Minier <[EMAIL PROTECTED]> -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Status of IPW3945 (Was: IPW3945)
Hi, Here's a short status of IPW3945 in Debian: IPW3945 needs three things: firmware (binary blob), driver, and daemon (non-free): - firmware is in firmware-ipw3945, up-to-date with upstream (<http://bughost.org/ipw3945/>) at version 1.13 in etch/testing; maintained by the Kernel team - public packages for the driver may be found on personal web sites of various people, I've found Joachim Reichel, Russel Stuart, and Stefan Lippers-Hollmann to be providing such packages; I could update the more recent version based on a packaging mostly by Kel Modderman to the latest upstream version for my local needs, and it works like a charm, especially with the patches Kel has been adding recently; Daniel Baumann ITPed this driver, and Kel requested comments on his packages on the debian-mentors@ list - daemon is also available publicly from Joachim Reichel's site; Jurij Smakov ITPed the daemon, and started separate packaging efforts which he offered for comments as well recently; I've tested the packages of Jurij, and they work nicely (except for a point I believe is being addressed) I believe the latest versions of the above packages are of release quality, and I wish they ship in etch as well. Bye, -- Loïc Minier <[EMAIL PROTECTED]> -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: [RFC] new virtual package names for optical discs burning applications
On Fri, Nov 17, 2006, George Danchev wrote: > Using alternatives mechanism -- currently I don't think that using > alternatives mechanism would be a benefit as a whole, but I might be blind of > course. Check /usr/bin/sensible-* in debianutils. They rely on alternatives and environment variables for defaults and overrides (respectively) and carry some logic to select the most adequate binary in the normal cases. E.g., sensible-cd-burner could spawn xcdroast; but I'm not sure this is what you want to achieve. -- Loïc Minier <[EMAIL PROTECTED]> 10 SIN 20 GO TO ROBOT HELL -- Temple of Robotology -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: [q] maintainance of xfsprogs and util-linux
Hi, On Sat, Nov 18, 2006, Michael Banck wrote: > We are preparing a release, so packaging new upstream versions is much > less of a target right now than fixing bugs. True; but IMO xfsprogs is relatively stable, and the changes are usually bug fixes. I grabbed the tarballs to make sure I don't say crap, and found the changes below, from CHANGES: xfsprogs-2.8.16 (30 October 2006) - Fix up an endian problem for nlink setting in phase 7 for xfs_repair. xfsprogs-2.8.15 (19 October 2006) - Fix up nlink checks and repairs in phase 7 for xfs_repair. - Remove a bogus LEAFN warning for a single leaf node v2 dir. xfsprogs-2.8.14 (6 October 2006) - Fix up the ring command in xfs_db, thanks to Utako Kusaka - Set the blocksize on the device to the given sector size which is _not_ necessarily 512 bytes; idea suggested by Shailendra Tripathi. - Fix up xfs_copy and its variable argument handling around vfprintf; xfs_copy was seg faulting on x86_64. xfsprogs-2.8.13 (21 September 2006) - Fix v2 directory checking with holes and unreadable blocks. - Fix a memory leak in dir2 checking. - Update libdisk/md support to work out the stripe width based on (# raid-disks - # parity disks) which doesn't include any spare disks (which we mistakenly did before). Thanks to Shailendra Tripathi's suggestions. - Get the kernel int types of __u32 and friends from if we can, otherwise define them ourselves. xfsprogs-2.8.12 (29 August 2006) - Multi-thread modifications to xfs_repair. - Updated Polish translation, thanks to Jakub Bogusz. - Change default mkfs realtime extent size setting to perform better for buffered writes. But I suppose it's still possible that the above introduces new bugs as well. Bye, -- Loïc Minier <[EMAIL PROTECTED]> 10 SIN 20 GO TO ROBOT HELL -- Temple of Robotology -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bug#399305: ITP: subversive -- The Subversive is a Eclipse plug-in that provides Subversion support
On Sun, Nov 19, 2006, Ivan Dubrov wrote: > * Package name: subversive > Description : The Subversive is a Eclipse plug-in that provides > Subversion support Out of curiosity, is this incompatible with subclipse? -- Loïc Minier <[EMAIL PROTECTED]> 10 SIN 20 GO TO ROBOT HELL -- Temple of Robotology -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bug#399305: ITP: subversive -- The Subversive is a Eclipse plug-in that provides Subversion support
On Sun, Nov 19, 2006, Roberto C. Sanchez wrote: > Compatibility is not the question. It is clearly inferior. For one, it > has no support for JavaHL. At least everything I can find on the > upstream web site indicates that it only supports JavaSVN. Anyhow, what > this means is that the only way to make use of ssh keys is by providing > your passphrase every time or by having it stored in plain text on your > hard drive. "clearly inferior" sounds a bit strong on this basis alone. I went through the features described on the website, and some seemed to be lacking in subclipse. And we don't have subclipse in Debian (yet). I'm asking about compatibility because I am currenlty using the subclipse plugin (and it is being packaged for Debian), installed locally, but would like to switch painlessly to anything which appears first in Debian and covers my basic needs. > This is because JavaSVN has no way to communicate to an ssh-agent. I > have emailed the JavaSVN developers about it. AFAIK they have no > intentions of trying to support ssh-agent because it is either not > possible or too hard with JavaSVN. > > This means that if you want to use your svn+ssh repo in half-way secure > fashion, you can't with this plugin. Probably better to stick with > subclipse. Does it work if you load your keys (and type your passphrase) before using JavaSVN? And if you have a graphical ssh-askpass installed? -- Loïc Minier <[EMAIL PROTECTED]> 10 SIN 20 GO TO ROBOT HELL -- Temple of Robotology -- 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, Shaun Jackman wrote: > When using CDBS, what is the best way to conditionally apply an > architecture-dependent patch. I'm using CDBS, but not yet using a > patch system such as simple-patchsys, dpatch, or quilt, so > recommendations of a patch system are welcome. Currently I have... If you use simple-patchsys, you can prepend before any "include" line: ifeq ($(DEB_HOST_ARCH),m68k) DEB_PATCHDIRS = debian/patches debian/patches/$(DEB_HOST_ARCH) endif to add debian/patches/m68k to the list of directories with patches to apply. Obviously, this can be adapted for many use cases, and different patch orders. -- Loïc Minier <[EMAIL PROTECTED]> "You see, killbots have a preset kill limit. Knowing their weakness, I sent wave after wave of my own men at them until they reached their limit and shutdown."-- Zapp Brannigan -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Mass closing of bugs ?
On Sun, Dec 03, 2006, Mike Hommey wrote: > Now that iceape replaces mozilla and provides mozilla packages for > transition, the BTS now show all old mozilla bugs in the iceape reports. > These may or may not include bugs that don't exist anymore, and > considering how mozilla used to be maintained, it may also include bugs > that were not even in mozilla anymore or at all. > > Considering that the maintainer scripts have not been inherited from > mozilla, and that the mozilla engine is pretty different, may I just > close all the bugs assigned to old mozilla packages, requesting a > reopen if the bug still exists in iceape ? The backlog is huge, and I wouldn't imagine anyone going through the ~700 bugs the mozilla source gained over the years. But since some bug reports might carry some value, it would be nice to include a description of the situation and instructions to reopen bugs in the mass closing mail(s). -- Loïc Minier <[EMAIL PROTECTED]> "You see, killbots have a preset kill limit. Knowing their weakness, I sent wave after wave of my own men at them until they reached their limit and shutdown."-- Zapp Brannigan -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Dropping GStreamer 0.8 for etch
Hi, This is to discuss dropping the 0.8 series of GStreamer for etch. Recently, a security bug affected gst-ffmpeg and needed an upload for both the 0.8 and 0.10. The security team wonders whether it will have to support both sources for the etch lifetime. The number of packages which are still using the 0.8 series of GStreamer has dropped significantly. Remain as libgstreamer0.8-0 rdeps: - teatime: Sebastian Dröge sent a patch for GStreamer 0.10 support in #401897 - muine: version 0.8.6 in experimental is built against GStreamer 0.10, see #381784 - kttsd: no idea about this one - goobox: gnome.org module that did not see any new upstream release since november 2005 and seems to be completely superseded by sound-juicer; Daniel Baumann seems to continue maintenance of this source Perhaps we can join efforts and drop GStreamer 0.8 from etch rapidly, ideally before release; I initially scheduled this for immediately after etch, as the 0.8 series are completely unmaintained upstream (even security-wise), but it seems doable after all. Please share your thoughts and comments. Cheers, -- Loïc Minier <[EMAIL PROTECTED]> "I have no strong feelings one way or the other." -- Neutral President -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Dropping GStreamer 0.8 for etch
On Wed, Dec 06, 2006, Josselin Mouette wrote: > Maybe it is also not too late to rework the gstreamer0.10-ffmpeg package > to link against the Debian libavcodec/libavformat packages. This would > save a lot of trouble to the security team. This is a separate issue, and the short status on the subject is that upstream thinks this is not possible, but they would accept help on this topic: <http://bugzilla.gnome.org/show_bug.cgi?id=363363> -- Loïc Minier <[EMAIL PROTECTED]> "I have no strong feelings one way or the other." -- Neutral President -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Dropping GStreamer 0.8 for etch
On Wed, Dec 06, 2006, Helge Kreutzmann wrote: > Well, I haven't tried sound-juicer, but according to the (very brief) > package description, it is a ripper, and not a player. It can play as well, although you can also play CDs from other music players such as Rhythmbox or simply gnome-cd. >The main aim of > goobox is to play CDs on those systems where no direct link between > the CD drive and the audio hardware exists (like, e.g., on my ibook). That's a good point. gnome-cd dropped support for this kind of playback and we heard some complaints (but we didn't hear reports from people which had CD drives without any connection to their sound card and who gained CD playback). Could goobox achieve playback without GStreamer in this subcase? > In principle, I could not see at which stage security support for > goobox would be critical: There could be a malicious CD which the user > wants to play (but this interface is IMHO controlled by paranoia) or > malicious data from the CDBS data base (but this is outside > gstreamer). All other data is local/trusted. But the GStreamer stack is full of decoders and sometimes encoders which need security support. -- Loïc Minier <[EMAIL PROTECTED]> "I have no strong feelings one way or the other." -- Neutral President -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Dropping GStreamer 0.8 for etch
On Wed, Dec 06, 2006, Helge Kreutzmann wrote: >The main aim of > goobox is to play CDs on those systems where no direct link between > the CD drive and the audio hardware exists (like, e.g., on my ibook). Uh, I misparsed your email, on systems with *no* link. Well, that's what sound-juicer, rhythmbox and gnome-cd do AFAICT. -- Loïc Minier <[EMAIL PROTECTED]> "I have no strong feelings one way or the other." -- Neutral President -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Dropping GStreamer 0.8 for etch
On Wed, Dec 06, 2006, Josselin Mouette wrote: > > This is a separate issue, and the short status on the subject is that > > upstream thinks this is not possible, but they would accept help on > > this topic: > > <http://bugzilla.gnome.org/show_bug.cgi?id=363363> > The attached patch should be at least enough for Debian. Finally working > h264 videos with totem-gstreamer, hear hear! > That's just a hack, and for upstream, this requires of course some > integration in the configure script, but that's definitely not > impossible. Again, this is a separate issue. I suggest you subscribe and/or comment in the upstream bug. I was able to produce a hackish gst-ffmpeg built with Debian's ffmpeg source as well (though it would have required a ffmpeg-source package or equivalent), but it was not good enough to be included in Debian. I've forwarded your patch upstream for comments. I rely on upstream for updates of gst-ffmpeg. Applying such a patch to Debian only would put upstream in a situation where bugs coming from Debian might be seen as "tainted". -- Loïc Minier <[EMAIL PROTECTED]> "I have no strong feelings one way or the other." -- Neutral President -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Dropping GStreamer 0.8 for etch
On Thu, Dec 07, 2006, Josselin Mouette wrote: > I don't think this justifies the extra burden on the security team, and > the bugs in some codecs that are fixed in the Debian ffmpeg package. > Given the growing number of h.264 videos out there, it doesn't make much > sense to ship a video player that can't read them, especially when it > can be so easily fixed. It's nice that you're concerned by this state of fact, but this is nothing new, and was already discussed multiple times. I actually already discussed this since months with 1) Debian users 2) upstream 3) the ffmpeg maintainer 4) the security team. If you truly want to unlock this situation, subscribe to the upstream bug on the subject, and update your patch to be acceptable upstream. > As the situation is very similar in mplayer, mplayer is considered > RC-buggy by the security team. There was an exception for > gstreamer-ffmpeg because it was considered too difficult to fix, but I > don't think this is justified and this should be considered > release-critical as well. Again, nothing new. As you state yourself, this was already discussed and an exception was granted. Beside, you miss the important point that gst-ffmpeg heavily patches (read: "replaces") the ffmpeg build system, wihle mplayer has a close-to-vanilla ffmpeg tree. "Dropping GStreamer 0.8 for etch" is not "building gst-ffmpeg against Debian's ffmpeg"; any of these changes can be achieved in whatever order, these are orthogonal, even if both would help security support (in a different way). As I'm not considering building gst-ffmpeg against ffmpeg for etch, I kindly suggest we let this subthread die or be continued in the upstream bug report where it would be more useful. -- Loïc Minier <[EMAIL PROTECTED]> "I have no strong feelings one way or the other." -- Neutral President -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Dropping GStreamer 0.8 for etch
On Thu, Dec 07, 2006, Romain Beauxis wrote: > Seems that you do not include some other packages not directly depending on > this lib. Actually, I had a look when I sent this message, and saw: bee% apt-cache rdepends libgstreamer0.8-ruby libgstreamer0.8-ruby Reverse Depends: ruby-gnome2 and: bee% apt-cache rdepends python-gst python-gst Reverse Depends: I should have looked closer at the ruby-gnome2 dependency on libgstreamer0.8-ruby; I'm a bit surprized it's a Depends, perhaps this is a legacy dependency because the package was split? Fortunately: bee% apt-cache rdepends ruby-gnome2 ruby-gnome2 Reverse Depends: geekast-binary > For instance mine is built with ruby's bindings... I'm afraid you lack a dependency on the ruby bindings for GStreamer then. > If you were to choose to remove it before etch, you better prospect for > dependances on gstreamer0.8-foo packages, and as I fear, fill bugs quiclky > since they may be more than this list.. Well, there's the risk of uncovering missing dependencies indeed. > Anyway, I'm gonne prepare a new release of my package using 0.10. Great! -- Loïc Minier <[EMAIL PROTECTED]> "I have no strong feelings one way or the other." -- Neutral President -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
SUMMARY: Re: Dropping GStreamer 0.8 for etch
On Wed, Dec 06, 2006, Loïc Minier wrote: > - teatime: Sebastian Dröge sent a patch for GStreamer 0.10 support in >#401897 Fixed package uploaded. > - muine: version 0.8.6 in experimental is built against GStreamer 0.10, >see #381784 Fixed package available. > - kttsd: no idea about this one GStreamer support can be switched to 0.10 or dropped. > - goobox Alternative programs available with a superset of the features, and an active upstream. I'm waiting for a final ack of the maintainer that the alternatives are indeed okay and that we can proceed with removal. Initially missing from the list: geekast-binary. The maintainer commented that he is now working on porting this package to GStreamer 0.10. As soon as the above issues are cleared in testing, I'll request the removal of the GStreamer 0.8 suite of testing and unstable. -- Loïc Minier <[EMAIL PROTECTED]> "I have no strong feelings one way or the other." -- Neutral President -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Dropping GStreamer 0.8 for etch
On Thu, Dec 07, 2006, Josselin Mouette wrote: > By hiding behind upstream, you're simply refusing to fix the problem. Insulting. > as gst-ffmpeg ships a vanilla ffmpeg tree Wrong. > As the security people are the ones being really affected, I would like > to have Moritz' input on this matter. Are you ready to grant an > exception to gstreamer-ffmpeg and not to mplayer while the situation of > both packages is strictly identical? Insulting. I don't intend to pursue discussion, especially not in these conditions. -- Loïc Minier <[EMAIL PROTECTED]> -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: symlinks replaced by directories and vice versa
On Sat, Dec 09, 2006, Mario 'BitKoenig' Holbe wrote:
> However, since this is such a frequent source of bugs and since so many
> package maintainers seem not to be able to deal well with it, I'm asking
> myself, if it wouldn't make sense to change this behaviour to something
> which is more native to maintainers - i.e. automagically replace
> symlinks by directories and vice versa (which would natively equal a
> package upgrade to a package removal followed by an installation of the
> new version) or abort package installation if it occurs or something
> like this.
I agree it's counter-intuitive. I seem to recall someone told me it
was a feature of dpkg which allows local admin to e.g. ln -s /bigdisk
/usr/share. I'm not sure this is the correct explanation, but if it
is, then perhaps it would make more sense to support this functionality
at the dpkg level directly, perhaps in a similar fashion to diversions
("I want that anything that would be installed to /usr/share be
installed in $otherdir" sounds similar to what diversion currently do).
> I'm not sure if this is the right list to discuss that
(perhaps the dpkg list indeed)
--
Loïc Minier <[EMAIL PROTECTED]>
"I have no strong feelings one way or the other." -- Neutral President
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Dropping GStreamer 0.8 for etch
On Sun, Dec 10, 2006, Helge Kreutzmann wrote: >I could not get rhythmbox to "simply" play CDs. What didn't work? I made sure this morning that an audio CD still plays fine here, so you might want to report a bug if it doesn't (I "maintain" RB to some extent). > I could not find a package for gnome-cd, though. It's in gnome-media. It's really a very simple CD player which aims at doing only CD playing, nothing more nothing less; it wont suffer the comparison against goobox' features. >Comparing goobox and sound-juicer it appears to me as if they offer >roughly similar functionality, but goobox offers a some more >(parameters for ripping can be set using sliders, cd-covers are >fetched from the net, random play, looping, more buttons); I did not >compare the >ripping part in detail, though. sound-juicer uses less screen estate. IMO, you should compare s-j + rb, and not one of the two with goobox. (CD covers are fetched by RB as well; it features random play, and looping. It also has "more buttons". :)) >And there are users for goobox, though according to popcon >sound-juicer is vastly more popular. Both are important point indeed, thanks for looking it up. >I have and am investigating some efforts into goobox (e.g. also >translation updates). So I would have expected such drastic >removal requests like other transitions: First a wishlist bug *early in >the release cycle* with the information available, e.g. links to >transition guides, offers for help or patches, if available. Then a >few month time for the maintainer to work on >transitioning/coordinating with upstream. Then now would have been >the time to upgrade this request to serious and cloing it to >ftp.debian.org. Sending this initial request on >"short notice" (still no bug in the BTS!), two weeks before >Christmas and similar a few weeks before release is not very >friendly. Hmm, you're being very defensive here; I understand it's very late in the release cycle (and I've underlined this fact in the initial post), and I'm not sure it will be possible to drop GStreamer 0.8 for etch. The thread is about *trying* to drop GStreamer 0.8, and examining what uses it (that's why I had a "?" in the subject of this thread :). From the short look I took at goobox when I reviewed apps using GStreamer 0.8, it seemed to be dead upstream. The fact that it's hosted at gnome.org made me wonder whether that will ever change since we have s-j and rb there already. And there's also the plethora of other audio playing apps, just to list some based on GStreamer: quodlibet, listen, muine, banshee, totem... I hope you understand that I'm looking at this from a GStreamer 0.8 maintainer point of view, not from a goobox user point of view. Anyway, no: I wont forcingly request removal of GStreamer 0.8 under the feet of goobox. However, I kindly invite you to consider whether it's worthwhile to continue your efforts with the current goobox release. I hope you don't mind the unsolicited advice, but I personally see goobox as superseded functionality-wise (especially by other gnome.org software), and bit-rotting (no upstream release in 2006, still using GStreamer 0.8); I suppose it's hard to throw away your polishing efforts, perhaps the alternative is for you to become upstream for goobox and update it to GStreamer 0.10. -- Loïc Minier <[EMAIL PROTECTED]> "I have no strong feelings one way or the other." -- Neutral President -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Hal issues with RB (Was: Dropping GStreamer 0.8 for etch)
On Mon, Dec 11, 2006, Sven Arvidsson wrote: > If you're not running a complete GNOME environment, it's possible that > hal is missing. Rhythmbox seems to need it for audio CD playback. At > least that's what bug 380503 indicates. RB recommends gnome-volume-manager which depends on hal, but it might make sense to Recommend or even depend on hal, I didn't check whether it helps. -- Loïc Minier <[EMAIL PROTECTED]> "I have no strong feelings one way or the other." -- Neutral President -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: madison not working correctly on merkel
On Sun, Dec 17, 2006, David Weinehall wrote: > Some entries seem to list newer Debian-versions than upstream > versions... Some watch-files out of sync? The list of GNOME versions is built from the 2.16 tarball repository, but Debian might have cherry-picked some newer upstream releases, such as libxml2 2.6.27. -- Loïc Minier <[EMAIL PROTECTED]> "Forget your stupid theme park! I'm gonna make my own! With hookers! And blackjack! In fact, forget the theme park!" -- Bender -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: FSG Packaging Summit in Berlin
On Thu, Jan 04, 2007, Jonathan Corbet wrote: > Debian will get the Etch release out this year. Honest. What > could possibly go wrong? Thereafter, the Debian developers will > go back to arguing about firmware in the kernel. Perhaps avoiding "the Debian developers" would make it softer, especially from the PoV of individual developers: "Thereafter, we will probably see some long arguing about firmware in the kernel on various Debian lists". -- Loïc Minier <[EMAIL PROTECTED]> -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: pkg-config including too much crap
On Tue, Apr 04, 2006, Martijn van Oosterhout wrote: > Well, the thing is that the .pc doesn't list all those libraries, it's > just that pkg-config is adding them. The .pc file looks like below. > Apparently, pkg-config is following the "Requires" link and appending > all those libs also. Perhaps that's supposed to be Requires.private. > Of perhaps the Requires shouldn't be there at all. Yes, it's following Requires and will pull Cflags and Libs from other modules. I think it would be ok in your case to move from Requires to Requires.private. There are some cases where this is not possible, for example would gtkspell/gtkspell.h #include gtk.h, it should pull the -I flags to see gtk.h; this -I flags is in the Cflags from gtk.pc, and hence gtkspell would need to Require gtk. On a related subject, I wonder if GtkSpell should depend on glib and #include its header to #define gchar, GError etc. Bye, -- Loïc Minier <[EMAIL PROTECTED]> -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: pkg-config including too much crap
On Tue, Apr 04, 2006, Roger Leigh wrote: > 1. gtk+-2.0.pc does not use Libs.private. This would clean up most of >the libraries. This is a GTK+ bug. gtk+-2.0.pc's Libs only has -lgtk, it requires gdk, atk, and cairo because of grep -ir #include /usr/include/gtk-2.0 | grep -v 'atk' (it needs at least the Cflags). Some people go as far as saying that since the headers are included from gtk's headers, the resulting binaries should be linked against these dependency-libs. Some discussion of this in #340904 and friends. > 2. Even then, -lgtk-x11-2.0 still needs to come from the Requires, but >should still be private. For this, a Requires.private would be the >best solution (but its Cflags should still remain public). This >needs implementing in pkg-config. Exactly, the Cflags should always be used IMO, there's some debate on whether one should still link against libs of which the headers are seen. -- Loïc Minier <[EMAIL PROTECTED]> -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: per-architecture Provides field
Hi,
On Wed, Apr 12, 2006, Erast Benson wrote:
> +Provides: sunwlxsl [solaris-i386]
> Depends: ${shlibs:Depends}
Why not simply use Provide: ${misc:Provides} and set misc:Provides to
sunwlxsl on solaris-i386? Why not simply Provide: sunwlxsl all of the
time, doesn't it provide sunwlxsl on other arches?
Cheers,
--
Loïc Minier <[EMAIL PROTECTED]>
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bug#362878: libgtk2.0-0: changelog.Debian.gz is not an upstream changelog
Christian, On Sun, Apr 16, 2006, Christian Marillat wrote: > Apparently you don't understand (or don't care), because this is the second > time I file the same bug report (#344125), but as this package isn't a > native package the upstream changelog should not be here. You're not in the perfect place to criticize the contents of Debian changelogs, see #244288. Be tolerant to your fellows, -- Loïc Minier <[EMAIL PROTECTED]> "You can gtk_main_run, but you can't gtk_widget_hide." --danw, 19-jul-04 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bug#363250: general: Custom PAGER gives error on sid, but works on sarge
reassign 363250 man retitle 363250 Please clarify how $PAGER is invoked in the man manpage stop Hi, On Tue, Apr 18, 2006, Rohan Dhruva wrote: > export PAGER="col -b | view -c 'set ft=man nomod nolist titlestring=MANPAGE' > -" This $PAGER definition makes the assumption that it's passed to sh -c (you use pipes and quotes). The man manpage doesn't say that $PAGER is passed to sh -c, it says it will use $PAGER as the program to display the manual page. I suggest you use: export PAGER="sh -c \"col -b | view -c 'set ft=man nomod nolist titlestring=MANPAGE' -\"" which explicitely calls sh -c to handle pipes and quotes in the expected way. You may also use your own /usr/local/bin/pager with: #!/bin/sh col -b | view -c 'set ft=man nomod nolist titlestring=MANPAGE' - and with PAGER=/usr/local/bin/pager. I am reassigning to man for the man manpage to be clarified with respect to the way $PAGER is called. Bye, -- Loïc Minier <[EMAIL PROTECTED]> "You can gtk_main_run, but you can't gtk_widget_hide." --danw, 19-jul-04 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bug#363250: general: Custom PAGER gives error on sid, but works on sarge
reassign 363250 man-db retitle 363250 please clarify in the man manpage how $PAGER is invoked stop Hi, On Tue, Apr 18, 2006, Rohan Dhruva wrote: > I suggest you use: > export PAGER="sh -c \"col -b | view -c 'set ft=man nomod nolist > titlestring=MANPAGE' -\"" > That didnt work. It works here, under zsh as well as under bash. Check with a new user. Are you using aliases? > man: command exited with status 256: /usr/bin/zsoelim /tmp/zmanqn0tzd | /usr/ > bin/tbl | /usr/bin/nroff -mandoc -rLL=89n -rLT=89n -Tutf8 | sh -c col -b | > view > -c 'set ft=man nomod nolist titlestring=MANPAGE' - I don't see anything similar being called on my system. I suggest you run something like: strace -o foo.strace -f -e execve -e signal= -q -v -s 200 man vim and attach the resulting foo.strace (warning: contains sensitive information). Also, please mention the version of man you are using (dpkg -l man-db), and your environment (env > foo.env, warning: contains sensitive information). Bye, -- Loïc Minier <[EMAIL PROTECTED]> "You can gtk_main_run, but you can't gtk_widget_hide." --danw, 19-jul-04 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bug#363250: general: Custom PAGER gives error on sid, but works on sarge
On Tue, Apr 18, 2006, Adeodato Simó wrote: > > view: -s option is only applicable to ex. > % /usr/sbin/update-alternatives --display view | grep current (I redirected the discussion to the bug report for the second time; FYI, it was nview.) -- Loïc Minier <[EMAIL PROTECTED]> "You can gtk_main_run, but you can't gtk_widget_hide." --danw, 19-jul-04 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bug#363250: general: Custom PAGER gives error on sid, but works on sarge
On Wed, Apr 19, 2006, Henning Makholm wrote: > Policy does not really specify how to handle $PAGER and its friends Feel free to clone against policy, I agree that it would be cleaner to define how it should be called in policy (but it would still be nice to have man man document how $PAGER is invoked too, or link to policy). -- Loïc Minier <[EMAIL PROTECTED]> "You can gtk_main_run, but you can't gtk_widget_hide." --danw, 19-jul-04 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bug#363250: general: Custom PAGER gives error on sid, but works on sarge
Hi, On Fri, Apr 21, 2006, Manoj Srivastava wrote: > Here is my solution for using vim + script as a pager; similar > mechanisms can be used to use plain vim as PAGER as well. Nice, I suggest filing a new bug against vim to propose this as a contrib script, or to ship it as "vim-pager" wrapper. #363250 is more about documenting the semantics of $PAGER (whether it can uses sh syntax, or whether it's a command with parameters separated with spaces), to be documented in man man, and/or policy. There's also another bug discussed in #363250 which is about nview's view not working correctly, but I didn't look into that. Bye, -- Loïc Minier <[EMAIL PROTECTED]> "You can gtk_main_run, but you can't gtk_widget_hide." --danw, 19-jul-04 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bug#363250: general: Custom PAGER gives error on sid, but works on sarge
On Sat, Apr 22, 2006, Manoj Srivastava wrote: > > #363250 is more about documenting the semantics of $PAGER (whether > > it can uses sh syntax, or whether it's a command with parameters > > separated with spaces), to be documented in man man, and/or policy. > Err, we should define how it behaves, not what is inside > it. As long as one can pipe things to $PAGER or use $PAGER on a file, > what it contains should not matter. Please read again the original report, the submitter wanted to have a pipe of commands in $PAGER, he said this worked in the past, and works on other distros. He did not want to simply be able to use $PAGER on a file or to pipe stuff to $PAGER, he wanted $PAGER to be parsed as a pipeline, as in sh syntax. > The safe bet would be for $PAGER to be a script or executable > which can handle reading from file or STDIN, like proper UNIX > programs. This is an independent problem First, we already have one layer of sh scripting with the sensible-pager program, and it would be a good enough place to handle the cases you mention, would people and programs use sensible-pager as the default pager. Second, this doesn't define what should happen when someone redefines $PAGER: what if one user wants $PAGER to be a pipeline? > To make life easier for people writing programs which deal > with $PAGER, and are using the POSIX exce* set of calls, one may > constrain $PAGER to "path [arg [arg ..]]", with no pipes or other > shell meta-characters. Yes, I think this is safe, but I'd go even further and propose the following: A/ handling of pager in programs 1/ programs should default to sensible-pager 2/ programs should offer a way to override the default pager in some way, for example via an environment variable called _PAGER, or a configuration setting -- it might even be better for them to avoid handling $PAGER, see 1/ B/ user configuration of the pager When defined, $PAGER is a sh pipeline which reads its data from stdin. This is with the intent of moving any logic for deciding of the best pager to run out of each individual program requiring a pager, exactly as in the sensible-browser case, which can consider $BROWSER, $DISPLAY, x-www-browser, and www-browser to find a sensible browser. Manoj, how would this fit in policy? -- Loïc Minier <[EMAIL PROTECTED]> "You can gtk_main_run, but you can't gtk_widget_hide." --danw, 19-jul-04 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bug#363250: general: Custom PAGER gives error on sid, but works on sarge
Hi, On Sat, Apr 22, 2006, Manoj Srivastava wrote: > > Please read again the original report, the submitter wanted to have > > a pipe of commands in $PAGER, he said this worked in the past, and > > works on other distros. He did not want to simply be able to use > > $PAGER on a file or to pipe stuff to $PAGER, he wanted $PAGER to be > > parsed as a pipeline, as in sh syntax. > I read it. I still think that my answer suffices: Put your > pipeline in a script, and set that to PAGER. If I have a file that I > want the users to see, as opposed to output I create, how can I > figure out how to use the example in the initial bug report? The point is that it used to work with a pipeline, as explained by the submitter, in the past and now it doesn't work, I later replied that it was never said that the content of $PAGER was following sh syntax. You propose a (valid) workaround, I propose to fix the policy, and to even actually support sh syntax (as this is trivial to do from sensible-pager). > There are two use cases that any pager directive must address: > 1) The program is going to generate output which must be piped to >a pager > 2) The program want to send a file to the user. I agree that these use cases need to be supported. > If the PAGER semantics are defined to state that whatever you > change it to must work in the two use cases, then programs that use > PAGER directly would not have an issue. But, if I follow you, this would prevent pipelines. > But perhaps the policy for Debian should be for programs to > ignore PAGER and just use sensible pager, where all the logic for > dealing with pager goes in. I still don't see how sensible pager can > handle the pipeline vs the non-pipeline case, though. Yes, I believe the policy should be changed in this way, and as I proposed. Look at the code of sensible-pager, it will call "$PAGER" if sensible-pager is called without any argument, and "$PAGER " if it's called as "sensible-pager ". This seems good enough for me; if people set $PAGER to a pipeline, they might suffer from problems for the second case, but we can work on that. > Barring that, policy would have to be that programs can' t > user PAGER to work with use case 2, and must be guilty of an "useless > use of cat" to pipe data to STDIN for PAGER. Yes, if you mean that permitting pipelines forbids programs to call "$PAGER $file", I agree with you. There are multiple ways to solve this, but I think that whatever way is chosen should be implemented in sensible-pager, and we can even change our mind later, and fix only sensible-pager. The contract of sensible-pager with respect to Debian programs should be to offer two modes of operation, the pipe of data on stdin mode, and the pass a file on the command line mode (matching your use cases 1 and 2). > PAGER has the benefit of being long standardized, and if we do > not use PAGER, we are breaking user expectations. > What is the benefit of creating a PAGER clone? sensible-pager is not a PAGER clone, it permits us to enhance the handling of $PAGER in a single place instead of changing every program in Debian that wants to send something to $PAGER. Have a look at the sensible-browser code, and at #351901 to convince you that there are useful things that can be done in such a nice place as sensible-pager. Eg, we might send data to "yelp" if running under GNOME. > > B/ user configuration of the pager When defined, $PAGER is a sh > > pipeline which reads its data from stdin. > How do programs present a text file to the user using a PAGER, > then? cat file.txt | $PAGER? That's a question for sensible-pager to solve, but one way is to use cat "$@" | $PAGER indeed. > > This is with the intent of moving any logic for deciding of the best > > pager to run out of each individual program requiring a pager, > > exactly as in the sensible-browser case, which can consider > > $BROWSER, $DISPLAY, x-www-browser, and www-browser to find a > > sensible browser. > In other words, ignore $PAGER, use sensible-pager all over, > and let that handle it? Yes. > Not, unless these questions are answered, and we actually have > a working implementation. Well the current implementation works, except for pipelines. :) Bye, -- Loïc Minier <[EMAIL PROTECTED]> "You can gtk_main_run, but you can't gtk_widget_hide." --danw, 19-jul-04 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bug#363250: general: Custom PAGER gives error on sid, but works on sarge
On Sun, Apr 23, 2006, Manoj Srivastava wrote: > Since allowing pipelines seems to be the motivating factor > here, we do need to solve that, I think. Yes, indeed, the root of the problem is the change of support for pipelines. However, I'm not sure that pipelines worked in the use case of passing a file as a parameter to $PAGER in the past. Currently, each program (for example man) has its way of calling $PAGER, perhaps as "$PAGER " or piping to "sh -c "$PAGER"", or perhaps piping directly to "$PAGER". Of course, if we say $PAGER can be a pipeline, and a pager can be used both as "$PAGER " and as the end of a pipeline, then defining $PAGER to be a pipeline must work in both cases, but I'm not sure it is a regression to not support pipelines in the use case of a file name as argument. In other words: $PAGER is a $PAGER is a program pipeline call $PAGER as works ??? $PAGER call $PAGER as cat | $PAGERworks works I do agree that the two use cases that you listed in a previous message exist, I'm not sure they were both supported in the case where $PAGER is a pipeline, but we can work on fixing that at least in sensible-pager by using systematically: cat "$@" | $PAGER Bye, -- Loïc Minier <[EMAIL PROTECTED]> "You can gtk_main_run, but you can't gtk_widget_hide." --danw, 19-jul-04 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bug#363250: general: Custom PAGER gives error on sid, but works on sarge
On Sun, Apr 23, 2006, Manoj Srivastava wrote: > Historically, if my memory serves me correctly, one used PAGER > to specify the program, and the default arguments. PAGER essentially > worked as an shell alias: > PAGER= less -cim > And then you could either pipe thigs to ti, or call it on a file. I > am not sure if I recall a-pipeline-as-pager ever working, even way > back in the mid 80's. The proposal adds support for it, and indirectly addresses the regression mentionned in the bug report which started this discussion. -- Loïc Minier <[EMAIL PROTECTED]> "You can gtk_main_run, but you can't gtk_widget_hide." --danw, 19-jul-04 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Making init scripts use dash
On Thu, May 18, 2006, Margarita Manterola wrote: > During some tests I've performed, I've found that making the init > scripts run with dash as default shell instead of bash makes the boot > time a 10% faster (6 seconds in a 60 second boot). [...] > 2. Change #!/bin/sh for #!/bin/dash in the scripts Right now, if a script is named ".sh", it is sourced, perhaps it's enough to change /etc/init.d/rc to use dash, depend on dash there (sysv-rc), and progressively convert init scripts to use a symlink ending in .sh when they are POSIX? -- Loïc Minier <[EMAIL PROTECTED]> "You can gtk_main_run, but you can't gtk_widget_hide." --danw, 19-jul-04 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#368511: Removal of libgtk1.2 ruby bindings (meta-bug)
Package: general Severity: wishlist Hi, I wish we could stop shipping the Ruby bindings for libgtk1.2. (libgtk1.2 being completely obsolete) The rdepends show: bee% apt-cache rdepends libgdk-imlib-ruby1.6 libgtk-ruby1.6 libglade-ruby1.6 libgdk-pixbuf-ruby1.6 libart-ruby1.6 libgnome-ruby1.6 libgdk-imlib-ruby1.6 Reverse Depends: libgnome-ruby1.6 libgnome-ruby1.6 Reverse Depends: libglade-ruby1.6 libart-ruby1.6 Reverse Depends: libgnome-ruby1.6 libglade-ruby1.6 Reverse Depends: libgtk-ruby1.6 Reverse Depends: rsjog libxml-parser-ruby1.6 libglade-ruby1.6 libgdk-pixbuf-ruby1.6 libgdk-imlib-ruby1.6 libgdk-pixbuf-ruby1.6 Reverse Depends: This only shows rsjog and libxml-parser-ruby1.6 as real rdeps, so it should be possible to get rid of these bindings quite rapidly. Bye, -- Loïc Minier <[EMAIL PROTECTED]>
Re: gnome 1 packages up for adoption
On Sat, May 27, 2006, Steve Langasek wrote: >python-gnome has a build-dependency on libgtkhtml-dev which > should be trivially removable since none of its binary packages use it. python-gnome is also deprecated and should go away when possible, I've filed bugs on the rdeps already. (As Steve already pointed out, this caused me to make the same mistake as Thomas, because apt-cache rdepends includes Suggests and Conflicts). -- Loïc Minier <[EMAIL PROTECTED]> "You can gtk_main_run, but you can't gtk_widget_hide." --danw, 19-jul-04 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#370336: ITP: gnome-python-desktop -- Python bindings for the GNOME desktop environment
Package: wnpp Severity: wishlist Owner: Loic Minier <[EMAIL PROTECTED]> * Package name: gnome-python-desktop Version : 2.14.0 Upstream Author : Benoît Dejean <[EMAIL PROTECTED]>, Gustavo Carneiro <[EMAIL PROTECTED]>, James Henstridge <[EMAIL PROTECTED]>, Johan Dahlin <[EMAIL PROTECTED]>, John Palmieri <[EMAIL PROTECTED]>, Matt Wilson <[EMAIL PROTECTED]>, Iñigo Serna <[EMAIL PROTECTED]>, Stéphan Kochen <[EMAIL PROTECTED]>, Tiago Cogumbreiro <[EMAIL PROTECTED]>, Raphael Slinckx <[EMAIL PROTECTED]> * URL : http://ftp.gnome.org/pub/GNOME/sources/gnome-python/ * License : Mixture of GPL and LGPL Programming Lang: Python Description : Python bindings for the GNOME desktop environment This package holds the Python bindings for libraries of the GNOME desktop which are not already in the pygtk bindings. I intend to start from Ubuntu's package. -- System Information: Debian Release: testing/unstable APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.16-2-686 Locale: [EMAIL PROTECTED], [EMAIL PROTECTED] (charmap=ISO-8859-15) -- Loïc Minier <[EMAIL PROTECTED]>
Re: mystery of dh_installdirs
Hi, On Fri, Jun 09, 2006, Atsuhito Kohda wrote: > Hi all, I got an FTBFS bug yesterday; > > There was an error while trying to autobuild your package: > > > install -m 755 debian/lynx > > > /build/buildd/lynx-cur-2.8.6dev18/debian/lynx-cur-wrapper/usr/bin/lynx-cur > > > install: cannot create regular file > > > `/build/buildd/lynx-cur-2.8.6dev18/debian/lynx-cur-wrapper/usr/bin/lynx-cur': > > > No such file or directory From the buildd log, this seems wrong: # Add here commands to install the package into debian/. /usr/bin/make install-full x=".cur" prefix=/build/buildd/lynx-cur-2.8.6dev18/debian/lynx-cur/usr \ libdir=/build/buildd/lynx-cur-2.8.6dev18/debian/lynx-cur/etc/lynx-cur \ docdir=/build/buildd/lynx-cur-2.8.6dev18/debian/lynx-cur/usr/share/doc/lynx-cur \ helpdir=/build/buildd/lynx-cur-2.8.6dev18/debian/lynx-cur/usr/share/doc/lynx-cur/lynx_help \ mandir=/build/buildd/lynx-cur-2.8.6dev18/debian/lynx-cur/usr/share/man/man1 The "prefix" and other vars you pass to configure shouldn't be overriden in make install. You should switch to using "DESTDIR" instead. Even if your package does not use automake, it seems to properly implement DESTDIR support. make install DESTDIR=debian/tmp This is also scary: mv -f /build/buildd/lynx-cur-2.8.6dev18/debian/lynx-cur/usr/bin/lynx.cur /build/buildd/lynx-cur-2.8.6dev18/debian/lynx-cur/usr/bin/lynx.old mv: cannot stat `/build/buildd/lynx-cur-2.8.6dev18/debian/lynx-cur/usr/bin/lynx.cur': No such file or directory m I couldn't reproduce the build failure the buildd experienced neither on my sid, nor in a pbuilder but I think you should fix the above problems first to see clearer in the problem. Perhaps it's a permission problem due to the usage of different umasks on the buildd setups and on our setups? I saw numerous "mkdir" and "cp" calls, which should IMO be install -d and install calls. Oh and you might want to use dh_install and debian/*.install instead of calling install manually. Bye, -- Loïc Minier <[EMAIL PROTECTED]> -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
