-
Notifications
You must be signed in to change notification settings - Fork 0
/
Copy pathbuilding-singularity-debian.html
1027 lines (622 loc) · 60.1 KB
/
building-singularity-debian.html
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503
504
505
506
507
508
509
510
511
512
513
514
515
516
517
518
519
520
521
522
523
524
525
526
527
528
529
530
531
532
533
534
535
536
537
538
539
540
541
542
543
544
545
546
547
548
549
550
551
552
553
554
555
556
557
558
559
560
561
562
563
564
565
566
567
568
569
570
571
572
573
574
575
576
577
578
579
580
581
582
583
584
585
586
587
588
589
590
591
592
593
594
595
596
597
598
599
600
601
602
603
604
605
606
607
608
609
610
611
612
613
614
615
616
617
618
619
620
621
622
623
624
625
626
627
628
629
630
631
632
633
634
635
636
637
638
639
640
641
642
643
644
645
646
647
648
649
650
651
652
653
654
655
656
657
658
659
660
661
662
663
664
665
666
667
668
669
670
671
672
673
674
675
676
677
678
679
680
681
682
683
684
685
686
687
688
689
690
691
692
693
694
695
696
697
698
699
700
701
702
703
704
705
706
707
708
709
710
711
712
713
714
715
716
717
718
719
720
721
722
723
724
725
726
727
728
729
730
731
732
733
734
735
736
737
738
739
740
741
742
743
744
745
746
747
748
749
750
751
752
753
754
755
756
757
758
759
760
761
762
763
764
765
766
767
768
769
770
771
772
773
774
775
776
777
778
779
780
781
782
783
784
785
786
787
788
789
790
791
792
793
794
795
796
797
798
799
800
801
802
803
804
805
806
807
808
809
810
811
812
813
814
815
816
817
818
819
820
821
822
823
824
825
826
827
828
829
830
831
832
833
834
835
836
837
838
839
840
841
842
843
844
845
846
847
848
849
850
851
852
853
854
855
856
857
858
859
860
861
862
863
864
865
866
867
868
869
870
871
872
873
874
875
876
877
878
879
880
881
882
883
884
885
886
887
888
889
890
891
892
893
894
895
896
897
898
899
900
901
902
903
904
905
906
907
908
909
910
911
912
913
914
915
916
917
918
919
920
921
922
923
924
925
926
927
928
929
930
931
932
933
934
935
936
937
938
939
940
941
942
943
944
945
946
947
948
949
950
951
952
953
954
955
956
957
958
959
960
961
962
963
964
965
966
967
968
969
970
971
972
973
974
975
976
977
978
979
980
981
982
983
984
985
986
987
988
989
990
991
992
993
994
995
996
997
998
999
1000
<!DOCTYPE html>
<head>
<meta charset="utf-8">
<meta http-equiv="X-UA-Compatible" content="IE=edge">
<meta name="viewport" content="width=device-width, initial-scale=1">
<meta name="description" content=" Building Singularity on Debian Oct 1, 2016 / This tutorial is generated courtsey of Karl Kornel from Stanford Research Computing. The ascii art is amazing, if you don’t care to build Singularity on Debian please scroll down to appreciate it in it’s entirety. Thank you Karl!NOTE: that an official debian initiative is underway, and this tutorial is for those interested in digging into the build.For the purposes of this tutorial, we will assume that the name of your remote is “stanford” and your username is “vsoch.”Quick ReferenceThis is for people who know what’s going on, and just want help remembering the command sequence.Making a fresh repo.git init .git remote add lbl [email protected]:singularityware/singularity.gitgit remote add stanford [email protected]:vsoch/singularity.gitgit fetch lblfor i in master 1.x 2.x gh-pages; dogit checkout lbl/$igit checkout -b $igit branch -u stanford/$idonegit push --all stanfordgit push --tags stanfordReleasing an upstream version, with the change in source format, and adding the appropriate backport suffix to the version number.git clone https://github.com/vsoch/singularity.gitgit checkout 2.1.2git checkout -b stanford-2.1.2# Change debian/source/format to 3.0 (git)# Add git debian/control's Build-Depends listgit commit -m 'Changing to git source format' debian/control debian/source/formatdch -D xenial-backports -v 2.1.2-1~sbp16.04.1+1 'Releasing for Xenial'git commit -m 'Update changelog for release' debian/changeloggit tag -s stanford/2.1.2-1_sbp16.04.1+1git pushgit push --tagsTo set up and build on a single system (same release only):aptitude install -y build-essential debhelper dh-autoreconf gitdpkg-buildpackage -us -ucTo set up and build on the build server:ssh $USER@$BUILDSERVERcd $SCRATCH/$USERtest -d build-area || mkdir build-areagit clone https://github.com/vsoch/singularity.gitcd singularitygit checkout stanford-2.1.2ls -d /var/cache/pbuilder/base*.cowpdebuild --pbuilder cowbuilder --buildresult ../build-area -- \--basepath /var/cache/pbuilder/base-xenial.cowrm ../singularity_*.dsc ../singularity_*.git \../singularity_*.changes ../singularity_*.buildcd ../build-areaOverviewSingularity is unusual from a Debian perspective, in that the Debian packaging data are part of the upstream repository.Normally, at least with Git repositories, the flow looks like this: ================== || Upstream || || Repo || || || || /--------\ || || | master | || || | branch | || || \----v---/ || =========v======== I =========v=============================== || /----v-----\ /--------------\ || || | upstream | | pristine-tar | || || | branch +---->| branch | || || \----v-----/ \-v------------/ || || I I || || I /--------\ I || || I | debian | I || || I | dir. | I || || I \-v------/ I || || I I I || || /----v---v-\ I || || | master | I Debian || || | branch | I Maintainer's || || \----v-----/ I Repo || =========I=============I================= I I /-v-------------v--\ | Debian package | \------------------/The Debian maintainer is responsible for pulling in code from upstream, adding the debian directory (which includes both metadata, build instructions, and patch files to change code), testing, and building the resulting Debian package(s).With Singularity, there is no “Debian Maintainer’s Repo”, because the debian directory is in the upstream repository. On the one hand, this is nice because we only have to deal with a single repository! However, there are two challenges that are introduced by this: You will always have to make a change of your own, because you need to set the name of the release that you are targeting when you build. The upstream repository is either going to have the release name (like “jessie” or “xenial”) un-set, or will probably have it set to something that you do not want. Most Debian build infrastructure is used to working from a .tar file containing the pristine (the “orig”) source code. That doesn’t exist here.To deal with point 1, we do two things: We make a new branch, and we add a commit on that branch which updates the changelog (the release name and version number come from the changelog).To deal with point 2, we change how Debian deals with the source code: Instead of expecting a source tarball (with the 3.0 (orig) or 3.0 (quilt) source formats), we use an experimental format (3.0 (git)) which simply bundles up the entire Git repo as the source!With the two changes we will make, the actual flow will look like this: ================================= || Upstream || || Repo || || || || /---------\ /----------\ || || | release | | various | || || | tags | | branches | || || \----v----/ \----v-----/ || =========v============v========== I I =========v============v==================== || /----v----\ /----v-----\ Our || || | release | | various | Repo || || | tags | | branches | || || \----v----/ \----------/ || || I || || I /-------------\ || || I | debian dir. | || || I | changes | || || I \--v----------/ || || I I || || /----v-------v-\ /--------------\ || || | stanford-XXX | | stanford/XXX | || || | branches +---> tags | || || \--------------/ \-------v------/ || || I || ===============v===============v=========== I I I /---------v--------\ \-----> Debian package | \------------------/The overall process goes like this: First, we make a clone of the upstream repository. That brings in upstream’s branches (like master, 1.x, and 2.x). We pick a release tag (like 2.1.2) and branch it (making the stanford-2.1.2 branch). We change some of the stuff in the debian directory, and we tag our changes. We build our package. The final package includes a copy of the entire Git repository as the source, instead of a .tar file.The following sections describe each of those four overall steps.Creating the RepositorySinguarity has their repository in Github, so cloning the repository is just a matter of forking it. However, if you want your repository to live somewhere other than Github, you can do this process:First, create a blank repository, add the upstream Github as a source, and fetch: git init . git remote add lbl [email protected]:singularityware/singularity.git git fetch lblNext, add a new remote representing your upstream repository: git remote add stanford [email protected]:vsoch/singularity.gitCheck out the branches you care about, and link them to your upstream: for i in master 1.x 2.x gh-pages; do git checkout lbl/$i git checkout -b $i git branch -u stanford/$i doneFinally, push everything to your new upstream: git push --all stanford git push --tags stanfordUpdating Your RepositoryFrom time to time, you should pull in upstream changes, so that your repository is in sync. Here’s how to do that.First, create a blank repository, and add both your remote and the upstream remote. Then, fetch from both: git init . git remote add lbl [email protected]:singularityware/singularity.git git remote add stanford [email protected]:vsoch/singularity.git git fetch --allNext, synchronize all changes from the branches we know about: for i in master 1.x 2.x gh-pages; do git checkout stanford/$i git checkout -b $i git branch -u stanford/$i git merge lbl/$i doneThen, run git branch -r and look to see if upstream has any new branches. If they do, then create matching branches on your end: for i in new1 new2; do git checkout lbl/$i git checkout -b $i git branch -u stanford/$i doneFinally, push everything up to your copy: git push --all stanford git push --tags stanfordIf you are leaving upstream’s branches untouched, then all of the merges should be fast-forward merges. If, however, you are making changes in upstream branches (like master, or 2.x), you should expect either a non-fast-forward merge or a conflict. It’s up to you to deal with them.Making a releaseWhen upstream makes a release, we should do the same. Even if we aren’t going to package it, making the release now means that packaging will go faster later!First, if you don’t have the Git repository checked out, get it now: git clone https://github.com/vsoch/singularity.gitNext, either switch to the branch you want to build, or check out the tag for the release you want. In this case, we are getting 2.1.2 (which is a tag). git checkout 2.1.2Then, create a new branch for that specific version, to which we’ll add our changes: git checkout -b stanford-2.1.2Now that we have our branch, there are two things we have to check: Check debian/source/format, and change it to 3.0 (git). Check debian/control, and add git to the “Build-Depends” list.Once those changes are made, commit them. git commit -m 'Changing to git source format' debian/control debian/source/formatIf you are working from your own Git repository, then you should also change the “Vcs-Git” and “Vcs-Browser” fields in debian/control. You should also add yourself to the “Uploaders” field. Then, once again, commit.Next, you need to update the changelog. This is what sets the release, and also the version number! dch -D xenial-backports -v 2.1.2-1~sbp16.04.1+1 'Releasing for Xenial' git commit -m 'Update changelog for release' debian/changelog(See the “Version Numbering” section for help on deciding what version number to use.)Finally, make a new tag repesenting your version. git tag -s stanford/2.1.2-1_sbp16.04.1+1(We changed the ~ in the version number to an _ because Git doesn’t allow the tilde character in tag names.)When making the tag, an editor will launch, giving you a space to enter a tag description. Simply re-use the entry you made into debian/changelog (just copy-paste the entire changelog entry, including the header and the date line).If you don’t have a PGP key, then change -s to -a.Finally, push everything, and you are ready to build! git push git push --tagsAt this point, you can either go on to build the package, or you can stop, and the release will remain ready for when you do want to build.Version NumberingVersion numbering is interesting in Debian, because you need to keep track of at least two things: The upstream version number. The Debian revision number, which is essentially the version number for the debian directory contents.But, you may also have to add other things: Debian derivatives (like Ubuntu) add their own suffix and number, like ubuntu1 or ubuntu2. If you are building something outside of the normal process, such as a backport (a newer version packaged for a production Debian release) or a test build, you need an additional suffix for that, normally a tilde character followed by something.When constructing the package version number, there are two rules, and one very important exception to remember: Version numbers are evaluated in “parts”, where each “part” is non-digit characters followed by digit characters. So, in the version number 2.1.2-1, the parts are 2, .1, .2, and -1. Within a part, first the non-numeric portion is compared (using an ASCII sort), and if equal, the numeric portion is compared (using a numeric sort). In Debian version numbers, the tilde character (~) sorts before everything else, including the empty string.Because of that exception, if you have a test build (like 2.1.2-1~testFoo+1) or a backport (2.1.2-1~bpo8+1), Debian will treat those versions as being older than a released version (like 2.1.2-1 or 2.1.2-1ubuntu1).More information is available in the Debian Policy Manual, sections 3.2 and 5.6.12.Given all of the above, here are recommended version numbers to use: Backports (no code changes) for Debian should use the form VERSION-1~sbp8+1, where the 8 is the version number of the Debian release (Debian jessie is version 8). Backports (no code changes) for Ubuntu should use the form VERSION-1~sbp16.04+1. Similarly, 16.04 is the Ubuntu version. If we are making actual code changes, we should use a form like VERSION-1stanford1. We shoud then try to get those code changes applied upstream.We use a different form for code changes because we want that to remain newer than anything that comes in through Debian/Ubuntu upstream (lest we lose our changes in an upgrade). Since backports don’t have code changes, they are lower-priority.Building the packageOnce you have a release tagged and pushed, it is time to build the package.Before you start, you have to make a choice: You can either build the package on your own system, or you can use the Debian build service. Either way, the build products are the same.Building on your own systemThe easiest way to build Singularity packages is on a system that you’ve already got. On the one hand, you don’t have to maintain a separate infrastructure! However, you will only build for the release that you are running on that system. So, if you’re running Debian wheezy, you’ll only be able to build packages for Debian wheezy.The other downside is that you’ll have to install all of the build dependencies system-wide. However, that’s not a big problem here, because Singularity’s needs are very simple. There are four packages (plus all of their dependencies) that need to be installed: build-essential is a single package that installs (via dependencies) all of essential things that are required for building Debian packages. debhelper is a suite of scripts that help to automate the Debian package-building process. Almost all of the steps in making a package, such as generating the list of changes, are orchestrated by debhelper. (Singularity uses debhelper, which is why this is required.) dh-autoreconf is an optional debhelper component that ensures autoreconf is run before the software’s configure script. This package also has the various autotools (autoconf, automake, etc.) as dependencies, so we can be sure they are also installed. (Singularity uses dh-autoreconf, which is why this is required.) Since we are getting everything from a Git repository, you’ll need to install git.You only have to do this the first time you build on this system. aptitude install -y build-essential debhelper dh-autoreconf gitNow it’s time to build the package! Here’s the command to use: dpkg-buildpackage -us -ucThat’s it! That one command triggers an entire sequence of commands that will archive the source, build it, package the output, and create ancillary files. The command output is relatively good at explaining what’s going on, so I won’t reproduce or expand on that here.Using the Debian Build ServerIf you plan on building for a release that is not your own, or you are unable to install all of the build dependencies, then you should use the Debian build server!First, log in to the build server, and go to your scratch directory. Make a build-area directory, if you don’t have one already: ssh $USER@buildserver cd $SCRATCH/$USER test -d build-area || mkdir build-areaCheck out the repository, go into it, and then check out the branch or tag that you want to package: git clone https://github.com/vsoch/singularity.git cd singularity git checkout stanford-2.1.2Look at the list of available releases to build against, and then pick one: ls -d /var/cache/pbuilder/base*.cowOnce the release you want is available, build your package! pdebuild --pbuilder cowbuilder --buildresult ../build-area -- \ --basepath /var/cache/pbuilder/base-xenial.cowThe pdebuild process takes care of several different things: Instructing cowbuilder to spawn a new COW (copy-on-write) environment, based on the release you specify, and start a root session within the environment. Identifying any missing build dependencies, and installing them inside the build environent. Running dpkg-buildpackage, making sure that build products get put in the right place, and owned by you (not by root).Once the build process is complete, the final products are placed into the build-area directory you created, but some intermediate products are left in the parent directory, which you should delete: rm ../singularity_*.dsc ../singularity_*.git \ ../singularity_*.changes ../singularity_*.buildThat’s it! You now have stuff that you can install or upload.Build Products, and UploadingOnce package-building is complete, you should have three or four build products: The .deb file is your package! You can install this directly with dpkg -i DEB_FILE_PATH. The .build is a complete log of the steps taken to build your package, as well as the output (standard out and standard error) from those steps. If you are building locally, then this file might only be created if there was a problem. If you are using the build server, this file is always created. The .git file is your entire Git repository, packed up in a single file. This is known as a Git Bundle. The .changes file is filled with metadata that is used for uploading a package. It includes information about what package(s) you’re uploading, as well as file sizes and checksums. The .dsc file is similar to your .changes file, except this file only contains information on the source. This file contains the information that someone else would need to get the source code you used, install the build dependencies, and then build the binary package themselves. The .dsc and .changes files are normally signed during the package-build process; this gets skipped normally by pdebuild, and gets disabled on dpkg-buildpackage by the -us -uc options. If you plan on uploading these files to a Debian repository, then you should sign them, either manually or using the debsign command. debsign singularity_*.changes You’ll be prompted twice, once to sign the .dsc file, then again to sign the .changes file.Once signed, you can upload using dput: dput stanford singularity_*.changesThat’s it! Once your servers upgrade, they should see the newer package version as an option. Please enable JavaScript to view the comments powered by Disqus. Site last generated: Jul 26, 2017 ">
<meta name="keywords" content="recipes">
<meta name="name" content="Building Singularity on Debian">
<meta name="thumbnail" content="http://singularity.lbl.gov/images/logo/logo.svg">
<title>Building Singularity on Debian | Singularity</title>
<link rel="stylesheet" href="assets/css/syntax.css">
<link rel="stylesheet" type="text/css" href="https://maxcdn.bootstrapcdn.com/font-awesome/4.5.0/css/font-awesome.min.css">
<!--<link rel="stylesheet" type="text/css" href="css/bootstrap.min.css">-->
<link rel="stylesheet" href="assets/css/modern-business.css">
<link rel="stylesheet" href="assets/css/lavish-bootstrap.css">
<link rel="stylesheet" href="assets/css/customstyles.css">
<link rel="stylesheet" href="assets/css/theme-blue.css">
<link rel="stylesheet" type="text/css" href="assets/css/asciinema-player.css" />
<script src="https://cdnjs.cloudflare.com/ajax/libs/jquery/2.1.4/jquery.min.js"></script>
<script src="https://cdnjs.cloudflare.com/ajax/libs/jquery-cookie/1.4.1/jquery.cookie.min.js"></script>
<script src="assets/js/jquery.navgoco.min.js"></script>
<script src="https://maxcdn.bootstrapcdn.com/bootstrap/3.3.4/js/bootstrap.min.js"></script>
<script src="https://cdnjs.cloudflare.com/ajax/libs/anchor-js/2.0.0/anchor.min.js"></script>
<script src="assets/js/toc.js"></script>
<script src="assets/js/customscripts.js"></script>
<link rel="shortcut icon" href="images/favicon/favicon.ico">
<!-- HTML5 Shim and Respond.js IE8 support of HTML5 elements and media queries -->
<!-- WARNING: Respond.js doesn't work if you view the page via file:// -->
<!--[if lt IE 9]>
<script src="https://oss.maxcdn.com/libs/html5shiv/3.7.0/html5shiv.js"></script>
<script src="https://oss.maxcdn.com/libs/respond.js/1.4.2/respond.min.js"></script>
<![endif]-->
<link rel="alternate" type="application/rss+xml" title="" href="http://localhost:4005feed.xml">
<script>
$(document).ready(function() {
// Initialize navgoco with default options
$("#mysidebar").navgoco({
caretHtml: '',
accordion: true,
openClass: 'active', // open
save: false, // leave false or nav highlighting doesn't work right
cookie: {
name: 'navgoco',
expires: false,
path: '/'
},
slide: {
duration: 400,
easing: 'swing'
}
});
$("#collapseAll").click(function(e) {
e.preventDefault();
$("#mysidebar").navgoco('toggle', false);
});
$("#expandAll").click(function(e) {
e.preventDefault();
$("#mysidebar").navgoco('toggle', true);
});
});
</script>
<script>
$(function () {
$('[data-toggle="tooltip"]').tooltip()
})
</script>
</head>
<body>
<!-- asciinema player -->
<script src="assets/js/asciinema-player.js"></script>
<!-- Show or hide players on button clicks-->
<script>
$( document ).ready(function() {
$(".asciinema-button").click(function(){
var asciinemaVideo = "#asciinema-" + $(this).attr('id');
if ($(asciinemaVideo).hasClass('hidden')){
$(asciinemaVideo).removeClass('hidden');
$(this).text('Hide Tutorial')
} else {
$(asciinemaVideo).addClass('hidden');
$(this).text('Show Tutorial')
}
});
});
</script>
<!-- Navigation -->
<nav class="navbar navbar-inverse navbar-fixed-top">
<div class="container topnavlinks">
<div class="navbar-header">
<button type="button" class="navbar-toggle" data-toggle="collapse" data-target="#bs-example-navbar-collapse-1">
<span class="sr-only">Toggle navigation</span>
<span class="icon-bar"></span>
<span class="icon-bar"></span>
<span class="icon-bar"></span>
</button>
<a class="navbar-brand" href="index.html"> <span class="projectTitle"> Singularity</span></a>
</div>
<div class="collapse navbar-collapse" id="bs-example-navbar-collapse-1">
<ul class="nav navbar-nav navbar-right">
<!-- entries without drop-downs appear here -->
<li><a href="blog">News</a></li>
<!-- entries with drop-downs appear here -->
<!-- conditional logic to control which topnav appears for the audience defined in the configuration file.-->
<li class="dropdown">
<a href="#" class="dropdown-toggle" data-toggle="dropdown">Docs<b class="caret"></b></a>
<ul class="dropdown-menu">
<li><a href="admin-guide">Admin Guide</a></li>
<li><a href="user-guide">User Guide</a></li>
<li><a href="links">Contributed Content</a></li>
</ul>
</li>
<li class="dropdown">
<a href="#" class="dropdown-toggle" data-toggle="dropdown">Quick Links<b class="caret"></b></a>
<ul class="dropdown-menu">
<li><a href="https://github.com/singularityware/singularity" target="_blank">Github Repo</a></li>
<li><a href="https://groups.google.com/a/lbl.gov/forum/#!forum/singularity" target="_blank">Google Group</a></li>
<li><a href="http://stackoverflow.com/questions/tagged/singularity" target="_blank">Singularity on Stack Overflow</a></li>
<li><a href="https://singularity-hub.org/faq" target="_blank">Singularity Hub</a></li>
<li><a href="https://singularity-container.slack.com" target="_blank">Slack</a></li>
<li><a href="faq#troubleshooting">Troubleshooting</a></li>
</ul>
</li>
<li class="dropdown">
<a href="#" class="dropdown-toggle" data-toggle="dropdown">People<b class="caret"></b></a>
<ul class="dropdown-menu">
<li><a href="http://www.lbl.gov/" target="_blank">LBNL</a></li>
<li><a href="https://srcc.stanford.edu/" target="_blank">Stanford</a></li>
</ul>
</li>
<li><a href="/search"><i class="fa fa-search"></i></li>
<!-- jekyll search hidden in favor of google
<li>
<div id="search-demo-container">
<input type="text" id="search-input" placeholder="search...">
<ul id="results-container"></ul>
</div>
<script src="assets/js/jekyll-search.js" type="text/javascript"></script>
<script type="text/javascript">
SimpleJekyllSearch.init({
searchInput: document.getElementById('search-input'),
resultsContainer: document.getElementById('results-container'),
dataSource: 'search.json',
searchResultTemplate: '<li><a href="{url}" title="Building Singularity on Debian">{title}</a></li>',
noResultsText: 'No results found.',
limit: 10,
fuzzy: true,
})
</script>
end search-->
</li>
</ul>
</div>
</div>
<!-- /.container -->
</nav>
<!-- Page Content -->
<div class="container">
<div class="col-lg-12"> </div>
<!-- Content Row -->
<div class="row">
<!-- Sidebar Column -->
<div class="col-md-3">
<div class="shiny"><a href="\"><figure><img src="/images/logo/logo.svg" class="sidebar-logo"/></figure></a></div>
<ul id="mysidebar" class="nav">
<li class="sidebarTitle">Singularity</li>
<li>
<a href="#">Information</a>
<ul>
<li><a href="blog">News</a></li>
<li><a href="about">About Singularity</a></li>
<li><a href="presentations">Presentations</a></li>
<li><a href="citation-registration">Registry: Citations and Installations</a></li>
</ul>
<li>
<a href="#">Download / Installation</a>
<ul>
<li><a href="all-releases">All Releases</a></li>
<li><a href="install-linux">Install Singularity on Linux</a></li>
<li><a href="install-mac">Install Singularity on Mac</a></li>
<li><a href="install-windows">Install Singularity on Windows</a></li>
</ul>
<li>
<a href="#">Contributing</a>
<ul>
<li><a href="contributing-support">User Support</a></li>
<li><a href="contributing-code">Code Development</a></li>
<li><a href="contributing-docs">Writing Documentation</a></li>
</ul>
<li>
<a href="#">Getting Help</a>
<ul>
<li><a href="faq">FAQ</a></li>
<li><a href="support">Support</a></li>
<li><a href="faq#troubleshooting">Troubleshooting</a></li>
</ul>
<li>
<a href="#">Documentation</a>
<ul>
<li><a href="quickstart">Quick Start</a></li>
<li><a href="tutorials">Recipes and Tutorials</a></li>
<li><a href="links">Contributed Content Links</a></li>
<li><a href="user-guide">User Documentation</a></li>
<li><a href="admin-guide">Admin Documentation</a></li>
</ul>
<!-- if you aren't using the accordion, uncomment this block:
<p class="external">
<a href="#" id="collapseAll">Collapse All</a> | <a href="#" id="expandAll">Expand All</a>
</p>
-->
</li>
</ul>
</div>
<!-- this highlights the active parent class in the navgoco sidebar. this is critical so that the parent expands when you're viewing a page. This must appear below the sidebar code above. Otherwise, if placed inside customscripts.js, the script runs before the sidebar code runs and the class never gets inserted.-->
<script>$("li.active").parents('li').toggleClass("active");</script>
<!-- Content Column -->
<div class="col-md-9">
<article class="post" itemscope itemtype="http://schema.org/BlogPosting">
<header class="post-header">
<h1 class="post-title" itemprop="name headline">Building Singularity on Debian</h1>
<p class="post-meta"><time datetime="2016-10-01T00:00:00-04:00" itemprop="datePublished">Oct 1, 2016</time> /
</p>
</header>
<div class="post-content" itemprop="articleBody">
<p>This tutorial is generated courtsey of <a href="https://twitter.com/californiakarl" target="_blank">Karl Kornel</a> from Stanford Research Computing. The ascii art is amazing, if you don’t care to build Singularity on Debian please scroll down to appreciate it in it’s entirety. Thank you Karl!</p>
<p><strong>NOTE: that an official debian initiative <a href="http://neuro.debian.net/pkgs/singularity-container.html?highlight=singularity">is underway</a>, and this tutorial is for those interested in digging into the build.</strong></p>
<p>For the purposes of this tutorial, we will assume that the name of your remote is “stanford” and your username is “vsoch.”</p>
<!-- this handles the automatic toc. use ## for subheads to auto-generate the on-page minitoc. if you use html tags, you must supply an ID for the heading element in order for it to appear in the minitoc. -->
<script>
$( document ).ready(function() {
// Handler for .ready() called.
$('#toc').toc({ minimumHeaders: 0, listType: 'ul', showSpeed: 0, headers: 'h2,h3,h4' });
/* this offset helps account for the space taken up by the floating toolbar. */
$('#toc').on('click', 'a', function() {
var target = $(this.getAttribute('href'))
, scroll_target = target.offset().top
$(window).scrollTop(scroll_target - 10);
return false
})
});
</script>
<div id="toc"></div>
<h2 id="quick-reference">Quick Reference</h2>
<p>This is for people who know what’s going on, and just want help remembering the command sequence.</p>
<h3 id="making-a-fresh-repo">Making a fresh repo.</h3>
<div class="highlighter-rouge"><pre class="highlight"><code>git init .
git remote add lbl [email protected]:singularityware/singularity.git
git remote add stanford [email protected]:vsoch/singularity.git
git fetch lbl
for i in master 1.x 2.x gh-pages; do
git checkout lbl/$i
git checkout -b $i
git branch -u stanford/$i
done
git push --all stanford
git push --tags stanford
</code></pre>
</div>
<h3 id="releasing-an-upstream-version-with-the-change-in-source-format-and-adding-the-appropriate-backport-suffix-to-the-version-number">Releasing an upstream version, with the change in source format, and adding the appropriate backport suffix to the version number.</h3>
<div class="highlighter-rouge"><pre class="highlight"><code>git clone https://github.com/vsoch/singularity.git
git checkout 2.1.2
git checkout -b stanford-2.1.2
# Change debian/source/format to 3.0 (git)
# Add git debian/control's Build-Depends list
git commit -m 'Changing to git source format' debian/control debian/source/format
dch -D xenial-backports -v 2.1.2-1~sbp16.04.1+1 'Releasing for Xenial'
git commit -m 'Update changelog for release' debian/changelog
git tag -s stanford/2.1.2-1_sbp16.04.1+1
git push
git push --tags
</code></pre>
</div>
<h3 id="to-set-up-and-build-on-a-single-system-same-release-only">To set up and build on a single system (same release only):</h3>
<div class="highlighter-rouge"><pre class="highlight"><code>aptitude install -y build-essential debhelper dh-autoreconf git
dpkg-buildpackage -us -uc
</code></pre>
</div>
<h3 id="to-set-up-and-build-on-the-build-server">To set up and build on the build server:</h3>
<div class="highlighter-rouge"><pre class="highlight"><code>ssh $USER@$BUILDSERVER
cd $SCRATCH/$USER
test -d build-area || mkdir build-area
git clone https://github.com/vsoch/singularity.git
cd singularity
git checkout stanford-2.1.2
ls -d /var/cache/pbuilder/base*.cow
pdebuild --pbuilder cowbuilder --buildresult ../build-area -- \
--basepath /var/cache/pbuilder/base-xenial.cow
rm ../singularity_*.dsc ../singularity_*.git \
../singularity_*.changes ../singularity_*.build
cd ../build-area
</code></pre>
</div>
<h2 id="overview">Overview</h2>
<p>Singularity is unusual from a Debian perspective, in that the Debian packaging data are part of the upstream repository.</p>
<p>Normally, at least with Git repositories, the flow looks like this:</p>
<div class="highlighter-rouge"><pre class="highlight"><code> ==================
|| Upstream ||
|| Repo ||
|| ||
|| /--------\ ||
|| | master | ||
|| | branch | ||
|| \----v---/ ||
=========v========
I
=========v===============================
|| /----v-----\ /--------------\ ||
|| | upstream | | pristine-tar | ||
|| | branch +---->| branch | ||
|| \----v-----/ \-v------------/ ||
|| I I ||
|| I /--------\ I ||
|| I | debian | I ||
|| I | dir. | I ||
|| I \-v------/ I ||
|| I I I ||
|| /----v---v-\ I ||
|| | master | I Debian ||
|| | branch | I Maintainer's ||
|| \----v-----/ I Repo ||
=========I=============I=================
I I
/-v-------------v--\
| Debian package |
\------------------/
</code></pre>
</div>
<p>The Debian maintainer is responsible for pulling in code from upstream, adding the debian directory (which includes both metadata, build instructions, and patch files to change code), testing, and building the resulting Debian package(s).</p>
<p>With Singularity, there is no “Debian Maintainer’s Repo”, because the debian directory is in the upstream repository. On the one hand, this is nice because we only have to deal with a single repository! However, there are two challenges that are introduced by this:</p>
<ol>
<li>You will always have to make a change of your own, because you need to set the name of the release that you are targeting when you build. The upstream repository is either going to have the release name (like “jessie” or “xenial”) un-set, or will probably have it set to something that you do not want.</li>
<li>Most Debian build infrastructure is used to working from a <code class="highlighter-rouge">.tar</code> file containing the pristine (the “orig”) source code. That doesn’t exist here.</li>
</ol>
<p>To deal with point 1, we do two things: We make a new branch, and we add a commit on that branch which updates the changelog (the release name and version number come from the changelog).</p>
<p>To deal with point 2, we change how Debian deals with the source code: Instead of expecting a source tarball (with the 3.0 (<code class="highlighter-rouge">orig</code>) or 3.0 (<code class="highlighter-rouge">quilt</code>) source formats), we use an experimental format (3.0 (<code class="highlighter-rouge">git</code>)) which simply bundles up the entire Git repo as the source!</p>
<p>With the two changes we will make, the actual flow will look like this:</p>
<div class="highlighter-rouge"><pre class="highlight"><code> =================================
|| Upstream ||
|| Repo ||
|| ||
|| /---------\ /----------\ ||
|| | release | | various | ||
|| | tags | | branches | ||
|| \----v----/ \----v-----/ ||
=========v============v==========
I I
=========v============v====================
|| /----v----\ /----v-----\ Our ||
|| | release | | various | Repo ||
|| | tags | | branches | ||
|| \----v----/ \----------/ ||
|| I ||
|| I /-------------\ ||
|| I | debian dir. | ||
|| I | changes | ||
|| I \--v----------/ ||
|| I I ||
|| /----v-------v-\ /--------------\ ||
|| | stanford-XXX | | stanford/XXX | ||
|| | branches +---> tags | ||
|| \--------------/ \-------v------/ ||
|| I ||
===============v===============v===========
I I
I /---------v--------\
\-----> Debian package |
\------------------/
</code></pre>
</div>
<p>The overall process goes like this:</p>
<ul>
<li>First, we make a clone of the upstream repository. That brings in upstream’s branches (like <code class="highlighter-rouge">master</code>, <code class="highlighter-rouge">1.x</code>, and <code class="highlighter-rouge">2.x</code>).</li>
<li>We pick a release tag (like <code class="highlighter-rouge">2.1.2</code>) and branch it (making the <code class="highlighter-rouge">stanford-2.1.2</code> branch).</li>
<li>We change some of the stuff in the debian directory, and we tag our changes.</li>
<li>We build our package. The final package includes a copy of the entire Git repository as the source, instead of a <code class="highlighter-rouge">.tar</code> file.</li>
</ul>
<p>The following sections describe each of those four overall steps.</p>
<h2 id="creating-the-repository">Creating the Repository</h2>
<p>Singuarity has their repository in Github, so cloning the repository is just a matter of forking it. However, if you want your repository to live somewhere other than Github, you can do this process:</p>
<p>First, create a blank repository, add the upstream Github as a source, and fetch:</p>
<div class="highlighter-rouge"><pre class="highlight"><code> git init .
git remote add lbl [email protected]:singularityware/singularity.git
git fetch lbl
</code></pre>
</div>
<p>Next, add a new remote representing your upstream repository:</p>
<div class="highlighter-rouge"><pre class="highlight"><code> git remote add stanford [email protected]:vsoch/singularity.git
</code></pre>
</div>
<p>Check out the branches you care about, and link them to your upstream:</p>
<div class="highlighter-rouge"><pre class="highlight"><code> for i in master 1.x 2.x gh-pages; do
git checkout lbl/$i
git checkout -b $i
git branch -u stanford/$i
done
</code></pre>
</div>
<p>Finally, push everything to your new upstream:</p>
<div class="highlighter-rouge"><pre class="highlight"><code> git push --all stanford
git push --tags stanford
</code></pre>
</div>
<h2 id="updating-your-repository">Updating Your Repository</h2>
<p>From time to time, you should pull in upstream changes, so that your repository is in sync. Here’s how to do that.</p>
<p>First, create a blank repository, and add both your remote and the upstream remote. Then, fetch from both:</p>
<div class="highlighter-rouge"><pre class="highlight"><code> git init .
git remote add lbl [email protected]:singularityware/singularity.git
git remote add stanford [email protected]:vsoch/singularity.git
git fetch --all
</code></pre>
</div>
<p>Next, synchronize all changes from the branches we know about:</p>
<div class="highlighter-rouge"><pre class="highlight"><code> for i in master 1.x 2.x gh-pages; do
git checkout stanford/$i
git checkout -b $i
git branch -u stanford/$i
git merge lbl/$i
done
</code></pre>
</div>
<p>Then, run git branch -r and look to see if upstream has any new branches. If they do, then create matching branches on your end:</p>
<div class="highlighter-rouge"><pre class="highlight"><code> for i in new1 new2; do
git checkout lbl/$i
git checkout -b $i
git branch -u stanford/$i
done
</code></pre>
</div>
<p>Finally, push everything up to your copy:</p>
<div class="highlighter-rouge"><pre class="highlight"><code> git push --all stanford
git push --tags stanford
</code></pre>
</div>
<p>If you are leaving upstream’s branches untouched, then all of the merges should be fast-forward merges. If, however, you are making changes in upstream branches (like <code class="highlighter-rouge">master</code>, or <code class="highlighter-rouge">2.x</code>), you should expect either a non-fast-forward merge or a conflict. It’s up to you to deal with them.</p>
<h2 id="making-a-release">Making a release</h2>
<p>When upstream makes a release, we should do the same. Even if we aren’t going to package it, making the release now means that packaging will go faster later!</p>
<p>First, if you don’t have the Git repository checked out, get it now:</p>
<div class="highlighter-rouge"><pre class="highlight"><code> git clone https://github.com/vsoch/singularity.git
</code></pre>
</div>
<p>Next, either switch to the branch you want to build, or check out the tag for the release you want. In this case, we are getting <code class="highlighter-rouge">2.1.2</code> (which is a tag).</p>
<div class="highlighter-rouge"><pre class="highlight"><code> git checkout 2.1.2
</code></pre>
</div>
<p>Then, create a new branch for that specific version, to which we’ll add our changes:</p>
<div class="highlighter-rouge"><pre class="highlight"><code> git checkout -b stanford-2.1.2
</code></pre>
</div>
<p>Now that we have our branch, there are two things we have to check:</p>
<ol>
<li>Check debian/source/format, and change it to 3.0 (git).</li>
<li>Check debian/control, and add git to the “Build-Depends” list.</li>
</ol>
<p>Once those changes are made, commit them.</p>
<div class="highlighter-rouge"><pre class="highlight"><code> git commit -m 'Changing to git source format' debian/control debian/source/format
</code></pre>
</div>
<p>If you are working from your own Git repository, then you should also change the “Vcs-Git” and “Vcs-Browser” fields in debian/control. You should also add yourself to the “Uploaders” field. Then, once again, commit.</p>
<p>Next, you need to update the changelog. This is what sets the release, and also the version number!</p>
<div class="highlighter-rouge"><pre class="highlight"><code> dch -D xenial-backports -v 2.1.2-1~sbp16.04.1+1 'Releasing for Xenial'
git commit -m 'Update changelog for release' debian/changelog
</code></pre>
</div>
<p>(See the “Version Numbering” section for help on deciding what version number to use.)</p>
<p>Finally, make a new tag repesenting your version.</p>
<div class="highlighter-rouge"><pre class="highlight"><code> git tag -s stanford/2.1.2-1_sbp16.04.1+1
</code></pre>
</div>
<p>(We changed the <code class="highlighter-rouge">~</code> in the version number to an <code class="highlighter-rouge">_</code> because Git doesn’t allow the tilde character in tag names.)</p>
<p>When making the tag, an editor will launch, giving you a space to enter a tag description. Simply re-use the entry you made into debian/changelog (just copy-paste the entire changelog entry, including the header and the date line).</p>
<p>If you don’t have a PGP key, then change <code class="highlighter-rouge">-s</code> to <code class="highlighter-rouge">-a</code>.</p>
<p>Finally, push everything, and you are ready to build!</p>
<div class="highlighter-rouge"><pre class="highlight"><code> git push
git push --tags
</code></pre>
</div>
<p>At this point, you can either go on to build the package, or you can stop, and the release will remain ready for when you do want to build.</p>
<h2 id="version-numbering">Version Numbering</h2>
<p>Version numbering is interesting in Debian, because you need to keep track of at least two things:</p>
<ul>
<li>The upstream version number.</li>
<li>The Debian revision number, which is essentially the version number for the debian directory contents.</li>
</ul>
<p>But, you may also have to add other things:</p>
<ul>
<li>Debian derivatives (like Ubuntu) add their own suffix and number, like ubuntu1 or ubuntu2.</li>
<li>If you are building something outside of the normal process, such as a backport (a newer version packaged for a production Debian release) or a test build, you need an additional suffix for that, normally a tilde character followed by something.</li>
</ul>
<p>When constructing the package version number, there are two rules, and one very important exception to remember:</p>
<ul>
<li>Version numbers are evaluated in “parts”, where each “part” is non-digit characters followed by digit characters. So, in the version number <code class="highlighter-rouge">2.1.2-1</code>, the parts are <code class="highlighter-rouge">2</code>, <code class="highlighter-rouge">.1</code>, <code class="highlighter-rouge">.2</code>, and <code class="highlighter-rouge">-1</code>.</li>
<li>Within a part, first the non-numeric portion is compared (using an ASCII sort), and if equal, the numeric portion is compared (using a numeric sort).</li>
<li>In Debian version numbers, the tilde character (<code class="highlighter-rouge">~</code>) sorts before everything else, including the empty string.</li>
</ul>
<p>Because of that exception, if you have a test build (like <code class="highlighter-rouge">2.1.2-1~testFoo+1</code>) or a backport (<code class="highlighter-rouge">2.1.2-1~bpo8+1</code>), Debian will treat those versions as being <em>older</em> than a released version (like <code class="highlighter-rouge">2.1.2-1</code> or <code class="highlighter-rouge">2.1.2-1ubuntu1</code>).</p>
<p>More information is available in the <a href="https://www.debian.org/doc/debian-policy/" target="_blank">Debian Policy Manual</a>, sections <a href="https://www.debian.org/doc/debian-policy/ch-binary.html#s-versions" target="_blank">3.2</a> and <a href="https://www.debian.org/doc/debian-policy/ch-controlfields.html#s-f-Version" target="_blank">5.6.12</a>.</p>
<p>Given all of the above, here are recommended version numbers to use:</p>
<ul>
<li>Backports (no code changes) for Debian should use the form <code class="highlighter-rouge">VERSION-1~sbp8+1</code>, where the <code class="highlighter-rouge">8</code> is the version number of the Debian release (Debian jessie is version 8).</li>
<li>Backports (no code changes) for Ubuntu should use the form <code class="highlighter-rouge">VERSION-1~sbp16.04+1</code>. Similarly, <code class="highlighter-rouge">16.04</code> is the Ubuntu version.</li>
<li>If we are making actual code changes, we should use a form like <code class="highlighter-rouge">VERSION-1stanford1</code>. We shoud then try to get those code changes applied upstream.</li>
</ul>
<p>We use a different form for code changes because we want that to remain newer than anything that comes in through Debian/Ubuntu upstream (lest we lose our changes in an upgrade). Since backports don’t have code changes, they are lower-priority.</p>
<h2 id="building-the-package">Building the package</h2>
<p>Once you have a release tagged and pushed, it is time to build the package.
Before you start, you have to make a choice: You can either build the package on your own system, or you can use the Debian build service. Either way, the build products are the same.</p>
<h3 id="building-on-your-own-system">Building on your own system</h3>
<p>The easiest way to build Singularity packages is on a system that you’ve already got. On the one hand, you don’t have to maintain a separate infrastructure! However, you will only build for the release that you are running on that system. So, if you’re running Debian wheezy, you’ll only be able to build packages for Debian wheezy.</p>
<p>The other downside is that you’ll have to install all of the build dependencies system-wide. However, that’s not a big problem here, because Singularity’s needs are very simple. There are four packages (plus all of their dependencies) that need to be installed:</p>
<ul>
<li><code class="highlighter-rouge">build-essential</code> is a single package that installs (via dependencies) all of essential things that are required for building Debian packages.</li>
<li><code class="highlighter-rouge">debhelper</code> is a suite of scripts that help to automate the Debian package-building process. Almost all of the steps in making a package, such as generating the list of changes, are orchestrated by debhelper. (Singularity uses debhelper, which is why this is required.)</li>
<li><code class="highlighter-rouge">dh-autoreconf</code> is an optional debhelper component that ensures autoreconf is run before the software’s configure script. This package also has the various autotools (<code class="highlighter-rouge">autoconf</code>, <code class="highlighter-rouge">automake</code>, etc.) as dependencies, so we can be sure they are also installed. (Singularity uses <code class="highlighter-rouge">dh-autoreconf</code>, which is why this is required.)</li>
<li>Since we are getting everything from a Git repository, you’ll need to install git.</li>
</ul>
<p>You only have to do this the first time you build on this system.</p>
<div class="highlighter-rouge"><pre class="highlight"><code> aptitude install -y build-essential debhelper dh-autoreconf git
</code></pre>
</div>
<p>Now it’s time to build the package! Here’s the command to use:</p>
<div class="highlighter-rouge"><pre class="highlight"><code> dpkg-buildpackage -us -uc
</code></pre>
</div>
<p>That’s it! That one command triggers an entire sequence of commands that will archive the source, build it, package the output, and create ancillary files. The command output is relatively good at explaining what’s going on, so I won’t reproduce or expand on that here.</p>
<h3 id="using-the-debian-build-server">Using the Debian Build Server</h3>
<p>If you plan on building for a release that is not your own, or you are unable to install all of the build dependencies, then you should use the Debian build server!</p>
<p>First, log in to the build server, and go to your scratch directory. Make a build-area directory, if you don’t have one already:</p>
<div class="highlighter-rouge"><pre class="highlight"><code> ssh $USER@buildserver
cd $SCRATCH/$USER
test -d build-area || mkdir build-area
</code></pre>
</div>
<p>Check out the repository, go into it, and then check out the branch or tag that you want to package:</p>
<div class="highlighter-rouge"><pre class="highlight"><code> git clone https://github.com/vsoch/singularity.git
cd singularity
git checkout stanford-2.1.2
</code></pre>
</div>
<p>Look at the list of available releases to build against, and then pick one:</p>
<div class="highlighter-rouge"><pre class="highlight"><code> ls -d /var/cache/pbuilder/base*.cow
</code></pre>
</div>
<p>Once the release you want is available, build your package!</p>
<div class="highlighter-rouge"><pre class="highlight"><code> pdebuild --pbuilder cowbuilder --buildresult ../build-area -- \
--basepath /var/cache/pbuilder/base-xenial.cow
</code></pre>
</div>
<p>The <code class="highlighter-rouge">pdebuild</code> process takes care of several different things:</p>
<ul>
<li>Instructing <code class="highlighter-rouge">cowbuilder</code> to spawn a new COW (copy-on-write) environment, based on the release you specify, and start a root session within the environment.</li>
<li>Identifying any missing build dependencies, and installing them inside the build environent.</li>
<li>Running dpkg-buildpackage, making sure that build products get put in the right place, and owned by you (not by <code class="highlighter-rouge">root</code>).</li>
</ul>
<p>Once the build process is complete, the final products are placed into the build-area directory you created, but some intermediate products are left in the parent directory, which you should delete:</p>
<div class="highlighter-rouge"><pre class="highlight"><code> rm ../singularity_*.dsc ../singularity_*.git \
../singularity_*.changes ../singularity_*.build
</code></pre>
</div>
<p>That’s it! You now have stuff that you can install or upload.</p>
<h3 id="build-products-and-uploading">Build Products, and Uploading</h3>
<p>Once package-building is complete, you should have three or four build products:</p>
<ul>
<li>The <code class="highlighter-rouge">.deb</code> file is your package! You can install this directly with <code class="highlighter-rouge">dpkg -i DEB_FILE_PATH</code>.</li>
<li>The <code class="highlighter-rouge">.build</code> is a complete log of the steps taken to build your package, as well as the output (standard out and standard error) from those steps. If you are building locally, then this file might only be created if there was a problem. If you are using the build server, this file is always created.</li>
<li>The <code class="highlighter-rouge">.git</code> file is your entire Git repository, packed up in a single file. This is known as a <a href="https://git-scm.com/blog/2010/03/10/bundles.html" target="_blank">Git Bundle</a>.</li>
<li>The .changes file is filled with metadata that is used for uploading a package. It includes information about what package(s) you’re uploading, as well as file sizes and checksums.</li>
<li>The <code class="highlighter-rouge">.dsc</code> file is similar to your .changes file, except this file only contains information on the source. This file contains the information that someone else would need to get the source code you used, install the build dependencies, and then build the binary package themselves.</li>
<li>
<p>The <code class="highlighter-rouge">.dsc</code> and <code class="highlighter-rouge">.changes</code> files are normally signed during the package-build process; this gets skipped normally by pdebuild, and gets disabled on <code class="highlighter-rouge">dpkg-buildpackage</code> by the <code class="highlighter-rouge">-us</code> <code class="highlighter-rouge">-uc</code> options. If you plan on uploading these files to a Debian repository, then you should sign them, either manually or using the debsign command.</p>
<div class="highlighter-rouge"><pre class="highlight"><code>debsign singularity_*.changes
</code></pre>
</div>
</li>
</ul>
<p>You’ll be prompted twice, once to sign the <code class="highlighter-rouge">.dsc</code> file, then again to sign the <code class="highlighter-rouge">.changes</code> file.</p>
<p>Once signed, you can upload using dput:</p>
<div class="highlighter-rouge"><pre class="highlight"><code> dput stanford singularity_*.changes
</code></pre>
</div>
<p>That’s it! Once your servers upgrade, they should see the newer package version as an option.</p>
</div>
<!--links to download are under archive before version 2.2-->
<!--links to download changed at version 2.2-->
</article>
<div id="disqus_thread" style="margin-top:30px"></div>
<script type="text/javascript">
/* * * CONFIGURATION VARIABLES: EDIT BEFORE PASTING INTO YOUR WEBPAGE * * */
var disqus_shortname = 'singularityware'; // required: replace example with your forum shortname
/* * * DON'T EDIT BELOW THIS LINE * * */
(function() {
var dsq = document.createElement('script'); dsq.type = 'text/javascript'; dsq.async = true;
dsq.src = '//' + disqus_shortname + '.disqus.com/embed.js';
(document.getElementsByTagName('head')[0] || document.getElementsByTagName('body')[0]).appendChild(dsq);
})();
</script>
<noscript>Please enable JavaScript to view the <a href="https://disqus.com/?ref_noscript">comments powered by Disqus.</a></noscript>
<hr class="shaded"/>
<footer>
<div class="row">
<!-- Social Media links, etc -->
<div class="col-lg-6 footer">
<a class="no-after social-icon" href="https://twitter.com/SingularityApp">
<i class="fa fa-4x fa-twitter no-after"></i>
</a>
<a class="no-after social-icon" href="https://github.com/singularityware">
<i class="fa fa-4x fa-github no-after"></i>
</a>