Re: Quick update on git-dpm migration script
Further updates: I used my sprint time at PyCon.ZA to poke at the migration. I was lucky enough to have Gary van der Merwe, with deep VCS experience, get involved, and we made some significant progress. http://anonscm.debian.org/cgit/users/stefanor/dpmt-migration.git/ svn2git.py Takes the SVN repository, and spits out a billion git ones. If you want to run it, you can find dumps of the svn repo in my home dir on alioth. I recommend loading the dump in /dev/shm (and putting the git repos there, too). Gary figured out how to de-octopus all the svn-buildpackage tags, to create a linearish history. (svn-buildpackage tags by copying your working directory to the remote, meaning different directories can be at different revisions, and the tag has multiple ancestors) We determined that my unhappyness with git-dpm history (the debian directory appearing from scratch on after every upstream merge, rather than having a useful history) is the result of a bug in git-dpm's import code, it's missing a parent link between these commits. But we didn't find where the bug is (or write a detailed bug report). Right now, we're not trying to convert to dpm, but just to svn-buildpackage style (which is simpler). https://bugs.debian.org/720448 means that history isn't round-trippable through dpm, without adding noise. This probably wouldn't go down well with the release team when preparing stable package updates for before the migration. The next step (which Gary is working on) is to start combining the imported-from-svn tree with an imported-from-dscs tree, so that we have full source packages, with all the svn history. I'm busy paying down all the technical debt we took on in the svn2git rules, to get the conversion running in a hurry. We need to capture all the branches, to have less disconnected tags in the repos. > I took a look at Stefano's dpmt-migration branch. His code is working at a > different level than mine; whereas I am working on single package imports, > he's looking at doing the full migration of all DPMT and PAPT packages. We'll > need that whenever we flip the switch. This might have been a bad approach (on my side). To perfectly migrate all repos, we may have to do multiple runs (with individual rules files) rather than one all-in-one migration. The reason for that is that svn2git only writes each svn change to 1 git-repo. It can't understand that repos will fork from each other later, and changes must be written to both, until then. (e.g. beautifulsoup gets copied to beautifulsoup4, but both are still in the archive) We could also deal with that situation by running svn2git for n revisions, copying git repos, then running another m revisions, etc. SR -- Stefano Rivera http://tumbleweed.org.za/ +1 415 683 3272 signature.asc Description: Digital signature
pyrenamer gives 'Attempt to unlock mutex that was not locked'
hello, Pyrenamer fails to run on my Sid uo-to-date system: # pyrenamer (pyrenamer:6163): Gtk-WARNING **: GtkSpinButton: setting an adjustment with non-zero page size is deprecated (pyrenamer:6163): Gtk-WARNING **: GtkSpinButton: setting an adjustment with non-zero page size is deprecated (pyrenamer:6163): Gtk-WARNING **: GtkSpinButton: setting an adjustment with non-zero page size is deprecated Attempt to unlock mutex that was not locked Aborted Any idea why? reportbug gives also "Attempt to unlock mutex that was not locked Aborted" Thanks! -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20141006141502.68a02d33@fx4100
Re: pyrenamer gives 'Attempt to unlock mutex that was not locked'
Hi all, please find my approach to resolving the issue of "Attempt to unlock mutex that was not locked" in the quoted emails below. The short answer is that this error is caused by improper use of glib threading. Such handling may have remained unnoticed up until now due to changes in the recent glib (2.42). Debian unstable/testing has been migrating from version 2.40 to 2.42 which is now causing this message in several codes. Best regards Torsten Original Message Subject: Re: Threading in pdfshuffler Date: Sun, 05 Oct 2014 22:19:40 +0200 From: Thilo To: Jeremy Lainé Hi Jeremy, thanks for your immediate reply! I went deeper into this issue and found the following: A generally useful introduction and usage examples are given at [1]. However, GObject (Gdk3) and Gtk2 are not clearly distinguished and so this does not provide a satisfying answer on how to proceed in the case at hand. Reference [2] gives practical guidelines on how one should write (new) code. Keeping these in mind, the Gdk3 --and this is what we are using when importing gobject as Kostas does in the code of pdfshuffler- documentation gives further insight [3]: > You should use gdk_threads_add_idle() and gdk_threads_add_timeout() instead > of g_idle_add() and g_timeout_add() since libraries not under your control > might be using the deprecated GDK locking mechanism. If you are sure that > none of the code in your application and libraries use the deprecated > gdk_threads_enter() or gdk_threads_leave() methods, then you can safely use > g_idle_add() and g_timeout_add(). Considering that the original author (Kostas) already utilizes GObject by means of function calls such as "gobject.idle_add()" instead of "gdk_threads_add_idle()", I think that we are better off to entirely remove the deprecated calls to "gtk.gdk.threads_init()" and related functions. Regarding your changes in the "update_thumbnail" method, I support your view. I uploaded an updated version of the code at [4] (I updated "changelog.debian", too). However, as I am still trying to understand Debian packaging I haven't created a package yet. I see two possibilities of how to proceed right now: (i) you could grab the files * pdfshuffler/pdfshuffler.py and * changelog.debian and build a new package or (ii) you wait for me packaging it and possibly answer some questions on the procedure in the meantime.. ;-) Feel free to forward this email to the PAPT-list. I haven't joined yet and since reportbug is broken as well, I don't feel like submitting the bug report myself at the moment.. Best regards Torsten [1] https://wiki.gnome.org/Projects/PyGObject/Threading [2] http://stackoverflow.com/a/21156816/3043824 [3] https://developer.gnome.org/gdk3/stable/gdk3-Threads.html [4] https://github.com/fuesika/pdfshuffler-ng On 05.10.2014 10:09, Jeremy Lainé wrote: > Hi Torsten, > > I won't pretend I am a GTK expert - I most certainly am not, I am > usually a Qt person - so it was basically trial and error, up-to-date > GTK on the topic are pretty confusing. I basically drew inspiration from > the bug report against "reportbug" which suffered from the same startup > error. I had not considered your option for the main loop which seems > even better since it avoids calls to the deprecated methods. > > I still believe the gdk_threads_enter/leave can be removed in the > "update_thumbnail" method as we are not actually calling any GDK code here. > > Cheers, > Jeremy > > On 10/05/2014 02:40 AM, fuesika wrote: >> Dear Jeremy, >> >> please find an e-mail below that I sent to the original author >> pdfshuffler. I was working on a bugfix at the time that you provided it >> via the repositories. Thanks for submitting! >> >> Looking at the source, I am still wondering what the originally intended >> threading behavior is (no answer from Kostas, yet). >> While my approach entirely removed the (explicit) gtk2-threading --could >> and should remove the gobject/gtk3-threading as well if I understand the >> glib-documentation correctly-- you set the entire program up as a >> threads-section which prevents any multi-threading. >> >> I am still trying to fully grasp the threading of glib and this is the >> reason why I am writing to you. What are the reasons for your approach? >> Aren't the commands "gtk.gdf.threads_init()" et al. obsolete since glib >> 2.22? >> >> Best regards >> Torsten >> >> >> Original Message >> Subject: Threading in pdfshuffler >> Date: Fri, 03 Oct 2014 14:51:33 +0200 >> To: Kostas >> >> Dear Kostas, >> >> through a Debian update a few minutes ago, I became of the (partly >> deprecated) threading lines in the code pdf-shuffler. The version from >> sourceforge states >>> def main(): >>> """This function starts PdfShuffler""" >>> gtk.gdk.threads_init() >>> gobject.threads_init() >>> PdfShuffler() >>> gtk.main() >> What I though that is appropriate (removing the multi-threading): >>> def main(): >>> """This func
Re: pyrenamer gives 'Attempt to unlock mutex that was not locked'
On Mon, 06 Oct 2014 14:19:55 +0200 Thilo wrote: > Hi all, > > please find my approach to resolving the issue of "Attempt to unlock > mutex that was not locked" in the quoted emails below. The short > answer is that this error is caused by improper use of glib > threading. Such handling may have remained unnoticed up until now due > to changes in the recent glib (2.42). Debian unstable/testing has > been migrating from version 2.40 to 2.42 which is now causing this > message in several codes. > > Best regards > Torsten Thanks for your quick answer. I guess I have to wait for a solution in Sid. I will check on a daily basis. -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20141006152446.5b96e0f0@fx4100
Re: Quick update on git-dpm migration script
On 10/06/2014 03:24 PM, Stefano Rivera wrote: > Further updates: > > I used my sprint time at PyCon.ZA to poke at the migration. > I was lucky enough to have Gary van der Merwe, with deep VCS experience, > get involved, and we made some significant progress. > > http://anonscm.debian.org/cgit/users/stefanor/dpmt-migration.git/ > > svn2git.py Takes the SVN repository, and spits out a billion git ones. > > If you want to run it, you can find dumps of the svn repo in my home dir > on alioth. I recommend loading the dump in /dev/shm (and putting the git > repos there, too). > > Gary figured out how to de-octopus all the svn-buildpackage tags, to > create a linearish history. > > (svn-buildpackage tags by copying your working directory to the remote, > meaning different directories can be at different revisions, and the tag > has multiple ancestors) > > We determined that my unhappyness with git-dpm history (the debian > directory appearing from scratch on after every upstream merge, rather > than having a useful history) is the result of a bug in git-dpm's import > code, it's missing a parent link between these commits. But we didn't > find where the bug is (or write a detailed bug report). > > Right now, we're not trying to convert to dpm, but just to > svn-buildpackage style (which is simpler). > > https://bugs.debian.org/720448 means that history isn't round-trippable > through dpm, without adding noise. This probably wouldn't go down well > with the release team when preparing stable package updates for before > the migration. > > The next step (which Gary is working on) is to start combining the > imported-from-svn tree with an imported-from-dscs tree, so that we have > full source packages, with all the svn history. > > I'm busy paying down all the technical debt we took on in the svn2git > rules, to get the conversion running in a hurry. We need to capture all > the branches, to have less disconnected tags in the repos. > >> I took a look at Stefano's dpmt-migration branch. His code is working at a >> different level than mine; whereas I am working on single package imports, >> he's looking at doing the full migration of all DPMT and PAPT packages. >> We'll >> need that whenever we flip the switch. > > This might have been a bad approach (on my side). To perfectly migrate > all repos, we may have to do multiple runs (with individual rules files) > rather than one all-in-one migration. The reason for that is that > svn2git only writes each svn change to 1 git-repo. It can't understand > that repos will fork from each other later, and changes must be written > to both, until then. (e.g. beautifulsoup gets copied to beautifulsoup4, > but both are still in the archive) > > We could also deal with that situation by running svn2git for n > revisions, copying git repos, then running another m revisions, etc. > > SR Thanks a lot to all of you for working on this. Thomas -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/5432ab1d.4020...@debian.org
