Debarshi's den - দেবর্ষির ডেড়া

Debarshi's posts with tag: gsoc

What are tags? You can give your posts a "tag", which is like a keyword. Tags help you find content which has something in common. You can assign as many tags as you wish to each post.
View posts by people in your network with tag gsoc
Blog EntryGSoC gibberishApr 19, '08 9:08 AM
for everyone

Even though I had experienced some weird developements myself last year, it had somehow ended on a happy note. However this one seems a bit too much to fathom.

All along I had believed that past credentials as a contributor is an ace up your sleeve when it comes to Google Summer of Code selections. Favouring someone because their only motivation to contribute is $4500, and downgrading an existing contributor because they will "anyway continue to do good work" is the kind of distorted thinking that I like to hate.


Blog EntryOpyum: second stable release (version 0.0.3)Oct 26, '07 6:26 PM
for everyone

I hereby announce the second stable release of Opyum, the Fedora Offline Package Manager, version 0.0.3.

Opyum (pronounced 'opium') provides a set of tools to enable users, who do not have a good network (eg., Internet) connection at their ready disposal, to easily install new packages or update existing ones through the conventional package management system available in Fedora.

Tar ball: http://rishi.fedorapeople.org/opyum/opyum-0.0.3.tar.gz
MD5SUM: 693bc38845aaef5ecf599d7564483f09
SHA1SUM: c21186d6b1f31ff8e7a4b9b9fa57dba74f12adae

New features:
Installing or updating from Yum-Packs is easier now with the introduction of system-install-yumpacks. Apart from that, there is a new repository manager to let users to add, remove, edit, enable and disable repositories.

Installation instructions:
# yum install opyum

Documentation page:
https://fedoraproject.org/wiki/DebarshiRay/Opyum

Project page:
https://hosted.fedoraproject.org/projects/opyum/

Bug reports:
https://bugzilla.redhat.com/


Blog EntryOpyum: first stable release (version 0.0.2)Aug 19, '07 10:10 AM
for everyone

I hereby announce the first stable release of Opyum, the Fedora Offline Package Manager, version 0.0.2.

Opyum (pronounced 'opium') provides a set of tools to enable users, who do not have a good network (eg., Internet) connection at their ready disposal, to easily install new packages or update existing ones through the conventional package management system available in Fedora.

If you are interested then you can read more about it at https://fedoraproject.org/wiki/SummerOfCode/2007/DebarshiRay.

Tar ball: http://rishi.fedorapeople.org/opyum/opyum-0.0.2.tar.gz
MD5SUM: 299873e5d0b4d762a261edb6b9bc62e6
SHA1SUM: ac50ec4a048a4db55c4bbf2d4a2419ff492f70ad

Pre-requisites: pirut-1.3.11

Documentation page: https://fedoraproject.org/wiki/DebarshiRay/Opyum.

Release notes are in NEWS in the release tarball.

Instructions on using Opyum are in the README in the release tarball.

Installation instructions:
1. $ tar -xzvf opyum-0.0.2.tar.gz
2. $ cd opyum-0.0.2
3. $ ./configure --prefix=/usr
   (Other prefixes are not expected to work. Please bear with it for the moment.)
4. $ make
5. # make install

Execution instructions:1. $ LANG=en_US.UTF-8 opyum
   (There is a bug involving Python and Pirut, which may cause the program to crash on localized desktops. See https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=252136)

Bug-reports and comments are to be sent to rishi@fedoraproject.org.


Blog EntryOpyum: Git repositoryAug 15, '07 5:11 PM
for everyone

Opyum (https://fedoraproject.org/wiki/DebarshiRay/Opyum) is now hosted at https://hosted.fedoraproject.org/projects/opyum.

To access the GIT repository use:

If you have write access:
   $ git clone ssh://git.fedoraproject.org/git/hosted/opyum

Otherwise:
   $ git clone git://git.fedoraproject.org/git/hosted/opyum

The last stable release (version 0.0.1) is at http://rishi.fedorapeople.org/rum-0.0.1.tar.gz. Please note that all future releases will be named: opyum-<version>.tar.gz. You may send bug reports to rishi@fedoraproject.org or debarshi.ray@gmail.com.


Blog EntryOffline Package Manager for Fedora -- Part 4Jul 22, '07 9:26 PM
for everyone

I have modified the initial design for the "Manage Repositories" (Edit->Repositories) dialog according to suggestions from Jeremy Katz and others on fedora-devel-list@redhat.com.

The "Authentication" tab is now gone, since it was felt that key management was a repository-specific activity and not a top-level one.The "Save changes to disk" option, which allows you to switch between Yum's --enablerepo/--disablerepo functionality and actually modifying the repository configuration files on the disk, has now been hidden away inside an "Advanced options" drop-down menu since most users would not need to bother about it anyway. Adding a CD-ROM/DVD as a repository is no different than adding any other standard repository, so it would be now be offered as one of the presets in the "Add" dialog.

Comments?


Blog Entry Offline Package Manager for Fedora -- Part 3Jul 18, '07 5:19 PM
for everyone

The first beta release, version 0.0.1, is now available from http://rishi.fedorapeople.org/rum-0.0.1.tar.gz.  This is meant to be a low-grade high-quality release, where I want to ensure that the basic set of features is in working order.

Right now it does two things:
(a) Profile management-- export, import and deletion of profiles.
(b) YumPack creation.

You can read the documentation at https://fedoraproject.org/wiki/DebarshiRay/rum.


Blog Entry Offline Package Manager for Fedora -- Part 2Jul 8, '07 10:46 AM
for everyone

After looking at some existing alternatives-- Repoman, Synaptic and some mock-ups designed by Damien Duran and Thomas Canniot, and fiddling with Glade for a week, I have finally settled upon the initial design for the "Manage Repositories" (Edit -> Repositories) dialog.

The design is heavily based on Synaptic's, since it is the best GUI package management tool I have seen. A point to be noticed is the "Save changes to disk" check button. The idea is to provide the user with the choice of whether to modify the configuration files and make the changes persistent, or to effect the changes only for one instance of the application. The "authentication" tab is going to be used to manage the Public keys of the repositories.

Since Pirut lacks an interface to configure the repositories, I would like to contribute this to Pirut as well.

Comments?


Blog EntryOffline Package Manager for Fedora -- Part 1Jul 5, '07 1:15 AM
for everyone

For the past few months I have been working on a so-called "offline package management tool" for Fedora. The basic idea behind this tool has been laid out in the proposal I had submitted for Google Summer of Code 2007. Hence I shall desist from repeating what has already been said.

Two command line prototypes down the line, the final GUI application is finally taking shape. Now would be a good time to pause, step back and evaluate and let the world know what has been going on. In fact there has been a lot of criticism about the lack of publicly available information about the current state of affairs.

Unlike the previous command line prototypes, the GUI version does not import the YUM modules directly. It uses the core Pirut modules, which are in turn based on the YUM API, to do most of the work. The GUI interface is also based on Pirut's, with the necessary extra components separately designed for the offline counterpart.

These decisions resulted from my desire to merge with Pirut at some point of time. Whether that will ultimately happen is something I can not guarantee right now. It depends on what the Fedora community, especially Jeremy Katz (Pirut maintainer), think of it.

However the Pirut modules hide away many of the reconfigurability options offered by the underlying YUM API. eg., one could not change the 'installroot', and there was no way you could just download the packages and not install them. This has now been fixed by a patch against Pirut 1.3.7, and will be available to the public once Pirut 1.3.9 gets released.


The next objective was to incorporate the extra GUI bits into the existing Pirut interface that would be required by the offline manager to carry out its activities. eg., interfaces to import & export profiles and other profile management activities, installation from a selected yumpack, etc..

As of now the profile management interfaces have been designed, and their callback methods integrated into the code base.

These include modifications to 'file' and 'edit' menus; a couple of instances of gtk.FileChooserDialog to handle the selection of profiles to be imported or exported; progress bars to track the import & export activity; and an all-purpose dialog to manage the profiles.

It has been one of my personal grudges against YUM and Pirut that they do not provide any interface to modify the yum.conf and *.repo files. Pirut is even worse. It does not even provide a GUI counterpart to YUM's --enablerepo and --disablerepo command line options. Funnily there exists a number of stand alone GUI and CLI applications which do offer such functionality. eg.. system-config-repo, repoman, yumex (GUI tools), and the Red Carpet User tool interface to YUM (CLI tool).

Jeremy Katz is game for including such a feature in Pirut, but the best way to do it would be to put in the file handling infrastructure in the YUM API so that yet another tool need not reinvent the wheel to do the job. A patch is already doing the rounds in the yum-devel list, while the GUI part of it is slowing taking shape.

I am keeping my fingers crossed for the time being, and awaiting any feedback that you may have.


Blog EntryFiasco: beginning of the end.Apr 12, '07 3:02 PM
for everyone
I just received a mail from David Cantrell. Among other things he has explained his side of the story, and apologized for his role in the events leading up to this post.

It is nice to be friends with David again, and I am looking forward to continuing to working with him towards making Parted a better program.

Blog EntryCongrats...Apr 10, '07 7:29 PM
for everyone
...to Rakesh on taking my place on the GNU Project's list of accepted proposals. A hearty thanks to Google to expanding GNU Project's number of slots to 9 from 8, enabling one more student after Rakesh to qualify.

It was hearty to see GNU make these adjustments in the most reasonable and efficient manner with the least amount of noise generated as compared to some other organizations. Who said GNU is ruled by fanatics?

Thank you RMS, Karl Berry, James Youngman, Chris di Bona and Leslie Hawthorne.

Blog Entry'F' for Fedora, 'F' for Free. Or is it fiasco?Apr 10, '07 5:10 PM
for everyone
Google is organizing Summer of Code again this year, and The Fedora Project is again participating as a mentor organization. However the problem is that they do not deserve to be chosen as one. Simply because they do not have mentors who can dedicate sufficient time for it, and the project administrator, Patrick Barnes, is either crazy or incompetent.

Before I go any further, let me tell you that I am going to be extremely mordant in my criticism here. If you have any problems, then please note that I do not give a damn as to who you are and what you think. Just get lost.

The story revolves around two of my Summer of Code proposals-- one for GNU Parted (http://glug-nith.org/~rishi/download/soc/soc-proposal-parted) and the other for Fedora (http://glug-nith.org/~rishi/download/soc/soc-proposal-fedora-offline).

From the discussions going on in the summer-of-code@gnu.org mailing list I could see that an application for Parted, whose title was very similar to mine, had made it to the final list list of 8 applications chosen by the GNU Project's GSoC co-administrator Karl Berry. However since they never took my name, and my supposed mentor, David Cantrell, never mentioned anything on the list (he did criticise the FSF for not giving the $500 to the mentor without considering that it was Google who decided to give it to the FSF) nor posted a public comment, as opposed to the other mentors who were actively backing and debating the pros and cons of their students, there was no way I could know. Ofcourse I could have asked some GNU mentor, but I did not do that. If the web application did not permit a student to know the rankings, then so be it.

At the same time there was complete silence from Fedora. No traffic on the fedora-mentors mailing list, no one seemed to know how many slots it had bagged, no reply to my repeated requests for comment (one of them is this) on the various mailing lists, apart from a conversation on #fedora-unity where people termed my proposal to be too trivial to be accepted. So I was all set to give up hope on this front, had it not been for Sankarshan Mukhopadhyay and Runa Bhattacharjee who somehow saw some sense in the proposal.

The April 11 deadline was coming nearer, and I was becoming increasingly sad to see Rakesh's proposal for GNOWSYS getting stuck at the 9th position for GNU Project. GNU Project had 8 slots and his only chance was if some higher ranked application got cancelled due to a conflict. One of the GNOWSYS mentors confirmed to Rakesh that the Parted application which had been chosen was indeed mine. That is when I poked Sankarshan Mukhopadhyay, a Fedora mentor, about the status of my proposal. If by some miracle I got accepted in Fedora, then my slot in GNU could be taken by Rakesh.

I was not prepared for the serious of surprises and shocks that ensued.

First of all not only did I have a chance, my application was one of the top 6 in Fedora and was almost sure of making it. The strangest part is that the GNU folks had no idea about this impending conflict. I had seen the GNU mentors sort out conflicts with other organizations (eg., Subversion & GCC) on their list, but why did not anyone know about this clash with Fedora? Even more strange because David Cantrell, my mentor for GNU Parted, is also an employee at Red Hat, and most of the Fedora mentors are his colleagues.

After a couple of frantic phone calls to Dr. Nagarjuna G., Rakesh's mentor for GNOWSYS, and an IRC conversation with Sankarshan Mukhopadhyay I decided to let the GNU and Fedora people know about this impending collision. Here is the one I sent to GNU, and here is the one I sent to Fedora. Obviously this was something the mentors and project administrators were supposed to do, since the student had no legitimate way of looking at the rankings till the final results were announced. But what can you do when a deserving candidate who is your good friend stands to lose due to the gross incompetence of others?

All seemed set for me to join Fedora, and Rakesh to get into GNU, but his was the suprise part. The shock was yet to come.

Suddenly Patrick Barnes and David Cantrell pinged me on #fedora-mentors. David is pissed off as if I had betrayed him by not telling him about my Pirut application before. In fact he thought I had wasted his time, and such things. What the hell? How was I supposed to know about the conflict if Sankarshan Mukhopadhyay had not broken the rules to reveal a vague idea of my status? Being a Red Hat employee is David not in the ideal position to know these things? Are not the mentors supposed to resolve the conflicts? And talking about David's time being wasted, he had not even officially intimated the GNU admins about his willingness to mentor me for Parted. It was only after James Youngman (a GNU co-administrator), followed by me, poked him that he did so. I have already talked about the lack of anything relevant from David that was visible to me. So where from does he get the right to be pissed off? Am I not the one who should be pissed off?

At the same time, Patrick announces Sankarshan Mukhopadhyay as my mentor. Patrick claims to be fully aware of the clash with GNU and says that if I had not mailed them (remember the circumstances leading to the mail were quite coincidental) they would have quietly let go of my Fedora proposal. What the hell? Are they not supposed to discuss this clearly and openly? What do they mean by silently letting the application slip off? Could they not have atleast asked me? So should not David be pissed off with Patrick and not me? Or is it too difficult for him to confront his co-developer on the Fedora Project?

Patrick went on to advice me to talk to Jeremy Katz about my proposal. Why the hell should I do that 36 hours before the results are to appear, when he never replied to my repeated mails so many days back? What is left to discuss with him? Or why would I even do so, even if he is the Pirut maintainer? Apparently Jeremy is very busy and can not read the fedora-devel-list in its entirety, and does not read fedora-mentors-list at all. No wonder Pirut sucks so badly.

But why is a student supposed to know all these details? There was not a single public comment or mail from the Fedora mentors in this regard till date. Now that I go out of my to make their life easier, they start asking me to talk to all sorts of people. Why could not they ask me to do this earlier? Were they blind, or were busy shoving their noses into the shithole? I have never seen such a situation in GNU, except David Cantrell, but then he is again more inclined towards Red Hat and Fedora than GNU.

The craziest part is that both Patrick and David fail to appreciate my efforts to resolve the conflict on my own initiative, something which they as mentors were supposed to do. In contrast there has been no such vindictiveness on the part of Karl Berry or James Youngman.

So is The Fedora Project really interested in Google Summer of Code 2007? Is The Fedora Project really keen to attracting new developers from the community? Should Patrick W. Barnes be allowed to be the administrator for next year's Summer of Code?

My answer to these three questions is a resounding no.

© 2008 Multiply, Inc.    About · Blog · Terms · Privacy · Corp Info · Contact Us · Help