פורסם: 22/12/2014 - 14:57
נושא ההודעה: אריזת חבילה לדביאן
|
|
אני צריך עזרה לארוז חבילה לדביאן
יש לי קצת נסיון בזה, העלתי פעם חבילה למאגר אישי באובונטו, זה היה די מסובך, בסוף זה הצליח...
אם יש מישהו שמוכן לעזור לי קצת להעלות לדביאן, הקבצים שלי די מוכנים, בעיקר מה שאני צריך זה איך להסתדר עם האתר שלהם (הרבה אנגלית ודי הרבה מלל, ולא כל כך ידידותי .. מה שמאוד מסבך אותי)
ואיך להגיע למצב שהחבילה פחות או יותר תואמת את הדרישות שלהם.
אם יש מישהו שיכול לעזור לי (אפשר במייל או בכל דרך...) אני מאוד ישמח! תודה רבה.
|
|
|
| חזרה לתוכן הדיון |
פורסם: 22/12/2014 - 15:06
נושא ההודעה:
|
על איזו חבילה מדובר?
התיעוד הבסיסי:
https://www.debian.org/doc/devel-manuals#maint-guide
קריטריון בסיסי למוכנות החבילה: שלא יהיו בה שגיאות lintian. או לפחות לא שגיאות שאתה יכול לתת להן הסבר טוב.
ר' גם https://mentors.debian.net/
|
|
|
| חזרה לתוכן הדיון |
פורסם: 22/12/2014 - 15:41
נושא ההודעה:
|
ראיתי את זה כבר, וזה בדיוק מה שהתכוונתי, זה לא כל כך ידידותי.
אני מניח שמי שכבר התנסה בזה, זה נראה לו פחות מסובך. אבל אני שרוצה לארוז חבילה די פשוטה אפשר לומר, בלי סקריפטים לפני/אחרי התקנה או דברים מורכבים כאלה, זה המון אינפורמציה שמסבכת אותי.
יש שם כמה מצגות יותר ידידותיות אני יעבור עליהם. תודה רבה.
אני הולך להסתבך...... 
|
|
|
| חזרה לתוכן הדיון |
פורסם: 22/12/2014 - 15:57
נושא ההודעה:
|
|
אני מסכים איתך שהקישור לתיעוד הבסיסי קשה לקריאה. מאוד טכני ויבש.
יש גם יותר מדרך אחת ליצור חבילות של דביאן.
כדי לעזור לך, אני אשמח לדעת יותר על סוג המקור שאתה רוצה לארוז. האם זו תוכנית ב-C או ג'אווה או פייתון למשל? כמה מורכב הקוד.
בבקשה תן קצת יותר פרטים.
|
|
|
| חזרה לתוכן הדיון |
פורסם: 22/12/2014 - 18:21
נושא ההודעה:
|
| oz_nahum : | אני מסכים איתך שהקישור לתיעוד הבסיסי קשה לקריאה. מאוד טכני ויבש.
יש גם יותר מדרך אחת ליצור חבילות של דביאן.
כדי לעזור לך, אני אשמח לדעת יותר על סוג המקור שאתה רוצה לארוז. האם זו תוכנית ב-C או ג'אווה או פייתון למשל? כמה מורכב הקוד.
בבקשה תן קצת יותר פרטים. |
בבקשה
זה קוד ב c++ ב qt. הקוד לא מורכב מאוד. יש לי תלויות בספריות הבסיסיות של qt, לא משהו שנראה לי מעבר לזה.
|
|
|
| חזרה לתוכן הדיון |
פורסם: 22/12/2014 - 19:25
נושא ההודעה:
|
|
אתה משתמש בQTMAKE או CMAKE?
|
|
|
| חזרה לתוכן הדיון |
פורסם: 22/12/2014 - 19:41
נושא ההודעה:
|
| oz_nahum : | | אתה משתמש בQTMAKE או CMAKE? |
qmake
|
|
|
| חזרה לתוכן הדיון |
פורסם: 22/12/2014 - 20:51
נושא ההודעה:
|
|
|
|
|
| חזרה לתוכן הדיון |
פורסם: 22/12/2014 - 22:48
נושא ההודעה:
|
|
כתבת שכבר כמעט גמרת לארוז. לכן שאלתי על איזו חבילה מדובר. איפה אפשר למצוא את האריזה שלך (המקור. התוצרים לא חשובים לי כרגע).
|
|
|
| חזרה לתוכן הדיון |
פורסם: 23/12/2014 - 05:18
נושא ההודעה:
|
הקישור הראשון מההודעה של עוז אכן מועיל. הקישור הזה לא נראה לי רלוונטי וגם לא עדכני. למיטב זכרוני dh יסתדר עם qmake.
|
|
|
| חזרה לתוכן הדיון |
פורסם: 23/12/2014 - 08:26
נושא ההודעה:
|
כרגע עשיתי לפי הקישור השני. כמה התאמות קטנות (qt5)
וכרגע יש לי חבילה מוכנה התקנתי אותה והיא עובדת כמצופה ממנה
היו לי כמה הערות מ lintian דברים שניתן לסדר בטח...
עכשיו השלב הבא זה לפתוח באג ב wnpp ? ואז לסגור אותו ב changelog ?
צפריר: אם אני רוצה שהחבילה תהיה במאגרים של דביאן איפה הכי מומלץ להעלות את הקוד?
כי כרגע הוא נמצא במחשב שלי בלבד ....
עניין נוסף, אם אני עובד עם qt יש לי אפשרות להימנע מ2 חבילות אחת ל 64 ואחת ל32 ? (המערכת שלי של 64 אז זה מקמפל לי חבילה של 64 שלא תעבוד במערכת של 32 כנראה)
|
|
|
| חזרה לתוכן הדיון |
פורסם: 23/12/2014 - 11:39
נושא ההודעה:
|
כאמור, הקישור השני כולל הרבה הנחיות שגויות.
בעיקרון אתה צריך לפתוח באג מסוג ITP על החבילה wnpp (הכי פשוט: reportbug wnpp)ולסגור אותו ב־changelog. מצד שני אתה צריך למצוא בסופו של דבר מי שיעלה את החבילה.
האם אתה מתכוון להמשיך ולתחזק את החבילה או שאתה רוצה רק להעלות עכשיו?
רק מפתחי דביאן רשומים יכולים להעלות חבילות. יכול להיות שימצא מי שהחבילה תעניין אותו אישית (או את הצוות שלו). לחלופין, אתה יכול לחפש משוב וספונסר לחבילה באתר https://mentors.debian.net/ .
אתה צריך לבנות את החבילה בארכיטקטורה אחת בלבד. שרתי הבניה של דביאן יבנו אותה לשאר הארכיטקטורות. באופן כללי לא מנסים לבנות חבילות שיעבדו "לכמה ארכיטקטורות" (כדוגמת fat binaries) אלא מנסים לגרום לכך שתוכל להתקין חבילות מכמה ארכיטקטורות על המערכת שלך (חפש מידע על MultiArch).
אתה יכול לשים את הקבצים בכל שטח אחסון. האם אתה משתמש בגיט (או מערכת בקרת תצורה אחרת) עבור האריזה? אם אין לך שטח אחסון אתה מוזמן לשלוח לי (tzafrir@cohens.org.il ) את הקבצים.
|
|
|
| חזרה לתוכן הדיון |
פורסם: 23/12/2014 - 12:51
נושא ההודעה:
|
| צפריר : | כאמור, הקישור השני כולל הרבה הנחיות שגויות.
בעיקרון אתה צריך לפתוח באג מסוג ITP על החבילה wnpp (הכי פשוט: reportbug wnpp)ולסגור אותו ב־changelog. מצד שני אתה צריך למצוא בסופו של דבר מי שיעלה את החבילה.
האם אתה מתכוון להמשיך ולתחזק את החבילה או שאתה רוצה רק להעלות עכשיו?
רק מפתחי דביאן רשומים יכולים להעלות חבילות. יכול להיות שימצא מי שהחבילה תעניין אותו אישית (או את הצוות שלו). לחלופין, אתה יכול לחפש משוב וספונסר לחבילה באתר https://mentors.debian.net/ .
אתה צריך לבנות את החבילה בארכיטקטורה אחת בלבד. שרתי הבניה של דביאן יבנו אותה לשאר הארכיטקטורות. באופן כללי לא מנסים לבנות חבילות שיעבדו "לכמה ארכיטקטורות" (כדוגמת fat binaries) אלא מנסים לגרום לכך שתוכל להתקין חבילות מכמה ארכיטקטורות על המערכת שלך (חפש מידע על MultiArch).
אתה יכול לשים את הקבצים בכל שטח אחסון. האם אתה משתמש בגיט (או מערכת בקרת תצורה אחרת) עבור האריזה? אם אין לך שטח אחסון אתה מוזמן לשלוח לי (tzafrir@cohens.org.il ) את הקבצים. |
סדרתי נראה לי הכל, נשאר לי רק לסדר את הבאג...
אני מתכווין להמשיך לתחזק, לא לנצח, אבל כמה שיתאפשר לי .
טוב אני יפתח באג ונראה איך אני מתקדם משם...
מה שלא הבנתי לגבי מולטי ארכיטקטורה,
אני מוסיף את השורות האלו ל control
| קוד: | Architecture: any
Pre-Depends: ${misc:Pre-Depends}
Multi-Arch: same
|
וזה מספיק? כי כשאני מהדר את החבילה זה מהדר עם סיומת amd64. זה ככה אמור להיות?
שלחתי לך את הקבצים. אני יסדר איזה git או משהו כזה.
|
|
|
| חזרה לתוכן הדיון |
פורסם: 23/12/2014 - 13:48
נושא ההודעה:
|
נראה לי שכן.
בינתיים, איך כותבים את הקוד הבא בצורה יותר יבילה?
| קוד: |
#ifdef Q_OS_LINUX
a.setWindowIcon(QIcon ( "/usr/share/pixmaps/hebrew-cal_128.png"));
#endif
#ifdef Q_OS_WIN32
//add in .pro file
#endif
|
|
|
|
| חזרה לתוכן הדיון |
פורסם: 23/12/2014 - 13:58
נושא ההודעה:
|
| צפריר : | נראה לי שכן.
בינתיים, איך כותבים את הקוד הבא בצורה יותר יבילה?
| קוד: |
#ifdef Q_OS_LINUX
a.setWindowIcon(QIcon ( "/usr/share/pixmaps/hebrew-cal_128.png"));
#endif
#ifdef Q_OS_WIN32
//add in .pro file
#endif
|
|
#elseif
צריך למחוק את זה בכלל...
בכלל יש כל מיני דברים מוזרים שם בקוד.
|
|
|
| חזרה לתוכן הדיון |
פורסם: 25/12/2014 - 09:14
נושא ההודעה:
|
|
|
|
|
| חזרה לתוכן הדיון |
פורסם: 26/12/2014 - 11:56
נושא ההודעה:
|
זה מה שיצא, תיעדתי את מה שעשיתי , אולי זה יהיה לתועלת מישהו
http://avisoftware123.blogspot.co.il/2014/12/deb.html
|
|
|
| חזרה לתוכן הדיון |
פורסם: 28/12/2014 - 10:45
נושא ההודעה:
|
כמה הערות:
1. קישור לקריאה ללא ג'אווהסקריפט (לשימוש עתידי שלי):
http://avisoftware123.blogspot.co.il/2014/12/deb.html?m=1
2. אני מתלבט לגבי ההמלצה על שימוש ב־dh-make. בעבר הוא היה הכרחי. הקובץ היחיד שאני נוהג להעתיק כיום הוא קובץ ה־control. אבל נראה לי שהוא כנראה מועיל למתחילים.
3. מתואר כאן תהליך קצת מלאכותי של יצירת קבצים, יצירת חבילה ואז רק יצירת מאגר git. אם אתם אורזים תוכנה שלכם זה נראה די מלאכותי. ההפרדה הזו נועדה למצב שבו מיישהו אחר אורז גרסה קיימת. נחזור לנקודה הזו בהמשך.
4. איך עושים עדכון?
כדי לעדכן, מומלץ לעבוד על הענף upstream ולמזג (merge) את הענף debian אליו עם הגרסה החדשה.
אם נראה לכם שההפרדה הזו בין תוכן החבילה לאריזה מיותרת, אתם צריכים להפוך את החבילה לצורת native שבה אין מספור נפרד לאריזה ובה אין טעם לענף נפרד לאריזה:
| קוד: |
echo '3.0 (native)' >debian/source/format
|
חבילות כאלו פחות נפוצות בתוך המאגר הרשמי אך נוחות יותר למי שמספק תיקיית debian כחלק מהמאגר.
5. הדרך המומלצת ליצור את הודעת ה־ITP היא ע"י הרצת reportbug wnpp. לדוגמה, הבאג שפתחת לא נשלח גם לרשימת התפוצה debian-devel כמקובל בבקשות ITP.
6. אבל, ויותר חשוב מכך, המלצתי לך כמה פעמים לעבור דרך http://mentors.debian.net . נראה לי שזו הדרך המועילה לתורמים חדשים. לי אישית אין מספיק זמן פנוי (גם לכמה חבילות שאני מתחזק).
כהערת אגב קטנה, יש כרגע דיון בדביאן על דרך העבודה המומלצת עם git-buildpackage ואחד הדברים שאמורים להשתנות הוא שמות הענפים שמומלצים לשימוש. אילו יהיו גם ברירות המחדל של git-buildpackage ושאר הכלים. ר'
http://dep.debian.net/deps/dep14/
כמוכן, בגרסאות חדשות יותר נוטים להשתמש בפקודה gbp buildpackage במקום git-buildpackage . מדובר בפועל על אותה פקודה.
|
|
|
| חזרה לתוכן הדיון |
פורסם: 29/12/2014 - 18:25
נושא ההודעה:
|
ראשית כל, תודה על ההשקעה צפריר.
| ציטוט: | 2. אני מתלבט לגבי ההמלצה על שימוש ב־dh-make. בעבר הוא היה הכרחי. הקובץ היחיד שאני נוהג להעתיק כיום הוא קובץ ה־control. אבל נראה לי שהוא כנראה מועיל למתחילים.
|
הוא מועיל לי בתבנית של הקבצים .... לא יותר.
| ציטוט: | | 3. מתואר כאן תהליך קצת מלאכותי של יצירת קבצים, יצירת חבילה ואז רק יצירת מאגר git. אם אתם אורזים תוכנה שלכם זה נראה די מלאכותי. ההפרדה הזו נועדה למצב שבו מיישהו אחר אורז גרסה קיימת. נחזור לנקודה הזו בהמשך. |
עשיתי את ההפרדה הזו כי אם אני משתמש עם dh_make ואני יוצר קודם את ה git ואז אני עושה tarball אני מקבל את ה git גם בפנים .
| ציטוט: | 4. איך עושים עדכון?
כדי לעדכן, מומלץ לעבוד על הענף upstream ולמזג (merge) את הענף debian אליו עם הגרסה החדשה. |
אשמח אם תסביר לי מה כוונתך.
כרגע אין לי ענף debian יש לי רק ענף מרכזי.
אני לא כל כך מומחה בgit, ואולי בגלל זה אני לא מבין
אני חושב שאין קשר בין תוכן החבילה לאריזה. הפרדה זה דבר הגיוני.
השאלה איך אני מסדר את זה כמו שצריך...
| ציטוט: | | 5. הדרך המומלצת ליצור את הודעת ה־ITP היא ע"י הרצת reportbug wnpp. לדוגמה, הבאג שפתחת לא נשלח גם לרשימת התפוצה debian-devel כמקובל בבקשות ITP. |
העדפתי לשלוח במייל , ככה אני לא מתקין כלום.. (אני באובונטו)
| ציטוט: | 6. אבל, ויותר חשוב מכך, המלצתי לך כמה פעמים לעבור דרך http://mentors.debian.net . נראה לי שזו הדרך המועילה לתורמים חדשים. לי אישית אין מספיק זמן פנוי (גם לכמה חבילות שאני מתחזק).
|
אני אעשה את זה ברגע שהכל יהיה פיקס, אני רוצה לעשות את זה כמו שצריך, ולכן אני שמח שאתה מתקן אותי. אפילו שניהול הקוד בgit והקימפול ועדכונים וכו' יכולים לחכות, אני מעדיף להבין את התהליך ואז להעלות.
אגב שמות של חבילות , מכיוון שאני עובד באובנטו , עד שתפסתי ש git-buildpackage מחפש את הגרסה עם השם ubuntu בתוכה, לא תפסתי מה הוא רוצה שהוא לא מוצא את הגרסה upstream/1.0.... בסוף איכשהוא הבנתי.
בסך הכל אני חושב שאני בכיוון הנכון, קצת עזרה פה ושם ויצא מזה משהו טוב. 
|
|
|
| חזרה לתוכן הדיון |
פורסם: 29/12/2014 - 20:21
נושא ההודעה:
|
4. לעניין הענפים: מכיוון שאתה לא עובד עם ענף נפרד לאריזה (זה קצת חסר טעם במקרה שלך), המלצתי לך להשתמש בפורמט native במקום בפורמט quilt.
5. לעניין עבודה באובונטו: אני לא בטוח לגבי git-buildpackage, אבל כל מיני כלים מהחבילה devscripts מסתכלים על הגדרות ויכולים להתנהג אחרת בהתאם להפצה.
לדוגמה, בקובץ .devscripts בתיקיית הבית אפשר לשים את ההגדרות הבאות:
| קוד: |
DEBCHANGE_VENDOR="debian"
DEBUILD_LINTIAN_OPTS="--profile debian"
|
אני לא יודע איך בדיוק reportbug מתנהג באובונטו (אם יש לו אפשרות לדווח לדביאן, או שזו אפילו ברירת המחדל שלו).
6. לדעתי החבילה שלך במצב מספיק טוב כדי שיתחילו להסתכל עליה שם. האויב של הטוב הוא המושלם.
|
|
|
| חזרה לתוכן הדיון |
פורסם: 30/12/2014 - 17:06
נושא ההודעה:
|
|
אוקיי. אני משנה ל native .
למרות שנראה לי שתפסתי את העניין עם הפרדה של ענפים, אבל באמת נראה לי מיותר בשבילי
ה devscript נראה לי עובד...
שאלה אחרונה לפני שאני מעלה, אני צריך לחתום את הקבצים, נכון? איך אני עושה את זה ב git buildpackage ?
ניסתי לעשות בכל מיני צורות, זה לא נראה שזה מוסיף את החתימה לאן שהוא. (עם --git-keyid)
כמובן שיש לי מפתח פרטי שיצרתי
|
|
|
| חזרה לתוכן הדיון |
פורסם: 30/12/2014 - 19:01
נושא ההודעה:
|
dpkg-buildpackage וכלים דומים (debuild, git-buildpackage) ינסו לחתום אוטומטית (אם לא הרצת אותם עם -uc -us).
אפשר לחתום במפורש בעזרת debsign:
| קוד: |
debsign ../package_version_arch.changes
|
|
|
|
| חזרה לתוכן הדיון |
פורסם: 30/12/2014 - 21:01
נושא ההודעה:
|
פשוט לא שמתי לב להוריד את -us -uc כנראה התרגלתי שהם שם.
טוב, אני מנסה להעלות וזה לא מצליח.
נסיתי כמו שכתוב פה
http://mentors.debian.net/intro-maintainers
גם html וגם ftp
ב html ה dput מוציא שגיאה פנימית של פייתון
וב ftp הוא אומר לי
| קוד: |
$ dput mentors-ftp ../hebrew-cal_1.0_amd64.changes -d
Checking signature on .changes
gpg: Signature made IST 20:47:22 2014 דצמ 30 ג' using RSA key ID AEA3455E
gpg: Good signature from "Avi Software <avisoftware123@gmail.com>"
gpg: aka "avisoftware <avisoftware123@gmail.com>"
Good signature on ../hebrew-cal_1.0_amd64.changes.
Checking signature on .dsc
gpg: Signature made IST 20:47:22 2014 דצמ 30 ג' using RSA key ID AEA3455E
gpg: Good signature from "Avi Software <avisoftware123@gmail.com>"
gpg: aka "avisoftware <avisoftware123@gmail.com>"
Good signature on ../hebrew-cal_1.0.dsc.
Uploading to mentors-ftp (via ftp to mentors.debian.net):
Server closed the connection
|
מה הסיפור?
זה בגלל שאני באובונטו? או משהו בראוטר? או אולי בספק (רימון  )
|
|
|
| חזרה לתוכן הדיון |
פורסם: 01/01/2015 - 00:05
נושא ההודעה:
|
|
האם הוספת את המפתח שלך להגדרות המשתמש? נסה אולי להעלות בעזרת http במקום ב־ftp.
אם גם זה לא עוזר, נסה לשאול בערוץ ה־IRC שלהם: הערוץ #debian-mentors ברשת OFTC (כלומר: irc.debian.org או irc.oftc.net, אך לא Freenode).
|
|
|
| חזרה לתוכן הדיון |
פורסם: 01/01/2015 - 10:54
נושא ההודעה:
|
ב http אני מקבל שגיאה כזאת
| קוד: |
dput mentors hebrew-cal_1.0_amd64.changes
Checking signature on .changes
gpg: Signature made IST 20:47:22 2014 דצמ 30 ג' using RSA key ID AEA3455E
gpg: Good signature from "Avi Software <avisoftware123@gmail.com>"
gpg: aka "avisoftware <avisoftware123@gmail.com>"
Good signature on /home/avi/qt/hebrew-cal_1.0_amd64.changes.
Checking signature on .dsc
gpg: Signature made IST 20:47:22 2014 דצמ 30 ג' using RSA key ID AEA3455E
gpg: Good signature from "Avi Software <avisoftware123@gmail.com>"
gpg: aka "avisoftware <avisoftware123@gmail.com>"
Good signature on /home/avi/qt/hebrew-cal_1.0.dsc.
Uploading to mentors (via http to mentors.debian.net):
Uploading hebrew-cal_1.0_amd64.deb: 64k/145kTraceback (most recent call last):
File "/usr/bin/dput", line 948, in <module>
main()
File "/usr/bin/dput", line 911, in main
files_to_upload, debug, 0, progress=progress)
File "/usr/share/dput/http.py", line 110, in upload
conn.send(s)
File "/usr/lib/python2.7/httplib.py", line 826, in send
self.sock.sendall(data)
File "/usr/lib/python2.7/socket.py", line 224, in meth
return getattr(self._sock,name)(*args)
socket.error: [Errno 32] Broken pipe |
אני לא מומחה לפייתון אבל זה נראה דומה לשגיאה ב ftp
ראיתי ברשת שיש בעיה עם רימון ב ftp לפעמים. אני מנסה לשאול אותם על זה.
כמובן שהוספתי את המפתח שלי שם בהגדרות.
אנסה גם לשאול בirc
|
|
|
| חזרה לתוכן הדיון |
פורסם: 01/01/2015 - 11:31
נושא ההודעה:
|
טוב העניין סודר, אכן רימון חוסמים גישה לפורטים לא שגרתיים , פתחו לי וזה עלה.
| קוד: |
Uploading hebrew-cal_1.0_amd64.deb: done.
Uploading hebrew-cal_1.0.dsc: done.
Uploading hebrew-cal_1.0.tar.xz: done.
Uploading hebrew-cal_1.0_amd64.changes: done.
|
|
|
|
| חזרה לתוכן הדיון |
פורסם: 01/01/2015 - 11:35
נושא ההודעה:
|
|
|
|
|
| חזרה לתוכן הדיון |
פורסם: 02/01/2015 - 09:06
נושא ההודעה:
|
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=774348
עכשיו הם רוצים שזה לא יהיה native, ועוד כל מיני שינויים.
נו, אני אשנה...
מה הם רוצים ממני בנושא העתקה של קוד? אסור לקחת חתיכת קוד ולשלב אותה בתוכנה? איך אני כן יכול לעשות את זה?
|
|
|
| חזרה לתוכן הדיון |
פורסם: 02/01/2015 - 12:27
נושא ההודעה:
|
|
בהחלט מותר. מצד שני, דביאן כוללת את libhdate וזה לא מסובך במיוחד לקרוא מקוד C++ לקוד C. האם אתה יכול להשתמש בספריה הקיימת? (לא, זה לא בדיוק מה שהם שאלו שם)
|
|
|
| חזרה לתוכן הדיון |
פורסם: 02/01/2015 - 12:36
נושא ההודעה:
|
|
שאלתי ב irc שלהם, ואמרו שמותר , אבל שאני לא ימצא לזה sponsor ...
אני חושב לעשות ככה:
עברתי על הקוד שלי, וחלק ממנו אני יכול להתמך על libhdate (תוך כדי שאני מוותר על תוספות קטנות ששיניתי) , יש כמה חלקים ששיניתי יותר ואין לי ברירה.
מה עלי לעשות :
א. נראה לך כדאי לי להישאר ב native?
או שאם אני רוצה שמישהו יקדם לי את זה אני יעבור ל quilt ?
ב. נניח ואני מתקן את כל התיקונים, איך אני מעדכן את החבילה למצב החדש?
זה די הרבה שינויים, להמשיך בgit הקיים ? (אם אני רוצה לעבור ל quilt צריך לפצל לכמה ענפים וכו' לא כזה מסובך, אבל יותר נח שזה מפוצל כמו שצריך מההתחלה)
|
|
|
| חזרה לתוכן הדיון |
|
|
ת.הצטרפות: 27/06/2012
·
הודעות: 34
·
