Re: Evolution-2.31.91 & .92 for F14
On Thu, 2010-09-16 at 20:10 -0500, Mike Chambers wrote: > If you download either of these versions from koji and try to install > them, you get a deps issue with gnome-panel, as it requires > libedataserverui-1.2.so.10()(64bit). Hi, for your information, the 2.31.92 release is not built completely yet, it's awaiting for other packages, like evolution-exchange and evolution-mapi to be build. Then it'll be pushed to testing. > So will gnome-panel (am guessing most of gnome as well) be built anytime > soon as well? Ah, right, dependent packages on evolution-data-server should be rebuild together with it, as there was a so name bump in evolution-data-server. Those can be rebuild now, till the new evolution-data-server is marked for building in the build system for Fedora 14. Bye, Milan -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
libedataserverui soname bump in Fedora 14
Hi all, I'm so sorry for a late notice, but there was a soname bump of libedataserverui library from evolution-data-server package in time for 2.31.91 update, but I didn't notice this change, and because this update didn't get it to the testing repo, then I realized just now, when I finished an update to 2.31.92 and pushed it to updates-testing. Affected packages seems to be these: almanah anjal gnome-panel It should be enough to just rebuild these against evolution-data-server-2.31.92, which is still marked for a build system. The update request url is here: https://admin.fedoraproject.org/updates/evolution-mapi-0.31.92-1.fc14,evolution-exchange-2.31.92-1.fc14,openchange-0.9-8.fc14,evolution-2.31.92-1.fc14,evolution-data-server-2.31.92-1.fc14,gtkhtml3-3.31.92-1.fc14 Bye, Milan ___ devel-announce mailing list devel-annou...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel-announce -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Evolution-data-server update to 2.91.1 in rawhide
Hi, the new release of evolution-data-server 2.91.1 contains API backward incompatible changes in Camel, thus packages using it might need adoption. Changes were announced at [1], and even I believe upstream will take care of these changes, I would like to help with adoption on modules requiring it. Planned date for doing the evolution-data-server update in Rawhide is next Monday, October 11th, 2010. I would like to also ask respective owners of [3] to approve me commit rights on his/her package, which I'll request this Friday or beginning of the next week through [2], so I'll be able to: a) occasionally rebuild those packages against newer evolution-data-server or evolution, to help with smoother updates (I hope package owners will be fine with me doing so.) b) add those packages to updates of evolution-data-server and evolution, thus changes from these will come out together. Thanks and bye, Milan [1] http://mail.gnome.org/archives/evolution-hackers/2010-September/msg00037.html [2] https://admin.fedoraproject.org/pkgdb/acls/name/ [3] Packages depending on evolution-data-server and/or evolution in rawhide as of today: almanah anerley contact-lookup-applet contacts dates deskbar-applet ekiga empathy evolution-couchdb evolution-rspam evolution-rss evolution-sharp giggle glabels gnome-do-plugins (obsolete these days?) gnome-launch-box gnome-panel gnome-phone-manager gnome-python2-desktop jana libopensync-plugin-evolution2 mail-notification meego-panel-datetime meego-panel-myzone moblin-panel-myzone moblin-panel-people nautilus-sendto pidgin planner ruby-revolution syncevolution tasks tracker ___ devel-announce mailing list devel-annou...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel-announce -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [PATCH] macros: Globally add --disable-silent-rules to configure
On Tue, 2011-08-09 at 11:11 -0400, Tom Lane wrote: > > Looks fine to me. The only reason I have to dislike it is the > > temptation for people to inspect build logs as a proof of what flags a > > package was built with (since the only sane thing is to store that in > > the binary itself, which the tools team is working on). But for > > debugging build failures this is great. > > What happens in packages using a (possibly old) autoconf script that > doesn't recognize --disable-silent-rules? > > IMO it would be better to add this option to the %configure calls > in packages where it's actually an issue (which is surely a small > minority, unless Colin has got evidence to the contrary). Hi, I would like you to give me an option to not use --disable-silent-rules, because it breaks waf build. I was just trying to build samba4 update for rawhide and I got this [1]: + ./configure --build=x86_64-redhat-linux-gnu --host=x86_64-redhat-linux-gnu --program-prefix= --disable-dependency-tracking --disable-silent-rules --prefix=/usr --exec-prefix=/usr --bindir=/usr/bin --sbindir=/usr/sbin --sysconfdir=/etc --datadir=/usr/share --includedir=/usr/include --libdir=/usr/lib64 --libexecdir=/usr/libexec --localstatedir=/var --sharedstatedir=/var/lib --mandir=/usr/share/man --infodir=/usr/share/info --with-modulesdir=/usr/lib64/samba --with-lockdir=/var/lib/samba4 --with-piddir=/var/run --with-privatedir=/var/lib/samba4/private --with-sockets-dir=/var/run --sysconfdir=/etc/samba4 --datadir=/usr/share/samba --disable-gnutls --disable-rpath-install --builtin-libraries=ccan,wbclient '--bundled-libraries=heimdal,!talloc,!tdb,!tevent,!ldb,!zlib' waf [command] [options] Main commands (example: ./waf build -j4) build : build all targets clean : removes the build files configure : configures the project ctags : build 'tags' file using ctags dist: makes a tarball for distribution distcheck : test that distribution tarball builds and installs distclean : removes the build directory etags : build TAGS file using etags install : installs the build files pydoctor: build python apidocs reconfigure : reconfigure if config scripts have changed test: Run the test suite (see test options below) testonly: run tests without doing a build first uninstall : removes the installed files wafdocs : build wafsamba apidocs wildcard_cmd: called on a unknown command waf: error: no such option: --disable-silent-rules error: Bad exit status from /var/tmp/rpm-tmp.5kugM6 (%build) Bad exit status from /var/tmp/rpm-tmp.5kugM6 (%build) RPM build errors: Child returncode was: 1 EXCEPTION: Command failed. See logs for output. Thus even autoconf is fine, then waf build system is not. Could Colin fix this, please? Thanks in advance and bye, Milan [1]http://koji.fedoraproject.org/koji/getfile?taskID=3265556&name=build.log -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
evolution-data-server soname version bump for rawhide/Fedora 16 next week
Hi, I just want to let you know that evolution-data-server 3.1.5 release, which is about to happen the next week, on August 15th, +/-, changes soname versions for almost everything it provides, namely libedataserver, libecal, libedatacal, libebook, libedatabook. Anything depending on it would be rebuild on both branches against newer eds, when its update will be done. I will rebuild all to which I have commit rights by the end of the week, after the release. Bye, Milan ___ devel-announce mailing list devel-annou...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel-announce -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [PATCH] macros: Globally add --disable-silent-rules to configure
On Thu, 2011-08-11 at 11:16 -0400, Colin Walters wrote: > So I think it makes sense to patch samba's wscript to also support > --disable-silent-rules for now. Hi, yup, I made it that way, for now. > It may make sense to also have an automake_compat.py in upstream waf > which does something with the configure options shipped with Automake > (which are currently dependency-tracking, maintainer-mode, multilib, > and silent-rules)...and while we're in here an option to ignore > unknown options =) I filed > http://code.google.com/p/waf/issues/detail?id=1023 Thanks, I hope they will take care of the issue better than me. Bye, Milan -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
evolution-data-server's libcamel soname version bump in Fedora 16/rawhide for 3.1.90 next week
Hi, just after 3.1.5 release of evolution-data-server was added an API change in libcamel, thus the next week, when 3.1.90 will be released and I'll do an update in Fedora 16/rawhide, anything depending on libcamel will require a rebuild. Again, I'll take care of everything I will be able to, and I'll also add it to the same update as evolution-data-server. After my yesterday turn, there are still packages I cannot do anything with, also because other dependency issues with them (like almanah depending on libcrypt), but I will do my best to make this (most likely final) soname version bump not that painful for others. Bye, Milan ___ devel-announce mailing list devel-annou...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel-announce -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Rawhide evolution gone funny
On Wed, 2011-11-02 at 07:57 +, Paul Johnson wrote: > For some reason, Evolution is not finding any of the plugins or > anything. It'll start but has on the title bar > > e-utils-WARNING **: /usr/lib64/evolution/3.2/libcomposer.so.0: > undefined symbol: gtkhtml_editor_file_chooser_dialog_run > Failed to load > module: /usr/lib64/evolution/3.2/modules/libevolution-module-addressbook.so Hi, I suppose the update succeeded with gtkhtml3 package, but not with the rest, as Michael said in the other mail in this thread, thus if you downgrade it, then it'll work again. At least till the broken deps on rawhide are fixed and the full update to evolution 3.3.1 and gtkhtml3 4.3.1 will be possible without dependency issues. Bye, Milan -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora rawhide FTBFS status 2011-06-16 x86_64
On Wed, 2011-06-22 at 19:17 -0500, Matt Domsch wrote: > evolution-data-server-3.1.2-1.fc16 (build/make) Hi, not much to be done, except of not using deprecated flags in configure, because this is failing on a recently deprecated G_CONST_RETURN, but not in the eds itself, but in pango, which is not ready for such change yet. When the pango will be fixed then the eds will start building too. I guess similar failures due to used libraries not ready for deprecated symbols in public headers are in more packages than in eds. Bye, Milan -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Evolution trash folder
On Sun, 2010-03-21 at 20:53 -0500, Mike Chambers wrote: > No checkmarks checked or unchecked that I could find. The only other > explanation is if I did a clean setup (no backups) and see what that > does. I might do that with a clean/new test user and see what > happens. Hi, try to run Evolution from console, and see what it says, if anything, in time of deleting the message. One thing I do not understand from your description, when you delete message (press a Del button), the message is marked as deleted and either is removed from the message list or shown there with a strike out font. It should be also visible in the account's Trash folder. Because your Folder->Expunge does correct thing, then the message is marked as deleted. Thus I guess your UI is not showing the right thing, does it do at least one of the above mentioned? Maybe the index for a Trash folder is corrupted for some reason; you can try to stop Evolution and move out your ~/.evolution/mail/imap//folders.db file, but as it contains all your account index, then the next start will take some time, till it fills it again. Or you can drop only all Trash related tables from there, but it's not as that easy to do. If something goes wrong, then return the folders.db file back. Hope that helps, Milan -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Evolution trash folder
Hi, On Mon, 2010-03-22 at 18:22 -0500, Mike Chambers wrote: > Yes the message was indeed marked with a strike out font, but it was > never sent to the trash folder. The you seem to have unchecked View->Hide deleted messages, maybe intentionally. > I did already remove my .evolution > folder and restarted evolution again, and now the emails at least get > moved to the trash folder when deleted. The only thing I see now, is > when I close/exit evolution it doesn't automatically empty the trash > folder, and it is set in my preferences to do it every time. I didn't notice that myself, and because you let it recreate all the summaries from scratch then the corruption of indexes is pretty unlikely. I've no idea here right now. Bye, Milan -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Evolution 3.3.1 in rawhide
On Mon, 2011-11-07 at 19:10 +, Paul Johnson wrote: > Just managed to upgrade tonight, but there seems to be a hitch with > evolution - none of my folders appear! > ... > > GLib-GObject-WARNING **: g_object_get_property: object class > `EShellSettings' has no property named `mail-enable-local-folders' > > > Is this mail-enable-local-folders the problem and is there a way > around it? Hi, it seems the schemas file installation failed for some reason, because the corresponding path in GConf is /apps/evolution/mail/display/enable_local which is part of evolution-mail.schemas for me. Please run something like this, whether it'll help. for i in /etc/gconf/schemas/*.schemas ; do \ gconftool-2 --install-schema-file $i >/dev/null; done Bye, Milan -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
evolution-data-server 3.3.3 soname version bump in rawhide
Hi, just a note that the upcoming release of evolution-data-server 3.3.3 contains soname version bumps for libcamel and libedatacal, as of today. The release is planned for the next week. I'll rebuild broken deps packages the next day after the update lands to the rawhide, at least those I've commit rights to (it'll be definitely sooner than the last time). Bye, Milan ___ devel-announce mailing list devel-annou...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel-announce -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: evolution-data-server 3.3.3 soname version bump in rawhide
On Thu, 2011-12-15 at 08:22 -0500, Stephen Gallagher wrote: > Could you provide a list of the dependent packages that you don't have > commit rights to, so we can organize a provenpackager to help handle it? Hi, I know this is not the right procedure, but can I provide it "after it breaks", please? I've a little mess in what is still active and what not, thus I get the list by the broken deps messages, which is more accurate than my outdated records. I'm sorry for that. I'm currently receiving broken deps for only two packages from the last soname bump of eds in rawhide, one is syncevolution, to which I have commit rights, but the issue is something with linking after its update to newer version - I didn't follow the error closely. The other is gnome-python2-desktop, to which I do not have commit rights. I do not have commit rights to others too, but owners are forgiving to me and usually rebuild their packages on their own. Bye, Milan -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: evolution-data-server 3.3.3 soname version bump in rawhide
On Thu, 2011-12-15 at 08:22 -0500, Stephen Gallagher wrote: > Could you provide a list of the dependent packages that you don't have > commit rights to, so we can organize a provenpackager to help handle it? Hi, they are all built since yesterday, those which broke. I expected higher number of packages, but who knows. There left only syncevolution, which requires newer update of the tarball, as the current one is failing due to some missing files. The gnome-python2-desktop is also rebuilt, I asked Tomas Bzatek to rebuild it for me. Thanks to anyone else whom helped with this (and I didn't notice it). Bye, Milan -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
evoltuion-data-server 3.3.5 libcamel soname bump in rawhide
Hi, with evolution-data-server 3.3.5 release is also bumped soname version for libcamel. I realized just now, when building eds for rawhide. Bye, Milan ___ devel-announce mailing list devel-annou...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel-announce -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: FC17alpha, evolution, ati card, kernel 3.3.0-rc6 and me going crazy...
On Wed, 2012-03-07 at 22:56 -0500, Peter A wrote: > The issue effects only Evolution it seems - all other software I tried > works fine (that's anything from firefox to libreoffice to gimp to > ancient stuff like xv from an rpm built in 99). My desktop is KDE with > OpenGL rendering but most effects turned off. > > The issue results in the tree menu showing the mail boxes on the left > being shifted about 75px up. However, the cursor location (e.g. > highlighted folder when drag and drop) is what the screen should be. In > other words, I need to move the cursor about 75px further down to select > the correct folder. I wanted to talk to some friends about this so I > took a screenshot - and the screenshot shows up perfect. > (http://www.loonybin.org/evo1.jpg) However, if I do a screengrab of the > root window, the corruption is visible. > (http://www.loonybin.org/evo2.jpg). Both screenshots were taken less > than a second apart with import. > > So who do you think the problem lies with? Hi, I've no idea on the issue itself, but I'm wondering whether you can reproduce this in gtk3-demo too. I'm asking, because the folder tree is a descendant of the standard GtkTreeView, with no extra drawing, thus, if it's not caused by something in evolution itself, which I doubt same as you do, then the issue should be reproducible with gtk3-demo too. The gtk3-demo executable is part of gtk3-devel. There is a tree view on its main page, same as three tree view demos. Maybe this is related to a fact that the table headers are hidden in evolution. Bye, Milan -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Evolution + bogofilter
On Mon, 2012-03-19 at 23:06 -0500, Mike Chambers wrote: > Does setting emails in your inbox folder to junk working automatically? > It seem it doesn't do it automatically and I have to keep selecting them > and manually marking them junk. > > On a fresh install (such as this one), I do a restore from a backup file > as I always do, to include doiong the same thing in F16 (that worked > just fine) and the settings are there, and set as suppose to be. Also > evolution-bogofilter is installed as well. Just for some reason it's > not setting them to junk automatically. > > Any ideas? > > evolution-bogofilter-3.3.91-1.fc17.x86_64 > evolution-3.3.91-1.fc17.x86_64 > bogofilter-1.2.2-3.fc17.x86_64 Hi, evolution's backup doesn't contain your bogofilter database, it's stored in a bogofilter private directory, thus I guess you need to train it again? Bye, Milan -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Unresponsive maintainer for libical
Hi,
I realized that the maintainer of libical, Debarshi Ray, seem to be
unresponsive for quite a long time, not doing updates for libical.
There are filled two bugs with a request to do an update, the first [1]
from 2009-09-27 notifying about a release of 0.44, and then
the second [2] from 2010-08-31, notification about 0.46 upstream release
(upstream skipped 0.45). These updates are fixing also other issues
which might be visible in applications using it.
There are opened only 4 bugs (including these two) against libical in
Fedora.
I know I'm not following the NonResponsiveMaintainer policy closely, but
I believe, in this particular case, it would be with no gain.
I'm fine to take ownership of the libical package and do releases for
it.
Bye,
Milan Crha
[1] https://bugzilla.redhat.com/show_bug.cgi?id=525933
[2] https://bugzilla.redhat.com/show_bug.cgi?id=628893
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Unresponsive maintainer for libical
On Fri, 2010-12-03 at 12:47 +0200, Debarshi Ray wrote: > > I know I'm not following the NonResponsiveMaintainer policy closely, but > > I believe, in this particular case, it would be with no gain. > > > > I'm fine to take ownership of the libical package and do releases for > > it. > > I am orphaning it in PackageDB. Please take up ownership. Hi, thanks. Could you give me a link to the proper PackageDB page, please? I seem to lose it and I do not have much idea how to find it. (Bad of me, I'm sorry). Thanks and bye, Milan -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Unresponsive maintainer for libical
On Fri, 2010-12-03 at 14:36 +, Peter Robinson wrote: > https://admin.fedoraproject.org/pkgdb/packages/ > > Then you need to login and search for the package. Hi, thanks both for the link. I see [1] the libical is not orphaned yet, neither in devel, nor in F14, as I "only" can add myself to the package, but not take ownership as with other orphaned packages. I'm keeping this on the next Monday. :) Thanks and bye, Milan [1] https://admin.fedoraproject.org/pkgdb/acls/name/libical -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Unresponsive maintainer for libical
On Sat, 2010-12-04 at 13:02 +0200, Debarshi Ray wrote: > > I see [1] the libical is not orphaned yet, neither in devel, nor in F14, > > as I "only" can add myself to the package, but not take ownership as > > with other orphaned packages. > > I think what happens is when the owner orphans a package one of the > co-maintainers automatically get promoted. Hi, so I added myself to the package, and it's waiting for a review now. It might be done by 'robert' [1], who is the only maintainer of libical at the moment. Bye and thanks, Milan [1] https://admin.fedoraproject.org/pkgdb/users/packages/robert -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
gtkhtml3 soname bump in Rawhide
Hi,
just finished gtkhtml3 update to 3.91.4 has a soname bump, due
to changes in its API as was discovered in [1]. It has it since 3.91.3
release, somehow, only the soname wasn't changed.
I know this is kinda late notice, but the bug was discovered just before
the release.
I'm sorry for any inconvenience caused by this.
Bye,
Milan Crha
[1] https://bugzilla.redhat.com/show_bug.cgi?id=664279
___
devel-announce mailing list
devel-annou...@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel-announce
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
evolution-data-server (2.91.5) soname bump and library files location changes in Rawhide
Hi, with the recent evolution-data-server 2.91.5 release in Rawhide are done some internal changes in the soname versions and a location where the backend files for the addressbook and calendar should be saved. >From the commit log: - Change the installation path for E-D-S backends. Address book and calendar backend modules are now split into different installation directories so the D-Bus factory processes will only load relevant backend modules. This changes some pkg-config details for third-party backend modules. Instead of querying the backend directory with: pkg-config --variable=extensiondir evolution-data-server-1.2 you must query the directory for address book backends with: pkg-config --variable=backenddir libedata-book-1.2 and the directory for calendar backends with: pkg-config --variable=backenddir libedata-cal-1.2 - Bye, Milan ___ devel-announce mailing list devel-annou...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel-announce -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
rawhide update (2.91.6) of evolution-related packages is gtk3 only
Hi, Evolution team drops support for gtk2 in 2.91.6 release of evolution-related packages (gtkhtml3, evolution-data-server and evolution) which might make trouble for dependent packages which are still gtk2. I expect there will follow gtk3 updates for them in the near future too, if not done already (this is mainly for packages using libedataserverui and gtkhtml3, the rest should be fine). There are done soname bumps and api version bumps in above mentioned packages as well. The release will be done on Monday, when I plan to update rawhide too (+/- few days, if something will go wrong). Bye, Milan ___ devel-announce mailing list devel-annou...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel-announce -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: rawhide update (2.91.6) of evolution-related packages is gtk3 only
On Wed, 2011-01-26 at 18:15 +, Peter Robinson wrote: > Hi Milan, > > On Wed, Jan 26, 2011 at 4:16 PM, Milan Crha wrote: > >Hi, > > Evolution team drops support for gtk2 in 2.91.6 release of > > evolution-related packages (gtkhtml3, evolution-data-server and > > evolution) which might make trouble for dependent packages which are > > still gtk2. I expect there will follow gtk3 updates for them in the near > > future too, if not done already (this is mainly for packages using > > libedataserverui and gtkhtml3, the rest should be fine). > > Will this affect packages that just use eds? Hi, because this is the UI change, then only those requiring libedataserverui library will be affected (with the gtk3 change; with soname bumps there will be more affected). > > There are done soname bumps and api version bumps in above mentioned > > packages as well. The release will be done on Monday, when I plan to > > update rawhide too (+/- few days, if something will go wrong). > > Will you be rebuilding affected packages? Sure thing, I'll rebuild all affected I have commit access for. Bye, Milan -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
evolution-data-server soname version bump in F23 and rawhide the next week
Hi, the 3.17.4 release of evolution-data-server changes soname versions for camel, libecal and libedata-cal, due to some API changes in respective parts. I will rebuild packages for which I have commit rights, the same as I can help with the API change fixes, thus feel free to ping me or drop an e-mail. Bye, Milan -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: F-23 Branched report: 20150720 changes
On Mon, 2015-07-20 at 08:58 -0600, Kevin Fenzi wrote: > Should be fixed for tomorrows composes I would expect. Hi, doesn't seem to. I made an update for rawhide and f23 branch with evolution-data-server on Monday morning CEST. I know it breaks some dependencies, because there had been done soname version bump, but I didn't receive any notice of it yet. The usually arrive the next day. Furthermore, I run my rawhide machine today and tried `dnf update`, which didn't offer me the update of the evolution-data-server. I'd expect to have it offered after two days of the koji build. Maybe I missed some policy/update change? Bye, Milan -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: F-23 Branched report: 20150720 changes
On Wed, 2015-07-22 at 06:48 +0200, Milan Crha wrote: > Furthermore, I run my rawhide machine today and tried `dnf update`, > which didn't offer me the update of the evolution-data-server. I'd > expect to have it offered after two days of the koji build. > > Maybe I missed some policy/update change? > Hi again, it looks like a dnf issue, see below. Even manual update from dnf-1.0.1-3.fc23.noarch to dnf-1.0.2-2.fc24.noarch didn't help. Bye, Milan $ dnf list evolution Fedora - Rawhide - Developmental packages for t 792 kB/s | 43 MB 00:55 Last metadata expiration check performed 0:00:47 ago on Tue Jul 21 23:49:59 2015. Installed Packages evolution.x86_64 3.17.3-1.fc23 @System Available Packages evolution.i6863.17.4-1.fc24 rawhide evolution.x86_64 3.17.4-1.fc24 rawhide $ su Password: # dnf update Fedora - Rawhide - Developmental packages for t 784 kB/s | 43 MB 00:55 Last metadata expiration check performed 0:00:35 ago on Tue Jul 21 23:51:51 2015. Dependencies resolved. Nothing to do. Complete! -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: F-23 Branched report: 20150720 changes
On Wed, 2015-07-22 at 12:45 +0100, Peter Robinson wrote: > BTW is there an option to turn on the full yum style dep resolution? > -v adds some but not what is pulling in a particular package (or > removing one) as part of a process. I might be strange but I do find > it useful for some use cases. Hi, I finally used yum-deprecated to get the comprehensive list of all broken dependencies by my update. The situation with dnf is confusing, because it: a) stops on the first broken dependency b) doesn't tell about any error by default, which makes it look like everything works properly, except of getting the new package which I know is there. It's very confusing for such yum-old-school like me Bye, Milan -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Unable to submit update for F22 (was Re: bodhi 2 now live)
On Wed, 2015-08-19 at 21:45 -0600, Kevin Fenzi wrote: > There will likely be oddities and bugs. Please file them in github so > we can prioritize them and get them fixed up. > > https://github.com/fedora-infra/bodhi/issues Hi, I do not have a github account, and I'm currently not going to create any (github is not my favorite site), thus I'm writing here instead (after all, Fedora infrastructure issue => Fedora bugzilla, no?). I tried to submit an update for Fedora 22 and it just tells me that it wasn't able to submit it with absolutely no reason. My values are: Packages: Related Bugs: 1231591 Candidate Builds: evolution-3.16.5-2.fc22 Update notes: Fixes possible crash when viewing mailing list message digest. Final details Type: bugfix Severity: unspecified Suggestion: unspecified Close bugs on stable? [x] Auto-request stable? [x] Stable karma: 3 Unstable karma: -3 Require bugs: [ ] Require testcases: [ ] Require checks: Clicking Submit returns: "Unable to create update" with no other information in the right-bottom corner tooltip. Bye, Milan P.S.: the interface is different, more confusing, maybe when I get use to it it'll feel better, but it also requires me to do more changes in the interface, while the "old good" bodhi had preselected "bugfix" type, thus I only added builds and description, sometimes also list of bugs and that was all. Right now I do 3 more clicks. Is there a way to disable notifications of changes of other people? It doesn't worth the bandwidth in my case. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Unable to submit update for F22 (was Re: bodhi 2 now live)
On Thu, 2015-08-20 at 11:00 +0100, Paul Howarth wrote: > Looks like you need to hit "enter" after typing/pasting in the > package NVR into the "Candidate Builds" field, which was not at all > obvious to me. Hi, thanks for the hint. That made it work, the package name is repeated below the entry with a checkbox, after pressing the Enter. That's not intuitive at all. What I'm doing is filling a web form, such forms are usually submitted by pressing Enter, I wouldn't think of pressing Enter in an edit input field. Also because it was not needed when working with bodhi before. D'oh, the bug reference is lost and the bug not updated. Nonetheless, the update is filled. I hope. I guess. Bye, Milan -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Rawhide soname version bumps on evolution-data-server and evolution packages
Hello, I'm going to update evolution packages (evolution-data-server, evolution, evolution-ews and evolution-mapi) in rawhide to their 3.13.4 versions during today, which brings soname version bumps in evolution-data-server and evolution. I'll take care of rebuilds where needed (and I have commit rights for). There are also large changes in 3.13.4, in evolution-data-server are used subprocesses for backends and evolution uses webkit-based composer. Please use GNOME's bugzilla [1] for any issue you might find with these. Thanks and bye, Milan [1] https://bugzilla.gnome.org/enter_bug.cgi?product=evolution-data-server https://bugzilla.gnome.org/enter_bug.cgi?product=evolution -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Fedora 33 System-Wide Change proposal: swap on zram
On Thu, 2020-06-04 at 16:30 -0400, Ben Cotton wrote: > ... The memory used is not preallocated. It's > dynamically allocated and deallocated, on demand. ... > > The system will use RAM normally up until it's full, and then start > paging out to swap-on-zram, same as a conventional swap-on-drive Hi, I confess I've absolutely no idea about this, I mean how that works in practice, but when you tell me "we do not allocate on start, we allocate on demand, when the memory is full", then, I hope a logic question is, where do you allocate, when the memory is already full? If there's some threshold, then it's quite the same as preallocate the memory. Let aside how the compression itself works. Does it mean, that the actual outcome will be quicker response (than when using swap on disk) for a price of higher requirements on the CPU (thus it can compress/decompress in a timely manner), thus eventually higher power consumption, thus shorter up time, before the battery is down? I know I can easily misunderstand things, but it feels like a side effect of the compression. Virtual machines. I usually do not give it access to the all host system resources, I give it like 1 or 2 CPUs (sometimes more, but only when I know I want to do something expensive there), and like 2GB of memory (I used to give it one, but since Fedora begun to require at least 2, I increased it). With this swap to RAM on, should I give it even more memory (and eventually CPU), thus Fedora can boot and work reasonably well? When you've a machine with 4GB RAM and 1TB HDD and 1.6GHz CPU, it's much cheaper to use swap on disk than to waste RAM, which should be used for other things (it's even not fully usable 4GB, because some of that can use integrated graphics card). I guess this will penalize such low cost machines, though it needs testing to know for sure. There are devices with a lot less resources (there had been mentioned IoT, under which, I suppose, belong also toys like Raspberry PI, which do not have a lot of RAM (not counting Raspberry PI 4B)), where it might (or might not) hurt even more. My main machine has 16GB RAM. When I run compilation of some bigger projects (like WebKitGTK in my case, but I do not want to even think of giants like LibreOffice), then I face memory pressures, also depending on the target type (debug/release) and how many cores I give to it. It happens from time to time that the whole system freezes (keyboard/mouse doesn't react, neither Caps Lock/Num Lock), with high CPU usage. I suppose it tries to compile, but I never left it run that long, I just turn off the machine and start again, where the new run eventually survives. Should this swap to RAM help anyhow in such situation? > [https://pagure.io/fedora-qa/issue/632 QA: SwapOnzram Test Day] to > discover edge cases, and tweak the default configuration if necessary > to establish a good one-size-fits all approach. The developer usage and average (office) user usage are very different. I'm afraid you cannot find any number, which will fit to all. Bye, Milan ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
[heads-up] soname version bump for evolution-data-server in rawhide
Hello, I'm sorry for a late notice, the 3.37.3 release (will be done today) of the evolution-data-server has a soname version bump on the libedataserver library. It has a change on an EWebDAVSession API, which I do not think is used by many components, if any other than evolution itself at all. I'll take care of the rebuilds for the packages I've the commit rights for. Bye, Milan ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: [heads-up] soname version bump for evolution-data-server in rawhide
On Sat, 2020-07-04 at 15:27 -0700, Kevin Fenzi wrote: > On Sat, Jul 04, 2020 at 09:48:04AM -0700, Kevin Fenzi wrote: > > On Sat, Jul 04, 2020 at 06:37:09PM +0200, Fabio Valentini wrote: > > > I don't understand the rush. Hi, there had been some major issues with the previous release, which I didn't want to delay for another week. > > > I looked a bit and it didn't seem easy to fix the test failure in > folks... Right, I saw that too and didn't understand why that single test fails. When I built folks locally it passed with no problem, using the same evolution-data-server. I'd surely rebuild the three I have commits right for if the folks could work. > so in the interest of not having rawhide broken all > weekend/until we can sort that out I went and untagged that set of > packages: Okay, thanks. I didn't expect causing such a problem. I'm sorry about that. Bye, Milan ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: [heads-up] soname version bump for evolution-data-server in rawhide
On Tue, 2020-07-07 at 09:05 +0200, Milan Crha wrote: > Right, I saw that too and didn't understand why that single test > fails. When I built folks locally it passed with no problem, using > the same evolution-data-server. I'd surely rebuild the three I have > commits right for if the folks could work. Hi, I currently use the f33-build-side-25060 sidetag. I managed to find the cause of the test failure in folks [1], I'll backport the change into the sidetag for the time being and I'll build what I can there as well. Fabio, could you move/build your packages into that sidetag too, please? The updated folks might be in the sidetag within an hour or so, depending on koji speed. Thanks and bye, Milan [1] https://gitlab.gnome.org/GNOME/folks/-/merge_requests/40 ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: [heads-up] soname version bump for evolution-data-server in rawhide
On Tue, 2020-07-07 at 13:12 +0200, Fabio Valentini wrote: > If you need help with building other packages, feel free to ping me. Hi, thanks. I'm currently working on a patch for syncevolution and I started a build of ekiga few minutes ago. According to: $ repoquery --whatrequires libedataserver-1.2.so* --alldeps there lefts elementary-planner, evolution-chime and gnome-panel, to which I do not have commit rights. I can wait until Friday and tag the things to rawhide later, thus the maintainers have more time to even notice the change. I'm sorry I caused this mess. Thanks and bye, Milan ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Evolution + bogofilter
On Tue, 2012-03-20 at 10:17 -0500, Mike Chambers wrote: > Yes I understand it has to relearn. But it doesn't is the problem. I > had to keep marking them as junk. > > Example, just reinstalled F16+updates on this very box. Started evo + > the backup file as a restore, just as with F17. Soon as I marked the > initial spam stuff in my inbox as junk, it started marking > automatically. No, it doesn't get them all the time and have to relearn > as I go, but it starts to immediately. > > F17 does NOT do it, almost none at all, even after a couple of days of > marking them. Hi, try to run evolution from console like this: $ CAMEL_DEBUG=junk evolution which should tell you what evolution does when you mark message as junk/not-junk. It should print something when a new mail arrives too. This thread http://mail.gnome.org/archives/evolution-list/2011-November/msg00093.html is discussing similar issue with older evolution. It's rather long, but it contains some tests even for bogofilter database, checking how full it is and so on. Hope that helps, Milan -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Evolution + bogofilter
On Tue, 2012-03-20 at 10:17 -0500, Mike Chambers wrote: > > evolution's backup doesn't contain your bogofilter database, it's > > stored in a bogofilter private directory, thus I guess you need to > > train it again? > > Yes I understand it has to relearn. But it doesn't is the problem. I > had to keep marking them as junk. Hi, just a little follow-up. I came across similar question with other user and even not for him, but for me, in my F17 install, I get an empty string when issuing: $ dconf read /org/gnome/evolution/mail/junk-default-plugin regardless the schema file defines the default value as 'Bogofilter'. Maybe that's the reason for non-working automatic spam filtering? Bye, Milan P.S.: I would change the value while evolution is off, just to make sure its change will be taken in the effect -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Evolution + bogofilter
On Thu, 2012-03-22 at 10:12 -0500, Mike Chambers wrote: > On Thu, 2012-03-22 at 10:40 +0100, Milan Crha wrote: > > > Hi, > > just a little follow-up. I came across similar question with other user > > and even not for him, but for me, in my F17 install, I get an empty > > string when issuing: > >$ dconf read /org/gnome/evolution/mail/junk-default-plugin > > regardless the schema file defines the default value as 'Bogofilter'. > > Maybe that's the reason for non-working automatic spam filtering? > > Bye, > > Milan > > > > P.S.: I would change the value while evolution is off, just to make sure > > its change will be taken in the effect > > On F16 I run the dconf line above and returns nothing as well, cept junk > stuff works. > > How do you change the value, as in what is the command and what am I > suppose to see/read in the dconf if it's working correctly? Hi, F16 version of evolution (3.2.x) doesn't use GSettings, it's new in F17 (evolution 3.3.x -> 3.4.0). The 3.2.x uses GConf, and the key is $ gconftool-2 --get /apps/evolution/mail/junk/default_plugin For setting value I would use dconf-editor, or gconf-editor for GConf key. On F17 the value in dconf should be "Bogofilter" for you (without quotes), the same what the default value in schema defines. Bye, Milan -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Evolution + bogofilter
On Mon, 2012-03-19 at 23:06 -0500, Mike Chambers wrote: > On a fresh install (such as this one), I do a restore from a backup > file as I always do, to include doiong the same thing in F16 (that > worked just fine) and the settings are there, and set as suppose to > be. Also evolution-bogofilter is installed as well. Just for some > reason it's not setting them to junk automatically. > > Any ideas? > > evolution-bogofilter-3.3.91-1.fc17.x86_64 > evolution-3.3.91-1.fc17.x86_64 > bogofilter-1.2.2-3.fc17.x86_64 Hi again, I think I found the issue, it's a bug in evolution's code. Let's move to the upstream bug [1] for further investigation. I'm also currently building a test package for evolution [2], I'll test it and update [1] with my findings. If you could test it too then it'll be helpful. Thanks and bye, Milan [1] https://bugzilla.gnome.org/show_bug.cgi?id=672916 [2] http://koji.fedoraproject.org/koji/taskinfo?taskID=3956023 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Building the GNOME 3.4.1 Release
On Sat, 2012-04-14 at 13:53 +0100, Richard Hughes wrote: > If you're maintaining a GNOMEish package and you want it included in > the 3.4.1 release, please build the package like normal and then add > the build ID to: > > https://docs.google.com/spreadsheet/ccc?key=0AtzJKpbiGX1zdGJzeU9waFJFZmgyQzBuN2VxU0lxbHc Hi, it will be kind of you to not touch packages you do not own, especially those which are actively maintained. The way you did it breaks "build the package like normal" from your instructions. > Most of the packages released on ftp.gnome.org with the exact version > 3.4.1 can be handled by the mclazy script, but I'm sure there are > other packages that we'll need to do manually for the 3.4.1 > mega-update. I've no idea what it means in reality. Say I'll not add my build ids into your google page, am I still responsible for filling update of my packages? Bye, Milan -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Building the GNOME 3.4.1 Release
On Mon, 2012-04-16 at 10:33 +0100, Richard Hughes wrote: > ... > If you had already updated F17 with the upstream 3.4.1 then > the automatic script would have ignored your package completely. Hey, I didn't have much time to do so. You script stepped in only two hours after release on Gnome's ftp. It's not so bad, but still early and unexpected for me. > There's no way for me to know the difference between "maintainer not > doing update because he's busy" and "maintainer wants to handle this > himself in his own time". Maybe he's just _currently_ busy, sleeping (consider different timezones) and so on? Anyway, I never asked to have those packages part of the auto-build list, and never was asked for acceptance. This is easily distinguishable, isn't it? > Now you've told me in a not-so-polite way > I'll just take off evolution from the auto-build list. evolution*, please. > > I've no idea what it means in reality. Say I'll not add my build ids > > into your google page, am I still responsible for filling update of my > > packages? > > Yes, if you want to be, although I think we should aim to have one > easy-to-qa update for micro-point updates of a single desktop > environment, rather than the huge number of updates we had before that > were *impossible* to QA [1]. Is there a reason evolution is so special > that it shouldn't be considered a core GNOME package that gets > released with everything else? I cannot answer this objectively now, I'm sorry. There is certainly nothing extra special about those packages, apart of your auto-build script not being able to build those packages correctly (which it cannot do in general anyway), but I currently have bad feelings about this process, so, well, let me think about it. Bye, Milan -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Building the GNOME 3.4.1 Release
On Mon, 2012-04-16 at 12:17 +0100, Bastien Nocera wrote: > We've always built packages coming from the GNOME FTP and that follow > the GNOME releases. Matthias did it, I did it, Tomas did it, and now > Richard is doing it. Hi, hmm, I do not see any x.x.x-1 build being done by any of those you name for evo itself for the past year. > What's so special about Evolution that we can't update it as a bug fix > update when the package is released on the FTP site? I still differentiate between build and update. There is no problem with the update, there is a little problem with the build. It's mainly because dependencies between those packages, and in case of evo 3.4.0.1 also slightly more complicated change in the .spec file, which the smart script didn't know about. Bye, Milan -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
evolution-data-server/evolution 3.5.3 soname bump/API changes in rawhide next week
Hi all, release of evolution-data-server 3.5.3 and evolution 3.5.3 the next week contains API changes in the core part of these, mostly in a way how backends are authenticated and where the information about configured accounts is stored, together with single-include approach, thus expect the simple rebuild will likely not work. Matthew Barnes wrote patches for some other packages to adapt to all the changes already. In case you (or the upstream part) have trouble with the transition, feel free to ask at evolution-hack...@gnome.org . Bye, Milan -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
libical soname version bump in the rawhide the next week
Hello, I will update libical to version 2.0 the next week in rawhide. The change is source compatible, but not binary compatible, as they call it, thus the soname version had been bumped as well. I'll take care of the packages I have commit rights for. Bye, Milan -- devel mailing list devel@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
evolution-data-server soname version bump in rawhide the next week
Hi, the 3.19.4 release of evolution-data-server changes soname version for camel, due to some API changes. I will rebuild packages for which I have commit rights, the same as I can help with the API change fixes, thus feel free to ping me or drop an e-mail. I do not think that other than Evolution will need more attention, others might be rebuild just to be sure nothing broke. Bye, Milan -- devel mailing list devel@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
evolution-data-server soname version bump for libedata-book/libedata-cal next week (3.9.90 release)
Hi, there will be a soname version bump in evolution-data-server update 3.9.90 the next week, namely for libedata-book and libedata-cal libraries. Affected might be evolution-mapi and evolution-ews, which are updated together with it anyway. If there will be more, and I have commit access to them, then I rebuild them as well. Bye, Milan -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
(+libebackend, libedataserver) Re: evolution-data-server soname version bump for libedata-book/libedata-cal next week (3.9.90 release)
On Fri, 2013-08-16 at 08:03 +0200, Milan Crha wrote: > there will be a soname version bump in evolution-data-server update > 3.9.90 the next week, namely for libedata-book and libedata-cal > libraries. Affected might be evolution-mapi and evolution-ews, which are > updated together with it anyway. If there will be more, and I have > commit access to them, then I rebuild them as well. Hi, I've just committed a fix which changes soname version also for libebackend and libedataserver. Like before, whatever I'll be able to rebuild I will rebuild. Bye, Milan -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
(+libcamel) Re: (+libebackend, libedataserver) Re: evolution-data-server soname version bump for libedata-book/libedata-cal next week (3.9.90 release)
On Fri, 2013-08-16 at 16:47 +0200, Milan Crha wrote: > I've just committed a fix which changes soname version also for > libebackend and libedataserver. Like before, whatever I'll be able to > rebuild I will rebuild. Hi again, I'm sorry, but there was done an API change in libcamel at the very last moment too, thus this one is affected as well. Like before, whatever I'll be able to rebuild I will rebuild. Bye, Milan -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Update libical to 1.0 in rawhide the next week (soname version bump)
Hello, there was a release of libical 1.0 recently [1], and I'd like to update rawhide with it. It seems to be API compatible with 0.48, they only bumped the soname version due to version jump to 1.0. Rex Dieter helped me to fix a spec file to it (to use cmake), thus I plan to push the change around May 23rd, 2013, aka at the end of the next week. I tried to build evolution packages locally against it and there was no build issue, thus it might be just about rebuilding other dependent packages [2] and check whether any workarounds for 0.48 are still needed (I see some changes in iCalendar file saving, most notably with timezones (nothing serious with respect of functionality, saved files are only significantly larger due to saving whole history of daylight saving time changes) and string escaping, with which were couple issues in 0.48). Maybe there will be more packages due to transitive dependency (like other evolution packages is missing in [2]). I'll take care of the rebuild of packages I've commit rights for, the rest will be left for respective maintainers. Bye, Milan [1] https://bugzilla.redhat.com/show_bug.cgi?id=959925 [2] Packages from rawhide found by $ repoquery --archlist=src --repoid=fedora-source --repoid=updates-source --repoid=updates-testing-source -q --whatrequires --alldeps --releasever=rawhide libical-devel | sort asterisk-0:11.3.0-1.fc20.src evolution-data-server-0:3.9.1-1.fc20.src (*) gnokii-0:0.6.31-4.fc19.src kdepimlibs-0:4.10.3-1.fc20.src obexd-1:0.46-4.fc19.src openchange-0:2.0-1.fc19.src (*) osmo-0:0.2.12-0.5.svn924.fc20.src syncevolution-1:1.3.99.3-1.fc20.src (*) zarafa-0:7.0.13-1.fc19.src (*) these 3 I have commit rights for -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Update libical to 1.0 in rawhide the next week (soname version bump)
On Thu, 2013-05-16 at 13:01 +0200, Milan Crha wrote: > there was a release of libical 1.0 recently [1], and I'd like to update > rawhide with it. It seems to be API compatible with 0.48, they only > bumped the soname version due to version jump to 1.0. Rex Dieter helped > me to fix a spec file to it (to use cmake), thus I plan to push the > change around May 23rd, 2013, aka at the end of the next week. Hi, this is unfortunate, but I just realized that I do not have commit rights for libical. Unless anyone else will take on this, it'll wait till the main maintainer gets to the update, or I gain the commit rights. I'm sorry for the confusion I caused. Here [1] is a patch to master branch of libical which I wanted to commit. Bye, Milan [1] https://bugzilla.redhat.com/show_bug.cgi?id=959925#c9 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Proposal: remove insecure WebKitGTK+ packages for F27
On Fri, 2016-06-10 at 11:39 -0500, Michael Catanzaro wrote: > There's no transition documentation. Basically, you want to make sure > your package builds when switching the pkg-config version in > configure.ac to webkit2gtk-4.0. Hi, feel free to check out what the evolution-data-server does to switch from WebKit1 to WebKit2 here [1]. The code only opens a page and finally reads its title with a result, listening for a signal when the page was loaded. It doesn't do any DOM operations on the page. Bye, Milan [1] https://bugzilla.gnome.org/show_bug.cgi?id=751588#c22 -- devel mailing list devel@lists.fedoraproject.org https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: Proposal: remove insecure WebKitGTK+ packages for F27
On Fri, 2016-06-10 at 08:11 -0500, Michael Catanzaro wrote: > Active porting efforts are underway for Evolution (which will take > care of the mass of evolution-data-server dependencies like gnome- > shell and gdm) Hi, I think it's a very important detail, because if I remove the --recursive argument in your repoquery command, then I get significantly shorter list of affected packages [1], with ~half of them being addressed by the ongoing effort for the Evolution port. At least in case of the evolution-data-server, it uses the WebKit1, but doesn't expose it in the public API, thus it's a private dependency, spread on its own "users" only through the linker (libraries). I mean, checking only for direct dependencies makes more sense, from my point of view. Bye, Milan [1] repoquery --whatrequires webkitgtk3 --enablerepo=updates-testing Yum-utils package has been deprecated, use dnf instead. See 'man yum2dnf' for more information. balsa-0:2.5.2-3.fc24.x86_64 bijiben-0:3.20.2-1.fc24.x86_64 cairo-dock-plug-ins-webkit-0:3.4.1-7.fc24.x86_64 dwb-0:2015.10.09-2.20151009git.fc24.x86_64 emacs-1:25.0.94-1.fc24.x86_64 empathy-0:3.12.12-1.fc24.x86_64 evolution-0:3.20.2-1.fc24.i686 evolution-0:3.20.2-1.fc24.x86_64 evolution-0:3.20.3-1.fc24.i686 evolution-0:3.20.3-1.fc24.x86_64 evolution-bogofilter-0:3.20.2-1.fc24.x86_64 evolution-bogofilter-0:3.20.3-1.fc24.x86_64 evolution-data-server-0:3.20.2-1.fc24.i686 evolution-data-server-0:3.20.2-1.fc24.x86_64 evolution-data-server-0:3.20.3-1.fc24.i686 evolution-data-server-0:3.20.3-1.fc24.x86_64 evolution-data-server-tests-0:3.20.2-1.fc24.i686 evolution-data-server-tests-0:3.20.2-1.fc24.x86_64 evolution-data-server-tests-0:3.20.3-1.fc24.i686 evolution-data-server-tests-0:3.20.3-1.fc24.x86_64 evolution-ews-0:3.20.2-1.fc24.i686 evolution-ews-0:3.20.2-1.fc24.x86_64 evolution-ews-0:3.20.3-1.fc24.x86_64 evolution-mapi-0:3.20.1-1.fc24.i686 evolution-mapi-0:3.20.1-1.fc24.x86_64 evolution-mapi-0:3.20.3-1.fc24.i686 evolution-mapi-0:3.20.3-1.fc24.x86_64 evolution-pst-0:3.20.2-1.fc24.x86_64 evolution-pst-0:3.20.3-1.fc24.x86_64 evolution-rss-1:0.3.95-7.fc24.x86_64 evolution-spamassassin-0:3.20.2-1.fc24.x86_64 evolution-spamassassin-0:3.20.3-1.fc24.x86_64 geary-0:0.11.0-1.fc24.x86_64 gnome-web-photo-0:0.10.5-9.fc24.x86_64 gphotoframe-0:2.0.2-2.hg2084299dffb6.fc24.1.noarch liferea-1:1.10.19-1.fc24.x86_64 rubygem-webkit-gtk-0:3.0.8-1.fc24.noarch seed-0:3.8.1-7.fc24.i686 seed-0:3.8.1-7.fc24.x86_64 sugar-browse-0:157.3-1.fc24.noarch surf-0:0.7-1.fc24.x86_64 uzbl-core-0:0-0.39.20120514git228bc38cbd.fc24.x86_64 vfrnav-0:20160212-3.fc24.i686 vfrnav-0:20160212-3.fc24.x86_64 webkitgtk3-devel-0:2.4.11-1.fc24.i686 webkitgtk3-devel-0:2.4.11-1.fc24.x86_64 webkitgtk3-doc-0:2.4.11-1.fc24.noarch wxGTK3-0:3.0.2-19.fc24.i686 wxGTK3-0:3.0.2-19.fc24.x86_64 xiphos-gtk3-0:4.0.4-3.fc24.x86_64 xiphos-gtk3-0:4.0.4-4.fc24.x86_64 -- devel mailing list devel@lists.fedoraproject.org https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
evolution-data-server soname version bump in rawhide the next week
Hi, the 3.21.3 release of evolution-data-server changes soname version for camel, due to some API changes in that sub-library. I will rebuild packages for which I have commit rights, the same as I can help with the API change fixes, thus feel free to ping me or drop an e-mail. I do not think that other than core Evolution packages will need more attention, others might be simply rebuild. Bye, Milan -- devel mailing list devel@lists.fedoraproject.org https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
evolution-data-server soname version bump in rawhide the next week
Hi, the 3.21.4 release of the evolution-data-server changes soname version for libcamel and libedataserver, due to some API changes in those sub-libraries. I will rebuild packages for which I have commit rights, the same as I can help with the API change fixes, thus feel free to ping me or drop an e-mail. I do not think that other than core Evolution packages will need more attention, others might be simply rebuild. Bye, Milan -- devel mailing list devel@lists.fedoraproject.org https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: Reviews Weekly
On Mon, 2016-09-12 at 14:26 +0200, Igor Gnatenko wrote: > > Javier Peña : 1 > Please fix unicode issues ;) Hi, it's because the related part claims: Content-Type: text/plain; charset="us-ascii" while using UTF-8 in the body. When I override the charset in the mail application I use, then it shows the umlauts and so on properly. Bye, Milan -- devel mailing list devel@lists.fedoraproject.org https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: GNOME 3.7.91
On Mon, 2013-03-04 at 15:18 +, Richard Hughes wrote: > If you're planning on doing a 3.7.91 build manually (i.e. that's not > picked up by mclazy, or one you'd rather do on your own), can you add > them to the spreadsheet please: > https://docs.google.com/spreadsheet/ccc?key=0AtzJKpbiGX1zdGJzeU9waFJFZmgyQzBuN2VxU0lxbHc > > This way we can QA and test the release and push it in one go. I'll > also be putting links to build failures on the same sheet. Thanks. Hi, is it branched already? My packages doesn't seem to be branched yet, thus no need for the giant update, only a rawhide build is done. Or, do you want to write them down regardless of branching for f19? Bye, Milan -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
evolution-data-server soname version bump
Hello, there will be done a 3.13.90 release of evolution-data-server the next week, February 16th, which has a soname version bump and contains some API changes along with that. I will rebuild packages for which I have commit rights, the same as provide patches where necessary. I already sent upstream patches for California [1], Folks [2], gnome-contacts[3] and gnome-calendar [4][5]. Bye, Milan [1] https://bugzilla.gnome.org/show_bug.cgi?id=743961 [2] https://bugzilla.gnome.org/show_bug.cgi?id=743934 [3] https://bugzilla.gnome.org/show_bug.cgi?id=743979 [4] https://bugzilla.gnome.org/show_bug.cgi?id=744050 [5] https://bugzilla.gnome.org/show_bug.cgi?id=744059 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Need help with gcc c++ issue
On Mon, 2015-02-16 at 16:40 +0100, Jakub Jelinek wrote: > On Mon, Feb 16, 2015 at 08:33:48AM -0700, Orion Poplawski wrote: > > Trying to build cmake, getting: > > In F23, all C++ packages need to be rebuilt, most likely you have a > dependency, that hasn't been rebuilt yet (libjsoncpp)? > So talk to the maintainer to rebuild it first. Hi, is there no mass rebuild planned? I get a similar error about a different symbol in a different application and library, which (the error) is quite confusing on its own. The mass rebuild makes more sense, from my point of view. I cannot see a reasonable way of asking various maintainers to rebuild their packages, whom may eventually ask another maintainers to rebuild their packages and so on, and get rawhide branch in shape within few days. I can be wrong, though. Bye, Milan -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Bug in reporting (was: Re: Fedora 26 Mass Rebuild)
On Tue, 2017-02-14 at 14:56 -0500, Mohan Boddu wrote: > Failures can be seen > http://dl.fedoraproject.org/pub/alt/mass-rebuild/f26-failures.html > > ... > > Please be sure to let releng know if you see any bugs in the > reporting. Hi, could you correct the reporting tool to write proper package maintainer/administrator when doing the report (link above), please? I'm mentioned in the list as: | mcrha (2): |ekiga |sflphone but I'm neither maintainer nor administrator of the both packages. I suppose it happened, because you picked the list of people with commit rights and sorted it alphabetically and then chose the first person in the list. It's wrong. At least in this case. Thanks and bye, Milan ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: thunderbird 45.7.1 and packer account
On Wed, 2017-02-22 at 13:08 +0100, tech...@dk-software.org wrote: > The error i become is "kinit dksoftw...@fedoraproject.org > kinit: Client 'dksoftw...@fedoraproject.org' not found in Kerberos > database while getting initial credentials" - can you fix it? Hi, I'm not the service/server admin, but I see one issue in your command. The domain name is case sensitive and should be in capitals, which means that's one obvious issue. Aka it should be: $ kinit dksoftw...@fedoraproject.org Hope it helps. Otherwise search Fedora Wiki pages, which contain good "how-to-setup kerberos" steps. Web search engines, like Google, are your friends. Bye, Milan ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Split translations to noarch packages?
Hello, I've got an idea and I'd like to know an opinion of a wider audience. Would it make sense to split translations from binary packages to a noarch subpackage? For example libreoffice does that already, it even splits the languages by country, which may or may not be applicable to other (larger) packages as well. What this could help with is a save of disk space on the build servers and mirrors. There might not be any significant difference for users, due to the main package would require the "langs" subpackage [*]. One may even avoid multilib issues on translation files (happened in the past for Evolution due to it removing unused translation strings during the build, to save package size). To give an example, I tried this with Evolution package and the result is that the langs subpackage is ~6MB large, while the main package is ~4MB large. Count that the languages are stored for each architecture, and koji builds for 6 of them at the moment, then the change of split means saving 30MB on disk for each single build of Evolution. When searching koji for Evolution packages then there had been done more than 70 builds since the first build for Fedora 24 (which is built for 3 arches only), which means more than 1GB on disk (roughly, counting 3 arches only). Multiply this by number of mirrors and so on. I know I can do this for packages I maintain, but I though it would make sense to think of it globally. Maybe? Bye, Milan [*] The only difference for users would be to not download languages again when installing two+ architectures in parallel, thus less data to download, thus only a benefit for them. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Split translations to noarch packages?
On Mon, 2017-04-24 at 08:18 -0400, Stephen Gallagher wrote: > If we went this route, I'd love to see us attempt to solve this > generically for all packages if at all possible. Hi, right, having this done transparently for the packagers would be ideal. You only need to decide from which build/architecture you'll compose that noarch package. Evolution package used to remove unused translated strings in the past, during the build. My main issue with libreoffice langpacks divided by country was that even I chose my mother language during installation of Fedora, that particular langpack wasn't installed, thus libreoffice was not localized to my mother language, though other parts, like GNOME Shell, were. This is few Fedora's back, on a machine which I keep updating, instead of installing from scratch, thus it's possible the behaviour changed meanwhile. I mean, maybe it doesn't make always sense to divide langpacks by country. Bye, Milan ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Split translations to noarch packages?
On Thu, 2017-04-27 at 13:31 +0200, David Tardon wrote: > There is a reason that libreoffice puts l10n data into separate > subpackages. Hi, yes, there is a very good reason for it and I'm not questioning that. libreoffice was just an example of a package which does that already, but also fails to do the right (or better "expected by me") thing, for which you gave a bug link. Thanks for it. As had been said in this thread, one approach doesn't work for all packages. I made it my way for the core evolution packages this morning for rawhide. There is only one langpacks subpackage. I looked also on syncevolution, because I've been curious, and the split translations package was around 90KB of size, thus it didn't make any sense to split the translations and I left syncevolution unchanged. That makes me think that there are these kinds of packages: a) without any translation - no changes for these b) with only a small translations - like syncevolution, split doesn't make sense c) with semi-large translations - packages, where split translations by language is less useful or impractical, thus one package with all languages is preferred/used d) with large translations - languages are that large that it's better to split the langpacks into per-language subpackages e) with large translations and additions - like libreoffice, translations split by language as well, but libreoffice also adds more dependencies to these translation packages (as you said). I did with evolution core packages what I thought is the best. I do not use weak dependencies, I define a hard dependency between the langpacks and the binary package, both ways, thus users get either both or none of them. That makes the change backward compatible, while still helping with disk usage on build servers and mirrors. One part of backward compatibility in this case is also related to d),e) above, where, for the way I made it, users can switch languages and they will have the UI translated without a need to install additional package(s). When starting this thread here, I did not intent to suggest any change on the build servers to do things automatically, I was more interested in ideas and opinions of other packagers. It would be nice to have these things done transparently, with minimal lines in RPM .spec file, but as there are a-b-c-d-e cases named above (and/or there can be found even more), then it makes it impractical. If this thread will lead to some "nice-to-have packaging guideline", then it would be welcome and more than I expected from it. > Btw, I'm not sure what do you mean by "divide langpacks by country". It's just a terminology. What I call "by country", other (more educated) folks call "by language/region/variant". Simply not-all-translations in one single subpackage. Thanks and bye, Milan ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Split translations to noarch packages?
Hi, On Thu, 2017-04-27 at 19:25 +, Tomasz Kłoczko wrote: > No generall agreement for such changes, ignoring already mentioned > arguments. > Seems only just because "we can". Nope, you are wrong. I gave clear explanation why I did so. Sure, some people, like you, might not like it. Okay, that happens. Different people has different point of view, different opinions, different priorities. In any way, the way you speak in this thread makes me just ignore you specifically, because you are not adding anything constructive. I'm sorry. That's just my opinion. Bye, Milan ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Split translations to noarch packages?
On Tue, 2017-04-25 at 13:10 +0200, Tomasz Kłoczko wrote: > So you guys want to say that you never heard that in %files is > possible to add %lang() tokens Hi, no, I never heard about that, though I'm not a good packager, thus it doesn't mean much. Though it can be because %lang() is way too complicated with compare of "Recommended method of handling i18n files" [1] as referenced from [2], which is significantly easier for packagers like me and which is used in evolution packages for years. Bye, Milan [1] https://fedoraproject.org/wiki/Packaging:Guidelines#Handling_Locale_Files [2] https://fedoraproject.org/wiki/How_to_create_an_RPM_package ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Killing koji buildjobs
On Fri, 2017-04-28 at 12:33 +0200, Ralf Corsepius wrote:
> These 2 build jobs (launched by me) seem to be hanging and don't seem
> to be wanting to finish (or fail) for 3 days (for reasons unknown to
> me):
Hi,
it looks like it got stuck after a failure in the tests. See the build
logs (tail is enough), where it says:
>> ../test-driver-ff: line 103: 21324 Aborted
>> (core dumped) ${TEST_FFPP} ${FLAGS_FFPP} "$@" > $log_file 2>&1
I didn't look into all build logs, but both i686 and aarch64 have this,
while x86_64 (which finished successfully) doesn't.
Bye,
Milan
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Split translations to noarch packages?
On Fri, 2017-04-28 at 21:09 +0200, Tomasz Kłoczko wrote: > Can you tell us something about those priorities Hi, I've been generally speaking. Your "priority" is obviously IPS. Mine not. Read the very first mail in this thread, to see my priorities and why I started it. > or maybe point to some URL where those priorities are listed? I do not have any. > I'm not like you RedHat employee so I have no idea about what you are > talking about. I see. I'm not talking for Red Hat, I'm talking for myself. > Did you ever try to use IPS? No. > Did you saw its source code or how it works? Neither this. I'm just an average packager. I thought I'll ask wider audience about an idea for something small and simple, nothing like changing packaging system, need a learn new tool or whatever, just something simple which can have interesting impact, but I didn't think I'll be punished for it, by you, this way. Again, I speak for myself. Anyway, this thread is over for me. Thank you for a valuable input. Have a nice weekend, Milan ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
rawhide evolution-data-server/libcamel soname version bump
Hello, I'm just updating evolution-data-server to 3.11.4 in rawhide, which includes a soname version bump for libcamel (it happened before 3.11.3, but that version didn't reach Fedora rawhide for some reason). I'll rebuild all affected packages I have commit rights for. Bye, Milan -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
rawhide evolution-data-server/libcamel soname version bump
Hello, I'm just updating evolution-data-server to 3.11.5 in rawhide, which includes a soname version bump for libcamel. I'm sorry for a late notice, this was meant to be sent the last week. I'll rebuild all affected packages I have commit rights for. Bye, Milan -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
evolution-data-server soname version bump in rawhide the next week
Hi, the 3.19.90 release of evolution-data-server changes soname version for camel, due to some API changes related to introspection support. I will rebuild packages for which I have commit rights, the same as I can help with the API change fixes, thus feel free to ping me or drop an e-mail. I do not think that other than core Evolution packages will need more attention, others might be simply rebuild. Bye, Milan -- devel mailing list devel@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: Issue rebuilding f24-build repo
On Tue, 2016-04-05 at 10:09 -0600, Kevin Fenzi wrote: > Hopefully there will be a longer term fix soon (either database > optimization or blocking some requests that are loading the db too > much). Hi, it's almost a week from this thread start and the database(?) is still slow. I just wanted to run a chain-build, which builds four packages, while the first two are built in serial, only then can be built the other two, and both f24 and rawhide waitrepo failed with: GenericError: Unsuccessfully waited 120:36 for evolution-data-server-3.20.1-1.fc25 to appear in the f25-build repo What is the usual time for the waitrepo to succeed these days, please? Is there any estimated time for the fix of the koji, thus it'll behave like earlier (on time) again, please? Thanks and bye, Milan -- devel mailing list devel@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: libsoup 2.54.0 accidental ABI break fixed in 2.54.1
On Wed, 2016-04-27 at 12:56 +0300, Alexander Bokovoy wrote: > For Fedora 24 beta I guess we are self-consistent but after beta > freeze is done we would need to rebuild everything depending on > libsoup, right? Hi, anything what subclasses from SoupAuthClass reduces the amount. It includes for example evolution-data-server (for e-soup-auth- bearer.h/.c) and evolution-ews (for e-soup-auth-negotiate.h/.c). While the usual claim is: GLib-GObject-WARNING **: specified class size for type 'ESoupAuthBearer' is smaller than the parent type's 'SoupAuth' class size (copied from https://bugzilla.gnome.org/show_bug.cgi?id=765222 ), I didn't get "size is bigger" when I used the updated libsoup in the F24, thus either the ABI check is faulty in the opposite case, or, more likely, it's not a problem (as subclasses can add items to the class, thus they can be larger). I do not know whether there is any way of searching source packages and their sources for the existence of SoupAuthClass string, even it would be helpful to check which packages to rebuild "just in case". There could also be some automatic way of checking the build.log-s, to see which packages were not build against libsoup 2.54.0(.x) and rebuild only them. That would help too. Rebuilding everything what requires libsoup, then transitively what requires those packages (the usage in the evolution-data-server is part of the public API) would mean a significant amount of packages to be rebuilt. Bye, Milan P.S.: The libsoup F24 update to 2.54.1 is filled here: https://bodhi.fedoraproject.org/updates/FEDORA-2016-f104225abc -- devel mailing list devel@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: libsoup 2.54.0 accidental ABI break fixed in 2.54.1
On Wed, 2016-04-27 at 09:01 -0500, Michael Catanzaro wrote: > Dunno a way to do this for Fedora, but Debian code search is probably > a pretty good approximation: > > https://codesearch.debian.net/results/SoupAuthClass/page_0 > > lazarus, soup-sharp, evolution-data-server, evolution-ews Hi, thanks, that sounds fine. I made a build root override for libsoup-2.54.1-1.fc24 with an expiration set on 2016-05-04 and I've prepared the evolution-data-server and evolution-ews to be rebuild against it once the $ koji wait-repo f24-build --build=libsoup-2.54.1-1.fc24 will succeed. I do not have commit rights for the lazarus, neither soup-sharp, thus someone else might step in and rebuild them against the updated libsoup too. I will add the two evolution-related packages into the libsoup update once the builds are done. https://bodhi.fedoraproject.org/updates/FEDORA-2016-f104225abc Bye, Milan -- devel mailing list devel@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
evolution-data-server soname version bump in rawhide with the 3.23.2 release
Hello, the 3.23.2 release of the evolution-data-server contains a soname version bump for libcamel, which contains many API backward incompatible changes. This had been done for easier introspectionability of the libcamel. Most of the affected modules are covered by upstream [1], where some will be either released together with the evolution-data-server or contain patches, which I'll backport to Fedora. As always, I'll rebuild the required modules for which I've commit rights. There should be made special attention about compiler warnings of those rebuilds, to catch any issues caused by the libcamel API changes (some builds do not stop when a symbol cannot be resolved, some do). In case you'd face any build (or runtime) issue, please let me know and I'll be happy to help to resolve it. I send this notice rather earlier. The upstream 3.23.2 release is currently planned for the November 21st, while the update will reach rawhide shortly after it. Thanks and bye, Milan [1] https://bugzilla.gnome.org/show_bug.cgi?id=764065#c24 ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: missing credentials
On Mon, 2016-12-12 at 12:43 -0600, Michael Catanzaro wrote: > That sounds highly plausible. evolution currently shells out to gpg > which is pretty fragile, so it's not very surprising that some issue > could cause it to hang forever. It needs to be rewritten to use > GPGME. Hi, I looked on GPGME sometime in the beginning of the year and it's missing some features the evolution(-data-server) uses. I do not recaal what exactly, I'm sorry. It's still just a front end for the gpg/ggp2 binary, thus basically the same what the evolution-data-server does. These things are run in a dedicated thread, thus they do not block the UI, only may result in an infinite wait for a response from the gpg/gpg2. It doesn't result in a timeout though. Being it about gpg/gpg2, I'd reference: https://bugzilla.gnome.org/show_bug.cgi?id=769204 Being it about WebKit2 usage as such (the 3.22.x uses WebKit2, while 3.20.x used WebKit1), I'd reference for example: https://bugzilla.redhat.com/show_bug.cgi?id=1398806#c2 Hope it helps, Milan ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: missing credentials
On Tue, 2016-12-13 at 10:08 -0800, Howard Howell wrote: > The first one GNOME Bugzilla – Bug 769204 says: > Status: RESOLVED NOTGNOME Hi, yes, that's correct, there was a problem in the gpg/gpg2, not in the evolution-data-server as such. Please read through it for some pointers into the gpg configuration. > The second one Bug 1398806 - Weird rendering for Evolution on > Wayland doesn't seem to apply. The exact comment suggests how to run the evolution, maybe just for testing. That problem comes so often that I wanted to suggest it here as well. It can be completely unrelated, of course. I would need a backtrace of the evolution to see what it tries to do. That's out of scope of this mailing list, thus better to file a bug and we can investigate there. > In the past when evolution blocked on gpg messages it was because I > didn't have the correct url to the cert for the sig or encryption. > could that still be the case here? Yes, it can. Just note that the "evolution stuck" is most likely a consequence of the gpg/gpg2 doing something (or waiting for something). > I have also noticed that now when I click reply, and then minimize > the evolution window, the reply no longer is interactive. This is > new behavior with F25 because I could do that with all prior versions > of fedora. But I suspect that some interaction with > wayland/evolution is the issue. I do not think so. See https://bugzilla.redhat.com/show_bug.cgi?id=1401239 which, by the way, references the change I suggested with the above bug link, which you claimed as "not to apply". Who knows. Bye, Milan ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Geany Plugins build fails due to missing webkigtk4 on aarch64/s390x - Need support
On Wed, 2020-04-08 at 21:18 +0200, Dominic Hopf via devel wrote:
> ```
> %if 0%{?rhel}
> BuildRequires: webkitgtk4-devel
> %else
> BuildRequires: webkit2gtk3-devel
> %endif
> ```
Hi,
this is an off topic for this thread, but maybe you'll find it useful.
You can use this (pick the one, which is truly needed, or both):
BuildRequires: pkgconfig(webkit2gtk-4.0)
BuildRequires: pkgconfig(webkit2gtk-web-extension-4.0)
and it'll work in all EPEL7, EPEL8 and Fedora. No need for conditionals
for the 'rhel' variable. This is how for example Evolution looks for
WebKitGTK+ development files. There was not needed any change in the
.spec file when the WebKitGTK+ package had been renamed.
Bye,
Milan
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Aarch64 build failure: hidden symbol `__aarch64_ldadd4_acq_rel' in /usr/lib/gcc/aarch64-redhat-linux/10/libgcc.a(ldadd_4_4.o) is referenced by DSO
On Sat, 2020-05-02 at 10:19 -0700, Kevin Fenzi wrote: > > As-is, everyone is blocking on waiting for the new gcc build to > complete > > (that koji estimates is another ~6 hours away). > > > > Personally, this morning was my primary chance to get a significant > amount > > of work done for the coming week... lost. :( > > I just untagged it. It should be out in the next newrepo. > > Sorry for not doing it sooner. Hi, out of the interest (no offense meant), would this not be caught by the rawhide gating? I'd expect that this is something what the rawhide gating would avoid. Of course, it expects reasonably good gating tests for the package(s), there's no doubt, but in this particular case, where hundreds of packages failed to build, even for a single architecture... I guess it would be a nice proof of concept for the rawhide gating, if caught by it. Bye, Milan ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Git Forge Requirements: Please see the Community Blog
On Wed, 2020-01-22 at 11:37 -0600, Michael Catanzaro wrote: > they all picked GitLab CE. Hi, I do not want to pollute this thread with unrelated information, but for what it worth, I only recently realized that GitLab CE, the one hosted on GNOME, does not have searching working properly. I filled a bug upstream [1]. Being able to reliably search in issues is rather essential function, from my point of view. I'm wondering how they can search for anything when they've filled 10k+ issues. Anyway, if you think this doesn't belong to this thread then I apologize. Bye, Milan [1] https://gitlab.com/gitlab-org/gitlab/issues/35611 ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Ideas for better development processes when maintaining hundreds of packages
On Tue, 2020-01-28 at 10:03 +0100, Richard W.M. Jones wrote: > * committing to git should build the package > > Is there a reason why this wouldn't be the case? Hi, the answer for the above is just your following point: > * commit groups of packages together aka the dependencies. Sometimes you want a special side tag, sometimes it's not needed. The way I do it right now (it's only about 4 packages depending on each other, not hundreds), is that I commit to master, then to stable, then the second package to master, to stable, then third and finally to the fourth and then I ran a chain-build as this: "a : b : c " in package 'd', (which builds 'c' and 'd' in parallel, once 'a' and 'b' are built in serial). Then I just refresh the koji build page from time to time and verify that the build still runs and/.or it finished successfully. I can run chain-build in stable too, it only needs a bit more intervention, to define overrides for 'a' and 'b' in bodhi, to be able to build them. I'm afraid fully automating such things might be a challenge. In other words, properly solving dependencies is problematic. Having yet another syntax to describe it, or the groups you suggest, scares me a bit. And we are not talking about inter-package dependencies, with packages you are not maintaining. Bye, Milan ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Unannounced soname bump with samba 4.12~rc1
On Sun, 2020-01-26 at 00:12 +0100, Fabio Valentini wrote: > - evolution-mapi > - openchange(-client) Hi, the above two are rebuilt too. Bye, Milan ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: PSA: Bodhi cannot associate bugs with updates right now
On Tue, 2019-02-19 at 18:32 -0500, Randy Barlow wrote: > Bodhi 3.13.2 has been deployed to production just now, which should > address the above issue. You should again be able to associate bugs > with updates. Apologies for the issue! Hi, I've been affected of this, even I didn't know what happened, because the web UI didn't show any error message or a clue what was wrong. The 'Submit' button just spin for few seconds and then nothing happened, which had been quite frustrating. Could the web UI be changed to claim all errors when it encounters any, instead of being just quiet and broken with no reason given? Thanks and bye, Milan ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
[heads-up] soname version bump for evolution-data-server in rawhide
Hello, next week's 3.33.2 release of evolution-data-server, on 2019-05-20, will contain soname version bumps in libecal, libedata-cal, libebook and libedata-book. At least unless anything bad happens. The main change on the calendar part is that there will be used libical-glib instead of libical, which allows automatic gobject introspection generation. That turned to be as significant change as it worth the calendar API change from version 1.2 to 2.0. The other change on the address book and the calendar parts was about adding a new argument into some methods, which touches both the C API and the D-Bus API, thus there is a version bump on the D-Bus service names as well. [1] Below is the list of affected packages in Fedora, divided into four sections: * Those, which require patching: almanah bijiben (aka gnome-notes) evolution evolution-ews evolution-mapi folks gnome-calendar gnome-shell gnome-todo libopensync libreoffice pidgin-chime syncevolution * Those, which require only rebuild: ekiga evolution-rspam evolution-rss glabels gnome-contacts gnome-phone-manager sflphone * Those, which require patching, but are already retired: california ffgtk * Those, which require work: elementary-calendar wingpanel-indicator-datetime Any existing patches can be found through [3], which contains also links to respective merge requests and bugs, filled to let know the maintainers beforehand. I will rebuild/apply patches to the packages I've commit rights for. I'd need help with others. Especially those two elementary-related packages won't work easily, because they use vala bindings, which they bundle in the sources, thus there is needed a lot of work. One of the elementary developers promised me to look on it once the eds is released. If you find more packages to be ported and you'd like to help with it, just let me know. Bye, Milan [1] This may cause trouble to Flatpak applications, which compile against some version of the evolution-data-server (eds) and then rely on the host system eds D-Bus services (that applies both ways, it won't help to compile against older eds, because the Flatpak application won't work on systems with the new eds). Such applications can run their own eds services, as shown here [2]. The advantage of it is to receive also backend-specific fixes in their Flatpak application, not only client-side fixes. The disadvantage is that the data won't be shared between the applications. [2] https://gitlab.gnome.org/GNOME/evolution/blob/master/flatpak/org.gnome.Evolution-stable.json#L258 [3] https://gitlab.gnome.org/GNOME/evolution-data-server/issues/33 ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: [HEADS UP] Unannounced soname bump of qrencode
Hi, On Wed, 2019-06-26 at 11:11 +0200, Miro Hrončok wrote: > $ rg -lF '.so*' rpm-specs/ | env LANG=en_US.utf8 sort > > rpm-specs/evolution.spec that's a false positive, the only occurrence of ".so*" in that file is in the %changelog section, namely: * Tue May 17 2011 x - 3.1.1-3 - Keep libevolution-mail-settings.so* from the previous change, it is still used by other parts of evolution. Just saying. Bye, Milan ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
[heads-up] soname version bump for evolution-data-server in rawhide
Hello, next week's 3.31.2 release of evolution-data-server (on 2018-11-12) will contain soname version bump of libedataserver due to removal of some semi-private API (e-gdbus-templates). I expect that most of the packages can be just rebuilt, because it was never meant to be used outside of evolution-data-server. According to: $ dnf repoquery --whatrequires pkgconfig\(libedataserver-1.2\) \ --alldeps --enablerepo=fedora-source the affected packages are: almanah elementary-calendar evolution folks gnome-calendar gnome-todo wingpanel-indicator-datetime I'll rebuild the packages I've commit rights for. Let me know if you face any issue with the other packages, I can help to correct it (which would be to copy the old code from eds, but I really do not expect anything using the e-gdbus-templates). Bye, Milan ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: [HEADS UP] Meson 0.48.0
On Tue, 2018-09-25 at 08:43 +0200, Igor Gnatenko wrote: > new meson release is out (release notes) which removes tools which > are deprecated for quite long time: > * mesonconf > * mesonintrospect > * mesontest > * wraptool Hi, having installed meson-0.48.1-1.fc29.noarch and trying to build geocode-glib 3.26.0 (the latest upstream release https://download.gnome.org/sources/geocode-glib/ as of now), it fails to build due to missing mesontest: = Building module geocode-glib in /home/user/fp/.flatpak- builder/build/geocode-glib-2 = ERROR: Command 'mesontest' not found > F28 and EPEL7 won't get update because of this incompatibility, > but if you need it for building updates -- let me know and I will > consider pushing it even there. From the above I believe you should not add this to the stable releases "if anyone needs it", unless you do some proof that it won't break more than the geocode-glib (and/or fix the breakage at the same time). I mean this just as a notice/confirmation that there are packages which can be broken with this change, as you pointed out. Bye, Milan ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: F39 Change Proposal: Flatpaks without Modules (System-Wide Change)
On Wed, 2023-05-10 at 11:54 +0100, Aoife Moloney wrote: > Additionally a couple of packages (evolution-data-services and > tracker-miners) are set up so they can be > built with an application-specific D-Bus prefix. Evolution has: > > buildopts: > rpms: > macros: | > %_eds_dbus_services_prefix org.gnome.Evolution > > This will need to be redone so that evolution-data-services doesn't > need recompilation > and the prefixing can be done by changing configuration files at > container build time. Hi, I cannot speak for the tracker-miners, but in case of the Evolution, it runs in its own sandbox, separated from the host system, with bundled evolution-data-server (eds) services, thus when the user installs the Flatpak version, he/she gets the expected Evolution and eds versions, independent of what the host system has installed. Advantage: the user gets all fixes, not only client-side (Evolution) fixes. It's important, from my point of view. > In many cases, this should consist of just a few minor changes to > container.yaml. Do you mean the `evolution.yaml` is gone with this change and the dependencies are taken directly from the .spec file? The eds dependency is a problem here, as you noted, not talking that not everything from the .spec file requires a rebuild for the flatpak (most dependencies are part of the runtime). Bye, Milan ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: F39 Change Proposal: Flatpaks without Modules (System-Wide Change)
On Wed, 2023-05-10 at 09:30 -0400, Owen Taylor wrote: > Does that sound workable? Are there better ways we could do it? Hi, if I recall correctly, using the custom D-Bus prefix is there to match application's D-Bus prefix defined for the flatpak, thus: a) the services run independently from the system, inside the sandbox; b) they can be started without any additional effort on the Flatpak configuration side (because the services share the app's D-Bus prefix). I briefly grepped the evolution-data-server sources and it seems that most of the places in the .c files can be changed in runtime, but there are places where the things can break, like the `evolution-data- server.pc` file or the D-Bus .service files, which both reference the D-Bus name from the compile time and those .service files are also named by the service (otherwise there's a runtime warning in the journal about the file not matching the service name). Those might not be show stoppers, I guess. By the way, when people install Evolution flatpak, they have preinstalled evolution-ews inside it. How will they install it after this change? Bye, Milan ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: F39 Change Proposal: Flatpaks without Modules (System-Wide Change)
Hi, On Wed, 2023-05-17 at 12:23 -0400, Owen Taylor wrote: > You use it in to fix bus names in flatpak-evolution-wrapper.sh - > those could just be hardcoded since the bus name will be always the > same for the Evolution Flatpak It will work unless the version of the D-Bus service is bumped for whatever reason. That's the only reason why the variables are part of the .pc file, to have correct D-Bus service name provided, not hard- coded. In any case, I understand these are not obstacles, not the big one, if the runtime change for the D-Bus service names will be possible. Feel free to file an upstream bug against the evolution-data-server, thus it's tracked (and not forgotten). Thanks and bye, Milan ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: updating cmark to 0.30
On Tue, 2023-01-17 at 13:55 +0800, Jens-Ulrik Petersen wrote: > So I plan to go ahead with this rebase and rebuilding these packages > after the mass rebuild if that's okay. Hi, does the new version change any API and/or soname version? > We can consider whether to backport to F37 and possibly F36 if needed > afterwards. I do not think you should change API/soname version in stable releases, that can lead to trouble (for example for 3rd-party packages). Bye, Milan ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
How to migrate database format during package update?
Hi, this is a query for an opinion and a best-practice experience for a case when a package needs to change its internal database format between versions, in an environment, which does not allow real migration, aka the app cannot read both formats, it can use one or the other. To be specific, the libdb package is going to be removed [1] sooner or later, and one of the packages which still use it is Bogofilter [2]. It's easy to just switch from libdb to SQLite in the .spec file, the problem is that the years of user's training of the Bogofilter spam/ham data would be lost by such change. The SQLite version cannot read the libdb data and vice versa (obviously), thus there needs to be done some manual migration by the users. The worst, the users may need to export their wordlist data before the update/upgrade and import it back after the update/upgrade. Also, when the bogofilter is run with the other format of the wordlist database, it simply errors out and expects manual intervention. It's also good, the old data is not completely lost, after all, and the user is aware something changed. My idea was to help the users with the migration in a way that the export of the libdb data could be done during the package update, in the %pre stage. A very nasty way I came with is to traverse the /home/ directories and if there exists the old database, then export it and rename the old file, thus the new bogofilter can run, even with an empty database. The thing is that the exported data is ready in such case, no need to downgrade the package or install old Fedora or any such thing just to recover the wordlist. It's the only advantage, while there are many disadvantages: - it's a nasty approach, the package should not touch users' home - it works only if the user uses the default/expected setting; saving the database into a different place voids this best-effort approach - the exported file is owned by root/admin, which requires change of the attributes thus the user can get rid of it - the package cannot tell to the user what to do next, to restore the exported data. I'm sure you might find more disadvantages, these are just the top four. That being said, any such change surely deserves release notes, with the commands what to do to export and then back import the wordlist. There should be filled a corresponding Change too, I guess. Still, how does other packages migrate their data, or at least help the users with the migration? Is there any way? Thanks and bye, Milan [1] https://bugzilla.redhat.com/show_bug.cgi?id=1778802 [2] https://bugzilla.redhat.com/show_bug.cgi?id=1788486 ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: How to migrate database format during package update?
On Wed, 2023-02-01 at 14:15 +0100, Alexander Sosedkin wrote: > cyrus-sasl ships a migration tool for some transition period > and suggests the user to manually invoke it: Hi, aha, I see, that's much saner idea than what I came up with. I'll try to cook something similar, making the libdb(-static) dependency optional (no migration tool without it). Thanks and bye, Milan ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: How to migrate database format during package update?
On Wed, 2023-02-01 at 10:12 -0800, Kevin Fenzi wrote: > Is there any way to pull the functionaly into the process itself? > ie, the first time it's called, it converts the db? Hi, the idea is to not depend on the libdb at all, neither in the build time. I reworked the proposed change to conditionally (in the .spec file) build the migration tool using static libdb, thus no pull in of the libdb package itself. Something similar is used in the cyrus-sasl Alexander pointed me to. It's much cleaner solution and it also lefts everything under the user's control, which is for good. I do not think there can be done the conversion on-the-fly, the bogofilter is build with one or other DB engine, not with multiple. Having wrapper scripts to convert the format is something I'd like to avoid. Thanks and bye, Milan ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Disabling rawhide builds during branching
On Tue, 2023-08-08 at 00:08 -0700, Adam Williamson wrote: > I'm not sure what's causing that, but it doesn't look good. Hi, would it be possible to somehow detect the "More Information" button on the screen and click it before calling the test failed, which will open a dialog with an error returned by the PackageKit (in this case), thus giving a clue what failed, please? Bye, Milan ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: appstream soname bump in Rawhide (special info for AppStreamQt users!)
On Mon, 2023-11-06 at 22:33 -0500, Neal Gompa wrote: > * Flatpak has an upstream change that needs backporting[1] or a new > release. > * GNOME Software has a merge request open[2]. > * libadwaita has an upstream change that needs backporting[3]. > * malcontent needs work done. Hi, I'm sorry for a late response, I forgot of this. I tried to build gnome-software in your side tag, but it fails due to the appstream packages cannot be installed together: Error: Transaction test error: DEBUG util.py:446:file /usr/lib64/girepository-1.0/AppStream- 1.0.typelib conflicts between attempted installs of appstream0.16- 0.16.3-1.fc40.x86_64 and appstream-1.0.0~git20231102.d88ed03- 1.fc40.x86_64 Thus I guess the dependencies need to be built in certain order, to not pull in old and new appstream packages or there's some problem with packaging of the two. Bye, Milan ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: appstream soname bump in Rawhide (special info for AppStreamQt users!)
On Tue, 2023-11-07 at 12:12 +0100, Kalev Lember wrote: > Can you do 'koji wait-repo f40-build-side-76936 --build > appstream0.16-0.16.3-2.fc40' and try building gnome-software again > once it says that the package is available in the repo? Hi, it changed the problem to: DEBUG util.py:446: Error: DEBUG util.py:446: Problem: package flatpak-devel-1.15.4-4.fc40.x86_64 from build requires flatpak(x86-64) = 1.15.4-4.fc40, but none of the providers can be installed DEBUG util.py:446:- conflicting requests DEBUG util.py:446:- nothing provides appstream(x86-64) >= 1.0.0 needed by flatpak-1.15.4-4.fc40.x86_64 from build You can see the build here: https://koji.fedoraproject.org/koji/taskinfo?taskID=108705408 Bye, Milan ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: appstream soname bump in Rawhide (special info for AppStreamQt users!)
On Tue, 2023-11-07 at 10:58 -0500, Neal Gompa wrote:
> It needs to be "appstream%{?_isa} >= 1.0.0~".
Hi,
I'm sorry, I do not follow. Do you mean "1.0.0" is higher than
"1.0.0~git20231102.d88ed03-1.fc40", but lower than "1.0.0-2.fc40"?
That sounds odd to me.
Both flatpak and gnome-software have
Requires: appstream%{?_isa} >= %{appstream_version}
adding the tilde only here and not into:
BuildRequires: pkgconfig(appstream) >= %{appstream_version}
will lead to a problem in the future (at least for me, I'll forget
about it very soon).
What about removing that `Requires`? There is added un-versioned
dependency on libappstream.so.5()(64bit) anyway, which may work, as
long as the .soname versions are properly bumped on API/ABI changes,
right? I understand these `Requires` as "to be on a safe side" only.
Bye,
Milan
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it:
https://pagure.io/fedora-infrastructure/new_issue
