Hi,
Just a quick heads up. I am now building gnote 0.3.0 for Fedora 11 and Fedora 10. There has been a number of important change my last mail about gnote to this list. It now includes several plugins, ability to spell check notes and most importantly, a GNOME applet.
I believe the only major feature left that was discussed here is the ability to import Tomboy notes on first start which is the next item on the developer's list along with sync abilities. Gnote is on a weekly release schedule now (every wed) so I am sure we will be getting good updates soon. I will keep you folks informed as we move forward.
Rahul
On Fri, 2009-05-01 at 18:29 +0530, Rahul Sundaram wrote:
Hi,
Just a quick heads up. I am now building gnote 0.3.0 for Fedora 11 and Fedora 10. There has been a number of important change my last mail about gnote to this list. It now includes several plugins, ability to spell check notes and most importantly, a GNOME applet.
I believe the only major feature left that was discussed here is the ability to import Tomboy notes on first start which is the next item on the developer's list along with sync abilities. Gnote is on a weekly release schedule now (every wed) so I am sure we will be getting good updates soon. I will keep you folks informed as we move forward.
We should probably look at switching out tomboy with gnote in the f12 panel configuration. Not sure what to do about upgrades, though. Obsoleting tomboy wouldn't be right...
On Fri, 1 May 2009, Matthias Clasen wrote:
On Fri, 2009-05-01 at 18:29 +0530, Rahul Sundaram wrote:
Hi,
Just a quick heads up. I am now building gnote 0.3.0 for Fedora 11 and Fedora 10. There has been a number of important change my last mail about gnote to this list. It now includes several plugins, ability to spell check notes and most importantly, a GNOME applet.
I believe the only major feature left that was discussed here is the ability to import Tomboy notes on first start which is the next item on the developer's list along with sync abilities. Gnote is on a weekly release schedule now (every wed) so I am sure we will be getting good updates soon. I will keep you folks informed as we move forward.
We should probably look at switching out tomboy with gnote in the f12 panel configuration. Not sure what to do about upgrades, though. Obsoleting tomboy wouldn't be right...
then don't obsolete it. For new installs people get gnote. For people who have tomboy and like it they can keep it. If someone upgrades and wishes to find a non-mono note app - that's what the search functions in pk/yum/yumex are all for.
-sv
On 2009-05-01, 14:09 GMT, Seth Vidal wrote:
then don't obsolete it. For new installs people get gnote. For people who have tomboy and like it they can keep it. If someone upgrades and wishes to find a non-mono note app - that's what the search functions in pk/yum/yumex are all for.
And given the brokeness of our package selection mechanism, it would get precedence over tomboy because it has shorter name. Yay! Finally once it selects the correct package!
Matěj
P.S.: Sorry, Seth, cannot resist.
On Mon, 4 May 2009, Matej Cepl wrote:
On 2009-05-01, 14:09 GMT, Seth Vidal wrote:
then don't obsolete it. For new installs people get gnote. For people who have tomboy and like it they can keep it. If someone upgrades and wishes to find a non-mono note app - that's what the search functions in pk/yum/yumex are all for.
And given the brokeness of our package selection mechanism, it would get precedence over tomboy because it has shorter name. Yay! Finally once it selects the correct package!
Matěj
P.S.: Sorry, Seth, cannot resist.
you haven't read the compare_providers routine in a long time, then.
If EVERYTHING else is equal then shortest-name is used. But there is A LOT of other things used before that is what it falls down to..
but thanks for not taking the time to see if things have changed.
-sv
On 2009-05-04, 16:45 GMT, Seth Vidal wrote:
but thanks for not taking the time to see if things have changed.
I haven't read the source code, true, but I lost /var parition last week (BTRFS is fun!) and had to rebuild /var/lib/rpm. During that I got exim installed again, so I don't think that much has changed (I prefer postfix, and I would understand if I got some sane default -- e.g., sendmail -- not random package).
Matěj
On Tue, 5 May 2009, Matej Cepl wrote:
On 2009-05-04, 16:45 GMT, Seth Vidal wrote:
but thanks for not taking the time to see if things have changed.
I haven't read the source code, true, but I lost /var parition last week (BTRFS is fun!) and had to rebuild /var/lib/rpm. During that I got exim installed again, so I don't think that much has changed (I prefer postfix, and I would understand if I got some sane default -- e.g., sendmail -- not random package).
I'd need to know a lot more about how you 'rebuilt' things and what the outputs were to tell you anything here.
But if a pkg requires mta and has nothing else to show us then sure, shortest name will win.
Would you rather it be unpredictable?
-sv
On 2009-05-05, 20:46 GMT, Seth Vidal wrote:
I'd need to know a lot more about how you 'rebuilt' things and what the outputs were to tell you anything here.
Something in the lines of
rpm -qf /usr/lib64/*/* |awk \ '/nevlastní žádný balíček/ {print $2}'\ |xargs repoquery -qf|sort -u|xargs yum install -y
run on different directories (various lib* and *bin directories). ('nevlastní žádný balíček' is 'not owned by any package' in Czech).
Which I think means something totally unpredictable, I guess.
But if a pkg requires mta and has nothing else to show us then sure, shortest name will win.
Would you rather it be unpredictable?
No, I would prefer FESCO (or whomever) approved policy stating that e.g. /usr/sbin/sendmail or mta-daemon means (in this or any other order):
1) sendmail 2) postfix 3) exim 4) huge group of pidgeons, 5) small group of pidgeons, 6) a pidgeon 7) bottle in the sea 8) Lotus Notes 9) M$ Exchange 10) qmail
or something of that sort.
Matěj
On Tue, 5 May 2009, Matej Cepl wrote:
On 2009-05-05, 20:46 GMT, Seth Vidal wrote:
I'd need to know a lot more about how you 'rebuilt' things and what the outputs were to tell you anything here.
Something in the lines of
rpm -qf /usr/lib64/*/* |awk \ '/nevlastní žádný balíček/ {print $2}'\ |xargs repoquery -qf|sort -u|xargs yum install -y
run on different directories (various lib* and *bin directories). ('nevlastní žádný balíček' is 'not owned by any package' in Czech).
Which I think means something totally unpredictable, I guess.
But if a pkg requires mta and has nothing else to show us then sure, shortest name will win.
Would you rather it be unpredictable?
No, I would prefer FESCO (or whomever) approved policy stating that e.g. /usr/sbin/sendmail or mta-daemon means (in this or any other order):
- sendmail
- postfix
- exim
- huge group of pidgeons,
- small group of pidgeons,
- a pidgeon
- bottle in the sea
- Lotus Notes
- M$ Exchange
- qmail
or something of that sort.
as I said on irc right before you dropped off:
Problems: 1. you need to determine that order and get everyone to stop arguing over it enough to ratify it 2. you need special info in the repodata to make that happen 3. you need to deal with conflicts in the repodata between repos
-sv
Seth Vidal wrote:
On Tue, 5 May 2009, Matej Cepl wrote:
No, I would prefer FESCO (or whomever) approved policy stating that e.g. /usr/sbin/sendmail or mta-daemon means (in this or any other order):
- sendmail
- postfix
- exim
[...]
as I said on irc right before you dropped off:
Problems:
- you need to determine that order and get everyone to stop arguing
over it enough to ratify it 2. you need special info in the repodata to make that happen 3. you need to deal with conflicts in the repodata between repos
4. You need to repeat the process whenever a new mta is added to the distro.
-Toshio
On 2009-05-05, 22:04 GMT, Seth Vidal wrote:
or something of that sort.
as I said on irc right before you dropped off:
sorry, my jabber server went away.
Problems:
- you need to determine that order and get everyone to stop
arguing over it enough to ratify it 2. you need special info in the repodata to make that happen 3. you need to deal with conflicts in the repodata between repos
Yes, and nobody wants to do the work, so we are in the same place where MTA is decided by the length of the package name. Which is certainly the best.
Oh well.
</thread> <!-- at least for me -->
Matěj
On Wed, 2009-05-06 at 17:27 +0200, Matej Cepl wrote:
Yes, and nobody wants to do the work, so we are in the same place where MTA is decided by the length of the package name. Which is certainly the best.
That's hardly fair. When the user doesn't express any preference for an MTA, either explicitly, or through the use of the "base" group in comps, then yes, yum resorts to the best providers algorithm to satisfy the generic mta requirement. With no other hints, all things wind up being equal amongst our MTA providers and yum does finally have to resort to shortest name.
On Wed, 6 May 2009, Jesse Keating wrote:
On Wed, 2009-05-06 at 17:27 +0200, Matej Cepl wrote:
Yes, and nobody wants to do the work, so we are in the same place where MTA is decided by the length of the package name. Which is certainly the best.
That's hardly fair. When the user doesn't express any preference for an MTA, either explicitly, or through the use of the "base" group in comps, then yes, yum resorts to the best providers algorithm to satisfy the generic mta requirement. With no other hints, all things wind up being equal amongst our MTA providers and yum does finally have to resort to shortest name.
and just so we're clear: Shortest-name is not a yum-ism - it comes from anaconda, from looooooooooooong ago in a galaxy far away. I duplicated it in yum for consistency.
-sv
On 2009-05-06, 16:44 GMT, Seth Vidal wrote:
and just so we're clear: Shortest-name is not a yum-ism - it comes from anaconda, from looooooooooooong ago in a galaxy far away. I duplicated it in yum for consistency.
And just so we are completely clear: my frustration notwithstanding, I don't think it is your fault or primarily technological problem -- I am quite sure that you can fix whatever algorithm is decided upon in no time.
Matěj
desktop@lists.fedoraproject.org