Re: So whos going to ALS
On Tue, Oct 05, 1999 at 04:55:12PM -0400, Johnie Ingram wrote: > > ... and would be willing to help at the Debian booth (#503, community > pavillion, check it out), or who knows good places to stay at in > Atlanta? Or who wants to planepool with the Novare team from Dallas? I'll be there for the duration, at the FSF booth. I'll be sure to stop by the Debian booth to see how things are going. Peter
Re: (Beware helix packages) Re: [CrackMonkey] The right to bare legs
On Tue, Aug 29, 2000 at 10:02:04PM -0500, Branden Robinson wrote: > > No, there is no difference between our apps and the upstream in most > > cases. We do brand gnome-core and gdm, but those are the only packages > > I can think of offhand. Those are only graphics changes, substituting > > some of our images in place of the defaults. > > Okay, fine. Name the Helixified packages under the following scheme: > > Package: helix-gnome-core > Conflicts: gnome-core > Provides: gnome-core > > Package: helix-gdm > Conflicts: gdm > Provides: gdm > > (The Provides: gdm isn't necessary if nothing depends on it, and off the > top of my head I can't think of anything that would depend on a display > manager.) The task-helix-core package I provide depends on gdm. That's the only one I can think of offhand, though, and I would want to depend on helix-gdm there. This solution looks like the best one. I'll start rebuilding our packages immediately. > > We are only collecting existing apps in an easily installed and > > updated set. We have never claimed to do anything else. > > Then why not just ship the Debian versions? Or, if you making > non-Helixified changes and bugfixes, why not submit them back to Debian? The reason why we aren't shipping the Debian versions is that the current binary packages are guaranteed to work on both potato and woody, so I have to provide all the dependencies in our packages. This is very broken. Fixing this is going to be part of the grand rebuild for helix-* packages. Peter
Re: (Beware helix packages) Re: [CrackMonkey] The right to bare legs
On Wed, Aug 30, 2000 at 01:20:48AM -0600, Jason Gunthorpe wrote: > > On Wed, 30 Aug 2000, Branden Robinson wrote: > > > > That is one mechanism of creating a private namespace, isn't another > > > Setting the origin to something other than Debian? > > > > Please see elsewhere in this thread for my other remarks on this subject. > > > > An Origin field is a great idea. > > We have one, sorry I am so late making it be really useful - very busy you > know.. > > Assuming I can manage to get in the proper frame of mind this problem > should become much less troubling for most APT users. > > The versioning scheme I will suggest is fairly direct: [ versioning scheme removed ] This looks good to me. I will start obeying these standards in the Helix GNOME packages. Peter
Re: (Beware helix packages) Re: [CrackMonkey] The right to bare legs
On Wed, Aug 30, 2000 at 03:50:08PM +0200, Christian Marillat wrote: > >>>> "PT" == Peter Teichman <[EMAIL PROTECTED]> writes: > > [...] > > PT> This solution looks like the best one. I'll start rebuilding our > PT> packages immediately. > > Don't forget to put this field in debian/control: > > Send-To: [EMAIL PROTECTED] Oh, thanks for reminding me. I just got this added to our build system.. I still have to rebuild everything to take advantage of it though. Peter
Re: (Beware helix packages) Re: [CrackMonkey] The right to bare legs
On Wed, Aug 30, 2000 at 01:20:48AM -0600, Jason Gunthorpe wrote: > 3) Libraries - All possible effort should be made to make Debian the > primary source of libraries. Period full stop. This is so important > because of what we are seeing with helix and their special library > packages now. Thus, I suggest the following: I agree with this completely. >a) If a add-on vendor needs a newer upstream library then they > can follow standard NMU procedures, using a -0.1.helix type tag. >b) If their is some critical bug in the Debian library then they > should still follow NMU type procedures and work with the > Debian library packager and upstream to make sure the next rev > is properly fixed. >c) I recommend the vendor provide a seperate section of their > FTP site specifically for libraries, and tagged with a proper > Release file. The libraries they collect there should be the > libraries they use and have modified. It would be best if most > of these files were exactly identical to what Debian ships. > Rational: > i) I expect people like helix will include woody > libraries that work on a potato system. These can use the > 'usual' 1.2-0.1.woody.1 tagging scheme and probably will not > be included by Debian. Our potato packages are going to move on to their own directory, so we won't be trying to make packages work on both woody and potato. That will resolve my having to put most library packages in with our woody stuff. As far as I can tell, the Helix GNOME support for woody is only going to be about five packages. > ii) I want the user to be able to say 'I want only helix gnome > but pick the newest library from the union of > debian+helix'. This is easiest if the libraries are > seperated. >iii) Libraries are truely a shared resource, we need to take > special steps to ensure apps in Debian linked to them work > and apps in Helix linked to them work - best way to that > is to only have 1 library package that everyone uses and > tests against. I have one question. What is the preferred way for me to handle our gtk package? This is a library package that we actually apply some patches to for a slightly nicer user interface. Peter
Re: (Beware helix packages) Re: [CrackMonkey] The right to bare legs
On Tue, Sep 05, 2000 at 12:29:32AM +1100, Donovan Baarda wrote: > I believe the infamous "aalib" affair actualy came out of a wishlist > bugreport submitted to them by a user; the then frozen potato aalib was too > low a version to meet all the helix dependencies. This meant people like me > had to pull aalib from unstable before I could install helix. By putting an > updated aalib into helix, debian potato users could apt-get helix without > that small hickup. It sounds like Helix made their own package rather than > grab the one from unstable... probably an un-necisary mistake. Dunno why > they did that, maybe so all the helix packages had a "helix" version number > for consistancy? Yes, this is what happened. It was a mistake on my part, and I rebuilt our Gimp packages and removed aalib as soon as the issue came up on debian-devel. The problem was introduced when I didn't know the Debian shlibs setup well enough to override a false version dependency I picked up from the Woody aalib. It was fixed in our archive at the beginning of this discussion, and Joey has now uploaded a version to Woody that overrides the Helix one. I am sorry that Woody had to be affected (the revision of aalib is now -w30) as a result of the Helix GNOME packages. Based on my current plans and the discussion on this list, I think that this sort of thing will not happen again. Again, I apologize. Peter -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: ITP: SkipStone
On Tue, Sep 05, 2000 at 11:03:07AM -0400, Brian Almeida wrote: > Skipstone is a GTK+ webbrowser that uses mozilla's embed features. It is > similar to galeon only it is pure GTK+, no GNOME. The author asked me to > make packages of it, and I have uploaded it into Debian. It is placed under > the GPL. See http://www.muhri.net/skipstone/ for more info. Skipstone appears to have some licensing problems. It has no overall license file, just comments in its source. Also, the Mozilla rendering component is released under the MPL, which is incompatible with the GPL. Galeon had to relicense with an exception clause - take a look at the current Galeon tarball for the COPYING.README file. Peter -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: gtk-doc vs glib1.2-dev info file conflict
On Wed, Dec 27, 2000 at 03:19:11PM +0100, Svante Signell wrote: > I have the helix version installed: > (Also this version should replace libgtk-doc, shouldn't it?) Whenever any helix packages are involved, [EMAIL PROTECTED] is the appropriate place to report problems. Not debian-devel. > #dpkg -s libglib1.2-dev > Package: libglib1.2-dev > Status: install ok installed > Priority: optional > Section: devel > Installed-Size: 367 > Maintainer: Helix Code, Inc. <[EMAIL PROTECTED]> > Source: glib1.2 > Version: 1.2.8-helix1 > Replaces: libgtk-doc, libglib1.1.5-dev, libglib1.1.6-dev, libglib1.1.9-dev, > libglib1.1.11-dev, libglib1.1.12-dev, libglib1.1.13-dev, libglib1.1.16-dev > Provides: libglib-dev, libglib1.1-dev > Depends: libglib1.2 (= 1.2.8-helix1) > Suggests: libgtk1.2-dev, libgtk1.2-doc > Conflicts: libglib-dev, libglib1.1.5-dev, libglib1.1.7-dev, libglib1.1.8-dev, > libglib1.1.9-dev, libglib1.1.10-dev, libglib1.1.11-dev, libglib1.1.12-dev, > libglib1.1.13-dev, libglib1.1.16-dev Yes, this package does Replace: libgtk-doc. The problem is that you are trying to upgrade libgtk-doc, which doesn't Replace: libglib1.2-dev. libgtk-doc is an old package, for gtk+ 1.0. I suspect that you want to remove that and install libgtk1.2-doc. Peter
Re: switching to libxml2
On 23 Apr 2001 20:58:57 +0200, Federico Di Gregorio wrote: > libglade and some other packages still depend on the very old libxml1. > i just compiled libglade0 (and libglade-gnome0) by simply installing > libxml2-dev and rebuilding. anyway, porting a package from libxml1 to > libxml2 is quite easy, so i am about to file bugs agains those buggy > packages. i am also quite ready to nmu if the authors don't rebuild > but what's the procedure in this case? i don't want to displease > anyone, but this dependency on the old library is annoying quite some > of us. > > ciao, > federico > > p.s. the problem is that libxml1-dev confliscts with libxml2-dev and > the maintainmer does not want to fix that because packages should not > use an old and deprecated library. obviously i agree. libxml1 is not deprecated. It is the xml library used by the GNOME 1.x platform. Until GNOME 2 is released, libxml1 will be in active use. There are significant source-level differences between applications that use the two, so a porting effort would be a large amount of work. That said, recent versions of the two xml libraries are made to coexist. There shouldn't be any files in common between the two. Any conflict between libxml1-dev and libxml2-dev is an artificial one. Peter
Re: KDE gone, Lyx next ?
On Sat, Oct 10, 1998 at 09:20:55AM +0200, Michael Meskes wrote: > On Fri, Oct 09, 1998 at 11:14:06PM -0700, Darren Benham wrote: > > Has it been verified that lyx can't be linked against fltk? > > Just try and you see it won't compile. But I have not much knowledge about > these toolkits so maybe someone can easily port it. Also I remember someone > working on a gtk version. Is there anything out there? There has been some talk on gnome-list of a gtk port. When it was last mentioned, a member of the LyX team said that they were working on a toolkit-independent layer. Once that is done, supposedly, it will be ported to other toolkits. There is definitely some interest in porting it to gtk (& probably gnome). This says to me that the LyX folks are at least aware of some toolkit issues. They should still be contacted on the license stuff, I'd say.. I doubt that the toolkit-independence will be done very soon, and they should be notified anyway.. Peter -- Peter Teichman (Parenthetic Me) [EMAIL PROTECTED]
