"port migrate" status

[Umesh Singla]

Hi macports-dev,

We have made some progress on the migrate project during the MacPorts
Meeting last week in Slovenia. To give background, it was started as one of
the Google Summer of Code projects in 2017. More details can be found here
[1].

The current state is you can use the migrate command but you may experience
some hiccups. We tried it on two machines (10.12 to 10.14, 10.13 to 10.14)
and we had problems with:
- older Xcode version, so a reminder to upgrade Xcode (?) and Xcode-CLT
would be nice.
- build dependencies, if not in the registry initially, do not get included
while computing the dependency order for installation.

The code is in the macports/gsoc17-migrate
 branch.
It'd be great if someone checks it out (expecting that a few developers
here would be upgrading to Catalina soon) and report any problems they face
on this thread.

Instructions can be found on the wiki [1].

[1]: https://trac.macports.org/wiki/SummerOfCode2017#migrate

- Umesh

Re: https://ports.macports.org/port/postfix/summary is broken

[Umesh Singla]

Thank you for reporting the issue. I checked the console for errors and
found a bug. It seems like it tries to load the variant "mariadb10.0"
entity from the database but it does not match the regex in its intended
URL which is 'ports\\/variant\\/(?P[-a-zA-Z0-9_]+)\\/$'. I'll
raise the issue with the team.

Umesh

On Sun, Sep 8, 2019 at 12:20 AM Gerben Wierda  wrote:

> When trying to open the postfix port page, Safari and Firefox both hang.
>
> Gerben Wierda
> Chess and the Art of Enterprise Architecture 
> Mastering ArchiMate 
> Architecture for Real Enterprises
>  at
> InfoWorld
> On Slippery Ice  at EAPJ
>
>

Re: Merging "port migrate"?

[Umesh Singla]

On Tue, Jul 2, 2019 at 8:52 PM Mojca Miklavec  wrote:

> On Sun, 30 Jun 2019 at 14:00, Clemens Lang wrote:
> >
> > On Sat, Jun 29, 2019 at 11:58:04PM +0200, Mojca Miklavec wrote:
> > > We are approaching the release of 10.15.
> > >
> > > What are the chances to get the "port migrate" code merged before the
> > > end of this summer and before the release of 10.15?
> > >
> > > If we wait too long, the OS might change sufficiently that the code
> > > will stop working one day.
> >
> > The only problem left I currently see is how the code deals with
> > variants in non-requested ports. At the moment, only requested ports are
> > being reinstalled, but these requested ports might only work correctly
> > if non-requested ports are reinstalled with the same variants (which
> > might not be the default ones).
>
> From this perspective I can imagine other potential problems. Some
> ports may declare a different variant or a different set of
> dependencies on an earlier OS than the one we would migrate to. On the
> new OS we might have different variants available altogether. So we
> probably won't have a foolproof solution anyway until the work from
> one gsoc before gets merged (correct handling of dependencies and
> variants), and even then there will be further issues.
>
> Even without "migrate" we are currently stuck when we install a port
> with default variant X, and then the default variant changes. Without
> reinstalling the port you get stuck with the old variant etc.
>
> So I cannot decide how big of a problem this is compared to the rest
> of issues that might arise and prevent users from getting a smooth
> upgrade experience.
>
> Now that you mention this ... probably the only way to reliably test
> this would be if we had some "macports simulator" which would "install
> the ports" to some chosen prefix without actually building the ports,
> only updating port registry. Then you would tell that "macports
> simulator" that it's running on a newer OS version, and it would try
> to run migrate. This would make it easier to see at least some of the
> potential issues (not all), and it would allow one to run various
> upgrade scenarios. I don't see anyone implementing that though, and it
> wouldn't be a small amount of work either.
>
> The biggest mystery to me is that if you forget to do something with
> MacPorts before you update, you can only run "rm -rf ..."; you cannot
> even run "port installed" etc., which would be handy in such
> situations. Again, something unrelated.
>
> > If that were fixed, the code would be good to go from my PoV. Does
> > somebody have time to work on this?
>
> I was wondering if bribing Umesh to finish this would be an option?
> Last time I talked to him he maybe wasn't aware of any pending issues.
> From what I remembered you closed a PR, but left a branch somewhere, I
> wasn't aware of what was left either.
>
> Opening the PR again with the notes about what is still needed might help?
> Umesh, how realistic would it be for you to finish the work?
> If we don't merge it soon, we may just as well end up not merging it
> ever, which would be a pity.
>

I think I can get around to taking a look at the code again and finishing
this. I cannot commit to doing it immediately but soon.

Opening the PR again might help actually.

- Umesh


>
> Mojca
>

Re: GSoC 2019 [Collect build statistics]

[Umesh Singla]

Nice. Makes testing a lot easier now. It would be great if you could push
the Dockerfile as well.

Also, I am not liking conversing on these multiple broken threads very
much. I'll try to setup Matrix (have absolutely no idea about it yet) today
so that we can compare gitter and matrix and move ahead.

Umesh

On Sat, May 18, 2019 at 2:19 AM Mojca Miklavec  wrote:

> On Fri, 17 May 2019 at 20:00, Arjun Salyan wrote:
> >
> > Hi Mojca and Umesh,
> >
> > I have now spent some time with docker. I have also dockerised the web
> app.
>
> Wonderful news!
>
> Let us know where we could fetch it from, so that we can test it and
> one of the infra team can put it on the server.
>
> I need to ship something until Monday. I'll be somewhat more relaxed
> after that. (PS: Clemens, do you happen to go to the automotive fair
> in Stuttgart next week?)
>
> Mojca
>

Re: Slack-like chat (also for GSOC)

[Umesh Singla]

I remember seeing Gitter.im being used by more than a usual number of open
source communities in the past. While I am personally fine with Github
Issues/PRs and emails, a chat-like application does come in handy for quick
replies.

I logged in just now to my old account from over 2 years back and I see no
limits on the messages. You can sign in with Github/Twitter. There is this
idea of community and rooms like IRC, and while anyone can read the
community messages by visiting the link, one needs to sign in to talk. It's
linked to a Github organization and owners of the organization act like
admins. It also allows for one-on-one conversations and rooms where only
invited users can join.

An example would be: https://gitter.im/coala/coala

@Mojca would you be willing to give this https://gitter.im/macports-gsoc a
try? I tried creating one suitable for us. Let me know if you are able to
see the secret room. :)

Thanks,
Umesh

On Wed, May 15, 2019 at 2:02 AM Mojca Miklavec  wrote:

> On Tue, 14 May 2019 at 18:11, Rainer Müller wrote:
> >
> > I think Slack workspaces are also always invite only, but please correct
> > me if I am wrong (maybe only for paid plans?). Assuming we might want to
> > replace IRC one day as the official development and support chat, that
> > would not work well.
> >
> > I think it is important that this would be open for anyone interested to
> > join, with private group chats as an optional feature.
>
> +1
>
> > > We don't need to all agree at once. I don't see anything wrong with
> > > giving it some testing first and decide what's best (no need to ask
> > > everyone to turn IRC off :).
> >
> > I recently tried the Matrix IRC Bridge to FreeNode IRC. By using riot.im
> > it actually works quite well and was easy to set up. It also solves the
> > "always-on" problem of IRC as it acts like a bouncer.
> >
> > >>> Would it be realistic to install such a service on breaburn if
> needed?
> > >>> (Or is it too complex / too much work?)
> > >>
> > >> I'd prefer a SaaS offering here. Self-hosting just increases the
> > >> maintenance burden and I don't think we need the configurability.
> >
> > For the self-hosted options, Rocket Chat would be an option. However,
> > when we used it at work, after a while I started to miss some kind of
> > threading for longer conversations. Although we also usually do not have
> > long conversations or that much activity on IRC, so maybe this is not
> > that important here.
>
> I don't have any experience with Matrix, but I maybe I should try it once.
>
> I'm not familiar with Rocket Chat either, but if you missed a feature,
> I trust your opinion.
>
> I do believe that longer conversations are important. Think of GSOC,
> where the same project runs for 5 months or longer. It does make sense
> to keep it well-organised.
>
> Zulip offers topics (which they heavily advertise as one of their
> "superpowers") which I find to be quite a nice "substitute" for
> threads like those in emails. If we pick that one, I would certainly
> go for GitHub OAuth and IRC mirror.
>
> I would discard the idea of using Slack. Based on general feedback
> that probably leaves the following top candidates?
> - Matrix (might work without self-hosting)
> - Zulip
> - Mattermost
>
> Rainer, you did not answer about whether you would be willing to try
> to install / maintain one of those on the server if we wanted to
> self-host the chat?
>
> Regarding Matrix: is anyone willing to set up one ("in the cloud") for
> testing?
>
> Mojca
>

Fwd: Wish to contribute to MacPorts as part of GSoC

[Umesh Singla]

Hi Shreyas,

While I believe you have a good set of skills, it may be a bit too late if
you want to participate in GSoC with us. But we definitely welcome all
kinds of contribution outside GSoC and the program is going to be there
next year as well. Contributors are definitely given higher preference.

Our criteria for selection involves a strong proposal and a demo of the
student's skill set by either raising a PR to the existing code base or PoC
implementations of any idea you are proposing. This is for the mentors to
be confident about a student being productive as soon as the coding period
starts.

Nonetheless, I'd advise you to go through the March and April archives of
this mailing list [1], as there's an abundance of information available on
almost all the "hot" projects and problems MacPorts is facing.

To answer your questions, I don't think we have any idea "similar" to
collect-build-statistics but if you meant similar to a web application,
others on the list are more suitable to answer. I am not sure what you
meant by improvements to the previous collect-build-statistics project
either. We do not have any implementation until now.

(Also, please keep your emails on the mailing list to get responses quicker
and from the wider community. Subscribe if you haven't already.)

[1]: https://lists.macports.org/pipermail/macports-dev/

- Umesh

-- Forwarded message -
From: Shreyas H N 
Date: Tue, Apr 9, 2019 at 4:37 PM
Subject: Wish to contribute to MacPorts as part of GSoC
To: 


Hello Umesh,

I am Shreyas H N, a PG1 student at IIIT Hyderabad. I found your contact on
the MacPorts GSoC page. "Collect build statistics" project caught my eye
and I believe I am competent enough to develop significant stuff in this
domain.

A short introduction about me:
I completed my Btech at M S Ramaiah University, Bangalore. I used
throughout Linux my undergrad. Just before I joined masters at IIITH, I
switched to Mac. I am a strong believe in the Growth "Mindset".
A few projects I am proud of:
1. MapRedue framework implementation from scratch (C++). WordCount and
InvertedPage index.
2. Machine Learning intern at IISc SERC in 2017 summer.
3. "mini BitTorrent"
4. DropBox clone



 Web development experience
1. Built "DropBox clone" web application using Flask, Bootstrap.
2. Task Management web application using ASP.NET as part of my internship
at MOOG in 2016
3. Developed a responsive website for my father's firm in 2015 (
www.nagarajassociates.in). This was my very first web development project

Other info:
1. Have been using git from the past year (Projects: Mapreduce,
Bittorrrent, Terminal file explorer, Dropbox and all assignments.
https://github.com/hiteshkaushik28/MapReduce_Project )
2. I was a Machine Learning intern at IISc in 2017.
3. I am a newbie to the OpenSource world but I have already experienced
that it is filled with passionate and humble people who love collaborating.

Work I have done so far:
1. Saw the code base introduction video on youtube (
https://www.youtube.com/watch?v=46qshiDskrM)
2. Went through certain portions of the guide.
3. Read the project ideas and chose "Build Statistics"

Currently I am brain storming how I can modify/improve this "Collect build
statistics" idea to prepare my project proposal.

My questions to you:
1. If you have any idea similar to "Collect build statistics", do suggest.
2. Do you think it is a good idea for me to propose only improvements to
the previous "Collect build statistics" GSoC project?

GSoC 2019 submission deadline is today

[Umesh Singla]

Hello,

*I apologize for another email which may not be of interest to many of the
members here but till we figure out a new channel for GSoC (and more such)
activities, I believe there is no other option than using -dev.*

With only a few hours left in final submissions, I advise the students to
submit a final PDF version of their proposal as soon as possible and not
leave it to the last minute. Draft submissions do not count [1]. While
proposals are given the most weight in the decision for selection, there
are a lot of other factors which you may have noticed already, from the
replies to your queries.

To potential mentors: I'd suggest clicking on the "Want To Mentor" button
on the summer-of-code dashboard [2] against the project/proposal you'd like
to mentor if you haven't already. I am saying this because the number of
"want-to-mentor" might be one of the criteria Google considers while
deciding the number of slots to be allotted to an organization. It'd help
in assigning the mentors to students as well.

- Umesh

[1]:
https://google.github.io/gsocguides/student/writing-a-proposal#submitting-a-final-pdf-proposal
[2]: https://summerofcode.withgoogle.com/dashboard

Re: Season of Docs from Google Open Source

[Umesh Singla]

Although there hasn't been any interest shown by the community regarding
GSoD [1] and feeling that it could be highly beneficial to MacPorts
(relatively easier projects and the equal stipend to participants compared
to GSoC will attract candidates), I am bumping the thread to give it
another chance.

Organization application submissions are open till Apr 23.

[1]:
https://opensource.googleblog.com/2019/03/introducing-season-of-docs.html

- Umesh

On Wed, Apr 3, 2019 at 2:01 AM 'sttaylor' via Google Summer of Code Mentors
List  wrote:

> Open source organizations can now submit applications to participate in
> Season of Docs. Head on over to the Season of Docs announcement list (
> season-of-docs-announce
> ) to see
> the details.
>
> If you have any questions about the program, please email the Season of
> Docs team at season-of-docs-supp...@googlegroups.com.
>
> --
> You received this message because you are subscribed to the Google Groups
> "Google Summer of Code Mentors List" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to google-summer-of-code-mentors-list+unsubscr...@googlegroups.com.
> To post to this group, send email to
> google-summer-of-code-mentors-l...@googlegroups.com.
> Visit this group at
> https://groups.google.com/group/google-summer-of-code-mentors-list.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/google-summer-of-code-mentors-list/eaf7cfe5-31f4-42b6-9828-fe388d7517f8%40googlegroups.com
> 
> .
> For more options, visit https://groups.google.com/d/optout.


On Tue, Mar 12, 2019 at 8:13 PM Zero King  wrote:

> Hi,
>
> Google recently announced Season of Docs[1], "a new program which
> fosters the open source contributions of technical writers".
> Organization applications open on April 2, 2019 at 20:00 UTC[2], should
> we apply for this chance to improve our documentation?
>
> [1]
> https://opensource.googleblog.com/2019/03/introducing-season-of-docs.html
> [2] https://developers.google.com/season-of-docs/docs/get-started/
>
> --
> Zero
>

Re: GSoC 2019 [Collect build statistics]

[Umesh Singla]

Hi

For me, this project can be divided into three major parts:

1. ports page:

a) We have seen a quick demo of this already. However, the major part I
think is missing is the search. We can brainstorm over the details like
search-as-you-type, adding new ports etc according to the timeline. Not
sure how much browsing by the first letter helps.

b) You cannot have a class Ports when it represents a Port:
https://github.com/arjunsalyan/MacPorts-Demo-App/blob/master/ports/models.py#L6
.

2. build statistics:

a) In Time Elapsed of builds, it would be incorrect to show time taken for
only one of the build stages. Example, in the case of
https://build.macports.org/builders/ports-10.12_x86_64-builder/builds/87301,
total-time-taken (12 min 59 secs) is right to be shown and not "6 mins 45
secs".

b) There are some things which seem hard-coded to me. I
see '10.14_x86_64', '10.13_x86_64' at multiple places - in port detail
view, build to database view and jinja templates. It's time to define some
constants config file now. For build statuses as well. With a new release
of macOS, we do not want to have to change multiple files in code. In this
project, it is important that a part which works, it is accurate and
complete.

c) Also, as Mojca mentioned, errors like these:
http://frozen-falls-98471.herokuapp.com/ports/database/ should not be
exposed. What is it intended to do anyway?

3. installation statistics:

a) Last year we had a quick attempt at this project (installation
statistics part). It's still lying in my account. Probably the only part
where we spent some time was models.py [2]. You could review it sometime
soon and come back with doubts/suggestions. It almost has the model
implementation on the installed ports statistics with a sample submission
data file present at the root of the project. Class Port, Category, etc can
help with the first part of the project as well.

The tricky part was to figure out (still needs to be figured out) unique
ports and what to keep as the primary key. Similarly, in the case of
maintainers (and look for more such cases).

There are several variations of how maintainers are mentioned in the
Portfiles, example GitHub handles, or emails, or personal websites at
times. You may want to look into the different formats (or ask on the list
separately), and come up with a solution to parse and store.

b) I would suggest keeping all the parsing scripts together at some place
in your project. Keep a document where you have changed the parsing output
(before and after) and also, what do they parse. Naming a script parse.py
doesn't tell much. I am having difficulty tracking down and reviewing all
the scripts.


==

As Mojca said, I am not seeing any way to provide code review on Github
when it's already merged. Since you have the base application ready, it's
time to use PRs. I would also advise starting to follow at least some of
the PEP8 style guide conventions, it's good to follow clean code practices
from the beginning. You can either use coala lint or pylint before pushing
the code, if familiar.

You recently added a .gitignore file but there are .pyc, __pycache__/, etc
files from before. Consider cleaning them up.

These are all the suggestions for later, but only a small portion of what a
proposal is expected to include. Right now, I'd suggest working on the
parsing the maintainers as best as possible. It'd then be good to tackle
the project part by part.

[1]:
https://github.com/umeshksingla/macports-stats/blob/master/firstproject/firstapp/models.py

Best,
Umesh

On Thu, Mar 21, 2019 at 3:57 PM Arjun Salyan 
wrote:

> On Thu, Mar 21, 2019 at 10:20 AM Mojca Miklavec 
> wrote:
>
>> (2) You made a simple PR last time to fix portindex2json for a more
>> reasonable output of categories. Would you be willing for a tiny bit
>> more difficult task and try to improve the output for maintainers as
>> well? We would want a list of all maintainers with two optional keys
>> for each (email &  github handle) plus a boolean value to tell whether
>> the port is under openmaintainer policy.
>>
>
> Hi, I was working on this. What do I do with "nomaintainer" ? For now I am
> getting the following output.
>
> {
>
> "variants" : "clang33 clang34 clang37 clang38 clang39 clang40
> clang50 clang60 clang70 mpich mpich_devel openmpi openmpi_devel python26
> python27 python33 python34 python35 python36 python37 debug no_static
> no_single regex_match_extra universal",
>
> "subports" : "boost-numpy",
>
> "portdir"  : "devel\/boost",
>
> "description"  : "Collection of portable C++ source libraries",
>
> "homepage" : "http:\/\/www.boost.org",
>
> "epoch": "0",
>
> "platforms": "darwin",
>
> "name" : "boost",
>
> "depends_lib"  : "port:zlib port:expat port:bzip2 port:libiconv
> port:icu port:python27",
>
> *"openmaintainer"   : True,*
>
> "long_description" : "Boost provides free portable 

Re: MacPorts GSoC project: Collect build statistics (web app)

[Umesh Singla]

Hi Rajdeep

On Sun, Mar 17, 2019 at 6:17 PM Rajdeep Bharati 
wrote:

> Dear MacPorts Community,
>
> This is with reference to the MacPorts project: Collect build statistics
> .
> I am Rajdeep Bharati, currently a sophomore, pursuing B.Tech in Computer
> Science from Jamia Hamdard University, New Delhi. I am really interested in
> working on the above project this summer.
> I have gone through the history of builds, and also the previous attempt
> of this project.
>
I thought of the following areas where the project can be improved:
>
>- Whenever a new port is created, then it should automatically be
>added to the database of the web app. This can be done using Django
> signals.
>
> Not sure if Django signals can/should be used from outside the
application. Adding a port can be as simple as using create_or_update, IMO.
But feel free to elaborate on the structure.

>
>- A RESTful API can be build using the database schema, with the help
>of Django REST Framework, and then the frontend can be made using ReactJS.
>This would drastically improve the performance of the website, and offer a
>dynamic and responsive user interface.
>
> An API will be useful to extend the use of the project beyond the
Django-app. Right now, a clean interface which can be maintained easily is
the priority. But it's again up to the developer to be able to fit the task
in the timeline. As mentioned previously in some of the emails on the same
topic, a working application is very much preferable over an incomplete
project.

>
>- A search-as-you-type search box can be implemented on the website,
>which would enable the user to promptly find the port/build/file they are
>looking for. This can be built using Elasticsearch.
>
> I'd not go into this at the moment given the state of the statistics
website. But something to be considered in the near future for sure.

>
>- A dashboard can be present on the website, showing the build
>history, and/or success metrics.
>- Tests need to be written and CI can be added.
>- Scraping of data (JSON) and importing it to the SQL database can be
>done as documented in the previous project.
>
> I am comfortable with the git workflow and have experience working on open
> source projects. Here is my Github handle:
> https://github.com/rajdeepbharati. Looking forward to hearing from you.
>

This is the current state of our ports search [1] and builds [2]. Try to
come up with either a static mock UI or a working demo UI which can
integrate the information from the two (or possibly more!), that will be a
good showcase of skills. Here's a quick no-brainer attempt at it from last
year [3].

Also, do you have access to macOS?

[1]: https://www.macports.org/ports.php
[2]: https://build.macports.org/
[3]:
https://github.com/macports/macports-webapp/blob/master/docs/Database_Design.md

Umesh


>
> Thank you.
> Yours sincerely
> Rajdeep Bharati
>

Re: GSoC 2019 [Collect build statistics]

[Umesh Singla]

Hi Arjun

On Wed, Mar 13, 2019 at 10:22 PM Arjun Salyan via macports-dev <
macports-dev@lists.macports.org> wrote:

> As suggested, I have made an attempt at a basic demo app:
> https://frozen-falls-98471.herokuapp.com
>
> Please review it and let me know if this seems fine. After applying any
> further inputs, I shall proceed with the documentation to setting it up.
>

This looks great for the first attempt. It would be great if you could
share the details on the flow of data (from portindex to html views), and
how you would extend it to incorporate mpstats output later.


> It is not completely static. The port information is fetched from database
> and is not hard-coded. What I did was to clone macports-ports, and used
> portindex2json.tcl to populate the database. However, the format of the
> json outputted by portindex2json could not be directly loaded into the
> database. I had to manually make it in the format of fixtures accepted by
> Django (and that is why only few ports are available), which means that
> portindex2json would also require some modification.
>

There are some known issues with portindex2json output, possibly related to
quotations, or strings and lists. Can you paste here the issues you ran
into? This seems like a priority to me.


> The build history is hard-coded. Also I need suggestions here- what info
> is most important to be displayed on the port info page. For now, I could
> only figure out to show build history for different os. Am I doing it
> correctly?
>

Apart from build stats, a link to a port's portfile on Github, dependencies
(with versions), or status of the build (on each OS?) will be helpful. It
would be better if the categories are clickable, which shows me the list of
ports belonging to that category (like a filter) but not for now. Better
parsing of maintainers will be useful too.

Also, the OS filter seems to be not working, probably there's no data but
on selecting 10.13 for AppHack, it still showed base-10.14_x86_64.


> The installation statistics, which currently run independently would also
> be integrated with port-info in the new app.
>
> Also, I have used bootstrap for this demo app, is that fine or we need to
> go with something more powerful like angular or react.
>

Bootstrap is fine as long as we are leveraging Django's jinja templating
and there's no need to expose APIs.

Umesh


> Thank You.
>

Re: Online MacPorts meeting for GSOC @ Saturday 26th January

[Umesh Singla]

Do we have a decision? It's fairly late but there's stiłl time...

Umesh

On Sat, Jan 26, 2019 at 3:32 PM Mojca Miklavec  wrote:

> Hi,
>
> Half of the candidate GSOC mentors are busy today, which kind of
> defeats the purpose of the meeting in a couple of hours.
>
> The deadline for application is the 6th of February, which is roughly
> 2 weeks away, but we need to finish the application by the end of next
> week at most. Can we come up with another proposal of the time? Please
> write off-list with your timing proposal / limitations, and in the
> meantime we continue the discussion via email?
>
> Mojca
>

Re: Online MacPorts meeting for GSOC @ Saturday 26th January

[Umesh Singla]

Edited the subject to 26th January...

Also, appreciate keeping a single agenda for the meeting.

On Fri, Jan 25, 2019 at 3:36 AM Mojca Miklavec  wrote:

> Hi,
>
> This is a reminder for anyone interested in Google Summer of Code that
> we plan an online meeting this Saturday. (Please let me know if you
> plan to join, so that we know whom to expect.)
>
> I assume that we would have some participants from Europe & India. If
> participants from China/Australia or USA are interested in joining,
> please raise your hands and we'll try to shift the timing into either
> direction to suite the participants better.
>
> Else we might go with 13:00 UTC, suggestions welcome. Let's try to
> make the meeting short.
>

I am good with any timings.


> We don't have too many mentors, but we could mentor up to two or max.
> three students provided that we get accepted and find suitable
> candidates (one project in base, one project in infrastructure, one
> with ports). Ideally each project needs two mentors (one at least for
> backup). We need to discuss the application, review and refine the
> ideas etc. (Or we could decide not to apply ...)
>
> Please send your ideas for GSOC project proposals, even if you don't
> plan to participate at the meeting. Also, we would really need a list
> of simple tasks that students could do while learning our codebase
> (for example something that would take an experienced developer 5-10
> minutes to fix).
>

Let's decide the admin stuff first, I think. And then we can have a
meeting/discussion-on-email about this shortly after we decide the above.

Umesh


>
> Mojca
>

Re: Online meeting today at 15:00 UTC (in 4 hours)

[Umesh Singla]

On Sun, Jan 13, 2019 at 4:07 PM Jackson Isaac  wrote:

>
>
> On Sun 13 Jan, 2019, 15:59 Umesh Singla 
>> On Sun, Jan 13, 2019 at 3:21 PM Jackson Isaac 
>> wrote:
>>
>>> On Sun 13 Jan, 2019, 14:52 Umesh Singla >> wrote:
>>>
>>>> Thanks for the summary.
>>>>
>>>> Also, were we able to decide on the GSoC-admin? I have put the call for
>>>> mentors email for now to avoid further delays. But let's decide soon, so we
>>>> have someone actively looking into it.
>>>>
>>>
>>> Umesh, since you showed interest in being the admin again, I would say
>>> you can go ahead and be the org admin. Hope to get in responses soon from
>>> potential mentors.
>>>
>>
>> Okay, but I was really hoping you'd be willing to take this up, and if
>> possible, I'll start looking into base once in a while and help out the
>> newcomers get started on base or infra projects. Also, with the new job, I
>> delay considerably replying to the emails which could affect the
>> application process.
>>
>
> Sure. I'll take up the admin role then, in case we have sufficient mentors.
>

Thanks.

- Umesh

Re: Online meeting today at 15:00 UTC (in 4 hours)

[Umesh Singla]

On Sun, Jan 13, 2019 at 3:21 PM Jackson Isaac  wrote:

> On Sun 13 Jan, 2019, 14:52 Umesh Singla 
>> Thanks for the summary.
>>
>> Also, were we able to decide on the GSoC-admin? I have put the call for
>> mentors email for now to avoid further delays. But let's decide soon, so we
>> have someone actively looking into it.
>>
>
> Umesh, since you showed interest in being the admin again, I would say you
> can go ahead and be the org admin. Hope to get in responses soon from
> potential mentors.
>

Okay, but I was really hoping you'd be willing to take this up, and if
possible, I'll start looking into base once in a while and help out the
newcomers get started on base or infra projects. Also, with the new job, I
delay considerably replying to the emails which could affect the
application process.

Umesh


>
>> On Sun, Jan 13, 2019 at 12:56 AM Mojca Miklavec 
>> wrote:
>>
>>> Hi,
>>>
>>> Here's the summary of today's meeting.
>>>
>>> === Next online meeting
>>>
>>> Scheduled two weeks from now (January 26th), with the stress on GSOC.
>>> We'll adjust the timing based on requests to join from USA or
>>> Australia, please raise your hands if you want to join.
>>>
>>> === MacPorts Meeting 2019
>>>
>>> We shortlisted some dates (Saturday - Wednesday):
>>> - 6.-10. April
>>> - 11.-15. May
>>> - 8.-12. June
>>> Aljaž is suggesting June to hopefully get nicer weather, potentially
>>> the ability to go swimming etc.
>>>
>>> The idea is to organize the meeting in Trieste, Aljaž will try to find
>>> a suitable place to stay. If you would like to join, please cast the
>>> vote for your favourite date. If none of those dates suit you and you
>>> would like to join, please let us know.
>>>
>>> === Google Summer of Code
>>>
>>> * We are looking for volunteers to mentor the students.
>>> * We would probably not participate with more than one or two
>>> projects, but we will only apply if we get sufficient interest from
>>> potential mentors (ideally those who know the base).
>>> * Me and Umesh could guide a student working on buildbot or webapp,
>>> but that's not sufficient on itself to apply.
>>> * Jackson would require hardware to be able to help more :)
>>> * We need to attach "sample tasks" to all the ideas that we are
>>> suggesting to students (for screening the students for their fitness
>>> to work in GSOC).
>>>
>>> === Software Freedom Conservancy
>>>
>>> We discussed joining SFC. I sent an email to the PortMgr, but that
>>> list is slightly quiet :).
>>> We will repeat the initiative on this mailing list. It could be nice
>>> to try if we could get some co-funding for the meeting.
>>>
>>> === Travis
>>>
>>> * Zero recently made quite some improvements to our bot & Travis
>>> infrastructure. Thank you very much!
>>>   * Private repositories for binary packages are now used.
>>>   * Packages are always built from source.
>>>   * Obsolete packages are no longer scheduled for build, just to fail
>>> anyway.
>>>   * Some improvement in the bot.
>>> * He is looking for some further suggestions that could improve our
>>> experience.
>>>   * (My not-too-serious suggestion was to ping participants after two
>>> weeks of no activity, to simplify Perry's life :)
>>> * Zero was thinking of starting to work on a script that could
>>> automatically update port version based on livecheck results and
>>> automatically create a pull request. This would be a very welcome
>>> addition.
>>>   * My question was whether we could also automate revbumping
>>> dependent ports, but this is slightly more challenging.
>>> * Zero is looking into the other tickets (four tickets are currently
>>> open) and into automating releases. He asked if someone (Clemens?)
>>> could create an account on Bintray, but he'll send the details over
>>> the mailing list.
>>> * Zero asked if it was possible NOT to result in an error in "port
>>> test" when a port doesn't have any tests defined. At the moment he
>>> cannot enable running tests on Travis since that would almost always
>>> result in a failure when the port didn't implement that functionality,
>>> even if there was sufficient time left to run the tests.
>>> * Rainer promised to create ticket for base to support "port bintest"
>&g

Re: Online meeting today at 15:00 UTC (in 4 hours)

[Umesh Singla]

Thanks for the summary.

Also, were we able to decide on the GSoC-admin? I have put the call for
mentors email for now to avoid further delays. But let's decide soon, so we
have someone actively looking into it.

Umesh

On Sun, Jan 13, 2019 at 12:56 AM Mojca Miklavec  wrote:

> Hi,
>
> Here's the summary of today's meeting.
>
> === Next online meeting
>
> Scheduled two weeks from now (January 26th), with the stress on GSOC.
> We'll adjust the timing based on requests to join from USA or
> Australia, please raise your hands if you want to join.
>
> === MacPorts Meeting 2019
>
> We shortlisted some dates (Saturday - Wednesday):
> - 6.-10. April
> - 11.-15. May
> - 8.-12. June
> Aljaž is suggesting June to hopefully get nicer weather, potentially
> the ability to go swimming etc.
>
> The idea is to organize the meeting in Trieste, Aljaž will try to find
> a suitable place to stay. If you would like to join, please cast the
> vote for your favourite date. If none of those dates suit you and you
> would like to join, please let us know.
>
> === Google Summer of Code
>
> * We are looking for volunteers to mentor the students.
> * We would probably not participate with more than one or two
> projects, but we will only apply if we get sufficient interest from
> potential mentors (ideally those who know the base).
> * Me and Umesh could guide a student working on buildbot or webapp,
> but that's not sufficient on itself to apply.
> * Jackson would require hardware to be able to help more :)
> * We need to attach "sample tasks" to all the ideas that we are
> suggesting to students (for screening the students for their fitness
> to work in GSOC).
>
> === Software Freedom Conservancy
>
> We discussed joining SFC. I sent an email to the PortMgr, but that
> list is slightly quiet :).
> We will repeat the initiative on this mailing list. It could be nice
> to try if we could get some co-funding for the meeting.
>
> === Travis
>
> * Zero recently made quite some improvements to our bot & Travis
> infrastructure. Thank you very much!
>   * Private repositories for binary packages are now used.
>   * Packages are always built from source.
>   * Obsolete packages are no longer scheduled for build, just to fail
> anyway.
>   * Some improvement in the bot.
> * He is looking for some further suggestions that could improve our
> experience.
>   * (My not-too-serious suggestion was to ping participants after two
> weeks of no activity, to simplify Perry's life :)
> * Zero was thinking of starting to work on a script that could
> automatically update port version based on livecheck results and
> automatically create a pull request. This would be a very welcome
> addition.
>   * My question was whether we could also automate revbumping
> dependent ports, but this is slightly more challenging.
> * Zero is looking into the other tickets (four tickets are currently
> open) and into automating releases. He asked if someone (Clemens?)
> could create an account on Bintray, but he'll send the details over
> the mailing list.
> * Zero asked if it was possible NOT to result in an error in "port
> test" when a port doesn't have any tests defined. At the moment he
> cannot enable running tests on Travis since that would almost always
> result in a failure when the port didn't implement that functionality,
> even if there was sufficient time left to run the tests.
> * Rainer promised to create ticket for base to support "port bintest"
> which could test something like "binaryname --version" or do some
> other simple test to check whether a port is working after it's being
> installed. This could also be a potential GSOC task, even though too
> small all by itself.
>
> === MacPorts base
>
> (Looking for volunteers to rewrite the base to python to gain more
> contributors :) :) :)
> Jackson will start drafting some introduction to programming MacPorts base.
>
> === Participants (in order of appearance)
>
> * umeshksingla (Umesh)
> * mojca (Mojca)
> * g5pw (Aljaž)
> * l2dy (Zero)
> * raimue (Rainer)
> * ijackson (Jackson)
>
> Thanks to everyone for participation, even if the schedule was a bit
> messy today, sorry for the confusion :)
>
> Mojca
>
>
> On Sat, 12 Jan 2019 at 12:01, Mojca Miklavec  wrote:
> >
> > Hi,
> >
> > I think I first messed up the addition and subtraction in time zones
> > (last time it was apparently at 13:00 UTC), and then with sending out
> > the email yesterday under the wrong address. I wanted to ask if there
> > were any participants from the far east or west who wanted to
> > participate, in that case we could shift the hour, but since we only
> > had people from UTC+1 and UTC+5.5 who raised their hands, we'll stick
> > with 15:00 UTC for now.
> >
> > This is the calendar:
> >
> >
> https://calendar.google.com/calendar/embed?src=9unkhredr302jroorlhusav0ko%40group.calendar.google.commode=AGENDA
> >
> > And this is for hangouts (last time we had a much shorter link, I'm
> > unable to come up with that shorter one this 

Call for Mentors - GSoC 2019

[Umesh Singla]

Hello all,

The Google Summer of Code has started accepting applications from
organizations. The deadline for the same is January 13, this Monday.

I would like to invite everyone involved with MacPorts who would like to
volunteer as mentors for students to help integrate them into the open
source community and succeed in completing their summer projects.

Please feel free to reply to this thread if you are interested in proposing
a project or joining/mentoring an existing one. If it's a new idea,
just describe the idea and introduce yourself.

*Please note that we have very few mentors this time, so we need to decide
if we can even participate this year depending on your responses. I'd also
like to mention that we really need more people who are familiar with the
macports-base code and willing to mentor. The development on base has been
on halt for long now.*

The current ideas list is here .
If possible, try to get back to us by Jan 22 or 23.

Regards,
Umesh

Re: Online meeting today at 15:00 UTC (in 4 hours)

[Umesh Singla]

Hi everyone,

Let's use the following link for the call:
https://hangouts.google.com/call/mk3BtdCWJ0u_xl5MfBX-AEEM

had people from UTC+1 and UTC+5.5 who raised their hands, we'll stick
> with 15:00 UTC for now.
>

Okay.


> This is the calendar:
>
>
> https://calendar.google.com/calendar/embed?src=9unkhredr302jroorlhusav0ko%40group.calendar.google.commode=AGENDA


This shows the meeting time in the past for me, by almost an hour.


> And this is for hangouts (last time we had a much shorter link, I'm
> unable to come up with that shorter one this time, but if anyone knows
> how, feel free to post something better):
>
>
> https://calendar.google.com/event?action=TEMPLATEtmeid=N2ZxcWFsbnFmcmtvcmxpYWVrMGxoc2s4MGQgOXVua2hyZWRyMzAyanJvb3JsaHVzYXYwa29AZwtmsrc=9unkhredr302jroorlhusav0ko%40group.calendar.google.com


This just links to a new event creation page.


> Meeting notes will be collected here:
> https://trac.macports.org/wiki/Meetings/2019-01-12


Thanks for initiating the wiki, Mojca. I will update the link to video call
here as well.
Let me know if the above link doesn't work for you or you want to test it
first.

Umesh

Re: Online MacPorts meeting? This Saturday?

[Umesh Singla]

+1 for any time this weekend.

On Tue, Jan 8, 2019 at 9:39 PM Umesh Singla  wrote:

> A big +1, again.
>
> On Tue, Jan 8, 2019 at 7:18 PM Jackson Isaac 
> wrote:
>
>> Hi Mojca
>>
>> On Tue 8 Jan, 2019, 19:08 Mojca Miklavec >
>>> Hi,
>>>
>>> This is slowly getting more and more urgent ... :)
>>>
>>> One week from now applications for GSOC start, and we still didn't
>>> manage to call an online meeting. Any chance we do it this weekend?
>>>
>>> Topics:
>>> - Google Summer of Code
>>> - Meeting in 2019
>>> - Software Freedom Conservancy
>>> - Review open pull requests and roadmap for base
>>> - anything else: please propose
>>>
>>
>> I am in for the call this Saturday. I would also like to discuss about
>> Gsoc. Hope we can schedule something (even if we have interested admins and
>> mentors would be enough) :)
>>
>>>
>>>

Re: Request to Join Organization

[Umesh Singla]

Hi Tathagat,

Welcome to MacPorts!

I would say the best way to get started for GSoC 2019 is to introduce
yourselves to our development community (cc'ed), your skills, interests and
any projects. You can have a look at our last year's GSoC page [1]. Most of
the information on the page is still relevant and don't hesitate to write
back to this channel with any doubts.

Umesh


[1]: https://trac.macports.org/wiki/SummerOfCode


On Thu, Nov 22, 2018 at 2:49 AM TATHAGAT THAPLIYAL <
tthapliyal_b...@thapar.edu> wrote:

> Hi 
> I would love to become a part of MacPorts Organisation on github and I
> hope to contribute in any way possible for GSOC-18
>
> Regards
> Tathagat Thapliyal
>

Re: Online meeting next Saturday (SFC, roadmap, meeting 2019)?

[Umesh Singla]

Can we not let this thread die? I feel it’s fairly important...

Umesh

On Sun, 14 Oct 2018 at 22:59, Mojca Miklavec  wrote:

> Hi,
>
> What do you think about another MacPorts online meeting next Saturday
> (20th) at 13:00 UTC?
>
> If you are interested in joining:
> - Do you have time?
> - Or do you propose another weekend which would be more suitable?
> - What topics would you like to discuss?
>
> Mojca
>
> My suggestions for topics of discussion:
> - Software Freedom Conservancy
> - Status of Mojave
> - Take a look at open pull requests for base & roadmap
> - Meeting in 2019
>

Re: Online meeting next Saturday?

[Umesh Singla]

I have my weekends free too. Oct 27 13:00 UTC?

We really need to drive this fast so we can get going with the website and
SFC and annual meeting and everything before 2019.

On Tue, Oct 23, 2018 at 6:48 PM Mojca Miklavec  wrote:

> On Mon, 22 Oct 2018 at 22:59, Clemens Lang wrote:
> > On Sun, Oct 14, 2018 at 07:29:04PM +0200, Mojca Miklavec wrote:
> > > What do you think about another MacPorts online meeting next Saturday
> > > (20th) at 13:00 UTC?
> > >
> > > If you are interested in joining:
> > > - Do you have time?
> > > - Or do you propose another weekend which would be more suitable?
> > > - What topics would you like to discuss?
> >
> > Sorry, that didn't fit my schedule. Should we reschedule for a later
> > date?
>
> Yes, suggestions for the date welcome. (So far I'm only busy on the
> 10th Nov, but I'm not even sure when exactly, I might be free by the
> time of the meeting. Any other weekend works so far for me.)
>
> > > My suggestions for topics of discussion:
> > > - Software Freedom Conservancy
> > > - Status of Mojave
> > > - Take a look at open pull requests for base & roadmap
> > > - Meeting in 2019
> >
> > Good agenda.
>
> Mojca
>

Re: Online meeting next Saturday?

[Umesh Singla]

+1 for 20th Oct 1300 UTC

On Fri, Oct 19, 2018 at 1:45 PM Umesh Singla  wrote:

> +1 for 20th Oct, 1300 UTC
>
> On Sun, Oct 14, 2018 at 10:59 PM Mojca Miklavec 
> wrote:
>
>> Hi,
>>
>> What do you think about another MacPorts online meeting next Saturday
>> (20th) at 13:00 UTC?
>>
>> If you are interested in joining:
>> - Do you have time?
>> - Or do you propose another weekend which would be more suitable?
>> - What topics would you like to discuss?
>>
>> Mojca
>>
>> My suggestions for topics of discussion:
>> - Software Freedom Conservancy
>> - Status of Mojave
>> - Take a look at open pull requests for base & roadmap
>> - Meeting in 2019
>>
>

Re: [macports/macports-webapp] Added readme and Database design (7045274)

[Umesh Singla]

Redirecting to the list.

On Thu, May 10, 2018 at 12:50 PM, Andrew Moore <slew...@gmail.com> wrote:

> Nice find.  Table of Contents:
>
> • Separate subject from body with a blank line
> • Limit the subject line to 50 characters
> • Capitalize the subject line
> • Do not end the subject line with a period
> • Use the imperative mood in the subject line
> • Wrap the body at 72 characters
> • Use the body to explain what and why vs. how
>
> I. would add: include a context.  Often I see commit messages like
>
> “Update to version X.Y.Z”
>
> Whereas
>
> "Python: Update to version X.Y.Z”
>
> Is little more effort and much friendlier.
> -AM
>

Totally agree. In fact, the example on MacPorts Commit Messages wiki page
[1] does use this.

[1]: https://trac.macports.org/wiki/CommitMessages#guidelines


- Umesh

> On May 9, 2018, at 5:40 PM, Umesh Singla <umeshksin...@macports.org>
> wrote:
> >
> > Apart from the usual commit guidelines present in the wiki, I found this
> particular blog https://chris.beams.io/posts/git-commit/ really helpful.
> It's quite popular as well and tries to present the solution very
> practically.
> >
> > Go through it in your free time.
> >
> > On Wed, May 9, 2018, 10:02 Jackson Isaac <notificati...@github.com>
> wrote:
> > Try to keep the commit messages in active voice. Take care of
> capitalization too.
> >
> > For e.g., "Add README and database design"
> >
> > Here I have kept README in all caps since that is how the filename also
> is.
> >
> > —
> > You are receiving this because you are subscribed to this thread.
> > Reply to this email directly, view it on GitHub, or mute the thread.
> >
>

Re: [macports/macports-webapp] Added readme and Database design (7045274)

[Umesh Singla]

Apart from the usual commit guidelines present in the wiki, I found this
particular blog https://chris.beams.io/posts/git-commit/ really helpful.
It's quite popular as well and tries to present the solution very
practically.

Go through it in your free time.

On Wed, May 9, 2018, 10:02 Jackson Isaac  wrote:

> Try to keep the commit messages in active voice. Take care of
> capitalization too.
>
> For e.g., "Add README and database design"
>
> Here I have kept README in all caps since that is how the filename also is.
>
> —
> You are receiving this because you are subscribed to this thread.
> Reply to this email directly, view it on GitHub
> ,
> or mute the thread
> 
> .
>

GSoC 2018: Congratulations to the selected student and mentors

[Umesh Singla]

Hello everyone,

Google just announced 1,264 projects for this year's summer of code. I'm
happy to share with you all that as requested MacPorts got one slot for the
following project:

1. Vishnu M
Project: Creating a dynamic website for Ports Index [1]
Mentors: Mojca Miklavec and Jackson Isaac

This goes without saying but I'm just reiterating:

1. I would like the student and the mentors to publicly interact with the
community on the mailing list (preferably under a single thread) and IRC so
that the rest of the community is able to follow the project and help you
in case mentors go temporarily offline.

2. I would like the student and mentors to come up with a communication
plan (how often do you want to meet, platform - mail/IRC/video) as soon as
possible. This is really necessary so everyone has a clear idea from the
beginning what to expect out of the project.

This time until only the mid of May is meant for community bonding period,
so learning any tools required or improving the project plan needs to be
taken up before the official coding period begins.

I hope others will add more to this email. I'll myself add more to this
once my exams get over.

Regards,
Umesh

[1]: https://summerofcode.withgoogle.com/projects/#6208860931489792

GSoC 18: Proof of Enrollment reminder

[Umesh Singla]

Dear students,

While you're busy writing the proposal, discussing with your mentors or
getting feedback, please keep in mind to upload the proof of
university enrollment
on the official GSoC portal before the deadline as the participation stands
canceled on failure to do so.

More details are available on the GSoC website [1].

Regards
Umesh

[1]: https://developers.google.com/open-source/gsoc/help/proof-of-enrollment

Re: Gsoc

[Umesh Singla]

Hi Abhishek

On Mon, Mar 26, 2018, 01:52 Abhishek Kashyap <abhishek.kasya...@gmail.com>
wrote:

> I think it is not mandatory to submit a patch.First priority is Best
> proposals.
> A/c to your template there is no need to mention vision and Gsoc period is
> from
> Comunity bonding period to final submission.It is irrelevant to mention
> the goals after GSOC because its only about GSOC.
> As we can contribute anytime.
> Thank You
>

I do not agree. First it depends on the organization how and when they want
to evaluate the students. Some even go to the extent of video interviewing
the candidates. If you follow blogs about GSoC on internet, it's encouraged
(or recommended) to make contact with the organization as early as possible
and "prove" your ability.

"There is no need to mention vision." Really?

It's not about just GSoC at all. Google wouldn't name a period "community
bonding" unless it means it. It's supposed to introduce school (GCI) and
college students to the world of open source and be a part of larger
community rather than just being a worker in some company. Most of the
members of MacPorts came through GSoC only and stuck to it, whom you now
interact as mentors and admins.

If you don't even agree to maintain your code before even submitting the
application, I don't know how you expect us to help you through the summer.

Regards,
Umesh Singla.


> On 26 March 2018 at 01:11, Mojca Miklavec <mo...@macports.org> wrote:
>
>> On 25 March 2018 at 18:49, Abhishek Kashyap wrote:
>> > Till now i have niether get any feedback nor any sugestion,
>>
>> Organisations were announced on the 12th of February. I believe it is
>> somewhat unrealistic to expect from volunteer mentors from different
>> time zones to study your proposal and write substantial feedback in
>> less that two hours on a day that most would spend away from
>> computers.
>>
>> > What can i do?
>> > Any tips
>>
>> I haven't seen you submit any patches or trying to contribute some
>> code or trying to prove us your competence/ability to finish the
>> project. If you have free time waiting for feedback, it would probably
>> be useful to spend it working on that.
>>
>> Sadly we lack some "good first issue" tag and I'm not sure what would
>> be a suitable easy task that doesn't require a lot of preliminary
>> familiarisation with the base.
>> https://trac.macports.org/wiki/Meetings/MacPortsMeeting2018/Roadmap
>> A simple task where we need help in the ports would be for example this
>> one:
>> https://trac.macports.org/ticket/54839
>>
>> I'm not too familiar with implementation details, but I have some
>> troubles with English in the proposal and there are no "stretch goals"
>> (for example how you could continue after the GSOC, what's the vision
>> for which there would be no time during the summer etc.).
>>
>> Mojca
>>
>
>

Re: Gsoc

[Umesh Singla]

Please keep the discussion on the mailing list.

On Mon, Mar 26, 2018 at 2:58 AM, Vishnu  wrote:

> Hi,
>
> I wanted some help in build bot summary.
> I am not sure i completely understand what's happening here.
> Could you please explain me about buildbot summary more?
>
> what i understand is :
> There can be n number of builds for each port.
> So how am i supposed to get the information of what all builds have
> already been done for that particular port.Where can i find that history
> from? from build.macports.org ?
>
>
> First and foremost I think first i have to implement the Buildbot idea
> .That would create logs.
> But for that idea..how to get all the exiting build history of ports?Build
> history such as timestamp,os,Succesful or not?
> Where to get exclusive information about a port.
>
>
> Please help me understand the concept.
>
> Thanks
>
> On 26 March 2018 at 02:13, Vishnu  wrote:
>
>> Thanks.. I will work upon the feedback.
>>
>
Thanks.

Re: Gsoc

[Umesh Singla]

Hi Vishnu,

I think the designated mentor to your project Mojca already gave you a
feedback on the previous mailing thread and I don't see any improvement in
the proposal. Here is the link to email if you missed it -
https://lists.macports.org/pipermail/macports-dev/2018-March/037885.html.

Thanks,
Umesh

On Mon, Mar 26, 2018 at 2:01 AM, Vishnu  wrote:

> Can i please get a feedback for my proposal.
>
> Thanks
>

Re: GSOC

[Umesh Singla]

Hi

You'll need to create an account on GSoC website first:
https://summerofcode.withgoogle.com/ and update your personal details.

Write your proposal in a Google Doc (or copy-paste it if you already have
written) and share the link on the above website with permission for us to
comment on it. I think you'll need to submit the proposal by searching for
MacPorts in the organization list and clicking on "Apply" button or
something similar.

Thanks and let me know if you need any help with it.

Umesh.

On Sun, Mar 25, 2018 at 12:07 AM, Abhishek Kashyap <
abhishek.kasya...@gmail.com> wrote:

> I am not asking how to write proposal i asking how to draft it?
> I have already written my proposals its only needs to be drafted.
> Thank you
>
> On 24 March 2018 at 22:15, Mojca Miklavec  wrote:
>
>> On 24 March 2018 at 14:49, Abhishek Kashyap wrote:
>> > How to draft a proposal ?
>> > I want to submit earlier for feedback and review.
>>
>> Our template is here:
>>
>> https://trac.macports.org/wiki/SummerOfCode#AboutUs
>> https://trac.macports.org/wiki/SummerOfCodeApplicationTemplate
>>
>>
>> Below are some tips and blog posts that have recently been posted to
>> the mentors' mailing list which you might find useful.
>>
>> https://google.github.io/gsocguides/student/writing-a-proposal
>> https://google.github.io/gsocguides/student/proposal-example-1
>> https://google.github.io/gsocguides/student/proposal-example-2
>>
>> https://medium.freecodecamp.org/hacking-gsoc-how-to-gain-rea
>> l-life-experience-and-support-open-source-b1e6a664f6e4
>> https://medium.com/@owtf/google-summer-of-code-writing-a-
>> good-proposal-141b1376f076
>> http://mirca.fun/gsoc-application/
>> http://wiki.apertium.org/wiki/Top_tips_for_GSOC_applications
>> https://www.mixxx.org/wiki/doku.php/gsocadvice#application_
>> evaluation_criteria
>> https://docs.google.com/presentation/d/1IRB2nnO1yxG348u_QjEJ
>> khoxiq9C9C7nnDOFC6vUz3M/edit?usp=sharing
>>
>> Mojca
>>
>
>

Re: Buildbot idea(s) for GSOC

[Umesh Singla]

Hi Mojca

See inline.

On Wed, Mar 7, 2018 at 3:22 AM, Mojca Miklavec  wrote:

> Dear Umesh,
>
> In case we would get any good students in that area, I would be
> grateful if someone would work on improving buildbot core & front-end
> in close collaboration with mentors directly from buildbot.
>
> I added this one idea on the list, but it needs some polishing:
> https://trac.macports.org/wiki/SummerOfCode#Buildbotideas
>
> However, in order to attract potential students, we would likely need
> to add a few suitable keywords to our "description", like perhaps
> "frontend". But we would also need to make it easier for such students
> who end up on our site to actually spot such projects without browsing
> through the full list.
>

I can add some tags like frontend or javascript on GSoC website to include
MacPorts in the search results. Probably the tag "End User Applications"
doesn't help much.

Maybe, we can divide the project list into 3 sections - infrastructure
based projects, macports-base and ports (or documentation-based as well?).
Trac, as compared to other orgs' fancy websites these days, doesn't help
much to attract students (one simple reason could be very small fonts or
not easily searchable). I couldn't have chosen any project, if it wasn't
for Jackson who helped me out last year.

The ideas which are not finalized or are still being discussed can be put
on to some other page or where mentors are not available for that year.
Something like general MacPorts projects and current year eligible-GSoC
projects.


> Buildbot participated in GSOC before, but did not apply this year.
> They would be willing to mentor and we really need some features
> implemented if we want to go for buildbot 1.0 setup one day. (That
> said, I would find it ok even if some project from buildbot mentorship
> is not strictly macports-oriented.)
>

I'll add someone's name from Buildbot to the project you added (I think
Pierre Tardy agreed to mentor?) along with "from Buildbot community" in the
description. But I'd say we should work on what exactly we mean by "make
Buildbot 1.0 a lot more useful for MacPorts". I haven't gone through the
threads about Buildbot on this list, maybe will do now.


> Another project we could put on the list would be figuring out how to
> start clean VMs for each build, but that might be tricky and the
> student would need to be able to figure that out on his own.
> Apparently buildbot supports that for Linux.


Not sure but can Jenkins help here? Usually you need a yaml file and a xml
file and provides quite a number of plugins to customize unlike Travis. It
would be a big shift though.

Umesh.

Re: GSOC 2018

[Umesh Singla]

Hi

You are welcome to select multiple ideas provided you're able to
communicate about it with mentors and propose on time. Only the best one
proposal will be selected.

Generally it's better to pay attention to understand one project's
requirements and expectations to get started with a community.

We don't have terms and conditions per se. A student will need a macOS
machine for most of the projects and proved ability to code, debug and
follow through. The discussion within the community about the project
usually tells a lot about the student.

Umesh.

On Mar 2, 2018 1:47 AM, "Abhishek Kasyap" 
wrote:

Can i select more than one idea in this organisation.What is terms and
condition of this Gsoc project.

Re: Suggestions for hacking sessions & discussions for the MacPorts meeting in March

[Umesh Singla]

On Thu, Feb 22, 2018 at 12:26 AM, db  wrote:

> On 21 Feb 2018, at 17:33, Mojca Miklavec  wrote:
> > - New website!
>
> Homebrew/Linuxbrew's are good examples to get up and running quickly, and
> still have updated technical documentation.


or ReadTheDocs (rst files, easy to manage the directory structure, can use
templates)? Website is more-or-less documentation only in our case.

Re: GSoC 2018 Project: Improve startupitem code

[Umesh Singla]

Brad, any thoughts on this? We already have a student interested in this
project.

And thanks for informing, Josh.

On Wed, Feb 14, 2018 at 8:15 PM, Joshua Root <j...@macports.org> wrote:

> On 2018-2-14 22:11 , Umesh Singla wrote:
> > For any discussions on this project, we can follow this thread. I am
> > cc'ing dev list if anyone has any question or idea or extension to it.
> >
> > > The first thing I would like you to do is to go through our
> current list of projects on Trac [0].
> > >
> > > Try adding/updating the descriptions for your projects or let me
> know. Remove anything which is outdated. As you probably know, you can also
> propose a new idea.
> > >
> > > Also, is there any project which you would like me to move up on
> the list? Currently, there are two projects on the list, "Improve
> startupitem code" and "Generating Portfiles" listing you as a potential
> mentor.
> >
> >
> > I’d love to see the startup item code more closely mirror the
> > capabilities of launchd :)
> >
> > It would be able great to write some short hand in a portfile that
> > builds an xml launchd plist.
> >
> >
> > That's good to know. I've moved this project up the list.
>
> Just a heads-up, I have been reviewing all the tickets about
> startupitems recently (after having ideas percolate for a long time) and
> have just started committing code. I may close most or all of the
> existing tickets in the not too distant future.
>
> No doubt there is still more that could be done; just be aware this work
> is happening when planning any potential GSoC project.
>
> - Josh
>

GSoC 2018 Project: Improve startupitem code

[Umesh Singla]

For any discussions on this project, we can follow this thread. I am cc'ing
dev list if anyone has any question or idea or extension to it.

> The first thing I would like you to do is to go through our current list
> of projects on Trac [0].
> >
> > Try adding/updating the descriptions for your projects or let me know.
> Remove anything which is outdated. As you probably know, you can also
> propose a new idea.
> >
> > Also, is there any project which you would like me to move up on the
> list? Currently, there are two projects on the list, "Improve startupitem
> code" and "Generating Portfiles" listing you as a potential mentor.
>
>
> I’d love to see the startup item code more closely mirror the capabilities
> of launchd :)

It would be able great to write some short hand in a portfile that builds
> an xml launchd plist.


That's good to know. I've moved this project up the list.

Umesh.

Re: GSoC 2018 Collect Build Statistics Project

[Umesh Singla]

Hi Ayush

On Wed, Feb 14, 2018 at 12:56 PM, Mojca Miklavec  wrote:

> Dear Ayush,
>
> Can you please write to the macports-devel mailing list instead? We
> would like to avoid private discussions regarding GSOC unless it's
> about sensitive/personal issues.
>

Subscribe to the list at https://lists.macports.org/mai
lman/listinfo/macports-dev, so that others can also provide inputs on it. All
the mentors are subscribed to the mailing list as well so emailing the
mailing list is equivalent to emailing all of the mentors.


>
> On 13 February 2018 at 13:50, Ayush Agrawal  wrote:
> > Hello,
> >
> > I am interested in working on project "Collect Build Statistics" under
> your
> > mentorship for the GSoC 2018 . I have pretty much experience of working
> in
> > python and JSON in different projects. Hence i would like to work on this
> > project.

>
> > I also wanted to ask whether this project can be done without Mac or not
> ?
>

Your skills are appreciated but there could be certain aspects of the project
where you will need to actually test the results by running a build instance,
so it would be much easier if you could run a build on your local machine,
for which you'll need macOS.

Umesh.

Re: GSOC mentors

[Umesh Singla]

Excited to announce that MacPorts has been accepted for another round of
Google Summer of Code program [0].

[0]: https://summerofcode.withgoogle.com/organizations/5306590446485504/

- Umesh

On Thu, Feb 1, 2018 at 12:54 AM, Jackson Isaac <ijack...@macports.org>
wrote:

> Hi Umesh,
>
> On Mon, Jan 29, 2018 at 11:46 AM, Umesh Singla
> <umeshksin...@macports.org> wrote:
> >
> > Hi
> >
> > On Mon, Jan 29, 2018 at 4:54 AM, Mojca Miklavec <mo...@macports.org>
> wrote:
> >>
> >> Dear Umesh,
> >>
> >> I would remove "secondary mentor" from the list of mentor who agreed.
> >
> >
> > I removed the list of mentors completely and working on revamping
> project ideas for getting our application in. I have kept it here [1] which
> is not straight visible to students/GSoC admins and helps us to track.
>
>
> Thanks! The new Ideas page looks good and organized. Probably keep the
> mentors table below the Admins table, since GSoC team have been shared
> that particular page ? They would want to know who the mentors are
> this year. Now it looks like there are only admins.
>
> >
> >
> >>
> >> It looks like we have almost no mentors this year.
> >
> >
> > Even if we are able to pull at least one project, it should be good. Not
> participating at all actually reduces the number of students interested
> next year because they tend to work-with/contribute-to organizations which
> have participated in the previous year.
> >
>
> This year looks promising from interest shown by mentors and projects
> they are coming up with. Thanks to the mentors too :)
>
> --
> Jackson Isaac
>

Re: GSOC mentors

[Umesh Singla]

Hi

I have already reached out to Michael, Bradley, jeremyhu, Lawrence, Rainer
yesterday with the projects they have currently on the list and that we
have Mojca and Clemens up to lend helping hands as backup-mentors.

On Mon, Jan 29, 2018 at 11:24 AM, Jackson Isaac 
wrote:

> Hi,
>
> I believe Michaels' project idea would be focusing more on the port
> side i.e., Qt5.
>
> From the tentative mentor list, I came up with teaming up the
> following mentors together:
>
> 1. I would say Michael and Mojca be the mentors for this project since
> both are familiar with port management (Mojca being more familiar with
> macports-ports than macports-base).
>
> 2. Clemens and I can be mentors for project based on macports-base.
>
> Clemens,
>
> Do you have something in particular that we might wanna do this year ?
>
> I was thinking about re-designing the portindex and the
> installation/uninstallation phases to try and adapt to libsolv solv
> repo. We can ask the student to understand and work on libsolv branch
> and submit patches for evaluation during application phase. Although
> this won't be the main idea for 3 months duration but more as a side
> project for evaluating the student skills.
>

It'd be great if you two are able to collaborate and work on an idea.
Jackson, if you have near-fully developed idea in mind, you can go ahead
and add it to the list.


> Umesh,
>
> We would need to come up with more guidelines for applicants. The
> process feels lenient right now, I would like to add some tasks that
> students should complete before being considered for GSoC.
>

Sure, we can work on that.


> Will also need to update the potential mentor list on Ideas pages
> after we get confirmations from other mentors and ideas that we want
> to implement this year. Can we have some kind on high priority tasks,
> good to haves, and experimental projects sections or something of that
> sort ?


High priority tasks need to be decided by the community. Until we come up
with something, it's better keep the projects for which mentors are
available higher on the list.


- Umesh

Re: Fwd: [GSoC Mentors] GSoC Org Ideas List should be solid by this Monday at 19:00 UTC for review

[Umesh Singla]

 No, I'm not receiving the emails from mentors list and the content on the
GoogleGroups is not visible to me.

I at least moved the Qt5 project up in the list after confirmation from
Michael Dickens, but can work on improving the project descriptions now,
sure.

Thanks for letting me know.

On Jan 29, 2018 12:14 AM, "Jackson Isaac"  wrote:

> Hi Umesh,
>
> I hope you are receiving mails from GSoC Mentors list.
>
> We might need to revamp our Ideas page. Although there are tasks on
> Ideas list, we might have to work on verifying which tasks are doable
> and have potential mentors for, this year. Brainstorm any new ideas
> that we can add would also help.
>
> Devs,
>
> Please add detailed ideas to the list, if any.
>
>
> -- Forwarded message --
> From: 'Stephanie Taylor' via Google Summer of Code Mentors List
> 
> Date: Sun, Jan 28, 2018 at 1:35 PM
> Subject: [GSoC Mentors] GSoC Org Ideas List should be solid by this
> Monday at 19:00 UTC for review
> To: Google Summer of Code Mentors List
> 
>
>
>
> Hi all,
>
> It seems quite a few veteran orgs have 0, or very few, projects listed
> on their Ideas List for their GSoC Org apps. Some have something like
> "coming soon" with no actual ideas on their page - this will result in
> an automatic rejection - please don't let that be you!
>
> Our team has been reviewing hundreds of applications this week and
> taking notes and we have noticed MANY orgs that have not completed
> their lists (have 1-2 ideas or ideas with 1 sentence describing the
> problem) or say 'coming in March', 'coming soon', etc. That's a
> 'Reject in our book.
>
> We will meet Monday, Jan 29 as a team to start our multi day meetings
> going through each and every org application together so you have
> until Monday at 19:00 UTC to get your ideas onto your list. You can
> always add more ideas later but if you are an Umbrella Org you should
> have plenty of ideas listed now - and if you are a smaller org you
> should have 4-5 well developed ideas minimum.
>
> And please don't just link to a bug tracker. If the bug tracker has
> extensive descriptions about the project/problem then that can
> sometimes be fine. But just saying here are 5 things we want worked on
> and a sentence about each isn't going to cut it.
>
> If you are an Org Admin I strongly encourage you to go back and look
> at your Ideas List before Monday at 19:00 UTC and make sure it is
> representative of what you want us to evaluate.
>
> Every year we have a few orgs who give us bad URLs or don't give us
> access permission to see their Project Ideas List. Again, please don't
> be that org... (your community will not be happy).
>
> Remember, the #1 thing our team considers when choosing which orgs to
> accept is the quality of the Project Ideas list. If you have nothing
> for us to look at we have to reject you.
>
> Please don't ask us to go and see if your application is okay. If you
> have a solid Project Ideas List and have read the Defining a Project
> Ideas list from the Mentor Guide and followed the advice your list is
> likely good to go.
>
> Best,
> Stephanie
>
>  Stephanie Taylor
>  Open Source Programs, Google
>  sttay...@google.com
>
>
>
> --
> You received this message because you are subscribed to the Google
> Groups "Google Summer of Code Mentors List" group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email to google-summer-of-code-mentors-list+unsubscribe@googlegroups.
> com.
> To post to this group, send email to
> google-summer-of-code-mentors-l...@googlegroups.com.
> Visit this group at
> https://groups.google.com/group/google-summer-of-code-mentors-list.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/google-summer-of-code-
> mentors-list/CAEp7XcT%2BacNEJP7E0ZYr742_xDFcJDQkB_
> DEB-gRwa9FKsOvEA%40mail.gmail.com.
> For more options, visit https://groups.google.com/d/optout.
>
> --
> Jackson Isaac
>

Re: Query on Participating in Gsoc 2018

[Umesh Singla]

Hi and welcome to the MacPorts community!

Iam Ankit Khatri,student 2nd year in NIT
> kurukshetra,India. Iam a beginner and want to know how to get started with
> MacPorts and contribute to it for GSOC-2018.I know Python and its
> framework(Django),Javascript,Jquery,Php,html5,css3,Java and I have worked
> on certain projects related to the same and i will learn many more new
> concepts in these languages in future.I was also selected as MICROSOFT
> STUDENT PARTNER, in which i have conducted various workshops and worked on
> various projects with best people around the country which were part of
> this MICROSOFT STUDENT PARTNER program.I know Python and its
> framework(Django),Javascript,Jquery,Php,html,css and other languages and
> have also worked on some projects using them.
>

I want to contribute to your organisation and want to get started, so
> Please guide me further on this.
>

Glad you are interested in helping out. It could be too early because the
final list of organizations is not out yet by Google but we're always happy
to see new students and their enthusiasm towards Open Source.

You might want to take a look at Tcl, as most of our codebase is written in
Tcl with some low-level parts in C. Now knowing Tcl shouldn't be an issue,
it can always be learned here [1].

You might want to start by installing MacPorts by source on your machine
and play around a little. Check out the guide here [2].

You have probably seen our Ideas Page on our wiki [3], if you haven't, make
sure to check it out. Most of the useful instructions and the list of ideas
are in there. Look for something that interests you.

If you have any queries, drop a message in the mailing list (cc'ed) or IRC
at #macports on Freenode.

[1]: http://www.tcl.tk/man/tcl8.5/tutorial/tcltutorial.html
[2]: https://guide.macports.org/#installing
[3]: https://trac.macports.org/wiki/SummerOfCode

Best,
Umesh Singla

Re: GSoC 2018 Application

[Umesh Singla]

Hi

On Sat, Jan 13, 2018 at 10:04 AM, Jackson Isaac 
wrote:

>
> > I have registered MacPorts for participating in GSoC this year and
> submitted
> > the initial version of the application from MacPorts side on GSoC'18 [0]
> > website, in coordination with Jackson.
>
> Thanks for filling out the form. I had a quick glance. We still need
> to refine the answers, correct ?


Yes, they still need improvement. I'm on it.


> Clemens, Mojca, Bradley,
>
> Are you in for mentoring this year again ? Also we need to decide what
> tasks need to be done this year as part of GSoC.
>

And also, if we are planning on any primary goals this year?

Thanks.

GSoC 2018 Application

[Umesh Singla]

Hi,

Following the conversation on the dev mailing list, I have assumed the role
of organization administrator and Jackson Isaac as backup administrator and
a potential mentor for now.

I have registered MacPorts for participating in GSoC this year and
submitted the initial version of the application from MacPorts side on
GSoC'18 [0] website, in coordination with Jackson.

The corresponding pages of our Trac have been updated.

The application questionnaire [1] and the ideas page [2] have been modified
to include this year's dates and other relevant information.

Please feel free to suggest any improvements.

@Jackson: I invited you to be a backup admin from GSoC's website. Please
check and approve.

[0]: https://summerofcode.withgoogle.com/
[1]: https://trac.macports.org/wiki/SummerOfCodeOrgApplication
[2]: https://trac.macports.org/wiki/SummerOfCode

Regards,
Umesh Singla

On Mon, Jan 8, 2018 at 1:13 PM, Mojca Miklavec <mo...@macports.org> wrote:

> Hi,
>
> The GSOC 2018 application period for organisations is now open,
> deadline for applying in January 23rd.
>
> I hope we are going to participate this year as well?
> If so, it would be about time to come up with additional ideas and
> clean up the ideas page.
>
> Mojca
>

Re: MacPorts Meeting 2018

[Umesh Singla]

Hi Mojca,

I think, by now, we should have a Wiki or a Trac page for the event
details. It'll be just easy to redirect people to this page for details.
Till now, we only have communication over the emails. Something like
https://trac.macports.org/wiki/Meetings/MacPortsMeeting2016.

Let me know if you need help create/manage the page.

Thanks

On Wed, Jan 10, 2018 at 1:10 AM, Mojca Miklavec  wrote:

> Hi,
>
> The meeting will take place from 10th to the 14th March. I managed to
> negotiate a much lower price for the same location as in 2016 (close
> to Kranjska gora), but we can still discuss some alternatives. The
> important part is to mark the dates on your calendar now. The price
> should be around 250 EUR, but more information to follow.
>
> Mojca
>
> On 8 January 2018 at 00:11, Mojca Miklavec  wrote:
> > Hi,
> >
> > It's time to set the final date for the MacPorts meeting 2018. Given
> > the initial poll results + some individual emails we are now
> > constrained to any time between Saturday the 10th and Tuesday the 20th
> > of March 2018. Those who want to come, please reply ASAP in case one
> > option does not suit you (a confirmation that both are fine is also
> > helpful) or suits you less. I would like to announce the final date
> > within a day or two maximum, so that people who come from other
> > contents can book their flights.
> >
> > Most wanted to start on Friday, but I guess the main idea was to be
> > able to take as little holidays at work as possible (so in principle
> > starting on Wednesday or Thursday should be kind of ok as well?)
> >
> > Option 1: Friday March 16th - Tuesday March 20th (potentially up to
> > two days earlier)
> > Option 2: Saturday March 10th - Wednesday March 14th
> >
> >
> > Option 1 coincides with many popular sport events, so we cannot book
> > the same house as last year (or another cute nearby location next to a
> > ski center on Pokljuka), but there is a sufficient number of
> > alternatives. (The same location as in 2016 would require quite a bit
> > of additional negotiation anyway since their initial offer was super
> > expensive compared to last time.)
> >
> > Even if date-wise Option 2 would probably be more favourable, the
> > number of working days involved will probably lead to Option 1.
> >
> > Mojca
>

ui_options(questions_singlechoice)

[Umesh Singla]

Hi, devs

I have to use $macports::ui_options(questions_singlechoice) for a project
on a list of some other registry data structure (snapshot) and not ports.
It gets displayed in the following manner on terminal:

Select any one snapshot to restore:

 1) ::registry::snapshot0

 2) ::registry::snapshot1

 3) ::registry::snapshot2

 4) ::registry::snapshot3

Enter a number to select an option:


I would like to know how to display useful information enough to identify
instead of "::registry::snapshot0" or "::registry::snapshot1". A
registry::snapshot has id, note, created_at fields.

Thanks for any help.

Re: [GSoC] migration

[Umesh Singla]

Hi all,

Sorry, I got caught up in academics and college stuff. Continuing from
where I left:

1. I broke migrate action into two parts - `port migrate` followed by `port
restore --last` to achieve the functionality we wanted. Now, migrate
creates a snapshot, uninstalls the ports and upgrades the port command
using forced and nosync selfupdate.

2. Restore now has 3 variations - `port restore`, `port restore --last`,
`port restore --snapshot-id=$some_id`.
i. `port restore` asks the user to select a snapshot interactively to
restore. It deactivates the currently installed ports and restore the
selected snapshot.
ii. `port restore --last` restores the last snapshot.
iii. `port restore --snapshot-id=$some_id` restores the specified
snapshot. It also deactivates the current state.

3. I have tried adding error handling and documentation as much as possible
but always open to suggestions and improvements.

Keeping this aside, I still wonder what happens in case port command
doesn't work on an upgraded OS at all and user doesn't have any or recent
snapshot in the registry. We won't be able to create a snapshot in
migration step.

Regards,
Umesh Singla


On Sat, Sep 9, 2017 at 3:48 AM, Joshua Root <j...@macports.org> wrote:

> On 2017-9-9 08:10 , Rainer Müller wrote:
>
>> On 2017-09-08 23:33, Umesh Singla wrote:
>>
>>> When I run the `migrate` action with only one port (expat) installed, I
>>> get the following:
>>>
>>> $ sudo ./bin/port migrate
>>>
>>> Taking a snapshot of the current state...
>>>
>>> Done: Snapshot '8':'snapshot created for migration' created at
>>> 2017-09-08 21:09:21
>>>
>>> Migration will first uninstall all the installed ports, upgrade MacPorts
>>> and then reinstall them again. Would you like to continue? [Y/n]: Y
>>>
>>
>> I would like to repeat that upgrading MacPorts from the 'port migrate'
>> action is not possible. After a major upgrade of macOS we cannot
>> guarantee that the old version of MacPorts runs at all on this new OS
>> version. MacPorts has to be reinstalled for the new OS version in an
>> extra step before.
>>
>> The best you can do is printing instructions on where to download
>> MacPorts.
>>
>
> I think that doing a forced selfupdate is probably possible in most cases.
> You just can't do everything in one run.
>
> - Josh
>

Re: Fwd: Google Summer of Code 2018

[Umesh Singla]

On Sep 26, 2017 2:09 AM, "Mojca Miklavec"  wrote:

Forwarding a message from Google ...
..

Last week we also announced the Google Code-in 2017  (GCI)
contest for 13-17 year old students. GCI is open for past GSoC mentoring
organizations to apply to be a part of this exciting contest from October
9th - October 24th. We are also giving GCI orgs over a month to enter their
tasks into the webapp, hopefully this will help them prepare for the busy
winter contest. GCI opens for student participants on November 28th! You
can read more about the program on our blog

.


Have we ever participated in GCI before?

Re: [GSoC] migration

[Umesh Singla]

Hi all,

When I run the `migrate` action with only one port (expat) installed, I get
the following:

$ sudo ./bin/port migrate

Taking a snapshot of the current state...

Done: Snapshot '8':'snapshot created for migration' created at 2017-09-08
21:09:21

Migration will first uninstall all the installed ports, upgrade MacPorts
and then reinstall them again. Would you like to continue? [Y/n]: Y

Uninstalling all ports...

Uninstalling: expat

--->  Deactivating expat @2.2.4_0

--->  Cleaning expat

--->  Uninstalling expat @2.2.4_0

--->  Cleaning expat

Upgrading MacPorts...

--->  Updating MacPorts base sources using rsync

MacPorts base version 2.4.99 installed,

MacPorts base version 2.4.1 downloaded.

--->  MacPorts base is outdated, installing new version 2.4.1

Installing new MacPorts release in /GSoC17/macports-test as root:admin;
permissions 0755


Fetching ports to install...

Restoring the original state...

MacPorts Version: 2.4.99

Installing (and activating): expat

--->  Fetching distfiles for expat

--->  Verifying checksums for expat

--->  Extracting expat

--->  Configuring expat

--->  Building expat

--->  Staging expat into destroot

--->  Installing expat @2.2.4_0

--->  Activating expat @2.2.4_0

--->  Cleaning expat

$


Since I have an updated version of registry db (v1.203) as opposed to its
current version (v1.202), I have a doubt if the above should have proceeded
in the way it did. I was expecting it to break after MacPorts base gets
upgraded complaining something of the sort, "Version number in metadata
table is higher than expected".

Does it mean that new port command is not being used for the next step of
installation? Or it's fine because mportinit didn't get initialized again?

- Umesh

Re: [GSoC] migration

[Umesh Singla]

@Brad, for `migrate`, we're only installing requested ports but for
`restore`, I imagine we will be installing all of them, after sorting?

- Umesh

On Sat, Sep 2, 2017 at 6:48 PM, Umesh Singla <umeshksin...@macports.org>
wrote:

> Hi Mojca,
>
> On Thu, Jun 15, 2017 at 12:05 AM, Mojca Miklavec <mo...@macports.org>
> wrote:
>
>> On 14 June 2017 at 05:47, Umesh Singla wrote:
>> >
>> > Okay, since there's already a OS comparison made, which I think can be
>> > directly used here. But to clarify, just the OS check? a check on
>> x86_64/ppc
>> > changes is also needed.
>>
>> And potentially cxx_stdlib?
>
>
> How can such a check be made possible? All we have at present is here,
> [0]. It doesn't compare stored values and current platform values. Are you
> suggesting a manual check while migration?
>
> - Umesh
>
> [0]: https://github.com/macports/macports-base/blob/
> master/src/macports1.0/macports.tcl#L1050-L1057
>
>

Re: Switching cxx_stdlib for C++11 on legacy macOS (was: Re: [GSoC] migration)

[Umesh Singla]

On Sat, Sep 2, 2017 at 9:55 PM, Rainer Müller <rai...@macports.org> wrote:

> On 09/02/2017 03:18 PM, Umesh Singla wrote:
> > On Thu, Jun 15, 2017 at 12:05 AM, Mojca Miklavec <mo...@macports.org
> > <mailto:mo...@macports.org>> wrote:
> >
> > On 14 June 2017 at 05:47, Umesh Singla wrote:
> > >
> > > Okay, since there's already a OS comparison made, which I think
> can be
> > > directly used here. But to clarify, just the OS check? a check on
> x86_64/ppc
> > > changes is also needed.
> >
> > And potentially cxx_stdlib?
> >
> >
> > How can such a check be made possible? All we have at present is here,
> [0]. It
> > doesn't compare stored values and current platform values. Are you
> suggesting a
> > manual check while migration?
>
> I do not think we need any special check at migration, as a rebuild will
> always
> use the current setting in macports.conf. However, after editing the
> default
> cxx_stdlib in macports.conf all affected ports need to be rebuild and
> linked
> with the new default to avoid problems later when installing new ports.
>

As stupid as it seems but I don't see any cxx_stdlib option in my
macports.conf (see attached). Option $macports::cxx_stdlib seems to be
configured while mportinit (which means runtime, I guess) depending on
$os_platform and $os_major. So, it should suffice not to check for it.

The fact that surprises me is that even $mapcorts::build_arch is left to
configure on runtime depending on again, only $os_platform, $os_arch and
$os_major and they are NOT stored anywhere (macports.conf or
macports::autoconf namespace). All these options come from $tcl_platform
which will change as soon as the platform changes. So, this says that only
the check like this:

{($os_platform ne $macports::autoconf::os_platform) || ($os_major !=
$macports::autoconf::os_major)}

should be enough for suggesting to migrate. I'm not able to find any way to
include the check on, as quoted in migration guide, "architecture
migrations (e.g., from PowerPC to Intel)" which could be helpful.

Also, if it is, I can simply add migrate action to run `-f selfupdate`
because it seems that selfupdate.tcl handles downloading and installing a
appropriate macports-base release. Any help is appreciated.


> The following goes beyond your GSoC project, but I think it fits into this
> discussion. Back in May, I published an experiment on my GitHub repo that
> I had
> lying around. This adds functionality to stores the cxx_stdlib option in
> registry, such that 'port outdated' will consider ports as outdated if the
> registry entry does not match the cxx_stdlib option in macports.conf.
>
> This was originally written to support switching the cxx_stdlib from
> libstdc++
> to libc++ on old releases of OS X in order to support C++11. However, I
> personally lost interest to support legacy systems any longer and do not
> run any
> of them any more.
>
> https://github.com/raimue/macports-base/commit/c4386f8c5be01
> e3f8eeba9e351373df860d9d8ab
>
> WARNING: Do not install this commit/branch over your regular prefix as
> it will upgrade the SQLite registry.db and make it incompatible with
> MacPorts 2.4.x or master!


Sure, this is a helpful point to keep in mind. Though, any reasons to not
switch to libc++?

I am not sure how useful this experiment is yet, because this approach
> still has a number of problems and shortcomings:
>
> * show stopper: cxx_stdlib is stored for all ports, not only those
>   actually linking against the C++ stdlib
> * cxx_stdlib cannot be changed separately for a single port
>   This might be necessary for some ports that want to link against
>   system frameworks and do not link against anything else. Such a port
>   is now always be considered outdated.
> * I did not know/think of libstdc++ vs. macports-libstdc++
> * archivefetch does not yet respect cxx_stdlib in any way
>
> For some of these problems, I don't know how they should be solved,
> especially the first show stopper. But maybe this helps to get the ball
> rolling a bit more.


I obviously can't suggest anything right now but once I wrap up, I'll try
looking more.

- Umesh


macports.conf
Description: Binary data

Re: [GSoC] migration

[Umesh Singla]

Hi Mojca,

On Thu, Jun 15, 2017 at 12:05 AM, Mojca Miklavec <mo...@macports.org> wrote:

> On 14 June 2017 at 05:47, Umesh Singla wrote:
> >
> > Okay, since there's already a OS comparison made, which I think can be
> > directly used here. But to clarify, just the OS check? a check on
> x86_64/ppc
> > changes is also needed.
>
> And potentially cxx_stdlib?


How can such a check be made possible? All we have at present is here, [0].
It doesn't compare stored values and current platform values. Are you
suggesting a manual check while migration?

- Umesh

[0]:
https://github.com/macports/macports-base/blob/master/src/macports1.0/macports.tcl#L1050-L1057

Re: [GSoC 2017] Final Evaluations + Preparation

[Umesh Singla]

Hi Brad,

On Fri, Sep 1, 2017 at 12:19 AM, Bradley Giesbrecht <pixi...@macports.org>
wrote:

> The evaluation is dependent on the work and effort. We need you to
> communicate the details of what has been accomplished, what works, doesn’t
> work and future plans.
>

Sure.

Effectively, my project had three course of actions to implement -
snapshot, migrate and restore. Out of them, migrate and restore both
depended on the snapshot action largely and also, I divided each of these
actions into procedures or simpler steps further as you probably know from
my previous mails throughout the term. I have the following points to make.
I welcome all kinds of comments.

1. snapshot action is entirely finished for now.

   - All the Tcl and C functions for creating a snapshot, fetching a
   snapshot given its id, fetching a list of recent snapshots, fetching
   properties of a certain snapshot have been finished.
   - This required me to create a new entity named reg_snapshot and wrote
   all the helper functions as well in util.c as were there for entry, file,
   portgroup etc.

2. restore action is also finished for now.

   - It takes an optional argument as 'port restore --snapshot-id ' if
   you want to pass in a certain snapshot or without the argument, it lists
   the snapshots on the console and asks user to select an id and proceeds.
   - It first deactivates all the currently active ports and then
   reproduces the install commands for the selected snaphsot. NOTE that it
   doesn't uninstall the original ports, as desired for the minimal build.
   - But before deactivating, it first sorts the portlist in a way that
   dependencies come later.
   - And also, before installing the selected snapshot, it first sorts the
   ports from the snapshot in a way that dependencies come first.
   - I have used "registry::run_target" directly for doing all this and
   tried testing by modifying registry.db locally with many of the scenarios I
   could think of.

3. migrate action had essentially four steps - a) creating a snapshot, b)
uninstall the current ports, c) upgrade port command and d) restore the
last snapshot.

   - Out of these 4, creating a snapshot and restoring are simply imported
   from the respective modules.
   - I have finished the procedure for uninstalling the ports, and verified.
   - The one task that is left to commit, is to cover, if even possible,
   all the scenarios where we need to look for upgrading port command, that
   is, basically check for the change in OS or arch in macports.conf.
   - While I have added the most simple checks for it like here [0], there
   was a wonderful discussion thread on it by Mojca [1] and Clemens [2]
   yesterday covering many good cases like change of compiler, for one or
   change in libraries by Apple, for two. This is what I am working on as
   informed by my last update.

4. I have added most of the documentation for all the modules, functions
and any important steps, listed any minor TODOs in the code itself, added
ui_msg statements, cleaned the code etc.

5. Apart from this, I have been trying to get involved more in the
community on the dev mailing list and as Ken pointed out that writing a
portfile is not a task too difficult, I have been looking at portfile
tutorial as well.

6. Future Plans related to the project:

   - First, finish the part of migration left.
   - Write testcases.
   - On mportinit, we should suggest the user to run `port migrate` instead
   of (or in addition to) the link to migration guide.



> Your branch of base does not build for me, is that expected?


No, it's not expected. It should build. It builds for me locally and almost
all the Travis CI builds have been successfully passing for about last 15
days [3]. Here are the Travis build logs from my last commit [4]. Can you
tell me the error you're getting?

I guess, I'll update my blog with this email. Thanks again for asking for
updates. I only have these points to make at present, but I'll try to
update you with any new developments soon.

Regards,
Umesh Singla

[0]:
https://github.com/macports/macports-base/blob/e3a0dc2ebde62a9c5feac6a1edee1708a95bb02a/src/macports1.0/macports.tcl#L651-L656
[1]:
https://lists.macports.org/pipermail/macports-dev/2017-August/036323.html
[2]:
https://lists.macports.org/pipermail/macports-dev/2017-August/036311.html
[3]: https://github.com/macports/macports-base/commits/gsoc17-migrate
[4]: https://travis-ci.org/macports/macports-base/builds/269010852

Re: [MacPorts] Migration modified

[Umesh Singla]

Hi

On Tue, Aug 29, 2017 at 8:30 PM, Rainer Müller  wrote:

> On 2017-08-29 16:41, Arno Hautala wrote:
> > Just as a message is sent to the user list when a new MacPorts version
> > is posted, a message could be sent when a new OS is released that
> > reminds users that migration will be required.
>
> Such a message would probably only reach a small amount of users...
>
> Before we discuss more workarounds, I still see no reason why it would
> be required to run these steps before upgrading the OS. Otherwise I
> would prefer to go back to the old order of steps that always work and
> are less confusing.


Following the use case which it serves currently, I agree that it is best
to go with the original sequence of steps. Probably, thomasrussellmurphy
reinstalled the complete OS and the guide didn't serve his purpose.

- Umesh

Re: [MacPorts] Migration modified

[Umesh Singla]

Hi

On Tue, Aug 29, 2017 at 8:11 PM, Arno Hautala  wrote:

> On Tue, Aug 29, 2017 at 10:37 AM, Rainer Müller 
> wrote:
> >
> > Obviously we cannot give users instructions unless they go looking for
> > them. MacPorts will only be able to notice the OS has been upgraded
> > after the fact.
>
> Just as a message is sent to the user list when a new MacPorts version
> is posted, a message could be sent when a new OS is released that
> reminds users that migration will be required.
>
> I'm hoping however that eventually MacPorts will be able to upgrade
> itself and reinstall all ports following an OS upgrade?
>

Upgrading the port command is actually included in the migration script I'm
working on, after uninstalling all the ports. After upgrading macports, it
installs only requested ports since dependencies might differ with
platforms.

- Umesh

Re: [MacPorts] Migration modified

[Umesh Singla]

Hi, see inline.

On Tue, Aug 29, 2017 at 5:42 PM, Rainer Müller  wrote:

> On 2017-08-29 01:57, MacPorts wrote:
> > Page "Migration" was changed by thomasrussellmurphy
> > Diff URL:  version=99>
> > Revision 99
> > Comment: Change procedure to have the preparation step of logging
> installed ports *before* installing the new OS and upgrading MacPorts
>
> Thank you for working on the instructions.
>
> However, I doubt that users will actually read these instructions before
> upgrading their OS. Quite the contrary, the port command will link to
> this wiki page when it detects that the OS was upgraded. I would expect
> this to be the most common case when users will come to this wiki page,
> so I think the instructions should focus on that. Right now the steps
> start with what they should have done before upgrading their OS, which
> is not helpful in this situation.
>
> What was the reason to move the steps for saving the installed/requested
> ports to the top?


@Rainer, does this mean we can't help a user when user upgrades or
reinstalls OS from scratch before landing on this page. This is actually a
problem I have been thinking about with my GSoC project on migration this
summer.

While moving the steps for saving the installed/requested to the top makes
sense because that is what a user should do, ideally. But in the event of
reinstalling an OS from scratch (I am not talking about 'upgrading' OS),
even the `port migrate` won't be able to help us unless we have saved a
list as above prior to reinstalling OS or `port` command even won't be
there.

- Umesh

Re: [GSoC] migration

[Umesh Singla]

Hi Brad,

It occurred to me that I have been committing but did not update you for a
while. For the last few weeks, I have the following notes. I have tried to
write them in a to-the-point manner.

*GSoC Week #10 (4 Aug - 10 Aug)*

Points:


   1. if no variants, then avoid searching for them, so another field in
   snapshot_ports?
   2. to bring the whole snapshot to use Tcl, need to create the entire
   snapshot-stack
   3. limit the number of snapshots a user can store?


*GSoC Week #11 (11 Aug - 18 Aug)*

Points:


   1. We're not doing requested variants yet.


*GSoC Week #12 (19 Aug - 25 Aug)*

I am taking up the only safe approach to restoring all the ports that were
installed and let the user trim leaves afterward.

Points:

   1. added documentation for all the registry-snapshot functions
   2. finally fixed the snapshot format for passing an object from the
   registry to tcl
   3. added copyright notices to all the files with “2017 The MacPorts
   Project”
   4. removed printf/puts statements from all my files
   5. made installation and sort function use the new format of [snapshot
   ports]
   6. removed TODOs which were over and described the left ones at proper
   places

Doubts:

   1. How many snapshots to list for restore? I'm doing 10, I just don't
   feel like listing everything for now.

TODO:

   1. no hash for snapshot->proc, yet.
   2. working on installing the port command after uninstalling.

All comments are appreciated.

Regards,

Umesh Singla

Re: Order of variants

[Umesh Singla]

Thanks, I was just concerned if there is a variant dependency possible.

On Fri, Aug 25, 2017 at 7:24 AM, Ryan Schmidt <ryandes...@macports.org>
wrote:

>
> On Aug 24, 2017, at 15:53, Umesh Singla wrote:
>
> > Do the order in which I specify the variants to `port install var1 var2
> var3` matter? Does the variant string construction have to follow any
> rules? Just clarifying.
>
> The order you specify on the command line shouldn't matter. MacPorts
> should normalize it (to alphabetical?) internally and in package filenames.
>
>

Re: [GSoC] migration

[Umesh Singla]

> > That was a suggested design; if you're already doing it differently then
> I guess you don't need a design. I disagree with the last sentence though,
> a snapshot can be viewed as precisely the state of the original tables at a
> previous time.
>
> If that is the case, we can simply (insert into snapshot_ports select *
> from ports) to create a snapshot. Obviously the snapshot_ports table needs
> an extra snapshot_id column.
>

Yes, that's what we are indirectly doing at present.


> >> Also, we are not using version and revision. Even going by the literal
> meaning of a snapshot, it should not have a key or id linked to something
> that can change over time. It's simply the present state.
> >
> > The row in the ports table would not change over time, it would simply
> persist until no longer needed. If we ever get the ability to install old
> versions then that information would come in handy.
>
> Sounds right.


Sure.

- Umesh

Re: [GSoC] migration

[Umesh Singla]

> > Later, I am planning to keep information on the manual portgroups in the
> snapshot, if there are any.
> >
> > What would this information be used for?
> >
> > I am under the impression that a user can categorize and classify the
> ports into portgroups, so it should be better if we migrate them too.
> Though, it seems highly
>
> Checkout "man portgroup”, I think your understanding may not be 100%
> correct. Portgroups simply provide a way for port authors to include common
> code in there ports.
>
> Perhaps you are thinking that we would need to snapshot portgroup files if
> we where to ever support installing older versions of software. In that
> case you would be correct, the portgroup files would need to match the
> version of the portfile.
>

As I said, I myself am not very clear at present but just listing the
points to be used later. But the above is what I meant more or less, though
I was clear on the relation between portgroups and the versions.

- Umesh

Re: [GSoC] migration

[Umesh Singla]

Hi

On Fri, Aug 11, 2017 at 4:19 AM, Joshua Root  wrote:

> On 2017-8-11 03:41 , Bradley Giesbrecht wrote:
>
>> I think Josh is referring to 3NF normalization (third normal form). I
>> don’t think this use case warrants this complexity. I think it is fine for
>> two snapshot id’s to reference the same port+variant combination. When a
>> snapshot id is deleted, cascade delete.
>>
>
> Again I'm not sure how this differs from what I wrote. A snapshot contains
> any number of ports, and a port can be in any number of snapshots.
>

I tried to clear this in my other mail.


> Don't worry about having a completely textbook normalised DB, but do avoid
> replicating large amounts of the data.


Sure.


> And TBH a join query would be one of the simplest parts of all this...
>

I started with a join query actually. Something like this,

char* query = "SELECT port_name, requested, variant_name, variant_sign "
"FROM registry.snapshots "
"INNER JOIN "
"registry.snapshot_ports ON "
"snapshots.id=snapshot_ports.snapshots_id "
"LEFT JOIN "
"registry.snapshot_port_variants ON "
"snapshot_ports.id=snapshot_port_variants.snapshot_ports_id"
"WHERE snapshots.id=?";

But then I was having a hard time passing the result to Tcl without a
snapshot struct. And if there is a need for reg_snapshot, then need for
methods as well to operate on it. So, I separated the SQL functions to
fetch ports first and then variants.

But, having said this all, now I think I could have solved this with JOIN
query as well. All these ideas keep coming to me, the longer I spend my
time.

I can really use an idea on workflow here.

- Umesh

Re: [GSoC] migration

[Umesh Singla]

Hi


> And then again, I am sensing a confusion with the idea of snapshot with
>> Josh, like when he says "remove ports when they are no longer referenced by
>> any snapshot".
>>
>
> What confusion exactly? A snapshot is simply a set of ports (by which I
> mean rows in the 'ports' table, with a unique combination of
> name,version,revision,variants). When nothing references a row any more,
> it needs to be deleted.
>

By 'ports', do you mean 'registry.ports' table? If yes, then I disagree.
It's actually 'registry.snapshot_ports' table. A snapshot has nothing to do
with the original registry "tables".

Also, we are not using version and revision. Even going by the literal
meaning of a snapshot, it should not have a key or id linked to something
that can change over time. It's simply the present state.

Later, I am planning to keep information on the manual portgroups in the
snapshot, if there are any.

- Umesh

Re: [GSoC] migration

[Umesh Singla]

> As usual, Josh makes good points.
>
> A text-based database is less convenient to query. I really don’t see why
> storing the information in a database should be challenging. But I’m not
> writing the TCL or C.
>
> I would feel more comfortable running sql queries to verify the snapshots
> are being created accurately.
>
> If text-based storage moves the project forward more quickly do that for
> now. That would be my advice.
>
> It is your call Umesh.
>

At this stage, it's equal time and effort going either side. So I suggest
to continue with the original approach UNLESS there's an additional
advantage with the other.

> And yes, you would need procedures to manipulate this stuff from Tcl as
> you suggested above. And the existing code would need to be updated to only
> remove ports when they are no longer referenced by any snapshot.
> >
> > And then again, I am sensing a confusion with the idea of snapshot with
> Josh, like when he says "remove ports when they are no longer referenced by
> any snapshot”.
>
> I think Josh is referring to 3NF normalization (third normal form). I
> don’t think this use case warrants this complexity. I think it is fine for
> two snapshot id’s to reference the same port+variant combination. When a
> snapshot id is deleted, cascade delete.
>

I think we can pick up the deletion of a snapshot later.

- Umesh

Re: [GSoC] migration

[Umesh Singla]

On Thu, Aug 10, 2017 at 2:54 AM, Joshua Root <j...@macports.org> wrote:

> On 2017-8-10 04:59 , Umesh Singla wrote:
>
>> Hi
>>
>> I was trying to streamline the whole process and I felt the need to have
>> the snapshot as a separate entity just like a reg_entry or a reg_portgroup
>> is, that is, "registry::snapshot" with a bunch of functions like create,
>> get, list_all etc. I think this might help in writing the whole thing from
>> a higher Tcl level.
>>
>> But then again, a snapshot is not something coming directly from the
>> database, so I'm not sure how to keep it. Can I get your view on this?
>>
>
> Well, you already know that my view is that it would be far simpler to
> store the snapshots as a text-based format, rather than write and modify a
> large amount of non-trivial C.
>

I think what Josh means here, is a complete text-based dump of the current
state in a file and then using restore, something like what we currently
expect our users to do themselves.

It could be useful in a case when a user wants to completely re-install the
OS from scratch and then, a text-formatted file can easily be backed up for
use by restore later. We can argue that keeping in registry.db is also
similar to keeping in a file, but the interface we are providing a user
help migrate are bit different. Because it is not intuitive to take a dump
of registry.db manually but running a take_snapshot command is.


> But if you are set on doing this in the sqlite database, the relational
> way of doing it would be to add:
>
> 1. A table of snapshots, consisting minimally of names and ids
> 2. A table associating snapshot ids with port ids on a many-to-many basis
>
> Under this model, the set of currently installed ports would be just
> another snapshot, albeit one with a special meaning. The activation state
> of each port would have to move from the ports table and become
> per-snapshot (maybe stored in the second table?).
>
> And yes, you would need procedures to manipulate this stuff from Tcl as
> you suggested above. And the existing code would need to be updated to only
> remove ports when they are no longer referenced by any snapshot.


And then again, I am sensing a confusion with the idea of snapshot with
Josh, like when he says "remove ports when they are no longer referenced by
any snapshot".

- Umesh

Re: [GSoC] migration

[Umesh Singla]

> >> I was trying to streamline the whole process and I felt the need to
> have the snapshot as a separate entity just like a reg_entry or a
> reg_portgroup is, that is, "registry::snapshot" with a bunch of functions
> like create, get, list_all etc. I think this might help in writing the
> whole thing from a higher Tcl level.
> >> But then again, a snapshot is not something coming directly from the
> database, so I'm not sure how to keep it. Can I get your view on this?
> >
> > Well, you already know that my view is that it would be far simpler to
> store the snapshots as a text-based format, rather than write and modify a
> large amount of non-trivial C.
> >
> > But if you are set on doing this in the sqlite database, the relational
> way of doing it would be to add:
> >
> > 1. A table of snapshots, consisting minimally of names and ids
> > 2. A table associating snapshot ids with port ids on a many-to-many basis
>
> The snapshot tables would not be updated. I see no reason for a many to
> many. Each port/variant in a snapshot would have a snapshot id. When a
> snapshot is deleted delete it’s id everywhere.
>

It is simply a one-to-many foreign key, that is, linking one snapshot to
many port ids and further, one port to many variants.

Speaking of deleting a snapshot, do we want to limit the number of
snapshots a user can have? or something like keeping an expiry date for a
snapshot.

- Umesh

Re: [GSoC] migration

[Umesh Singla]

Hi

On Sun, Aug 6, 2017 at 6:43 PM, Jackson Isaac <ijack...@macports.org> wrote:

> Hi,
>
> On Sun, Aug 6, 2017 at 5:41 PM, Umesh Singla <umeshksin...@macports.org>
> wrote:
> > On Sat, Jul 22, 2017 at 7:26 AM, Joshua Root <j...@macports.org> wrote:
> >>
> >>
> >>> For now, I'd like to ask in what order does "registry::entry imaged"
> >>> returns the port list? Because I'm running the sorting function which
> the
> >>> restore_ports.tcl uses but it's giving me the ports in the same order
> as
> >>> result.
> >>
> >>
> >> Probably just ordered by rowid, i.e. might as well be random. Note that
> >> the sort_ports proc from restore_ports.tcl does not take a list of
> registry
> >> references like registry::entry returns, but a list of strings
> representing
> >> port names, versions and variants in the format generated by 'port
> >> installed'.
> >
> >
> > `port installed` returns the result of `registry::entry imaged` sorted
> in an
> > alphabetical order, first by name, then version etc.
> >
> > `registry::entry imaged` might be returning in a random order but
> sorting it
> > (with ports coming before their dependencies) doesn't change the result
> at
> > all.
> >
>
> [1] and [2] might be useful. The list of ports are passed to
> _mportexec after topologically sorting them for installing. This might
> also answer some of your previous queries regarding using [mportexec
> $workername $install_target] and sorting the dependencies at once.
>

Thanks for this.


> Variants is still pending. You could try to integrate sorting and
> installation of ports with libsolv and extend variant handling from
> your script. You might have to tweak the libsolv code if you pass the
> variants like foo+bar-baz. One idea could be to add 'bar' as
> dependency and 'baz' as conflict explicitly since it will only read
> the portindex for 'foo'.
>

When you say variants is still pending, do you mean we can't specify
particular set of variants along with a port to be installed? So, it always
assumes the default variants for a port at present?

If the variants are still not supported by libsolv, what I think is best to
go with calculating dependencies recursively as I'm doing now and then
integrate it with libsolv.


> Libsolv proved to be faster than our traditional recursive dependency
> calculation engine even after reading through the complete portindex
> every time it was called.
>

I had doubts about "reading the portindex contents first and writing into
libsolv formatted solvables"  every time when I went through the code but
for now, I can take your word.


> Let me know if you have any doubts regarding the libsolv code. The
> comments should be explanatory enough by itself but feel free if you
> want to understand what is actually happening behind the scenes by
> libsolv.
>

The comments are really descriptive there. macports-base can hopefully
learn from it.

- Umesh

Re: [GSoC] migration

[Umesh Singla]

Hi

On Sun, Aug 6, 2017 at 6:56 PM, Joshua Root <j...@macports.org> wrote:

> On 2017-8-6 22:11 , Umesh Singla wrote:
>
>> On Sat, Jul 22, 2017 at 7:26 AM, Joshua Root <j...@macports.org > j...@macports.org>> wrote:
>>
>>
>> For now, I'd like to ask in what order does "registry::entry
>> imaged" returns the port list? Because I'm running the sorting
>> function which the restore_ports.tcl uses but it's giving me the
>> ports in the same order as result.
>>
>>
>> Probably just ordered by rowid, i.e. might as well be random. Note
>> that the sort_ports proc from restore_ports.tcl does not take a list
>> of registry references like registry::entry returns, but a list of
>> strings representing port names, versions and variants in the format
>> generated by 'port installed'.
>>
>>
>> `port installed` returns the result of `registry::entry imaged` sorted in
>> an alphabetical order, first by name, then version etc.
>>
>
> Yes. The order of the input lines doesn't matter for restore_ports.tcl of
> course because it's sorting them. My point was just that that particular
> sort procedure takes something like "zlib @1.2.11_0 (active)" as input,
> rather than "::registry::entry150".


Yes, I was aware of that anyway.


>
> `registry::entry imaged` might be returning in a random order but sorting
>> it (with ports coming before their dependencies) doesn't change the result
>> at all.
>>
>
> This could easily be true in some cases but definitely not in the general
> case. Are you testing on real-world registry contents or just on an
> installation you created recently for testing? In the latter case, each
> port will happen to come before its dependents simply because dependencies
> are installed first. After some upgrading of ports over time, in
> practically random order, this will often no longer be the case.
>

I was only trying on installation I created which had about 60 ports in
total but only 5 requested. So, you are right because the order was always
stored sorted and was never modified. Thanks.


>
> Attached is a small script that I used to demonstrate that this property
> does not hold in my own registry. There, entry0 is fftw-3, and comes before
> its dependent entry243 (py27-numpy). On the other hand, entry267 is
> py27-setuptools, which comes after its dependent entry76 (py27-nose).
>

- Umesh

Re: [GSoC] migration

[Umesh Singla]

On Sat, Jul 22, 2017 at 7:26 AM, Joshua Root  wrote:

>
> For now, I'd like to ask in what order does "registry::entry imaged"
>> returns the port list? Because I'm running the sorting function which the
>> restore_ports.tcl uses but it's giving me the ports in the same order as
>> result.
>>
>
> Probably just ordered by rowid, i.e. might as well be random. Note that
> the sort_ports proc from restore_ports.tcl does not take a list of registry
> references like registry::entry returns, but a list of strings representing
> port names, versions and variants in the format generated by 'port
> installed'.
>

`port installed` returns the result of `registry::entry imaged` sorted in
an alphabetical order, first by name, then version etc.

`registry::entry imaged` might be returning in a random order but sorting
it (with ports coming before their dependencies) doesn't change the result
at all.

- Umesh

Re: [GSoC] migration

[Umesh Singla]

Hi Brad

A quick update.

Points -

   1. Is it okay to fetch dependents using mportlookup while installing?
   2. For migrate action, we agreed upon installing all and only the
   (active requested + inactive requested) ports, in short, all the requested
   in the sorted order, right? Dependencies can figure out themselves, they
   might be different for different platforms.
   3. Are the ports which are part of the snapshot related to the actual
   ports at implementation level? If no, then snapshot needs to move to a
   different data structure, and in that case:


   - move all to C file snapshot.c from entry.c in cregistry. Till now, I
  was just using a way around to it with "registry::entry create_snapshot"
  which doesn't comply with the design at all. A snapshot shouldn't use the
  data structure 'reg_entry', so I'm moving all to a separate module where
  the C registry functions dealing with snapshot could be kept.
  - OR if 'reg_entry' is possible, then why do we have a
  reg_portgroup struct and others.

Todo -

   1. Later: fetching dependencies only once while migrating. Right now,
   doing it twice for installation and while uninstalling.
   2. know the internals of `port selfupdate` and check if a part of it can
   be used for the only step left in migrate, having a fresh installation of
   macports for the updated platform.

Please find the work log here
<https://github.com/macports/macports-base/commits/gsoc17-migrate?author=umeshksingla>
.

Regards,
Umesh Singla

On Tue, Aug 1, 2017 at 6:17 AM, Bradley Giesbrecht <pixi...@macports.org>
wrote:

> > On Jul 27, 2017, at 2:10 PM, db <iams...@gmail.com> wrote:
> >
> > On 27 Jul 2017, at 21:21, Bradley Giesbrecht <pixi...@macports.org>
> wrote:
> >> Migration will uninstall all installed ports and then install all the
> ports from the snapshot
> >
> > Yes, but I'm talking about using snapshot and restore at different times
> with ports being updated between them, likely resulting in different
> outcomes.
>
> We are not keeping track of port versions so restore would deactivate all
> ports and then install the snap shot ports with variants. At least that is
> what I imagine.
>
> —
> Brad

Re: [GSoC] migration

[Umesh Singla]

Hi

On Sun, Jul 23, 2017 at 5:03 AM, db <iams...@gmail.com> wrote:

> On 22 Jul 2017, at 03:01, Umesh Singla <umeshksin...@macports.org> wrote:
> > I don't know, in the above example, what do you mean when you say "..you
> realize that from its deps..", like, realize how? I am just asking this if
> there's some other way to get info on the latest modifications that I might
> not be aware of.
> > 'sync' or 'upgrade outdated' provide the information what all ports got
> updated immediately on console but I'm not sure if it can be accessed later
> since the user may not realize that another port has broken immediately,
> like hstr here.
>
> Since MP doesn't keep logs (!) I keep them myself and investigate when
> something doesn't work properly.
>
> > Another thing that comes to my mind now is if, suppose, updated version
> of ncurses was actually required for some another port and reverting it to
> the older state could possibly result in breaking of that port.
>
> No, because, as I said, it would revert to a previous tree state. The
> thing is doing it by reinstalling only the upgraded ports and not the whole
> tree. It shouldn't be difficult to implement.


@Bradley, when we came up with re-installing all the ports, I had this
doubt too. It sure shouldn't be difficult, getting only the upper and lower
dependencies to check for, if a user is able to figure out the faulty port
himself.

I understand the part of migration but I'd like to know more about the
restore here. This conversation actually helped me focus on the
"install/activate the snapshot ports" part of your statement
"Restoring a snapshot would turn off all parts and install/activate the
snapshot ports with variants."
in one of your previous replies.

Can we help with such a use case here? To me, "it would revert to a
previous tree state" sounds like restore but with less complexity. Though
issues will come up even if the number of such ports is greater than 2 and
will make it hard for the user.

Regards,
Umesh

Re: [GSoC] migration

[Umesh Singla]

Hi Josh

Another thing that comes to my mind now is if, suppose, updated version of
>> ncurses was actually required for some another port and reverting it to the
>> older state could possibly result in breaking of that port. May be, we
>> could get all the ports which depend on it and check if this specific port
>> requirement could be satisfied by its older versions as well and then just
>> ask the user if the user would like to restore or not?
>>
>> Again, I'm not really aware of the things, so I'd like the inputs of
>> community here.
>>
>
> We don't have version dependencies so no, this sort of check is not
> possible a priori. Breakage will be caught by rev-upgrade after the fact in
> many cases (and if it is set to rebuild automatically, it may well revert
> you back to the newer version).
>

Thanks for clearing this out.


> Also note that we can't actually revert to an older version of a port if
> it has been uninstalled.
>

I don't understand this. Does this mean that macports only allows me to
install the most recent version of a port? You said "if it has been
uninstalled", so if it's still installed, can we then revert to an older
version?

- Umesh

Re: [GSoC 2017] Second Evaluation

[Umesh Singla]

Okay, please ignore. I got it.

Thanks

On Tue, Jul 25, 2017 at 6:20 AM, Umesh Singla <umeshksin...@macports.org>
wrote:

> [I'm not sure if the previous mail got delivered, resending]
>
> I have submitted the evaluation from my side on the portal. I'll try to
> come up with a write-up for this period too as I did for the last one, as
> soon as possible.
>
> Now I gotta ask if there is any way you all use to let Gmail remember you
> to use @macports alias before hitting the Send button. Every time, it
> changes to my Gmail address by default and I have to change it back :/
>
> Regards,
> Umesh
>
> On Tue, Jul 25, 2017 at 6:04 AM, Umesh Singla <umeshksin...@gmail.com>
> wrote:
>
>> Hi Jackson
>>
>> I have submitted the evaluation from my side on the portal. I'll try to
>> come up with a write-up for this period too as I did for the last one, as
>> soon as possible.
>>
>> Regards,
>> Umesh
>>
>> Umesh Singla
>>
>> On Mon, Jul 24, 2017 at 9:40 PM, Jackson Isaac <ijack...@macports.org>
>> wrote:
>>
>>> Hi GSoC Students and Mentors,
>>>
>>> Phase 2 evaluations has begun. Deadline for filling the evaluations is
>>> July 28, 2017 16:00 UTC. The procedure remains the same as previous.
>>> Also please summarize the work done until now, challenges faced and
>>> how did you manage to overcome them.
>>>
>>> Please let us know if there are any issues faced.
>>>
>>> Regards,
>>> Jackson Isaac
>>>
>>
>>
>

Re: [GSoC 2017] Second Evaluation

[Umesh Singla]

[I'm not sure if the previous mail got delivered, resending]

I have submitted the evaluation from my side on the portal. I'll try to
come up with a write-up for this period too as I did for the last one, as
soon as possible.

Now I gotta ask if there is any way you all use to let Gmail remember you
to use @macports alias before hitting the Send button. Every time, it
changes to my Gmail address by default and I have to change it back :/

Regards,
Umesh

On Tue, Jul 25, 2017 at 6:04 AM, Umesh Singla <umeshksin...@gmail.com>
wrote:

> Hi Jackson
>
> I have submitted the evaluation from my side on the portal. I'll try to
> come up with a write-up for this period too as I did for the last one, as
> soon as possible.
>
> Regards,
> Umesh
>
> Umesh Singla
>
> On Mon, Jul 24, 2017 at 9:40 PM, Jackson Isaac <ijack...@macports.org>
> wrote:
>
>> Hi GSoC Students and Mentors,
>>
>> Phase 2 evaluations has begun. Deadline for filling the evaluations is
>> July 28, 2017 16:00 UTC. The procedure remains the same as previous.
>> Also please summarize the work done until now, challenges faced and
>> how did you manage to overcome them.
>>
>> Please let us know if there are any issues faced.
>>
>> Regards,
>> Jackson Isaac
>>
>
>

Re: [GSoC] migration

[Umesh Singla]

Hi

On Fri, Jul 21, 2017 at 5:39 PM, db <iams...@gmail.com> wrote:

> On 21 Jul 2017, at 13:02, Umesh Singla <umeshksin...@gmail.com> wrote:
> > Unless we have a snapshot of the previous state, that is, before it got
> hampered.
> > But then again, we reinstall all the ports presently. At this time, it
> could be hard for me to detect what went wrong while sync or upgrade.
>
> If I understood you correctly it will presently reinstall all ports in a
> given snapshot.
>
> I'm not saying that these commands should check for what went wrong during
> upgrade, but to reinstall only those whose upgrade caused another port to
> stop working as expected. The actual cause is for the user to find. For
> example, let's say you did upgrade outdated and hstr doesn't work anymore,
> but you realise that from its rdeps only ncurses was updated. Then you
> could use restore with the snapshot preceding the upgrade to just rollback
> the whole tree to that state by reinstalling in this case only ncurses and
> not hstr, readline, etc.
>
> hstr
>   pkgconfig
> libiconv
>   gperf
>   ncurses
>   readline
>
>
Let's say we have a snapshot of the state before sync or upgrade.

I don't know, in the above example, what do you mean when you say "..you
realize that from its deps..", like, realize how? I am just asking this if
there's some other way to get info on the latest modifications that I might
not be aware of.

'sync' or 'upgrade outdated' provide the information what all ports got
updated immediately on console but I'm not sure if it can be accessed later
since the user may not realize that another port has broken immediately,
like hstr here.

Another thing that comes to my mind now is if, suppose, updated version
of ncurses was actually required for some another port and reverting it to
the older state could possibly result in breaking of that port. May be, we
could get all the ports which depend on it and check if this specific port
requirement could be satisfied by its older versions as well and then just
ask the user if the user would like to restore or not?

Again, I'm not really aware of the things, so I'd like the inputs of
community here.

Regards,
Umesh

Fwd: [GSoC] migration

[Umesh Singla]

Forwarding this to macports-dev.

-- Forwarded message --
From: Umesh Singla <umeshksin...@gmail.com>
Date: Fri, Jul 21, 2017 at 4:32 PM
Subject: Re: [GSoC] migration
To: db <iams...@gmail.com>


Hi


> > Snapshot and restore should be able to be executed without migrate.
>
> I have a question and I haven't been following in detail this GSoC, so
> bear with me.
>
> Could snapshot and restore be used to rollback to a previous state in case
> a sync and upgrade outdated fails or installs a port that doesn't work
> properly and without reinstalling all non-relevant (unchanged) ports?


Unless we have a snapshot of the previous state, that is, before it got
hampered.

But then again, we reinstall all the ports presently. At this time, it
could be hard for me to detect what went wrong while sync or upgrade.

Thanks,
Umesh

Re: [GSoC] migration

[Umesh Singla]

Hi Brad, Clemens, Josh

Please see inline.

> GSoC Week #7 (13 Jul - 19 Jul)
> >
> > I moved the things to migrate action instead of 'restore' since
> 'restore' looks a subset of 'migrate', so can be dealt easily once migrate
> is over.
>
> I’m not sure I understand and if I do understand I think I disagree.
>

Ah, sorry. I agree. I shouldn't have used the word "subset". I was aware
that only a small section overlaps.

Snapshot is a state of installed and active ports with their variants.
> Restoring a snapshot would turn off all parts and install/activate the
> snapshot ports with variants.
> Migration would be taking a new snapshot, uninstalling all ports,
> upgrading the port command for the new arch and finally restoring the last
> snapshot which would entail installing all ports from snapshot since we
> installed earlier.
>
> Snapshot and restore should be able to be executed without migrate.
>

Yes, that was in mind. But then again, it's good having more clarity as I
go.

Reading below I think I misunderstand so please clarify.
>
> > Agenda for last week:
> >
> >
> > 3. Re-installing the ports from the portlist. I took the help of
> restore_ports.tcl here, which works when called migrate. It uses sort_ports
> [1] function.
> >
> >
> >
> > When we install, is it fine to use [mportexec $workername
> $install_target] from migrate.tcl?
>
> I’m sorry, I don’t know base well enough to answer this. Can you please
> ask Clemens or Josh?
>

@Clemens @Josh, can you clarify this?

> What took time is that these two functions at present take the port list
> in different formats. So, I tried debugging by simply printing on console
> method to know the formats of the two.
> >
> > I want to use the sorting function for dependencies only once instead of
> calling it twice while uninstalling and then re-installing. I'm still
> working on it and actually, close to solve this but thought, better send
> the weekly update first.
>


> I’d check with Clemens on this. He mentored a previous GSoC project which
> used libsolve for dependency calculations. Perhaps there is something to
> borrow or learn from that project?


Sure, I will look into it. For now, I'd like to ask in what order does
"registry::entry imaged" returns the port list? Because I'm running the
sorting function which the restore_ports.tcl uses but it's giving me the
ports in the same order as result.



> >
> > Since migrate action creates a snapshot within and then uses it to redo
> the whole state, I feel creating a snapshot here explicitly is redundant.
>
> Not sure I follow. I imaging migrate action would start by calling
> snapshot, register the snapshot id, uninstall all ports, reinstall the port
> command and finally call restore action with the snapshot id for the last
> snapshot.
>
> > Internally snapshot also uses the same registry C functions to get the
> information first and then save to database as [registry::entry imaged]
> does, so instead of first retrieving from [registry::entry imaged], saving
> it in sqlite and then again fetching all the info using the snapshot-id we
> just got, can't we directly use [registry::entry imaged] here? Am I missing
> something?
>
> Oh, maybe in this case we already have the list in memory? But when we
> upgrade the port command wouldn’t we then call the new port command and
> perform the restore with the upgrade port command?
>

Okay, yes. For a moment, I mixed restore and migrate and forgot about a
different port command now. Also, Brad, when we say "reinstall the port
command", what exactly does it mean? Like, what all steps it could have?
Does it mean including from the installation guide here [1]. I could use
some help here.


> Very good letter Umesh, thanks for the update. I hope my replies and
> questions are useful.
>

Welcome. They are indeed.

Regards,
Umesh Singla

[1]: https://www.macports.org/install.php

Re: [GSoC] migration

[Umesh Singla]

Hi Brad,

With another week over, I have the following updates to share.


*GSoC Week #7 (13 Jul - 19 Jul)*

I moved the things to migrate action instead of 'restore' since 'restore'
looks a subset of 'migrate', so can be dealt easily once migrate is over.


Agenda for last week:

The migrate action consisted of three parts, creating a new snapshot,
uninstall installed ports, re-installing them for the last snapshot.

1. Creating a new snapshot was over before, though some refactoring is
still left.

2. Regarding uninstalling installed ports, I took the help of reclaim.tcl
which works with the migrate action now. It uses
sort_portlist_by_dependendents procedure. So, all in all, it uses
"registry_uninstall::uninstall".

3. Re-installing the ports from the portlist. I took the help of
restore_ports.tcl here, which works when called migrate. It uses sort_ports
[1] function.


When we install, is it fine to use [mportexec $workername $install_target]
from migrate.tcl?

What took time is that these two functions at present take the port list in
different formats. So, I tried debugging by simply printing on console
method to know the formats of the two.

I want to use the sorting function for dependencies only once instead of
calling it twice while uninstalling and then re-installing. I'm still
working on it and actually, close to solve this but thought, better send
the weekly update first.


For the next one week:

   1. make appropriate changes to procedures according to one format.
   2. write for “SELECT PORTS FROM SNAPSHOT ..”, i.e. connect it with the
   new tables we have.
   3. try finishing the migrate action asap?


Points:

Since migrate action creates a snapshot within and then uses it to redo the
whole state, I feel creating a snapshot here explicitly is redundant.

Internally snapshot also uses the same registry C functions to get the
information first and then save to database as [registry::entry imaged]
does, so instead of first retrieving from [registry::entry imaged], saving
it in sqlite and then again fetching all the info using the snapshot-id we
just got, can't we directly use [registry::entry imaged] here? Am I missing
something?

Regarding "selected" snapshot for 'restore', it looks fine.


New points which I made during pondering to save for the end:

   1. Add ui_debug statements
   2. Catch some error-prone areas.
   3. Remove the useless/structure comments and add actual doc-strings.
   4. Add copyright notices
   5. Using ui_msg instead of puts and else. Should probably add that.


Also, here's my view of restore_ports.tcl of what it does:

   - macports prefix configs
   - umask 022
   - set portList [read_portlist $filename] - reads the portlist from file
   supplied or stdin
   - set operationList [sort_ports $portList]
  - sort_ports $portList
 - extracts name, version, variants, active for a port
 - sets it 1 in port_in_list if not there, else increments the
 count for that port
 - if port dependencies for the combination (port_name, its
 variants) doesn’t exist already, fetches them using
 dependenciesForPort(port_name, its variants), kind of recursively.
  - dependenciesForPort $port_name $variants
   - install_ports $operationList
  - checks $active for a port and use it to decide install_target
  - uses mportexec for installing


Please find the work log here [2]. It is largely in work-in-progress state.


[1]:
https://github.com/macports/macports-contrib/blob/master/restore_ports/restore_ports.tcl#L52

[2]: https://github.com/macports/macports-base/commits/gsoc17-migrate


Best Regards,

Umesh Singla

Re: [GSoC] migration

[Umesh Singla]

Hi

>   • A snapshot would be a list of install commands that created the
> current installed state.
> >   • Restoring a snapshot would deactivate the active ports and
> reproduce the install commands for the selected snapshot.
> >   • Migrate would amount to creating a new snapshot, uninstalling
> installed ports and reproducing the install commands for the last snapshot.
> > @Brad: Did you miss “uninstalling installed ports” in the second point
> above?
>
> No. I imagined being able to switch between snapshots with minimal
> building. Migration would uninstall because we are changing platforms.
>

I didn't look at the point with this perspective. But it sure is a great
idea.

Thanks,
Umesh

Re: [GSoC] migration

[Umesh Singla]

Hi Brad,

With another week over, I have the following updates to share. These are
actually the points from my Notes as I keep going on, so the email might
not be well crafted. Thought, would share with you without any delay.

*Week #5-6 (28 Jun - 12 Jul)*

Golden lines for the project:

   1. A *snapshot* would be a list of install commands that created the
   current installed state.
   2. *Restoring* a snapshot would deactivate the active ports and
   reproduce the install commands for the selected snapshot.
   3. *Migrate* would amount to creating a new snapshot, uninstalling
   installed ports and reproducing the install commands for the last snapshot.

@Brad: Did you miss “uninstalling installed ports” in the second point
above?


Challenges from the first phase:

   1. “variants” - still not discussed by anyone after 2 emails, 1 post and
   1 comment on GitHub. -> resolved.
   2. I wrote at the end of my first phase that one variant of a port can
   be active at a time, turns out I was wrong. All thanks to the UI messages
   and the research.

Challenges still to tackle:

   1. snapshot needs to store which ports are active as well?
   2. refactoring snapshot to use registry::write wrappers and transaction
   logic.
   3. ensuring that active versions are installed after the inactive
   versions since the output after running `port install vim -huge +tiny`:

——

Computing dependencies for vim

..

--->  Staging vim into destroot

*--->  Installing vim @8.0.0596_0+tiny*

*--->  Deactivating vim @8.0.0596_0+tiny+x11*

--->  Cleaning vim

*--->  Activating vim @8.0.0596_0+tiny*

--->  Cleaning vim

--->  Updating database of binaries

..

shows that installation also activates and we don’t want to activate the
ports which were originally inactivated.

Agenda for last two weeks:

   1. Begin with restore action.
   2. Write for uninstalling ports - took the help of reclaim.tcl for this
   3. Work on reproducing the install commands for a snapshot
   4. Improve the snapshot action as needed for the restore action.

Still left from last two weeks:

   1. A part to include installation of ports with the help of
   restore_ports.tcl.

Agenda for next two:

   1. Finish the restore action by Jul 24.

Challenges that might come later:

   1. dealing with builds at MP_PREFIX and not at /opt/local. Don’t know
   now but keep in mind.
   2. conflicting ports as Josh said and migration guide says.

Important discoveries I made during this period:

   1. came to know that the port *vim +tiny+x11* is different from *vim
   +tiny*, says a lot how ports are variant-bundled.
   2. ‘imaged’ is installed but inactive, while ‘installed’ is installed
   and active.

Pondering:

   1. Reinstalling the MacPorts/Xcode CL tools for the new platform if it
   is not built for the new OS already is not something we can help with,
   right?

Work log: https://github.com/macports/macports-base/commits/gsoc17-migrate

All reviews and comments are welcome.

Regards,

Re: [GSoC] migration

[Umesh Singla]

Hi Brad,

While I was writing for restoring of ports, it seems that I need to include
another field 'active' along with ports while taking snapshot. This might
sound obvious now but it wasn't to me before I looked at what is going on,
closely. While there is something like 'active' port but there's no such
state as being 'inactive'.

This led me to a further research and I came across this in the migration
guide:

"Though it is now quite well-tested, the restore_ports script may fail in
some cases. One known issue is that the script will fail if there are
conflicting ports in the list. It's possible to have conflicting ports
installed provided at most one of the conflicting set is active. If the
script fails for this reason, you can delete one of the conflicting
ports..."

Do you think it can be solved by merely adding active field? What possible
conflicts is it talking about?

The example I went through is installing of vim. I ran:

*port install vim -huge +tiny +x11* -> this is active now

followed by,

*port install vim -huge +tiny* -> now this becomes active and previous one
deactivated (different ports, therefore). Of course, both are requested =
True.

So, in the snapshot database, it is:


ports:

id  snapshot_id  portname  req

2540104   vim 1 ...

2593104   vim 1

with variants stored as:

idport_id  variantsign

242 2540   tiny +

243 2540   x11 +

244 2540   huge   -   ...

250 2593   tiny +

251 2593   huge   -

Reproducing the install commands for these two, is that a conflict? I used
reg_entry_imaged which doesn't give info on a port being active. Probably,
I should use a combination of reg_entry_installed and reg_entry_imaged OR
registry::installed which is more straightforward and serves my purpose.
Can you help me with the next step here?

Regards,
Umesh Singla

Re: [GSoC 2017] First Evaluation

[Umesh Singla]

Hello all,

I have prepared a small informal write up about the work and challenges
faced till now and posted on my blog [1]. Also, I have already completed my
side of evaluation and submitted on GSoC website.

Looking forward to community reviews.

Regards,
Umesh Singla

[1]:
https://umeshsingla.blogspot.in/2017/06/5-project-and-pre-first-evaluation.html

On Mon, Jun 26, 2017 at 9:42 PM, Jackson Isaac <ijack...@macports.org>
wrote:

>  Hi GSoC Students and Mentors,
>
> Phase 1 evaluation has started as of now until 16:00 UTC June 30,
> 2017. Please make sure that students fill out the mentor evaluations
> and at least one mentor evaluate the student performance before the
> deadline.
>
> It would be also good if the students can prepare a write-up about
> their work (code written) till now and further plans for 2nd phase.
>
> --
> Jackson Isaac
>

Fwd: [GSoC] migration

[Umesh Singla]

I sent this mail three days ago, but by mistake to only Bradley (pixilla)
(and that too, not from @macports address). So, forwarding this here.
Though we can ignore most of what I wrote at that time.

Thanks

-- Forwarded message --
From: Umesh Singla <umeshksin...@gmail.com>
Date: Fri, Jun 23, 2017 at 7:39 AM
Subject: Re: [GSoC] migration
To: Bradley Giesbrecht <pixi...@macports.org>


Hi Brad

I assumed we would allow multiple snapshots and be able to chose from a
> list of snapshots by date-sequence.
>

Yes, and I think, adopting the files strategy is basically doing the work
of sqlite manually.


> For the migration functionality wouldn’t we only install “requested”
> ports? Dependencies could be different with a platform change.


Thanks Brad for clearing this one out. This has been bugging me since long
and is actually very fundamental to the project. I was confused between
choosing `registry::installed` or `registry::entry installed` at first but
then came the `imaged` to create more confusion.

Now, getting the list should be as simple as (for snapshot_main):

"""
set installed_ports [registry::entry imaged]

...

foreach port $installed_ports {
set isrequested [registry::property_retrieve $port requested]
if {$isrequested == 1} {
# get its variants
# store them
}
}

"""

Anyway I tried consulting the existing migration guide. Why does it save
the list of all installed ports and then sets the requested flags? Only
installing the requested and let the dependencies figure out themselves -
is it an improvement we're making now?


> Also, if the installed variants for a given port are the default variants
> would we want to ignore variants?
>

I guess it should be fine to ignore them. When the default flavor is
desired, it'll be there when the port is installed through the script.

Also, we're treating the inactive ports similarily, right? Makes sense to
me.

Thanks,
Umesh Singla

Re: [GSoC] migration

[Umesh Singla]

Hi Bradley,

On Sun, Jun 25, 2017 at 1:59 AM, Bradley Giesbrecht <pixi...@macports.org>
wrote:
>
> >> For the migration functionality wouldn’t we only install “requested”
> ports? Dependencies could be different with a platform change.
> >> Also, if the installed variants for a given port are the default
> variants would we want to ignore variants?
> >
> > These two points are related. A requested flag for variants is needed to
> be able to do the right thing.
> >
> > We don't want to ignore variants exactly; we want to apply only the
> requested variants (positive and negative) when reinstalling ports.
>
> Is a “default” variant requested? I believe some ports have different
> default variants depending on the platform, operation system or other
> environment factors. Shouldn’t we be replicating the actual user install
> commands as close as possible?


I believe a default variant is requested unless the first command to
install the port has variants explicitly mentioned but it is not requested
in the context of a user because the user can probably be unaware of
available variants.

But again, as you said, there can be different default variants, storing
the original defaults can result in confusion between what originally was
default (they should not become requested) and what is the current default?
So, I think we should NOT treat the default as requested. Replicating the
actual user commands is the most ideal thing to do.

A confusion could have been here: `port install port_name` and `port
install port_name +default`. Both will install default but it's not
requested in first case while requested in second case. The second one
should get listed as requested in db and hence, not create any problem
further.


> Should we include variants the user did not supply to the port install
> command?
>

I didn't get it. Either the variants are default or they were requested,
both will be present in the stack. How can we get the variants which the
user never supplied? Are you trying to hint at the difference in the port
installed at the first run and the variants installed later on?

Also, I need your help in a technical detail. I'll try to push in some time
and get back to you if you're free.


Regards,
Umesh Singla

Re: [GSoC] migration

[Umesh Singla]

Hi

Taking a step back for a moment, why is an SQL database the best way
>> to store this data? What sorts of queries are you going to want to
>> run on it? Would a text (Tcl array) representation similar to the
>> PortIndex be a better fit?
>>
>>
>> We need to store all the information about the existing state of the
>> ports first, then uninstall all the ports and re-install on the updated OS
>> after self-updating using the info we have in the database. So, we can't
>> have a temporary kind of Tcl array representation.
>>
>
> A Tcl array representation doesn't have to be temporary. It can easily be
> written to a file.
>
> If the only operations are going to be storing the list of ports and then
> reinstalling all the ports in the list, that says to me that SQL is much
> more complexity than you need.


I'll check with my mentor. I may not have been clear in explaining the need
for SQL or Tcl array representation could be an easy way go.

In registry2 parlance, "imaged" means installed and "installed" means
> active. Confusing I know.
>

Thanks for the clarification.

- Umesh

Re: [GSoC] migration

[Umesh Singla]

Hi Josh,

Taking a step back for a moment, why is an SQL database the best way to
> store this data? What sorts of queries are you going to want to run on it?
> Would a text (Tcl array) representation similar to the PortIndex be a
> better fit?
>


We need to store all the information about the existing state of the ports
first, then uninstall all the ports and re-install on the updated OS after
self-updating using the info we have in the database. So, we can't have a
temporary kind of Tcl array representation.


I can get this info from `port -v installed` and `port -v installed
>> requested` command, that is, calling /action_installed/ [1] which in turn,
>> calls /registry::installed/ [2] for each port from /snapshot_main/. Is this
>> best way to go?
>>
>
> Using registry::installed will work, but it's not the most efficient since
> it provides the same interface as the old flat-file registry (See below).
>
> Further, can you point me to some port action where it deals with
>> retrieving and populating tables as a hint? The /action_target/ used for
>> most of the port commands like /install/, /clean/, /fetch/ doesn't really
>> hint on how to deal with it.
>>
>
> These don't deal with SQL directly, they use the registry API.
>
> I hunted down till I reached /macports::registry.format/  -->
>> /receipt_{flat/sqlite}.tcl /files//which have a bunch of functions using
>> /registry::entry/ which I think is the most "basic" operation and then,
>> also /receipt_sqlite:://create_entry_l/function.
>>
>
> The way to get the list of installed ports is with 'registry::entry
> imaged'. Have a look at how reclaim.tcl does it for example.
>


Yes, thanks for this. @Brad, 'registry::entry imaged' or 'registry::entry
installed', may be?

I found 2 functions reg_entry_imaged() and reg_entry_installed() in
registry, which look almost similar implementation wise. Can you tell me
what is an imaged port? I mean, how will the two results be different?


The create_entry_l procedure is there to help in converting the old
> flat-file format to sqlite. It's probably not very relevant for you.
>

Yeah, ignoring this.


> If you do end up adding new tables to the db, you will need to add support
> for them to the entire stack from cregistry up.
>


I think you're referring to the work in last two commits here

.


Thank you for the help,
Umesh

Re: [GSoC] migration

[Umesh Singla]

Hi Bradley,

I'm having a bit difficulty in implementing the body of snapshot procedure.
Basically what I need to do now is (as I have written in my notes, so you
can tell me if I'm on right track in my thoughts as well):

"get the list of installed ports, their-installed-variants and
if-requested,
then add one port at a time to the 2nd table, its variants to the 3rd
table,
after all this, add an entry in the snapshot table for the entire snapshot,
that's it."

I can get this info from `port -v installed` and `port -v installed
requested` command, that is, calling *action_installed* [1] which in turn,
calls *registry::installed* [2] for each port from *snapshot_main*. Is this
best way to go?

Further, can you point me to some port action where it deals with
retrieving and populating tables as a hint? The *action_target* used for
most of the port commands like *install*, *clean*, *fetch* doesn't really
hint on how to deal with it.

I hunted down till I reached *macports::registry.format*  -->
*receipt_{flat/sqlite}.tcl
*files which have a bunch of functions using *registry::entry* which I
think is the most "basic" operation and then, also *receipt_sqlite::*
*create_entry_l* function.

Do I need to write for inserting into tables? If yes, write direct SQL
queries or Tcl procedures ( a better way, I think)?

Any help would be appreciated.

Regards,
Umesh


[1]:
https://github.com/macports/macports-base/blob/master/src/port/port.tcl#L3266
[2]:
https://github.com/macports/macports-base/blob/master/src/registry2.0/registry.tcl#L136

Re: [GSoC] migration

[Umesh Singla]

Hi

For testing it should be enough to just modify the registry.db locally
> as you need it. Once you reach a stable schema, you will have to add
> modifications to the registry schema at two places.
>
> 1) The initial database schema for new installations is defined here:
>
> https://github.com/macports/macports-base/blob/
> e3a0dc2ebde62a9c5feac6a1edee1708a95bb02a/src/cregistry/sql.c#L122-L131
>
> 2) The metadata table in registry.db has a row with key='version', where
> value holds the schema version. The code to update from one schema
> version to the next is here:
>
> https://github.com/macports/macports-base/blob/
> e3a0dc2ebde62a9c5feac6a1edee1708a95bb02a/src/cregistry/sql.c#L231-L240


Thanks Rainer for this. This is really useful. I had doubts on how often
cregistry/sql.c file gets updated or whether this is the one. The name
sql.c seems to be so OS core file. So, I can just add the new tables here?

Also, new tables means adding them in update_db() too, just like it is the
case with existing port or portgroup tables?

Forgive me for asking almost everything.


--
Umesh Singla

Re: [GSoC] migration

[Umesh Singla]

Hi

> I have not followed Rainer's strategy for having `port snapshot --create`
> and `port snapshot --restore` as discussed in the previous thread, instead
> have 3 separate actions...
>
> If I am following this correctly I think isolating the functionality into
> actions makes sense. If we want to refactor the interface in the future it
> will be easier to combine pieces then split into parts.


Acknowledged.

> 4. Another thing that ran my mind while pondering that there are 2
> options for sqlite database as well: make the tables in the very beginning
> (while initial installation) or while running the snapshot for the first
> time. I suggest to go with the first one because it's simple.
> > The major target is to finish the snapshot action before Jun 24.
>
> Does “port selfupdate” constitute an “initial installation”?
>

The way I went through macports1.0 -> selfupdate.tcl file, I don't see any
such thing.

Does port currently perform schema checks?
>

If there's sql.c -> update_db() function, then it should be called
somewhere. I only see it at one place inside registry attach function which
is not really relevant here.


> If port can detect if the schema needs updating then perhaps we can hook
> in and “do the right thing".
>

But all this is for the first time, right? I'll ponder over it more.

Point to me if I missed something vital.


> I suggest IRC #macports on Wednesdays at 2:00 PM UTC. If this time does
> not work for anyone who would like to be included suggest an alternative or
> additional day and time.
>

So, today!


--
Umesh Singla

Re: [GSoC] migration

[Umesh Singla]

Hi Rainer,

I have already created a new branch gsoc17-migrate in macports-base after
discussing with Jackson on IRC and just now, pushed some initial code to
https://github.com/macports/macports-base/tree/gsoc17-migrate, to begin
with. For the copyright part, I'll just ignore it, for now, it doesn't seem
to be a big deal.

Thanks

On Fri, Jun 9, 2017 at 5:18 AM, Rainer Müller <rai...@macports.org> wrote:

> Hello Umesh,
>
> good to hear from you! I was afraid we had already lost you...
>
> Where you will push your work to? Either create a new branch (e.g.
> gsoc17-migration) in macports/macports-base, or push to your own github
> account. It would be good to know which place to watch for updates.
>
> I will answer some of other questions inline below.
>
> On 2017-06-09 00:38, Umesh Singla wrote:
> > 2. In the proposal, I had written "what would be desirable is if `port`
> > was to /recommend/ a migration upon detecting a new environment", so we
> > can have it two ways - either check for the changes in the environment
> > before running every command or only check for the changes when a user
> > actually uses restore (or migrate) action.
> >
> > While the first one seems to be more realistic from user's perspective
> > but running it every time is also not a good idea since OS/hardware
> > changes are not frequent. I suggest running the detection for changes in
> > architecture before a set of some commands like install, sync,
> > selfupdate etc. The second option is actually on-top-of-head type
> > solution which assumes the user to be aware of any arch changes by
> > himself and thus, is actually not "recommending". Please suggest a way
> > to proceed.
> >
> > Also, is there any existing action which checks for changes in the
> > environment which I can use as a reference. I checked selfupdate but it
> > only checks how old port definitions are. Is it sufficed to check for
> > universal_arch/build_arch like options in `macports.conf` file,
> > comparing it with `uname -a` or `env` command outputs. How rigorous we
> > need the detection to be?
>
> Such a check already exists, which is executed an every initialization
> of the macports1.0 package. As this is just a simple compare of the OS
> version, it is no problem to run this every time. Currently it prints a
> link to the Migration wiki page:
>
> https://github.com/macports/macports-base/blob/
> e3a0dc2ebde62a9c5feac6a1edee1708a95bb02a/src/macports1.0/
> macports.tcl#L651-L656
>
> > 5. I saw the copyright license on top of most of the files. Do
> > developers have this, right from the beginning or after the initial work
> > on the module gets finished?
>
> The following goes with the usual IANAL disclaimer. In almost all
> jurisdictions, you own the copyright from the moment you create
> something. There is no need to explicitly claim copyright any more
> (mostly after USA reformed their copyright law in 1989). The headers in
> source code files have pure informational use.
>
> In my opinion, it only makes sense to list authors who contributed a
> significant amount of code to the file. Most of files in base should
> already list "The MacPorts Project". Although not being a legal entity,
> this is a kind of placeholder for all contributors holding the joint
> copyright ownership.
>
>
> While I could not answer all your questions right now (I have to leave
> some work for Bradley ;-)), feel free to ask questions as much as you
> like on the list or via IRC.
>
> Happy hacking on your project!
>
> Rainer
>

Re: [GSoC 2017] Community Bonding

[Umesh Singla]

Hi



> > About the project, so the `restore`, `snapshot` and `migrate` actions
> > are going to the action_array list [1]. While the flow was made clear
> > in the proposal, I think the first step should be to decide on an
> > exhaustive list of arguments/flags these 3 actions can possibly take.
> > This will help to design the procedures.
> >
> > Also, should we keep the code in a different Tcl script migrate.tcl
> > like `reclaim`?
>
> I would prefer that, yes. You'll just need
>   package provides macports 1.0
> line at the top and then you can write code as if it was in
> macports.tcl. Alternatively, you can do what reclaim.tcl does and use
>   package provides migrate 1.0
> and add 'package require migrate 1.0' in macports.tcl.
>
>
Since we are planning on 3 different actions which can also be used
independently like snapshot and migrate, having 2 scripts in the
macports1.0 directory directly or keeping these 2 commands in a single
script doesn't seem to be good from design pov. We can have a separate
folder for new (upcoming) actions with a hope that the existing code be
split into "action" modules over the time.


>
> If you need any additional special SQL queries, that can be done, yes.
> There should be abstractions available in Tcl already so that you don't
> have to deal with SQLite's C API directly, though.
>
>
The cregistry folder seems to have most of the sql queries implemented and
to deal with the registry database, I'll only have create, update and
select queries to do, so looks like I won't have to deal with C. I went
through an entire "port uninstall" example to see how from Tcl gets to
sqlite C through registry, so things seem a bit clear than before.


>
> Yes, the testing is not trivial at all. It might make sense to work with
> mocking a lot here (e.g. overwrite functions that would usually be
> called by your code to do nothing). That would allow you to run tests
> without actually changing your system or doing a lot of environment
> setup.
>
> Fortunately Tcl makes this quite easy because you can change any
> function definition at runtime.


Is there anything even sacred to Tcl? Till now, it looks like you can just
use anything in the language with pretty much anything else. This calls for
a new blog post. And planning to discuss on the testing part in next email.

Also, can we have a small README with two to three lines kept in every
folder in the base code at least? That'll be actually very helpful.

As Clemens suggested on IRC, will start with an *honest* short daily log of
the work like what I did for the project and what I did related to MP etc
from today onwards.

Also, I tried StackOverflow but does tclsh support all bash commands?


Regards,
Umesh Singla

Re: [GSoC 2017] Community Bonding

[Umesh Singla]

I've got it. It's umeshksin...@macports.org and the GitHub account I'll be
using is github.com/umeshksingla.

Thanks

On May 23, 2017 3:39 AM, "Bradley Giesbrecht" <pixi...@macports.org> wrote:

> On May 22, 2017, at 12:22 PM, Umesh Singla <umeshksin...@gmail.com> wrote:
>
> I have written two introductory posts on my blog [0] on Blogger.
>
> [0]: http://umeshsingla.blogspot.in/

Umesh, thanks for sharing this link.

In your second blog post you mention that by now you should have received
your MacPorts @macports.org handle. Please share your handle when you
receive it.

Also, please share the GitHub account you will be using for your MacPorts
work.


Regards,
Bradley Giesbrecht (pixilla)

Re: [GSoC 2017] Community Bonding

[Umesh Singla]

Hi

I have written two introductory posts on my blog [0] on Blogger. I thought
I shared the link to it in the proposal but no, I didn't. The one is just
when the results got announced and other about my take on the macports-base
video.

About the project, so the `restore`, `snapshot` and `migrate` actions are
going to the action_array list [1]. While the flow was made clear in the
proposal, I think the first step should be to decide on an exhaustive list
of arguments/flags these 3 actions can possibly take. This will help to
design the procedures.

Also, should we keep the code in a different Tcl script migrate.tcl like
`reclaim`? and code dealing with the database is going to be in C in
cregistry's sql.c [2], right? (like Tcl calling registry2.0 code
currently?)

All this is still trivial. What worries me most is the testing part. I'm
not sure Brad, how are we going to take on the testing phase. We can
virtually change specifications to see if the script works or compare the
two docker images? Also, it needs a set of tests that should include all
combinations of variants, requested-activate-deactivate scenarios. This is
one big task to be considered.

Guide me to the first step, thanks. It'd be great if you want to have a
FaceTime or Skype. I think after 0900 (UTC -8) would suit you best?


[0]: http://umeshsingla.blogspot.in/
[1]: https://github.com/macports/macports-base/blob/master/
src/port/port.tcl#L4264
[2]: https://github.com/macports/macports-base/blob/master/
src/cregistry/sql.c

On Mon, May 22, 2017 at 9:07 PM, Bradley Giesbrecht <pixi...@macports.org>
wrote:

> > On May 18, 2017, at 11:07 AM, Jackson Isaac <ijack...@macports.org>
> wrote:
> >
> > neverpanic's session[1] during MacPorts Meeting should help you get
> > started with macports-base and give you a good overview of macports
> > internals. Please go through it if not yet done.
> >
> > It would be great to hear from you how is community bonding is going
> > on till now. Let us know if you face any issues or need any help to
> > setup meetings.
> >
> > [1] https://www.youtube.com/watch?v=46qshiDskrM
>
>
> > On May 4, 2017, at 1:27 PM, Umesh Singla <umeshksin...@gmail.com> wrote:
> >
> > Regarding the work, I plan to keep a blog to report my progress. I'll
> write a post about every two weeks, and keep email communication with my
> mentors.
>
> Hi Umesh,
>
> Do you have a blog address you are ready to share?
> Have you watched the video [1] Jackson referenced?
> Do you have any questions about MacPorts base, this project or MacPorts in
> general?
>
> Looking forward to hearing from you.
>
> Regards,
> Bradley Giesbrecht (pixilla)
>
>
>


-- 
Umesh Singla

Re: Congratulations to all the selected GSOC students and projects

[Umesh Singla]

Hi

Thanks to the MacPorts guys for picking my project to be implemented! You
won't be disappointed! ;)
I see also that there's one other project in the organization.
Congratulations to my fellow interns!

Regarding the work, I plan to keep a blog to report my progress. I'll write
a post about every two weeks, and keep email communication with my mentors.

Thanks again, and you'll be hearing from me soon.
Have a nice weekend everyone! :)

Regards

On Fri, May 5, 2017 at 12:19 AM, Mojca Miklavec <mo...@macports.org> wrote:

> Dear students and developers,
>
> Google just announced 1,318 projects selected for the GSOC 2017.
>
> I'm happy to share with you that MacPorts got two slots for the
> following projects:
>
> - Umesh Singla:
>   Adding migrate action to port command
>   mentor: Bradley Giesbrecht (pixilla)
>
> - "Zero King" (l2dy)
>   Bot and CI for macports-ports
>   mentors: Clemens Lang (cal/neverpanic) & Mojca Miklavec (mojca)
>
> At this point I would like to express my gratitude to Jackson Isaac
> who took over the administration and made sure that we applied in time
> :)
>
> Apart from (at least!) weekly meetings with the mentors, either via
> our IRC channel (or somewhere else if more appropriate) we would like
> to encourage the students to *publicly* interact with the community.
> Ask questions on the mailing list and IRC, so that the rest of the
> community will be kept up to date and will be able to help you even if
> mentors will be temporarily offline.
>
> Unless you have some issues of private nature that should not be read
> by everyone, please try to avoid sending private emails for technical
> discussions.
>
> I suggest that we create a new entry for 2017 at
> https://trac.macports.org/wiki/SummerOfCodeArchive
> and add the description of projects to
> https://trac.macports.org/wiki/SummerOfCode2017
>
> The time until the end of May is meant for community bonding period,
> learning our codebase or any other tools needed to get up to speed by
> the time the official coding period begins.
>
> Project proposals/plans can still be improved or adapted by the end of
> the month provided that both the student and mentor(s) agree to
> changes.
>
>
> To answer the (semi-serisous) question about what happens if the
> project is finished way before the GSOC is over or whether it's OK to
> start coding before the official coding period starts: this is of
> course no problem as long a you keep in mind that it is desired to
> keep coding and produce useful results until the end of the program.
> (In particular: coding 16 hours per days and completing the project in
> May and then quitting GSOC doesn't count.)
>
> I hope that others will add more to this thread.
>
> Mojca
>



-- 
Umesh Singla

Re: GSoC'17: Add migrate action to port command Project

[Umesh Singla]

Hi cal, ijackson

Thanks for reviewing my proposal and providing a great feedback. I've
replied to most of your comments in the proposal. This surely helps. Please
let me know if I have made some false assumption about anything, the
timeline/ project plan needs to be modified a great bit or I haven't talked
about some issue (like hardware, performance, ) which you were expecting
etc. These things can affect my application, so I'm just asking for more
guidance.

Thank you so much,
Umesh

Re: GSoC'17: Add migrate action to port command Project

[Umesh Singla]

Hi


> I believe at a minimum we should plan on two new actions, port “snapshot”
> and “migrate”. A snapshot will the installed ports, their variants and if
> the port was “requested”.
>
> The migrate action will call the snapshot action to create and/or use
> snapshots to rebuild ports on the new platform.
>

This looks quite a plan.
So, what snapshot action will do is to take a "snapshot" of each installed
port and keep a list of these snapshots having a name, requested boolean
and other required info (will try to figure it out soon) additionally.

A variants table will help to specify the appropriate variants, so
basically an indirect version of this: `sudo port install port_name
+variant1 +variant2`.

Migrate action will take these snapshots and use the original guidelines in
the migration docs to rebuild acc to the specifications we now have.
Correct me if I'm wrong.


> I think it is a good idea to include snapshot as an early milestone.


> Does the migrate and snapshot actions help you divide the work?
>

Yes, thanks, this gives a lot of direction to my work.


> The snapshot action is basically an inventory of what is installed along
> with meta data like requested and variants. We will store snapshots in our
> sqlite database.
>

I hope I understood it well as above.


>
> > I don't know if we'll allow Tcl to run in the new environment.
> Otherwise, it seems to implement port with a bash script calling on sqlite3
> on the macports registry/registry.d to get the relevant data.
>
> I think we can require any version of port that includes the migrate
> action, I do not think we will need bash. Clemens, others, do you concur?
>

That time, I was trying to say that for a more general scenario, it'll take
to implement port with a bash front-end that invoked sqlite3 directly upon
the MacPorts registry (located in ${prefix}/var/macports/registry/registry.d)
(not anymore) and extracting the required data. Yes, the above seems an
elegant solution but still migrate action needs more implementation
detailing. Let me work on it.

> Also, will the project phasing out dependency on XCode tools affect this
> one anytime soon?
> Good question, I cannot give you a definitive answer at the moment but we
> should keep this in mind.
>

will include this as stretch goal or something like "Plans after GSoC" :D

An additonal point of thought would be to resolve the conflicts arising if
there are conflicting ports in the list and I guess, order of reinstalling
ports could also be one such factor for conflict if not the default
variants?

Thanks,
Umesh

GSoC'17: Add migrate action to port command Project

[Umesh Singla]

Hello,

As we discussed on IRC, I've been looking into the project "Add migrate
action to port command" and hoping to submit a draft proposal very soon.
I'll need your help in putting up a nice proposal for sure.

I'm currently trying to acquaint myself with the MacPorts codebase and came
across the Macports guide [0]. Thanks for keeping such guides for newbies.
The project description points to a migration instruction guide [1],
automating which is more or less the goal of the project, am I right?

Since final submission deadline is close, I'll be grateful if someone can
point me in the right direction for now and not waste time fiddling around.

Also, @Jackson, I'm not able to find any discussion about this project on
mailing list threads. Can you link me to them? I think they'll help me in
understanding the need and expected outcomes by the community from this
project and *might give a better insight into the project*.

@pixilla, if we need to discuss, what'd be the best time according to your
timezone?

Hoping for a quick reply,
Umesh

[0]: https://guide.macports.org/
[1]: https://trac.macports.org/wiki/Migration

Introducing for GSoC'17

[Umesh Singla]

Hi,
I am Umesh Singla, a third-year Computer Science student at IIIT Hyderabad.
I'm relatively new to MacPorts. I have a programming experience of a few
years and have worked with Python and C. I am also a regular contributor to
The OpenDaylight Project. You can have a look at my Github here
<https://github.com/umeshksingla> and my CV here
<https://web.iiit.ac.in/~umeshkumar.singla/resume.pdf>.

As suggested, I have Xcode and Xcode cl tools installed, gone through a
basic tutorial on Tcl and sorted out some of the projects from the ideas
list. I'll try to get my development environment ready soon.

Please suggest if some of the projects have high priority than others, so
that I can choose my project which could be useful at the time. If
possible, suggest a beginner task to work on.

Looking forward to working with you all.

Thanks,
Umesh
IRC - umeshksingla