Re: Working with Git
> > Now I still seem to have this branch in my local git repo: > > $ git branch > l2dy-curl-ca-bundle-update > * master > > Can I delete it? With, I presume, "git branch -d l2dy-curl-ca-bundle-update"? Yes, you can delete it with the command you show (unless it complains that it is not merged into master, in which case you might need -D instead of -d). -Sterling ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: New build failure emails are difficult to act on
> On Nov 2, 2016, at 06:52, Lawrence Velázquez wrote: > > Can you open a ticket for this and assign it to me? You can just > copypaste your original email as the description or something. Thanks: https://trac.macports.org/ticket/52810#ticket > > vq > >> On Nov 2, 2016, at 3:56 AM, Jeremy Huddleston Sequoia >> wrote: >> >> >>> On Nov 2, 2016, at 00:20, Mojca Miklavec wrote: >>> >>> On 2 November 2016 at 06:17, Jeremy Huddleston Sequoia wrote: I've been having a bit of difficulty dealing with the new buildbot emails. I would really like links to the individual failing jobs. Instead, we're given links to each job and a list of failed ports, but there is no indication as to which port corresponds to which job. One must look thorough each link to find the relevant one. Could we get those links added to the 'Broken ports' section? >>> >>> Sure. We gladly accept patches :) :) :) >>> >>> OK, joke aside. I wrote the part of the code that generates the >>> emails, but I did not manage to figure out how to map the build >>> number/url to a port. Buildbot nine is apparently more clever about >>> that and there it should apparently be more straightforward to do it, >>> but many are reluctant to switch just yet. >>> >>> There are several ways to fix this: >>> >>> - hack into Python code (most elegant, but I did not have any success >>> with that yet) >>> >>> - I once tried to fetch the contents of json files for individual >>> builds and parse it, but that crashed/froze the buildbot (it might be >>> that I wrote buggy code, but that approach is super ugly anyway) >>> >>> - probably the easiest workaround would be to print the URL or the >>> build number to >>> https://build.macports.org/builders/ports-10.8_x86_64_legacy-watcher/builds/2764/steps/summary/logs/stdio >>> which would make it easier to map the URLs to ports. >>> >>> Somewhat related tickets: >>> https://trac.macports.org/ticket/52766 >>> https://trac.macports.org/ticket/51995 >> >> FYI, My current hack method is to open the 'Full logs:' link, check out the >> summary, and then figure out from that list which of the job's to check (if >> the third job failed, pick the link with the third number in the series). >> >> --Jeremy >> >> ___ >> macports-dev mailing list >> macports-dev@lists.macosforge.org >> https://lists.macosforge.org/mailman/listinfo/macports-dev > smime.p7s Description: S/MIME cryptographic signature ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: Working with Git
> On Oct 31, 2016, at 12:04 PM, Lawrence Velázquez wrote: > >> On Oct 31, 2016, at 11:29 AM, Ryan Schmidt wrote: >> >>> On Oct 5, 2016, at 9:53 PM, Ryan Schmidt wrote: >>> >>> How will this work on GitHub? >>> >>> The user will submit a pull request. How do I test it locally? What if the >>> pull request is incomplete? I know I can tell the user what's wrong, and >>> they can push another commit to the same branch they made to initiate the >>> pull request, and those new commits will automatically appear in the pull >>> request, and I can then merge it if I like it. But what if the user does >>> not respond and fix the changes? What if the user makes additional commits >>> but they're still not sufficient? How do I take the user's pull request, >>> make additional changes, and commit them to our master? >> >> There were several different and sometimes conflicting answers to this >> question in this thread. Now that we have converted to git, and I have >> received a pull request for one of my ports, I need to know how to test it >> locally and then commit it to master. I don't want to understand git's >> theory or to be given lots of options amongst which to choose; I just want >> to be told how to get my work done. > > Here are some rough instructions. These will have to be refined; let me > know if you have any problems. I'm writing this in a bit of > a sleep-deprived fog. > > To the right of the big green "Rebase and merge" button on the PR page, > you should see a link to view "command line instructions". Those > instructions are almost what you want, but you'll have to tweak them to > avoid merge commits. Yes, there are "command line instructions" on the web site, but they are different from the commands you gave below, which are again different from other commands suggested in previous threads, so it is difficult to know which set of instructions to follow. > To obtain the submitter's changes: > > $ git fetch https://github.com/l2dy/macports-ports.git > curl-ca-bundle-update > $ git checkout -b l2dy-curl-ca-bundle-update FETCH_HEAD > $ git rebase master l2dy-curl-ca-bundle-update > > The first command imports changes from the submitter's > "curl-ca-bundle-update" branch. The second command creates a new local > branch to match. The third command transplants the submitter's changes > onto the top of your master branch. (Rebasing will fail if the > submitter's changes don't apply cleanly to the current ports tree. You > can just ask them to fix this themselves and push a new branch.) > > Now you can check out the new branch and try out the submitter's > changes. You can also modify the branch as you see fit. > > $ git checkout l2dy-curl-ca-bundle-update > > When you're ready to push the submitter's contributions to master: > > $ git checkout master > $ git merge --ff-only l2dy-curl-ca-bundle-update > $ git push origin master Thanks, that worked, up until the "git push origin master" command, which asked me to authenticate, and supplying my username and password was unsuccessful: $ git push origin master Username for 'https://github.com': ryandesign Password for 'https://ryandes...@github.com': remote: Invalid username or password. fatal: Authentication failed for 'https://github.com/macports/macports-ports.git/' Instead, I used GitHub Desktop's "Sync" button, which worked. I usually prefer to use GitHub Desktop, but it would be nice to be able to push from the command line as well. > The first two commands incorporate the submitter's changes into your > master branch. The last one pushes to GitHub. Now I still seem to have this branch in my local git repo: $ git branch l2dy-curl-ca-bundle-update * master Can I delete it? With, I presume, "git branch -d l2dy-curl-ca-bundle-update"? >> Could someone please update the WorkingWithGit page with the correct >> instructions? > > Yes, I will polish up that page this week, as well as the migration FAQ. ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: GitHub usernames as maintainers
On 2016-11-02 23:58, Clemens Lang wrote: > On Wed, Nov 02, 2016 at 06:45:21PM -0400, Brandon Allbery wrote: >> For me, it looks too much like an email address when combined with >> other things (e.g. "maintainers openmaintainer @foo"). > > I think that's a formatting problem. We could just as well print > https://github.com/neverpanic in the output of port info --maintainer, > which is (a) not ambiguous, and (b) clickable. Although clickable, from such an URL it is quite strange to deduce what to use in the CC field on tickets. Rainer ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: Github user repos?
On 2016-11-02 23:39, Ryan Schmidt wrote: > Contrary to Rainer's statement above, my plan was to leave unclaimed > old user repo in the macports org indefinitely. Deleting them implies > they contain no useful information; having not examined them, I'm not > in a position to make that determination. I do not mind keeping them in the GitHub organization for the time being, but after some time has passed, we should get rid of unclaimed user repositories. We will still have these files and their history in the svn repository, that will stay available as a read-only copy. Rainer ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: Proposal for a MacPorts'ish commit message template
On 2016-11-02 23:46, Ryan Schmidt wrote: >> Which editor are you using? It differs by editor. > > Well, you mentioned vim. Very occasionally I use that. I don't > remember seeing any particular syntax highlighting in it when editing > a commit message. You would need these settings in your ~/.vimrc, which enable syntax highlighting in general: filetype plugin indent on syntax on On the first line, the text color will change after 50 characters. The second line will turn red if it is not blank as supposed to be. Rainer ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: Proposal for a MacPorts'ish commit message template
On Wed, Nov 02, 2016 at 05:46:16PM -0500, Ryan Schmidt wrote: > Well, you mentioned vim. Very occasionally I use that. I don't > remember seeing any particular syntax highlighting in it when editing > a commit message. You need syntax highlighting (:syntax on) and ideally color enabled. Additionally, the filetype must be set to 'gitcommit' (:setfiletype gitcommit). I have "syntax on" in my ~/.vimrc and the filetype is automatically set when I get prompted for a git commit message. I don't know how that happens. To enforce a certain textwidth, you can just :set textwidth=72. Text typed after you set this will automatically wrap. Other text can be reflowed, for example by selecting it in visual mode (shift+v) and pressing gq. > Usually I use TextWrangler or TextMate. TextMate has a file type for git commit messages. Unfortunately, it only seems to highlight overlong summary lines and nothing else (e.g. it does not warn you about text in the second line). You can get a wrap column in TextMate using View > Show Wrap Column and set the position of the line in View > Wrap Column... I do not know TextWrangler. -- Clemens ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: GitHub usernames as maintainers
On Wed, Nov 02, 2016 at 06:45:21PM -0400, Brandon Allbery wrote: > For me, it looks too much like an email address when combined with > other things (e.g. "maintainers openmaintainer @foo"). I think that's a formatting problem. We could just as well print https://github.com/neverpanic in the output of port info --maintainer, which is (a) not ambiguous, and (b) clickable. -- Clemens ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: How to handle MacPorts' handles in the future (including the email address connected to it)??
> On Nov 1, 2016, at 3:17 PM, Marko Käning wrote: > > Hi Rainer, > > On 01 Nov 2016, at 21:05 , Rainer Müller wrote: >> What do you mean by address rewriting? If you are referring to problems >> with SPF, > > I guess I do. > > >> the new mail server is now doing SRS [1]. > > OK... > > >> Right now we do not host any mailboxes with IMAP, we only forward mails >> to existing addresses. I would like to keep the administrative overhead >> low, certainly all developers have an existing mailbox. > > Yeah, I understand that. I’d be happy enough with the rewriting approach. > > >> Although I thought about implementing authenticated mail submission on >> our mail server in order to be able to enable SPF for macports.org and >> reduce spam. But that will not happen in the near future while there are >> other issues. > > So, what does it mean? Does the new server support it - as written above - or > doesn’t MacPorts support it? > > You see me confused. ;) I'm confused about why you're confused or what you're talking about. We've always provided @macports.org email forwarding for committers. You tell us what handle you want, we set it up to forward to whatever email address you want. We had that for 10 years on macOS forge and we now moved that same system to our new server. Is it not working for you for some reason? ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: Github user repos?
On 11/2/16 3:39 PM, Ryan Schmidt wrote: > >> On Nov 1, 2016, at 3:49 PM, David Evans wrote: >> >> On 11/1/16 1:21 PM, Rainer Müller wrote: >>> On 2016-11-01 21:10, David Evans wrote: I see that some github user repos have been created while others (like mine ;-) ) have not. Is this an ongoing process that's going to take a while or is there some action that the user needs to take and get his repo created? >>> >>> Yours is already there: >>> >>> https://github.com/macports/macports-user-devans >>> >>> GitHub only show the most recently modified repositories on the >>> organization page. You need to use the search box on top of the list of >>> repositories to find it. >>> BTW, I note that at least one of those already created belongs to a maintainer who has not been with us for quite a while (nox). >>> >>> The plan is to eventually remove them, if users do not claim them. >>> Maybe they should be done on a per request basis to avoid converting abandoned user space. >>> >>> All of our Subversion history was converted and each commit moved to the >>> appropriate Git repository. There is no extra work involved with this. >>> >>> Rainer >>> >> >> Thanks, Rainer. I thought I had probably missed something. As they say the >> Navy, "There's always 10% that don't get >> the word." >> >> I see from the previous reply that there is some feeling that these repos >> should be moved from the MacPorts >> organizational account to the user's own account. Or can they stay where >> they are indefinitely as long as >> they are active? > > Active user repos should be moved to that user's personal GitHub account and > used or refactored there. > > Contrary to Rainer's statement above, my plan was to leave unclaimed old user > repo in the macports org indefinitely. Deleting them implies they contain no > useful information; having not examined them, I'm not in a position to make > that determination. Thanks for the clarification. I've moved (forked) mine to my personal account and the original has been deleted at my request. Dave ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: Proposal for a MacPorts'ish commit message template
> On Nov 2, 2016, at 5:43 PM, Clemens Lang wrote: > > On Wed, Nov 02, 2016 at 05:33:28PM -0500, Ryan Schmidt wrote: >>> vim does that with syntax highlighting automatically nowadays when >>> it notices you are writing a commit message. If you need an >>> indication on your line width, may I suggest you configure your >>> editor appropriately? >> >> Can we document in the WorkingWithGit page how to do that? I have no >> idea. > > Which editor are you using? It differs by editor. Well, you mentioned vim. Very occasionally I use that. I don't remember seeing any particular syntax highlighting in it when editing a commit message. Usually I use TextWrangler or TextMate. ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: GitHub usernames as maintainers
On Wed, Nov 2, 2016 at 6:42 PM, Clemens Lang wrote: > > When we were originally planning the transition to GitHub, I suggested > > that we allow an "@" syntax in the maintainers line for GitHub > > usernames (i.e. "maintainers @neverpanic" for Clemens). I don't > > remember right now why we then decided that wasn't a good idea. > > I think we should re-visit that decision. Maybe I'll find a couple of > minutes to implement this in base. If so, I'll send a PR for discussion. For me, it looks too much like an email address when combined with other things (e.g. "maintainers openmaintainer @foo"). -- brandon s allbery kf8nh sine nomine associates allber...@gmail.com ballb...@sinenomine.net unix, openafs, kerberos, infrastructure, xmonadhttp://sinenomine.net ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: Proposal for a MacPorts'ish commit message template
On Wed, Nov 02, 2016 at 05:33:28PM -0500, Ryan Schmidt wrote: > > vim does that with syntax highlighting automatically nowadays when > > it notices you are writing a commit message. If you need an > > indication on your line width, may I suggest you configure your > > editor appropriately? > > Can we document in the WorkingWithGit page how to do that? I have no > idea. Which editor are you using? It differs by editor. -- Clemens ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: GitHub usernames as maintainers
On Wed, Nov 02, 2016 at 05:27:30PM -0500, Ryan Schmidt wrote: > On Nov 2, 2016, at 1:49 AM, Mojca Miklavec wrote: > > It would be nice if "port info" would also print the github > > usernames of maintainers. > > When we were originally planning the transition to GitHub, I suggested > that we allow an "@" syntax in the maintainers line for GitHub > usernames (i.e. "maintainers @neverpanic" for Clemens). I don't > remember right now why we then decided that wasn't a good idea. I think we should re-visit that decision. Maybe I'll find a couple of minutes to implement this in base. If so, I'll send a PR for discussion. -- Clemens ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: GitHub migration complete
> On Nov 1, 2016, at 3:52 AM, Marko Käning wrote: > > On 01 Nov 2016, at 04:00 , Ryan Schmidt wrote: >> We suggest that you move your user repository to your own GitHub account >> where you can continue to use it as you see fit. Instructions for how to >> move it are forthcoming. You should not use the Fork button to do so. > > Can I simply remove it? Yes, if you don't need what's in your user repo anymore, we can delete it. ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: Github user repos?
> On Nov 1, 2016, at 3:49 PM, David Evans wrote: > > On 11/1/16 1:21 PM, Rainer Müller wrote: >> On 2016-11-01 21:10, David Evans wrote: >>> I see that some github user repos have been created while others (like mine >>> ;-) ) have not. Is this an ongoing process >>> that's going to take a while or is there some action that the user needs to >>> take and get his repo created? >> >> Yours is already there: >> >> https://github.com/macports/macports-user-devans >> >> GitHub only show the most recently modified repositories on the >> organization page. You need to use the search box on top of the list of >> repositories to find it. >> >>> BTW, I note that at least one of those already created belongs to a >>> maintainer who has not been with us for quite a >>> while (nox). >> >> The plan is to eventually remove them, if users do not claim them. >> >>> Maybe they should be done on a per request basis to avoid converting >>> abandoned user space. >> >> All of our Subversion history was converted and each commit moved to the >> appropriate Git repository. There is no extra work involved with this. >> >> Rainer >> > > Thanks, Rainer. I thought I had probably missed something. As they say the > Navy, "There's always 10% that don't get > the word." > > I see from the previous reply that there is some feeling that these repos > should be moved from the MacPorts > organizational account to the user's own account. Or can they stay where > they are indefinitely as long as > they are active? Active user repos should be moved to that user's personal GitHub account and used or refactored there. Contrary to Rainer's statement above, my plan was to leave unclaimed old user repo in the macports org indefinitely. Deleting them implies they contain no useful information; having not examined them, I'm not in a position to make that determination. ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: New build failure emails are difficult to act on
> On Nov 2, 2016, at 12:17 AM, Jeremy Huddleston Sequoia > wrote: > > I've been having a bit of difficulty dealing with the new buildbot emails. I > would really like links to the individual failing jobs. Instead, we're given > links to each job and a list of failed ports, but there is no indication as > to which port corresponds to which job. One must look thorough each link to > find the relevant one. > > Could we get those links added to the 'Broken ports' section? Many improvements to the buildbot emails are desired, which I've described before. We haven't had time to look into implementing any of them yet. ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: Proposal for a MacPorts'ish commit message template
MacPorts used CVS commit templates 10 years ago. This was before my involvement with MacPorts, so I don't know how it was decided to do that in the first place or what developer opinions about it were. But you don't have to look at too much of the history of the repositories from 2006 and prior to see what a disaster it was. Developers would fill in some fields and not others, or completely ignore the template and write their own message above or below it. Maybe with instructional comments it would be better, on the other hand, my initial reaction to your template (and my initial reaction when I saw it mentioned previously) was "TL;DR". On Nov 1, 2016, at 6:08 PM, Clemens Lang wrote: > > On Tue, Nov 01, 2016 at 11:51:52PM +0100, Marko Käning wrote: > >> as I find it on the console quite handy to know when 50 or 72 >> characters are reached in a line: > > vim does that with syntax highlighting automatically nowadays when it > notices you are writing a commit message. If you need an indication on > your line width, may I suggest you configure your editor appropriately? Can we document in the WorkingWithGit page how to do that? I have no idea. ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: GitHub usernames as maintainers
On Nov 2, 2016, at 1:49 AM, Mojca Miklavec wrote: > It would be nice if "port info" would also print the github usernames > of maintainers. When we were originally planning the transition to GitHub, I suggested that we allow an "@" syntax in the maintainers line for GitHub usernames (i.e. "maintainers @neverpanic" for Clemens). I don't remember right now why we then decided that wasn't a good idea. ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
New mailing list host: lists.macports.org
Hello, as part of the move off of macOS forge, we will migrate the mailing lists to the new mail server. We will migrate all subscriptions and user preferences and postings to the old mailing list addresses will be forwarded. However, the new hostname lists.macports.org implies that addresses and List-Ids will change. Please adapt your filtering rules and expect mails with addresses @lists.macports.org. The migration of all lists to the new host and addresses will happen this weekend, November 5/6. Rainer ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Kudos to Jeremy...
Who has been on a holy terror for 36 hours. Fixing the libunwind bug (on our heads for two years) and updating / advancing all the compiler infrastructure / libcxx / libcxx abi and many other ports Someone gave that man a JOLT cola! Ken ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: New project members: jonesc
> On 02 nov 2016, at 20:07, Lawrence Velázquez wrote: > >> Please join us in welcoming the following new MacPorts project member: >> >> - Chris Jones (jonesc) >> >> We look forward to continued excellent contributions! Welcome Chris! 😊 -- Aljaž Srebrnič a.k.a g5pw My public key: https://g5pw.me/key Key fingerprint = 2109 8131 60CA 01AF 75EC 01BF E140 E1EE A54E E677 signature.asc Description: Message signed with OpenPGP using GPGMail ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: New project members: jonesc
Thanks All ! > On 2 Nov 2016, at 7:07 pm, Lawrence Velázquez wrote: > >> On Nov 2, 2016, at 2:20 PM, Rainer Müller wrote: >> >> Please join us in welcoming the following new MacPorts project member: >> >> - Chris Jones (jonesc) >> >> We look forward to continued excellent contributions! > > Yay! > > vq > ___ > macports-dev mailing list > macports-dev@lists.macosforge.org > https://lists.macosforge.org/mailman/listinfo/macports-dev ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: New project members: jonesc
> On Nov 2, 2016, at 2:20 PM, Rainer Müller wrote: > > Please join us in welcoming the following new MacPorts project member: > > - Chris Jones (jonesc) > > We look forward to continued excellent contributions! Yay! vq ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: [macports-ports] branch master updated: libcxx: Bump to 3.9.0 (#52666)
Hi, On Wed, Nov 02, 2016 at 09:57:37AM -0700, Bradley Giesbrecht wrote: > Can you pass multiple tickets (closes x y z)? Yes, space-separated, comma-separated, or because the ticket references are quite long, just with multiple Closes $ticket lines. -- Clemens ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: Trac down again
On 2016-11-02 19:16, Adam Mercer wrote: > On Tue, Nov 1, 2016 at 10:17 AM, Rainer Müller wrote: > >> We still have some options for tuning, but as it only occurs >> sporadically, we always have to wait to see if this solved it. > > Seems like trac is down again, just got a 503. Does it need another kick? We are on it and investigating what the currently running requests and processes are. It will return shortly. Rainer ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
New project members: jonesc
Please join us in welcoming the following new MacPorts project member: - Chris Jones (jonesc) We look forward to continued excellent contributions! - Joshua, Ryan, and Rainer Do you want to join the MacPorts team? If you would like to be considered for team membership and commit access, please read this section of the Guide: http://guide.macports.org/chunked/project.membership.html ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: Trac down again
On Tue, Nov 1, 2016 at 10:17 AM, Rainer Müller wrote: > We still have some options for tuning, but as it only occurs > sporadically, we always have to wait to see if this solved it. Seems like trac is down again, just got a 503. Does it need another kick? Cheers Adam ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: [macports-ports] branch master updated: libcxx: Bump to 3.9.0 (#52666)
> On Nov 1, 2016, at 5:47 PM, Rainer Müller wrote: > > On 2016-11-02 00:54, Jeremy Huddleston Sequoia wrote: >> Jeremy Huddleston Sequoia (jeremyhu) pushed a commit to branch master >> in repository macports-ports. >> >> https://github.com/macports/macports-ports/commit/864eb7639d6774a7853767be6b15384c790bfe70 > >> [...] > >> commit 864eb7639d6774a7853767be6b15384c790bfe70 >> Author: Jeremy Huddleston Sequoia >> AuthorDate: Tue Nov 1 16:52:53 2016 -0700 >> >>libcxx: Bump to 3.9.0 (#52666) >> >>Signed-off-by: Jeremy Huddleston Sequoia > > Please do not use the # syntax anymore in commit messages. This is now > reserved for references to pull requests on GitHub. Instead, paste the > full URL to the Trac ticket into the commit message: > > Closes https://trac.macports.org/ticket/52666 > > When you add keywords such as "closes", "fixes", "fix" in front of the > ticket URL, the ticket will also automatically be closed with a > reference to the commit. Can you pass multiple tickets (closes x y z)? Regards, Bradley Giesbrecht (pixilla) ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: New build failure emails are difficult to act on
Can you open a ticket for this and assign it to me? You can just copypaste your original email as the description or something. vq > On Nov 2, 2016, at 3:56 AM, Jeremy Huddleston Sequoia > wrote: > > >> On Nov 2, 2016, at 00:20, Mojca Miklavec wrote: >> >> On 2 November 2016 at 06:17, Jeremy Huddleston Sequoia wrote: >>> I've been having a bit of difficulty dealing with the new buildbot emails. >>> I would really like links to the individual failing jobs. Instead, we're >>> given links to each job and a list of failed ports, but there is no >>> indication as to which port corresponds to which job. One must look >>> thorough each link to find the relevant one. >>> >>> Could we get those links added to the 'Broken ports' section? >> >> Sure. We gladly accept patches :) :) :) >> >> OK, joke aside. I wrote the part of the code that generates the >> emails, but I did not manage to figure out how to map the build >> number/url to a port. Buildbot nine is apparently more clever about >> that and there it should apparently be more straightforward to do it, >> but many are reluctant to switch just yet. >> >> There are several ways to fix this: >> >> - hack into Python code (most elegant, but I did not have any success >> with that yet) >> >> - I once tried to fetch the contents of json files for individual >> builds and parse it, but that crashed/froze the buildbot (it might be >> that I wrote buggy code, but that approach is super ugly anyway) >> >> - probably the easiest workaround would be to print the URL or the >> build number to >> https://build.macports.org/builders/ports-10.8_x86_64_legacy-watcher/builds/2764/steps/summary/logs/stdio >> which would make it easier to map the URLs to ports. >> >> Somewhat related tickets: >> https://trac.macports.org/ticket/52766 >> https://trac.macports.org/ticket/51995 > > FYI, My current hack method is to open the 'Full logs:' link, check out the > summary, and then figure out from that list which of the job's to check (if > the third job failed, pick the link with the third number in the series). > > --Jeremy > > ___ > macports-dev mailing list > macports-dev@lists.macosforge.org > https://lists.macosforge.org/mailman/listinfo/macports-dev ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: port info --{build,configure}.dir ?
> On Nov 2, 2016, at 5:06 AM, René J.V. Bertin wrote: > > Would a request to provide the build and/or configure directory > variables as meta-info data be accepted? Probably not. vq ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Update to new version of GDB 7.12
Hello The GDB debugger version in macports is currently gdb7.9, there is a newer version gdb7.12 with improved support for dynamic structures. Is it possible for Macports to upload this new version so it can be installed? The current version of GDN in macports is very outdated (GDB7.9) the update version is GDB 7.12. ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
port info --{build,configure}.dir ?
Hi, Would a request to provide the build and/or configure directory variables as meta-info data be accepted? Evidently it's something that's relevant to port developer only (or almost, like info --patchfiles). R. ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: New build failure emails are difficult to act on
> On Nov 2, 2016, at 00:20, Mojca Miklavec wrote: > > On 2 November 2016 at 06:17, Jeremy Huddleston Sequoia wrote: >> I've been having a bit of difficulty dealing with the new buildbot emails. >> I would really like links to the individual failing jobs. Instead, we're >> given links to each job and a list of failed ports, but there is no >> indication as to which port corresponds to which job. One must look >> thorough each link to find the relevant one. >> >> Could we get those links added to the 'Broken ports' section? > > Sure. We gladly accept patches :) :) :) > > OK, joke aside. I wrote the part of the code that generates the > emails, but I did not manage to figure out how to map the build > number/url to a port. Buildbot nine is apparently more clever about > that and there it should apparently be more straightforward to do it, > but many are reluctant to switch just yet. > > There are several ways to fix this: > > - hack into Python code (most elegant, but I did not have any success > with that yet) > > - I once tried to fetch the contents of json files for individual > builds and parse it, but that crashed/froze the buildbot (it might be > that I wrote buggy code, but that approach is super ugly anyway) > > - probably the easiest workaround would be to print the URL or the > build number to > https://build.macports.org/builders/ports-10.8_x86_64_legacy-watcher/builds/2764/steps/summary/logs/stdio > which would make it easier to map the URLs to ports. > > Somewhat related tickets: > https://trac.macports.org/ticket/52766 > https://trac.macports.org/ticket/51995 FYI, My current hack method is to open the 'Full logs:' link, check out the summary, and then figure out from that list which of the job's to check (if the third job failed, pick the link with the third number in the series). --Jeremy smime.p7s Description: S/MIME cryptographic signature ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: New build failure emails are difficult to act on
On 2 November 2016 at 06:17, Jeremy Huddleston Sequoia wrote: > I've been having a bit of difficulty dealing with the new buildbot emails. I > would really like links to the individual failing jobs. Instead, we're given > links to each job and a list of failed ports, but there is no indication as > to which port corresponds to which job. One must look thorough each link to > find the relevant one. > > Could we get those links added to the 'Broken ports' section? Sure. We gladly accept patches :) :) :) OK, joke aside. I wrote the part of the code that generates the emails, but I did not manage to figure out how to map the build number/url to a port. Buildbot nine is apparently more clever about that and there it should apparently be more straightforward to do it, but many are reluctant to switch just yet. There are several ways to fix this: - hack into Python code (most elegant, but I did not have any success with that yet) - I once tried to fetch the contents of json files for individual builds and parse it, but that crashed/froze the buildbot (it might be that I wrote buggy code, but that approach is super ugly anyway) - probably the easiest workaround would be to print the URL or the build number to https://build.macports.org/builders/ports-10.8_x86_64_legacy-watcher/builds/2764/steps/summary/logs/stdio which would make it easier to map the URLs to ports. Somewhat related tickets: https://trac.macports.org/ticket/52766 https://trac.macports.org/ticket/51995 Mojca ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev