mainManeage - Support: sr #110220, Checking for available space in...

 
 

sr #110220: Checking for available space in build directory

Submitter:  Pedram Ashofteh-Ardakani <pedram>
Submitted:  Sun 05 Apr 2020 06:13:43 AM UTC
   
 
Category:  None Priority:  5 - Normal
Severity:  3 - Normal Status:  Done
Privacy:  Public Assigned to:  pedram
Open/Closed:  Closed Operating System:  GNU/Linux
* Mandatory Fields

Add a New Comment Rich Markup
   

Jump to the original submission

Thu 25 Jun 2020 10:45:47 PM UTC, comment #36: 

Great, thanks a lot Pedram ;-)! It has been merged into the core Maneage branch as Commit 5c3f2c4e38b. Just some small points:

  • Generally, its good practice to not use ALLCAPS variable names in a shell script. When a reader sees such variable names, they expect that the variable is an environment variable, not an internal shell variable.


  • Its best to avoid specialized things like 'local' in a portable script. The 'configure.sh' script can't assume any particular shell and should work on all of them and its not easy to confirm if 'local' is supported on all.


  • Some minimalist shells may not support '-lt'. So its more robust to use AWK for numeric checks (which supports this job on any POSIX system).


  • I also added a small 'sleep' command after the warning to let the user read the message and have time to reconsider their choice ;-).


Since it has been merged, I am now closing this task.

Mohammad Akhlaghi <makhlaghi>
Group administrator
Thu 25 Jun 2020 09:15:17 AM UTC, comment #35: 

Great! Following comment #15 about the `df` command, I removed the `-T` option as well as all other options. We don't need any extra options actually.

So, I made this commit on gitlab to check for available space. I ran the `configure.sh` file to check if it works as expected. The output looked fine to me. Please let me know if I should make changes.

Pedram Ashofteh-Ardakani <pedram>
Group Member
Sat 16 May 2020 06:46:23 AM UTC, comment #34: 

Good news! Thanks to Mohammad for introducing the `info` command, now I can understand commands easier without the need to surf the net!

OK. While experimenting, I found out about the `ntfs-3g` command. Now, this valuable command can mount the `ntfs` partition with standard GNU/Linux permissions. The only caveat is the need for root permissions:

# create a directory to mount the partition on:
$ sudo mkdir /mnt/windows
# mount the desired partition, replace it with `sda3` below:
$ sudo ntfs-3g -o permissions /dev/sda3 /mnt/windows
# create a test file in the mounted drive:
$ echo "I will give you my life m'Lord" > /mnt/windows/testfile
# check permissions:
$ ls -l /mnt/windows/testfile
-rwxrwxrwx 1 root root 18 Apr 21 11:53 testfile
# now, change the `testfile` permissions. Note that we need to
# have root permissions or it will complain:
$ sudo chmod -x testfile
# check again:
$ ls -l /mnt/windows/testfile
-rw-rw-rw- 1 root root 18 Apr 21 11:53 testfile

Voila!

Even though it is not recommended, the user can actually build `maneage` on an NTFS partition. But s/he has to be pretty careful with whatever s/he is doing.

Maybe this too can be added as a `Known issue` as discussed on task 15642.

Cheers!

Pedram Ashofteh-Ardakani <pedram>
Group Member
Sun 26 Apr 2020 07:02:46 PM UTC, comment #33: 

I am happy you are enjoying it :-).

Let me just clarify the point about the return value: what you read from somewhere about return 0 and 1 is correct. It is exactly what I am suggesting here: the function is a boolean function (with only two return values). So the values should indeed be interpreted as true or false.

In effect the job of this function is to set a true/false value for this statement: "The given directory is in a partition that allows modifying permission flags".

Mohammad Akhlaghi <makhlaghi>
Group administrator
Sun 26 Apr 2020 09:09:36 AM UTC, comment #32: 

It feels great working this way. Learning all the time, tackling new problems, positive atmosphere! Thanks for making this happen :-)

Yay! It does feel good to be a part of this. Great job in keeping the history neat, nice and tidy! Cheers :-D.

> Then you can delete your old branch if you want [...] (comment #30)

I guess the branch has fulfilled its purpose. So, I deleted it. Also, I will add branches with new names from now on to keep the commits and changes `atomic` and manageable. Thanks for providing the code snippets! They will be useful - now, and in the future - if this thread gets to live a long, healthy, and social life ;-).

> I like the quote you put in the `junkfile'! True hacking culture :-D! (comment #30)

Glad you noticed it :-D So indeed, its life will not go to waste ;-).

> No line should end with a white-space character! [...] (comment #30)

Thanks for pointing this out! Actually, vim did manage to remove the trailing spaces, wrap the commits at 72 characters, the title at 50, etc.. But I broke its conventions while tinkering with the configuration files :-D. That happy-face lives in the previous sentence because your comment actually sparked off a bit of searching for vim configuration files. The result: Came up with a pretty neat vim configuration file on GitHub repo by amix :-D. It takes care of the trailing white spaces too ;-)

> [...] no line should be longer than 75~80 characters [...] (comment #30)

So that's not just a git convention. OK, I'll stick to it!

> [...] I added a test before calling this function [...] (comment #30)

Great!

> [...] if you specify anything other than `1' the reader of your  code will wonder why you chose it [...] (comment #30)

I read somewhere that returning `0` and `1` could lead up to the misinterpreting them with `true` and `false` - from other programming languages. Using `255` instead of `1` acts just as a reminder. There's no need to do that here though. No problem.

> [...] follow this convention in your commit messages [...] (comment #30)

Sure! this post actually helped me a lot. Thanks for letting me know about the conventions!

> [...] renamed the title of this issue to checking for available space [...] (comment #31)

Cool! I'll keep everything you said in mind for this one. I appreciate your time and consideration.

Pedram Ashofteh-Ardakani <pedram>
Group Member
Sun 26 Apr 2020 02:04:17 AM UTC, comment #31: 

By the way, I just renamed the title of this issue to checking for available space, since that also came up.

After you can implement that, we'll close this task ;-). But of course, there is no rush ;-).

Mohammad Akhlaghi <makhlaghi>
Group administrator
Sun 26 Apr 2020 02:02:27 AM UTC, comment #30: 

Great! It has been merged and pushed to the `maneage' branch :-D.

You will just notice that all your work is now in one commit, and that it is no longer after the `7d26642', but after `d73a262'. This is because I rebased your branch over the `maneage' branch and "squashed" all the commits into one during the rebase. I also re-wrote the commit message to be more clear. But of course, you are still the commit author ;-).

This is done because Maneage is a special project: everyone will be pulling the `maneage' branch into their projects, so any branches in the `maneage' branch will also go into all the other derived projects. Also, we don't want to confuse the users with small bugs we found while testing the feature, we want every commit to be ONLY ONE change that project authors can easily understand: it will be really confusing for a biologist using Maneage for example, if they see one commit saying I started the work, then the next comming saying that I forgot about `set -e' and so on!They will get confused ;-).

I also made some small modifications to the code and described them below. But if you like, you can see the changes after pulling the updated `maneage' branch:


git checkout maneage
git pull
git diff ped-ntfs...maneage reproduce/software/shell/configure.sh


Then you can delete your old branch if you want, Please let me know here when you do that so I also remove your remote branch reference from my local repository.


git branch -D ped-ntfs
git push --delete ped-ntfs YOUR-REMOTE-NAME


Here is an explanation of my changes.

  • I like the quote you put in the `junkfile'! True hacking culture :-D!


  • No line should end with a white-space character! This is generally a convention in all programming source, it is so well-regarded that even Git shows it to you: after you make a commit run `git log -p' to see the lines you changed. You will see some lines ending in different patches of red. If you go and have a look in a text editor, you will see that these are white-space characters at the end of the line! If you follow this convention of running `git log -p' after your commit, you will notice before you push. You can then correct them and run `git commit --amend' to correct your commit. Generally, if you use a professional text editor (like GNU Emacs), it has modes that will automatically remove such white-space characters before saving the file. I have activated this mode and so my code never has this problem :-D. I strongly recommend moving to one, I recommend GNU Emacs, but to avoid falling into the editor wars, let me say that Vim is also a respected solution (that I don't use ;-)!).


  • Generally, no line should be longer than 75~80 characters, unless there is absolutly no way to avoid it ;-). This is another very important convention in coding that many software projects adhere to. having short lines helps in readability. This is applicable to code, comments, and anything generally!


  • There is no need to tell the user anything beyond "Build directory set to ..." ;-). If things are fine, don't confuse the user with too many messages ;-). So I removed the "Specified build directory handles permissions perfectly."


  • You hadn't put a comment for the first block of commands in the function.


  • I noticed that if there is a problem before this test, then `bdir' will be empty and the `junkfile' within the function will expand to `/check_permission_tmp_file' (under the root directory!). So I added a test before calling this function and made sure that `bdir' is actually defined ;-).


  • When you don't want to use the returned value and just want to crash out, return with a `1'. Any non-zero number is fine, so if you specify anything other than `1' the reader of your code will wonder why you chose it! Maybe its a bug (you intended to return something else, but forgot)?


  • Generally, its helps to follow this convention in your commit messages: start the commit body (after the title) with "Until now ..." and describe the problem as clearly as possible. Then in a second paragraph start with "With this commit ..." and describe your solution. Especially in something like Maneage (where many people will be updating their projects with your commit), you want to make everything as clear as possible, so they don't have to go looking in the code. Also, *if the commit affects their project in any way* (that is not the case here), explain it


Mohammad Akhlaghi <makhlaghi>
Group administrator
Fri 24 Apr 2020 09:36:04 AM UTC, comment #29: 

Oops, just a fix. Nothing fatal.

Pedram Ashofteh-Ardakani <pedram>
Group Member
Fri 24 Apr 2020 09:13:39 AM UTC, comment #28: 

At last, it works! Thanks for the tip:

> `exit 1` (comment #26)

I found out that using the `set -e` at the beginning of the code was the reason behind stopping the whole script when `check_perm ()` returned a non-zero value. Actually, using the `set -e` is a great convention to keep and I'm glad you did it :thumbs-up:.

> [...] 5 empty lines before and after every group of codes (comment #27)

Roger that!

So, I changed the way the function was implemented in the `if` conditional. Now it works perfectly. You might want to revise the prompt sentences to fit in just like other prompts.

I checked it on both NTFS and ext4 partitions, and the script behaves as expected :-D. I guess it's time to check it on macOS :-)


Pedram Ashofteh-Ardakani <pedram>
Group Member
Fri 24 Apr 2020 03:34:01 AM UTC, comment #27: 

Another small note: as you may have noticed, all Maneage source files (in any language) follow this convention: there are 5 empty lines before and after every group of codes.

So make sure that there are 5 empty lines before and after your new `check_perm ()' function (including its comments), like all the other parts of `configure.sh' ;-).

Mohammad Akhlaghi <makhlaghi>
Group administrator
Thu 23 Apr 2020 10:52:23 PM UTC, comment #26: 

Great! It looks much better now. But before looking into it with more detail, I need to know if you actually tested it in Maneage?

You can use one simple debugging trick to test your new function in Maneage: put the following two lines just after the `if' structure that tests the build directory in configure.sh:


echo; echo "GOT HERE"; echo
exit 1


You can now be sure that the `configure.sh' script (and thus the `./project' script) will not go any farther than checking the build directory. When it works as expected (in a good and bad partition), then remove these two lines and commit your change ;-).

This is the expected behavior: if the directory is not POSIX-compatible, it should warn the user and ask for the build directory again, until the directory is in a proper partition.

Please try this out and let us know after you have actually tested it in multiple scenarios ;-).

Mohammad Akhlaghi <makhlaghi>
Group administrator
Thu 23 Apr 2020 01:14:55 PM UTC, comment #25: 


> did you try running/testing it within Maneage ... ? (comment #24)

Frankly, I didn't dare to do so :-D But as soon as I get more familiar with it, sure thing!

Thanks for providing tutorial links once again! I found some good ones also:

> [...] by giving the build directory once in a bad place and once in a good place? (comment #24)

Yes, partially. I ran the script on both NTFS and ext4 filesystems and it works as expected. But did not try it within Maneage unfortunately.

> I know there are a lot of new things now, so I understand how you may have forgot that point, no problem ;-) (comment #24)

Thank you for your kind words and encouragement :-). Well, I'm a seasoned beginner :-D since I've tried to learn many, many things, and that helps with getting out of the comfort zone with a bit more confidence). Thank you for your patience. It may take just a while to start off, but when it's on, it's on!

> I recommend defining this test as a shell function. (comment #24)

Sure! Thanks for providing examples! Here's the updated version.

Pedram Ashofteh-Ardakani <pedram>
Group Member
Wed 22 Apr 2020 09:45:27 PM UTC, comment #24: 

I am happy to see that you are enjoying it, this is the whole purpose of free software :-D.

I like all the great comments you have added to it and how you have generalized it. But just one question, did you try running/testing it within Maneage ;-)? For example by giving the build directory once in a bad place and once in a good place?

The thing is that you have put a shell script directly in a Makefile (`basic.mk')! Maneage will not operate with this, it should crash with Make complaining about the syntax.

This test should be added in reproduce/software/shell/configure.sh, which is a shell-script.  Please see the last few paragraphs of Comment #19 again, hopefully that will point you in the right direction ;-). I know there are a lot of new things now, so I understand how you may have forgot that point, no problem ;-).

Once you look through `configure.sh' and find where to put it, I recommend defining this test as a shell function. There are already a few functions like create_file_with_notice or absolute_dir to learn from ;-).

Mohammad Akhlaghi <makhlaghi>
Group administrator
Wed 22 Apr 2020 09:22:29 PM UTC, comment #23: 

comment #22

> don't forget what Master Foo said in his 10000 lines story ;-).


>> “And who better understands the Unix-nature?” Master Foo asked.
>> “Is it he who writes the ten thousand lines, or he who, perceiving the emptiness of the task, gains merit by not coding?”
>> Upon hearing this, the programmer was enlightened.


It sure is fun working with you! Thanks for the tips!
Yes, you're right. I got lost in getting the most details out of the situation, instead of just focusing on the execution permission problem one might face. Maybe I'll develop something easier and post it on the issue opened on Perl's GitHub page.

About the code snippet you shared, it's great! The logic is quite minimal and effective! And it works perfectly for both cases where the file is or is not executable by default :thumbs-up:.

Yeah, actually I used the `$ ls -l` command at first, but got into the octal representations, one thing let to another and I found myself checking for all possible combinations of file permissions :-D.

> So you know Perl?

I'm afraid not much yet :palm-face:. But here's a quite nice place to start learning Perl. Actually I found the documentation so simple, clear, and attractive that I thought something similar could be implemented on the Maneage website. Right?

comment #21
Thank you for the informative links! I'll go through them gladly.

hours pass by and then:

Hi again! OK, here is the commit. I didn't do a merge request to the master because as you said before that may complicate stuff. So, here you can find the link to that commit. Do you find it useful?

BTW, I'll work on the free space available idea soon. Thank you for your patience and kind mentorship!

Cheers.

Pedram Ashofteh-Ardakani <pedram>
Group Member
Tue 21 Apr 2020 09:28:23 PM UTC, comment #22: 

Now, lets get to the permission checking:

WOW! So you know Perl? I haven't had the chance to learn Perl yet ;-)! But generally, don't forget what Master Foo said in his 10000 lines story ;-).

Also, for the configure script (where we haven't actually started building our own software), you shouldn't use Perl: its not available on some systems.

It is interesting that you used `stat' call. Why didn't you just use `ls -l'? that also prints the permission flags ;-). Like this small script I just wrote (the comments are longer than the actual code!). In short you don't need to break up the permissions script, the mere fact that it remains unchanged is enough to detect the problem ;-).


# Set the name
bdir=./
checkname=$bdir/posix-partition-check.txt
rm -f $checkname
echo "test" > $checkname

# By default, its not executable, so we should make executable and
# read the permissions.
chmod +x $checkname
perm_before=$(ls -l $checkname | awk '{print $1}')

# Now we'll remove the executable flags and read the permissions
# again.
chmod -x $checkname
perm_after=$(ls -l $checkname | awk '{print $1}')

# If the permissions are equal, the filesystem doesn't allow
# permissions.
if [ $perm_before = x$perm_after ]; then
    echo "'$bdir' isn't POSIX-compatible"
else
    echo "'$bdir' can be used."
fi
rm $checkname


Mohammad Akhlaghi <makhlaghi>
Group administrator
Tue 21 Apr 2020 06:43:41 PM UTC, comment #21: 

Let me devote the first comment to a small note about the collaboration workflow for Maneage itself. For a nice review of the various collaboration workflows with Git, see Chapter 5 of the ProGit book ;-).

The Maneage project is different from the Maneage paper because the Maneage paper is currently a private project (it will be made public after the paper is published). Also by its nature, the paper is a small personal project. So we don't expect people to clone and want to collaborate generally with it (especially after publication). Because of this, it was OK to have people directly push branches to it and we followed that more simple workflow.

However, Maneage it not like that: its already public, and many people will be cloning it to start their projects. Therefore having extra "topic" branches on the main project's repository will only clutter the repositories of everyone that uses it and is not good. So the workflow for Maneage itself is different, its very similar to Gnuastro's, where I have written a full Forking tutorial. If you have a look there, you'll see what you should do, just change the repository name and URLs ;-).

Mohammad Akhlaghi <makhlaghi>
Group administrator
Tue 21 Apr 2020 11:17:57 AM UTC, comment #20: 

comment #19

> the second (`echo $?') was non-zero, Right?

Unfortunately no, here is what I did:

$ echo "Let's create a test.txt file here" > test.txt
$ stat test.txt
  File: test.txt
  Size: 34              Blocks: 1          IO Block: 4096   regular file
Device: 803h/2051d      Inode: 98578       Links: 1
Access: (0777/-rwxrwxrwx)  Uid: ( 1000/  pedram)   Gid: ( 1001/  pedram)
Access: 2020-04-21 11:34:24.505997800 +0430
Modify: 2020-04-21 11:34:24.506445700 +0430
Change: 2020-04-21 11:34:24.506445700 +0430
 Birth: -
$ df -TP test.txt
Filesystem     Type    1024-blocks      Used Available Capacity Mounted on
/dev/sda3      fuseblk   204799996 192161036  12638960      94% /media/pedram/dataStorage
$ chmod -x test.txt
$ echo $?
0
$ stat test.txt
  File: test.txt
  Size: 34              Blocks: 1          IO Block: 4096   regular file
Device: 803h/2051d      Inode: 98578       Links: 1
Access: (0777/-rwxrwxrwx)  Uid: ( 1000/  pedram)   Gid: ( 1001/  pedram)
Access: 2020-04-21 11:34:24.505997800 +0430
Modify: 2020-04-21 11:34:24.506445700 +0430
Change: 2020-04-21 11:34:24.506445700 +0430
 Birth: -
$ sudo chmod -x test.txt
$ echo $?
0
$ stat test.txt
  File: test.txt
  Size: 34              Blocks: 1          IO Block: 4096   regular file
Device: 803h/2051d      Inode: 98578       Links: 1
Access: (0777/-rwxrwxrwx)  Uid: ( 1000/  pedram)   Gid: ( 1001/  pedram)
Access: 2020-04-21 11:34:24.505997800 +0430
Modify: 2020-04-21 11:34:24.506445700 +0430
Change: 2020-04-21 11:34:24.506445700 +0430
 Birth: -

But I have an idea. Maybe we could deliberately make a test file, run `$ chmod +x testfile' on it, check its `$ stat testfile', then do various other `chmod' commands on it and check if the `stat' actually changes as it should! If not, we'd know that something's wrong. Maybe something like this:

ibidir=$(pwd)
testfile=$ibidir/chmod-test.txt
chmodlog=$ibidir/chmod-log.txt
echo "Testing for chmod permissions" > $testfile
checkperm () {
        echo $(perl -e'printf "%o\n",(stat shift)[2] & 07777' $testfile)
}
for i_u in {0..7} # i_u: represents octal `user' permission
do
        for i_g in {0..7} # i_g: represents octal `group' permission
        do
                for i_o in {0..7} # i_o: represents octal `other' permission
                do
                        perm=$i_u$i_g$i_o
                        chmod $perm $testfile
                        if [ $perm -eq $(checkperm) ]
                        then
                                echo "Setting permission $perm ... result $(checkperm) ... OK" >> $chmodlog
                        else
                                echo "Setting permission $perm ... result $(checkperm) ... *** NOT OK  ***" >> $chmodlog
                        fi
                done
        done
done

This works in bash, and it doesn't need `sudo` for checking all these permissions. Does this syntax work in the makefile too? I cloned and created the `ped-ntfs' branch. I don't know if this works correctly in the makefile too. Actually, I made some changes to the basic.mk file but I do not have the permission to push the branch I made to the project. Should I fork the project and ask for a merge request?

BTW, I'll make another script to check for the octal file permission if using `Perl' is not a good idea in the configuration stage.

> [...] generally most virtual consoles (in a graphic user interface) have a "Select All" [...]

Unfortunately `Qt version 5.12.2.' doesn't have such a feature. I guess it's better to catch all the output before running the command then :-D.

Pedram Ashofteh-Ardakani <pedram>
Group Member
Mon 20 Apr 2020 07:13:46 PM UTC, comment #19: 

Just to confirm, you ran the commands I gave but the first one didn't work, and the output of the second (`echo $?') was non-zero. Right?

If so, then Great! So now you know what to check ;-)!

You can now easily put this into a shell `if' conditional to see if the given build directory is POSIX-compatible or not, something like this (assuming the given directory is in the variable `bdir'):


ppcname=$bdir/posix-partition-check.txt
rm -f $ppcname
echo "junk" > $ppcname
if chmod -x $ppcname; then
  echo "good"
else
  echo "bad"
fi


Try it by setting different values for `bdir' in a POSIX compatiable and non-compatible directory and see if it does indeed work ;-).

You have to add this test (with proper actions if its good or bad) in the configuration step where we check the user's given build-directory. The main configuration script is stored here: `reproduce/software/shell/configure.sh'. Go through this file and look at all the parts. They are very well commented (hopefully!), so you should be able to understand what is going on, even if you are not too fluent in shell.

This particular test should be put after we test if the build directory is writable (because you need to write a test file!).

Just note that you need to do this in the main Maneage project, not this paper, so clone the core Maneage project, make a development branch and do the work there ;-). Then push it to a repository of your own and let me know so I look at it ;-). This is the main Maneage project page: https://gitlab.com/maneage/project

About the GCC problem, if you reached LaTeX, then indeed it was successfully built. You don't need to send the log. But generally most virtual consoles (in a graphic user interface) have a "Select All" that you can use in such cases ;-).

Mohammad Akhlaghi <makhlaghi>
Group administrator
Mon 20 Apr 2020 05:51:30 PM UTC, comment #18: 

Wow. I can't change permissions. That's nothing new as described in an ask ubuntu question 9 years ago.

The user should mount the NTFS partition in some special way and set mappings. BUT Windows messes everything up as soon as the user interacts with the same file while logged in on Windows.

So, it depends on how tech-savvy the user is. In other words, NTFS, user-friendly NOT :-D.

comment #17

> Just don't use `tee' [...]

Well, the terminal kept a history of 1000 lines, I changed it to unlimited from the preferences and did as you said. The computer kept working and producing outputs on screen for more than 90 minutes. The good news is, it worked! I don't know why, looks like everything is installed but the LaTeX part for a lack of internet connection on that point of time.

However, I couldn't copy the huge output. Tried many things. Using the `/dev/vcsX` files [didn't work], `screendump N` command [didn't work], and I could not manage to select all the output with my mouse :-D. I was holding the left click for a while but it seemed like it was going to take forever.

I tried to find other workarounds but no luck. Forums and Q&A websites kept talking about using a command before execution to get the output, not after that. To be short, the output is lost. But anyway, the last output said everything is ok - but the LaTeX.

So, I guess this bug is not reproducible since I didn't change anything before running this command again.

Just one thing. I installed `zram` because the Linux froze from time to time (too many browser tabs open at the same time, combined with other RAM thirsty programs).

Pedram Ashofteh-Ardakani <pedram>
Group Member
Fri 17 Apr 2020 07:24:19 PM UTC, comment #17: 

The fact that the created file already has an `x' flag is interesting! Probably that's the problem! Then make a file like before, but try removing the executable flag like below, does it work?


chmod -x test.txt
echo $?


The last part (`echo $?') prints the returned value of the `chmod' command. If this is non-zero, then we can use this as a check ;-).

About the `.local' directory: this is a symbolic link in the project's source directory, not the build directory. Sorry that I didn't clarify ;-).

OK, so the fact that you don't have a `gcc' file under the `proglib' directory means that GCC wasn't installed successfully. Can you please run `./project configure -e' again and send the full outputs as a `.txt.gz' file like before? Just don't use `tee' this time, when it finishes, manually copy all the terminal output into a text file. Maybe the problem of not seeing any error messages is with `tee'!?!

Mohammad Akhlaghi <makhlaghi>
Group administrator
Fri 17 Apr 2020 06:00:56 AM UTC, comment #16: 

Hi Mohammad! Thanks for your response.

> [...] strictly POSIX compliant [...]


Oh, good point. I'll search through a list of standard POSIX compliant commands then ;-)

> it's better to simply check the problematic command


Yes! That's a great idea! Just check if the command returns an error! Simple, yet effective :-) I'll try to find the problematic command through reading more about the failed tests on my NTFS partition.

> `$ echo "test file" > test.txt`
> `$ chmod +x test.txt`
> `$ rm test.txt`


Hmm, it's strange. There is no problem. It's worth mentioning that I have been using my NTFS partition from Linux for about 4 years. And there was no problem with running Linux commands inside that partition. Well, I didn't test `rocket science` commands on it of course. But it's pretty OK with all the normal commands. As a matter of fact, I can see that the new `test.txt` file has the `x` executable attribute by default!


# mount the NTFS partition without root privileges
$ df -Tp test
$ udisksctl mount -b /dev/sda3
$ ll test.txt
-rwxrwxrwx 1 pedram pedram 10 Apr 17 09:48 test.txt*
$ df -TP test.txt
Filesystem     Type    1024-blocks      Used Available Capacity Mounted on
/dev/sda3      fuseblk   204799996 192097924  12702072      94% /media/pedram/mount-name
$ rm test.txt
# no errors, it just works


> I like the available space test!


I'm glad you liked the idea! OK, I'll definitely keep the POSIX compatibility in mind :-D

> can you see if this file exists: `.local/version-info/proglib/gcc'?


No sign of the `.local` folder in the build directory :-( I found out a `version-info` directory though, but there's no sign of `gcc`. Here's the content:


$ ls -alh /home/.../maneage-build/software/installed/version-info/proglib/
total 164K
drwxrwxr-x 2 pedram pedram 4.0K Apr 12 13:02 .
drwxrwxr-x 6 pedram pedram 4.0K Apr 12 12:29 ..
-rw-rw-r-- 1 pedram pedram   16 Apr 12 12:36 bash
-rw-rw-r-- 1 pedram pedram   18 Apr 12 13:02 binutils
-rw-rw-r-- 1 pedram pedram   12 Apr 12 12:30 bzip2
-rw-rw-r-- 1 pedram pedram   19 Apr 12 12:43 coreutils
-rw-rw-r-- 1 pedram pedram   12 Apr 12 12:47 curl
-rw-rw-r-- 1 pedram pedram   18 Apr 12 12:46 diffutils
-rw-rw-r-- 1 pedram pedram   10 Apr 12 12:43 file
-rw-rw-r-- 1 pedram pedram   20 Apr 12 12:47 findutils
-rw-rw-r-- 1 pedram pedram   21 Apr 12 12:29 flock
-rw-rw-r-- 1 pedram pedram   14 Apr 12 12:59 gawk
-rw-rw-r-- 1 pedram pedram   11 Apr 12 12:52 git
-rw-rw-r-- 1 pedram pedram   18 Apr 12 12:47 glibtool
-rw-rw-r-- 1 pedram pedram   48 Apr 12 12:53 gmp
-rw-rw-r-- 1 pedram pedram   13 Apr 12 12:44 grep
-rw-rw-r-- 1 pedram pedram   14 Apr 12 12:31 gzip
-rw-rw-r-- 1 pedram pedram   29 Apr 12 12:56 isl
-rw-rw-r-- 1 pedram pedram   13 Apr 12 12:44 libbsd
-rw-rw-r-- 1 pedram pedram   18 Apr 12 12:46 libiconv
-rw-rw-r-- 1 pedram pedram    0 Apr 12 12:29 low-level-links
-rw-rw-r-- 1 pedram pedram   10 Apr 12 12:30 lzip
-rw-rw-r-- 1 pedram pedram   14 Apr 12 12:47 m4
-rw-rw-r-- 1 pedram pedram   13 Apr 12 12:32 make
-rw-rw-r-- 1 pedram pedram   36 Apr 12 12:59 metastore
-rw-rw-r-- 1 pedram pedram   39 Apr 12 12:59 mpc
-rw-rw-r-- 1 pedram pedram   53 Apr 12 12:58 mpfr
-rw-rw-r-- 1 pedram pedram   16 Apr 12 12:35 ncurses
-rw-rw-r-- 1 pedram pedram   15 Apr 12 12:37 openssl
-rw-rw-r-- 1 pedram pedram   14 Apr 12 12:33 patchelf
-rw-rw-r-- 1 pedram pedram   12 Apr 12 12:40 perl
-rw-rw-r-- 1 pedram pedram   18 Apr 12 12:45 pkg-config
-rw-rw-r-- 1 pedram pedram   17 Apr 12 12:35 readline
-rw-rw-r-- 1 pedram pedram   12 Apr 12 12:44 sed
-rw-rw-r-- 1 pedram pedram   13 Apr 12 12:32 tar
-rw-rw-r-- 1 pedram pedram   16 Apr 12 12:42 texinfo
-rw-rw-r-- 1 pedram pedram   10 Apr 12 12:31 unzip
-rw-rw-r-- 1 pedram pedram   16 Apr 12 12:48 wget
-rw-rw-r-- 1 pedram pedram   15 Apr 12 12:43 which
-rw-rw-r-- 1 pedram pedram   15 Apr 12 12:31 xz
-rw-rw-r-- 1 pedram pedram    8 Apr 12 12:30 zip
-rw-rw-r-- 1 pedram pedram   12 Apr 12 12:31 zlib

(BTW, shouldn't these have execution permissions?)

However, I looked for `gcc` everywhere inside the build directory, and found these 3 instances:


$ find . -iname "gcc"
./software/build-tmp-gcc/gcc-9.2.0/gcc
./software/build-tmp-gcc/gcc-9.2.0/libphobos/libdruntime/gcc
./software/build-tmp-gcc/gcc-9.2.0/build/gcc


Pedram Ashofteh-Ardakani <pedram>
Group Member
Thu 16 Apr 2020 02:30:39 AM UTC, comment #15: 

Thanks a lot Pedram.

One important thing we should have in mind regarding the initial configuration script is that it should be strictly POSIX Compliant, in other words, it should be very portable (runnable on any system). This is because this script is run before we start building programs that we can later trust.

For example, when I had a look at the "Open Group's" specification  for `df', I noticed that it doesn't have a `-T' option.

Based on my experience, its better to simply check the problematic command ;-). For example on your NTFS partition (when it is not loaded with POSIX compatibility), can you run this command (with what ever `chmod' call was problematic for Perl):


echo "test file" > test.txt
chmod +x test.txt
rm test.txt


If this fails on the NTFS directory, this is the perfect test :-)! Do you know the exact problematic `chmod' call in Perl? It would be good to use the same call.

I like the available space test! but again, I think its best to make sure it is fully POSIX compliant, or find a very portable solution. Here, Raul has a macOS and maybe he can try it out ;-).

Thanks also for the GCC output, it is very strange! I don't see any error in the whole file: it has left the GCC build directory successfully! But it is surprisingly short (GCC takes almost one hour of constant printing of outputs!). In the top project directory, can you see if this file exists: `.local/version-info/proglib/gcc'? I just want to see if GCC has been successfully built or not.

Mohammad Akhlaghi <makhlaghi>
Group administrator
Mon 13 Apr 2020 07:22:02 AM UTC, comment #14: 

I hope so! After a bit of searching - not googling ;-) - I found out that actually NTFS is POSIX compatible, but the user needs to mount it with special permissions. It looks like that requiring root privileges kind of defeats the purpose. But, it may be the last resort for someone that doesn't have enough memory available anywhere else - which again, Maneage should warn the user if that's the case.

Thanks for providing these opportunities :-) Does this work?

# ubd: user's build directory
ubd=$(pwd)
# sftype: system file type
sftype=$(df -TP $ubd| awk 'FNR==2 {print $2}')
# system file type check command
if [ "$sftype" = "fuseblk" ]; then
        printf  '%s\n'\
                " -- The '$ubd'"\
                " -- Directory is inside a '$sftype' file system."
else
        printf  '%s\n'\
                " -- The '$ubd'"
                " -- Directory is inside a '$sftype' file system."
fi;
# amem: available memory
# amemh: human readable available memory
amem=$(df -TP $ubd | awk 'FNR==2 {print $5}')
amemh=$(df -ThP $ubd | awk 'FNR==2 {print $5}')
# available memory check command
if [ $amem -lt 5000000 ]; then
        printf  '%s\n'\
                " ## == WARNING! == ## "\
                " ## Available space: $amemh"\
                " ## It's recommended to have more than 5GB free space"\
                " ## available for the build to run properly."
else
        printf  '%s\n'\
                " -- Available space: $amemh"
fi;


I attached the full terminal output as bug-gcc.txt.gz. Is it normal to see some actual code in here? Should they print inside the terminal?



(file #48825)

Pedram Ashofteh-Ardakani <pedram>
Group Member
Sun 12 Apr 2020 02:15:45 PM UTC, comment #13: 

Great! That was a VERY INTERESTING situation! I am sure the Perl authors will add a test for this later.

In Maneage, we should add a test for this kind of situation and avoid more complicated situations later (because especially in its multi-user mode, Maneage needs POSIX permissions). Now that you have an NTFS partition, can you find a good command that will help us identify if a given directory is NTFS or not? We can then put this check right at the start of the configure script and if the user gives an NTFS partition as a build directory, we can notify them of potential problems and ask them for POSIX-permissions-compatible partition.

If you can post the check command here, I'll tell you where to put it in the source of Maneage and you can make your first commit in the source of Maneage ;-).

About the GCC error, we need a few more lines above the ones quoted. The lines you quoted are the Make notifications, telling us where in the process the build failed, but it doesn't contain the actual error line(s). Can you run `./project configure -e' again and send us the full terminal output (in a `.txt.gz' file)? Ideally the last 500 lines or so should be enough, but this will be more complete.

Mohammad Akhlaghi <makhlaghi>
Group administrator
Sun 12 Apr 2020 09:03:06 AM UTC, comment #12: 

... OK. So, the problem with Perl arose because /my/build/dir was located in an NTFS partition, which couldn't handle chmod permissions quite well. Thus, I saved up some space on my ext4 home directory - by `rm -r anaconda3` :-( - and relocated the Maneage build directory there. I let the tarballs stay put where they were before, and used the optional address that `./project config` suggests.

All went well for about 45 minutes, but, we have another problem:

make[4]: Target 'all' not remade because of errors.
rm gcc.pod
make[4]: Leaving directory '/my/build/dirsoftware/build-tmp-gcc/gcc-9.2.0/build/gcc'
make[3]: *** [Makefile:4667: all-stage1-gcc] Error 2
make[3]: Target 'all-stage1' not remade because of errors.
make[3]: Leaving directory '/my/build/dirsoftware/build-tmp-gcc/gcc-9.2.0/build'
make[2]: *** [Makefile:24054: stage1-bubble] Error 2
make[2]: Target 'stage3-bubble' not remade because of errors.
make[2]: Leaving directory '/my/build/dirsoftware/build-tmp-gcc/gcc-9.2.0/build'
make[1]: *** [Makefile:994: all] Error 2
make[1]: Leaving directory '/my/build/dirsoftware/build-tmp-gcc/gcc-9.2.0/build'
make: *** [reproduce/software/make/basic.mk:1279: /my/build/dirsoftware/installed/version-info/proglib/gcc] Error 2
make: Target 'all' not remade because of errors.


So, shall I go and open up an issue in the gcc bug report forum :-D?

Pedram Ashofteh-Ardakani <pedram>
Group Member
Sat 11 Apr 2020 06:46:25 PM UTC, comment #11: 

Great! I see you have already got a reply :-). I hope the problem can be found soon ;-).

Mohammad Akhlaghi <makhlaghi>
Group administrator
Sat 11 Apr 2020 11:03:50 AM UTC, comment #10: 

Yes, master Foo has quite nice answers to different scenarios. I did enjoy reading them, thanks to you and mentioning him in your comments.

I did open up a new issue on GitHub, here's the link if you're interested: https://github.com/Perl/perl5/issues/17712

Pedram Ashofteh-Ardakani <pedram>
Group Member
Thu 09 Apr 2020 02:16:51 PM UTC, comment #9: 

I am happy to see that you have enjoyed reading the rootless root! It is written with such creativity and clarity :-).

About the problem with Perl, I think we have found a way forward. The fact that the raw tarball doesn't install on your system (outside of Maneage) means that you can contact them and they should be able to help.

So can you please find the suggested help or bug mailing lists of Perl and contact them with this problem? Don't say anything about Maneage (to confuse them). Just say that you want to build Perl from source, but you can't because of this error.

Let us know how it goes ;-)...

Mohammad Akhlaghi <makhlaghi>
Group administrator
Thu 09 Apr 2020 06:23:52 AM UTC, comment #8: 

comment #6

> I was hoping that you would use this chance to look into the actual commands that are run in the recipe to build Perl, not just stop searching immediately after it and blindly disabling all threads ;-)!


Upon hearing this, the troubled user was enlighted.

Pedram Ashofteh-Ardakani <pedram>
Group Member
Thu 09 Apr 2020 06:20:37 AM UTC, comment #7: 

Hi Mohammad.

  • About `*line 677*`: Yes, you're right :-). I missed the word `*start*`. My bad. I tried to disable all threads to have an ordered output. Didn't mean to be blind about it #_- But thanks anyway. Reading code sure is a good way of learning - a bow to master Foo and his followers ;-).


  • About the `*sed*`: Gee! I'll have to check how the `|` is working because it eliminates the need to escape all the `/` before every and each directory entry! Thanks again!


  • About the `*gdb*`: Installed it, didn't work out, unfortunately.


  • About installing `*Perl*` in a separate temporary directory: Did it step by step. The same thing happens. It exits with an `*Error 22*`, *sigh*.


make: *** [makefile:448: install-all] Error 22


So, how can I help? I'll attach the outputs just in case.

(file #48790)

Pedram Ashofteh-Ardakani <pedram>
Group Member
Tue 07 Apr 2020 03:40:33 AM UTC, comment #6: 

Thanks Pedram, let me address the points one by one

  • About the `line 677' part: I had mentioned that this is the line of "Perl's build rule", not the precise line you should edit ;-)! After it I had given an address ("In the recipe (the commands that start after a TAB), close to the bottom, you have to change `$(numthreads)' to `1'"). I had also given a link, if you click on it, it will take you to the main Maneage source. In the link too, line 726 is the line that you should have edited ;-). I was hoping that you would use this chance to look into the actual commands that are run in the recipe to build Perl, not just stop searching immediately after it and blindly disabling all threads ;-)!


  • You are right about the problem with sed not changing everything! I had forgot a `g' at the end of the `sed' expression! I had also not considered the directories for temporary builds (on my system the tarballs are uncompressed and built in the RAM (`/dev/shm'), but apparently on your system this doesn't happen.


I went through the differences between the files and again couldn't see any error message! I don't see anything about a complaint! The only difference is a few libraries weren't found on your system, like dbmclose(), ndbm.h, gdbm/ndbm.h, db.h, bfd.h and gdbm.h. They all look like debugging libraries: GNU's debugger is called `GDB'.

Just to throw a stone in the dark, can you try installing the GNU debuuger, on Ubuntu, it should be with this command.


sudo apt install gdb


Then try re-configuring Maneage. If it works, that is great, because we have alrady packaged GDB in Maneage, it just needs to be set as a prerequisite of Perl.

But if it doesn't, can you just try building and installing Perl in a temporary directory outside of Maneage? If the problem also happens outside of Maneage, we can take it to the Perl developers more easier.

The tarball is already present on your system, so run these commands? Just change `/A/TEMPORARY/DIRECTORY' to some temporary directory on your system.


cp .build/software/tarballs/perl-5.30.0.tar.gz /A/TEMPORARY/DIRECTORY
cd /A/TEMPORARY/DIRECTORY
tar xf perl-5.30.0.tar.gz
mkdir temp_install
cd perl-5.30.0
idir=/A/TEMPORARY/DIRECTORY/temp_install
./Configure -des -Dusethreads -Duseshrplib -Dprefix=$idir -Dvendorprefix=$idir  -Dman1ext=1perl -Dman3ext=3perl -Dcccdlflags='-fPIC'
make
make install


Mohammad Akhlaghi <makhlaghi>
Group administrator
Mon 06 Apr 2020 06:59:25 AM UTC, comment #5: 

comment #3 and comment #4

:palm-face: Failed to attach. #_#

Sending the new log and makefile again ...

(file #48769)

Pedram Ashofteh-Ardakani <pedram>
Group Member
Mon 06 Apr 2020 06:55:14 AM UTC, comment #4: 

comment #3

Now it has happened for all of us. The screenshots weren't successfully attached. Also, something weird happened while compressing the previous log-and-makefile.tar.gz (file #48767) by right-clicking and selecting the compress button on my PCManFM-Qt file manager (version 0.14.1). Did it again using:


$ tar -czvf ped-screenshots.tar.gz *.jpg
$ tar -czvf ped-log-and-makefile.tar.gz log-ped-j1.txt bu_make.mk


Now sending the new versions ;-) (after waiting for a long time as a precaution! :-D ...)

(file #48768)

Pedram Ashofteh-Ardakani <pedram>
Group Member
Mon 06 Apr 2020 06:25:24 AM UTC, comment #3: 

comment #1
comment #2

Thanks for your response and for introducing `sed`!

So, looking for the command you asked, none of them were on line 677 unfortunately. Maybe this means we don't have the same `basic.mk` file, even though I cloned it from the gitlab repository. You can find my version of makefile in the attachments under the name bu_basik.mk.

Here's what I see:


$ cat basic.mk | grep '(numthreads)' -n
448:    $(call gbuild, tar-$(tar-version), , , -j$(numthreads) V=1) \
474:    $(call gbuild, make-$(make-version), , , -j$(numthreads)) \
496:                   --with-pkg-config=$(ildir)/pkgconfig, -j$(numthreads))
567:                   SHLIB_LIBS="-lncursesw" -j$(numthreads)) \
648:                       -j$(numthreads))
726:    && make SHELL=$(ibdir)/bash -j$(numthreads) \
775:    && make SHELL=$(ibdir)/bash -j$(numthreads) \
827:                   -j$(numthreads), , ./config ) \
1029:   && make SHELL=$(ibdir)/bash V=1 -j$(numthreads) \
1243:                    -j$(numthreads) ) \
1332:     && make SHELL=$(ibdir)/bash -j$(numthreads) \


Anyway, after checking them one by one, I found the one related to installing Perl on line 726. However, to keep the log human-readable, I disabled multithreading in the whole make file using the `sed` command you just taught me:


$ sed -e's|j$(numthreads)|j1|' backup_basic.mk > basic.mk


Then, moving to the paper directory and running the `./project configure -e | tee ./log.txt` again, `sed` was used to modify the output as you said. But I found out that some instances were not replaced! Also, it is the same case in the `full-good-j1.txt.gz` and `perl-test-good.txt` you sent here (the path to your build was NOT replaced as you expected in a some places). So I checked and used `sed` a bit differently (notice the escape character `\` and the addition of `g`):


$ sed -e's/PATH\/TO\/MY\/BUILD/build\/dir/g' log.txt > log-ped-j1.txt


Now, you can find the new log attached under the name `log-ped-j1.txt`.

Here are the system specs:


$ cat /etc/*-release
DISTRIB_ID=Ubuntu
DISTRIB_RELEASE=19.04
DISTRIB_CODENAME=disco
DISTRIB_DESCRIPTION="Ubuntu 19.04"
NAME="Ubuntu"
VERSION="19.04 (Disco Dingo)"
ID=ubuntu
ID_LIKE=debian
PRETTY_NAME="Ubuntu 19.04"
VERSION_ID="19.04"
HOME_URL="https://www.ubuntu.com/"
SUPPORT_URL="https://help.ubuntu.com/"
BUG_REPORT_URL="https://bugs.launchpad.net/ubuntu/"
PRIVACY_POLICY_URL="https://www.ubuntu.com/legal/terms-and-policies/privacy-policy"
VERSION_CODENAME=disco
UBUNTU_CODENAME=disco


Also, you can find some screenshots from Perl warnings that came up on the terminal attached under the names `ped-perl-xx.jpg`. I hope this helps with simplifying the problem.

P.S: Looks like Savannah should add a verbose upload progress bar to the file attachments section :-D

(file #48767)

Pedram Ashofteh-Ardakani <pedram>
Group Member
Sun 05 Apr 2020 11:17:27 AM UTC, comment #2: 

Sorry, I just noticed that the files of my previous comment weren't sent (I had checked with the "Preview" button before sending, but apparently that removed all the files I had selected for download)!

I am attaching them with this comment ;-).

(file #48763, file #48764, file #48765)

Mohammad Akhlaghi <makhlaghi>
Group administrator
Sun 05 Apr 2020 11:14:37 AM UTC, comment #1: 

Thanks a lot for the complete report ;-).

This is a very confusing situation! From the log you sent, I couldn't see any clear error messages! Only the final ones you reported (which are actually error messages produced by Make, not by Perl's installation routine!).

The Make errors show that the problem was in the `make install' command of Perl (in particular the first line you reported that says the error is in `install-all'). So apparently the build has been done with no errors, there is only an error in the installation.

The only way to attempt to debug it was to compare with a clean build of Perl on my own system. But the outputs were too crowded to get into the details, and we were both building on many threads (which make the log outputs hard to read).

So I started with the last set of commands, where it prints the names of the installed files. In the log-file, I renamed the build directory on both our systems to `/my/test/build/directory' and you can see the result in the two attached files: `perl-test-good.txt' is the installed files on my system and `perl-test-pedram.txt' are the files that were installed on your system.

If you download the files and do a diff on them, you will see that there are many differences, this is why I renamed both our build directories ;-): many Perl packages have not been installed in your system! In particular all of the ones under `lib/perl5/5.30/core_perl/auto/*'.

Because the build has gone on multiple threads the reset of the output is too mixed to be readable/comparable! Can you set Perl to be built on a single thread, then re-run the configure script and send the updated log?

To do this, you have to make a small modification in Perl's build rule, or instructions. They start at line 677 of reproduce/software/make/basic.mk. In the recipe (the commands that start after a TAB), close to the bottom, you have to change `$(numthreads)' to `1'. So this line


        && make SHELL=$(ibdir)/bash -j$(numthreads) \


is changed to


        && make SHELL=$(ibdir)/bash -j1 \


Then re-run the configure script while saving the log.

Afterwards, rename your build directory in the log to the same one I have set (just changing `/PATH/TO/YOUR/BUILD' in the command below):


$ sed -e's|/PATH/TO/YOUR/BUILD|/build/dir|' log.txt > log-good-j1.txt


I have already done this in the attached `full-good-j1.txt.gz' file.

We can then get a hint of the cause of this problem by inspecting the differences between the two (with a `diff' command).

Once you see the difference, it would be great if you could look around in the internet a little to see if the cause can be found. If not, post it here, and maybe we can contact the bug-reporting system of Perl....

Mohammad Akhlaghi <makhlaghi>
Group administrator
Sun 05 Apr 2020 06:13:43 AM UTC, original submission:  

After running `./project configure` there were some errors. Then after executing `./project make` I get the prompt: The configuration wasn't successful.

So I ran `./project configure -e` and saved the output to the attached file `maneage_paper_conf_log.tar.gz` since I didn't know if there were any log files present to send them your way (are there any?). Here are the last few lines:


make[1]: *** [makefile:448: install-all] Error 22
make[1]: Target 'install' not remade because of errors.
make[1]: Leaving directory '/media/pedram/dataStorage/Ped_Doc/Research/myProjects/tmp/software/build-tmp/perl-5.30.0'
make: *** [reproduce/software/make/basic.mk:689: /media/pedram/dataStorage/Ped_Doc/Research/myProjects/tmp/software/installed/version-info/proglib/perl] Error 2
make: Target 'all' not remade because of errors.


Can I get some help with this?

Thanks in advance.

Pedram Ashofteh-Ardakani <pedram>
Group Member

 

(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

Attach Files:
   
   
Comment:
   

Attached Files
file #48825:  bug-gcc.txt.gz added by pedram (46KiB - application/gzip)
file #48790:  perl-tee-logs.tar.gz added by pedram (290KiB - application/gzip)
file #48769:  ped-log-and-makefile.tar.gz added by pedram (44KiB - application/gzip - the new extractable file (solved the problem in extraction path))
file #48768:  ped-screenshots.tar.gz added by pedram (2MiB - application/gzip)
file #48767:  log-and-makefile.tar.gz added by pedram (43KiB - application/gzip)
file #48763:  perl-test-good.txt added by makhlaghi (72KiB - text/plain)
file #48764:  perl-test-pedram.txt added by makhlaghi (18KiB - text/plain)
file #48765:  full-good-j1.txt.gz added by makhlaghi (35KiB - application/gzip)
file #48757:  maneage_paper_conf_log.tar.gz added by pedram (30KiB - application/gzip)

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -email is unavailable- added by makhlaghi (Posted a comment)
  • -email is unavailable- added by pedram
  • -email is unavailable- added by pedram (Submitted the item)
  •  

    There are 0 votes so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.

    Only logged-in users can vote.

     

    Follow 15 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2020-06-25 makhlaghi StatusIn Progress Done
        Open/ClosedOpen Closed
    2020-04-26 makhlaghi StatusNone In Progress
        Assigned toNone pedram
        Summarymakefile:448: install-all (Error 22) Checking for available space in build directory
    2020-04-13 pedram Attached File- Added bug-gcc.txt.gz, #48825
    2020-04-09 pedram Attached File- Added perl-tee-logs.tar.gz, #48790
    2020-04-06 pedram Attached File- Added ped-log-and-makefile.tar.gz, #48769
    2020-04-06 pedram Attached File- Added ped-screenshots.tar.gz, #48768
    2020-04-06 pedram Attached File- Added log-and-makefile.tar.gz, #48767
    2020-04-05 makhlaghi Attached File- Added perl-test-good.txt, #48763
        Attached File- Added perl-test-pedram.txt, #48764
        Attached File- Added full-good-j1.txt.gz, #48765
    2020-04-05 pedram Attached File- Added maneage_paper_conf_log.tar.gz, #48757
        Carbon-Copy- Added -email is unavailable-

    Back to the top

    Powered by Savane 3.13-02a9.
    Corresponding source code