From wormey at eskimo.com Wed Sep 1 23:00:33 2010 From: wormey at eskimo.com (Space Case) Date: Wed, 1 Sep 2010 23:00:33 -0700 Subject: New problem: menu bar disappeared In-Reply-To: <6DBFD1E6-D058-40D0-9E18-A8087503754C@algonet.se> Message-ID: <201009020600.XAA12043@eskimo.com> Hi. I'm still working my biarch problem, and finding some interesting things. I'll report on that later. Right now, I have another system, Fedora rawhide x86_64, Smart 1.3 that is being a problem. The menu bar has disappeared, and I don't know how I made it do that. Is there a way to make smart show me the menu bar? Thanks, Steve From afb at algonet.se Thu Sep 2 00:56:05 2010 From: afb at algonet.se (=?ISO-8859-1?Q?Anders_F_Bj=F6rklund?=) Date: Thu, 2 Sep 2010 09:56:05 +0200 Subject: New problem: menu bar disappeared In-Reply-To: <201009020600.XAA12043@eskimo.com> References: <201009020600.XAA12043@eskimo.com> Message-ID: Space Case wrote: > Right now, I have another system, Fedora rawhide x86_64, > Smart 1.3 that is being a problem. The menu bar has > disappeared, and I don't know how I made it do that. > > Is there a way to make smart show me the menu bar? There is not really a way of *hiding* the menu, so no way of showing it either. Sounds like a GTK+ bug. (like the earlier Glib 2.24 multi-threading bug...) Does `pygtk-demo` have any of the same problems ? If so: "Doctor, it hurts when I run rawhide" ;-) --anders From wormey at eskimo.com Thu Sep 2 20:32:30 2010 From: wormey at eskimo.com (Space Case) Date: Thu, 2 Sep 2010 20:32:30 -0700 Subject: New problem: menu bar disappeared In-Reply-To: Message-ID: <201009030332.UAA08469@eskimo.com> On Sep 2, 9:56am, =?ISO-8859-1?Q?Anders_F_Bj=F6rklund?= wrote: >There is not really a way of *hiding* the menu, so >no way of showing it either. Sounds like a GTK+ bug. >(like the earlier Glib 2.24 multi-threading bug...) > >Does `pygtk-demo` have any of the same problems ? > >If so: "Doctor, it hurts when I run rawhide" ;-) That's what it is. I can't get gnome-terminal to display a menu, either. Time for some updating, methinks. Thanks, Steve From wormey at eskimo.com Sat Sep 4 00:13:55 2010 From: wormey at eskimo.com (Space Case) Date: Sat, 4 Sep 2010 00:13:55 -0700 Subject: How to set a generic lock flag? In-Reply-To: <6DBFD1E6-D058-40D0-9E18-A8087503754C@algonet.se> Message-ID: <201009040713.AAA14593@eskimo.com> On Sep 1, 8:32am, =?ISO-8859-1?Q?Anders_F_Bj=F6rklund?= wrote: >So gnome-gnames is being suggested as part of >another install/upgrade ? (maybe use --explain) > >Something or other along the chain of dependencies >should be pulling those @i586 dependencies in, no ? OK, I have a couple of interesting cases. One is where there's a package conflict, it wants to install an i586 package. Remove the conflicting package, and the desire for i586 goes away. The second is where an upgraded package wants a noarch lang package. Attempt to upgrade the package, it wants to upgrade a total of 57 packages and install 6. Installing the lang package itself results in also upgrading the base package, and nothing else. I still have some i586 packages that want to install, if you want me to look at something else: python-qt4-4.7.3-3.11 at i586 mozilla-js192-1.9.2.8-3.1 at i586 python-sip-4.10.2-3.1 at i586 Thanks, Steve Selected bits of smart output: (I use ellipses (...) to denote removal of uninteresting text) smart> upgrade libwebkitgtk-devel Upgrading packages (2): libwebkitgtk-devel-1.3.3-2.2 at i586 Upgrades: libwebkit-devel-1.2.3-0.1.1 at x86_64 (upgraded) Conflicts: libwebkit-devel-1.2.3-0.1.1 at x86_64 (upgraded) libwebkitgtk-devel-1.3.3-2.2 at x86_64 Upgrades: libwebkitgtk-devel-1.3.3-2.1 at x86_64 (upgraded) libwebkit-devel-1.2.3-0.1.1 at x86_64 (upgraded) Conflicts: libwebkit-devel-1.2.3-0.1.1 at x86_64 (upgraded) smart> remove libwebkit-devel ... smart> upgrade libwebkitgtk-devel Upgrading packages (1): libwebkitgtk-devel-1.3.3-2.2 at x86_64 Upgrades: libwebkitgtk-devel-1.3.3-2.1 at x86_64 (upgraded) --------------------- gateway:~ # smart query --installed | grep gnome-desktop gnome-desktop-2.31.6-1.1 at x86_64 gnome-desktop-devel-2.31.6-1.1 at x86_64 libgnome-desktop-2-17-2.31.6-1.1 at x86_64 gateway:~ # smart --shell ... smart> upgrade gnome-desktop Upgrading packages (57): ... gnome-desktop-2.31.90-1.1 at x86_64 Upgrades: gnome-desktop-2.31.6-1.1 at x86_64 (upgraded) Requires: bundle-lang-gnome-en-11.3-15.1 at noarch (installed) Required By: nautilus-2.31.90-1.1 at x86_64 (installed) ... Installing packages (6): gnome-desktop-2.28.2-0.1.1 at i586 Requires: gnome-desktop-lang-2.28.2-0.1.1 at noarch (installed) Required By: nautilus-2.31.90-1.1 at x86_64 (installed) gnome-desktop-lang-2.28.2-0.1.1 at noarch (installed) gnome-desktop-lang-2.28.2-0.1.1 at noarch Requires: gnome-desktop-2.28.2-0.1.1 at i586 (installed) Required By: libgnome-desktop-2-11-2.28.2-0.1.1 at x86_64 (installed) gnome-desktop-2.28.2-0.1.1 at i586 (installed) ... Confirm changes? (Y/n): n smart> install gnome-desktop-lang Upgrading packages (1): gnome-desktop-2.31.90-1.1 at x86_64 Upgrades: gnome-desktop-2.31.6-1.1 at x86_64 (upgraded) Requires: gnome-desktop-lang-2.31.90-1.1 at noarch (installed) Required By: gnome-desktop-lang-2.31.90-1.1 at noarch (installed) Installing packages (1): gnome-desktop-lang-2.31.90-1.1 at noarch Requires: gnome-desktop-2.31.90-1.1 at x86_64 (installed) Required By: gnome-desktop-2.31.90-1.1 at x86_64 (installed) 863.8kB of package files are needed. 2.2MB will be used. Confirm changes? (Y/n): y smart> commit ... (download and install happens) ... smart> upgrade gnome-desktop No interesting upgrades available! From sriram at belenix.org Mon Sep 6 12:16:42 2010 From: sriram at belenix.org (Sriram Narayanan) Date: Tue, 7 Sep 2010 00:46:42 +0530 Subject: A question about bundling smart with our distribution Message-ID: Hello: I'm one of the team members of the Belenix Distro (www.belenix.org). We are presently using the SVR4 package format, and have wanted to move to a more modern day package format. We are very likely to use rpm5 as our package system :) We intend to bundle both yum and smart, and will leave it to our users as to which tool they'd like to use. Our question: Would you be OK with us using the smart given that most of the system libraries on our distro are CDDL licensed ? Thanks, Sriram -- Belenix: www.belenix.org From afb at algonet.se Mon Sep 6 13:00:34 2010 From: afb at algonet.se (=?ISO-8859-1?Q?Anders_F_Bj=F6rklund?=) Date: Mon, 6 Sep 2010 22:00:34 +0200 Subject: A question about bundling smart with our distribution In-Reply-To: References: Message-ID: <64B3CA46-4BDB-4808-9D98-B88D9B1E9C3A@algonet.se> Sriram Narayanan wrote: > I'm one of the team members of the Belenix Distro (www.belenix.org). > We are presently using the SVR4 package format, and have wanted to > move to a more modern day package format. The .pkg and .7z formats are available too, if you need them... It was added after discussion with other OpenSolaris community: https://code.launchpad.net/~afb/smart/pkg There was also a branch with some generic Solaris fixes, like broken file locking and such as discovered by OSUnix/StormOS: https://code.launchpad.net/~afb/smart/solaris But I guess neither project went ahead with Smart at the time, and Belenix was developing a custom package manager I think ? So we only added basic Nexenta support, with --ignore-locks. If you want to help test/support real Solaris support, great! > We are very likely to use rpm5 as our package system :) We intend to > bundle both yum and smart, and will leave it to our users as to which > tool they'd like to use. > > Our question: > Would you be OK with us using the smart given that most of the system > libraries on our distro are CDDL licensed ? I'm not sure what you are asking here. Smart is freely available under the GPLv2+ license. It works fine with rpm5 as the backend. Currently Smart 1.4 is under finalizing, but the Solaris support could be merged in for the next release (Smart 1.5) perhaps... ? --anders From sriram at belenix.org Mon Sep 6 13:29:15 2010 From: sriram at belenix.org (Sriram Narayanan) Date: Tue, 7 Sep 2010 01:59:15 +0530 Subject: A question about bundling smart with our distribution In-Reply-To: <64B3CA46-4BDB-4808-9D98-B88D9B1E9C3A@algonet.se> References: <64B3CA46-4BDB-4808-9D98-B88D9B1E9C3A@algonet.se> Message-ID: Hi: We're considering using rpm5 as our package system, with smart as the frontend. Moinak (CCd) had developed spkg as a stop gap arrangement till we figured out what to do next. We find IPS infeasible in low-bandwidth countries, and we wanted to move away from SVR4 to something that's more widely known. We have been apprehensive about package manager licensing ever since Debian Legal disliked how Nexenta modified and used dpkg (even though they wanted to conteibute back the source). Debian Legal's concerns were about Nexenta's dpkg linking with a non-GPL libc. There is once again a discussion thread about this on this month's Debian Legal mailing list. No one on the Belenix team is a lawyer, and we've all got day jobs where we do something else. So, we thought that the best thing to do is to simply ask on the smart mailing list whether you are OK with us building, linking and distributing smart code along with non-GPLd (yet opensource) libraries. -- Sriram On 9/7/10, Anders F Bj?rklund wrote: > Sriram Narayanan wrote: >> I'm one of the team members of the Belenix Distro (www.belenix.org). >> We are presently using the SVR4 package format, and have wanted to >> move to a more modern day package format. > > The .pkg and .7z formats are available too, if you need them... > It was added after discussion with other OpenSolaris community: > > https://code.launchpad.net/~afb/smart/pkg > > There was also a branch with some generic Solaris fixes, like > broken file locking and such as discovered by OSUnix/StormOS: > > https://code.launchpad.net/~afb/smart/solaris > > But I guess neither project went ahead with Smart at the time, > and Belenix was developing a custom package manager I think ? > > So we only added basic Nexenta support, with --ignore-locks. > If you want to help test/support real Solaris support, great! > >> We are very likely to use rpm5 as our package system :) We intend to >> bundle both yum and smart, and will leave it to our users as to which >> tool they'd like to use. >> >> Our question: >> Would you be OK with us using the smart given that most of the system >> libraries on our distro are CDDL licensed ? > > > I'm not sure what you are asking here. Smart is freely available > under the GPLv2+ license. It works fine with rpm5 as the backend. > > Currently Smart 1.4 is under finalizing, but the Solaris support > could be merged in for the next release (Smart 1.5) perhaps... ? > > --anders > > -- Sent from my mobile device Belenix: www.belenix.org From afb at algonet.se Mon Sep 6 13:44:35 2010 From: afb at algonet.se (=?ISO-8859-1?Q?Anders_F_Bj=F6rklund?=) Date: Mon, 6 Sep 2010 22:44:35 +0200 Subject: A question about bundling smart with our distribution In-Reply-To: References: <64B3CA46-4BDB-4808-9D98-B88D9B1E9C3A@algonet.se> Message-ID: Sriram Narayanan: > No one on the Belenix team is a lawyer, and we've all got day jobs > where we do something else. Me too. :-) But all the legalese should be in the LICENSE file (GPL). > So, we thought that the best thing to do is to simply ask on the smart > mailing list whether you are OK with us building, linking and > distributing smart code along with non-GPLd (yet opensource) > libraries. I'm fine with it myself, as I've used Smart on both Darwin and FreeBSD. Neither of which has GPL system libraries... Smart also runs on Mac OS X and Windows, which doesn't even have open source system libraries. Smart is still under GPL. And Python doesn't really "link" in the same way as C/C++ ? So as long as you contribute any changes you make to Smart... --anders From gustavo at niemeyer.net Mon Sep 6 14:13:18 2010 From: gustavo at niemeyer.net (Gustavo Niemeyer) Date: Mon, 6 Sep 2010 18:13:18 -0300 Subject: A question about bundling smart with our distribution In-Reply-To: References: <64B3CA46-4BDB-4808-9D98-B88D9B1E9C3A@algonet.se> Message-ID: Hey there, > So as long as you contribute any changes you make to Smart... That's not entirely the case. If the code is a change in Smart, or is using Smart as a library, it must be licensed as GPL too. That's the very basis of the GPL license, so we can't simply dismiss it or the license would have no value. -- Gustavo Niemeyer http://niemeyer.net http://niemeyer.net/blog http://niemeyer.net/twitter From afb at algonet.se Mon Sep 6 14:23:01 2010 From: afb at algonet.se (=?ISO-8859-1?Q?Anders_F_Bj=F6rklund?=) Date: Mon, 6 Sep 2010 23:23:01 +0200 Subject: A question about bundling smart with our distribution In-Reply-To: References: <64B3CA46-4BDB-4808-9D98-B88D9B1E9C3A@algonet.se> Message-ID: <57C8D19B-7495-451F-BDF9-A5BC67F12F31@algonet.se> Gustavo Niemeyer wrote: >> So as long as you contribute any changes you make to Smart... > > That's not entirely the case. If the code is a change in Smart, or is > using Smart as a library, it must be licensed as GPL too. That's the > very basis of the GPL license, so we can't simply dismiss it or the > license would have no value. Sorry, I was not being clear. I meant for the _specific_ issue of distributing Smart with a system a non-GPL-compatible libc library. For the code using Smart, the standard GPLv2+ rules would apply... But to me it is OK with running Smart (GPL) on a Sun libc (CDDL) OS. --anders From gustavo at niemeyer.net Mon Sep 6 14:31:08 2010 From: gustavo at niemeyer.net (Gustavo Niemeyer) Date: Mon, 6 Sep 2010 18:31:08 -0300 Subject: A question about bundling smart with our distribution In-Reply-To: <57C8D19B-7495-451F-BDF9-A5BC67F12F31@algonet.se> References: <64B3CA46-4BDB-4808-9D98-B88D9B1E9C3A@algonet.se> <57C8D19B-7495-451F-BDF9-A5BC67F12F31@algonet.se> Message-ID: Hey Anders, > Sorry, I was not being clear. I meant for the _specific_ issue of > distributing Smart with a system a non-GPL-compatible libc library. > > For the code using Smart, the standard GPLv2+ rules would apply... > But to me it is OK with running Smart (GPL) on a Sun libc (CDDL) OS. Absolutely. You can use Smart to manage software licensed with any license. -- Gustavo Niemeyer http://niemeyer.net http://niemeyer.net/blog http://niemeyer.net/twitter From sriram at belenix.org Mon Sep 6 20:37:42 2010 From: sriram at belenix.org (Sriram Narayanan) Date: Tue, 7 Sep 2010 09:07:42 +0530 Subject: A question about bundling smart with our distribution In-Reply-To: References: <64B3CA46-4BDB-4808-9D98-B88D9B1E9C3A@algonet.se> <57C8D19B-7495-451F-BDF9-A5BC67F12F31@algonet.se> Message-ID: Thanks everyone :) -- Sriram On 9/7/10, Gustavo Niemeyer wrote: > Hey Anders, > >> Sorry, I was not being clear. I meant for the _specific_ issue of >> distributing Smart with a system a non-GPL-compatible libc library. >> >> For the code using Smart, the standard GPLv2+ rules would apply... >> But to me it is OK with running Smart (GPL) on a Sun libc (CDDL) OS. > > Absolutely. You can use Smart to manage software licensed with any license. > > -- > Gustavo Niemeyer > http://niemeyer.net > http://niemeyer.net/blog > http://niemeyer.net/twitter > -- Sent from my mobile device Belenix: www.belenix.org From steve at kelem.net Thu Sep 9 11:34:07 2010 From: steve at kelem.net (Steve Kelem) Date: Thu, 09 Sep 2010 11:34:07 -0700 Subject: upgrade/downgrade loop Message-ID: <4C89289F.4060301@kelem.net> I have "smart" in one of my desktop panels. It lets me know when there are new upgrades available, but it is currently stuck in a loop. This morning it wanted to upgrade gnupg, and downgrade gnupg2: 2010/9/9 11:10 gnupg 1.4.10-2.fc13 at x86_64 Downgrades [x] gnupg2 2.0.14-2.fc13 at x86_64 gnupg2 2.0.14-6.fc13 at x86_64 Upgrades gnupg2 2.0.14-2.fc13 at x86_64 from download.fedoraproject.org/.../gnupg... Three minutes later, after the above action had completed, it wanted to downgrade gnupg and upgrade gnupg2: 2010/9/9 11:13 gnupg2 2.0.14-2.fc13 at x86_64 Downgrades [x] gnupg2 2.0.14-6.fc13 at x86_64 Upgrades [x] gnupg 1.4.10-2.fc13 at x86_64 1. Why is there this loop? 2. How do we fix it? 3. Is this the correct email list for this problem? 4. Should I file a bug? If so, where? Thanks for your help, Steve I'm running Fedora 13 on a dual x86_64 system (Dell Latitude E6500). From afb at algonet.se Thu Sep 9 14:28:55 2010 From: afb at algonet.se (=?ISO-8859-1?Q?Anders_F_Bj=F6rklund?=) Date: Thu, 9 Sep 2010 23:28:55 +0200 Subject: upgrade/downgrade loop In-Reply-To: <4C89289F.4060301@kelem.net> References: <4C89289F.4060301@kelem.net> Message-ID: <0281FD4A-32C7-45BA-8025-9AF67402B0E8@algonet.se> Steve Kelem wrote: > I have "smart" in one of my desktop panels. It lets me know when > there are new upgrades available, but it is currently stuck in a > loop. This morning it wanted to upgrade gnupg, and downgrade gnupg2: > 2010/9/9 11:10 > gnupg 1.4.10-2.fc13 at x86_64 > Downgrades > [x] gnupg2 2.0.14-2.fc13 at x86_64 > > gnupg2 2.0.14-6.fc13 at x86_64 > Upgrades > gnupg2 2.0.14-2.fc13 at x86_64 > > from download.fedoraproject.org/.../gnupg... > > Three minutes later, after the above action had completed, it > wanted to downgrade gnupg and upgrade gnupg2: > 2010/9/9 11:13 > gnupg2 2.0.14-2.fc13 at x86_64 > Downgrades > [x] gnupg2 2.0.14-6.fc13 at x86_64 > Upgrades > [x] gnupg 1.4.10-2.fc13 at x86_64 > > 1. Why is there this loop? Well presumably you have something else requiring "gpg"... The original package provides both: gpg = 2.0.14-2.fc13 gnupg2 = 2.0.14-2.fc13 Then it was split, for the update: gpg = 1.4.10-2.fc13 gnupg = 1.4.10-2.fc13 gnupg2 = 2.0.14-6.fc13 So in order to upgrade "gnupg2", "gnupg" must be installed. smart query --requires gpg > 2. How do we fix it? I think you should be able to break free of the loop by locking the version of "gnupg" to be "= 1.4.10-2.fc13" ? That way you will still get updates to gnupg2, but it won't upgrade gnupg just because of the "gpg" provides. smart flag --set lock 'gnupg = 1.4.10-2.fc13 at x86_64' > 3. Is this the correct email list for this problem? > 4. Should I file a bug? If so, where? > > Thanks for your help, > Steve > > I'm running Fedora 13 on a dual x86_64 system (Dell Latitude E6500). This seems like the correct list, maybe on Fedora too ? You can report bugs at https://bugs.launchpad.net/smart --anders From wormey at eskimo.com Wed Sep 1 23:00:33 2010 From: wormey at eskimo.com (Space Case) Date: Wed, 1 Sep 2010 23:00:33 -0700 Subject: New problem: menu bar disappeared In-Reply-To: <6DBFD1E6-D058-40D0-9E18-A8087503754C@algonet.se> Message-ID: <201009020600.XAA12043@eskimo.com> Hi. I'm still working my biarch problem, and finding some interesting things. I'll report on that later. Right now, I have another system, Fedora rawhide x86_64, Smart 1.3 that is being a problem. The menu bar has disappeared, and I don't know how I made it do that. Is there a way to make smart show me the menu bar? Thanks, Steve From afb at algonet.se Thu Sep 2 00:56:05 2010 From: afb at algonet.se (=?ISO-8859-1?Q?Anders_F_Bj=F6rklund?=) Date: Thu, 2 Sep 2010 09:56:05 +0200 Subject: New problem: menu bar disappeared In-Reply-To: <201009020600.XAA12043@eskimo.com> References: <201009020600.XAA12043@eskimo.com> Message-ID: Space Case wrote: > Right now, I have another system, Fedora rawhide x86_64, > Smart 1.3 that is being a problem. The menu bar has > disappeared, and I don't know how I made it do that. > > Is there a way to make smart show me the menu bar? There is not really a way of *hiding* the menu, so no way of showing it either. Sounds like a GTK+ bug. (like the earlier Glib 2.24 multi-threading bug...) Does `pygtk-demo` have any of the same problems ? If so: "Doctor, it hurts when I run rawhide" ;-) --anders From wormey at eskimo.com Thu Sep 2 20:32:30 2010 From: wormey at eskimo.com (Space Case) Date: Thu, 2 Sep 2010 20:32:30 -0700 Subject: New problem: menu bar disappeared In-Reply-To: Message-ID: <201009030332.UAA08469@eskimo.com> On Sep 2, 9:56am, =?ISO-8859-1?Q?Anders_F_Bj=F6rklund?= wrote: >There is not really a way of *hiding* the menu, so >no way of showing it either. Sounds like a GTK+ bug. >(like the earlier Glib 2.24 multi-threading bug...) > >Does `pygtk-demo` have any of the same problems ? > >If so: "Doctor, it hurts when I run rawhide" ;-) That's what it is. I can't get gnome-terminal to display a menu, either. Time for some updating, methinks. Thanks, Steve From wormey at eskimo.com Sat Sep 4 00:13:55 2010 From: wormey at eskimo.com (Space Case) Date: Sat, 4 Sep 2010 00:13:55 -0700 Subject: How to set a generic lock flag? In-Reply-To: <6DBFD1E6-D058-40D0-9E18-A8087503754C@algonet.se> Message-ID: <201009040713.AAA14593@eskimo.com> On Sep 1, 8:32am, =?ISO-8859-1?Q?Anders_F_Bj=F6rklund?= wrote: >So gnome-gnames is being suggested as part of >another install/upgrade ? (maybe use --explain) > >Something or other along the chain of dependencies >should be pulling those @i586 dependencies in, no ? OK, I have a couple of interesting cases. One is where there's a package conflict, it wants to install an i586 package. Remove the conflicting package, and the desire for i586 goes away. The second is where an upgraded package wants a noarch lang package. Attempt to upgrade the package, it wants to upgrade a total of 57 packages and install 6. Installing the lang package itself results in also upgrading the base package, and nothing else. I still have some i586 packages that want to install, if you want me to look at something else: python-qt4-4.7.3-3.11 at i586 mozilla-js192-1.9.2.8-3.1 at i586 python-sip-4.10.2-3.1 at i586 Thanks, Steve Selected bits of smart output: (I use ellipses (...) to denote removal of uninteresting text) smart> upgrade libwebkitgtk-devel Upgrading packages (2): libwebkitgtk-devel-1.3.3-2.2 at i586 Upgrades: libwebkit-devel-1.2.3-0.1.1 at x86_64 (upgraded) Conflicts: libwebkit-devel-1.2.3-0.1.1 at x86_64 (upgraded) libwebkitgtk-devel-1.3.3-2.2 at x86_64 Upgrades: libwebkitgtk-devel-1.3.3-2.1 at x86_64 (upgraded) libwebkit-devel-1.2.3-0.1.1 at x86_64 (upgraded) Conflicts: libwebkit-devel-1.2.3-0.1.1 at x86_64 (upgraded) smart> remove libwebkit-devel ... smart> upgrade libwebkitgtk-devel Upgrading packages (1): libwebkitgtk-devel-1.3.3-2.2 at x86_64 Upgrades: libwebkitgtk-devel-1.3.3-2.1 at x86_64 (upgraded) --------------------- gateway:~ # smart query --installed | grep gnome-desktop gnome-desktop-2.31.6-1.1 at x86_64 gnome-desktop-devel-2.31.6-1.1 at x86_64 libgnome-desktop-2-17-2.31.6-1.1 at x86_64 gateway:~ # smart --shell ... smart> upgrade gnome-desktop Upgrading packages (57): ... gnome-desktop-2.31.90-1.1 at x86_64 Upgrades: gnome-desktop-2.31.6-1.1 at x86_64 (upgraded) Requires: bundle-lang-gnome-en-11.3-15.1 at noarch (installed) Required By: nautilus-2.31.90-1.1 at x86_64 (installed) ... Installing packages (6): gnome-desktop-2.28.2-0.1.1 at i586 Requires: gnome-desktop-lang-2.28.2-0.1.1 at noarch (installed) Required By: nautilus-2.31.90-1.1 at x86_64 (installed) gnome-desktop-lang-2.28.2-0.1.1 at noarch (installed) gnome-desktop-lang-2.28.2-0.1.1 at noarch Requires: gnome-desktop-2.28.2-0.1.1 at i586 (installed) Required By: libgnome-desktop-2-11-2.28.2-0.1.1 at x86_64 (installed) gnome-desktop-2.28.2-0.1.1 at i586 (installed) ... Confirm changes? (Y/n): n smart> install gnome-desktop-lang Upgrading packages (1): gnome-desktop-2.31.90-1.1 at x86_64 Upgrades: gnome-desktop-2.31.6-1.1 at x86_64 (upgraded) Requires: gnome-desktop-lang-2.31.90-1.1 at noarch (installed) Required By: gnome-desktop-lang-2.31.90-1.1 at noarch (installed) Installing packages (1): gnome-desktop-lang-2.31.90-1.1 at noarch Requires: gnome-desktop-2.31.90-1.1 at x86_64 (installed) Required By: gnome-desktop-2.31.90-1.1 at x86_64 (installed) 863.8kB of package files are needed. 2.2MB will be used. Confirm changes? (Y/n): y smart> commit ... (download and install happens) ... smart> upgrade gnome-desktop No interesting upgrades available! From sriram at belenix.org Mon Sep 6 12:16:42 2010 From: sriram at belenix.org (Sriram Narayanan) Date: Tue, 7 Sep 2010 00:46:42 +0530 Subject: A question about bundling smart with our distribution Message-ID: Hello: I'm one of the team members of the Belenix Distro (www.belenix.org). We are presently using the SVR4 package format, and have wanted to move to a more modern day package format. We are very likely to use rpm5 as our package system :) We intend to bundle both yum and smart, and will leave it to our users as to which tool they'd like to use. Our question: Would you be OK with us using the smart given that most of the system libraries on our distro are CDDL licensed ? Thanks, Sriram -- Belenix: www.belenix.org From afb at algonet.se Mon Sep 6 13:00:34 2010 From: afb at algonet.se (=?ISO-8859-1?Q?Anders_F_Bj=F6rklund?=) Date: Mon, 6 Sep 2010 22:00:34 +0200 Subject: A question about bundling smart with our distribution In-Reply-To: References: Message-ID: <64B3CA46-4BDB-4808-9D98-B88D9B1E9C3A@algonet.se> Sriram Narayanan wrote: > I'm one of the team members of the Belenix Distro (www.belenix.org). > We are presently using the SVR4 package format, and have wanted to > move to a more modern day package format. The .pkg and .7z formats are available too, if you need them... It was added after discussion with other OpenSolaris community: https://code.launchpad.net/~afb/smart/pkg There was also a branch with some generic Solaris fixes, like broken file locking and such as discovered by OSUnix/StormOS: https://code.launchpad.net/~afb/smart/solaris But I guess neither project went ahead with Smart at the time, and Belenix was developing a custom package manager I think ? So we only added basic Nexenta support, with --ignore-locks. If you want to help test/support real Solaris support, great! > We are very likely to use rpm5 as our package system :) We intend to > bundle both yum and smart, and will leave it to our users as to which > tool they'd like to use. > > Our question: > Would you be OK with us using the smart given that most of the system > libraries on our distro are CDDL licensed ? I'm not sure what you are asking here. Smart is freely available under the GPLv2+ license. It works fine with rpm5 as the backend. Currently Smart 1.4 is under finalizing, but the Solaris support could be merged in for the next release (Smart 1.5) perhaps... ? --anders From sriram at belenix.org Mon Sep 6 13:29:15 2010 From: sriram at belenix.org (Sriram Narayanan) Date: Tue, 7 Sep 2010 01:59:15 +0530 Subject: A question about bundling smart with our distribution In-Reply-To: <64B3CA46-4BDB-4808-9D98-B88D9B1E9C3A@algonet.se> References: <64B3CA46-4BDB-4808-9D98-B88D9B1E9C3A@algonet.se> Message-ID: Hi: We're considering using rpm5 as our package system, with smart as the frontend. Moinak (CCd) had developed spkg as a stop gap arrangement till we figured out what to do next. We find IPS infeasible in low-bandwidth countries, and we wanted to move away from SVR4 to something that's more widely known. We have been apprehensive about package manager licensing ever since Debian Legal disliked how Nexenta modified and used dpkg (even though they wanted to conteibute back the source). Debian Legal's concerns were about Nexenta's dpkg linking with a non-GPL libc. There is once again a discussion thread about this on this month's Debian Legal mailing list. No one on the Belenix team is a lawyer, and we've all got day jobs where we do something else. So, we thought that the best thing to do is to simply ask on the smart mailing list whether you are OK with us building, linking and distributing smart code along with non-GPLd (yet opensource) libraries. -- Sriram On 9/7/10, Anders F Bj?rklund wrote: > Sriram Narayanan wrote: >> I'm one of the team members of the Belenix Distro (www.belenix.org). >> We are presently using the SVR4 package format, and have wanted to >> move to a more modern day package format. > > The .pkg and .7z formats are available too, if you need them... > It was added after discussion with other OpenSolaris community: > > https://code.launchpad.net/~afb/smart/pkg > > There was also a branch with some generic Solaris fixes, like > broken file locking and such as discovered by OSUnix/StormOS: > > https://code.launchpad.net/~afb/smart/solaris > > But I guess neither project went ahead with Smart at the time, > and Belenix was developing a custom package manager I think ? > > So we only added basic Nexenta support, with --ignore-locks. > If you want to help test/support real Solaris support, great! > >> We are very likely to use rpm5 as our package system :) We intend to >> bundle both yum and smart, and will leave it to our users as to which >> tool they'd like to use. >> >> Our question: >> Would you be OK with us using the smart given that most of the system >> libraries on our distro are CDDL licensed ? > > > I'm not sure what you are asking here. Smart is freely available > under the GPLv2+ license. It works fine with rpm5 as the backend. > > Currently Smart 1.4 is under finalizing, but the Solaris support > could be merged in for the next release (Smart 1.5) perhaps... ? > > --anders > > -- Sent from my mobile device Belenix: www.belenix.org From afb at algonet.se Mon Sep 6 13:44:35 2010 From: afb at algonet.se (=?ISO-8859-1?Q?Anders_F_Bj=F6rklund?=) Date: Mon, 6 Sep 2010 22:44:35 +0200 Subject: A question about bundling smart with our distribution In-Reply-To: References: <64B3CA46-4BDB-4808-9D98-B88D9B1E9C3A@algonet.se> Message-ID: Sriram Narayanan: > No one on the Belenix team is a lawyer, and we've all got day jobs > where we do something else. Me too. :-) But all the legalese should be in the LICENSE file (GPL). > So, we thought that the best thing to do is to simply ask on the smart > mailing list whether you are OK with us building, linking and > distributing smart code along with non-GPLd (yet opensource) > libraries. I'm fine with it myself, as I've used Smart on both Darwin and FreeBSD. Neither of which has GPL system libraries... Smart also runs on Mac OS X and Windows, which doesn't even have open source system libraries. Smart is still under GPL. And Python doesn't really "link" in the same way as C/C++ ? So as long as you contribute any changes you make to Smart... --anders From gustavo at niemeyer.net Mon Sep 6 14:13:18 2010 From: gustavo at niemeyer.net (Gustavo Niemeyer) Date: Mon, 6 Sep 2010 18:13:18 -0300 Subject: A question about bundling smart with our distribution In-Reply-To: References: <64B3CA46-4BDB-4808-9D98-B88D9B1E9C3A@algonet.se> Message-ID: Hey there, > So as long as you contribute any changes you make to Smart... That's not entirely the case. If the code is a change in Smart, or is using Smart as a library, it must be licensed as GPL too. That's the very basis of the GPL license, so we can't simply dismiss it or the license would have no value. -- Gustavo Niemeyer http://niemeyer.net http://niemeyer.net/blog http://niemeyer.net/twitter From afb at algonet.se Mon Sep 6 14:23:01 2010 From: afb at algonet.se (=?ISO-8859-1?Q?Anders_F_Bj=F6rklund?=) Date: Mon, 6 Sep 2010 23:23:01 +0200 Subject: A question about bundling smart with our distribution In-Reply-To: References: <64B3CA46-4BDB-4808-9D98-B88D9B1E9C3A@algonet.se> Message-ID: <57C8D19B-7495-451F-BDF9-A5BC67F12F31@algonet.se> Gustavo Niemeyer wrote: >> So as long as you contribute any changes you make to Smart... > > That's not entirely the case. If the code is a change in Smart, or is > using Smart as a library, it must be licensed as GPL too. That's the > very basis of the GPL license, so we can't simply dismiss it or the > license would have no value. Sorry, I was not being clear. I meant for the _specific_ issue of distributing Smart with a system a non-GPL-compatible libc library. For the code using Smart, the standard GPLv2+ rules would apply... But to me it is OK with running Smart (GPL) on a Sun libc (CDDL) OS. --anders From gustavo at niemeyer.net Mon Sep 6 14:31:08 2010 From: gustavo at niemeyer.net (Gustavo Niemeyer) Date: Mon, 6 Sep 2010 18:31:08 -0300 Subject: A question about bundling smart with our distribution In-Reply-To: <57C8D19B-7495-451F-BDF9-A5BC67F12F31@algonet.se> References: <64B3CA46-4BDB-4808-9D98-B88D9B1E9C3A@algonet.se> <57C8D19B-7495-451F-BDF9-A5BC67F12F31@algonet.se> Message-ID: Hey Anders, > Sorry, I was not being clear. I meant for the _specific_ issue of > distributing Smart with a system a non-GPL-compatible libc library. > > For the code using Smart, the standard GPLv2+ rules would apply... > But to me it is OK with running Smart (GPL) on a Sun libc (CDDL) OS. Absolutely. You can use Smart to manage software licensed with any license. -- Gustavo Niemeyer http://niemeyer.net http://niemeyer.net/blog http://niemeyer.net/twitter From sriram at belenix.org Mon Sep 6 20:37:42 2010 From: sriram at belenix.org (Sriram Narayanan) Date: Tue, 7 Sep 2010 09:07:42 +0530 Subject: A question about bundling smart with our distribution In-Reply-To: References: <64B3CA46-4BDB-4808-9D98-B88D9B1E9C3A@algonet.se> <57C8D19B-7495-451F-BDF9-A5BC67F12F31@algonet.se> Message-ID: Thanks everyone :) -- Sriram On 9/7/10, Gustavo Niemeyer wrote: > Hey Anders, > >> Sorry, I was not being clear. I meant for the _specific_ issue of >> distributing Smart with a system a non-GPL-compatible libc library. >> >> For the code using Smart, the standard GPLv2+ rules would apply... >> But to me it is OK with running Smart (GPL) on a Sun libc (CDDL) OS. > > Absolutely. You can use Smart to manage software licensed with any license. > > -- > Gustavo Niemeyer > http://niemeyer.net > http://niemeyer.net/blog > http://niemeyer.net/twitter > -- Sent from my mobile device Belenix: www.belenix.org From steve at kelem.net Thu Sep 9 11:34:07 2010 From: steve at kelem.net (Steve Kelem) Date: Thu, 09 Sep 2010 11:34:07 -0700 Subject: upgrade/downgrade loop Message-ID: <4C89289F.4060301@kelem.net> I have "smart" in one of my desktop panels. It lets me know when there are new upgrades available, but it is currently stuck in a loop. This morning it wanted to upgrade gnupg, and downgrade gnupg2: 2010/9/9 11:10 gnupg 1.4.10-2.fc13 at x86_64 Downgrades [x] gnupg2 2.0.14-2.fc13 at x86_64 gnupg2 2.0.14-6.fc13 at x86_64 Upgrades gnupg2 2.0.14-2.fc13 at x86_64 from download.fedoraproject.org/.../gnupg... Three minutes later, after the above action had completed, it wanted to downgrade gnupg and upgrade gnupg2: 2010/9/9 11:13 gnupg2 2.0.14-2.fc13 at x86_64 Downgrades [x] gnupg2 2.0.14-6.fc13 at x86_64 Upgrades [x] gnupg 1.4.10-2.fc13 at x86_64 1. Why is there this loop? 2. How do we fix it? 3. Is this the correct email list for this problem? 4. Should I file a bug? If so, where? Thanks for your help, Steve I'm running Fedora 13 on a dual x86_64 system (Dell Latitude E6500). From afb at algonet.se Thu Sep 9 14:28:55 2010 From: afb at algonet.se (=?ISO-8859-1?Q?Anders_F_Bj=F6rklund?=) Date: Thu, 9 Sep 2010 23:28:55 +0200 Subject: upgrade/downgrade loop In-Reply-To: <4C89289F.4060301@kelem.net> References: <4C89289F.4060301@kelem.net> Message-ID: <0281FD4A-32C7-45BA-8025-9AF67402B0E8@algonet.se> Steve Kelem wrote: > I have "smart" in one of my desktop panels. It lets me know when > there are new upgrades available, but it is currently stuck in a > loop. This morning it wanted to upgrade gnupg, and downgrade gnupg2: > 2010/9/9 11:10 > gnupg 1.4.10-2.fc13 at x86_64 > Downgrades > [x] gnupg2 2.0.14-2.fc13 at x86_64 > > gnupg2 2.0.14-6.fc13 at x86_64 > Upgrades > gnupg2 2.0.14-2.fc13 at x86_64 > > from download.fedoraproject.org/.../gnupg... > > Three minutes later, after the above action had completed, it > wanted to downgrade gnupg and upgrade gnupg2: > 2010/9/9 11:13 > gnupg2 2.0.14-2.fc13 at x86_64 > Downgrades > [x] gnupg2 2.0.14-6.fc13 at x86_64 > Upgrades > [x] gnupg 1.4.10-2.fc13 at x86_64 > > 1. Why is there this loop? Well presumably you have something else requiring "gpg"... The original package provides both: gpg = 2.0.14-2.fc13 gnupg2 = 2.0.14-2.fc13 Then it was split, for the update: gpg = 1.4.10-2.fc13 gnupg = 1.4.10-2.fc13 gnupg2 = 2.0.14-6.fc13 So in order to upgrade "gnupg2", "gnupg" must be installed. smart query --requires gpg > 2. How do we fix it? I think you should be able to break free of the loop by locking the version of "gnupg" to be "= 1.4.10-2.fc13" ? That way you will still get updates to gnupg2, but it won't upgrade gnupg just because of the "gpg" provides. smart flag --set lock 'gnupg = 1.4.10-2.fc13 at x86_64' > 3. Is this the correct email list for this problem? > 4. Should I file a bug? If so, where? > > Thanks for your help, > Steve > > I'm running Fedora 13 on a dual x86_64 system (Dell Latitude E6500). This seems like the correct list, maybe on Fedora too ? You can report bugs at https://bugs.launchpad.net/smart --anders From wormey at eskimo.com Wed Sep 1 23:00:33 2010 From: wormey at eskimo.com (Space Case) Date: Wed, 1 Sep 2010 23:00:33 -0700 Subject: New problem: menu bar disappeared In-Reply-To: <6DBFD1E6-D058-40D0-9E18-A8087503754C@algonet.se> Message-ID: <201009020600.XAA12043@eskimo.com> Hi. I'm still working my biarch problem, and finding some interesting things. I'll report on that later. Right now, I have another system, Fedora rawhide x86_64, Smart 1.3 that is being a problem. The menu bar has disappeared, and I don't know how I made it do that. Is there a way to make smart show me the menu bar? Thanks, Steve From afb at algonet.se Thu Sep 2 00:56:05 2010 From: afb at algonet.se (=?ISO-8859-1?Q?Anders_F_Bj=F6rklund?=) Date: Thu, 2 Sep 2010 09:56:05 +0200 Subject: New problem: menu bar disappeared In-Reply-To: <201009020600.XAA12043@eskimo.com> References: <201009020600.XAA12043@eskimo.com> Message-ID: Space Case wrote: > Right now, I have another system, Fedora rawhide x86_64, > Smart 1.3 that is being a problem. The menu bar has > disappeared, and I don't know how I made it do that. > > Is there a way to make smart show me the menu bar? There is not really a way of *hiding* the menu, so no way of showing it either. Sounds like a GTK+ bug. (like the earlier Glib 2.24 multi-threading bug...) Does `pygtk-demo` have any of the same problems ? If so: "Doctor, it hurts when I run rawhide" ;-) --anders From wormey at eskimo.com Thu Sep 2 20:32:30 2010 From: wormey at eskimo.com (Space Case) Date: Thu, 2 Sep 2010 20:32:30 -0700 Subject: New problem: menu bar disappeared In-Reply-To: Message-ID: <201009030332.UAA08469@eskimo.com> On Sep 2, 9:56am, =?ISO-8859-1?Q?Anders_F_Bj=F6rklund?= wrote: >There is not really a way of *hiding* the menu, so >no way of showing it either. Sounds like a GTK+ bug. >(like the earlier Glib 2.24 multi-threading bug...) > >Does `pygtk-demo` have any of the same problems ? > >If so: "Doctor, it hurts when I run rawhide" ;-) That's what it is. I can't get gnome-terminal to display a menu, either. Time for some updating, methinks. Thanks, Steve From wormey at eskimo.com Sat Sep 4 00:13:55 2010 From: wormey at eskimo.com (Space Case) Date: Sat, 4 Sep 2010 00:13:55 -0700 Subject: How to set a generic lock flag? In-Reply-To: <6DBFD1E6-D058-40D0-9E18-A8087503754C@algonet.se> Message-ID: <201009040713.AAA14593@eskimo.com> On Sep 1, 8:32am, =?ISO-8859-1?Q?Anders_F_Bj=F6rklund?= wrote: >So gnome-gnames is being suggested as part of >another install/upgrade ? (maybe use --explain) > >Something or other along the chain of dependencies >should be pulling those @i586 dependencies in, no ? OK, I have a couple of interesting cases. One is where there's a package conflict, it wants to install an i586 package. Remove the conflicting package, and the desire for i586 goes away. The second is where an upgraded package wants a noarch lang package. Attempt to upgrade the package, it wants to upgrade a total of 57 packages and install 6. Installing the lang package itself results in also upgrading the base package, and nothing else. I still have some i586 packages that want to install, if you want me to look at something else: python-qt4-4.7.3-3.11 at i586 mozilla-js192-1.9.2.8-3.1 at i586 python-sip-4.10.2-3.1 at i586 Thanks, Steve Selected bits of smart output: (I use ellipses (...) to denote removal of uninteresting text) smart> upgrade libwebkitgtk-devel Upgrading packages (2): libwebkitgtk-devel-1.3.3-2.2 at i586 Upgrades: libwebkit-devel-1.2.3-0.1.1 at x86_64 (upgraded) Conflicts: libwebkit-devel-1.2.3-0.1.1 at x86_64 (upgraded) libwebkitgtk-devel-1.3.3-2.2 at x86_64 Upgrades: libwebkitgtk-devel-1.3.3-2.1 at x86_64 (upgraded) libwebkit-devel-1.2.3-0.1.1 at x86_64 (upgraded) Conflicts: libwebkit-devel-1.2.3-0.1.1 at x86_64 (upgraded) smart> remove libwebkit-devel ... smart> upgrade libwebkitgtk-devel Upgrading packages (1): libwebkitgtk-devel-1.3.3-2.2 at x86_64 Upgrades: libwebkitgtk-devel-1.3.3-2.1 at x86_64 (upgraded) --------------------- gateway:~ # smart query --installed | grep gnome-desktop gnome-desktop-2.31.6-1.1 at x86_64 gnome-desktop-devel-2.31.6-1.1 at x86_64 libgnome-desktop-2-17-2.31.6-1.1 at x86_64 gateway:~ # smart --shell ... smart> upgrade gnome-desktop Upgrading packages (57): ... gnome-desktop-2.31.90-1.1 at x86_64 Upgrades: gnome-desktop-2.31.6-1.1 at x86_64 (upgraded) Requires: bundle-lang-gnome-en-11.3-15.1 at noarch (installed) Required By: nautilus-2.31.90-1.1 at x86_64 (installed) ... Installing packages (6): gnome-desktop-2.28.2-0.1.1 at i586 Requires: gnome-desktop-lang-2.28.2-0.1.1 at noarch (installed) Required By: nautilus-2.31.90-1.1 at x86_64 (installed) gnome-desktop-lang-2.28.2-0.1.1 at noarch (installed) gnome-desktop-lang-2.28.2-0.1.1 at noarch Requires: gnome-desktop-2.28.2-0.1.1 at i586 (installed) Required By: libgnome-desktop-2-11-2.28.2-0.1.1 at x86_64 (installed) gnome-desktop-2.28.2-0.1.1 at i586 (installed) ... Confirm changes? (Y/n): n smart> install gnome-desktop-lang Upgrading packages (1): gnome-desktop-2.31.90-1.1 at x86_64 Upgrades: gnome-desktop-2.31.6-1.1 at x86_64 (upgraded) Requires: gnome-desktop-lang-2.31.90-1.1 at noarch (installed) Required By: gnome-desktop-lang-2.31.90-1.1 at noarch (installed) Installing packages (1): gnome-desktop-lang-2.31.90-1.1 at noarch Requires: gnome-desktop-2.31.90-1.1 at x86_64 (installed) Required By: gnome-desktop-2.31.90-1.1 at x86_64 (installed) 863.8kB of package files are needed. 2.2MB will be used. Confirm changes? (Y/n): y smart> commit ... (download and install happens) ... smart> upgrade gnome-desktop No interesting upgrades available! From sriram at belenix.org Mon Sep 6 12:16:42 2010 From: sriram at belenix.org (Sriram Narayanan) Date: Tue, 7 Sep 2010 00:46:42 +0530 Subject: A question about bundling smart with our distribution Message-ID: Hello: I'm one of the team members of the Belenix Distro (www.belenix.org). We are presently using the SVR4 package format, and have wanted to move to a more modern day package format. We are very likely to use rpm5 as our package system :) We intend to bundle both yum and smart, and will leave it to our users as to which tool they'd like to use. Our question: Would you be OK with us using the smart given that most of the system libraries on our distro are CDDL licensed ? Thanks, Sriram -- Belenix: www.belenix.org From afb at algonet.se Mon Sep 6 13:00:34 2010 From: afb at algonet.se (=?ISO-8859-1?Q?Anders_F_Bj=F6rklund?=) Date: Mon, 6 Sep 2010 22:00:34 +0200 Subject: A question about bundling smart with our distribution In-Reply-To: References: Message-ID: <64B3CA46-4BDB-4808-9D98-B88D9B1E9C3A@algonet.se> Sriram Narayanan wrote: > I'm one of the team members of the Belenix Distro (www.belenix.org). > We are presently using the SVR4 package format, and have wanted to > move to a more modern day package format. The .pkg and .7z formats are available too, if you need them... It was added after discussion with other OpenSolaris community: https://code.launchpad.net/~afb/smart/pkg There was also a branch with some generic Solaris fixes, like broken file locking and such as discovered by OSUnix/StormOS: https://code.launchpad.net/~afb/smart/solaris But I guess neither project went ahead with Smart at the time, and Belenix was developing a custom package manager I think ? So we only added basic Nexenta support, with --ignore-locks. If you want to help test/support real Solaris support, great! > We are very likely to use rpm5 as our package system :) We intend to > bundle both yum and smart, and will leave it to our users as to which > tool they'd like to use. > > Our question: > Would you be OK with us using the smart given that most of the system > libraries on our distro are CDDL licensed ? I'm not sure what you are asking here. Smart is freely available under the GPLv2+ license. It works fine with rpm5 as the backend. Currently Smart 1.4 is under finalizing, but the Solaris support could be merged in for the next release (Smart 1.5) perhaps... ? --anders From sriram at belenix.org Mon Sep 6 13:29:15 2010 From: sriram at belenix.org (Sriram Narayanan) Date: Tue, 7 Sep 2010 01:59:15 +0530 Subject: A question about bundling smart with our distribution In-Reply-To: <64B3CA46-4BDB-4808-9D98-B88D9B1E9C3A@algonet.se> References: <64B3CA46-4BDB-4808-9D98-B88D9B1E9C3A@algonet.se> Message-ID: Hi: We're considering using rpm5 as our package system, with smart as the frontend. Moinak (CCd) had developed spkg as a stop gap arrangement till we figured out what to do next. We find IPS infeasible in low-bandwidth countries, and we wanted to move away from SVR4 to something that's more widely known. We have been apprehensive about package manager licensing ever since Debian Legal disliked how Nexenta modified and used dpkg (even though they wanted to conteibute back the source). Debian Legal's concerns were about Nexenta's dpkg linking with a non-GPL libc. There is once again a discussion thread about this on this month's Debian Legal mailing list. No one on the Belenix team is a lawyer, and we've all got day jobs where we do something else. So, we thought that the best thing to do is to simply ask on the smart mailing list whether you are OK with us building, linking and distributing smart code along with non-GPLd (yet opensource) libraries. -- Sriram On 9/7/10, Anders F Bj?rklund wrote: > Sriram Narayanan wrote: >> I'm one of the team members of the Belenix Distro (www.belenix.org). >> We are presently using the SVR4 package format, and have wanted to >> move to a more modern day package format. > > The .pkg and .7z formats are available too, if you need them... > It was added after discussion with other OpenSolaris community: > > https://code.launchpad.net/~afb/smart/pkg > > There was also a branch with some generic Solaris fixes, like > broken file locking and such as discovered by OSUnix/StormOS: > > https://code.launchpad.net/~afb/smart/solaris > > But I guess neither project went ahead with Smart at the time, > and Belenix was developing a custom package manager I think ? > > So we only added basic Nexenta support, with --ignore-locks. > If you want to help test/support real Solaris support, great! > >> We are very likely to use rpm5 as our package system :) We intend to >> bundle both yum and smart, and will leave it to our users as to which >> tool they'd like to use. >> >> Our question: >> Would you be OK with us using the smart given that most of the system >> libraries on our distro are CDDL licensed ? > > > I'm not sure what you are asking here. Smart is freely available > under the GPLv2+ license. It works fine with rpm5 as the backend. > > Currently Smart 1.4 is under finalizing, but the Solaris support > could be merged in for the next release (Smart 1.5) perhaps... ? > > --anders > > -- Sent from my mobile device Belenix: www.belenix.org From afb at algonet.se Mon Sep 6 13:44:35 2010 From: afb at algonet.se (=?ISO-8859-1?Q?Anders_F_Bj=F6rklund?=) Date: Mon, 6 Sep 2010 22:44:35 +0200 Subject: A question about bundling smart with our distribution In-Reply-To: References: <64B3CA46-4BDB-4808-9D98-B88D9B1E9C3A@algonet.se> Message-ID: Sriram Narayanan: > No one on the Belenix team is a lawyer, and we've all got day jobs > where we do something else. Me too. :-) But all the legalese should be in the LICENSE file (GPL). > So, we thought that the best thing to do is to simply ask on the smart > mailing list whether you are OK with us building, linking and > distributing smart code along with non-GPLd (yet opensource) > libraries. I'm fine with it myself, as I've used Smart on both Darwin and FreeBSD. Neither of which has GPL system libraries... Smart also runs on Mac OS X and Windows, which doesn't even have open source system libraries. Smart is still under GPL. And Python doesn't really "link" in the same way as C/C++ ? So as long as you contribute any changes you make to Smart... --anders From gustavo at niemeyer.net Mon Sep 6 14:13:18 2010 From: gustavo at niemeyer.net (Gustavo Niemeyer) Date: Mon, 6 Sep 2010 18:13:18 -0300 Subject: A question about bundling smart with our distribution In-Reply-To: References: <64B3CA46-4BDB-4808-9D98-B88D9B1E9C3A@algonet.se> Message-ID: Hey there, > So as long as you contribute any changes you make to Smart... That's not entirely the case. If the code is a change in Smart, or is using Smart as a library, it must be licensed as GPL too. That's the very basis of the GPL license, so we can't simply dismiss it or the license would have no value. -- Gustavo Niemeyer http://niemeyer.net http://niemeyer.net/blog http://niemeyer.net/twitter From afb at algonet.se Mon Sep 6 14:23:01 2010 From: afb at algonet.se (=?ISO-8859-1?Q?Anders_F_Bj=F6rklund?=) Date: Mon, 6 Sep 2010 23:23:01 +0200 Subject: A question about bundling smart with our distribution In-Reply-To: References: <64B3CA46-4BDB-4808-9D98-B88D9B1E9C3A@algonet.se> Message-ID: <57C8D19B-7495-451F-BDF9-A5BC67F12F31@algonet.se> Gustavo Niemeyer wrote: >> So as long as you contribute any changes you make to Smart... > > That's not entirely the case. If the code is a change in Smart, or is > using Smart as a library, it must be licensed as GPL too. That's the > very basis of the GPL license, so we can't simply dismiss it or the > license would have no value. Sorry, I was not being clear. I meant for the _specific_ issue of distributing Smart with a system a non-GPL-compatible libc library. For the code using Smart, the standard GPLv2+ rules would apply... But to me it is OK with running Smart (GPL) on a Sun libc (CDDL) OS. --anders From gustavo at niemeyer.net Mon Sep 6 14:31:08 2010 From: gustavo at niemeyer.net (Gustavo Niemeyer) Date: Mon, 6 Sep 2010 18:31:08 -0300 Subject: A question about bundling smart with our distribution In-Reply-To: <57C8D19B-7495-451F-BDF9-A5BC67F12F31@algonet.se> References: <64B3CA46-4BDB-4808-9D98-B88D9B1E9C3A@algonet.se> <57C8D19B-7495-451F-BDF9-A5BC67F12F31@algonet.se> Message-ID: Hey Anders, > Sorry, I was not being clear. I meant for the _specific_ issue of > distributing Smart with a system a non-GPL-compatible libc library. > > For the code using Smart, the standard GPLv2+ rules would apply... > But to me it is OK with running Smart (GPL) on a Sun libc (CDDL) OS. Absolutely. You can use Smart to manage software licensed with any license. -- Gustavo Niemeyer http://niemeyer.net http://niemeyer.net/blog http://niemeyer.net/twitter From sriram at belenix.org Mon Sep 6 20:37:42 2010 From: sriram at belenix.org (Sriram Narayanan) Date: Tue, 7 Sep 2010 09:07:42 +0530 Subject: A question about bundling smart with our distribution In-Reply-To: References: <64B3CA46-4BDB-4808-9D98-B88D9B1E9C3A@algonet.se> <57C8D19B-7495-451F-BDF9-A5BC67F12F31@algonet.se> Message-ID: Thanks everyone :) -- Sriram On 9/7/10, Gustavo Niemeyer wrote: > Hey Anders, > >> Sorry, I was not being clear. I meant for the _specific_ issue of >> distributing Smart with a system a non-GPL-compatible libc library. >> >> For the code using Smart, the standard GPLv2+ rules would apply... >> But to me it is OK with running Smart (GPL) on a Sun libc (CDDL) OS. > > Absolutely. You can use Smart to manage software licensed with any license. > > -- > Gustavo Niemeyer > http://niemeyer.net > http://niemeyer.net/blog > http://niemeyer.net/twitter > -- Sent from my mobile device Belenix: www.belenix.org From steve at kelem.net Thu Sep 9 11:34:07 2010 From: steve at kelem.net (Steve Kelem) Date: Thu, 09 Sep 2010 11:34:07 -0700 Subject: upgrade/downgrade loop Message-ID: <4C89289F.4060301@kelem.net> I have "smart" in one of my desktop panels. It lets me know when there are new upgrades available, but it is currently stuck in a loop. This morning it wanted to upgrade gnupg, and downgrade gnupg2: 2010/9/9 11:10 gnupg 1.4.10-2.fc13 at x86_64 Downgrades [x] gnupg2 2.0.14-2.fc13 at x86_64 gnupg2 2.0.14-6.fc13 at x86_64 Upgrades gnupg2 2.0.14-2.fc13 at x86_64 from download.fedoraproject.org/.../gnupg... Three minutes later, after the above action had completed, it wanted to downgrade gnupg and upgrade gnupg2: 2010/9/9 11:13 gnupg2 2.0.14-2.fc13 at x86_64 Downgrades [x] gnupg2 2.0.14-6.fc13 at x86_64 Upgrades [x] gnupg 1.4.10-2.fc13 at x86_64 1. Why is there this loop? 2. How do we fix it? 3. Is this the correct email list for this problem? 4. Should I file a bug? If so, where? Thanks for your help, Steve I'm running Fedora 13 on a dual x86_64 system (Dell Latitude E6500). From afb at algonet.se Thu Sep 9 14:28:55 2010 From: afb at algonet.se (=?ISO-8859-1?Q?Anders_F_Bj=F6rklund?=) Date: Thu, 9 Sep 2010 23:28:55 +0200 Subject: upgrade/downgrade loop In-Reply-To: <4C89289F.4060301@kelem.net> References: <4C89289F.4060301@kelem.net> Message-ID: <0281FD4A-32C7-45BA-8025-9AF67402B0E8@algonet.se> Steve Kelem wrote: > I have "smart" in one of my desktop panels. It lets me know when > there are new upgrades available, but it is currently stuck in a > loop. This morning it wanted to upgrade gnupg, and downgrade gnupg2: > 2010/9/9 11:10 > gnupg 1.4.10-2.fc13 at x86_64 > Downgrades > [x] gnupg2 2.0.14-2.fc13 at x86_64 > > gnupg2 2.0.14-6.fc13 at x86_64 > Upgrades > gnupg2 2.0.14-2.fc13 at x86_64 > > from download.fedoraproject.org/.../gnupg... > > Three minutes later, after the above action had completed, it > wanted to downgrade gnupg and upgrade gnupg2: > 2010/9/9 11:13 > gnupg2 2.0.14-2.fc13 at x86_64 > Downgrades > [x] gnupg2 2.0.14-6.fc13 at x86_64 > Upgrades > [x] gnupg 1.4.10-2.fc13 at x86_64 > > 1. Why is there this loop? Well presumably you have something else requiring "gpg"... The original package provides both: gpg = 2.0.14-2.fc13 gnupg2 = 2.0.14-2.fc13 Then it was split, for the update: gpg = 1.4.10-2.fc13 gnupg = 1.4.10-2.fc13 gnupg2 = 2.0.14-6.fc13 So in order to upgrade "gnupg2", "gnupg" must be installed. smart query --requires gpg > 2. How do we fix it? I think you should be able to break free of the loop by locking the version of "gnupg" to be "= 1.4.10-2.fc13" ? That way you will still get updates to gnupg2, but it won't upgrade gnupg just because of the "gpg" provides. smart flag --set lock 'gnupg = 1.4.10-2.fc13 at x86_64' > 3. Is this the correct email list for this problem? > 4. Should I file a bug? If so, where? > > Thanks for your help, > Steve > > I'm running Fedora 13 on a dual x86_64 system (Dell Latitude E6500). This seems like the correct list, maybe on Fedora too ? You can report bugs at https://bugs.launchpad.net/smart --anders From wormey at eskimo.com Wed Sep 1 23:00:33 2010 From: wormey at eskimo.com (Space Case) Date: Wed, 1 Sep 2010 23:00:33 -0700 Subject: New problem: menu bar disappeared In-Reply-To: <6DBFD1E6-D058-40D0-9E18-A8087503754C@algonet.se> Message-ID: <201009020600.XAA12043@eskimo.com> Hi. I'm still working my biarch problem, and finding some interesting things. I'll report on that later. Right now, I have another system, Fedora rawhide x86_64, Smart 1.3 that is being a problem. The menu bar has disappeared, and I don't know how I made it do that. Is there a way to make smart show me the menu bar? Thanks, Steve From afb at algonet.se Thu Sep 2 00:56:05 2010 From: afb at algonet.se (=?ISO-8859-1?Q?Anders_F_Bj=F6rklund?=) Date: Thu, 2 Sep 2010 09:56:05 +0200 Subject: New problem: menu bar disappeared In-Reply-To: <201009020600.XAA12043@eskimo.com> References: <201009020600.XAA12043@eskimo.com> Message-ID: Space Case wrote: > Right now, I have another system, Fedora rawhide x86_64, > Smart 1.3 that is being a problem. The menu bar has > disappeared, and I don't know how I made it do that. > > Is there a way to make smart show me the menu bar? There is not really a way of *hiding* the menu, so no way of showing it either. Sounds like a GTK+ bug. (like the earlier Glib 2.24 multi-threading bug...) Does `pygtk-demo` have any of the same problems ? If so: "Doctor, it hurts when I run rawhide" ;-) --anders From wormey at eskimo.com Thu Sep 2 20:32:30 2010 From: wormey at eskimo.com (Space Case) Date: Thu, 2 Sep 2010 20:32:30 -0700 Subject: New problem: menu bar disappeared In-Reply-To: Message-ID: <201009030332.UAA08469@eskimo.com> On Sep 2, 9:56am, =?ISO-8859-1?Q?Anders_F_Bj=F6rklund?= wrote: >There is not really a way of *hiding* the menu, so >no way of showing it either. Sounds like a GTK+ bug. >(like the earlier Glib 2.24 multi-threading bug...) > >Does `pygtk-demo` have any of the same problems ? > >If so: "Doctor, it hurts when I run rawhide" ;-) That's what it is. I can't get gnome-terminal to display a menu, either. Time for some updating, methinks. Thanks, Steve From wormey at eskimo.com Sat Sep 4 00:13:55 2010 From: wormey at eskimo.com (Space Case) Date: Sat, 4 Sep 2010 00:13:55 -0700 Subject: How to set a generic lock flag? In-Reply-To: <6DBFD1E6-D058-40D0-9E18-A8087503754C@algonet.se> Message-ID: <201009040713.AAA14593@eskimo.com> On Sep 1, 8:32am, =?ISO-8859-1?Q?Anders_F_Bj=F6rklund?= wrote: >So gnome-gnames is being suggested as part of >another install/upgrade ? (maybe use --explain) > >Something or other along the chain of dependencies >should be pulling those @i586 dependencies in, no ? OK, I have a couple of interesting cases. One is where there's a package conflict, it wants to install an i586 package. Remove the conflicting package, and the desire for i586 goes away. The second is where an upgraded package wants a noarch lang package. Attempt to upgrade the package, it wants to upgrade a total of 57 packages and install 6. Installing the lang package itself results in also upgrading the base package, and nothing else. I still have some i586 packages that want to install, if you want me to look at something else: python-qt4-4.7.3-3.11 at i586 mozilla-js192-1.9.2.8-3.1 at i586 python-sip-4.10.2-3.1 at i586 Thanks, Steve Selected bits of smart output: (I use ellipses (...) to denote removal of uninteresting text) smart> upgrade libwebkitgtk-devel Upgrading packages (2): libwebkitgtk-devel-1.3.3-2.2 at i586 Upgrades: libwebkit-devel-1.2.3-0.1.1 at x86_64 (upgraded) Conflicts: libwebkit-devel-1.2.3-0.1.1 at x86_64 (upgraded) libwebkitgtk-devel-1.3.3-2.2 at x86_64 Upgrades: libwebkitgtk-devel-1.3.3-2.1 at x86_64 (upgraded) libwebkit-devel-1.2.3-0.1.1 at x86_64 (upgraded) Conflicts: libwebkit-devel-1.2.3-0.1.1 at x86_64 (upgraded) smart> remove libwebkit-devel ... smart> upgrade libwebkitgtk-devel Upgrading packages (1): libwebkitgtk-devel-1.3.3-2.2 at x86_64 Upgrades: libwebkitgtk-devel-1.3.3-2.1 at x86_64 (upgraded) --------------------- gateway:~ # smart query --installed | grep gnome-desktop gnome-desktop-2.31.6-1.1 at x86_64 gnome-desktop-devel-2.31.6-1.1 at x86_64 libgnome-desktop-2-17-2.31.6-1.1 at x86_64 gateway:~ # smart --shell ... smart> upgrade gnome-desktop Upgrading packages (57): ... gnome-desktop-2.31.90-1.1 at x86_64 Upgrades: gnome-desktop-2.31.6-1.1 at x86_64 (upgraded) Requires: bundle-lang-gnome-en-11.3-15.1 at noarch (installed) Required By: nautilus-2.31.90-1.1 at x86_64 (installed) ... Installing packages (6): gnome-desktop-2.28.2-0.1.1 at i586 Requires: gnome-desktop-lang-2.28.2-0.1.1 at noarch (installed) Required By: nautilus-2.31.90-1.1 at x86_64 (installed) gnome-desktop-lang-2.28.2-0.1.1 at noarch (installed) gnome-desktop-lang-2.28.2-0.1.1 at noarch Requires: gnome-desktop-2.28.2-0.1.1 at i586 (installed) Required By: libgnome-desktop-2-11-2.28.2-0.1.1 at x86_64 (installed) gnome-desktop-2.28.2-0.1.1 at i586 (installed) ... Confirm changes? (Y/n): n smart> install gnome-desktop-lang Upgrading packages (1): gnome-desktop-2.31.90-1.1 at x86_64 Upgrades: gnome-desktop-2.31.6-1.1 at x86_64 (upgraded) Requires: gnome-desktop-lang-2.31.90-1.1 at noarch (installed) Required By: gnome-desktop-lang-2.31.90-1.1 at noarch (installed) Installing packages (1): gnome-desktop-lang-2.31.90-1.1 at noarch Requires: gnome-desktop-2.31.90-1.1 at x86_64 (installed) Required By: gnome-desktop-2.31.90-1.1 at x86_64 (installed) 863.8kB of package files are needed. 2.2MB will be used. Confirm changes? (Y/n): y smart> commit ... (download and install happens) ... smart> upgrade gnome-desktop No interesting upgrades available! From sriram at belenix.org Mon Sep 6 12:16:42 2010 From: sriram at belenix.org (Sriram Narayanan) Date: Tue, 7 Sep 2010 00:46:42 +0530 Subject: A question about bundling smart with our distribution Message-ID: Hello: I'm one of the team members of the Belenix Distro (www.belenix.org). We are presently using the SVR4 package format, and have wanted to move to a more modern day package format. We are very likely to use rpm5 as our package system :) We intend to bundle both yum and smart, and will leave it to our users as to which tool they'd like to use. Our question: Would you be OK with us using the smart given that most of the system libraries on our distro are CDDL licensed ? Thanks, Sriram -- Belenix: www.belenix.org From afb at algonet.se Mon Sep 6 13:00:34 2010 From: afb at algonet.se (=?ISO-8859-1?Q?Anders_F_Bj=F6rklund?=) Date: Mon, 6 Sep 2010 22:00:34 +0200 Subject: A question about bundling smart with our distribution In-Reply-To: References: Message-ID: <64B3CA46-4BDB-4808-9D98-B88D9B1E9C3A@algonet.se> Sriram Narayanan wrote: > I'm one of the team members of the Belenix Distro (www.belenix.org). > We are presently using the SVR4 package format, and have wanted to > move to a more modern day package format. The .pkg and .7z formats are available too, if you need them... It was added after discussion with other OpenSolaris community: https://code.launchpad.net/~afb/smart/pkg There was also a branch with some generic Solaris fixes, like broken file locking and such as discovered by OSUnix/StormOS: https://code.launchpad.net/~afb/smart/solaris But I guess neither project went ahead with Smart at the time, and Belenix was developing a custom package manager I think ? So we only added basic Nexenta support, with --ignore-locks. If you want to help test/support real Solaris support, great! > We are very likely to use rpm5 as our package system :) We intend to > bundle both yum and smart, and will leave it to our users as to which > tool they'd like to use. > > Our question: > Would you be OK with us using the smart given that most of the system > libraries on our distro are CDDL licensed ? I'm not sure what you are asking here. Smart is freely available under the GPLv2+ license. It works fine with rpm5 as the backend. Currently Smart 1.4 is under finalizing, but the Solaris support could be merged in for the next release (Smart 1.5) perhaps... ? --anders From sriram at belenix.org Mon Sep 6 13:29:15 2010 From: sriram at belenix.org (Sriram Narayanan) Date: Tue, 7 Sep 2010 01:59:15 +0530 Subject: A question about bundling smart with our distribution In-Reply-To: <64B3CA46-4BDB-4808-9D98-B88D9B1E9C3A@algonet.se> References: <64B3CA46-4BDB-4808-9D98-B88D9B1E9C3A@algonet.se> Message-ID: Hi: We're considering using rpm5 as our package system, with smart as the frontend. Moinak (CCd) had developed spkg as a stop gap arrangement till we figured out what to do next. We find IPS infeasible in low-bandwidth countries, and we wanted to move away from SVR4 to something that's more widely known. We have been apprehensive about package manager licensing ever since Debian Legal disliked how Nexenta modified and used dpkg (even though they wanted to conteibute back the source). Debian Legal's concerns were about Nexenta's dpkg linking with a non-GPL libc. There is once again a discussion thread about this on this month's Debian Legal mailing list. No one on the Belenix team is a lawyer, and we've all got day jobs where we do something else. So, we thought that the best thing to do is to simply ask on the smart mailing list whether you are OK with us building, linking and distributing smart code along with non-GPLd (yet opensource) libraries. -- Sriram On 9/7/10, Anders F Bj?rklund wrote: > Sriram Narayanan wrote: >> I'm one of the team members of the Belenix Distro (www.belenix.org). >> We are presently using the SVR4 package format, and have wanted to >> move to a more modern day package format. > > The .pkg and .7z formats are available too, if you need them... > It was added after discussion with other OpenSolaris community: > > https://code.launchpad.net/~afb/smart/pkg > > There was also a branch with some generic Solaris fixes, like > broken file locking and such as discovered by OSUnix/StormOS: > > https://code.launchpad.net/~afb/smart/solaris > > But I guess neither project went ahead with Smart at the time, > and Belenix was developing a custom package manager I think ? > > So we only added basic Nexenta support, with --ignore-locks. > If you want to help test/support real Solaris support, great! > >> We are very likely to use rpm5 as our package system :) We intend to >> bundle both yum and smart, and will leave it to our users as to which >> tool they'd like to use. >> >> Our question: >> Would you be OK with us using the smart given that most of the system >> libraries on our distro are CDDL licensed ? > > > I'm not sure what you are asking here. Smart is freely available > under the GPLv2+ license. It works fine with rpm5 as the backend. > > Currently Smart 1.4 is under finalizing, but the Solaris support > could be merged in for the next release (Smart 1.5) perhaps... ? > > --anders > > -- Sent from my mobile device Belenix: www.belenix.org From afb at algonet.se Mon Sep 6 13:44:35 2010 From: afb at algonet.se (=?ISO-8859-1?Q?Anders_F_Bj=F6rklund?=) Date: Mon, 6 Sep 2010 22:44:35 +0200 Subject: A question about bundling smart with our distribution In-Reply-To: References: <64B3CA46-4BDB-4808-9D98-B88D9B1E9C3A@algonet.se> Message-ID: Sriram Narayanan: > No one on the Belenix team is a lawyer, and we've all got day jobs > where we do something else. Me too. :-) But all the legalese should be in the LICENSE file (GPL). > So, we thought that the best thing to do is to simply ask on the smart > mailing list whether you are OK with us building, linking and > distributing smart code along with non-GPLd (yet opensource) > libraries. I'm fine with it myself, as I've used Smart on both Darwin and FreeBSD. Neither of which has GPL system libraries... Smart also runs on Mac OS X and Windows, which doesn't even have open source system libraries. Smart is still under GPL. And Python doesn't really "link" in the same way as C/C++ ? So as long as you contribute any changes you make to Smart... --anders From gustavo at niemeyer.net Mon Sep 6 14:13:18 2010 From: gustavo at niemeyer.net (Gustavo Niemeyer) Date: Mon, 6 Sep 2010 18:13:18 -0300 Subject: A question about bundling smart with our distribution In-Reply-To: References: <64B3CA46-4BDB-4808-9D98-B88D9B1E9C3A@algonet.se> Message-ID: Hey there, > So as long as you contribute any changes you make to Smart... That's not entirely the case. If the code is a change in Smart, or is using Smart as a library, it must be licensed as GPL too. That's the very basis of the GPL license, so we can't simply dismiss it or the license would have no value. -- Gustavo Niemeyer http://niemeyer.net http://niemeyer.net/blog http://niemeyer.net/twitter From afb at algonet.se Mon Sep 6 14:23:01 2010 From: afb at algonet.se (=?ISO-8859-1?Q?Anders_F_Bj=F6rklund?=) Date: Mon, 6 Sep 2010 23:23:01 +0200 Subject: A question about bundling smart with our distribution In-Reply-To: References: <64B3CA46-4BDB-4808-9D98-B88D9B1E9C3A@algonet.se> Message-ID: <57C8D19B-7495-451F-BDF9-A5BC67F12F31@algonet.se> Gustavo Niemeyer wrote: >> So as long as you contribute any changes you make to Smart... > > That's not entirely the case. If the code is a change in Smart, or is > using Smart as a library, it must be licensed as GPL too. That's the > very basis of the GPL license, so we can't simply dismiss it or the > license would have no value. Sorry, I was not being clear. I meant for the _specific_ issue of distributing Smart with a system a non-GPL-compatible libc library. For the code using Smart, the standard GPLv2+ rules would apply... But to me it is OK with running Smart (GPL) on a Sun libc (CDDL) OS. --anders From gustavo at niemeyer.net Mon Sep 6 14:31:08 2010 From: gustavo at niemeyer.net (Gustavo Niemeyer) Date: Mon, 6 Sep 2010 18:31:08 -0300 Subject: A question about bundling smart with our distribution In-Reply-To: <57C8D19B-7495-451F-BDF9-A5BC67F12F31@algonet.se> References: <64B3CA46-4BDB-4808-9D98-B88D9B1E9C3A@algonet.se> <57C8D19B-7495-451F-BDF9-A5BC67F12F31@algonet.se> Message-ID: Hey Anders, > Sorry, I was not being clear. I meant for the _specific_ issue of > distributing Smart with a system a non-GPL-compatible libc library. > > For the code using Smart, the standard GPLv2+ rules would apply... > But to me it is OK with running Smart (GPL) on a Sun libc (CDDL) OS. Absolutely. You can use Smart to manage software licensed with any license. -- Gustavo Niemeyer http://niemeyer.net http://niemeyer.net/blog http://niemeyer.net/twitter From sriram at belenix.org Mon Sep 6 20:37:42 2010 From: sriram at belenix.org (Sriram Narayanan) Date: Tue, 7 Sep 2010 09:07:42 +0530 Subject: A question about bundling smart with our distribution In-Reply-To: References: <64B3CA46-4BDB-4808-9D98-B88D9B1E9C3A@algonet.se> <57C8D19B-7495-451F-BDF9-A5BC67F12F31@algonet.se> Message-ID: Thanks everyone :) -- Sriram On 9/7/10, Gustavo Niemeyer wrote: > Hey Anders, > >> Sorry, I was not being clear. I meant for the _specific_ issue of >> distributing Smart with a system a non-GPL-compatible libc library. >> >> For the code using Smart, the standard GPLv2+ rules would apply... >> But to me it is OK with running Smart (GPL) on a Sun libc (CDDL) OS. > > Absolutely. You can use Smart to manage software licensed with any license. > > -- > Gustavo Niemeyer > http://niemeyer.net > http://niemeyer.net/blog > http://niemeyer.net/twitter > -- Sent from my mobile device Belenix: www.belenix.org From steve at kelem.net Thu Sep 9 11:34:07 2010 From: steve at kelem.net (Steve Kelem) Date: Thu, 09 Sep 2010 11:34:07 -0700 Subject: upgrade/downgrade loop Message-ID: <4C89289F.4060301@kelem.net> I have "smart" in one of my desktop panels. It lets me know when there are new upgrades available, but it is currently stuck in a loop. This morning it wanted to upgrade gnupg, and downgrade gnupg2: 2010/9/9 11:10 gnupg 1.4.10-2.fc13 at x86_64 Downgrades [x] gnupg2 2.0.14-2.fc13 at x86_64 gnupg2 2.0.14-6.fc13 at x86_64 Upgrades gnupg2 2.0.14-2.fc13 at x86_64 from download.fedoraproject.org/.../gnupg... Three minutes later, after the above action had completed, it wanted to downgrade gnupg and upgrade gnupg2: 2010/9/9 11:13 gnupg2 2.0.14-2.fc13 at x86_64 Downgrades [x] gnupg2 2.0.14-6.fc13 at x86_64 Upgrades [x] gnupg 1.4.10-2.fc13 at x86_64 1. Why is there this loop? 2. How do we fix it? 3. Is this the correct email list for this problem? 4. Should I file a bug? If so, where? Thanks for your help, Steve I'm running Fedora 13 on a dual x86_64 system (Dell Latitude E6500). From afb at algonet.se Thu Sep 9 14:28:55 2010 From: afb at algonet.se (=?ISO-8859-1?Q?Anders_F_Bj=F6rklund?=) Date: Thu, 9 Sep 2010 23:28:55 +0200 Subject: upgrade/downgrade loop In-Reply-To: <4C89289F.4060301@kelem.net> References: <4C89289F.4060301@kelem.net> Message-ID: <0281FD4A-32C7-45BA-8025-9AF67402B0E8@algonet.se> Steve Kelem wrote: > I have "smart" in one of my desktop panels. It lets me know when > there are new upgrades available, but it is currently stuck in a > loop. This morning it wanted to upgrade gnupg, and downgrade gnupg2: > 2010/9/9 11:10 > gnupg 1.4.10-2.fc13 at x86_64 > Downgrades > [x] gnupg2 2.0.14-2.fc13 at x86_64 > > gnupg2 2.0.14-6.fc13 at x86_64 > Upgrades > gnupg2 2.0.14-2.fc13 at x86_64 > > from download.fedoraproject.org/.../gnupg... > > Three minutes later, after the above action had completed, it > wanted to downgrade gnupg and upgrade gnupg2: > 2010/9/9 11:13 > gnupg2 2.0.14-2.fc13 at x86_64 > Downgrades > [x] gnupg2 2.0.14-6.fc13 at x86_64 > Upgrades > [x] gnupg 1.4.10-2.fc13 at x86_64 > > 1. Why is there this loop? Well presumably you have something else requiring "gpg"... The original package provides both: gpg = 2.0.14-2.fc13 gnupg2 = 2.0.14-2.fc13 Then it was split, for the update: gpg = 1.4.10-2.fc13 gnupg = 1.4.10-2.fc13 gnupg2 = 2.0.14-6.fc13 So in order to upgrade "gnupg2", "gnupg" must be installed. smart query --requires gpg > 2. How do we fix it? I think you should be able to break free of the loop by locking the version of "gnupg" to be "= 1.4.10-2.fc13" ? That way you will still get updates to gnupg2, but it won't upgrade gnupg just because of the "gpg" provides. smart flag --set lock 'gnupg = 1.4.10-2.fc13 at x86_64' > 3. Is this the correct email list for this problem? > 4. Should I file a bug? If so, where? > > Thanks for your help, > Steve > > I'm running Fedora 13 on a dual x86_64 system (Dell Latitude E6500). This seems like the correct list, maybe on Fedora too ? You can report bugs at https://bugs.launchpad.net/smart --anders